1 © 2001, Cisco Systems, Inc. All rights reserved. VVT _05_2001_c1 Resource Priority Header draft-ietf-sip-resource-priority-05 James M Polk Henning Schulzrinne 11 Nov 04

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 Resource Priority Header A means of addressing congestion in SIP elements

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 Changes from previous (-04) version added R-P to the response column of Table 2 from 3261 stated R-P MUST be copied in the response without changes added section 4.2 "Rejection Messages" to include the condition in which an existing call is preempted to take a higher priority call, and gave a reference to “Reason Header for Preemption” ID rewrote "strict mode" to be for MLPP-type use-cases (attempted) reintroduction of “semi-strict mode” to be for GETS/ETS-type use-cases – This has generated “a few” comments on the list Added Preemption Behavior sections for UASs and Proxies, if applied in local policy Addressed that SIPFRAG has problems if a Proxy is expecting to see the R-P header

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 added Section 7 "Namespace Descriptions" with the names and priority-values and expected behaviors added Section 7.1 "Multiple Namespaces in a Message" as a guidance section, giving examples of how priority ordering is to be, and not to be performed a domain that chooses to configure more than one namespace – states local policy determines all this, and they better be careful when doing it Modified the Security Considerations section to get into how poor implementations could be dangerous, and the top 3 things to look out for when enabling this header – left the rest of the Sec Cons section alone (is this good?) Modified the IANA registration section to give an example registry layout of both the namespace registry and the priority-value registry Changes from previous version II

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 Issues brought up since -05 submitted That namespaces should not be bound to an expected behavior – doc is guidance and clearly 1 or more networks will use a namespace the way registered – so be careful! Somehow want a unknown RP to be forwarded by an intermediary *and* mid- hop replied to that the RP was malformed

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 To limit RP to only be used in INVITEs... “semi-strict” mode should be removed... To remove namespace behaviors from ID... Doesn’t want any authorization mechanism recommended... Doesn’t like that IETF should define new namespaces... Issues brought up since -05 submitted II

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 Proposal to remove confusion about Modes Remove “modes” –Creating a behavior template to each namespace was clearly no longer working Create 2 (3261) tables (one with, one without ‘Require’ Header): –This is the SIP protocol level behavior That we move all behavior descriptions into separate subsections independent of namespace Define each namespace Within each namespace, state the behaviors expected Create new R-P table that matches namespaces to expected behaviors (ala 3261’s table 2) –To be what goes into IANA –To be what new namespaces must complete in their definition

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 From Table 2 of 3261 Header field where proxy INV ACK CAN BYE REG OPT PRA Resource-Priority R amdr m m m m m m m Resource-Priority r amdr c c c c c c c Resource-Priority m - m m m m m Header field where proxy SUB NOT UPD MSG REF INF PUB Resource-Priority R amdr m m m m m m m Resource-Priority r amdr c c c c c c c Resource-Priority m - m m m m m Example table with ‘Require’ Header another table would be created for without Require header

© 2001, Cisco Systems, Inc. All rights reserved VVT _05_2001_c1 New Table for Resource Priority Behaviors Namespaces dsn drsn q735 ets wps Number of Priority-values Reference ****** this RFC (if ever published)***** Preemption Policy yes yes yes no no Queue Based Policy no no no yes yes New Error Code and the list goes on... Each behavior is to be uniquely defined previously in the document

© 2001, Cisco Systems, Inc. All rights reserved. 10 © 2001, Cisco Systems, Inc. All rights reserved. 10 © 2001, Cisco Systems, Inc. All rights reserved. 10 VVT _05_2001_c1 What’s next? Rev doc in roughly 2 weeks Another (short) WGLC...pray (repeat above steps if necessary)