1© 2001, Cisco Systems, Inc. All rights reserved.© 2001, Cisco Systems, Inc. All rights reserved.© 2001, Cisco Systems, Inc. All rights reserved.VVT-2202981_05_2001_c1

Resource Priority Header

draft-ietf-sip-resource-priority-05

James M PolkHenning Schulzrinne

11 Nov 04

© 2001, Cisco Systems, Inc. All rights reserved. 2© 2001, Cisco Systems, Inc. All rights reserved. 2© 2001, Cisco Systems, Inc. All rights reserved. 2VVT-2202981_05_2001_c1

Resource Priority Header

• A means of addressing congestion in SIP elements

© 2001, Cisco Systems, Inc. All rights reserved. 3© 2001, Cisco Systems, Inc. All rights reserved. 3© 2001, Cisco Systems, Inc. All rights reserved. 3VVT-2202981_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. 4© 2001, Cisco Systems, Inc. All rights reserved. 4© 2001, Cisco Systems, Inc. All rights reserved. 4VVT-2202981_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. 5© 2001, Cisco Systems, Inc. All rights reserved. 5© 2001, Cisco Systems, Inc. All rights reserved. 5VVT-2202981_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. 6© 2001, Cisco Systems, Inc. All rights reserved. 6© 2001, Cisco Systems, Inc. All rights reserved. 6VVT-2202981_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. 7© 2001, Cisco Systems, Inc. All rights reserved. 7© 2001, Cisco Systems, Inc. All rights reserved. 7VVT-2202981_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. 8© 2001, Cisco Systems, Inc. All rights reserved. 8© 2001, Cisco Systems, Inc. All rights reserved. 8VVT-2202981_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 200 - 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 200 - 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. 9© 2001, Cisco Systems, Inc. All rights reserved. 9© 2001, Cisco Systems, Inc. All rights reserved. 9VVT-2202981_05_2001_c1

New Table for Resource Priority

Behaviors Namespaces dsn drsn q735 ets wps--------- --- ---- ---- --- ---Number of Priority-values 5 6 5 5 5

Reference ****** this RFC (if ever published)*****

Preemption Policy yes yes yes no no

Queue Based Policy no no no yes yes

New Error Code 417 417 417 417 417

...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. 10VVT-2202981_05_2001_c1

What’s next?

• Rev doc in roughly 2 weeks• Another (short) WGLC• ...pray....• ... (repeat above steps if necessary)