Movatterモバイル変換

Network Working Group                                        K. CarlbergRequest for Comments: 5115                                           G11Category: Standards Track                                    P. O'Hanlon                                                                     UCL                                                            January 2008Telephony Routing over IP (TRIP) Attribute for Resource PriorityStatus 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.Abstract   This 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.1.  Introduction   An IP telephony gateway allows nodes on an IP-based network to   communicate with other entities on the circuit switched telephone   network.  The Telephony Routing over IP (TRIP) protocol [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].Carlberg & O'Hanlon         Standards Track                     [Page 1]

RFC 5115              Resource Priority Attribute           January 2008   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].2.  Emergency Telecommunications Service   Emergency Telecommunications Service is a broad term that refers to   the services provided by systems used to support emergency   communications.  One example of these systems is the U.S. Government   Emergency Telecommunications Service (GETS).  This system currently   operates over the U.S. Public Switched Telephone Network (PSTN) as a   pay-per-use system by authorized personnel.  It uses the T1.631-1993   ANSI standard [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.3.  SIP Resource-Priority Effort   The initial discussions in the IEPREP working group list, along with   the presentation at the Adelaide IETF [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, isCarlberg & O'Hanlon         Standards Track                     [Page 2]

RFC 5115              Resource Priority Attribute           January 2008   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.3.1.  Benefits   There are three basic benefits derived from the addition of the   Resource Priority header in SIP.  The first is an ability to signal   the priority within a SIP message to other entities in an IP network.   The caveat is that some entities may not recognize/support the   priority or namespace, but at least the ability to signal the   priority with respect to resources has been specified in the SIP   protocol.   The second benefit is that telephony-related protocol/codepoints from   other standards can have a corresponding mapping to SIP NameSpace and   Value tokens in the Resource-Priority header.  Hence, the current   NS/EP codepoint in ANSI standard T1.631-1993 could have a   corresponding NameSpace.Value token set for the IETF standards body.   And as a result, this mapping would facilitate the transparent   bridging of signals (i.e., codepoints) between standards defined by   various organizations -- be they private or public.   The third benefit of the Resource-Priority header, and its definition   of alphanumeric tokens, is that it is highly versatile.  The   NameSpace allows for a wide set of priorities to be defined and   updated, if the need arises, by simply defining a new NameSpace   token.  Hence, there is no reliance on a single set of priorities   applied for all cases.3.2  Issue   Having defined a means of signaling priority through gateways, the   follow-on question arises of how does one determine which gateways   support a given NameSpace.  The dissemination of this type of   information is within the scope of TRIP.  However, the current   specification of TRIP does not include a component that advertises   associations of gateways with specific NameSpaces.  To address this   omission, the following section defines a new TRIP attribute that   associates one or more NameSpaces with a gateway.Carlberg & O'Hanlon         Standards Track                     [Page 3]

RFC 5115              Resource Priority Attribute           January 20084.  New Attribute: ResourcePriority   This section provides details on the syntax and semantics of the   ResourcePriority TRIP attribute.  Its presentation reflects the form   of existing attributes presented inSection 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.4.1.  Syntax of ResourcePriority   The ResourcePriority attribute contains one or more NameSpace token   identifiers.  An initial set of identifiers is defined in [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.Carlberg & O'Hanlon         Standards Track                     [Page 4]

RFC 5115              Resource Priority Attribute           January 2008    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.4.2  Additional TRIP ConsiderationsSection 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.4.2.1.  Route Origination   The ResourcePriority attribute is not well-known.  If a route has a   ResourcePriority attribute associated with it, the Location Server   (LS) MUST include that attribute in the advertisement it originates.4.2.2.  Route Aggregation   Routes with differing ResourcePriority token values MUST NOT be   aggregated.  Routes with the same token values in the   ResourcePriority attribute MAY be aggregated and the same   ResourcePriority attribute attached to the aggregated object.4.2.3.  Route Dissemination and Attribute Scope   An LS MUST include the ResourcePriority attribute when communicating   with peer LSs within its own domain.   If received from a peer LS in another domain, an LS MUST propagate   the ResourcePriority attribute to other LSs within its domain.   An LS MAY add the ResourcePriority attribute when propagating routing   objects to an LS in another domain.  The inclusion of the   ResourcePriority attribute is a matter of local administrative   policy.Carlberg & O'Hanlon         Standards Track                     [Page 5]

RFC 5115              Resource Priority Attribute           January 20085.  Security Considerations   The document defines a new attribute for the TRIP protocol and has no   direct security considerations applied to it.  However, the security   considerations for TRIP and its messages remain the same and are   articulated inSection 14 of [rfc3219].6.  IANA Considerations   As described inSection 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-parameters7.  Acknowledgements   The authors appreciate review and subsequent comments from James Polk   and Henning Schulzrinne.8.  References8.1.  Normative References   [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)",RFC4412, February 2006.8.2.  Informative References   [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.Carlberg & O'Hanlon         Standards Track                     [Page 6]

RFC 5115              Resource Priority Attribute           January 2008   [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)",RFC3487, 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.Authors' Addresses   Ken Carlberg   G11   123a Versailles Circle   Baltimore, MD   USA   EMail: carlberg@g11.org.uk   Piers O'Hanlon   University College London   Gower Street   London   UK   EMail: p.ohanlon@cs.ucl.ac.ukCarlberg & O'Hanlon         Standards Track                     [Page 7]

RFC 5115              Resource Priority Attribute           January 2008Full Copyright Statement   Copyright (C) The IETF Trust (2008).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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.Carlberg & O'Hanlon         Standards Track                     [Page 8]