Internet Engineering Task Force Internet Draft Schulzrinne/Polk Columbia U./Cisco draft-ietf-sip-resource-priority-01.txt July 24, 2003 Expires: December 2003 Communications Resource Priority for the Session Initiation Protocol (SIP) STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document defines two new SIP header fields for communications resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The Resource-Priority header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not directly influence the forwarding behavior of IP routers. Schulzrinne/Polk [Page 1] Internet Draft Resource Priority July 24, 2003 1 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2 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 requirements for real-time communications applications involving SIP, including voice-over-IP, multimedia conferencing and instant messaging/presence. Session Initiation Protocol (SIP) [2] applications 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". Currently, SIP does not include a mechanism that allows a request originator to indicate to SIP element that it wishes the request to invoke such resource prioritization. To address this need, this document adds a SIP protocol element that labels certain SIP requests. Schulzrinne/Polk [Page 2] Internet Draft Resource Priority July 24, 2003 This document defines (Section 3) a new SIP [2] header field for communications resource priority, called Resource-Priority. This header field MAY be used by SIP user agents, including 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 [3] prioritization mechanism, in both the GSTN-to-IP and IP-to-GSTN directions. The Resource-Priority header field may be used in several situations. A SIP request with such an indication can be treated differently in several 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 [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 displace existing signaling requests or bypass GSTN gateway capacity limits in effect for lower priorities. This header field is related to, but differs in semantics from, the Priority header field (RFC 3261 [2], Section 20.26). The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. While it 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 this 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. Schulzrinne/Polk [Page 3] Internet Draft Resource Priority July 24, 2003 The mechanism described here can be used for emergency preparedness in emergency telecommunications systems (ETS), but is only a small part of an emergency preparedness network. The mechanism is structured so that it works in all SIP/RTP transparent networks [11], i.e., 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 PSTN gateway or set of SIP elements that are aware of the mechanism. For conciseness, we refer to SIP proxies and user agents that act on the Resource-Priority header field as an RP actor. We define the header field syntax in Section 3 and then describe the behavior of user agents and proxies in Sections 4.5 through 4.7. Section 6 briefly describes how this feature affects existing systems that do not support it. Third-party authentication is discussed in Section 5, while general security issues are enumerated in Section 8. This specification does not propose any new SIP security mechanisms. Examples can be found in Section 7. The mechanism aims to satisfy the requirements in [11]. We present a detailed analysis in Section A. 3 The Resource-Priority and Accept-Resource-Priority SIP Header Fields This document defines the Resource-Priority and Accept-Resource- Priority SIP header fields. The Resource-Priority header field marks a SIP request as desiring prioritized resource access, as described in the introduction. In responses, it indicates the actual resource priority that was granted to the request. Implementations MAY change the value offered in the request; in some environments, the response value is known to be the same as in the request. The SIP element behavior is described for UACs in Section 4.5, for UAS in Section 4.6, for proxies in Section 4.7. The syntax of the Resource-Priority header field is as follows: Resource-Priority = "Resource-Priority" HCOLON (*COMMA Resource-value) Resource-value = namespace "." priority Schulzrinne/Polk [Page 4] Internet Draft Resource Priority July 24, 2003 namespace = alphanum / "-" priority = alphanum / "-" An example header field is: Resource-Priority: q735.1 The Resource-value parameter in the Resource-Priority header indicates the resource priority desired by the request originator. Since a request may traverse multiple administrative domains with multiple different namespaces, it is necessary to be able to enumerate several different namespaces. However, each namespace MUST NOT appear more than once. 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-independent ASCII. Each namespace has at least one priority value. Namespaces and priority values within each namespace are registered with IANA (Section 12); some initial namespaces are described in Section B. We require that even namespaces with only one priority value list that value to avoid problems if additional priority values are added later. There may be multiple resource values or, equivalently, multiple Resource-Priority header fields. For example, the United States Wireless Priority System (WPS) includes both a priority and high-probability-of- call-completion parameter in a single call. The Accept-Resource-Priority response header field indicates what resource values the SIP element supports. The syntax of the Accept- Resource-Priority header field is as follows: Accept-Resource-Priority _ "Accept-Resource-Priority" HCOLON Resource-value (*COMMA Resource-value) Schulzrinne/Polk [Page 5] Internet Draft Resource Priority July 24, 2003 Example: Accept-Resource-Priority: dsn.flash-override, dsn.flash, dsn.immediate, dsn.priority, dsn.routine Header field where proxy INV UPD MES OPT NOT SUB ______________________________________________________________ Resource-Priority R amd o o o - o o Resource-Priority 200 - o o o - o o Accept-Resource-Priority 200 - o o - o - - Accept-Resource-Priority 417 - m m m - m m Accept-Resource-Priority 420 - m m m - m m Use of the header fields in requests with methods such as ACK, BYE, CANCEL, INFO, PRACK and REGISTER are unlikely to be meaningful and the header field MAY be ignored by recipients of such requests. (Other request methods MAY define their own handling rules; unless otherwise specified, recipients MAY ignore these header fields.) Accept-Resource-Priority is only returned in 420 (Not Supported) responses if the element supports the resource priority mechanism, but does not support the particular namespace or priority value. There is no requirement that all requests within a SIP dialog or call use the Resource-Priority header field. 4 Behavior of SIP Elements that Receive Prioritized Requests 4.1 General Rules All user agent servers and proxy servers that receive SIP requests share certain common behavior, which we describe below. Behavior that is specific to user agent servers is covered in Section 4.6, while Section 4.7 deals with proxy behavior. A SIP element supporting this specification MUST be able to interpret the Resource-Priority header field in INVITE, MESSAGE [4], UPDATE [5], SUBSCRIBE [6] and NOTIFY [6] requests. It MAY ignore the header field in other requests unless the request definition defines behavior for the particular method. If a request contains multiple valid namespace/priority values, it is up to local policy to determine how the request is treated. Schulzrinne/Polk [Page 6] Internet Draft Resource Priority July 24, 2003 4.2 Error Conditions 4.3 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 to add a resource priority indication, if authorized. 4.4 Handling Unknown Namespaces and Priority Values When handling requests with unknown namespsaces or priority values, elements can operate in two modes, "strict" and "loose". If the request includes a Require header field with the Resource-Priority option tag, a UAS MUST follow the strict rules, otherwise UAS and proxies may choose either mode according to local policy. Following standard behavior (Section 8.2.2.3 of [2]), a UAS MUST then reject the request with response code 420 (Bad Extension) if it does not understand the resource priority mechanism. For example, a gateway that is unaware of a resource priority namespace might accept a request at non-elevat