Operations Area Working Group

1. Operations Area Working Group Mini-BOF PresentationCOPS push mode policy configuration draft-xu-cops-push-00.txt Tom Taylor (draft editor) <taylor@nortel.com> Tina Tsou (q. 5/11 Rapporteur) <tena@huawei.com>

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. 2

3. Why Both Push and Pull? 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). Session signalling e.g. SIP+SDP Service Control Rs interface uses Q.3301.1 (Diameter) Policy Decision Point Rw interface uses Q.3303.x (COPS-PR, etc.) Possible user resource control signalling e.g. RSVP Policy Enforcement Point User Data • PEP duties: • packet admission/rejection • QoS marking of packets • NAT 3

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

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

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

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 7