1. Operations Area Working Group Mini-BOF Presentation COPS push mode policy configuration draft-xu-cops-push-00.txt Tom Taylor (draft editor) Tina Tsou (q. 5/11 Rapporteur)

2. 2 Background Draft Rec. Q.3303.1 alias Q.rcp3 has been around for a couple of years –COPS-PR-based control of transport border element (see architecture, next page); –scheduled for initiation of Study Group Last Call (“consent”) next month. Recent realization that chosen approach violates COPS-PR as currently defined. draft-xu-cops-push-00.txt proposes to formally extend COPS-PR to legitimize approach used in draft Q.3303.1. This mini-BOF is an opportunity to clarify the issues and suggest preferable way forward. –ITU-T is standardizing multiple protocols (COPS-PR, Megaco/H.248, Diameter) for the same interface, so saying that a different protocol should be used implies a new work item with this one continuing to completion anyway.

3. 3 Why Both Push and Pull? Service Control Session signalling e.g. SIP+SDP Policy Decision Point Policy Enforcement Point User Data Possible user resource control signalling e.g. RSVP Rs interface uses Q.3301.1 (Diameter) Rw interface uses Q.3303.x (COPS-PR, etc.) PEP duties: packet admission/rejection QoS marking of packets NAT For sessions without user resource control signalling, Rs interface is used for authorization, reservation, and commitment (PUSH mode, triggered by session signalling). For sessions with user resource control signalling, request for commitment flows from PEP to PDP across the Rw interface (PULL mode).

4. 4 COPS-PR Works Efficiently For PULL PEPPDP Initiating event REQ (New handle) DEC (handle, policy) RPT (handle,...) Modifying event RPT (handle,...) DEC (handle, policy) RPT (handle,...) Clearing event DRQ (handle,...)

5. 5... But Not So Well For PUSH PEPPDP Initiating event REQ (New handle) DEC (handle 0, policy) RPT (handle 0,...) DEC (handle 1, policy) RPT (handle 1,...) DEC (handle 0, Request_State) REQ (handle 1) PEPPDP Clearing event RPT (handle 1,...) DRQ (handle 1,...) DEC (handle 1, Request_Delete)

6. 6 What ITU-T Authors Propose PEPPDP Initiating event REQ (New handle) DEC (handle 0, policy) RPT (handle 0,...) DEC (New handle 1, policy, Push_State) RPT (handle 1,...) DEC (handle 0, Request_State) REQ (handle 1) PEPPDP Clearing event RPT (handle 1,...) DRQ (handle 1,...) DEC (handle 1, Push_Delete) Necessity accepted in list discussion

7. 7 List Comments David Durham 2/26/2007 –ITU-T should have defined performance requirements to justify concerns –suggestion to pre-allocate handles to mitigate latency problem –against removing RPT requirement on session teardown (TT accepted on list) –as a general principle, interoperability takes precedence over optimization Dan Romascanu 3/12/2007 –use cases for push mode usage? –why COPS? –Tom Taylor reply 3/13/2007, Heyuan Xu reply 3/15/2007 use case essentially covered in previous slides Juergen Schoenwaelder 3/15/2007 –what characteristics caused COPS to be used instead of NETCONF? –Heyuan Xu reply noted above – what was implemented in his routers NETCONF new at the time