Network Working Group K. Kompella
Request for Comments: 3477 Y. Rekhter
Category: Standards Track Juniper Networks
January 2003
Network Working Group K. Kompella
Request for Comments: 3477 Y. Rekhter
Category: Standards Track Juniper Networks
January 2003
Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
资源预留协议中未编号链路的信令发送.流量工程（RSVP-TE）
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links.
多协议标签交换流量工程（MPLS TE）使用的当前信令不支持未编号的链路。本文档定义了用于标签交换路径（LSP）隧道（RSVP-TE）的资源预留协议（RSVP）的程序和扩展，RSVP-TE是MPLS TE信令协议之一，支持无编号链路所需。
Specification of Requirements
需求说明
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Supporting MPLS TE over unnumbered links (i.e., links that do not have IP addresses) involves two components: (a) the ability to carry (TE) information about unnumbered links in IGP TE extensions (ISIS or OSPF), and (b) the ability to specify unnumbered links in MPLS TE signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The focus of this document is on the latter.
在未编号链路（即，没有IP地址的链路）上支持MPLS TE涉及两个组成部分：（a）在IGP TE扩展（ISIS或OSPF）中承载（TE）有关未编号链路的信息的能力，以及（b）在MPLS TE信令中指定未编号链路的能力。前者包含在[GMPLS-ISIS，GMPLS-OSPF]中。本文件的重点是后者。
Current signalling used by MPLS TE does not provide support for unnumbered links because the current signalling does not provide a way to indicate an unnumbered link in its Explicit Route and Record Route Objects. This document proposes simple procedures and extensions that allow RSVP-TE signalling [RFC3473] to be used with unnumbered links.
MPLS TE使用的当前信令不支持未编号的链路，因为当前信令不提供在其显式路由中指示未编号链路和记录路由对象的方法。本文件提出了允许RSVP-TE信令[RFC3473]与未编号链路一起使用的简单程序和扩展。
An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it. If one is using OSPF or ISIS as the IGP in support of traffic engineering, then the IS-IS and/or OSPF and RSVP modules on an LSR must agree on the identifiers.
未编号的链接必须是点对点链接。未编号链路两端的LSR为该链路分配一个标识符。此标识符是一个非零32位数字，在分配它的LSR范围内是唯一的。如果使用OSPF或ISIS作为IGP支持流量工程，则LSR上的is-is和/或OSPF和RSVP模块必须在标识符上达成一致。
There is no a priori relationship between the identifiers assigned to a link by the LSRs at each end of that link.
链路两端的LSR分配给链路的标识符之间没有先验关系。
LSRs at the two end points of an unnumbered link exchange with each other the identifiers they assign to the link. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP ([LMP]), by means of RSVP/CR-LDP (especially in the case where a link is a Forwarding Adjacency, see below), or by means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]).
未编号链路两端的LSR相互交换分配给链路的标识符。可通过配置、借助诸如LMP（[LMP]）、借助RSVP/CR-LDP（尤其在链路是转发邻接的情况下，参见下文）或借助is-is或OSPF扩展（[ISIS-GMPLS]、[OSPF-GMPLS]）来完成标识符的交换。
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an identifier for that link. So does LSR B. From A's perspective, we refer to the identifier that A assigned to the link as the "link local identifier" (or just "local identifier"), and to the identifier that B assigned to the link as the "link remote identifier" (or just "remote identifier"). Likewise, from B's perspective, the identifier that B assigned to the link is the local identifier, and the identifier that A assigned to the link is the remote identifier.
考虑LSR A和B之间的（未编号）链路，LSR A选择该链路的标识符。LSR B也是如此。从A的角度来看，我们将A分配给链路的标识符称为“链路本地标识符”（或简称“本地标识符”），将B分配给链路的标识符称为“链路远程标识符”（或简称“远程标识符”）。同样，从B的角度来看，B分配给链路的标识符是本地标识符，A分配给链路的标识符是远程标识符。
In the context of this document the term "Router ID" means a stable IP address of an LSR that is always reachable if there is any connectivity to the LSR. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface on the LSR is down. In some cases this value will need to be configured. If one is using the OSPF or ISIS as the IGP in support of traffic engineering, then it is RECOMMENDED for the Router ID to be set to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE].
在本文件的上下文中，术语“路由器ID”是指LSR的稳定IP地址，如果与LSR存在任何连接，则该地址始终可访问。这通常实现为“环回地址”；关键属性是，如果LSR上的接口关闭，地址不会变得不可用。在某些情况下，需要配置此值。如果使用OSPF或ISIS作为IGP以支持流量工程，则建议将路由器ID设置为[OSPF-TE]中定义的“路由器地址”，或[ISIS-TE]中定义的“流量工程路由器ID”。
This section is equally applicable to the case of unnumbered component links (see [LINK-BUNDLE]).
本节同样适用于未编号组件链接的情况（见[链接束]）。
If an LSR that originates an LSP advertises this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR uses the Forwarding Adjacency formed by this LSP as an unnumbered component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST allocate an identifier to that Forwarding Adjacency (just like for any other unnumbered link). Moreover, the Path message used for establishing the LSP that forms the Forwarding Adjacency MUST contain the LSP_TUNNEL_INTERFACE_ID object (described below), with the LSR's Router ID set to the head end's Router ID, and the Interface ID set to the identifier that the LSR allocated to the Forwarding Adjacency.
如果发起LSP的LSR在IS-IS或OSPF中将此LSP作为未编号的转发邻接播发（请参见[LSP-HIER]），或者LSR将此LSP形成的转发邻接用作捆绑链路的未编号组件链路（请参见[link-BUNDLE]），则LSR必须为该转发邻接分配一个标识符（与任何其他未编号的链接一样）。此外，用于建立形成转发邻接的LSP的路径消息必须包含LSP_TUNNEL_INTERFACE_ID对象（如下所述），LSR的路由器ID设置为前端的路由器ID，接口ID设置为LSR分配给转发邻接的标识符。
If the Path message contains the LSP_TUNNEL_INTERFACE_ID object, then the tail-end LSR MUST allocate an identifier to that Forwarding Adjacency (just like for any other unnumbered link). Furthermore, the Resv message for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the LSR's Router ID set to the tail-end's Router ID, and the Interface ID set to the identifier allocated by the tail-end LSR.
如果Path消息包含LSP_TUNNEL_INTERFACE_ID对象，那么后端LSR必须为该转发邻接分配一个标识符（就像任何其他未编号的链接一样）。此外，LSP的Resv消息必须包含LSP_TUNNEL_INTERFACE_ID对象，LSR的路由器ID设置为终端的路由器ID，接口ID设置为终端LSR分配的标识符。
For the purpose of processing the ERO and the IF_ID RSVP_HOP objects, an unnumbered Forwarding Adjacency is treated as an unnumbered (TE) link or an unnumbered component link as follows. The LSR that originates the Adjacency sets the link local identifier for that link to the value that the LSR allocates to that Forwarding Adjacency, and the link remote identifier to the value carried in the Interface ID field of the Reverse Interface ID object. The LSR that is a tail-end of that Forwarding Adjacency sets the link local identifier for that link to the value that the LSR allocates to that Forwarding Adjacency, and the link remote identifier to the value carried in the Interface ID field of the Forward Interface ID object.
为了处理ERO和IF_ID RSVP_HOP对象，未编号的转发邻接被视为未编号（TE）链路或未编号的组件链路，如下所示。发起邻接的LSR将该链路的链路本地标识符设置为LSR分配给该转发邻接的值，将链路远程标识符设置为反向接口ID对象的接口ID字段中携带的值。作为该转发邻接的尾端的LSR将该链路的链路本地标识符设置为LSR分配给该转发邻接的值，将链路远程标识符设置为转发接口ID对象的接口ID字段中携带的值。
The LSP_TUNNEL_INTERFACE_ID object has a class number of of 193, C-Type of 1 and length of 12. The format is given below.
LSP_TUNNEL_INTERFACE_ID对象的类号为193，C-Type为1，长度为12。格式如下所示。
Figure 1: LSP_TUNNEL_INTERFACE_ID Object
图1:LSP_隧道_接口_ID对象
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv message. In the former case, we call it the "Forward Interface ID" for that LSP; in the latter case, we call it the "Reverse Interface ID" for the LSP.
此对象可以选择显示在路径消息或Resv消息中。在前一种情况下，我们称之为该LSP的“转发接口ID”；在后一种情况下，我们称之为LSP的“反向接口ID”。
A new subobject of the Explicit Route Object (ERO) is used to specify unnumbered links. This subobject has the following format:
显式路由对象（ERO）的新子对象用于指定未编号的链接。此子对象具有以下格式：
Figure 2: Unnumbered Interface ID Subobject
图2：未编号的接口ID子对象
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 4 (Unnumbered Interface ID). The Length is 12.
类型为4（未编号的接口ID）。长度是12。
The Interface ID is the identifier assigned to the link by the LSR specified by the router ID.
接口ID是由路由器ID指定的LSR分配给链路的标识符。
When an LSR receives a Path message containing the IF_ID RSVP_HOP object (see [RFC3473], [RFC3471]) with the IF_INDEX TLV, the LSR processes this TLV as follows. The LSR must have information about the identifiers assigned by its neighbors to the unnumbered links between the neighbors and the LSR. The LSR uses this information to find a link with tuple <Router ID, local identifier> matching the tuple <IP Address, Interface ID> carried in the IF_INDEX TLV. If the matching tuple is found, the match identifies the link for which the LSR has to perform label allocation.
当LSR通过IF_索引TLV接收到包含IF_ID RSVP_HOP对象（请参见[RFC3473]、[RFC3471]）的路径消息时，LSR将按如下方式处理该TLV。LSR必须具有由其邻居分配给邻居和LSR之间未编号链路的标识符的信息。LSR使用此信息查找元组<路由器ID，本地标识符>与IF_索引TLV中携带的元组<IP地址，接口ID>匹配的链接。如果找到匹配的元组，则匹配项将标识LSR必须为其执行标签分配的链接。
Otherwise, the LSR SHOULD return an error using the IF_ID ERROR_SPEC object (see [RFC3473], [RFC3471]). The Error code in the object is set to 24. The Error value in the object is set to 16.
否则，LSR应使用IF_ID error_SPEC对象返回错误（请参见[RFC3473]、[RFC3471]）。对象中的错误代码设置为24。对象中的错误值设置为16。
The Unnumbered Interface ID subobject is defined to be a part of a particular abstract node if that node has the Router ID that is equal to the Router ID field in the subobject, and if the node has an
未编号的接口ID子对象定义为特定抽象节点的一部分，前提是该节点的路由器ID等于子对象中的路由器ID字段，并且该节点具有
(unnumbered) link or an (unnumbered) Forwarding Adjacency whose local identifier (from that node's point of view) is equal to the value carried in the Interface ID field of the subobject.
（未编号）链路或（未编号）转发邻接，其本地标识符（从该节点的角度）等于子对象的接口ID字段中的值。
With this in mind, the ERO processing in the presence of the Unnumbered Interface ID subobject follows the rules specified in section 4.3.4.1 of [RFC3209].
考虑到这一点，存在未编号接口ID子对象时的ERO处理遵循[RFC3209]第4.3.4.1节中规定的规则。
As part of the ERO processing, or to be more precise, as part of the next hop selection, if the outgoing link is unnumbered, the Path message that the node sends to the next hop MUST include the IF_ID RSVP_HOP object, with the IP address field of that object set to the Router ID of the node, and the Interface ID field of that object set to the identifier assigned to the link by the node.
作为ERO处理的一部分，或者更准确地说，作为下一跳选择的一部分，如果传出链路未编号，则节点发送到下一跳的路径消息必须包括if_ID RSVP_hop对象，该对象的IP地址字段设置为节点的路由器ID，以及将该对象的接口ID字段设置为节点分配给链接的标识符。
A new subobject of the Record Route Object (RRO) is used to record that the LSP path traversed an unnumbered link. This subobject has the following format:
记录路由对象（RRO）的新子对象用于记录LSP路径穿过未编号链路的情况。此子对象具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Reserved (MBZ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Reserved (MBZ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 4 (Unnumbered Interface ID); the Length is 12. Flags are defined below.
类型为4（未编号的接口ID）；长度是12。标志定义如下。
0x01 Local protection available
0x01本地保护可用
Indicates that the link downstream of this node is protected via a local repair mechanism. This flag can only be set if the Local protection flag was set in the SESSION_ATTRIBUTE object of the corresponding Path message.
指示此节点下游的链路通过本地修复机制受到保护。只有在相应路径消息的会话_属性对象中设置了本地保护标志时，才能设置此标志。
0x02 Local protection in use
0x02正在使用的本地保护
Indicates that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over).
表示正在使用本地修复机制来维护此隧道（通常在其先前路由的链路中断时）。
If at an intermediate node (or at the head-end), the ERO subobject that was used to determine the next hop is of type Unnumbered Interface ID, and a RRO object was received in the Path message (or is desired in the original Path message), an RRO subobject of type Unnumbered Interface ID MUST be appended to the received RRO when sending a Path message downstream.
如果在中间节点（或在前端），用于确定下一跳的ERO子对象的类型为未编号接口ID，并且在路径消息中接收到一个RRO对象（或在原始路径消息中需要），在向下游发送Path消息时，必须将接口ID类型为Unnumbered的RRO子对象附加到接收到的RRO。
If the ERO subobject that was used to determine the next hop is of any other type, the handling procedures of [RFC3209] apply. Also, if Label Recording is desired, the procedures of [RFC3209] apply.
如果用于确定下一跳的ERO子对象为任何其他类型，则[RFC3209]的处理程序适用。此外，如果需要标签记录，则[RFC3209]中的程序适用。
This document makes a small extension to RFC 3209 [RFC3209] to refine and explicate the use of unnumbered links. As such it poses no new security concerns. In fact, one might argue that use of the extra interface identify could make an RSVP message harder to spoof.
本文档对RFC 3209[RFC3209]进行了一个小的扩展，以改进和解释未编号链接的使用。因此，它不会带来新的安全问题。事实上，有人可能会争辩说，使用额外的接口标识会使RSVP消息更难伪造。
The IANA assigns values to RSVP protocol parameters. The current document defines a new subobject for the EXPLICIT_ROUTE object and for the ROUTE_RECORD object. The rules for the assignment of subobject numbers have been defined in [RFC3209], using the terminology of BCP 26, RFC 2434, "Guidelines for Writing an IANA Considerations Section in RFCs". Those rules apply to the assignment of subobject numbers for the new subobject of the EXPLICIT_ROUTE and ROUTE_RECORD objects.
IANA为RSVP协议参数赋值。当前文档为显式路由对象和路由记录对象定义了新的子对象。[RFC3209]使用BCP 26、RFC 2434“在RFCs中编写IANA注意事项部分的指南”中的术语定义了子对象编号的分配规则。这些规则适用于为显式路由和路由记录对象的新子对象指定子对象编号。
Furthermore, the same Internet authority needs to assign a class number to the LSP_TUNNEL_INTERFACE_ID object. This must be of the form 11bbbbbb (i.e., RSVP silently ignores this unknown object but forwards it).
此外，同一互联网机构需要为LSP_TUNNEL_INTERFACE_ID对象分配一个类号。这必须是11bbbbbb的形式（即RSVP默默地忽略此未知对象，但将其转发）。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可供发布的权利主张副本和任何许可证保证副本，或试图
obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
可从IETF秘书处获得本规范实施者或用户使用此类专有权利的一般许可或许可。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Thanks to Lou Berger and Markus Jork for pointing out that the RRO should be extended in like fashion to the ERO. Thanks also to Rahul Aggarwal and Alan Kullberg for their comments on the text. Finally, thanks to Bora Akyol, Vach Kompella, and George Swallow.
感谢Lou Berger和Markus Jork指出RRO应该以同样的方式扩展到ERO。还感谢拉胡尔·阿加瓦尔和艾伦·库尔伯格对文本的评论。最后，多亏了博拉·阿克约尔、瓦赫·科佩拉和乔治·斯沃恩。
[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月。
[RFC3209] Awduche, D., Berger, L., Gan, D. Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.Li，T.，Srinivasan，V.和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，编辑，“通用多协议标签交换（MPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，编辑，“通用多协议标签交换（MPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al., "IS-IS Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-ISIS]Kompella，K.，Rekhter，Y.，Banerjee，A.等人，“支持广义MPLS的IS-IS扩展”，正在进行的工作。
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al., "OSPF Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-OSPF]Kompella，K.，Rekhter，Y.，Banerjee，A.等人，“支持广义MPLS的OSPF扩展”，正在进行中。
[ISIS-TE] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering", Work in Progress.
[ISIS-TE]Li，T.和H.Smit，“交通工程的IS-IS扩展”，正在进行中。
[LINK-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[LINK-BUNDLE]Kompella，K.，Rekhter，Y.和L.Berger，“MPLS流量工程中的链路捆绑”，正在进行中。
[LSP-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[LSP-HIER]Kompella，K.和Y.Rekhter，“具有MPLS TE的LSP层次结构”，正在进行中。
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", Work in Progress.
[LMP]Lang，J.，Mitra，K.，等，“链路管理协议（LMP）”，正在进行的工作。
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", Work in Progress.
[OSPF-TE]Katz，D.，Yeung，D.，Kompella，K.，“OSPF版本2的交通工程扩展”，正在进行中。
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。