SIP Working Group J. Polk Internet-Draft Cisco Expires: August 21st, 2005 H. Schulzrinne Columbia U. February 21st, 2005 Communications Resource Priority for the Session Initiation Protocol (SIP) draft-ietf-sip-resource-priority-06 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 21st, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document defines two new SIP header fields for communicating resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and SIP proxies. It does not directly influence the forwarding behavior of IP routers. Polk & Schulzrinne [page 1] Internet-Draft SIP Resource Priority February 21st, 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 The 'Resource-Priority' Header Field . . . . . . . . . . . 6 3.2 The 'Accept-Resource-Priority' Header Field . . . . . . . 7 3.3 Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields . . . . . . . . . 7 3.4 The 'resource-priority' Option Tag . . . . . . . . . . . . 8 4. Behavior of SIP Elements that Receive Prioritized Requests . . 8 4.1 General Rules . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Usage of Require Header with Resource-Priority . . . . . . . 9 4.3 OPTIONS Request with Resource-Priority . . . . . . . . . . . 9 4.4 Alternatives for Preferential Treatment of Requests . . . . 10 4.4.1 Preemption Policy . . . . . . . . . . . . . . . . . . . 10 4.4.2 Priority Queuing Policy . . . . . . . . . . . . . . . . 10 4.5 Rejection Messages . . . . . . . . . . . . . . . . . . . . 11 4.6 Error Conditions . . . . . . . . . . . . . . . . . . . . . 12 4.6.1 Known Namespace and Priority Value . . . . . . . . . . 12 4.6.2 Handling Unknown Namespaces and Priority Values . . . 12 4.7 User Agent Client Behavior . . . . . . . . . . . . . . . . 13 4.7.1 User Agent Client Behavior with a Preemption Policy . . 13 4.7.2 User Agent Client Behavior with a Priority Queue Policy 13 4.8 User Agent Server Behavior . . . . . . . . . . . . . . . . 13 4.8.1 User Agent Servers and Preemption Policy . . . . . . . . 14 4.8.1 User Agent Servers and Priority-Queue Policy . . . . . . 14 4.9 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 14 5. Third-Party Authentication . . . . . . . . . . . . . . . . . . 15 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 15 7. Multiple Namespaces in a Message . . . . . . . . . . . . . . 16 8. Namespace Definitions . . . . . . . . . . . . . . . . . . . . 18 8.1 Namespace Descriptions . . . . . . . . . . . . . . . . . . . 18 8.1.1 The "DSN" Namespace . . . . . . . . . . . . . . . . . . 18 8.1.2 The "DRSN" Namespace . . . . . . . . . . . . . . . . . . 19 8.1.3 The "Q735" Namespace . . . . . . . . . . . . . . . . . . 20 8.1.4 The "ETS" Namespace . . . . . . . . . . . . . . . . . . 20 8.1.5 The "WPS" Namespace . . . . . . . . . . . . . . . . . . 22 8.2 Future Namespace Considerations . . . . . . . . . . . . . . 24 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1 Simple Call . . . . . . . . . . . . . . . . . . . . . . . 25 9.2 Receiver Does Not Understand Namespace . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10.1 Authentication and Authorization . . . . . . . . . . . . . 29 10.2 Confidentiality and Integrity . . . . . . . . . . . . . . 30 10.3 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 31 10.4 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11.1 IANA Registration of 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields . . . . . . . . . 32 11.2 IANA Registration for Option Tag resource-priority . . . . 32 Polk & Schulzrinne [page 2] Internet-Draft SIP Resource Priority February 21st, 2005 11.3 IANA Registration for Response Code 417 . . . . . . . . . 32 11.4 IANA Namespace Registrations . . . . . . . . . . . . . . . 32 11.5 IANA Priority-Value Registrations . . . . . . . . . . . . 33 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1 Normative References . . . . . . . . . . . . . . . . . . . 34 13.2 Informative References . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . 36 1. Introduction During emergencies, communications resources including telephone circuits, IP bandwidth and gateways between the circuit-switched and IP networks may become congested. Congestion can occur due to heavy usage, loss of resources caused by the natural or man-made disaster and attacks on the network during man-made emergencies. This congestion may make it difficult for persons charged with emergency assistance, recovery or law enforcement to coordinate their efforts. As IP networks become part of converged or hybrid networks along with public and private circuit-switched (telephone) networks, it becomes necessary to ensure that these networks can assist during such emergencies. Also, users may want to interrupt their lower-priority communications activities and dedicate their end system resources to the high-priority communications attempt if a high-priority communications request arrives at their end system. There are many IP-based services that can assist during emergencies. This memo only covers real-time communications applications involving the Session Initiation Protocol (SIP) [RFC3261], including voice-over-IP, multimedia conferencing, instant messaging and presence. SIP applications may involve at least five different resources that may become scarce and congested during emergencies. These resources include gateway resources, circuit-switched network resources, IP network resources, receiving end system resources and SIP proxy resources. IP network resources are beyond the scope of SIP signaling and are therefore not considered here. In order to improve emergency response, it may become necessary to prioritize access to SIP-signaled resources during periods of emergency-induced resource scarcity. We call this "resource prioritization". The mechanism itself may well be in place at all times, but only materially affect call handling during times of resource scarcity. Currently, SIP does not include a mechanism that allows a request originator to indicate to a SIP element that it wishes the request to Polk & Schulzrinne [page 3] Internet-Draft SIP Resource Priority February 21st, 2005 invoke such resource prioritization. To address this need, this document adds a SIP protocol element that labels certain SIP requests. This document defines (Section 3) a new SIP [RFC3261] header field for communications resource priority, called 'Resource-Priority' This header field MAY be used by SIP user agents, including General Switched Telephone Network (GSTN) gateways and terminals, and SIP proxy servers to influence their treatment of SIP requests, including the priority afforded to GSTN calls. For GSTN gateways, the behavior translates into analogous schemes in the GSTN, for example the ITU Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both the GSTN-to-IP and IP-to-GSTN directions. ITU Recommendation I.255.3 [I.255.3] is another example. The 'Resource-Priority' header field may be used in several situations. A SIP request with such an indication can be treated differently in these situations: 1. The request can be given elevated priority for access to GSTN gateway resources such as trunk circuits. 2. The request can interrupt lower-priority requests at a user terminal, such as an IP phone. 3. The request can carry information from one multi-level priority domain in the telephone network, e.g., using the facilities of Q.735.3 [Q.735.3], to another, without the SIP proxies themselves inspecting or modifying the header field. 4. In SIP proxies and back-to-back user agents, requests of higher priorities may delay, reject or error existing signaling requests of lower priorities. This header field is related to, but differs in semantics from, the 'Priority' header field (RFC 3261 [RFC3261], Section 20.26). The 'Priority' header field describes the importance that the SIP request should have to the receiving human or its agent. For example, that header may be factored into decisions about call routing to mobile devices and assistants and call acceptance when the call destination is busy. The 'Priority' header field does not affect the usage of GSTN gateway or proxy resources, for example. In addition, any User Agent Client (UAC) can assert any 'Priority' value, while access to resource priority values are subject to authorization. While the 'Resource-Priority' header does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority, procedures for using this header to cause such influence may be defined in other documents. Existing implementations of RFC 3261 that do not participate in the Polk & Schulzrinne [page 4] Internet-Draft SIP Resource Priority February 21st, 2005 resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message." Thus, the use of this mechanism is wholly invisible to existing implementations unless the request includes the Require header field with the resource-priority option tag. The mechanism described here can be used for emergency preparedness in emergency telecommunications systems, but is only a small part of an emergency preparedness network and is not restricted to such use. The mechanism aims to satisfy the requirements in [RFC3487]. It is structured so that it works in all SIP and Real-Time Transport Protocol (RTP) [RFC3550] transparent networks defined in [RFC3487]. In such networks, all network elements and SIP proxies let valid SIP requests pass through unchanged. This is important since it is likely that this mechanism will often be deployed in networks where the edge networks are unaware of the resource priority mechanism and provide no special privileges to such requests. The request then reaches a GSTN gateway or set of SIP elements that are aware of the mechanism. For conciseness, we refer to SIP proxies and user agents (UAs) that act on the 'Resource-Priority' header field as RP actors. The remainder of this document is structured as follows. After defining terminology in Section 2, we define the syntax for the two new SIP header fields in Section 3 and then describe protocol behavior in Section 4. The two principal mechanisms for differentiated treatment of SIP requests, namely preemption and queuing, are described in Section 4.4. Rejection messages are covered in Section 4.5, error conditions in Section 4.6. Section 4.7 through Section 4.9 detail the behavior of specific SIP elements. Third-party authentication is briefly summarized in Section 5. Section 6 describes how this feature affects existing systems that do not support it. Sections 7 and 8 delve into namespace issue, namely their general properties, how to deal with multiple namespaces on the same SIP element and in the same SIP message, as well as enumerating five namespaces that are registered through this document. Protocol examples are given in Section 9. Security issues are considered in Section 10, but this document does not define new security mechanisms. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant Polk & Schulzrinne [page 5] Internet-Draft SIP Resource Priority February 21st, 2005 implementations. 3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields This document defines the 'Resource-Priority' and 'Accept-Resource-Priority' SIP header field syntax. Behavior is described in Section 4.. The SIP element behavior is described for user agent clients (UACs) in Section 4.7, for UAS in Section 4.8 and for SIP proxy servers in Section 4.9. 3.1 The 'Resource-Priority' Header Field The 'Resource-Priority' header field marks a SIP request as desiring prioritized access to resource, as described in the introduction. In responses, the 'Resource-Priority' header fields indicates the actual resource priority that was granted to the request. While it is likely those responses contain the same 'Resource-Priority' header field value as the requests, local policy MAY call for the UAS to insert no header field or a different value. There is no protocol requirement that all requests within a SIP dialog or session use the 'Resource-Priority' header field. Local administrative policy MAY mandate the inclusion of the 'Resource- Priority' header field in all requests. Implementations of this specification MUST allow inclusion to be either by explicit user request or automatic. The syntax of the 'Resource-Priority' header field is described below. The "token-nodot" production is copied from [RFC3265]. Resource-Priority = "Resource-Priority" HCOLON r-value *(COMMA r-value) r-value = namespace "." r-priority namespace = token-nodot r-priority = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) An example 'Resource-Priority' header field is shown below: Resource-Priority: dsn.flash The 'Resource-value' parameter in the 'Resource-Priority' header indicates the resource priority desired by the request originator. Each resource value is formatted as 'namespace' '.' 'priority value'. The value is drawn from the namespace identified by the 'namespace' token. Namespaces and priorities are case-insensitive ASCII tokens that do not contain periods. Thus, ædsn.flashÆ and Polk & Schulzrinne [page 6] Internet-Draft SIP Resource Priority February 21st, 2005 æDSN.FlashÆ, for example, are equivalent. Each namespace has at least one priority value. Namespaces and priority values within each namespace MUST be registered with IANA (Section 11). Initial namespace registrations are described in Section 11.4. Since a request may traverse multiple administrative domains with multiple different namespaces, it is necessary to be able to enumerate several different namespaces within the same message. However, a particular namespace MUST NOT appear more than once in the same SIP message. These may be expressed equivalently as either comma-separated lists within a single header field, as multiple header fields or some combination. The ordering of r-values within the header field has no significance. Thus, for example, the following three header snippets are equivalent: Resource-Priority: dsn.flash, wps.3 Resource-Priority: wps.3, dsn.flash Resource-Priority: wps.3 Resource-Priority: dsn.flash 3.2 The 'Accept-Resource-Priority' Header Field The 'Accept-Resource-Priority' response header field enumerates the resource values (r-values) a SIP user agent server is willing to accept. The syntax of the 'Accept-Resource-Priority' header field is as follows: Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON [r-value *(COMMA r-value)] An example is given below: Accept-Resource-Priority: dsn.flash-override, dsn.flash, dsn.immediate, dsn.priority, dsn.routine Some administrative domains MAY choose to disable the use of the Accept-Resource-Priority header as revealing too much information about that domain in responses. However, this behavior is NOT RECOMMENDED, as this header field aids in troubleshooting. 3.3 Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields The following table extends the values in Table 2 of RFC3261 [RFC3261]. (The PRACK method, labeled as PRA, is defined in [RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT) methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in Polk & Schulzrinne [page 7] Internet-Draft SIP Resource Priority February 21st, 2005 [RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB) method is in [RFC3903].) Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Resource-Priority R amdr o o o o o o o Resource-Priority r amdr o o o o o o o Resource-Priority 200 amdr o - o o o o o Accept-Resource-Priority 200 amdr o - o o o o o Accept-Resource-Priority 417 amdr o - o o o o o Accept-Resource-Priority 420 amdr o - o o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Resource-Priority R amdr o o o o o o o Resource-Priority r amdr o o o o o o o Resource-Priority 200 amdr o o o o o o o Accept-Resource-Priority 200 amdr o o o o o o o Accept-Resource-Priority 417 amdr o o o o o o o Accept-Resource-Priority 420 amdr o o o o o o o Other request methods MAY define their own handling rules; unless otherwise specified, recipients MAY ignore these header fields. The 'Accept-Resource-Priority' SHOULD be returned in 420 (Bad Extension) responses marked as 'o' in table above if the element implements the resource priority mechanism with some other namespaces or priority values, but does not implement the particular namespace or priority value contained in this current request. 3.4 The 'resource-priority' Option Tag This document also defines the "resource-priority" option tag. The behavior is described in Section 4.2. and the IANA registration is in Section 11.2. 4. Behavior of SIP Elements that Receive Prioritized Requests All SIP user agents and proxy servers that support this specification share certain common behavior, which we describe below in Section 4.1. The behavior when encountering a 'resource- priority' option tag in a 'Require' header field is describe in Section 4.2. Section 4.3 describes the treatment of OPTIONS requests. The two fundamental resource contention resolution mechanisms, preemption and queuing, are described in Section 4.4. Rejection Behavior specific to user agent clients is covered in section 4.7, for user agent servers in Section 4.8, while Section 4.9 deals with proxy behavior. Polk & Schulzrinne [page 8] Internet-Draft SIP Resource Priority February 21st, 2005 4.1 General Rules The Resource-Priority header field is potentially applicable to all SIP request messages. At a minimum, implementations of the following request types MUST support the Resource-Priority header to be in compliance with this specification: 1) INVITE [RFC3261] 2) ACK [RFC3261] 3) PRACK [RFC3262] 4) UPDATE [RFC3311] 5) REFER [RFC3515] and SHOULD support the Resource-Priority header in the following request types (if the SIP element does) to be in compliance with this specification: 6) MESSAGE [RFC3428] 7) SUBSCRIBE [RFC3265] 8) NOTIFY [RFC3265] Note that this does not imply all implementations to support every request method listed. If a SIP element receives the Resource-Priority header in a Request message other than what is listed above, the header MAY be ignored, according to the foundational rules of [RFC3261]. 4.2 Usage of Require Header with Resource-Priority Following standard SIP behavior, if a SIP request contains the Require header field with the æresource-priorityÆ option tag, a SIP element MUST respond with a 420 (Bad Extension) if it does not support the SIP extensions described in this document. It then lists æresource-priorityÆ in the æUnsupportedÆ header field included in the response. The use of the 'resource-priority' option tag in 'Proxy-Require' header field is NOT RECOMMENDED. 4.3 OPTIONS Request with Resource-Priority An OPTIONS request can be used to determine if an element supports the mechanism. A compliant implementation MUST return a 'Accept-Resource-Priority' header field in OPTIONS responses enumerating all valid resource values. An RP actor MAY be configured not to return such values or only return them to authorized requestors. Note that according to RFC 3261, proxies reached with a Max-Forwards Polk & Schulzrinne [page 9] Internet-Draft SIP Resource Priority February 21st, 2005 value of zero answer the OPTIONS request, allowing a UAC to discover the capabilities of both proxy and user agent servers. 4.4 Alternatives for Preferential Treatment of Requests SIP elements may use the resource priority mechanism to modify a variety of behavior such as routing requests, authentication requirements or logging. the request itself or of the session created by the request. We use the terms session and call interchangeably in this document, both implying a continuous data stream between two or more parties. Sessions are established by SIP dialogs. Below, we define two common policies, namely preemption and priority queuing. Preemption applies only to sessions created by SIP requests, while both sessions and request handling can be subject to priority queuing. Both policies can sometimes be combined in the same element, although none of the namespaces described in this document do this. Policies can be defined for each namespace or, in some cases, can be specific to an administrative domain. Naturally, only SIP elements that understand this mechanism and the namespace and resource value perform these policies. Section 4.8 discusses what happens if an RP actor does not understand namespaces or priority values contained in a request. 4.4.1 Preemption Policy An RP actor following a preemption policy may disrupt an existing session to make room for a higher-priority incoming session. Since sessions may require different amounts of bandwidth or number of circuits, a single higher priority session may displace more than one lower-priority session. As noted above, the processing of SIP requests itself is not preempted. Thus, since proxies do not manage sessions, they do not perform preemption. [I-D.ietf-sipping-reason-header-for-preemption] for more details and examples of this behavior. UAS behavior for preemption is discussed in Section 4.8. 4.4.2 Priority Queuing Policy In a priority queuing policy, requests that find no available resources are queued on a first-come, first-served basis to the queue assigned to the priority value. Each priority value may have its own queue or several priority values may share a single queue. If a resource becomes available, a request from the queue with the highest priority is served. Each queue can hold a finite number of Polk & Schulzrinne [page 10] Internet-Draft SIP Resource Priority February 21st, 2005 pending requests. If the queue for a newly arriving request is full, the request is rejected immediately. In addition, a priority queuing policy MAY impose a residence time limit. If a request exceeds a specified waiting time, the RP actor then rejects the request and removes it from the queue. In addition, an RP actor MAY impose a global queue size limit summed across all queues and drop waiting lower-priority requests. This does not imply preemption since the session has not been established yet. Often, normal, non-prioritized requests will not be queued, i.e., the queue size for such requests is zero. 4.5 Rejection Messages The following is a list of rejections to SIP messages that contain a Resource-Priority header specifically because of the contents of the header. If a UA is currently occupied with another session and receives a dialog generating message containing a valid Resource-Priority header of equal or lower relative priority value, the response is the same as stated in section 13.3.1.3 of [RFC3261]: - a 486 (Busy Here) is returned if the UAS knows it cannot or will not accept the request, - a 600 (Busy Everywhere) is returned if the UAS knows there are no other SIP elements that can accept the INVITE, and - a 488 (Not Acceptable Here) if the UAS is rejecting the INVITE. [RFC3261] advises that a 488 response SHOULD include a warning header with a reason for the rejection. If the message from the UAC contains a known namespace, and the priority-value is higher than is authorized, this error condition is addressed in the next subsection (4.6). In the case in which a UAS is currently occupied with another session and receives an INVITE containing a valid Resource-Priority header of higher relative priority than that of the current dialog, this does not create an error condition. The UAS will act according to the behaviors defined for that namespace within that administrative domain. Section 8.1.1 through 8.1.5 define the rules for the 5 namespaces that are created with this document. It can also be stated that if a Proxy Server is currently experiencing processing difficulties (perhaps due to overload conditions), this is an error condition that will be addressed in Polk & Schulzrinne [page 11] Internet-Draft SIP Resource Priority February 21st, 2005 section 4.6.1. 4.6 Error Conditions 4.6.1 Known Namespace and Priority Value Two error conditions can occur if a request reaches an element that supports the namespace and resource priority. Elements receiving requests with namespaces or priority values that they do not understand act according to the rules in the next section. Insufficient authorization: If the element receives a request with a namespace and priority value it recognizes, but the originator is not authorized for that level of service, the element MUST return a 403 (Forbidden) response. Insufficient resources: If there are insufficient resources at an element for a given priority, a request might be delayed or refused, depending on local policy or the definition of the namespace. If it is refused, the element returns a 503 (Service Unavailable) response. The response MAY also include a 'Warning' header with warning code 370 (Insufficient Bandwidth) if the request failed due to insufficient capacity for the media streams, rather than insufficient signaling capacity. The 503 (Service Unavailable) response provides sufficient indication to the originator to re-attempt with a higher appropriate resource priority or if no Resource-Priority header was present in the original request (which may be local policy not to include one for normal level calls), to add a resource priority indication, if authorized. 4.6.2 Handling Unknown Namespaces and Priority Values When handling requests with unknown namespaces or priority values, elements will operate according to local policy. Some administrative domains will openly reject with a 417 (Unknown Resource-Priority) Response message regardless of whether the namespace or header field (or both) are not known, giving no further details to the requestor. Other administrative domains will return 417 (Unknown Resource-Priority) Response with an Accept-Resource- Priority header indicating which valid namespace(s) and priority- value(s) are "good" within that domain. As previously stated, a single SIP message can have more than one Resource-Priority header. If one header is understood, the remaining Resource-Priority headers SHOULD NOT be modified, deleted or cause a rejection of the message. The reason for this is that there will be cases where multiple namespaces will be necessary for end-to-end communications. Allowing multiple instances of the header in the same message allows the message to traverse multiple administrative domains - without Polk & Schulzrinne [page 12] Internet-Draft SIP Resource Priority February 21st, 2005 each having to know about the policy of the other(s) - all while providing a valid resource-Priority per administrative domain. An example of this is the case where the ETS namespace will be enabled by the US Government networks (used by very few individuals within that administrative domain) that also support the DSN and/or DRSN namespaces for most (if not all) individuals in those domains. These namespaces will be defined later in this document. Some SIP elements MAY allow process messages with unknown Resource- Priority headers without returning a 417. This is a matter of local policy. 4.7 User Agent Client Behavior SIP UACs supporting this specification MUST be able to generate the 'Resource-Priority' header field for requests that require elevated resource access priority. As stated previously, the UAC SHOULD be able to generate more than one resource value in a single SIP request. If a 417 (Unknown Resource-Priority) is received, the UAC MAY attempt a subsequent request with the same combination of namespace/priority-value, or the retry the request with a different set of namespace/priority combinations, drawing from the values returned by the 'Accept-Resource-Priority' header field in the response, if included, and if authorized for that user. 4.7.1 User Agent Client Behavior with a Preemption Policy A UAC in an administrative domain that employs preemption MUST be prepared to receive a BYE Request with a Reason header explaining why the session was terminated. [I-D.ietf-sipping-reason-header-for-preemption] discusses this. 4.7.2 User Agent Client Behavior with a Priority Queue Policy 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, but has put the original request into a queue. This UAC SHOULD indicate this queued status to the user by some audio or visual indication to prevent the user from interpreting the call as having failed. 4.8 User Agent Server Behavior The precise effect of the 'Resource-Priority' indication depends on the type of UAS, the namespace and local policy. Polk & Schulzrinne [page 13] Internet-Draft SIP Resource Priority February 21st, 2005 4.8.1 User Agent Servers and Preemption Policy A UAS compliant with this specification MUST terminate a session established with a valid namespace and lower priority value in favor of a new session set-up with a valid namespace and higher relative priority-value, unless local policy has some form of call-waiting capability enabled. If a session is terminated, the BYE method is used with a Reason header indicating why/where the preemption took place. [I-D.ietf-sipping-reason-header-for-preemption] provides additional information in the case of purposeful or administrative termination of a session by including the Reason header in the BYE message that states why the BYE was sent (in this case, a preemption event). That document offers several reasons for where the termination occurred ('at the UA', 'in the network', 'at a IP/PSTN gateway'), and includes call flow examples of each reason. 4.8.2 User Agent Servers and Priority-Queue Policy A UAS compliant with this specification SHOULD generate a 182 (Queued) Response if that element's resources are busy, until it is able to handle the request and provide a final response. Local policy will determine additional behaviors of a queue-based SIP element. However, the frequency of provisional messages indicated in [RFC3261] still need to apply to keep each session set- up active until successful or rejected. 4.9 Proxy Behavior SIP proxies MAY ignore or inspect the 'Resource-Priority' header field. SIP proxies MAY reject any unauthenticated request bearing the header field. A compliant SIP Server experiencing a processing queue due to excessive load MUST process messages containing higher relative priority-values up to the queue the header indicates on a FIFO basis based on the arrival time of the message. It is conceivable that priority-levels within a proxy are grouped to include more than one level per queue. This is a matter of local policy. If a Proxy is expecting a message to have a 'Resource-Priority' header and the header is protected via S/MIME encapsulation in a SIP message fragment [RFC3420], the Proxy MUST return an error response. Therefore, the use of SIPFRAG in administrative domains with this type of policy is not recommended. If no S/MIME is used, SIP proxies MAY downgrade or upgrade the 'Resource-Priority' of a request or insert a new 'Resource-Priority' Polk & Schulzrinne [page 14] Internet-Draft SIP Resource Priority February 21st, 2005 header if allowed by local policy. This behavior is similar to that for any header field, as a UA can decide to reject a request for the presence, absence or value of any information in the request. If a stateful proxy has authorized a particular resource priority level and if it offers differentiated treatment to responses containing resource priority levels, the proxy SHOULD ignore any higher value contained in responses, to avoid that colluding user agents artificially raise the priority level. A SIP proxy MAY use the 'Resource-Priority' indication in its routing decisions, e.g., to retarget to a SIP node or SIP URI that is reserved for a particular resource priority. When the 'Require' header is included in a message, it ensures that in parallel forking, only branches that support the resource- priority mechanism succeed. There are not additional special considerations for proxies when forking requests that contain a resource priority indication. Otherwise, the proxy behavior is the same as for user agent servers Section 4.7). 5. Third-Party Authentication In some cases, the RP actor may not be able to authenticate the requestor or determine whether an authenticated user is authorized to make such a request. In these circumstances, the SIP entity may avail itself of general SIP mechanisms that are not specific to this application. The authenticated identity management mechanism [RFC3893] allows a third party to verify the identity of the requestor and certify this towards an RP actor. In networks with mutual trust, the SIP asserted identity mechanism [RFC3325] can help the RP actor determine the identity of the requestor. 6. Backwards Compatibility The resource priority mechanism described in this document is fully backwards compatible with SIP systems following [RFC3261]. Systems that do not understand the mechanism can only deliver standard, not elevated, service priority. User agent servers and proxies can ignore any 'Resource-Priority' header field just like any other unknown header field and then treat the request like any other request. Naturally, the request may still succeed. Introducing 'Require' or 'Proxy-Require' would not help backwards compatibility, as systems that do not support these mechanism are no better off rejecting the request due to feature failure. Since the Polk & Schulzrinne [page 15] Internet-Draft SIP Resource Priority February 21st, 2005 intent of resource priority indications is to increase the probability of call completion, adding failure modes appears counterproductive. 7. Multiple Namespaces in a Message There are two cases where multiple namespaces might occur. Namely, a single RP actor may understand more than one namespace and a SIP request may contain more than one resource value from different namespaces. As noted earlier, the order of resource values in a SIP request is immaterial. o If a SIP element understands multiple namespaces, it must create a total ordering across all resource values from these namespaces, maintaining the relative ordering within each namespace. It is RECOMMENDED that the same ordering is used across an administrative domain. o If a 'Resource-Priority' header contains multiple namespaces, the RP actor MUST select one resource value, typically the one with the highest ranking. o If a SIP element supports this specification and the request includes a 'Require' header field with the 'Resource-Priority' option tag, it MUST be possible to configure a UAS to copy the Resource-Priority header value or values from the Request to the Response without changing any field values (this means the Offerer is in control of this header's value within an administrative domain). This rule MUST be followed even if multiple instances of the Resource-Priority header exist in a Request, unless the UAS lacks the authorization to copy unknown header fields. User authorization of priority-values within a namespace is outside the scope of this document. Here is a series of examples (both good and bad) of a SIP element that supports two namespaces (foo and bar). Foo's priority-values are 3 (highest), then 2 and then 1 (lowest ), and bar's priority- values are C (highest), then B and then A (lowest). The following are 3 lists of acceptable priority orders the SIP element MAY process are: Foo.3 Foo.3 Bar.C (Highest Priority) Foo.2 Bar.C Foo.3 Foo.1 or Foo.2 or Foo.2 Bar.C Bar.B Foo.1 Bar.B Foo.1 Bar.B Bar.A Bar.A Bar.A (Lowest Priority) Polk & Schulzrinne [page 16] Internet-Draft SIP Resource Priority February 21st, 2005 Bar.C (Highest Priority) Foo.3 Bar.B <= both are equivalently processed FIFO) or Foo.2 Bar.A <= both are equivalently processed FIFO) Foo.1 (Lowest Priority) Bar.C (Highest Priority) Foo.3 or Foo.2 Foo.1 (Lowest Priority) Where Bar.A and Bar.B are ignored within this example administrative Domain; Based on the stated priority order of each namespace above, the following (non-inclusive list of) combinations are NOT acceptable and MUST NOT be configurable: Example 1 Example 2 Example 3 --------- --------- --------- Foo.3 Foo.3 Bar.C Foo.2 Bar.A Foo.1 Foo.1 or Foo.2 or Foo.3 Bar.C Bar.B Foo.2 Bar.A Foo.1 Bar.A Bar.B Bar.C Bar.B Example 4 --------- Bar.C Foo.1 Bar.B or Foo.3 Bar.A Foo.2 In Example 1 above, Bar.A is ordered higher than Bar.B - which is not consistent within the order of the namespace of this section. In Example 2 above, Bar.A is ordered higher than Bar.B and Bar.C - which is not consistent within the order of the namespace of this section. In Example 3 above, Foo.1 is ordered higher than Foo.2 and Foo.3 - which is not consistent within the order of the namespace of this section. In Example 4 above, Foo.1 is ordered higher than Foo.3 and Foo.2 is ignored - which is not consistent within the order of the namespace of this section. Polk & Schulzrinne [page 17] Internet-Draft SIP Resource Priority February 21st, 2005 8. Namespace Definitions This specification defines five unique namespaces below: dsn, drsn, q735, ets and wps, constituting their registration with IANA. Each IANA registration contains: 1) The namespace label, a unique namespace label within the IANA registry for the Resource-Priority header; 2) Number of Priority levels - the number of relative priority levels the namespace has defined; 3) The "Intended Operation" - identifying whether the namespace is to be used with priority queuing or preemption; 4) Any new Rejection codes or behaviors unique to the namespace being defined 5) Any new Error codes specific to the namespace being defined 6) The IETF Reference document specifying the parameters and specifications of the namespace, the listing of the priority- values in relative order, any new rejection messages, and any new error codes or error behaviors. 8.1 Namespace Descriptions 8.1.1 The "DSN" Namespace The DSN namespace comes from the name of a US Government network called "The Defense Switched Network". The DSN namespace has a finite list of relative priority-values listed here in the order of lowest priority to highest priority: (lowest) dsn.routine dsn.priority dsn.immediate dsn.flash (highest) dsn.flash-override In compliant administrative domains utilizing the dsn namespaces, the UAS MUST copy the Resource-Priority header priority-values from the Request to the Response for every header in the message unless the UAS lacks local authorization to copy certain namespace.priority-value combinations. The dsn namespace introduces no new error behaviors. The IANA Considerations section will have the following entry for the DSN namespace: Polk & Schulzrinne [page 18] Internet-Draft SIP Resource Priority February 21st, 2005 Intended New New Error Namespace Levels Operation Rej. code code Reference --------- ------ ---------------- --------- ---- --------- dsn 5 preemption-based no no [This RFC] 8.1.2 The "DRSN" Namespace The DRSN namespace comes from the name of a US Government network called "The Defense RED Switched Network". The DRSN namespace has a finite list of relative priority-values listed here in the order of lowest priority to highest priority: (lowest) drsn.routine drsn.priority drsn.immediate drsn.flash drsn.flash-override (highest) drsn.flash-override-override One unique facet regarding the DRSN namespace relative to the DSN and Q735 namespaces is the behavior of SIP elements with regard to the 6th priority-value: drsn.flash-override-override This is the highest relative priority-value within the DRSN namespace, but it is only to be used at this higher level in message processing in SIP Proxies, and dialog establishment in SIP UAs (including gateways). In any UAS, once the session is established at the drsn.flash-override-override priority level, it defends that dialog with a priority level of drsn.flash-override only; thus allowing a new drsn.flash-override-override to preempt any existing session. This behavior MUST be followed to be compliant with this specification. In compliant administrative domains utilizing the drsn namespaces, the UAS MUST copy the Resource-Priority header priority-values from the Request to the Response for every header in the message unless the UAS lacks local authorization to copy certain (perhaps restricted) namespace.priority-value combinations. The drsn namespace operates on the preemption policy. The drsn namespace introduces no new error behavior. The IANA Considerations section will have the following entry for the DRSN namespace: Polk & Schulzrinne [page 19] Internet-Draft SIP Resource Priority February 21st, 2005 Intended New New Error Namespace Levels Operation Rej. code code Reference --------- ------ ---------------- --------- ---- --------- drsn 6 preemption-based no no [This RFC] 8.1.3 The "Q735" Namespace The Q735 namespace is defined here as Q.735.3 was defined, namely as operationally equivalent to the DSN specification for MLPP. Q.735.3 was created to be a commercial version of the same specification. The Q735 namespace has a finite list of relative priority-values listed here in the order of lowest priority to highest priority: (lowest) q735.4 q735.3 q735.2 q735.1 (highest) q735.0 In compliant administrative domains utilizing the q735 namespaces, the UAS MUST copy the Resource-Priority header priority-values from the Request to the Response for every header in the message unless the UAS lacks local authorization to copy certain (perhaps restricted) namespace.priority-value combinations. The q735 namespace operates according to the preemption policy. The q735 namespace introduces no new error behaviors. The IANA Considerations section will have the following entry for the Q735 namespace: Intended New New Error Namespace Levels Operation Rej. code code Reference --------- ------ ---------------- --------- ---- --------- q735 5 preemption-based no no [This RFC] 8.1.4 The "ETS" Namespace The ETS namespace derives its name indirectly from the name of the US Government Telecommunications Service called "Government Emergency Telecommunications Service" (or GETS), though the organization responsible for the GETS service chose the acronym "ETS" for its GETS over IP service, which stands for "Emergency Telecommunications Service". The ETS namespace has a finite list of relative priority-values listed here in the order of lowest priority to highest priority: Polk & Schulzrinne [page 20] Internet-Draft SIP Resource Priority February 21st, 2005 (lowest) ets.4 ets.3 ets.2 ets.1 (highest) ets.0 The ets namespace operates according to the priority queuing policy. ETS-based administrative domains will not queue normal, non- prioritized requests. ETS-based administrative domains will not queue normal, non- prioritized messages. If a queue depth exists, the messages will be rejected according to section 4.5. A UAS within this type of administrative domain SHOULD be configurable to limit the number of requests in a queue. One of two different ways of limiting the queue depth is RECOMMENDED: 1) having a maximum number within a queue (perhaps with a different number queued per priority-level), and 2) consider all requests above the default level to be in a single queue on a FIFO basis (for example, based on the reception timestamp of the request) A UAS within this type of administrative domain SHOULD be configurable to limit the time a request sits in a queue. One of two different ways of limiting the time in queue is RECOMMENDED: 1) having a maximum time within a queue (perhaps with a different time per priority-level) before a/each message moves into a rejection condition discussed in section 4.5., and 2) considering all requests above the default level in a single queue on a FIFO basis (for example, based on the reception timestamp of the request), all with the same maximum time in queue before a/each message moves into a rejection condition discussed in section 4.5. Local policy will determine additional behaviors of a queue-based SIP element. However, the frequency of provisional messages indicated in [RFC3261] still need to apply to keep each session set- up active until successful or rejected. A compliant SIP Server experiencing a processing queue due to excessive load MUST move the messages containing higher relative priority-values up to the queue the header indicates on a FIFO basis based on the arrival time of the message (as there may be more than one message at the same level already in queue). It is conceivable that priority-levels within a proxy are grouped to include more than one level per queue. This is a matter of local policy. Polk & Schulzrinne [page 21] Internet-Draft SIP Resource Priority February 21st, 2005 In compliant administrative domains utilizing the ets namespaces, the UAS MUST copy the Resource-Priority header priority-values from the Request to the Response for every header in the message unless the UAS lacks local authorization to copy certain (perhaps restricted) namespace.priority-value combinations. Additional ETS policy is left to domain administrators, and to future efforts. The ets namespace does not define new error behaviors. The IANA Considerations section will have the following entry for the ETS namespace: Intended New New Error Namespace Levels Operation Rej. code code Reference --------- ------ ---------------- --------- ---- --------- ets 5 queue-based no no [This RFC] 8.1.5 The "WPS" Namespace The WPS namespace derives its name from the "Wireless Priority Service" defined in GSM and other wireless technologies. Each namespace has a finite list of relative priority-values. Each is listed here in the order of lowest priority to highest priority: (lowest) wps.4 wps.3 wps.2 wps.1 (highest) wps.0 The wps namespace operates with the intended preferential treatment of a queue-based policy (as defined in section 4), where higher relative priority requests are queued ahead of lower relative priority requests for processing at any point of scarce resource constraints in an administrative domain. WPS-based administrative domains will not queue normal, non- prioritized messages. If a queue depth exists, the messages will be rejected according to section 4.5. A UAS within this type of administrative domain SHOULD be configurable to limit the number of requests in a queue. One of two different ways of limiting the queue depth is RECOMMENDED: 1) having a maximum number within a queue (perhaps with a different number queued per priority-level), and Polk & Schulzrinne [page 22] Internet-Draft SIP Resource Priority February 21st, 2005 2) consider all requests above the default level to be in a single queue on a FIFO basis (for example, based on the reception timestamp of the request) A UAS within this type of administrative domain SHOULD be configurable to reject a queued lower priority request in lieu of the newly arrived higher priority level request if the maximum aggregate queue depth has been reached for that element. This behavior is not considered a "preemption event" because the session had not been previously established. This bumping will result in the lower level request being rejected (discussed in section 4.5) A UAS within this type of administrative domain SHOULD be configurable to limit the time a request sits in a queue. One of two different ways of limiting the time in queue is RECOMMENDED: 1) having a maximum time within a queue (perhaps with a different time per priority-level) before a/each message moves into a rejection condition discussed in section 4.5., and 2) considering all requests above the default level in a single queue on a FIFO basis (for example, based on the reception timestamp of the request), all with the same maximum time in queue before a/each message moves into a rejection condition discussed in section 4.5. Local policy will determine additional behaviors of a queue-based SIP element. However, the frequency of provisional messages indicated in [RFC3261] still need to apply to keep each session set- up active until successful or rejected. A compliant SIP Server experiencing a processing queue due to excessive load MUST move the messages containing higher relative priority-values up to the queue the header indicates on a FIFO basis based on the arrival time of the message (as there may be more than one message at the same level already in queue). It is conceivable that priority-levels within a proxy are grouped to include more than one level per queue. This is a matter of local policy. In compliant administrative domains utilizing the wps namespaces, the UAS MUST copy the Resource-Priority header priority-values from the Request to the Response for every header in the message unless the UAS lacks local authorization to copy certain (perhaps restricted) namespace.priority-value combinations. Additional WPS policy is left to domain administrators, and to future efforts. The wps namespace operates according to the priority queuing policy and will not queue normal, non-prioritized messages. The wps namespace defines no new error behaviors. Polk & Schulzrinne [page 23] Internet-Draft SIP Resource Priority February 21st, 2005 The IANA Considerations section will have the following entry for the WPS namespace: Intended New New Error Namespace Levels Operation Rej. code code Reference --------- ------ ---------------- --------- ---- --------- wps 5 queue-based no no [This RFC] 8.2 Future Namespace Considerations Organizations considering the use of the Resource-Priority header should investigate if an existing combination of namespace and priority-values meets the needs. For example, emergency first responders around the world are discussing utilizing this mechanism for preferential treatment in future networks. There should not be a unique namespace for different jurisdictions. This will greatly increase interoperability and reduce development time, and probably reduce future confusion if there is ever a need to map one namespace to another in an interworking function. In the specification of any future namespace, several facets need to be done or included: 1) New namespace/priority-value combinations proposed in the future MUST be defined in a Standards Track RFC and MUST include an augmentation to following table offered to IANA for Registration: Intended New New Error Namespace Levels Operation Rej. code code Reference --------- ------ ---------------- --------- ---- --------- Levels> or queue> code> code> IETF doc> - as well as list the finite set of priority values in relative priority order (with no wildcards) for IANA Registration. 2) New priority-values MUST NOT be added to any previously (IANA) registered list associated with a particular namespace. This will cause interoperability problems. 3) If there is a new "intended behavior" (other than preemption- based or priority queue-based), the parameters for that behavior must be provided and how said behavior affects different types of RP actors. 4) Any new Response Codes unique to this new namespace need to be explained. Polk & Schulzrinne [page 24] Internet-Draft SIP Resource Priority February 21st, 2005 5) Any new Rejection Codes or changes to existing rejections codes as a result of the creation of the namespace need to be offered and explained. 9. Examples The SDP message body and the BYE and ACK exchanges are the same as in RFC 3665 [RFC3665] and omitted for brevity. 9.1 Simple Call User A User B | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | In this scenario, User A completes a call to User B directly. The call from A to B is marked with a resource priority indication. F1 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... F2 180 Ringing User B -> User A SIP/2.0 180 Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Polk & Schulzrinne [page 25] Internet-Draft SIP Resource Priority February 21st, 2005 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Length: 0 F3 200 OK User B -> User A SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... 9.2 Receiver Does Not Understand Namespace In this example, the receiving UA does not understand the "dsn" namespace and thus returns a 417 (Unknown Resource-Priority) status code. We omit the message details for messages F5 through F7 since they are essentially the same as in the first example. User A User B | | | INVITE F1 | |----------------------->| | 417 R-P failed F2 | |<-----------------------| | ACK F3 | |----------------------->| | | | INVITE F4 | |----------------------->| | 180 Ringing F5 | |<-----------------------| | 200 OK F6 | |<-----------------------| | ACK F7 | |----------------------->| | | Polk & Schulzrinne [page 26] Internet-Draft SIP Resource Priority February 21st, 2005 | Both Way RTP Media | |<======================>| F1 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... F2 417 Resource-Priority failed User B -> User A SIP/2.0 417 Resource-Priority failed Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4 Contact: Content-Type: application/sdp Content-Length: 0 F3 ACK User A -> User B ACK sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F4 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Polk & Schulzrinne [page 27] Internet-Draft SIP Resource Priority February 21st, 2005 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Resource-Priority: q735.3 Contact: Content-Type: application/sdp Content-Length: ... ... 10. Security Considerations Any resource priority mechanism can be abused to obtain resources and thus deny service to other users. An adversary may be able to take over a particular gateway, cause additional congestion during PSTN emergencies or deny service to legitimate users. In the Internet, or any IP domain, this mechanism can cause certain messages or sessions (calls) to be given a higher relative priority of processing within a SIP element (move to the head of the line scenario), to the point of prematurely terminating an existing session in favor of a newer one. In some administrative domains, this will be the expected behavior for authenticated and authorized users (see section 8). Unauthorized users MUST NOT be given this opportunity to abuse network/element resources. While the indication itself does not have to provide separate authentication, any SIP request containing this header has higher authentication requirements than regular requests. A poor implementation of authentication and authorization will likely cause illegitimate higher priority messages to process without being successfully challenged for the privilege to do so. While this will not likely have a great affect on the performance of SIP Servers, this could have some (to a great) impact on the premature termination of existing sessions. Those domains wishing to utilize a namespace with an operation of preemption of lower relative priority sessions should use caution to ensure only the proper usage of this header is granted. Care should be taken on 3 fronts: 1) To the domain that enables usage of the Resource-Priority header such that adequate control exists to prevent unwanted preferential message treatment from internal users. Without an authentication and authorization mechanism to validate each user request, unwanted usage (and potentially user hacked settings) can have undesired affects on any internal network. 2) To the domain that enables usage of the Resource-Priority header such that inadequate control exists to prevent unwanted preferential message treatment from SIP messages from outside the Polk & Schulzrinne [page 28] Internet-Draft SIP Resource Priority February 21st, 2005 domain coming into the domain (and outside the area of direct AAA control). 3) In the choosing of a namespace itself, to make sure the desired behavior of SIP elements have equivalent behaviors defined in this document to ensure interoperability and no surprises. An example of this is choosing a namespace throughout a domain and configuring it for preferential treatment with no preemption, even though a neighbor domain uses it as it is IANA defined (with preemption as one expected behavior), resulting in poor performance of fist domain's calls into the second administrative domain's network. Below, we describe authentication and authorization aspects, confidentiality and privacy requirements, protection against denial of service attacks and anonymity requirements. Naturally, the general discussion in RFC 3261 [RFC3261] applies. All user agents and proxy servers which support this extension MUST implement SIP over TLS [RFC3546] and the sips: URI scheme as described in Section 26.2 of RFC 3261, and Digest Authentication [RFC2617] as described in Section 22 of RFC 3261. In addition, user agents which support this extension SHOULD also implement S/MIME [RFC2633] as described in Section 23 of RFC 3261 to allow for signing and verification of signatures over requests which use this extension. 10.1 Authentication and Authorization Prioritized access to network and end system resources imposes particularly stringent requirements on authentication and authorization mechanisms since access to prioritized resources may impact overall system stability and performance, not just result in theft of, say, a single phone call. Under certain emergency conditions, the network infrastructure, including its authentication and authorization mechanism, may be under attack. Given the urgency during emergency events, normal statistical fraud detection may be less effective, thus placing a premium on reliable authentication. Common requirements for authentication mechanisms apply, such as resistance to replay, cut-and-paste and bid-down attacks. Authentication MAY be SIP-based or use other mechanisms. Use of Digest authentication and/or S/MIME is RECOMMENDED for UAS authentication. Digest authentication requires that the parties share a common secret, thus limiting its use across administrative Polk & Schulzrinne [page 29] Internet-Draft SIP Resource Priority February 21st, 2005 domains. SIP systems employing resource priority SHOULD implement S/ MIME at least for integrity, as described in Section 23 of [RFC3261]. However, in some environments, receipt of asserted identity [RFC3325] from a trusted entity may be sufficient authorization. Section 5 describes third-party authentication. Trait-based authorization [I-D.ietf-sipping-trait-authz] "entails an assertion by a authorization service of attributes associated with an identity" and may be appropriate for this application. With trait-based authorization, a network element can directly determine, by inspecting the certificate, that a request is authorized to obtain a particular type of service, without having to consult a mapping mechanism that converts user identities to authorizations. Authorization may be based on factors beyond the identity of the caller, such as the requested destination. Namespaces MAY also impose particular authentication or authorization consideration that are stricter than the baseline described here. 10.2 Confidentiality and Integrity Calls which use elevated resource priority levels provided by the 'Resource-Priority' header field are likely to be sensitive and often need to be protected from intercept and alteration. In particular, requirements for protecting the confidentiality of communications relationships may be higher than for normal commercial service. For SIP, the 'To', 'From', 'Organization' and 'Subject' header fields are examples of particularly sensitive information. Systems MUST implement encryption at the transport level using TLS and MAY implement other transport-layer or network-layer security mechanisms. UACs SHOULD use the "sips" URI to request a secure transport association to the destination. The 'Resource-Priority' header field can be carried in the SIP message header or can be encapsulated in a message fragment carried in the SIP message body [RFC3420]. To be considered valid authentication for the purposes of this specification, S/MIME signed SIP messages or fragments MUST contain, at a minimum, the Date, To, From, Call-ID, and Resource-Priority header fields. Encapsulation in S/MIME body parts allows the user to protect this header field against inspection or modification by proxies. However, in many cases, proxies will need to authenticate and authorize the request, so that encapsulation is undesirable. Removal of a Resource-Priority header field or downgrading its priority value affords no additional opportunities to an adversary since that man-in-the-middle could simply drop or otherwise invalidate the SIP request and thus prevent call completion. Only SIP elements within the same administrative trust domain employing a secure channel between their SIP elements will trust a Polk & Schulzrinne [page 30] Internet-Draft SIP Resource Priority February 21st, 2005 Resource-Priority header field that is not appropriately signed. Others will need to authenticate the request independently. Thus, insertion of a Resource-Priority header field or upgrading the priority value has no further security implications except causing a request to fail (see discussion in the previous paragraph). 10.3 Anonymity Some users may wish to remain anonymous to the request destination. Anonymity for requests with resource priority is no different than for any other authenticated SIP request. For the reasons noted earlier, users have to authenticate themselves towards the SIP elements carrying the request where they desire resource priority treatment. The authentication may be based on capabilities and noms, not necessarily their civil name. Clearly, they may remain anonymous towards the request destination, using the network-asserted identity and general privacy mechanism described in [RFC3323]. 10.4 Denial-of-Service Attacks As noted, systems described here are likely to be subject to deliberate denial-of-service (DoS) attacks during certain types of emergencies. DoS attacks may be launched on the network itself as well as its authentication and authorization mechanism. As noted, systems should minimize the amount of state, computation and network resources that an unauthorized user can command. The system must not amplify attacks by causing the transmission of more than one packet to a network address whose reachability has not been verified. 11. IANA Considerations This section defines two new SIP headers (11.1), one SIP OPTION tag (11.2), one new 4XX error code (11.3), a new registry within the sip-parameters section of IANA for Resource-Priority namespaces (11.4) and a new registry within the sip-parameters section of IANA for Resource-Priority and priority-values (11.5). Additional namespaces and priority values MUST be registered with IANA. Within each namespace, the registration MUST indicate the 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 [RFC 3427] establishes a policy for the registration of new SIP extension headers. Resource priority namespaces and priority values have similar interoperability requirements to those of SIP extension headers. Consequently, registration of new resource priority namespaces and priority values Polk & Schulzrinne [page 31] Internet-Draft SIP Resource Priority February 21st, 2005 requires documentation in an RFC using the extension header approval process specified in RFC 3427. 11.1 IANA Registration of 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields [NOTE TO RFC EDITOR: Replace RFC XXXX with RFC number of this document.] The following is the registration for the 'Resource-Priority' header field: RFC number: XXXX Header name: 'Resource-Priority' Compact form: none The following is the registration for the 'Accept-Resource-Priority' header field: RFC number: XXXX Header name: Accept-Resource-Priority Compact form: none 11.2 IANA Registration for Option Tag resource-priority RFC number: XXXX Name of option tag: 'resource-priority' Descriptive text: Indicates or requests support for the resource priority mechanism. 11.3 IANA Registration for Response Code 417 RFC number: XXXX Response code: 417 Default reason phrase: Unknown Resource-Priority 11.4 IANA Namespace and Priority-Value Registrations A new registry ("Resource-Priority Namespaces") in the sip-parameters section of IANA is to be created taking a form similar to this table below: Intended New New Error Namespace Levels Operation Rej. code code Reference --------- ------ ---------------- --------- ---- --------- dsn 5 preemption no no [This RFC] drsn 6 preemption no no [This RFC] Polk & Schulzrinne [page 32] Internet-Draft SIP Resource Priority February 21st, 2005 q735 5 preemption no no [This RFC] ets 5 priority-queue no no [This RFC] wps 5 priority-queue no no [This RFC] Legend ------ Namespace = the unique string of the namespace Levels = the number of priority-values within the namespace Operation = Intended (or expected) operational behavior of SIP elements encountering this namespace New Rej. Code = New Rejection Codes introduced for this namespace New Error Code = New Error Codes introduced for this namespace Reference = IETF Document reference for this namespace 11.5 IANA Priority-Value Registrations A new registry ("Resource-Priority Priority-values") in the sip-parameters section of IANA is to be created taking a form similar to this table below (Reference [XXXX] is this RFC): Namespace: drsn Reference: [XXXX] Priority-Values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override", "flash-override-override" Namespace: dsn Reference: [XXXX] Priority-Values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override", Namespace: q735 Reference: [XXXX] Priority values (least to greatest): "4", "3", "2", "1", "0" Namespace: ets Reference: [XXXX] Priority values (least to greatest): "4", "3", "2", "1", "0" Namespace: wps Reference: [XXXX] Priority values (least to greatest): "4", "3", "2", "1", "0" 12. Acknowledgments Ben Campbell, Paul Kyzivat, Rohan Mahy, Mike Pierce, Samir Srivastava and Allison Mankin provided helpful comments. Polk & Schulzrinne [page 33] Internet-Draft SIP Resource Priority February 21st, 2005 Dean Willis provided much help with this effort. Martin Dolly, An Nguyen and Niranjan Sandesara assisted with the ets and wps namespaces. Janet Gunn helped improve the queue-based policy text. 13. References 13.1 Normative References [I.255.3] International Telecommunications Union, "Integrated Services Digital Network (ISDN) - General Structure and Service Capabilities - Multi-Level Precedence and Preemption", Recommendation I.255.3, July 1990. [Q.735.3] International Telecommunications Union, "Stage 3 description for community of interest supplementary services using Signaling System No. 7: Multi-level precedence and preemption", Recommendation Q.735.3, March 1993. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [I-D.ietf-sipping-reason-header-for-preemption] Polk, J., "Reason Header for Preemption within the Session Polk & Schulzrinne [page 34] Internet-Draft SIP Resource Priority February 21st, 2005 Initiation Protocol (SIP)", draft-ietf-sipping-reason-header-for-preemption-02 (work in progress), August 2004 13.2 Informative References [I-D.ietf-ieprep-framework] Carlberg, K., Brown, I. and C. Beard, "Framework for Supporting ETS in IP Telephony", draft-ietf-ieprep-framework-09 (work in progress), April 2004. [RFC3893] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", RFC 3893, May 2004. [RFC3903] Niemi, A., "An Event State Publication Extension to the Session Initiation Protocol (SIP)", RFC3903, May 2004. [I-D.ietf-sipping-trait-authz] Peterson, J., "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", draft-ietf-sipping-trait-authz-01 (work in progress), February 2005. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002. [RFC3325] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Polk & Schulzrinne [page 35] Internet-Draft SIP Resource Priority February 21st, 2005 Method", RFC 3515, April 2003. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. Authors' Addresses James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA EMail: jmpolk@cisco.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of Polk & Schulzrinne [page 36] Internet-Draft SIP Resource Priority February 21st, 2005 such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Polk & Schulzrinne [page 37]