Re: Question about draft-xu-cops-push-00.txt

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 
original request.

A pull mode example is probably more familiar, so I won't go into detail.

My co-authors can better explain the choice of COPS. Back when they first 
started this work, the industry had not yet made a choice between COPS and other 
protocols, so their decision was reasonable. I should mention that the ITU-T is 
also working on draft Recommendations based on H.248 (like the TISPAN Ia 
interface) and on Diameter. Diameter presents similar problems to COPS, in that 
the natural roles of client and server are reversed when moving from pull to 
push mode.


Romascanu, Dan (Dan) wrote:
> I have a question related to
> http://www.ietf.org/internet-drafts/draft-xu-cops-push-00.txt, which
> will be the subject of a mini-BOF in the OPS Area meeting in Prague. The
> document describes an optimization of COPS so that it can be used in a
> push mode at a degree of efficiency that is similar to the one of the
> pull mode for which the protocol was originally designed. What are the
> use cases and application or applications that require using COPS in a
> push mode? And if push mode is required, than why COPS? 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>  
> 
>  
> 
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ops-area
> 

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ops-area