Network Working Group K. Carlberg
Request for Comments: 5115 G11
Category: Standards Track P. O'Hanlon
UCL
January 2008
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
资源优先级的IP电话路由（TRIP）属性
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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.
本文档为IP电话路由（TRIP）协议定义了一个新属性。该属性关联PSTN中的协议/服务，在呼叫设置期间提供可通过行程网关访问的授权优先级。公共交换电话网（PSTN）中的优惠服务的当前例子是美国急诊科电信服务（GET）和英国政府电话优惠方案（GTPS）。TRIP的建议属性基于命名空间。
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.
IP电话网关允许基于IP的网络上的节点与电路交换电话网络上的其他实体通信。IP电话路由（TRIP）协议[rfc3219]为IP网络上的节点提供了一种通过使用定位服务器定位合适网关的方法。TRIP是一种策略驱动的跨管理域协议，用于宣传可达性、协商能力和指定这些网关的属性。
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].
TRIP协议以BGP-4[rfc4271]为模型，通过位置服务器使用逐跳方式（类似于贝尔曼-福特路由算法）分布的路径向量广告。这些位置服务器分组在称为Internet电话管理域（ITAD）的管理集群中。关于TRIP的更广泛的框架讨论见[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.
本文档定义了一个已向IANA注册的新属性。此新属性的目的及其规范背后的基本原理将在以下部分中解释。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[rfc2119]中所述进行解释。
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.
应急电信服务是一个广义术语，指用于支持应急通信的系统提供的服务。这些系统的一个例子是美国政府紧急电信服务（GETS）。该系统目前通过美国公共交换电话网（PSTN）作为授权人员的按使用付费系统运行。它使用T1.631-1993 ANSI标准[ANSI]来表示7号信令系统（SS7）的ISDN用户部分（ISUP）初始地址消息（IAM）中存在国家安全/应急准备（NS/EP）码点。GETS的一个关键方面是，美国PSTN中的信令标准用于传输GETS服务的激活/请求。
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.
从协议的角度来看，优先级标准的其他示例（可被称为紧急/灾难相关）有H.460.4 ITU[itu460]标准关于H.323呼叫的呼叫优先级指定，以及I.255.3[itu255]ITU标准关于多级优先级和抢占服务。后者已经集成到像AUTOVON这样的私人电话系统中。在这两种情况下，都存在信令码点，以区分经过身份验证和优先排序的最终用户与正常最终用户的电话呼叫。这种区别的形式各不相同，不在本文件的范围之内。[rfc3689]和[rfc3690]提供了有关ETS及其要求的附加信息。
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].
IEPREP工作组列表中的初步讨论，以及阿德莱德IETF[ADEL00]上的演示，导致斯特劳曼要求增强SIP，使其能够优先考虑呼叫信令。这项工作随后在SIP工作组中正式推进，以便SIP能够优先访问电路交换网络、终端系统和应急准备通信的代理资源[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
[rfc3487]中的要求在SIP工作组中产生了相应的文档[rfc4412]，该文档定义了一个称为资源优先级的SIP新头。此新标题（可选）是
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.
分为两部分：名称空间和值。名称空间部分唯一标识一组或多个优先级。值部分标识用于SIP消息的一组优先级中的一个。
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.
在SIP中添加资源优先级头有三个基本好处。第一种是能够向IP网络中的其他实体发送SIP消息中的优先级信号。需要注意的是，一些实体可能无法识别/支持优先级或名称空间，但至少在SIP协议中指定了发送资源优先级信号的能力。
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.
第二个好处是，来自其他标准的与电话相关的协议/代码点可以在资源优先级报头中具有到SIP命名空间和值令牌的对应映射。因此，ANSI标准T1.631-1993中当前的NS/EP代码点可以为IETF标准主体设置相应的NameSpace.Value标记。因此，这种映射将促进不同组织定义的标准之间信号（即代码点）的透明桥接——无论是私有的还是公共的。
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.
资源优先级头的第三个好处，以及它对字母数字标记的定义，是它具有高度的通用性。名称空间允许定义和更新一组广泛的优先级，如果需要的话，只需定义一个新的名称空间标记即可。因此，不依赖适用于所有情况的单一优先次序。
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.
定义了通过网关发送优先级信号的方法之后，接下来的问题是如何确定哪些网关支持给定的名称空间。此类信息的传播属于TRIP的范围。但是，当前的TRIP规范不包括一个组件，该组件将公布网关与特定名称空间的关联。为了解决这一遗漏，以下部分定义了一个新的TRIP属性，该属性将一个或多个名称空间与网关相关联。
This section provides details on the syntax and semantics of the ResourcePriority TRIP attribute. Its presentation reflects the form of existing attributes presented in Section 5 of [rfc3219].
本节提供有关ResourcePriority TRIP属性的语法和语义的详细信息。其呈现反映了[rfc3219]第5节中呈现的现有属性的形式。
Attribute Flags are set to the following:
属性标志设置为以下值：
Conditional Mandatory: False Required Flags: Not Well-Known, Independent Transitive Potential Flags: None TRIP Type Code: 12
条件强制：假必需标志：不知名，独立可传递潜在标志：无跳闸类型代码：12
There are no dependencies on other attributes, thus Conditional Mandatory is set to "False".
不依赖于其他属性，因此条件强制设置为“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".
由于SIP中的Resource Priority字段及其相应的命名空间令牌是可选的，因此TRIP中的ResourcePriority属性也是可选的。因此，它被设置为“不知名”。
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.
独立传递条件表示该属性将在所有ITAD之间转发。不识别该属性的位置服务器也会设置部分标志。
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:
ResourcePriority属性包含一个或多个命名空间令牌标识符。初始标识符集在[rfc4412]中定义，后续标识符可在IANA注册表中找到。ResourcePriority属性的语法是从[rfc4412]的“名称空间”标记语法复制而来的，后者又从[rfc3261]导入了“alphanum”，是一个字母数字值，如下所示：
namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
/ "`" / "'" / "~" )
namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
/ "`" / "'" / "~" )
Note that an augmented version of Backus-Naur Form is found in [rfc4234].
请注意，在[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) |
+---------------+---------------+--------------+----------------+
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.
需要注意的是，[rfc4412]中的优先级（即“r-priority”标记语法）未在ResourcePriority属性中使用。这是因为该属性的目标是公布与网关关联的命名空间，而不是公布该命名空间中的各个优先级。
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.
TRIP第5.12节列出了定义新属性时应考虑的一些因素。前三个注意事项（属性的使用、其标志和语法）已在本节中进行了讨论。最后三点考虑如下。
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.
ResourcePriority属性不是众所周知的。如果路由具有与其关联的ResourcePriority属性，则位置服务器（LS）必须在其发起的播发中包含该属性。
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.
不得聚合具有不同ResourcePriority令牌值的路由。可以聚合ResourcePriority属性中具有相同令牌值的路由，并将相同ResourcePriority属性附加到聚合对象。
An LS MUST include the ResourcePriority attribute when communicating with peer LSs within its own domain.
LS在其自己的域内与对等LSs通信时必须包含ResourcePriority属性。
If received from a peer LS in another domain, an LS MUST propagate the ResourcePriority attribute to other LSs within its domain.
如果从另一个域中的对等LS接收，LS必须将ResourcePriority属性传播到其域中的其他LSs。
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.
LS可以在将路由对象传播到另一个域中的LS时添加ResourcePriority属性。包含ResourcePriority属性是本地管理策略的问题。
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 in Section 14 of [rfc3219].
该文档为TRIP协议定义了一个新属性，并且没有对其应用直接的安全考虑。然而，TRIP及其信息的安全注意事项保持不变，并在[rfc3219]的第14节中阐明。
As described in Section 4 above, one new "TRIP attribute" has been defined. Its name and code value are the following:
如上文第4节所述，定义了一个新的“行程属性”。其名称和代码值如下所示：
Code Attribute Name
---- ----------------
12 ResourcePriority
Code Attribute Name
---- ----------------
12 ResourcePriority
These assignments are recorded in the following registry:
http://www.iana.org/assignments/trip-parameters
These assignments are recorded in the following registry:
http://www.iana.org/assignments/trip-parameters
The authors appreciate review and subsequent comments from James Polk and Henning Schulzrinne.
作者感谢James Polk和Henning Schulzrinne的评论和随后的评论。
[rfc3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[rfc3219]Rosenberg，J.，Salama，H.，和M.Squire，“IP电话路由（TRIP）”，RFC 3219，2002年1月。
[rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[rfc4412]Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[ADEL00] IETF Proceedings (47th), SIP Working Group, Adelaide, Australia, June 2000.
[ADEL00]IETF会议记录（第47次），SIP工作组，澳大利亚阿德莱德，2000年6月。
[ANSI] ANSI, "Signaling System No. 7 (SS7): High Probability of Completion (HPC) Network Capability", ANSI T1.631, 1993.
[ANSI]ANSI，“第7号信号系统（SS7）：高完工概率（HPC）网络能力”，ANSI T1.6311993。
[itu460] ITU, "Call Priority Designation for H.323 Calls", ITU Recommendation H.460.4, November 2002.
[itu460]国际电联，“H.323呼叫的呼叫优先级指定”，国际电联建议H.460.4，2002年11月。
[itu255] ITU, "Multi-Level Precedence and Preemption Service", ITU Recommendation I.255.3, July 1990.
[itu255]国际电联，“多级优先和抢占服务”，国际电联建议I.255.3，1990年7月。
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[rfc2871]Rosenberg，J.和H.Schulzrinne，“IP电话路由框架”，RFC 28712000年6月。
[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.
[rfc3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[rfc3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[rfc3487]Schulzrinne，H.，“会话启动协议（SIP）的资源优先级机制要求”，RFC 3487，2003年2月。
[rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[rfc3689]Carlberg，K.和R.Atkinson，“紧急电信服务（ETS）的一般要求”，RFC 3689，2004年2月。
[rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service (ETS)", RFC 3690, February 2004.
[rfc3690]Carlberg，K.和R.Atkinson，“紧急电信服务（ETS）的IP电话要求”，RFC 36902004年2月。
[rfc4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[rfc4234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[rfc4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[rfc4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
Authors' Addresses
作者地址
Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA
Ken Carlberg G11 123a美国马里兰州巴尔的摩凡尔赛宫
EMail: carlberg@g11.org.uk
EMail: carlberg@g11.org.uk
Piers O'Hanlon University College London Gower Street London UK
英国伦敦高尔街皮尔斯奥汉隆大学学院
EMail: p.ohanlon@cs.ucl.ac.uk
EMail: p.ohanlon@cs.ucl.ac.uk
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.