Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7551 Huawei
Category: Standards Track R. Jing
ISSN: 2070-1721 China Telecom
R. Gandhi, Ed.
Cisco Systems
May 2015
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7551 Huawei
Category: Standards Track R. Jing
ISSN: 2070-1721 China Telecom
R. Gandhi, Ed.
Cisco Systems
May 2015
RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)
相关双向标签交换路径（LSP）的RSVP-TE扩展
Abstract
摘要
This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.
本文档描述了将两个点对点单向标签交换路径（LSP）绑定到相关双向LSP的资源预留协议（RSVP）扩展。通过定义用于关联和扩展关联对象的新关联类型来实现关联。其中一种类型支持在两侧独立配置关联的双向LSP，而另一种类型支持单边配置。还定义了REVERSE_LSP对象，以使单个端点能够触发反向LSP的创建，并在单边供应情况下指定反向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/rfc7551.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7551.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
2.1. Key Word Definitions .......................................5
2.2. Reverse Unidirectional LSPs ................................5
2.3. Message Formats ............................................5
3. Overview ........................................................6
3.1. Provisioning Model Overview ................................6
3.1.1. Single-Sided Provisioning ...........................6
3.1.2. Double-Sided Provisioning ...........................6
3.2. Association Signaling Overview .............................6
3.2.1. Single-Sided Provisioning ...........................7
3.2.2. Double-Sided Provisioning ...........................7
3.3. Asymmetric Bandwidth Signaling Overview ....................8
3.3.1. Single-Sided Provisioning ...........................8
3.3.2. Double-Sided Provisioning ...........................8
3.4. Recovery LSP Overview ......................................8
4. Message and Object Definitions ..................................9
4.1. RSVP Message Formats .......................................9
4.2. ASSOCIATION Object .........................................9
4.3. Extended ASSOCIATION Object ...............................10
4.4. REVERSE_LSP Object Definition .............................11
4.4.1. REVERSE_LSP Object Format ..........................11
4.4.2. REVERSE_LSP Subobjects .............................11
5. Processing Rules ...............................................12
5.1. Rules for ASSOCIATION Object ..............................12
5.1.1. Compatibility for ASSOCIATION Object ...............14
5.2. Rules for REVERSE_LSP Object ..............................14
5.2.1. Compatibility for REVERSE_LSP Object ...............16
6. IANA Considerations ............................................16
6.1. Association Types .........................................16
6.2. REVERSE_LSP Object ........................................16
6.3. Reverse LSP Failure PathErr Sub-code ......................17
7. Security Considerations ........................................17
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................19
Acknowledgements ..................................................20
Contributors ......................................................20
Authors' Addresses ................................................20
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
2.1. Key Word Definitions .......................................5
2.2. Reverse Unidirectional LSPs ................................5
2.3. Message Formats ............................................5
3. Overview ........................................................6
3.1. Provisioning Model Overview ................................6
3.1.1. Single-Sided Provisioning ...........................6
3.1.2. Double-Sided Provisioning ...........................6
3.2. Association Signaling Overview .............................6
3.2.1. Single-Sided Provisioning ...........................7
3.2.2. Double-Sided Provisioning ...........................7
3.3. Asymmetric Bandwidth Signaling Overview ....................8
3.3.1. Single-Sided Provisioning ...........................8
3.3.2. Double-Sided Provisioning ...........................8
3.4. Recovery LSP Overview ......................................8
4. Message and Object Definitions ..................................9
4.1. RSVP Message Formats .......................................9
4.2. ASSOCIATION Object .........................................9
4.3. Extended ASSOCIATION Object ...............................10
4.4. REVERSE_LSP Object Definition .............................11
4.4.1. REVERSE_LSP Object Format ..........................11
4.4.2. REVERSE_LSP Subobjects .............................11
5. Processing Rules ...............................................12
5.1. Rules for ASSOCIATION Object ..............................12
5.1.1. Compatibility for ASSOCIATION Object ...............14
5.2. Rules for REVERSE_LSP Object ..............................14
5.2.1. Compatibility for REVERSE_LSP Object ...............16
6. IANA Considerations ............................................16
6.1. Association Types .........................................16
6.2. REVERSE_LSP Object ........................................16
6.3. Reverse LSP Failure PathErr Sub-code ......................17
7. Security Considerations ........................................17
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................19
Acknowledgements ..................................................20
Contributors ......................................................20
Authors' Addresses ................................................20
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] specifies that MPLS-TP MUST support associated bidirectional point-to-point Label Switched Paths (LSPs). These requirements are given in Section 2.1 ("General Requirements") of that document and are partially rephrased below:
MPLS传输配置文件（MPLS-TP）要求文件[RFC5654]规定，MPLS-TP必须支持相关的双向点到点标签交换路径（LSP）。这些要求在该文件的第2.1节（“一般要求”）中给出，并在以下部分重新表述：
7. MPLS-TP MUST support associated bidirectional point-to-point LSPs.
7. MPLS-TP必须支持相关的双向点到点LSP。
11. The end points of an associated bidirectional LSP MUST be aware of the pairing relationship of the forward and reverse LSPs used to support the bidirectional service.
11. 相关联的双向LSP的端点必须知道用于支持双向服务的正向和反向LSP的配对关系。
12. Nodes on the LSP of an associated bidirectional LSP where both the forward and backward directions transit the same node in the same (sub)layer as the LSP SHOULD be aware of the pairing relationship of the forward and the backward directions of the LSP.
12. 相关联的双向LSP的LSP上的节点，其中前向和后向在与LSP相同的（子）层中通过同一节点，应当知道LSP的前向和后向的配对关系。
50. The MPLS-TP control plane MUST support establishing associated bidirectional P2P LSP including configuration of protection functions and any associated maintenance functions.
50. MPLS-TP控制平面必须支持建立相关联的双向P2P LSP，包括配置保护功能和任何相关联的维护功能。
The above requirements are also repeated in [RFC6373].
[RFC6373]中也重复了上述要求。
Furthermore, an associated bidirectional LSP is also useful for protection-switching for Operations, Administration, and Maintenance (OAM) messages that require a return path.
此外，相关联的双向LSP对于需要返回路径的操作、管理和维护（OAM）消息的保护切换也是有用的。
A variety of applications, such as Internet services and the return paths of OAM messages, exist and may have different upstream and downstream bandwidth requirements. [RFC5654] specifies an asymmetric bandwidth requirement in Section 2.1 ("General Requirements"), and it is repeated below:
存在各种各样的应用，例如因特网服务和OAM消息的返回路径，并且可能具有不同的上游和下游带宽需求。[RFC5654]在第2.1节（“一般要求”）中规定了非对称带宽要求，如下所述：
14. MPLS-TP MUST support bidirectional LSPs with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions.
14. MPLS-TP必须支持具有非对称带宽要求的双向LSP，即前向和后向之间的保留带宽量不同。
The approach for supporting asymmetric bandwidth co-routed bidirectional LSPs is defined in [RFC6387].
[RFC6387]中定义了支持非对称带宽共路由双向LSP的方法。
The method of association and the corresponding Resource Reservation Protocol (RSVP) ASSOCIATION Object are defined in [RFC4872], [RFC4873], and [RFC6689]. In that context, the ASSOCIATION Object is used to associate a recovery LSP with the LSP it is protecting. This
[RFC4872]、[RFC4873]和[RFC6689]中定义了关联方法和相应的资源预留协议（RSVP）关联对象。在该上下文中，关联对象用于将恢复LSP与其保护的LSP关联起来。这
object also has broader applicability as a mechanism to associate RSVP states. [RFC6780] defines the Extended ASSOCIATION Objects that can be more generally applied for this purpose. This document uses the term "(Extended) ASSOCIATION Objects" to refer collectively to the ASSOCIATION Objects defined in [RFC4872] and the Extended ASSOCIATION Objects defined in [RFC6780].
对象作为关联RSVP状态的机制也具有更广泛的适用性。[RFC6780]定义了扩展关联对象，这些对象可以更普遍地用于此目的。本文档使用术语“（扩展）关联对象”来统称[RFC4872]中定义的关联对象和[RFC6780]中定义的扩展关联对象。
This document specifies mechanisms for binding two reverse unidirectional LSPs into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in (Extended) ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case. For example, the REVERSE_LSP Object allow asymmetric upstream and downstream bandwidths for the associated bidirectional LSP.
本文档指定了将两个反向单向LSP绑定到相关双向LSP的机制。通过定义用于（扩展）关联对象的新关联类型来实现关联。其中一种类型支持相关双向LSP的独立配置，而另一种类型支持单边配置。还定义了REVERSE_LSP对象，以使单个端点能够触发反向LSP的创建，并在单边供应情况下指定反向LSP的参数。例如，反向LSP对象允许相关联的双向LSP的不对称上游和下游带宽。
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]中所述进行解释。
Two reverse unidirectional LSPs are setup in the opposite directions between a pair of source and destination nodes to form an associated bidirectional LSP. A reverse unidirectional LSP originates on the same node where the forward unidirectional LSP terminates, and it terminates on the same node where the forward unidirectional LSP originates.
在一对源节点和目的节点之间的相反方向上设置两个反向单向LSP，以形成相关联的双向LSP。反向单向LSP在前向单向LSP终止的同一节点上发起，并在前向单向LSP发起的同一节点上终止。
This document uses the Routing Backus-Naur Form (RBNF) to define message formats as defined in [RFC5511].
本文档使用路由Backus Naur表单（RBNF）定义[RFC5511]中定义的消息格式。
This section provides an overview and definition of the models for provisioning associated bidirectional LSPs.
本节概述和定义了用于提供相关双向LSP的模型。
The associated bidirectional LSP's forward and reverse unidirectional LSPs are established, monitored, and protected independently as specified by [RFC5654]. Configuration information regarding the LSPs can be provided at one or both endpoints of the associated bidirectional LSP. Depending on the method chosen, there are two models of creating an associated bidirectional LSP -- single-sided provisioning and double-sided provisioning.
按照[RFC5654]的规定，独立建立、监控和保护相关双向LSP的正向和反向单向LSP。可以在相关联的双向LSP的一个或两个端点处提供关于LSP的配置信息。根据所选择的方法，有两种创建相关双向LSP的模型——单边资源调配和双边资源调配。
For the single-sided provisioning, the Traffic Engineering (TE) tunnel is configured only on one endpoint. An LSP for this tunnel is initiated by the initiating endpoint with the (Extended) ASSOCIATION and REVERSE_LSP Objects inserted in the Path message. The other endpoint then creates the corresponding reverse TE tunnel and signals the reverse LSP in response using information from the REVERSE_LSP Object and other objects present in the received Path message.
对于单边供应，只在一个端点上配置流量工程（TE）隧道。此隧道的LSP由在路径消息中插入（扩展）关联和反向\u LSP对象的发起端点发起。然后，另一个端点创建相应的反向TE隧道，并使用来自反向LSP对象和接收到的路径消息中存在的其他对象的信息向反向LSP发送响应信号。
For the double-sided provisioning, two unidirectional TE tunnels are configured independently, one on each endpoint. The LSPs for the tunnels are signaled with (Extended) ASSOCIATION Objects inserted in the Path message by both endpoints to indicate that the two LSPs are to be associated to form a bidirectional LSP.
对于双面供应，两个单向TE隧道是独立配置的，每个端点上一个。隧道的LSP通过两个端点在路径消息中插入的（扩展的）关联对象发出信号，以指示两个LSP将被关联以形成双向LSP。
This section provides an overview of the association signaling methods for the associated bidirectional LSPs.
本节概述了关联双向LSP的关联信令方法。
Three scenarios exist for binding two unidirectional LSPs together to form an associated bidirectional LSP. These are:
将两个单向LSP绑定在一起以形成相关联的双向LSP存在三种情况。这些是：
1) Neither unidirectional LSP exists, and both must be established.
1) 既不存在单向LSP，也必须建立两者。
2) Both unidirectional LSPs exist, but the association must be established.
2) 两个单向LSP都存在，但必须建立关联。
3) One LSP exists, but the reverse associated LSP must be established.
3) 存在一个LSP，但必须建立反向关联的LSP。
The following sections describe the applicable provisioning models for each of these scenarios.
以下各节描述了适用于每种场景的资源调配模型。
Path Computation Element (PCE)-based approaches [RFC4655] may be used for path computation of an associated bidirectional LSP. However, these approaches are outside the scope of this document.
基于路径计算元素（PCE）的方法[RFC4655]可用于相关联的双向LSP的路径计算。但是，这些方法不在本文件的范围内。
Consider the topology described in Figure 1. LSP1 from node A to B, takes the path A,D,B, and LSP2 from node B to A takes the path B,D,C,A. These two LSPs, once established and associated, form an associated bidirectional LSP between nodes A and B.
考虑图1中描述的拓扑结构。从节点A到B的LSP1采用路径A、D、B，从节点B到A的LSP2采用路径B、D、C、A。这两个LSP一旦建立并关联，就会在节点A和B之间形成关联的双向LSP。
LSP1 -->
A-------D-------B
\ / <-- LSP2
\ /
\ /
C
LSP1 -->
A-------D-------B
\ / <-- LSP2
\ /
\ /
C
Figure 1: An Example of Associated Bidirectional LSP
图1：关联双向LSP的示例
For the single-sided provisioning model, creation of reverse LSP1 shown in Figure 1 is triggered by LSP2, or creation of reverse LSP2 is triggered by LSP1. When creation of reverse LSP2 is triggered by LSP1, LSP1 is provisioned first (or refreshed, if LSP1 already exists) at node A. LSP1 is then signaled with an (Extended) ASSOCIATION, and REVERSE_LSP Objects are inserted in the Path message. The Association Type indicates single-sided provisioning. Upon receiving this Path message for LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION Object inserted in LSP2's Path message is the same as that received in LSP1's Path message.
对于单边供应模型，图1所示的反向LSP1的创建由LSP2触发，或者反向LSP2的创建由LSP1触发。当LSP1触发反向LSP2的创建时，首先在节点A设置LSP1（或刷新，如果LSP1已经存在）。然后向LSP1发送（扩展）关联的信号，并在路径消息中插入反向LSP对象。关联类型表示单边设置。在接收到LSP1的该路径消息后，节点B建立反向LSP2。插入LSP2路径消息中的（扩展）关联对象与在LSP1路径消息中接收的对象相同。
A similar procedure is used if LSP2 is provisioned first at node B, and the creation of reverse LSP1 at node A is triggered by LSP2. In both scenarios, the two unidirectional LSPs are bound together to form an associated bidirectional LSP based on identical (Extended) ASSOCIATION Objects in the two LSPs' Path messages.
如果首先在节点B处供应LSP2，并且由LSP2触发在节点A处创建反向LSP1，则使用类似的过程。在这两种情况下，两个单向LSP绑定在一起，以基于两个LSP路径消息中相同（扩展）的关联对象形成关联的双向LSP。
For the double-sided provisioning model, both LSP1 and LSP2 shown in Figure 1 are signaled independently with (Extended) ASSOCIATION Objects inserted in the Path messages, in which the Association Type indicating double-sided provisioning is included. In this case, the two unidirectional LSPs are bound together to form an associated bidirectional LSP based on identical (Extended) ASSOCIATION Objects
对于双边供应模型，图1中所示的LSP1和LSP2都使用插入路径消息中的（扩展的）关联对象独立发出信号，其中包括指示双边供应的关联类型。在这种情况下，两个单向LSP绑定在一起，以形成基于相同（扩展）关联对象的关联双向LSP
in the two LSPs' Path messages. In all three scenarios described in Section 3.2, the LSPs to be selected for the association are provisioned by the management action applied at both endpoints.
在两个LSP的路径消息中。在第3.2节中描述的所有三种场景中，要为关联选择的LSP由应用于两个端点的管理操作提供。
This section provides an overview of the methods for signaling asymmetric upstream and downstream bandwidths for the associated bidirectional LSPs.
本节概述了用于为相关联的双向lsp发送非对称上行和下行带宽的信令的方法。
A new REVERSE_LSP Object for use in the single-sided provisioning model is defined in this document, in Section 4.4. The REVERSE_LSP Object allows the initiating node of the single-sided provisioned LSP to trigger creation of the reverse LSP on the remote node. When the single-sided provisioning model is used, a SENDER_TSPEC Object can be added in the REVERSE_LSP Object as a subobject in the initiating LSP's Path message to specify a different bandwidth for the reverse LSP. As described in Section 4.4, addition of the REVERSE_LSP Object also allows the initiating node to control other aspects of the reverse LSP (such as its path) by including other objects in a REVERSE_LSP Object.
本文件第4.4节定义了用于单边供应模型的新反向LSP对象。反向LSP对象允许单边供应LSP的发起节点触发远程节点上反向LSP的创建。使用单边供应模型时，可以在反向LSP对象中添加发送方\u TSPEC对象，作为发起LSP路径消息中的子对象，以指定反向LSP的不同带宽。如第4.4节所述，添加反向LSP对象还允许发起节点通过在反向LSP对象中包含其他对象来控制反向LSP的其他方面（例如其路径）。
Consider again the topology described in Figure 1, where the creation of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the (Extended) ASSOCIATION Object with Association Type indicating single-sided provisioning and inserts a SENDER_TSPEC subobject for use by LSP2 in the REVERSE_LSP Object in the Path message. Node B then establishes the LSP2 in the reverse direction using the asymmetric bandwidth thus specified by LSP1 and allows node A to control the reverse LSP2.
再次考虑图1中描述的拓扑结构，其中由LSP1触发反向LSP2的创建。节点A向LSP1发送指示单边供应的关联类型为（扩展）关联对象的信号，并在路径消息的反向\u LSP对象中插入发送方\u TSPEC子对象供LSP2使用。然后，节点B使用LSP1如此指定的非对称带宽在反向上建立LSP2，并允许节点A控制反向LSP2。
When the double-sided provisioning model is used, the two unidirectional LSPs are established with separate bandwidths, which may or may not be identical. However, these LSPs are associated purely based on the identical contents of their (Extended) ASSOCIATION Objects.
当使用双面供应模型时，两个单向LSP使用不同的带宽建立，带宽可能相同，也可能不同。但是，这些LSP纯粹基于其（扩展）关联对象的相同内容进行关联。
Recovery of each unidirectional LSP forming the bidirectional LSP is independent [RFC5654] and is based on the parameters signaled in their respective RSVP Path messages.
形成双向LSP的每个单向LSP的恢复是独立的[RFC5654]，并且基于其各自RSVP路径消息中的信号参数。
Recovery LSP association is based on the identical content of the (Extended) ASSOCIATION Objects signaled in their Path messages during the initial LSP setup for both single-sided and double-sided provisioning. As defined in [RFC6780], multiple ASSOCIATION Objects may be present in the signaling of a single LSP.
恢复LSP关联基于（扩展）关联对象的相同内容，这些对象在初始LSP设置期间在其路径消息中发出信号，用于单边和双边资源调配。如[RFC6780]中所定义，在单个LSP的信令中可能存在多个关联对象。
This section presents the RSVP message-related formats as modified by this document. Unmodified RSVP message formats are not listed.
本节介绍本文件修改的RSVP消息相关格式。未修改的RSVP消息格式未列出。
The format of a Path message is as follows:
Path消息的格式如下所示：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <ASSOCIATION> ... ]
[ <REVERSE_LSP> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <ASSOCIATION> ... ]
[ <REVERSE_LSP> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the <sender descriptor> is not modified by this document.
本文档不修改<sender descriptor>的格式。
The ASSOCIATION Object is populated using the rules defined below for associating two reverse unidirectional LSPs to form an associated bidirectional LSP.
使用下面定义的规则填充关联对象，这些规则用于关联两个反向单向LSP以形成关联的双向LSP。
Association Types:
关联类型：
In order to bind two reverse unidirectional LSPs to be an associated bidirectional LSP, the Association Type MUST be set to indicate either single-sided or double-sided LSPs.
为了将两个反向单向LSP绑定为关联的双向LSP，必须将关联类型设置为指示单面或双面LSP。
The new Association Types are defined as follows:
新的关联类型定义如下：
Value Type
----- -----
3 Double-Sided Associated Bidirectional LSP (D)
4 Single-Sided Associated Bidirectional LSP (A)
Value Type
----- -----
3 Double-Sided Associated Bidirectional LSP (D)
4 Single-Sided Associated Bidirectional LSP (A)
Association ID:
关联ID:
For both single-sided and double-sided provisioning, Association ID MUST be set to a value assigned by the node that originates the association for the bidirectional LSP.
对于单边和双边供应，关联ID必须设置为发起双向LSP关联的节点分配的值。
Association Source:
协会资料来源：
Association Source MUST be set to an address selected by the node that originates the association for the bidirectional LSP. For example, this may be a management entity or, in the case of single-sided provisioning, an address assigned to the node that originates the LSP.
关联源必须设置为发起双向LSP关联的节点选择的地址。例如，这可以是管理实体，或者在单边供应的情况下，可以是分配给发起LSP的节点的地址。
The Extended ASSOCIATION Object is populated using the rules defined below for associating two reverse unidirectional LSPs to form a bidirectional LSP.
使用以下定义的规则填充扩展关联对象，这些规则用于关联两个反向单向LSP以形成双向LSP。
The Association Type, Association ID, and Association Source MUST be set as defined for the ASSOCIATION Object in Section 4.1.
关联类型、关联ID和关联源必须按照第4.1节中关联对象的定义进行设置。
Global Association Source:
全球协会资料来源：
For both single-sided and double-sided provisioning, Global Association Source, when used, MUST be set to the Global_ID [RFC6370] of the node that originates the association for the bidirectional LSP.
对于单边和双边供应，全局关联源在使用时必须设置为发起双向LSP关联的节点的全局_ID[RFC6370]。
Extended Association ID:
扩展关联ID:
For both single-sided and double-sided provisioning, Extended Association ID, when used, MUST be set to a value selected by the node that originates the association for the bidirectional LSP.
对于单边和双边供应，使用扩展关联ID时，必须将其设置为发起双向LSP关联的节点选择的值。
The REVERSE_LSP Object is carried in the Path message of a forward LSP to provide information to be used by the reverse LSP. The object also indicates that the LSP is the forward LSP of a single-sided associated bidirectional LSP.
反向LSP对象携带在前向LSP的路径消息中，以提供反向LSP使用的信息。该对象还指示LSP是单侧相关联的双向LSP的前向LSP。
The Object has the following format:
对象具有以下格式：
Class_Num = 203, C_Type = 1.
类别数量=203，类别类型=1。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects are used to override the default contents of a Path message of a reverse LSP; see Section 5.2. The contents of a REVERSE_LSP Object is zero or more variable-length subobjects that have the same format as RSVP Objects; see Section 3.1.2 of [RFC2205]. Any object that may be carried in a Path message MAY be carried in the REVERSE_LSP Object. Subobject ordering MUST follow any Path message Object ordering requirements.
子对象用于覆盖反向LSP路径消息的默认内容；见第5.2节。REVERSE_LSP对象的内容是零个或多个与RSVP对象具有相同格式的可变长度子对象；见[RFC2205]第3.1.2节。路径消息中可能携带的任何对象都可能携带在反向_LSP对象中。子对象排序必须遵循任何路径消息对象排序要求。
Examples of the Path message Objects that can be carried in the REVERSE_LSP Object are (but not limited to):
可在反向_LSP对象中携带的路径消息对象的示例包括（但不限于）：
- SENDER_TSPEC [RFC2205] - EXPLICIT_ROUTE Object (ERO) [RFC3209] - SESSION_ATTRIBUTE Object [RFC3209] - ADMIN_STATUS Object [RFC3473] - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] - PROTECTION Object [RFC3473] [RFC4872]
- 发送方_TSPEC[RFC2205]-显式_路由对象（ERO）[RFC3209]-会话_属性对象[RFC3209]-管理_状态对象[RFC3473]-LSP_所需_属性对象[RFC5420]-保护对象[RFC3473][RFC4872]
In general, the processing rules for the ASSOCIATION Object are as specified in [RFC4872], and those for the Extended ASSOCIATION Object are as specified in [RFC6780]. The following sections describe the rules for processing (Extended) ASSOCIATION Objects for both double-sided and single-sided associated bidirectional LSPs and REVERSE_LSP Objects for single-sided associated bidirectional LSPs.
通常，关联对象的处理规则如[RFC4872]所述，扩展关联对象的处理规则如[RFC6780]所述。以下各节描述了处理（扩展）双边关联双向LSP和单边关联双向LSP的关联对象以及单边关联双向LSP的反向关联LSP对象的规则。
This section defines the processing for the association of two unidirectional LSPs to form an associated bidirectional LSP. Such association is based on the use of an (Extended) ASSOCIATION Object.
本节定义了两个单向LSP的关联处理，以形成关联的双向LSP。这种关联基于（扩展的）关联对象的使用。
The procedures related to the actual identification of associations between LSPs based on (Extended) ASSOCIATION Objects are defined in [RFC6780]. [RFC6780] specifies that in the absence of rules for identifying the association that are specific to the Association Type, the included (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order for an association to exist. This document adds no specific rules for the new Association Types defined, and the identification of an LSP association therefore proceeds as specified in [RFC6780].
[RFC6780]中定义了与基于（扩展）关联对象的LSP之间关联的实际识别相关的程序。[RFC6780]规定，在没有特定于关联类型的关联识别规则的情况下，LSP中包含的（扩展的）关联对象必须相同才能存在关联。本文档未为定义的新关联类型添加任何特定规则，因此LSP关联的标识将按照[RFC6780]中的规定进行。
As described in [RFC6780], association of LSPs can be upstream or downstream initiated, as indicated by (Extended) ASSOCIATION Objects in Path or Resv Messages. The association of bidirectional LSPs is always upstream initiated; therefore, the Association Types defined in this document are only to be interpreted in Path Messages. These types SHOULD NOT be used in ASSOCIATION Objects carried in Resv messages and SHOULD be ignored if present.
如[RFC6780]所述，LSP的关联可以由上游或下游启动，如Path或Resv消息中的（扩展）关联对象所示。双向lsp的关联总是由上游发起的；因此，本文档中定义的关联类型只能在路径消息中进行解释。在Resv消息中携带的关联对象中不应使用这些类型，如果存在，则应忽略这些类型。
To indicate an associated bidirectional LSP, an ingress node MUST insert an (Extended) ASSOCIATION Object into the Path message of the unidirectional LSP that is part of the associated bidirectional LSP it initiates. If either Global Association Source or Extended Association Address is required, then an Extended ASSOCIATION Object [RFC6780] MUST be inserted in the Path message. Otherwise, an ASSOCIATION Object MAY be used. (Extended) ASSOCIATION Objects with both single-sided and double-sided Association Types MUST NOT be added or sent in the same Path message.
为了指示关联的双向LSP，入口节点必须将（扩展的）关联对象插入到单向LSP的路径消息中，该单向LSP是其发起的关联双向LSP的一部分。如果需要全局关联源或扩展关联地址，则必须在路径消息中插入扩展关联对象[RFC6780]。否则，可以使用关联对象。（扩展）不能在同一路径消息中添加或发送具有单面和双面关联类型的关联对象。
The ingress node MUST set the Association Type field in the (Extended) ASSOCIATION Object to "Single-Sided Associated Bidirectional LSP" when single-sided provisioning is used, and to "Double-Sided Associated Bidirectional LSP" when double-sided provisioning is used.
当使用单边供应时，入口节点必须将（扩展的）关联对象中的关联类型字段设置为“单边关联双向LSP”，当使用双边供应时，必须将其设置为“双边关联双向LSP”。
A transit node MAY identify the unidirectional LSPs of an associated bidirectional LSP based on (Extended) ASSOCIATION Objects, with the Association Type values defined in this document, carried in Path messages. Clearly, such associations are only possible when the LSPs transit the node. As mentioned above, such associations are made per the rules defined in [RFC6780].
传输节点可以基于路径消息中携带的（扩展的）关联对象（具有本文档中定义的关联类型值）来识别关联的双向LSP的单向LSP。显然，这种关联只有在LSP通过节点时才可能发生。如上所述，此类关联根据[RFC6780]中定义的规则进行。
Egress nodes that support the Association Types defined in this document identify the unidirectional LSPs of an associated bidirectional LSP based on (Extended) ASSOCIATION Objects carried in Path messages. Note that an ingress node will normally be the ingress for one of the unidirectional LSPs that make up an associated bidirectional LSP. When an egress node receives a Path message containing an (Extended) ASSOCIATION Object with one of the Association Types defined in this document, it MUST attempt to identify other LSPs (including ones for which it is an ingress node) with which the LSP being processed is associated. As defined above, such associations are made per the rules defined in [RFC6780]. An LSP not being associated at the time of signaling (for example, during rerouting or re-optimization) on an egress node is not necessarily considered an error condition.
支持本文档中定义的关联类型的出口节点基于路径消息中携带的（扩展的）关联对象识别关联的双向LSP的单向LSP。注意，入口节点通常是构成相关联的双向LSP的单向LSP之一的入口。当出口节点接收到包含（扩展）关联对象的Path消息，该对象具有本文档中定义的关联类型之一时，它必须尝试识别与正在处理的LSP关联的其他LSP（包括其作为入口节点的LSP）。如上所述，此类关联根据[RFC6780]中定义的规则进行。在出口节点上发信号时（例如，在重新路由或重新优化期间）不关联的LSP不一定被视为错误条件。
Associated bidirectional LSP teardown follows the standard procedures defined in [RFC3209] and [RFC3473] either without or with the administrative status. Generally, the teardown procedures of the unidirectional LSPs forming an associated bidirectional LSP are independent of each other, so it is possible that while one LSP follows graceful teardown with administrative status, the reverse LSP is torn down without administrative status (using PathTear/ResvTear/PathErr with state removal). See Section 5.2 for additional rules related to LSPs established using single-sided provisioning.
相关的双向LSP拆卸遵循[RFC3209]和[RFC3473]中定义的标准程序，无论是否具有管理状态。通常，形成相关联的双向LSP的单向LSP的拆卸过程彼此独立，因此，当一个LSP跟随具有管理状态的优雅拆卸时，反向LSP可能在没有管理状态的情况下被拆卸（使用具有状态移除的pathrear/ResvTear/PathErr）。有关使用单边供应建立的LSP的其他规则，请参见第5.2节。
When an LSP signaled with a Path message containing an (Extended) ASSOCIATION Object with an Association Type defined in this document is torn down, the processing node SHALL remove the binding of the LSP to any previously identified associated bidirectional LSP.
当使用包含（扩展的）关联对象的路径消息（包含本文档中定义的关联类型）发送信号的LSP被拆除时，处理节点应移除LSP与任何先前识别的关联双向LSP的绑定。
No additional processing is needed for Path messages with an (Extended) ASSOCIATION Object containing an Association Type field set to "Double-Sided Associated Bidirectional LSP".
对于包含关联类型字段设置为“双面关联双向LSP”的（扩展）关联对象的路径消息，不需要额外处理。
The ASSOCIATION Object has been defined in [RFC4872] and the Extended ASSOCIATION Object has been defined in [RFC6780], both with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification.
关联对象已在[RFC4872]中定义，扩展关联对象已在[RFC6780]中定义，两者的类号均为11BBBB格式，这确保了与非支持节点的兼容性。根据[RFC2205]，这样的节点将忽略对象，但在不修改的情况下转发它。
Operators wishing to use a function supported by a particular Association Type SHOULD ensure that the type is supported on any node that is expected to act on the association [RFC6780].
希望使用特定关联类型支持的函数的操作员应确保该类型在预期作用于该关联的任何节点上都受支持[RFC6780]。
An egress node that does not support the Association Types defined in this document is expected to return a PathErr with Error Code "Admission Control Failure" (1) [RFC2205] and Sub-code "Bad Association Type" (5) [RFC4872].
不支持本文档中定义的关联类型的出口节点将返回错误代码为“准入控制失败”（1）[RFC2205]和子代码为“错误关联类型”（5）[RFC4872]的PathErr。
LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by this document. The recovery mechanisms defined in [RFC4872] and [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but they use a different value for Association Type; multiple ASSOCIATION Objects can be present in the LSP Path message and can coexist with the procedures defined in this document.
[RFC4872]和[RFC4873]中定义的LSP恢复不受本文件影响。[RFC4872]和[RFC4873]中定义的恢复机制依赖于（扩展的）关联对象的使用，但它们对关联类型使用不同的值；LSP Path消息中可以存在多个关联对象，并且可以与本文档中定义的过程共存。
When a node initiates setup of an LSP using a Path message containing an ASSOCIATION or Extended ASSOCIATION Object, and the Association Type set to "Single-Sided Associated Bidirectional LSP", the Path message MUST carry the REVERSE_LSP Object to trigger creation of a reverse LSP on the egress node.
当节点使用包含关联或扩展关联对象且关联类型设置为“单边关联双向LSP”的路径消息启动LSP设置时，路径消息必须携带反向LSP对象，以触发出口节点上反向LSP的创建。
The REVERSE_LSP subobject MAY contain any of the objects that the initiating node desires to have included in the Path message for the associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be included in a REVERSE_LSP Object.
反向LSP子对象可以包含发起节点希望包含在关联反向LSP的路径消息中的任何对象。反向\u LSP对象不应包含在反向\u LSP对象中。
A transit node receiving a valid Path message containing a REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in the outgoing Path message.
接收到包含REVERSE_LSP对象的有效路径消息的传输节点必须转发在传出路径消息中未更改的REVERSE_LSP对象。
An egress node, upon receiving a Path message containing an REVERSE_LSP Object MUST verify that the Path message contains an ASSOCIATION or Extended ASSOCIATION Object with the Association Type set to "Single-Sided Associated Bidirectional LSP". If it does not, the Path message MUST NOT trigger a reverse LSP. This verification failure SHOULD NOT trigger any RSVP message but can be logged locally, and perhaps reported through network management mechanisms.
出口节点在接收到包含反向LSP对象的路径消息时，必须验证路径消息是否包含关联类型设置为“单边关联双向LSP”的关联或扩展关联对象。否则，Path消息不得触发反向LSP。此验证失败不应触发任何RSVP消息，但可在本地记录，并可能通过网络管理机制报告。
Once validated, the egress node MUST create an LSP in the reverse direction or reject the Path message. If the creation of a reverse LSP fails, the egress node MUST return a PathErr with Error Code "Admission Control Failure" (1) [RFC2205] and Sub-code "Reverse LSP Failure" (6) defined in this document. Note that normal Resv processing SHOULD NOT be impacted by the presence of an ASSOCIATION Object with an Association Type set to "Single-Sided Associated Bidirectional LSP".
验证后，出口节点必须在反向创建LSP或拒绝路径消息。如果反向LSP创建失败，出口节点必须返回一个PathErr，错误代码为“准入控制失败”（1）[RFC2205]，子代码为本文档中定义的“反向LSP失败”（6）。请注意，正常的Resv处理不应受到关联类型设置为“单边关联双向LSP”的关联对象的影响。
The egress node MUST use the subobjects contained in the REVERSE_LSP Object for initiating the reverse LSP. When a subobject is not present in the received REVERSE_LSP Object, the egress node SHOULD initiate the reverse LSP based on the information contained in the received Path message of the forward LSP as follows:
出口节点必须使用反向LSP对象中包含的子对象来启动反向LSP。当接收到的反向LSP对象中不存在子对象时，出口节点应根据前向LSP的接收路径消息中包含的信息启动反向LSP，如下所示：
o The egress node SHOULD copy the information from the received SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS, and PROTECTION Objects in the forward LSP Path message to form the Path message of the reverse LSP when the object is not present in the received REVERSE_LSP Object.
o 当接收到的反向LSP对象中不存在对象时，出口节点应从正向LSP路径消息中的接收会话属性、类类型、标签请求、关联、管理状态和保护对象复制信息，以形成反向LSP的路径消息。
o The IP address in the reverse LSP's SESSION Object SHOULD be set to the IP address carried in the received SENDER_TEMPLATE Object; and conversely, the IP address in the SENDER_TEMPLATE Object SHOULD be set to the IP address carried in the received SESSION Object. There are no additional requirements related to the IDs carried in the SESSION and SENDER_TEMPLATE Objects.
o 反向LSP会话对象中的IP地址应设置为接收的发送方\模板对象中携带的IP地址；相反，发送方\模板对象中的IP地址应设置为接收到的会话对象中携带的IP地址。会话和发送者模板对象中携带的ID没有其他相关要求。
o When the forward LSP Path message contains a RECORD_ROUTE Object, the egress node SHOULD include the received RECORD_ROUTE Object in the reverse LSP Path message. Local node information SHOULD also be recorded per standard Path message processing.
o 当正向LSP路径消息包含记录路由对象时，出口节点应在反向LSP路径消息中包含接收到的记录路由对象。还应按照标准路径消息处理记录本地节点信息。
o There are no specific requirements related to other objects.
o 没有与其他对象相关的特定要求。
The resulting Path message is used to create the reverse LSP. From this point on, standard Path message processing is used in processing the resulting Path message.
生成的路径消息用于创建反向LSP。从这一点开始，标准路径消息处理将用于处理生成的路径消息。
Note that the contents of a forward LSP, including a carried REVERSE_LSP Object, may change over the life of an LSP, and such changes MUST result in corresponding changes in the reverse LSP. In particular, any object or subobject that was copied during the creation of the initial reverse LSP's Path message MUST be copied when modified in the forward LSP, and a trigger Path message MUST be processed.
注意，前向LSP的内容，包括携带的反向LSP对象，可以在LSP的寿命期间改变，并且这种改变必须导致反向LSP中的相应改变。特别是，在正向LSP中修改时，必须复制在创建初始反向LSP路径消息期间复制的任何对象或子对象，并且必须处理触发路径消息。
The removal of the REVERSE_LSP Object in the received Path message SHOULD cause the egress node to tear down any previously established reverse LSP.
移除接收到的路径消息中的REVERSE_LSP对象应导致出口节点拆除任何先前建立的反向LSP。
When the egress node receives a PathTear message for the forward LSP or whenever the forward LSP is torn down, the node MUST remove the associated reverse LSP using standard PathTear message processing. Teardown of the reverse LSP for other reasons SHOULD NOT trigger removal of the initiating LSP, but it SHOULD result in the egress node sending a PathErr with Error Code "Admission Control Failure" (1) [RFC2205] and Sub-code "Reverse LSP Failure" (6) defined in this document.
当出口节点接收到前向LSP的PathTear消息时，或者当前向LSP被拆除时，该节点必须使用标准PathTear消息处理删除关联的反向LSP。出于其他原因拆除反向LSP不应触发移除启动LSP，但它应导致出口节点发送路径错误，错误代码为“准入控制失败”（1）[RFC2205]，子代码为“反向LSP失败”（6），在本文档中定义。
The REVERSE_LSP Object is defined with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification.
REVERSE_LSP对象是用11bbbb格式的类号定义的，这确保了与非支持节点的兼容性。根据[RFC2205]，这样的节点将忽略对象，但在不修改的情况下转发它。
IANA has registered values for the namespace defined in this document and summarized in this section.
IANA已注册了本文档中定义的名称空间的值，并在本节中进行了总结。
IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry (see <http://www.iana.org/assignments/gmpls-sig-parameters>). The "Association Type" subregistry is included in this registry.
IANA维护“通用多协议标签交换（GMPLS）信令参数”注册表（参见<http://www.iana.org/assignments/gmpls-sig-parameters>). “关联类型”子区域包含在此注册表中。
This registry has been updated by new Association Types for ASSOCIATION and Extended ASSOCIATION Objects defined in this document as follows:
此注册表已由本文档中定义的关联和扩展关联对象的新关联类型更新，如下所示：
Value Name Reference 3 Double-Sided Associated Bidirectional LSP (D) Section 4.2 4 Single-Sided Associated Bidirectional LSP (A) Section 4.2
值名称参考3双面关联双向LSP（D）第4.2节4单面关联双向LSP（A）第4.2节
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). The "Class Names, Class Numbers, and Class Types" subregistry is included in this registry.
IANA维护“资源预留协议（RSVP）参数”注册表（请参阅<http://www.iana.org/assignments/rsvp-parameters>). “类名、类号和类类型”子区域包含在此注册表中。
This registry has been extended for new Class Number (Class-Num) and Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 11bbbbbb range defined in this document as follows:
此注册表已扩展为本文档中定义的11bbbbbb范围内请求的RSVP REVERSE_LSP对象的新类编号（类Num）和类类型（C-Type），如下所示：
Class Number Class Name Reference 203 REVERSE_LSP Section 4.4
类别编号类别名称参考203第4.4节
o REVERSE_LSP : Class Type or C-type = 1
o 反向LSP：类别类型或C类型=1
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). The "Error Codes and Globally-Defined Error Value Sub-Codes" subregistry is included in this registry.
IANA维护“资源预留协议（RSVP）参数”注册表（请参阅<http://www.iana.org/assignments/rsvp-parameters>). “错误代码和全局定义的错误值子代码”子区域包含在此注册表中。
This registry has been extended for the new PathErr Sub-code defined in this document as follows:
此注册表已针对本文档中定义的新PathErr子代码进行了扩展，如下所示：
Error Code = 01: "Admission Control Failure" (see [RFC2205])
错误代码=01：“准入控制失败”（参见[RFC2205]）
o "Reverse LSP Failure" (6)
o “反向LSP故障”（6）
This document introduces two new Association Types for the (Extended) ASSOCIATION Object, Double-Sided Associated Bidirectional LSP and Single-Sided Associated Bidirectional LSP. These types, by themselves, introduce no additional information to signaling. Related security considerations are already covered for this in RFC 6780.
本文档介绍了（扩展）关联对象的两种新关联类型，双边关联双向LSP和单边关联双向LSP。这些类型本身不会为信令引入额外的信息。RFC 6780中已经包含了相关的安全注意事项。
The REVERSE_LSP Object is carried in the Path message of a forward LSP of the single-sided associated bidirectional LSP. It can carry parameters for the reverse LSP. This does allow for additional information to be conveyed, but this information is not fundamentally different from the information that is already carried in a bidirectional LSP message. The processing of such messages is already subject to local policy as well as security considerations discussions. For a general discussion on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920].
反向LSP对象被携带在单侧相关联的双向LSP的前向LSP的路径消息中。它可以携带反向LSP的参数。这确实允许传送额外的信息，但是该信息与双向LSP消息中已经携带的信息没有本质上的区别。此类消息的处理已经受到当地政策以及安全考虑因素讨论的制约。有关MPLS和GMPLS相关安全问题的一般性讨论，请参阅MPLS/GMPLS安全框架[RFC5920]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<http://www.rfc-editor.org/info/rfc2205>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, <http://www.rfc-editor.org/info/rfc4872>.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，DOI 10.17487/RFC4872，2007年5月<http://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <http://www.rfc-editor.org/info/rfc4873>.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，DOI 10.17487/RFC4873，2007年5月<http://www.rfc-editor.org/info/rfc4873>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <http://www.rfc-editor.org/info/rfc5511>.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，DOI 10.17487/RFC5511，2009年4月<http://www.rfc-editor.org/info/rfc5511>.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, October 2012, <http://www.rfc-editor.org/info/rfc6780>.
[RFC6780]Berger，L.，Le Faucheur，F.，和A.Narayanan，“RSVP关联对象扩展”，RFC 6780，DOI 10.17487/RFC6780，2012年10月<http://www.rfc-editor.org/info/rfc6780>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<http://www.rfc-editor.org/info/rfc4655>.
[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, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，DOI 10.17487/RFC5420，2009年2月<http://www.rfc-editor.org/info/rfc5420>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <http://www.rfc-editor.org/info/rfc5654>.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 5654，DOI 10.17487/RFC5654，2009年9月<http://www.rfc-editor.org/info/rfc5654>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 6370，DOI 10.17487/RFC6370，2011年9月<http://www.rfc-editor.org/info/rfc6370>.
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar, N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, DOI 10.17487/RFC6373, September 2011, <http://www.rfc-editor.org/info/rfc6373>.
[RFC6373]Andersson，L.，Ed.，Berger，L.，Ed.，Fang，L.，Ed.，Bitar，N.，Ed.，和E.Gray，Ed.，“MPLS传输配置文件（MPLS-TP）控制平面框架”，RFC 6373，DOI 10.17487/RFC6373，2011年9月<http://www.rfc-editor.org/info/rfc6373>.
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, September 2011, <http://www.rfc-editor.org/info/rfc6387>.
[RFC6387]Takacs，A.，Berger，L.，Caviglia，D.，Fedyk，D.，和J.Meuria，“GMPLS非对称带宽双向标签交换路径（LSP）”，RFC 6387，DOI 10.17487/RFC6387，2011年9月<http://www.rfc-editor.org/info/rfc6387>.
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, DOI 10.17487/RFC6689, July 2012, <http://www.rfc-editor.org/info/rfc6689>.
[RFC6689]Berger，L.“RSVP关联对象的使用”，RFC 6689，DOI 10.17487/RFC6689，2012年7月<http://www.rfc-editor.org/info/rfc6689>.
Acknowledgements
致谢
The authors would like to thank Lou Berger and George Swallow for their great guidance in this work; Jie Dong for the discussion of the recovery LSP; Lamberto Sterling for his valuable comments about asymmetric bandwidth signaling; Attila Takacs for the discussion of the provisioning model; Siva Sivabalan, Eric Osborne, and Robert Sawaya for the discussions on the ASSOCIATION Object; and Matt Hartley for providing useful suggestions on the document. At the same time, the authors would like to acknowledge the contributions of Bo Wu, Xihua Fu, and Lizhong Jin for the initial discussions; Wenjuan He for the prototype implementation; and Lou Berger, Daniel King, and Deborah Brungard for the review of the document.
作者要感谢Lou Berger和George Swallow在这项工作中给予的巨大指导；董杰就恢复LSP进行了讨论；Lamberto Sterling对不对称带宽信令的宝贵评论；Attila Takacs讨论供应模型；Siva Sivabalan、Eric Osborne和Robert Sawaya就协会对象进行了讨论；以及Matt Hartley为该文件提供了有用的建议。同时，作者要感谢吴波、傅锡华和金立中对初步讨论的贡献；何文娟为原型实现；以及Lou Berger、Daniel King和Deborah Brungard审查该文件。
Contributors
贡献者
Fan Yang ZTE
范洋中兴
EMail: yang.fan240347@gmail.com
EMail: yang.fan240347@gmail.com
Weilian Jiang ZTE
维联江中兴通讯
EMail: jiang.weilian@gmail.com
EMail: jiang.weilian@gmail.com
Authors' Addresses
作者地址
Fei Zhang (editor) Huawei
张飞（编辑）华为
EMail: zhangfei7@huawei.com
EMail: zhangfei7@huawei.com
Ruiquan Jing China Telecom
瑞泉京中国电信
EMail: jingrq@ctbri.com.cn
EMail: jingrq@ctbri.com.cn
Rakesh Gandhi (editor) Cisco Systems
拉凯什·甘地（编辑）思科系统
EMail: rgandhi@cisco.com
EMail: rgandhi@cisco.com