Internet Engineering Task Force Internet Draft Polk/Schulzrinne Cisco/Columbia U. draft-polk-sipping-resource-00.txt February 19, 2002 Expires: June 2002 SIP Communications Resource Priority Header 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 a new SIP header field for communications resource priority, called "Resource-Priority". This header field influences the behavior of gateways and SIP proxies. It does not influence the forwarding behavior of IP routers. Polk/Schulzrinne [Page 1] Internet Draft Resource Priority February 19, 2002 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 This document defines a new SIP [2] header field for communications resource priority, called "Resource-Priority". This header MAY be used by GSTN gateways 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 the ITU Recommendation Q.735.3 [3] prioritization mechanism, in both GSTN- to-IP and IP-to-GSTN directions. For IP networks, proxies may offer mechanisms beyond the scope of this document to influence, for example, admission control or IP packet marking. The Resource-Priority header field may be inserted by proxies and SIP user agents. The Resource-Priority header field may be used in several situations: 1. Requesting elevated priority for access to PSTN gateway resources such as trunk circuits. 2. Carrying 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 the header field. 3. Indicating signaling priority in SIP proxies and back-to- back user agents, with higher priorities displacing existing signaling requests or bypassing PSTN gateway capacity limits in effect for lower priorities. This header is related to, but differs in semantics from, the Priority header field (RFC 2543, Section 6.25). 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. It does not influence the use of communications resources such as packet forwarding priority in routers. The mechanism described here can be used for emergency preparedness, but is only a small part of an emergency preparedness network. SIP entities supporting this specification MUST be able to generate Polk/Schulzrinne [Page 2] Internet Draft Resource Priority February 19, 2002 and process this header. 3 The Resource-Priority Header Field This document defines the Resource-Priority general header field. Resource-Priority _ "Resource-Priority" HCOLON Resource-value Resource-value _ namespace "." priority namespace _ alphanum / "-" priority _ alphanum / "-" As a response header, the value indicates the actual priority selected by the recipient. 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 resource value is formatted as "namespace" "." "priority value". Name space and priority values are registered with IANA (see IANA Considerations). Header field where proxy ACK BYE CAN INV OPT REG _____________________________________________________________ Resource-Priority c ar - - - o - - SIP elements MAY downgrade the Resource-Priority of or reject unauthenticated requests. Details are a matter of local policy. Proxies MAY downgrade the Resource-Priority value of unauthenticated requests. Details are specific to each administrative domain and beyond the scope of this document. Proxies SHOULD NOT reject requests with such headers but instead downgrade the resource priority value. A proxy or user agent MAY return status code 503 (Service Unavailable) if there are insufficient resources at the resource priority level specified. 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. 4 IANA Considerations Additional name spaces and priority values are registered with IANA. Within each namespace, The registration MUST indicate the relative precedence levels, expressed as an ordered list. Existing lists of Polk/Schulzrinne [Page 3] Internet Draft Resource Priority February 19, 2002 priorities can only be extended at the bottom, i.e., by adding values with lower priority than any currently registered values. TBD: Any restrictions on new namespaces? 5 Security Considerations The Resource-Priority header field can be abused to consume scarce communications resources. Thus, authentication of the requester is of particular importance. Authentication MAY be SIP-based. A Namespace dsn An initial namespace, "dsn" (Defense Switched Network), contains the priority values, "flash-override", "flash", "immediate", "priority", "routine", where "flash-override" is the highest priority and "routine" is the lowest. [TBD: Should this just be registered by IANA rather than appear in the document?] The values are adopted from RFC 791 [4], omitting the levels "network control" and "internetwork control", as these are inappropriate here. The values are prioritized in the order "critic-ecp" (highest), "flash-override", "flash", "immediate", "priority" and "routine" (lowest). Additional values in the extension parameter are treated as "routine" by entities that do not understand the value. The value "critic-ecp" stands for "Critical and Emergency Call Processing" [4]. This value SHOULD only be used for authorized emergency communications, for example in the United States Government Emergency Telecommunications Service (GETS) [5], the United Kingdom Government Telephone Preference Scheme (GTPS) and similar government emergency preparedness or reactionary implementations elsewhere. B Namespace q735 The namespace "q735" is registered here. It supports carrying information between Q.735.3 (or equivalent) PSTN/ISDN entities without intervening interpretation by SIP proxies and avoids unnecessary interpretation between different networks. The namespace contains the priority values "0", "1", "2", "3" and "4", with "0" being the lowest value and the "4" the highest. C Bibliography [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. Polk/Schulzrinne [Page 4] Internet Draft Resource Priority February 19, 2002 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [3] International Telecommunication Union, "Stage 3 description for community of interest supplementary services using signalling system no. 7: Multi-level precedence and preemption," Recommendation Q.735.3, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993. [4] J. Postel, "Internet protocol," Request for Comments 791, Internet Engineering Task Force, Sept. 1981. [5] K. Carlberg and I. Brown, "Framework for supporting IEPS in IP telephony," Internet Draft, Internet Engineering Task Force, Oct. 2001. Work in progress. D Acknowledgements Mike Pierce provided helpful comments. E Authors' Addresses James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA electronic mail: jmpolk@cisco.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu Polk/Schulzrinne [Page 5] Table of Contents 1 Conventions used in this document ................... 2 2 Introduction ........................................ 2 3 The Resource-Priority Header Field .................. 3 4 IANA Considerations ................................. 3 5 Security Considerations ............................. 4 A Namespace dsn ....................................... 4 B Namespace q735 ...................................... 4 C Bibliography ........................................ 4 D Acknowledgements .................................... 5 E Authors' Addresses .................................. 5 Polk/Schulzrinne [Page 1]