< draft-ietf-sip-resource-priority-09.txt   draft-ietf-sip-resource-priority-10.txt >
Network Working Group H. Schulzrinne Network Working Group H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: December 1, 2005 J. Polk Expires: January 14, 2006 J. Polk
Cisco Cisco
May 30, 2005 July 13, 2005
Communications Resource Priority for the Session Initiation Protocol Communications Resource Priority for the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sip-resource-priority-09 draft-ietf-sip-resource-priority-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 1, 2005. This Internet-Draft will expire on January 14, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines two new SIP header fields for communicating This document defines two new SIP header fields for communicating
resource priority, namely "Resource-Priority" and "Accept-Resource- resource priority, namely "Resource-Priority" and "Accept-Resource-
Priority". The "Resource-Priority" header field can influence the Priority". The "Resource-Priority" header field can influence the
skipping to change at page 2, line 12 skipping to change at page 2, line 12
telephones, and SIP proxies. It does not directly influence the telephones, and SIP proxies. It does not directly influence the
forwarding behavior of IP routers. forwarding behavior of IP routers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. The Resource-Priority and Accept-Resource-Priority SIP 3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 7 Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 The 'Resource-Priority' Header Field . . . . . . . . . . . 7 3.1 The 'Resource-Priority' Header Field . . . . . . . . . . . 7
3.2 The 'Accept-Resource-Priority' Header Field . . . . . . . 8 3.2 The 'Accept-Resource-Priority' Header Field . . . . . . . 9
3.3 Usage of the 'Resource-Priority' and 3.3 Usage of the 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . . . . . . . . . 9 'Accept-Resource-Priority' Header Fields . . . . . . . . . 9
3.4 The 'resource-priority' Option Tag . . . . . . . . . . . . 9 3.4 The 'resource-priority' Option Tag . . . . . . . . . . . . 10
4. Behavior of SIP Elements that Receive Prioritized Requests . . 10 4. Behavior of SIP Elements that Receive Prioritized Requests . . 10
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 General Rules . . . . . . . . . . . . . . . . . . . . . . 10 4.2 General Rules . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Usage of Require Header with Resource-Priority . . . . . . 11 4.3 Usage of Require Header with Resource-Priority . . . . . . 11
4.4 OPTIONS Request with Resource-Priority . . . . . . . . . . 11 4.4 OPTIONS Request with Resource-Priority . . . . . . . . . . 11
4.5 Approaches for Preferential Treatment of Requests . . . . 11 4.5 Approaches for Preferential Treatment of Requests . . . . 11
4.5.1 Preemption . . . . . . . . . . . . . . . . . . . . . . 12 4.5.1 Preemption . . . . . . . . . . . . . . . . . . . . . . 12
4.5.2 Priority Queueing . . . . . . . . . . . . . . . . . . 12 4.5.2 Priority Queueing . . . . . . . . . . . . . . . . . . 12
4.6 Error Conditions . . . . . . . . . . . . . . . . . . . . . 13 4.6 Error Conditions . . . . . . . . . . . . . . . . . . . . . 13
4.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . 13 4.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . 13
4.6.2 No Known Namespace or Priority Value . . . . . . . . . 13 4.6.2 No Known Namespace or Priority Value . . . . . . . . . 13
4.6.3 Authentication Failure . . . . . . . . . . . . . . . . 14 4.6.3 Authentication Failure . . . . . . . . . . . . . . . . 14
4.6.4 Authorization Failure . . . . . . . . . . . . . . . . 14 4.6.4 Authorization Failure . . . . . . . . . . . . . . . . 14
4.6.5 Insufficient Resources . . . . . . . . . . . . . . . . 14 4.6.5 Insufficient Resources . . . . . . . . . . . . . . . . 14
4.6.6 Busy . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6.6 Busy . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7 Element-Specific Behaviors . . . . . . . . . . . . . . . . 15 4.7 Element-Specific Behaviors . . . . . . . . . . . . . . . . 15
4.7.1 User Agent Client Behavior . . . . . . . . . . . . . . 15 4.7.1 User Agent Client Behavior . . . . . . . . . . . . . . 15
4.7.2 User Agent Server Behavior . . . . . . . . . . . . . . 16 4.7.2 User Agent Server Behavior . . . . . . . . . . . . . . 16
4.7.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . 17 4.7.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . 16
5. Third-Party Authentication . . . . . . . . . . . . . . . . . . 17 5. Third-Party Authentication . . . . . . . . . . . . . . . . . . 17
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1 Simple Call . . . . . . . . . . . . . . . . . . . . . . . 18 7.1 Simple Call . . . . . . . . . . . . . . . . . . . . . . . 18
7.2 Receiver Does Not Understand Namespace . . . . . . . . . . 19 7.2 Receiver Does Not Understand Namespace . . . . . . . . . . 19
8. Handling Multiple Concurrent Namespaces . . . . . . . . . . . 21 8. Handling Multiple Concurrent Namespaces . . . . . . . . . . . 21
8.1 General Rules . . . . . . . . . . . . . . . . . . . . . . 21 8.1 General Rules . . . . . . . . . . . . . . . . . . . . . . 21
8.2 Examples of Valid Orderings . . . . . . . . . . . . . . . 22 8.2 Examples of Valid Orderings . . . . . . . . . . . . . . . 22
8.3 Examples of Invalid Orderings . . . . . . . . . . . . . . 22 8.3 Examples of Invalid Orderings . . . . . . . . . . . . . . 22
9. Registering Namespaces . . . . . . . . . . . . . . . . . . . . 23 9. Registering Namespaces . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 14 skipping to change at page 3, line 14
11.1 General Remarks . . . . . . . . . . . . . . . . . . . . . 27 11.1 General Remarks . . . . . . . . . . . . . . . . . . . . . 27
11.2 Authentication and Authorization . . . . . . . . . . . . . 27 11.2 Authentication and Authorization . . . . . . . . . . . . . 27
11.3 Confidentiality and Integrity . . . . . . . . . . . . . . 28 11.3 Confidentiality and Integrity . . . . . . . . . . . . . . 28
11.4 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 29 11.4 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 29
11.5 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29 11.5 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 29 12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 29
12.2 IANA Registration of 'Resource-Priority' and 12.2 IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . . . . . . . . . 30 'Accept-Resource-Priority' Header Fields . . . . . . . . . 30
12.3 IANA Registration for Option Tag resource-priority . . . . 30 12.3 IANA Registration for Option Tag resource-priority . . . . 30
12.4 IANA Registration for Response Code 417 . . . . . . . . . 31 12.4 IANA Registration for Response Code 417 . . . . . . . . . 30
12.5 IANA Resource-Priority Namespace Registration . . . . . . 31 12.5 IANA Resource-Priority Namespace Registration . . . . . . 31
12.6 IANA Priority-Value Registrations . . . . . . . . . . . . 31 12.6 IANA Priority-Value Registrations . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1 Normative References . . . . . . . . . . . . . . . . . . . 32 14.1 Normative References . . . . . . . . . . . . . . . . . . . 32
14.2 Informative References . . . . . . . . . . . . . . . . . . 33 14.2 Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . 36
1. Introduction 1. Introduction
skipping to change at page 6, line 28 skipping to change at page 6, line 28
requests pass through unchanged. This is important since it is requests pass through unchanged. This is important since it is
likely that this mechanism will often be deployed in networks where likely that this mechanism will often be deployed in networks where
the edge networks are unaware of the resource priority mechanism and the edge networks are unaware of the resource priority mechanism and
provide no special privileges to such requests. The request then provide no special privileges to such requests. The request then
reaches a GSTN gateway or set of SIP elements that are aware of the reaches a GSTN gateway or set of SIP elements that are aware of the
mechanism. mechanism.
For conciseness, we refer to SIP proxies and user agents (UAs) that For conciseness, we refer to SIP proxies and user agents (UAs) that
act on the 'Resource-Priority' header field as RP actors. act on the 'Resource-Priority' header field as RP actors.
It is likely to be common that the same SIP element will handle
requests that bear the 'Resource-Priority' header fields and those
that do not.
Government entities and standardization bodies have developed several Government entities and standardization bodies have developed several
different priority schemes for their networks. Users would like to different priority schemes for their networks. Users would like to
be able to obtain authorized priority handling in several of these be able to obtain authorized priority handling in several of these
networks, without changing SIP clients. Also, a single call may networks, without changing SIP clients. Also, a single call may
traverse SIP elements that are run by different administrations and traverse SIP elements that are run by different administrations and
subject to different priority mechanisms. Since there is no global subject to different priority mechanisms. Since there is no global
ordering among those priorities, we allow each request to contain ordering among those priorities, we allow each request to contain
more than one priority value drawn from these different priority more than one priority value drawn from these different priority
lists, called a namespace in this document. Typically, each SIP lists, called a namespace in this document. Typically, each SIP
element only supports one such namespace, but we discuss what happens element only supports one such namespace, but we discuss what happens
skipping to change at page 11, line 4 skipping to change at page 11, line 8
If a SIP element receives the 'Resource-Priority' header field in a If a SIP element receives the 'Resource-Priority' header field in a
request other than those listed above, the header MAY be ignored, request other than those listed above, the header MAY be ignored,
according to the rules of [RFC3261]. according to the rules of [RFC3261].
In short, an RP actor performs the following steps when receiving a In short, an RP actor performs the following steps when receiving a
prioritized request. Error behavior is described in Section 4.6. prioritized request. Error behavior is described in Section 4.6.
1. If the RP actor recognizes none of the name spaces, treat the 1. If the RP actor recognizes none of the name spaces, treat the
request as if it had no 'Resource-Priority' header field. request as if it had no 'Resource-Priority' header field.
2. Ascertain that the request is authorized according to local 2. Ascertain that the request is authorized according to local
policy to use the priority levels indicated. If the request is policy to use the priority levels indicated. If the request is
not authorized, reject it. Examples of authorization policies not authorized, reject it. Examples of authorization policies
are discussed in Security Considerations (Section 11). are discussed in Security Considerations (Section 11).
3. If the request is authorized, either preempt other current 3. If the request is authorized and resources are available (no
sessions or insert the request into a priority queue, as congestion), serve the request as usual. If the request is
described in Section 4.5. authorized, but resources are not available (congestion), either
preempt other current sessions or insert the request into a
priority queue, as described in Section 4.5.
4.3 Usage of Require Header with Resource-Priority 4.3 Usage of Require Header with Resource-Priority
Following standard SIP behavior, if a SIP request contains the Following standard SIP behavior, if a SIP request contains the
'Require' header field with the 'resource-priority' option tag, a SIP 'Require' header field with the 'resource-priority' option tag, a SIP
user agent MUST respond with a 420 (Bad Extension) if it does not user agent MUST respond with a 420 (Bad Extension) if it does not
support the SIP extensions described in this document. It then lists support the SIP extensions described in this document. It then lists
"resource-priority" in the 'Unsupported' header field included in the "resource-priority" in the 'Unsupported' header field included in the
response. response.
skipping to change at page 12, line 46 skipping to change at page 13, line 5
In a priority queueing policy, requests that find no available In a priority queueing policy, requests that find no available
resources are queued to the queue assigned to the priority value. resources are queued to the queue assigned to the priority value.
Unless otherwise specified, requests are queued in first-come, first- Unless otherwise specified, requests are queued in first-come, first-
served order. Each priority value may have its own queue or several served order. Each priority value may have its own queue or several
priority values may share a single queue. If a resource becomes priority values may share a single queue. If a resource becomes
available, the RP actor selects the request from the highest-priority available, the RP actor selects the request from the highest-priority
non-empty queue according to the queue service policy. For first- non-empty queue according to the queue service policy. For first-
come, first-served policies, the request from that queue that has come, first-served policies, the request from that queue that has
been waiting the longest is served. Each queue can hold a finite been waiting the longest is served. Each queue can hold a finite
number of pending requests. If the queue for a newly arriving number of pending requests. If the per-priority-value queue for a
request is full, the request is rejected immediately. In addition, a newly arriving request is full, the request is rejected immediately.
priority queueing policy MAY impose a waiting time limit for each In addition, a priority queueing policy MAY impose a waiting time
priority class, where requests that exceed a specified waiting time limit for each priority class, where requests that exceed a specified
are ejected from the queue and a failure response is returned to the waiting time are ejected from the queue and a failure response is
requestor. returned to the requestor.
In addition, an RP actor MAY impose a global queue size limit summed Finally, an RP actor MAY impose a global queue size limit summed
across all queues and drop waiting lower-priority requests. This across all queues and drop waiting lower-priority requests. This
does not imply preemption since the session has not been established does not imply preemption since the session has not been established
yet. yet.
4.6 Error Conditions 4.6 Error Conditions
4.6.1 Introduction 4.6.1 Introduction
In this section, we describe the error behavior that is shared among In this section, we describe the error behavior that is shared among
multiple types of RP actors, including various instances of UAS such multiple types of RP actors, including various instances of UAS such
skipping to change at page 13, line 39 skipping to change at page 13, line 46
changing the outcome. changing the outcome.
4.6.2 No Known Namespace or Priority Value 4.6.2 No Known Namespace or Priority Value
If an RP actor does not understand any of the resource values in the If an RP actor does not understand any of the resource values in the
request, the treatment depends on the presence of the 'Require' request, the treatment depends on the presence of the 'Require'
'resource-priority' option tag: 'resource-priority' option tag:
1. Without the option tag, the RP actor treats the request as if it 1. Without the option tag, the RP actor treats the request as if it
contained no 'Resource-Priority' header field and processes it contained no 'Resource-Priority' header field and processes it
with default priority. with default priority. Resource values that are not understood
MUST NOT be modified or deleted.
2. With the option tag, it MUST reject the request with a 417 2. With the option tag, it MUST reject the request with a 417
(Unknown Resource-Priority) response code. (Unknown Resource-Priority) response code.
Making case (1) the default is necessary since otherwise there would Making case (1) the default is necessary since otherwise there would
be no way to successfully complete any calls in the case where a be no way to successfully complete any calls in the case where a
proxy on the way to the UAS shares no common namespaces with the UAC, proxy on the way to the UAS shares no common namespaces with the UAC,
but the UAC and UAS do have such a namespace in common. but the UAC and UAS do have such a namespace in common.
If a resource value is understood, the resource values that are not
understood MUST NOT be modified, deleted or cause a rejection of the
message.
In general, as noted, a SIP request can contain more than one In general, as noted, a SIP request can contain more than one
'Resource-Priority' header field. This is necessary if a request 'Resource-Priority' header field. This is necessary if a request
needs to traverse different administrative domains, each with their needs to traverse different administrative domains, each with their
own set of valid resource values. For example, the ETS namespace own set of valid resource values. For example, the ETS namespace
might be enabled for United States government networks that also might be enabled for United States government networks that also
support the DSN and/or DRSN namespaces for most individuals in those support the DSN and/or DRSN namespaces for most individuals in those
domains. domains.
A 417 (Unknown Resource-Priority) response MAY, according to local A 417 (Unknown Resource-Priority) response MAY, according to local
policy, include an 'Accept-Resource-Priority' header field policy, include an 'Accept-Resource-Priority' header field
skipping to change at page 15, line 5 skipping to change at page 15, line 10
rejecting the request for reasons of media path availability, such as rejecting the request for reasons of media path availability, such as
insufficient gateway resources. In that case, [RFC3261] advises that insufficient gateway resources. In that case, [RFC3261] advises that
a 488 response SHOULD include a 'Warning' header field with a reason a 488 response SHOULD include a 'Warning' header field with a reason
for the rejection, with warning code 370 (Insufficient Bandwidth) for the rejection, with warning code 370 (Insufficient Bandwidth)
typical. typical.
For systems implementing queueing, if the request is queued, the UAS For systems implementing queueing, if the request is queued, the UAS
will return 408 (Request Timeout) if the request exceeds the maximum will return 408 (Request Timeout) if the request exceeds the maximum
configured waiting time in queue. configured waiting time in queue.
If the originator did not include a 'Resource-Priority' header field,
these error responses will provide the necessary indication to do so.
(In some administrative domains, requests with normal priority will
not include the 'Resource-Priority' header field.) In addition, if
authorized, the requestor may also attempt to use a higher resource
priority value.
4.6.6 Busy 4.6.6 Busy
Resource contention also occurs when a call request arrives at a UAS Resource contention also occurs when a call request arrives at a UAS
that is unable to accept another call, either because the UAS has that is unable to accept another call, either because the UAS has
just one line presence or has active calls on all line presences. If just one line presence or has active calls on all line presences. If
the call request indicates an equal or lower priority value compared the call request indicates an equal or lower priority value compared
to all active calls present on the UAS, the UAS returns a 486 (Busy to all active calls present on the UAS, the UAS returns a 486 (Busy
here) response. here) response.
If the request is queued instead, the UAS will return 408 (Request If the request is queued instead, the UAS will return 408 (Request
skipping to change at page 15, line 46 skipping to change at page 15, line 44
request. request.
Upon receiving a 417 (Unknown Resource-Priority) response, the UAC Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
MAY attempt a subsequent request with the same or different resource MAY attempt a subsequent request with the same or different resource
value. If available, it SHOULD choose authorized resource values value. If available, it SHOULD choose authorized resource values
from the set of values returned in the 'Accept-Resource-Priority' from the set of values returned in the 'Accept-Resource-Priority'
header field. header field.
4.7.1.1 User Agent Client Behavior with a Preemption Algorithm 4.7.1.1 User Agent Client Behavior with a Preemption Algorithm
A UAC in an administrative domain that employs preemption MUST be A UAC that requests a priority value that may cause preemption MUST
prepared to receive a BYE request with a Reason header explaining why understand a Reason header field in the BYE request explaining why
the session was terminated, as discussed in [I-D.ietf-sipping-reason- the session was terminated, as discussed in [I-D.ietf-sipping-reason-
header-for-preemption]. header-for-preemption].
4.7.1.2 User Agent Client Behavior with a Queueing Policy 4.7.1.2 User Agent Client Behavior with a Queueing Policy
By standard SIP protocol rules, a UAC MUST be prepared to receive a By standard SIP protocol rules, a UAC MUST be prepared to receive a
182 (Queued) response from an RP actor that is currently at capacity, 182 (Queued) response from an RP actor that is currently at capacity,
but has put the original request into a queue. A UAC MAY indicate but has put the original request into a queue. A UAC MAY indicate
this queued status to the user by some audio or visual indication to this queued status to the user by some audio or visual indication to
prevent the user from interpreting the call as having failed. prevent the user from interpreting the call as having failed.
skipping to change at page 17, line 11 skipping to change at page 17, line 6
(Queued) response if that element's resources are busy, until it is (Queued) response if that element's resources are busy, until it is
able to handle the request and provide a final response. The able to handle the request and provide a final response. The
frequency of such provisional messages is governed by [RFC3261]. frequency of such provisional messages is governed by [RFC3261].
4.7.3 Proxy Behavior 4.7.3 Proxy Behavior
SIP proxies MAY ignore the 'Resource-Priority' header field. SIP SIP proxies MAY ignore the 'Resource-Priority' header field. SIP
proxies MAY reject any unauthenticated request bearing that header proxies MAY reject any unauthenticated request bearing that header
field. field.
When the 'Require' header is included in a message, it ensures that When the 'Require' header field is included in a message, it ensures
in parallel forking, only branches that support the resource-priority that in parallel forking, only branches that support the resource-
mechanism succeed. priority mechanism succeed.
If S/MIME encapsulation is used according to Section 23 of RFC 3261, If S/MIME encapsulation is used according to Section 23 of RFC 3261,
special considerations apply. As tabulated in Section 3.3, the special considerations apply. As tabulated in Section 3.3, the
'Resource-Priority' header field can be modified by proxies and thus 'Resource-Priority' header field can be modified by proxies and thus
is exempted by the integrity checking described in Section 23.4.1.1 is exempted by the integrity checking described in Section 23.4.1.1
of RFC 3261. Since it may need to be inspected or modified by of RFC 3261. Since it may need to be inspected or modified by
proxies, the header field MUST also be placed in the "outer" message proxies, the header field MUST also be placed in the "outer" message
if the UAC would like proxy servers to be able to act on the header if the UAC would like proxy servers to be able to act on the header
information. Similar considerations apply if parts of the message information. Similar considerations apply if parts of the message
are integrity-protected or encrypted as described in [RFC3420]. are integrity-protected or encrypted as described in [RFC3420].
skipping to change at page 23, line 40 skipping to change at page 23, line 40
Organizations considering the use of the Resource-Priority header Organizations considering the use of the Resource-Priority header
field should investigate if an existing combination of namespace and field should investigate if an existing combination of namespace and
priority-values meets their needs. For example, emergency first priority-values meets their needs. For example, emergency first
responders around the world are discussing utilizing this mechanism responders around the world are discussing utilizing this mechanism
for preferential treatment in future networks. There should not be a for preferential treatment in future networks. There should not be a
unique namespace for different jurisdictions. This will greatly unique namespace for different jurisdictions. This will greatly
increase interoperability and reduce development time, and probably increase interoperability and reduce development time, and probably
reduce future confusion if there is ever a need to map one namespace reduce future confusion if there is ever a need to map one namespace
to another in an interworking function. to another in an interworking function.
Below, we describe the steps necessary to register new namespaces. Below, we describe the steps necessary to register a new namespace.
New namespaces MUST be defined in a Standards Track RFC, following A new namespace MUST be defined in a Standards Track RFC, following
the 'Standards Action' policy in [RFC2434] and MUST include the the 'Standards Action' policy in [RFC2434] and MUST include the
following facets: following facets:
o It must define the namespace label, a unique namespace label o It must define the namespace label, a unique namespace label
within the IANA registry for the SIP Resource-Priority header within the IANA registry for the SIP Resource-Priority header
field. field.
o It must enumerate the priority levels, i.e., 'r-priority' values, o It must enumerate the priority levels, i.e., 'r-priority' values,
the namespace is using. Note that only finite lists are the namespace is using. Note that only finite lists are
permissible, not (e.g.,) unconstrained integers or tokens. permissible, not (e.g.,) unconstrained integers or tokens.
o The priority algorithm (Section 4.5), identifying whether the o The priority algorithm (Section 4.5), identifying whether the
namespace is to be used with priority queueing ("queue") or namespace is to be used with priority queueing ("queue") or
preemption ("preemption"); if queueing is used, the namespace MAY preemption ("preemption"); if queueing is used, the namespace MAY
indicate whether normal-priority requests are queued. If there is indicate whether normal-priority requests are queued. If there is
a new "intended algorithm" other than preemption priority a new "intended algorithm" other than preemption or priority
queueing, the algorithm must be described, taking into account all queueing, the algorithm must be described, taking into account all
RP actors (UAC, UAS, proxies). RP actors (UAC, UAS, proxies).
o A namespace may either reference an existing list of priority o A namespace may either reference an existing list of priority
values or define a new finite list of priority values in relative values or define a new finite list of priority values in relative
priority order for IANA registration within the sip-parameters priority order for IANA registration within the sip-parameters
Resource-Priority priority-values registry. New priority-values Resource-Priority priority-values registry. New priority-values
MUST NOT be added to any previously IANA-registered list SHOULD NOT be added to a previously IANA-registered list
associated with a particular namespace, this will cause associated with a particular namespace, as this may cause
interoperability problems. interoperability problems. Unless otherwise specified, it is
assumed that all priority value confer higher priority than
requests without a priority value.
o Any new SIP response codes unique to this new namespace need to be o Any new SIP response codes unique to this new namespace need to be
explained and registered. explained and registered.
o The reference document must specify and describe any new Warning o The reference document must specify and describe any new Warning
header field warn-codes (RFC 3261, Section 27.2). header field warn-codes (RFC 3261, Section 27.2).
o The document needs to specify a new row for the following table o The document needs to specify a new row for the following table
that summarize the features of the namespace and are included into that summarize the features of the namespace and are included into
IANA Resource-Priority Namespace registration: IANA Resource-Priority Namespace registration:
Intended New New resp. Intended New New resp.
Namespace Levels algorithm warn-code code Reference Namespace Levels algorithm warn-code code Reference
skipping to change at page 25, line 45 skipping to change at page 25, line 46
priority value differs from the other values. Normally, requests do priority value differs from the other values. Normally, requests do
not preempt those of equal priority, but a newly arriving 'flash- not preempt those of equal priority, but a newly arriving 'flash-
override-override' request will displace another one of equal override-override' request will displace another one of equal
priority if there are insufficient resources. This can also be priority if there are insufficient resources. This can also be
expressed as saying that 'flash-override-override' requests defends expressed as saying that 'flash-override-override' requests defends
themselves as 'flash-override' only. themselves as 'flash-override' only.
10.4 The "Q735" Namespace 10.4 The "Q735" Namespace
Q.735.3 [Q.735.3] was created to be a commercial version of the Q.735.3 [Q.735.3] was created to be a commercial version of the
operationally equivalent DSN specification for multi-layer precedence operationally equivalent DSN specification for Multi-Level Precedence
and preemption (MLPP). The Q735 namespace is defined here in the and Preemption (MLPP). The Q735 namespace is defined here in the
same manner. same manner.
The Q735 namespace defines the following resource values, listed in The Q735 namespace defines the following resource values, listed in
order of lowest priority to highest priority: order of lowest priority to highest priority:
(lowest) q735.4 (lowest) q735.4
q735.3 q735.3
q735.2 q735.2
q735.1 q735.1
(highest) q735.0 (highest) q735.0
skipping to change at page 30, line 9 skipping to change at page 30, line 9
12.1 Introduction 12.1 Introduction
This section defines two new SIP headers (Section 12.2), one SIP This section defines two new SIP headers (Section 12.2), one SIP
OPTION tag (Section 12.3), one new 4xx error code (Section 12.4), a OPTION tag (Section 12.3), one new 4xx error code (Section 12.4), a
new registry within the sip-parameters section of IANA for Resource- new registry within the sip-parameters section of IANA for Resource-
Priority namespaces (Section 12.5) and a new registry within the sip- Priority namespaces (Section 12.5) and a new registry within the sip-
parameters section of IANA for Resource-Priority and priority-values parameters section of IANA for Resource-Priority and priority-values
(Section 12.6). (Section 12.6).
Additional namespaces and priority values MUST be registered with Additional namespaces and priority values MUST be registered with
IANA. Within each namespace, the registration MUST indicate the IANA, as described in Section 9.
relative priority levels, expressed as an ordered list. New
priority-values MUST NOT be added to existing namespace registries.
The registration MUST describe, in the registration itself, how SIP
elements should treat requests from that namespace in 'operation',
e.g., whether preemption or only preferential queuing are allowed.
The SIP Change Process [RFC3427] establishes a policy for the The SIP Change Process [RFC3427] establishes a policy for the
registration of new SIP extension headers. Resource priority registration of new SIP extension headers. Resource priority
namespaces and priority values have similar interoperability namespaces and priority values have similar interoperability
requirements to those of SIP extension headers. Consequently, requirements to those of SIP extension headers. Consequently,
registration of new resource priority namespaces and priority values registration of new resource priority namespaces and priority values
requires documentation in an RFC using the extension header approval requires documentation in an RFC using the extension header approval
process specified in RFC 3427. process specified in RFC 3427.
Registration policies for new namespaces are defined in Section 9. Registration policies for new namespaces are defined in Section 9.
 End of changes. 24 change blocks. 
50 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/