Re: Question about draft-xu-cops-push-00.txt
Tom-PT Taylor <taylor <at> nortel.com>
2007-03-13 20:02:57 GMT
The other individuals copied on this response are probably better qualified to
answer, but I'll have a go.
The architecture, using ITU-T terminology, is as follows: the Policy Decision
Function (PDF) sets policy. The Transport Enforcement function (TEF) enforces
the policy. The interface between them is variously designated Rw (in the
ITU-T), Ia (in TISPAN), Go/Gx (in 3GPP), or TC-1 (in the MultiService Forum).
The particular role of the Rw interface is to carry admission decisions and
related material such as NAT configuration requests and responses.
To broaden the picture, the Policy Decision Function gets requests from the
P-CSCF (more abstractly, the Service Control Function, SCF). That interface is
designated Rs in the ITU-T, Gq' in TISPAN, Gq in 3GPP, and TC-0 in the
MultiService Forum. Everyone agrees that the protocol across that interface is
Diameter, but there is variation in the AVPs that have to be supported.
The SCF, PDF, and TEF interact on a per-session basis. Whether push or pull mode
is used depends on signalling capabilities at the user terminal and the access
technology in use. That can vary from session to session.
To take the push mode example: suppose the terminal is unable to signal at the
transport level (e.g. using RSVP or NSIS). Then the network has to act on its
behalf. The terminal sends a SIP INVITE with SDP to the P-CSCF. The P-CSCF
analyzes the SDP to determine the implied QoS requirements and the external
transport addresses associated with the flow and passes an admission request on
to the PDF. The PDF checks its sources of policy information to decide whether
the flows can be admitted; if so, it sends a request down to the TEF to admit
the flow and set up NATing (if applicable). The TEF returns the NAT address
assignments, which the PDF passes back to the SCF in its response to the