Internet Engineering Task Force (IETF) Z. Ali
Request for Comments: 6511 G. Swallow
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Juniper Networks
February 2012
Internet Engineering Task Force (IETF) Z. Ali
Request for Comments: 6511 G. Swallow
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Juniper Networks
February 2012
Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths
RSVP-TE标签交换路径的非倒数第二跳弹出行为和带外映射
Abstract
摘要
There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs.
有许多部署场景要求出口标签交换路由器（LSR）使用某种“带外”（OOB）机制接收资源预留协议-流量工程（RSVP-TE）标签交换路径（LSP）与应用程序和有效负载标识符的绑定。本文件定义了满足此要求的协议机制。本文档中描述的程序同样适用于点对点（P2P）和点对多点（P2MP）LSP。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6511.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6511.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. RSVP-TE Signaling Extensions ....................................3
2.1. Signaling Non-PHP Behavior .................................3
2.2. Signaling OOB Mapping Indication ...........................5
2.3. Relationship between OOB and Non-PHP Flags .................6
2.4. Egress Procedure for Label Binding .........................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
4.1. Attribute Flags for LSP Attributes Object ..................7
4.2. New RSVP Error Sub-Code ....................................8
5. Acknowledgements ................................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. RSVP-TE Signaling Extensions ....................................3
2.1. Signaling Non-PHP Behavior .................................3
2.2. Signaling OOB Mapping Indication ...........................5
2.3. Relationship between OOB and Non-PHP Flags .................6
2.4. Egress Procedure for Label Binding .........................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
4.1. Attribute Flags for LSP Attributes Object ..................7
4.2. New RSVP Error Sub-Code ....................................8
5. Acknowledgements ................................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
When Resource Reservation Protocol - Traffic Engineering (RSVP-TE) is used for applications like Multicast Virtual Private Network (MVPN) [RFC6513] and Virtual Private LAN Service (VPLS) [RFC4761], an egress Label Switching Router (LSR) receives the binding of the RSVP-TE Label Switched Path (LSP) to an application and a payload identifier using an "out-of-band" (OOB) mechanism (e.g., Border Gateway Protocol (BGP)). In such cases, the egress LSR cannot make correct forwarding decisions until such OOB mapping information is received. Furthermore, in order to apply the binding information, the egress LSR needs to identify the incoming LSP on which traffic is coming.
当资源预留协议-流量工程（RSVP-TE）用于多播虚拟专用网（MVPN）[RFC6513]和虚拟专用LAN服务（VPLS）[RFC4761]等应用时，出口标签交换路由器（LSR）接收RSVP-TE标签交换路径（LSP）的绑定使用“带外”（OOB）机制（例如，边界网关协议（BGP））连接到应用程序和有效负载标识符。在这种情况下，出口LSR在接收到这样的OOB映射信息之前不能做出正确的转发决策。此外，为了应用绑定信息，出口LSR需要识别业务来自的传入LSP。
Therefore, non-Penultimate Hop Popping (non-PHP) behavior is required to apply OOB mapping. Non-PHP behavior requires the egress LSRs to assign a non-NULL label for the LSP being signaled.
因此，应用OOB映射需要非倒数第二跳弹出（非PHP）行为。非PHP行为要求出口LSR为发出信号的LSP分配非空标签。
There are other applications that require non-PHP behavior. When RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP multicast traffic non-PHP behavior enables a leaf LSR to identify the P2MP TE LSP on which traffic is received. Hence, the egress LSR can determine whether traffic is received on the expected P2MP LSP and discard traffic that is not received on the expected P2MP LSP. Non-PHP behavior is also required to determine the context of upstream assigned labels when the context is a MPLS LSP. Non-PHP behavior may also be required for MPLS Transport Profile (MPLS-TP) LSPs [RFC5921].
还有其他需要非PHP行为的应用程序。当RSVP-TE点对多点（P2MP）LSP用于承载IP多播流量时，非PHP行为使叶LSR能够识别接收流量的P2MP TE LSP。因此，出口LSR可以确定在预期P2MP LSP上是否接收到业务，并丢弃在预期P2MP LSP上未接收到的业务。当上下文是MPLS LSP时，还需要非PHP行为来确定上游分配标签的上下文。MPLS传输配置文件（MPLS-TP）LSP[RFC5921]也可能需要非PHP行为。
This document defines two new flags in the Attributes Flags TLV of the LSP Attributes object defined in [RFC5420]: one flag for communication of non-PHP behavior and one flag to indicate that the binding of the LSP to an application and a payload identifier (Payload ID) needs to be learned via an out-of-band mapping mechanism. As there is one-to-one correspondence between bits in the Attribute Flags TLV and the Record Route Object (RRO) Attributes subobject, corresponding flags to be carried in the RRO Attributes subobject are also defined.
本文档在[RFC5420]中定义的LSP Attributes对象的Attributes flags TLV中定义了两个新标志：一个标志用于非PHP行为的通信，另一个标志用于指示需要通过带外映射机制学习LSP与应用程序和有效负载标识符（有效负载ID）的绑定。由于属性标志TLV和记录路由对象（RRO）属性子对象中的位之间存在一对一的对应关系，因此还定义了要在RRO属性子对象中携带的对应标志。
The procedures described in this document are equally applicable for point-to-point (P2P) and P2MP LSPs. Specification of the OOB communication mechanism(s) is beyond the scope of this document.
本文件中描述的程序同样适用于点对点（P2P）和P2MP LSP。OOB通信机制的规范超出了本文件的范围。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section describes the signaling extensions required to address the above-mentioned requirements.
本节描述了满足上述要求所需的信令扩展。
In order to request non-PHP behavior for an RSVP-TE LSP, this document defines a new flag in the Attributes Flags TLV of the LSP Attributes object defined in [RFC5420]:
为了请求RSVP-TE LSP的非PHP行为，本文档在[RFC5420]中定义的LSP Attributes对象的Attributes Flags TLV中定义了一个新标志：
Bit Number 7: Non-PHP behavior flag
第7位：非PHP行为标志
In order to indicate to the ingress LSR that the egress LSR recognizes the "Non-PHP behavior flag", the same bit is used in the Flags field of the Record Route Object (RRO) Attributes subobject.
为了向入口LSR指示出口LSR识别“非PHP行为标志”，在记录路由对象（RRO）属性子对象的标志字段中使用相同的位。
An ingress LSR sets the "Non-PHP behavior flag" to signal that the egress LSRs SHOULD assign a non-NULL label for the LSP being signaled. This flag MUST NOT be modified by any other LSRs in the network. LSRs other than the egress LSRs SHOULD ignore this flag.
入口LSR设置“非PHP行为标志”以表示出口LSR应为正在发送信号的LSP分配非空标签。网络中的任何其他LSR不得修改此标志。出口LSR以外的LSR应忽略此标志。
If an egress LSR receiving the Path message supports the LSP Attributes object and the Attributes Flags TLV and also recognizes the "Non-PHP behavior flag", it MUST allocate a non-NULL local label. The egress LSR MUST also set the "Non-PHP behavior flag" in the Flags field of the RRO Attributes subobject.
如果接收路径消息的出口LSR支持LSP Attributes对象和Attributes Flags TLV，并且还识别“非PHP行为标志”，则它必须分配一个非空的本地标签。出口LSR还必须在RRO属性子对象的标志字段中设置“非PHP行为标志”。
If the egress LSR
如果出口是LSR
- supports the LSP Attributes object but does not recognize the Attributes Flags TLV; or
- 支持LSP Attributes对象，但不识别属性标志TLV；或
- supports the LSP Attributes object and recognizes the Attributes Flags TLV, but does not recognize the "Non-PHP behavior flag";
- 支持LSP Attributes对象并识别属性标志TLV，但不识别“非PHP行为标志”；
then it silently ignores the request according to the processing rules of [RFC5420].
然后根据[RFC5420]的处理规则，它将静默地忽略该请求。
An ingress LSR requesting non-PHP behavior SHOULD examine the "Non-PHP behavior flag" in the Flags field of the RRO Attributes subobject and MAY send a Path Tear to the egress, which has not set the "Non-PHP behavior flag". An ingress LSR requesting non-PHP behavior MAY also examine the label value corresponding to the egress LSR(s) in the RRO and MAY send a Path Tear to the egress, which assigns a NULL label value.
请求非PHP行为的入口LSR应检查RRO Attributes子对象的Flags字段中的“非PHP行为标志”，并可能向未设置“非PHP行为标志”的出口发送路径撕裂。请求非PHP行为的入口LSR还可以检查与RRO中的出口LSR相对应的标签值，并可以向出口发送路径撕裂，从而分配空标签值。
When signaling a P2MP LSP, a source node may wish to solicit an individual response to the "Non-PHP behavior flag" from the leaf nodes. Given the constraints on how the LSP Attributes may be carried in Path and Resv messages according to [RFC5420], in this situation, the source node MUST use a separate Path message for each leaf in networks where [RFC6510] is not supported. In networks with [RFC6510] deployed, either a single leaf per Path message or multiple leaves per Path message MAY be used by the source node.
当发送P2MP LSP信号时，源节点可能希望从叶节点请求对“非PHP行为标志”的单独响应。根据[RFC5420]，给定如何在Path和Resv消息中携带LSP属性的约束，在这种情况下，源节点必须为不支持[RFC6510]的网络中的每个叶使用单独的路径消息。在部署了[RFC6510]的网络中，源节点可以使用每个路径一个叶子消息或每个路径多个叶子消息。
This document defines a single flag to indicate that the normal binding mechanism of an RSVP session is overridden. The actual out-of-band mappings are beyond the scope of this document. The flag is carried in the Attributes Flags TLV of the LSP Attributes object defined in [RFC5420] and is defined as follows:
本文档定义了一个标志，指示RSVP会话的正常绑定机制被覆盖。实际带外映射超出了本文档的范围。该标志携带在[RFC5420]中定义的LSP Attributes对象的Attributes Flags TLV中，定义如下：
Bit Number 8: OOB mapping flag
第8位：OOB映射标志
In order to indicate to the ingress LSR that the egress LSR recognizes the "OOB mapping flag", the following same bit is used in the Flags field of the Record Route object (RRO) Attributes subobject.
为了向入口LSR指示出口LSR识别“OOB映射标志”，在记录路由对象（RRO）属性子对象的标志字段中使用以下相同的位。
An ingress LSR sets the "OOB mapping flag" to signal the egress LSR that the binding of RSVP-TE LSP to an application and a payload identifier is being signaled out-of-band. This flag MUST NOT be modified by any other LSRs in the network. LSRs other than the egress LSRs SHOULD ignore this flag.
入口LSR设置“OOB映射标志”以向出口LSR发送信号，表示RSVP-TE LSP与应用程序和有效负载标识符的绑定正在带外发送信号。网络中的任何其他LSR不得修改此标志。出口LSR以外的LSR应忽略此标志。
When an egress LSR that supports the "OOB mapping flag" receives a Path message with that flag set, the egress LSR MUST set the "OOB mapping flag" in the Flags field of the RRO Attributes subobject. The rest of the RSVP signaling proceeds as normal. However, the LSR MUST have received the OOB mapping before accepting traffic on the LSP. This implies that the egress LSR MUST NOT set up forwarding state for the LSP before it receives the OOB mapping.
当支持“OOB映射标志”的出口LSR接收到设置了该标志的路径消息时，出口LSR必须在RRO属性子对象的标志字段中设置“OOB映射标志”。剩余的RSVP信号正常进行。但是，LSR必须在接受LSP上的流量之前接收OOB映射。这意味着出口LSR在接收OOB映射之前不得为LSP设置转发状态。
Note that the payload information SHOULD be supplied by the OOB mapping. If the egress LSR receives the payload information from OOB mapping, then the LSR MUST ignore the L3PID (Layer 3 Protocol ID) in the Label Request Object [RFC3209].
注意，有效负载信息应该由OOB映射提供。如果出口LSR从OOB映射接收有效负载信息，则LSR必须忽略标签请求对象[RFC3209]中的L3PID（第3层协议ID）。
If the egress LSR
如果出口是LSR
- supports the LSP Attributes object but does not recognize the Attributes Flags TLV; or
- 支持LSP Attributes对象，但不识别属性标志TLV；或
- supports the LSP Attributes object and recognizes the Attributes Flags TLV, but does not recognize the "OOB mapping flag";
- 支持LSP Attributes对象并识别属性标志TLV，但不识别“OOB映射标志”；
then it silently ignores the request according to the processing rules of [RFC5420].
然后根据[RFC5420]的处理规则，它将静默地忽略该请求。
An ingress LSR requesting OOB mapping SHOULD examine the "OOB mapping flag" in the Flags field of the RRO Attributes subobject and MAY send a Path Tear to the egress, which has not set the "OOB mapping flag".
请求OOB映射的入口LSR应检查RRO属性子对象的“标志”字段中的“OOB映射标志”，并可向未设置“OOB映射标志”的出口发送路径撕裂。
When signaling a P2MP LSP, a source node may wish to solicit an individual response to the "OOB mapping flag" from the leaf nodes. Given the constraints on how the LSP Attributes object may be carried in Path and Resv messages according to [RFC5420], in this situation, the source node MUST use a separate Path message for each leaf in networks where [RFC6510] is not supported. In networks with [RFC6510] deployed, either a single leaf per Path message or multiple leaves per Path message MAY be used by the source node.
当发信号通知P2MP LSP时，源节点可能希望从叶节点请求对“OOB映射标志”的单独响应。根据[RFC5420]，给定关于如何在Path和Resv消息中携带LSP属性对象的约束，在这种情况下，源节点必须为不支持[RFC6510]的网络中的每个叶使用单独的路径消息。在部署了[RFC6510]的网络中，源节点可以使用每个路径一个叶子消息或每个路径多个叶子消息。
In deploying applications where the egress LSR receives the binding of the RSVP-TE LSP to an application and a payload identifier using an OOB mechanism, it is important to recognize that the OOB mapping is sent asynchronously with respect to the signaling of RSVP-TE LSP. The egress LSR only installs forwarding state for the LSP after it receives the OOB mapping. In deploying applications using an OOB mechanism, an ingress LSR may need to know when the egress is properly set up for forwarding (i.e., has received the OOB mapping). How the ingress LSR determines that the LSR is properly set up for forwarding at the egress LSR is beyond the scope of this document. Nonetheless, if the OOB mapping is not received by the egress LSR within a reasonable time, the procedure defined in Section 2.4 to tear down the LSP is followed.
在部署应用程序时，出口LSR使用OOB机制接收RSVP-TE LSP与应用程序和有效负载标识符的绑定，必须认识到OOB映射是相对于RSVP-TE LSP的信令异步发送的。出口LSR仅在收到OOB映射后为LSP安装转发状态。在使用OOB机制部署应用程序时，入口LSR可能需要知道出口何时被正确设置为转发（即，已接收到OOB映射）。入口LSR如何确定LSR已正确设置以在出口LSR处转发超出了本文档的范围。尽管如此，如果出口LSR未在合理时间内收到OOB映射，则遵循第2.4节中定义的拆除LSP的程序。
The "Non-PHP behavior flag" and "OOB mapping flag" can appear and be processed independently of each other. However, as mentioned earlier, in the context of the applications discussed in this document, OOB mapping requires non-PHP behavior. An ingress LSR requesting the OOB mapping MAY also set the "Non-PHP behavior flag" in the LSP Attributes object in the Path message.
“非PHP行为标志”和“OOB映射标志”可以独立显示和处理。但是，正如前面提到的，在本文讨论的应用程序上下文中，OOB映射需要非PHP行为。请求OOB映射的入口LSR也可以在路径消息的LSP属性对象中设置“非PHP行为标志”。
RSVP-TE signaling completion and the OOB mapping information reception happen asynchronously at the egress. As mentioned in Section 2.2, egress waits for the OOB mapping before accepting traffic on the LSP. Nonetheless, MPLS Operations, Administration, and Maintenance (OAM) mechanisms, e.g., LSP ping and traceroute, as defined in [RFC4379] and [RFC6425], are expected to work independently of OOB mapping learning process.
RSVP-TE信令完成和OOB映射信息接收在出口异步发生。如第2.2节所述，出口在接受LSP上的流量之前等待OOB映射。尽管如此，[RFC4379]和[RFC6425]中定义的MPLS操作、管理和维护（OAM）机制，如LSP ping和traceroute，预计将独立于OOB映射学习过程工作。
In order to avoid unnecessary use of the resources and possible black-holing of traffic, an egress LSR MAY send a Path Error message if the OOB mapping information is not received within a reasonable time. This Path Error message SHOULD include the error code/sub-code "Notify Error / no OOB mapping received" for all affected LSPs. If a notify request was included when the LSP was initially set up, a
为了避免不必要地使用资源和可能的通信量黑洞，如果在合理时间内没有接收到OOB映射信息，则出口LSR可以发送路径错误消息。此路径错误消息应包括所有受影响LSP的错误代码/子代码“通知错误/未收到OOB映射”。如果初始设置LSP时包含通知请求，则
Notify message (as defined in [RFC3473]) MAY also be used for delivery of this information to the ingress LSR. An egress LSR MAY implement a cleanup timer for this purpose. The time-out value is a local decision at the egress, with a RECOMMENDED default value of 60 seconds.
通知消息（如[RFC3473]中所定义）也可用于将该信息传递给入口LSR。出于此目的，出口LSR可实施清理计时器。超时值是出口处的本地决定，建议默认值为60秒。
The addition of non-PHP behavior adds a variety of attacks on the label assigned by the egress node. As change in the value of the egress label reported in the RRO can cause the LSP to be torn down, additional security considerations for protecting labels assigned by the egress node are required. Security mechanisms as identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875] can be used for this purpose. This document does not introduce any additional security issues above those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875].
非PHP行为的添加增加了对出口节点指定的标签的各种攻击。由于在RRO中报告的出口标签的值的变化可能导致LSP被拆除，因此需要额外的安全注意事项来保护出口节点分配的标签。[RFC5920]、[RFC2205]、[RFC3209]、[RFC3473]、[RFC5420]和[RFC4875]中确定的安全机制可用于此目的。本文件不介绍[RFC5920]、[RFC2205]、[RFC3209]、[RFC3473]、[RFC5420]和[RFC4875]中确定的任何其他安全问题。
The following changes to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Parameters registry are required.
需要对资源预留协议-流量工程（RSVP-TE）参数注册表进行以下更改。
The following new flags are defined for the Attributes Flags TLV in the LSP Attributes object.
为LSP Attributes对象中的属性标志TLV定义了以下新标志。
o Non-PHP behavior flag:
o 非PHP行为标志：
This flag is used in the Attributes Flags TLV in a Path message. The flag has a corresponding new flag to be used in the RRO Attributes subobject. As per [RFC5420], the bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This flag is not allowed in the Attributes Flags TLV in a Resv message. Specifically, attributes of this flag are as follows:
此标志用于路径消息中的属性标志TLV。该标志具有相应的新标志，将在“RRO属性”子对象中使用。根据[RFC5420]，属性标志TLV和RRO属性子对象中的位编号相同。也就是说，相同的属性由两个位置的相同位表示。Resv消息中的属性标志TLV中不允许使用此标志。具体而言，此标志的属性如下所示：
- Bit Number: 7
- 位号：7
- Attribute flag carried in Path message: Yes
- 路径消息中携带的属性标志：是
- Attribute flag carried in Resv message: No
- Resv消息中携带的属性标志：否
- Attribute flag carried in RRO message: Yes
- RRO消息中携带的属性标志：是
o OOB mapping flag:
o OOB映射标志：
This flag is used in the Attributes Flags TLV in a Path message. The flag has a corresponding new flag to be used in the RRO Attributes subobject. As per [RFC5420], the bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This flag is not allowed in the Attributes Flags TLV in a Resv message. Specifically, attributes of this flag are as follows:
此标志用于路径消息中的属性标志TLV。该标志具有相应的新标志，将在“RRO属性”子对象中使用。根据[RFC5420]，属性标志TLV和RRO属性子对象中的位编号相同。也就是说，相同的属性由两个位置的相同位表示。Resv消息中的属性标志TLV中不允许使用此标志。具体而言，此标志的属性如下所示：
- Bit Number: 8
- 位号：8
- Attribute flag carried in Path message: Yes
- 路径消息中携带的属性标志：是
- Attribute flag carried in Resv message: No
- Resv消息中携带的属性标志：否
- Attribute flag carried in RRO message: Yes
- RRO消息中携带的属性标志：是
For Error Code = 25 "Notify Error" (see [RFC3209]), the following sub-code is defined.
对于错误代码=25“通知错误”（参见[RFC3209]），定义了以下子代码。
Sub-code Value
-------- -----
Sub-code Value
-------- -----
No OOB mapping received 12
没有收到OOB映射12
The authors would like to thank Yakov Rekhter for his suggestions on this document.
作者感谢Yakov Rekhter对本文件的建议。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[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月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayyangarps，“使用资源预留协议流量工程（RSVP-TE）建立MPLS LSP的属性编码”，RFC 5420，2009年2月。
[RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects", RFC 6510, February 2012.
[RFC6510]Berger，L.和G.Swallow，“标签交换路径（LSP）属性对象的资源预留协议（RSVP）消息格式”，RFC 65102012年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，2007年1月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425]Saxena，S.，Ed.，Swallow，G.，Ali，Z.，Farrel，A.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 64252011年11月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC6513]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，2012年2月。
Authors' Addresses
作者地址
Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com
Zafar Ali Cisco Systems，Inc.电子邮件：zali@cisco.com
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
George Swallow Cisco Systems，Inc.电子邮件：swallow@cisco.com
Rahul Aggarwal Juniper Networks EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Juniper Networks电子邮件：raggarwa_1@yahoo.com