Network Working Group K. Carlberg Request for Comments: 5115 G11 Category: Standards Track P. O'Hanlon UCL January 2008 Telephony Routing over IP (TRIP) Attribute for Resource Priority Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
AbstractThis document defines a new attribute for the Telephony Routing over IP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. rfc3219] provides a way for nodes on the IP network to locate a suitable gateway through the use of Location Servers. TRIP is a policy- driven, inter-administrative domain protocol for advertising the reachability, negotiating the capabilities, and specifying the attributes of these gateways. The TRIP protocol is modeled after BGP-4 [rfc4271] and uses path- vector advertisements distributed in a hop-by-hop manner (resembling a Bellman-Ford routing algorithm) via Location Servers. These Location Servers are grouped in administrative clusters known as Internet Telephony Administrative Domains (ITADs). A more extensive framework discussion on TRIP can be found in [rfc2871].
This document defines a new attribute that has been registered with IANA. The purpose of this new attribute, and the rationale behind its specification, is explained in the following sections. 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 [rfc2119]. ANSI] to signal the presence of the National Security / Emergency Preparedness (NS/EP) codepoint in an ISDN User Part (ISUP) Initial Address Message (IAM) for Signaling System No. 7 (SS7). A key aspect of GETS is that a signaling standard in the U.S. PSTN is used to convey the activation/request of the GETS service. From a protocol perspective, other examples of priority (and which can be argued as emergency/disaster related) standards are the H.460.4 ITU [itu460] standard on Call Priority designation for H.323 calls, and the I.255.3 [itu255] ITU standard on Multi-Level Precedence and Preemption Service. The latter has been integrated into private telephony systems like AUTOVON. In both cases, signaling codepoints exist to distinguish telephony calls by authenticated and prioritized end-user from the normal end-user. The form of this distinction varies and is outside the scope of this document. [rfc3689] and [rfc3690] provide additional information on ETS and its requirements. ADEL00], led to strawman requirements to augment SIP to have the ability to prioritize call signaling. This effort was then advanced formally in the SIPPING working group so that SIP would be able to prioritize access to circuit-switched networks, end systems, and proxy resources for emergency preparedness communication [rfc3487]. The requirements in [rfc3487] produced the corresponding document [rfc4412] in the SIP working group, which defines a new header for SIP called Resource-Priority. This new header, which is optional, is
divided into two parts: a NameSpace and a Value. The NameSpace part uniquely identifies a group of one or more priorities. The Value part identifies one of a set of priorities used for a SIP message.
Section 5 of [rfc3219]. Attribute Flags are set to the following: Conditional Mandatory: False Required Flags: Not Well-Known, Independent Transitive Potential Flags: None TRIP Type Code: 12 There are no dependencies on other attributes, thus Conditional Mandatory is set to "False". Since the Resource-Priority field in SIP, with its corresponding NameSpace token, is optional, the ResourcePriority attribute in TRIP is also optional. Hence, it is set to "Not Well-Known". The Independent Transitive condition indicates that the attribute is to be forwarded amongst all ITADs. The Location Server that does not recognize the attribute sets the Partial flag as well. rfc4412], with subsequent identifiers to be found in the IANA registry. The syntax of the ResourcePriority attribute is copied from the "namespace" token syntax from [rfc4412], which in turn imported "alphanum" from [rfc3261], and is an alphanumeric value as shown below: namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) Note that an augmented version of Backus-Naur Form is found in [rfc4234]. Since NameSpaces are arbitrary in length, each tuple consists of a Length value with a NameSpace value as shown in the figure below. There is no padding between tuples.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | NameSpace Length | NameSpace Value (variable) | +---------------+---------------+--------------+----------------+ It is important to note that the priority (i.e., "r-priority" token syntax) from [rfc4412] is NOT used in the ResourcePriority attribute. This is because the objective of the attribute is to advertise the NameSpace associated with a gateway and not the individual priorities within that NameSpace. Section 5.12 of TRIP lists a number of considerations that should be addressed when defining new attributes. The first three considerations (use of the attribute, its flags, and syntax) have been discussed above in this section. The final three considerations are the following.
Section 14 of [rfc3219]. Section 4 above, one new "TRIP attribute" has been defined. Its name and code value are the following: Code Attribute Name ---- ---------------- 12 ResourcePriority These assignments are recorded in the following registry: http://www.iana.org/assignments/trip-parameters [rfc3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002. [rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. [ADEL00] IETF Proceedings (47th), SIP Working Group, Adelaide, Australia, June 2000. [ANSI] ANSI, "Signaling System No. 7 (SS7): High Probability of Completion (HPC) Network Capability", ANSI T1.631, 1993. [itu460] ITU, "Call Priority Designation for H.323 Calls", ITU Recommendation H.460.4, November 2002. [itu255] ITU, "Multi-Level Precedence and Preemption Service", ITU Recommendation I.255.3, July 1990.
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000. [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. [rfc3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003. [rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. [rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service (ETS)", RFC 3690, February 2004. [rfc4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [rfc4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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 procedures with respect to rights in RFC 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 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 email@example.com.