Internet Engineering Task Force (IETF) M. Chen
Request for Comments: 7965 W. Cao
Category: Standards Track Huawei
ISSN: 2070-1721 A. Takacs
Ericsson
P. Pan
August 2016
Internet Engineering Task Force (IETF) M. Chen
Request for Comments: 7965 W. Cao
Category: Standards Track Huawei
ISSN: 2070-1721 A. Takacs
Ericsson
P. Pan
August 2016
LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels
用于伪线绑定到标签交换路径（LSP）隧道的LDP扩展
Abstract
摘要
Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs.
许多传输服务要求以伪线（PWs）形式的用户通信量通过单个共路由双向隧道或共享相同路由的两个单向隧道进行传输。本文档定义了标签分发协议（LDP）的可选扩展，该扩展支持PWs和底层流量工程（TE）隧道之间的绑定。扩展适用于单段和多段PWs。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7965.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7965.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . 5
3.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . 7
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
5. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 9
6. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 11
7. PSN Tunnel Select Considerations . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 13
9.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 14
9.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . 5
3.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . 7
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
5. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 9
6. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 11
7. PSN Tunnel Select Considerations . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 13
9.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 14
9.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Pseudo Wire Emulation Edge-to-Edge (PWE3) [RFC3985] is a mechanism to emulate Layer 2 services, such as Ethernet Point-to-Point circuits. Such services are emulated between two Attachment Circuits, and the Pseudowire-encapsulated Layer 2 service payload is transported via Packet Switching Network (PSN) tunnels between Provider Edges (PEs). PWE3 typically uses the Label Distribution Protocol (LDP) [RFC5036] or Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) as PSN tunnels. The PEs select and bind the Pseudowires to PSN tunnels independently. Today, there is no standardized protocol-based provisioning mechanism to associate PWs with PSN tunnels; such associations must be managed via provisioning or other private methods.
伪线仿真边对边（PWE3）[RFC3985]是一种模拟第2层服务的机制，如以太网点对点电路。此类服务在两个连接电路之间进行仿真，并且伪线封装的第2层服务有效载荷通过提供商边缘（PE）之间的分组交换网络（PSN）隧道传输。PWE3通常使用标签分发协议（LDP）[RFC5036]或资源预留协议-流量工程（RSVP-TE）[RFC3209]标签交换路径（LSP）作为PSN隧道。PEs独立地选择伪线并将其绑定到PSN隧道。如今，没有标准化的基于协议的供应机制将PWs与PSN隧道相关联；此类关联必须通过设置或其他专用方法进行管理。
PW-to-PSN Tunnel Binding has become increasingly common and important in many deployment scenarios, as it allows service providers to offer service level agreements to their customers for such traffic attributes as bandwidth, latency, and availability.
PW到PSN隧道绑定在许多部署场景中变得越来越常见和重要，因为它允许服务提供商为其客户提供带宽、延迟和可用性等流量属性的服务级别协议。
The requirements for explicit control of PW-to-LSP mapping are described in Section 5.3.2 of [RFC6373]. Figure 1 illustrates how PWs can be bound to particular LSPs.
[RFC6373]第5.3.2节描述了PW到LSP映射的明确控制要求。图1说明了如何将PWs绑定到特定LSP。
+------+ +------+
---AC1 ---|..............PWs...............|---AC1---
---...----| PE1 |=======LSPs=======| PE2 |---...---
---ACn ---| |-------Links------| |---ACn---
+------+ +------+
+------+ +------+
---AC1 ---|..............PWs...............|---AC1---
---...----| PE1 |=======LSPs=======| PE2 |---...---
---ACn ---| |-------Links------| |---ACn---
+------+ +------+
Figure 1: Explicit PW-to-LSP Binding Scenario
图1：显式PW到LSP绑定场景
There are two PEs (PE1 and PE2) connected through multiple parallel links that may be on different physical fibers. Each link is managed and controlled as a bidirectional LSP. At each PE, there are a large number of bidirectional user flows from multiple Ethernet interfaces (access circuits in the figure). Each user flow utilizes a pair of unidirectional PWs to carry bidirectional traffic. The operators need to make sure that the user flows (that is, the PW-pairs) are carried on the same fiber or bidirectional LSP.
有两个PE（PE1和PE2）通过不同物理光纤上的多个并行链路连接。每个链路作为双向LSP进行管理和控制。在每个PE处，有大量来自多个以太网接口（图中的接入电路）的双向用户流。每个用户流利用一对单向PW来承载双向流量。运营商需要确保用户流（即PW对）在同一光纤或双向LSP上传输。
There are a number of reasons behind this requirement. First, due to delay and latency constraints, traffic going over different fibers may require a large amount of expensive buffer memory to compensate for the differential delay at the head-end nodes. Further, the operators may apply different protection mechanisms on different parts of the network (e.g., to deploy 1:1 protection in one part and 1+1 protection in other parts). As such, operators may prefer to
这一要求背后有许多原因。首先，由于延迟和延迟限制，通过不同光纤的流量可能需要大量昂贵的缓冲内存来补偿前端节点的差异延迟。此外，运营商可以在网络的不同部分应用不同的保护机制（例如，在一个部分部署1:1保护，在其他部分部署1+1保护）。因此，运营商可能更愿意
have a user's traffic traverse the same fiber. That implies that both forwarding and reserve direction PWs that belong to the same user flow need to be mapped to the same co-routed bidirectional LSP or two LSPs with the same route.
让用户的通信量穿过同一光纤。这意味着属于相同用户流的转发和保留方向pw都需要映射到相同的共路由双向LSP或具有相同路由的两个LSP。
Figure 2 illustrates a scenario where PW-LSP binding is not applied.
图2说明了未应用PW-LSP绑定的场景。
+----+ +--+ LSP1 +--+ +----+
+-----+ | PE1|===|P1|======|P2|===| PE2| +-----+
| |----| | +--+ +--+ | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | +--+ | |----| |
+-----+ | |======|P3|==========| | +-----+
+----+ +--+ LSP2 +----+
+----+ +--+ LSP1 +--+ +----+
+-----+ | PE1|===|P1|======|P2|===| PE2| +-----+
| |----| | +--+ +--+ | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | +--+ | |----| |
+-----+ | |======|P3|==========| | +-----+
+----+ +--+ LSP2 +----+
Figure 2: Inconsistent SS-PW-to-LSP Binding Scenario
图2：不一致的SS PW到LSP绑定场景
LSP1 and LSP2 are two bidirectional connections on diverse paths. The operator needs to deliver a bidirectional flow between PE1 and PE2. Using existing mechanisms, it's possible that PE1 may select LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for traffic from PE1 to PE2, while selecting LSP2 (PE2-P3-PE1) as the PSN tunnel for traffic from PE2 to PE1.
LSP1和LSP2是不同路径上的两个双向连接。操作员需要在PE1和PE2之间提供双向流量。使用现有机制，PE1可能会选择LSP1（PE1-P1-P2-PE2）作为PE1到PE2流量的PSN隧道，而选择LSP2（PE2-P3-PE1）作为PE2到PE1流量的PSN隧道。
Consequently, the user traffic is delivered over two disjointed LSPs that may have very different service attributes in terms of latency and protection. This may not be acceptable as a reliable and effective transport service to the customer.
因此，用户流量通过两个分离的lsp交付，这两个lsp在延迟和保护方面可能具有非常不同的服务属性。作为对客户的可靠和有效的运输服务，这可能是不可接受的。
A similar problem may also exist in multi-segment PWs (MS-PWs), where user traffic on a particular PW may hop over different networks in forward and reverse directions.
在多段PW（MS-PW）中也可能存在类似的问题，其中特定PW上的用户通信量可以正向和反向跳过不同的网络。
One way to solve this problem is by introducing manual provisioning at each PE to bind the PWs to the underlying PSN tunnels. However, this is prone to configuration errors and does not scale.
解决此问题的一种方法是在每个PE处引入手动资源调配，以将PWs绑定到底层PSN隧道。但是，这很容易出现配置错误，并且无法扩展。
This document introduces an automatic solution by extending Forwarding Equivalence Class (FEC) 128/129 PW based on [RFC4447].
本文介绍了一种基于[RFC4447]扩展转发等价类（FEC）128/129 PW的自动解决方案。
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]中所述进行解释。
This document defines a new optional TLV, the PSN Tunnel Binding TLV, to communicate tunnel/LSP selection and binding requests between PEs. The TLV carries a PW's binding profile and provides explicit or implicit information for the underlying PSN Tunnel Binding operation.
本文档定义了一个新的可选TLV，即PSN隧道绑定TLV，用于在PEs之间传递隧道/LSP选择和绑定请求。TLV携带PW的绑定配置文件，并为底层PSN隧道绑定操作提供显式或隐式信息。
The binding operation applies in both single-segment (SS) and multi-segment (MS) scenarios.
绑定操作适用于单段（SS）和多段（MS）场景。
The extension supports two types of binding requests:
扩展支持两种类型的绑定请求：
1. Strict binding: The requesting PE will choose and explicitly indicate the LSP information in the requests; the receiving PE MUST obey the requests; otherwise, the PW will not be established.
1. 严格绑定：请求PE在请求中选择并明确表示LSP信息；接收PE必须遵守要求；否则，PW将无法建立。
2. Co-routed binding: The requesting PE will suggest an underlying LSP to a remote PE. Upon receipt, the remote PE has the option to use the suggested LSP or reply to the information for an alternative.
2. 共同路由绑定：请求的PE将向远程PE建议基础LSP。收到后，远程PE可以选择使用建议的LSP或回复替代信息。
In this document, the term "tunnel" is identical to the "TE Tunnel" defined in Section 2.1 of [RFC3209], which is uniquely identified by a SESSION object that includes the Tunnel endpoint address, the Tunnel ID, and the Extended Tunnel ID. The term "LSP" is identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209], which is uniquely identified by the SESSION object together with the SENDER_TEMPLATE (or FILTER_SPEC) object that consists of the LSP ID and the Tunnel endpoint address.
在本文件中，术语“隧道”与[RFC3209]第2.1节中定义的“TE隧道”相同，由会话对象唯一标识，该会话对象包括隧道端点地址、隧道ID和扩展隧道ID。术语“LSP”与[RFC3209]第2.1节中定义的“LSP隧道”相同，它由会话对象和发送方\模板（或筛选器\规范）对象（由LSP ID和隧道端点地址组成）唯一标识。
The PSN Tunnel Binding TLV is an optional TLV and MUST be carried in the LDP Label Mapping message [RFC5036] if PW-to-LSP binding is required. The format is as follows:
PSN隧道绑定TLV是可选TLV，如果需要PW到LSP绑定，则必须在LDP标签映射消息[RFC5036]中携带。格式如下:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| PSN Tunnel Binding(0x0973)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S|T| Unallocated flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PSN Tunnel Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| PSN Tunnel Binding(0x0973)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S|T| Unallocated flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PSN Tunnel Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PSN Tunnel Binding TLV
图3:PSN隧道绑定TLV
The U-bit and F-bit are defined in Section 3.3 [RFC5036]. Since the PSN Tunnel Binding TLV is an optional TLV, the U-bit MUST be set to 1 so that a receiver MUST silently ignore this TLV if unknown to it, and continue processing the rest of the message.
第3.3节[RFC5036]中定义了U位和F位。由于PSN隧道绑定TLV是可选的TLV，因此必须将U位设置为1，以便接收器在未知时必须默默忽略此TLV，并继续处理消息的其余部分。
A receiver of this TLV is not allowed to forward the TLV further when it does not know the TLV. So, the F-bit MUST be set to 0.
当不知道TLV时，不允许该TLV的接收器进一步转发TLV。因此，F位必须设置为0。
The PSN Tunnel Binding TLV type is 0x0973.
PSN隧道绑定TLV类型为0x0973。
The Length field is 2 octets long. It defines the length in octets of the value field (including Flags, Reserved, and sub-TLV fields).
长度字段的长度为2个八位字节。它定义值字段（包括标志、保留和子TLV字段）的长度（以八位字节为单位）。
The Flags field is 2 octets in length and three flags are defined in this document. The rest of the unallocated flags MUST be set to zero when sending and MUST be ignored when received.
标志字段的长度为2个八位字节，本文档中定义了三个标志。其余未分配的标志在发送时必须设置为零，在接收时必须忽略。
C (Co-routed path) bit: This bit informs the remote T-PE/S-PEs about the properties of the underlying LSPs. When set, the remote T-PE/S-PEs SHOULD select the co-routed LSP (as the forwarding tunnel) as the reverse PSN tunnel. If there is no such tunnel available, it may trigger the remote T-PE/S-PEs to establish a new LSP.
C（共路由路径）位：该位通知远程T-PE/S-PE底层LSP的属性。设置后，远程T-PE/S-PE应选择共路由LSP（作为转发隧道）作为反向PSN隧道。如果没有此类隧道可用，则可能会触发远程T-PE/S-PE建立新的LSP。
S (Strict) bit: This bit instructs the PEs with respect to the handling of the underlying LSPs. When set, the remote PE MUST use the tunnel/LSP specified in the PSN Tunnel Sub-TLV as the PSN tunnel on the reverse direction of the PW, or the PW will fail to be established.
S（严格）位：该位指示PEs处理底层LSP。设置时，远程PE必须使用PSN tunnel Sub TLV中指定的隧道/LSP作为PW反向上的PSN隧道，否则PW将无法建立。
Either the C-bit or the S-bit MUST be set. The C-bit and S-bit are mutually exclusive from each other, and they cannot be set in the same message. If a status code set to "both C-bit and S-bit are set" or "both C-bit and S-bit are clear" is received, a Label Release message with the status code set to "The C-bit or S-bit unknown" (0x0000003C) MUST be the reply, and the PW will not be established.
必须设置C位或S位。C位和S位相互排斥，不能在同一条消息中设置。如果接收到设置为“C位和S位均已设置”或“C位和S位均已清除”的状态代码，则状态代码设置为“C位或S位未知”（0x0000003C）的标签释放消息必须作为回复，并且不会建立PW。
T (Tunnel Representation) bit: This bit indicates the format of the LSP tunnels. When the bit is set, the tunnel uses the tunnel information to identify itself, and the LSP Number fields in the PSN Tunnel sub-TLV (Section 3.1.1) MUST be set to zero. Otherwise, both the tunnel and LSP information of the PSN tunnel are required. The default is set. The motivation for the T-bit is to support the MPLS protection operation where the LSP Number fields may be ignored.
T（隧道表示）位：该位表示LSP隧道的格式。设置位时，隧道使用隧道信息识别自身，PSN隧道子TLV（第3.1.1节）中的LSP编号字段必须设置为零。否则，需要PSN隧道的隧道和LSP信息。默认设置为。T位的动机是支持MPLS保护操作，其中可以忽略LSP编号字段。
The Reserved field is 2 octets in length and is left for future use.
保留字段的长度为2个八位字节，留作将来使用。
PSN Tunnel Sub-TLVs are designed for inclusion in the PSN Tunnel Binding TLV to specify the tunnel/LSPs to which a PW is required to bind.
PSN隧道子TLV设计用于包含在PSN隧道绑定TLV中，以指定PW需要绑定到的隧道/LSP。
Two sub-TLVs are defined: The IPv4 and IPv6 Tunnel sub-TLVs.
定义了两个子TLV：IPv4和IPv6隧道子TLV。
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 (1) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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 (1) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
Figure 4: IPv4 PSN Tunnel Sub-TLV Format
图4:IPv4 PSN隧道子TLV格式
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 (2) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (2) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 PSN Tunnel Sub-TLV Format
图5:IPv6 PSN隧道子TLV格式
The definition of the Source and Destination Global/Node IDs and Tunnel/LSP Numbers are derived from [RFC6370]. This describes the underlying LSPs. Note that the LSPs in this notation are globally unique. The ITU-T style identifiers [RFC6923] are not used in this document.
源和目标全局/节点ID以及隧道/LSP编号的定义源自[RFC6370]。这描述了底层LSP。请注意，此符号中的LSP是全局唯一的。本文件中未使用ITU-T样式标识符[RFC6923]。
As defined in Sections 4.6.1.1 and 4.6.1.2 of [RFC3209], the "Tunnel endpoint address" is mapped to the Destination Node ID, and the "Extended Tunnel ID" is mapped to the Source Node ID. Both IDs can be either IPv4 or IPv6 addresses. The Node IDs are routable addresses of the ingress LSR and egress LSR of the Tunnel/LSP.
如[RFC3209]第4.6.1.1节和第4.6.1.2节所定义，“隧道端点地址”映射到目标节点ID，“扩展隧道ID”映射到源节点ID。这两个ID可以是IPv4或IPv6地址。节点id是隧道/LSP的入口LSR和出口LSR的可路由地址。
A PSN Tunnel sub-TLV could be used to identify either a tunnel or a specific LSP. The T-bit in the Flags field defines the distinction as such that, when the T-bit is set, the Source/Destination LSP Number fields MUST be zero and ignored during processing. Otherwise, both Source/Destination LSP Number fields MUST have the actual LSP IDs of specific LSPs.
PSN隧道子TLV可用于识别隧道或特定LSP。标志字段中的T位定义了区别，当设置T位时，源/目标LSP编号字段必须为零，并在处理过程中忽略。否则，两个源/目标LSP编号字段必须具有特定LSP的实际LSP ID。
Each PSN Tunnel Binding TLV MUST only have one such sub-TLV. When sending, only one sub-TLV MUST be carried. When received, if there are more than one sub-TLVs carried, only the first sub-TLV MUST be used, the rest of the sub-TLVs MUST be ignored.
每个PSN隧道绑定TLV必须只有一个子TLV。发送时，只能携带一个子TLV。收到时，如果携带了多个子TLV，则只能使用第一个子TLV，必须忽略其余子TLV。
During PW setup, the PEs may choose to select the desired forwarding tunnels/LSPs and inform the remote T-PE/S-PEs about the desired reverse tunnels/LSPs.
在PW设置期间，PEs可以选择所需的转发隧道/LSP，并将所需的反向隧道/LSP通知远程T-PE/S-PEs。
Specifically, to set up a PW (or PW Segment), a PE may select a candidate tunnel/LSP to act as the PSN tunnel. If no candidate is available or none satisfy the constraints, the PE will trigger and establish a new tunnel/LSP. The selected tunnel/LSP information is carried in the PSN Tunnel Binding TLV and sent with the Label Mapping message to the target PE.
具体而言，为了建立PW（或PW段），PE可以选择候选隧道/LSP作为PSN隧道。如果没有候选人可用或没有人满足约束，PE将触发并建立新的隧道/LSP。所选隧道/LSP信息在PSN隧道绑定TLV中携带，并与标签映射消息一起发送到目标PE。
Upon the reception of the Label Mapping message, the receiving PE will process the PSN Tunnel Binding TLV, determine whether it can accept the suggested tunnel/LSP or to find the reverse tunnel/LSP that meets the request, and respond with a Label Mapping message, which contains the corresponding PSN Tunnel Binding TLV.
在接收到标签映射消息后，接收PE将处理PSN隧道绑定TLV，确定其是否可以接受建议的隧道/LSP或找到满足请求的反向隧道/LSP，并使用包含相应PSN隧道绑定TLV的标签映射消息进行响应。
It is possible that two PEs request PSN Binding to the same PW or PW segment over different tunnels/LSPs at the same time. This may cause collisions of tunnel/LSPs selection as both PEs assume the active role.
两个PE可能同时通过不同的隧道/LSP请求PSN绑定到同一PW或PW段。这可能会导致隧道/LSP选择冲突，因为两个PE都承担主动角色。
As defined in (Section 7.2.1, [RFC6073]), each PE may be categorized into active and passive roles:
如（第7.2.1节[RFC6073]）所定义，每个PE可分为主动和被动角色：
1. Active PE: The PE that initiates the selection of the tunnel/LSPs and informs the remote PE;
1. 主动PE：启动隧道/LSP选择并通知远程PE的PE；
2. Passive PE: The PE that obeys the active PE's suggestion.
2. 被动体育：服从主动体育建议的体育。
In the rest of this document, we will elaborate upon the operation for SS-PW and MS-PW:
在本文件的其余部分中，我们将详细说明SS-PW和MS-PW的操作：
1. SS-PW: In this scenario, both PEs for a particular PW may assume the active roles.
1. SS-PW：在这种情况下，特定PW的两个PE都可以担任主动角色。
2. MS-PW: One PE is active, while the other is passive. The PWs are set up using FEC 129.
2. MS-PW：一个PE是主动的，而另一个是被动的。PWs是使用FEC 129设置的。
As illustrated in Figure 6, both PEs (e.g., PE1 and PE2) of a PW may independently initiate the setup. To perform PSN Binding, the Label Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN Tunnel sub-TLV MUST contain the desired tunnel/LSPs of the sender.
如图6所示，PW的PEs（如PE1和PE2）可独立启动设置。要执行PSN绑定，标签映射消息必须携带PSN隧道绑定TLV，并且PSN隧道子TLV必须包含发送方所需的隧道/LSP。
+----+ LSP1 +----+
+-----+ | PE1|====================| PE2| +-----+
| |----| | | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | | |----| |
+-----+ | |====================| | +-----+
+----+ LSP2 +----+
+----+ LSP1 +----+
+-----+ | PE1|====================| PE2| +-----+
| |----| | | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | | |----| |
+-----+ | |====================| | +-----+
+----+ LSP2 +----+
Figure 6: PSN Binding Operation in SS-PW Environment
图6:SS-PW环境中的PSN绑定操作
As outlined previously, there are two types of binding requests: co-routed and strict.
如前所述，有两种类型的绑定请求：联合路由和严格路由。
In strict binding, a PE (e.g., PE1) will mandate that the other PE (e.g., PE2) use a specified tunnel/LSP (e.g., LSP1) as the PSN tunnel on the reverse direction. In the PSN Tunnel Binding TLV, the S-bit MUST be set, the C-bit MUST be cleared, and the Source and Destination IDs/Numbers MUST be filled.
在严格绑定中，一个PE（例如PE1）将强制另一个PE（例如PE2）使用指定的隧道/LSP（例如LSP1）作为反向上的PSN隧道。在PSN隧道绑定TLV中，必须设置S位，必须清除C位，并且必须填写源和目标ID/编号。
Upon receipt, if the S-bit is set, as well as following the processing procedure defined in Section 5.3.3 of [RFC4447], the receiving PE (i.e., PE2) needs to determine whether to accept the indicated tunnel/LSP in PSN Tunnel Sub-TLV.
收到后，如果设置了S位，并且遵循[RFC4447]第5.3.3节中定义的处理程序，则接收PE（即PE2）需要确定是否接受PSN隧道子TLV中指示的隧道/LSP。
The receiving PE (PE2) may also be an active PE, and it may have initiated the PSN Binding requests to the other PE (PE1); if the received PSN tunnel/LSP is the same as was sent in the Label Mapping message by PE2, then the signaling has converged on a mutually agreed upon Tunnel/LSP. The binding operation is completed.
接收PE（PE2）也可以是活动PE，并且它可能已经向另一个PE（PE1）发起PSN绑定请求；如果接收到的PSN隧道/LSP与PE2在标签映射消息中发送的相同，则信令已聚合到相互商定的隧道/LSP上。绑定操作已完成。
Otherwise, the receiving PE (PE2) MUST compare its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is larger, the PE (PE2) will reply with a Label Mapping message to complete the PW setup and confirm the binding request. The PSN Tunnel Binding TLV in the message MUST contain the same Source and Destination IDs/Numbers as in the received binding request, in the appropriate order (where the source is PE2 and PE1 becomes the destination). On the other hand, if the receiving PE (PE2) has a Node ID that is larger than the Source Node ID carried in the PSN Tunnel Binding TLV, it MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs", and the received PSN Tunnel Binding TLV, and the PW will not be established.
否则，接收PE（PE2）必须将自己的节点ID与接收到的源节点ID作为无符号整数进行比较。如果收到的源节点ID较大，则PE（PE2）将使用标签映射消息进行回复，以完成PW设置并确认绑定请求。消息中的PSN隧道绑定TLV必须以适当的顺序包含与接收到的绑定请求中相同的源和目标ID/编号（其中源为PE2，PE1成为目标）。另一方面，如果接收PE（PE2）的节点ID大于PSN隧道绑定TLV中携带的源节点ID，则其必须使用状态代码设置为“拒绝-无法使用建议的隧道/LSP”的标签释放消息进行回复，并且接收到的PSN隧道绑定TLV，并且PW将不会建立。
To support co-routed binding, the receiving PE can select the appropriate PSN tunnel/LSP for the reverse direction of the PW, so long as the forwarding and reverse PSNs share the same route (links and nodes).
为了支持共路由绑定，接收PE可以为PW的反向选择适当的PSN隧道/LSP，只要转发和反向PSN共享相同的路由（链路和节点）。
Initially, a PE (PE1) sends a Label Mapping message to the remote PE (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared, and the appropriate Source and Destination IDs/Numbers. In case of unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the Source IDs/Numbers; the Destination IDs/Numbers are set to zero and left for PE2 to complete when responding to the Label Mapping message.
最初，PE（PE1）向远程PE（PE2）发送带有PSN隧道绑定TLV的标签映射消息，设置C位、清除S位以及适当的源和目标ID/编号。在单向LSP的情况下，PSN隧道绑定TLV可能仅包含源ID/编号；当响应标签映射消息时，目标ID/编号设置为零，留给PE2完成。
Upon receipt, since PE2 is also an active PE, and may have initiated the PSN Binding requests to the other PE (PE1), if the received PSN tunnel/LSP has the same route as the one that has been sent in the Label Mapping message to PE1, then the signaling has converged. The binding operation is completed.
在接收时，由于PE2也是活动PE，并且可能已经发起了到另一个PE（PE1）的PSN绑定请求，如果接收到的PSN隧道/LSP具有与在标签映射消息中发送到PE1的路由相同的路由，则信令已经聚合。绑定操作已完成。
Otherwise, PE2 needs to compare its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is larger, PE2 needs to find/establish a tunnel/LSP that meets the co-routed constraint, and reply with a Label Mapping message that has a PSN Binding TLV that contains the Source and Destination IDs/ Numbers of the tunnel/LSP. On the other hand, if the receiving PE (PE2) has a Node ID that is larger than the Source Node ID carried in the PSN Tunnel Binding TLV, it MUST reply with a Label Release message that has a status code set to "Reject - unable to use the
否则，PE2需要将自己的节点ID与接收到的源节点ID作为无符号整数进行比较。如果接收到的源节点ID更大，PE2需要找到/建立满足共同路由约束的隧道/LSP，并使用标签映射消息进行回复，该消息具有包含隧道/LSP的源和目标ID/编号的PSN绑定TLV。另一方面，如果接收PE（PE2）的节点ID大于PSN隧道绑定TLV中携带的源节点ID，则其必须使用状态代码设置为“拒绝-无法使用”的标签释放消息进行回复
suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV.
建议的隧道/LSP”（0x0000003B）和接收到的PSN隧道绑定TLV。
In addition, if the received PSN tunnel/LSP endpoints do not match the PW endpoints, PE2 MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV MUST also be carried.
此外，如果收到的PSN隧道/LSP端点与PW端点不匹配，PE2必须回复标签释放消息，状态代码设置为“拒绝-无法使用建议的隧道/LSP”（0x0000003B），并且还必须携带收到的PSN隧道绑定TLV。
In both strict and co-routed bindings, if the T-bit is set, the LSP Number field MUST be set to zero. Otherwise, the field MUST contain the actual LSP number for the related PSN LSP.
在严格绑定和共路由绑定中，如果设置了T位，则LSP Number字段必须设置为零。否则，该字段必须包含相关PSN LSP的实际LSP编号。
After a PW is established, the operators may choose to move the PWs from the current tunnel/LSPs to other tunnel/LSPs. Also, the underlying PSN tunnel may break due to a network failure. When either of these scenarios occur, a new Label Mapping message MUST be sent to notify the remote PE of the changes. Note that when the T-bit is set, the working LSP broken will not provide this update if there are protection LSPs in place.
建立PW后，操作员可以选择将PW从当前隧道/LSP移动到其他隧道/LSP。此外，底层PSN隧道可能因网络故障而中断。当出现上述任何一种情况时，必须发送一条新的标签映射消息，以将更改通知远程PE。请注意，当设置T位时，如果存在保护LSP，则工作LSP断开不会提供此更新。
The message may carry a new PSN Tunnel Binding TLV, which contains the new Source and Destination Numbers/IDs. The handling of the new message should be identical to what has been described in this section.
消息可能携带新的PSN隧道绑定TLV，其中包含新的源和目标编号/ID。新消息的处理方式应与本节中描述的相同。
However, if the new Label Mapping message does not contain the PSN Tunnel Binding TLV, it declares the removal of any co-routed/strict constraints. The current independent PW-to-PSN Binding will be used.
但是，如果新的标签映射消息不包含PSN隧道绑定TLV，它将声明删除任何共同路由/严格约束。将使用当前独立的PW到PSN绑定。
Further, as an implementation option, the PEs may choose not to remove the traffic from an operational PW until the completion of the underlying PSN tunnel/LSP changes.
此外，作为一种实现选项，PEs可以选择在基本PSN隧道/LSP改变完成之前不从操作PW移除通信量。
MS-PW uses FEC 129 for PW setup. We refer to Figure 7 for this operation.
MS-PW使用FEC 129进行PW设置。有关此操作，请参见图7。
+-----+ LSP1 +-----+ LSP2 +-----+ LSP3 +-----+
+---+ |T-PE1|======|S-PE1|======|S-PE2|======|T-PE2| +---+
| |---| | | | | | | |---| |
|CE1| |......................PW....................| |CE2|
| |---| | | | | | | |---| |
+---+ | |======| |======| |======| | +---+
+-----+ LSP4 +-----+ LSP5 +-----+ LSP6 +-----+
+-----+ LSP1 +-----+ LSP2 +-----+ LSP3 +-----+
+---+ |T-PE1|======|S-PE1|======|S-PE2|======|T-PE2| +---+
| |---| | | | | | | |---| |
|CE1| |......................PW....................| |CE2|
| |---| | | | | | | |---| |
+---+ | |======| |======| |======| | +---+
+-----+ LSP4 +-----+ LSP5 +-----+ LSP6 +-----+
Figure 7: PSN Binding Operation in MS-PW Environment
图7:MS-PW环境中的PSN绑定操作
When an active PE (that is, T-PE1) starts to signal an MS-PW, a PSN Tunnel Binding TLV MUST be carried in the Label Mapping message and sent to the adjacent S-PE (that is, S-PE1). The PSN Tunnel Binding TLV includes the PSN Tunnel sub-TLV that carries the desired tunnel/LSP of T-PE1.
当活动PE（即T-PE1）开始向MS-PW发送信号时，必须在标签映射消息中携带PSN隧道绑定TLV，并发送到相邻的S-PE（即S-PE1）。PSN隧道绑定TLV包括承载T-PE1的所需隧道/LSP的PSN隧道子TLV。
For strict binding, the initiating PE MUST set the S-bit, clear the C-bit, and indicate the binding tunnel/LSP to the next-hop S-PE.
对于严格绑定，发起PE必须设置S位，清除C位，并向下一跳S-PE指示绑定隧道/LSP。
When S-PE1 receives the Label Mapping message, it needs to determine if the signaling is for the forward or reverse direction, as defined in Section 4.2.3 of [RFC7267].
当S-PE1接收到标签映射消息时，它需要确定信令是正向还是反向，如[RFC7267]第4.2.3节所定义。
If the Label Mapping message is for the forward direction, and S-PE1 accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the tunnel/LSP information for reverse-direction processing later on. If the PSN Binding request is not acceptable, S-PE1 MUST reply with a Label Release Message to the upstream PE (T-PE1) with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B).
如果标签映射消息用于正向，并且S-PE1从T-PE1接受请求的隧道/LSP，则S-PE1必须保存隧道/LSP信息，以便稍后进行反向处理。如果PSN绑定请求不可接受，S-PE1必须向上游PE（T-PE1）回复标签释放消息，状态代码设置为“拒绝-无法使用建议的隧道/LSP”（0x0000003B）。
Otherwise, S-PE1 relays the Label Mapping message to the next S-PE (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the information of the new PSN tunnel/LSPs selected by S-PE1. S-PE2 and subsequent S-PEs will repeat the same operation until the Label Mapping message reaches to the remote T-PE (that is, T-PE2).
否则，S-PE1将标签映射消息中继到下一个S-PE（即S-PE2），PSN隧道子TLV携带S-PE1选择的新PSN隧道/LSP的信息。S-PE2和后续S-PEs将重复相同的操作，直到标签映射消息到达远程T-PE（即T-PE2）。
If T-PE2 agrees with the requested tunnel/LSPs, it will reply with a Label Mapping message to initiate the binding process in the reverse direction. The Label Mapping message contains the received PSN Tunnel Binding TLV for confirmation purposes.
如果T-PE2同意请求的隧道/LSP，它将使用标签映射消息进行回复，以反向启动绑定过程。标签映射消息包含收到的PSN隧道绑定TLV，以进行确认。
When its upstream S-PE (S-PE2) receives the Label Mapping message, the S-PE relays the Label Mapping message to its upstream adjacent S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in the PSN Tunnel sub-TLV. The same procedure will be applied on subsequent S-PEs, until the message reaches T-PE1 to complete the PSN Binding setup.
当其上游S-PE（S-PE2）接收到标签映射消息时，S-PE将标签映射消息中继到其上游相邻的S-PE（S-PE1），并将先前保存的PSN隧道/LSP信息保存在PSN隧道子TLV中。相同的程序将应用于后续S-PEs，直到消息到达T-PE1以完成PSN绑定设置。
During the binding process, if any PE does not agree to the requested tunnel/LSPs, it can send a Label Release Message to its upstream adjacent PE with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B). In addition, if the received PSN tunnel/LSP endpoints do not match the PW Segment endpoints, the receiving PE MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV MUST also be carried.
在绑定过程中，如果任何PE不同意请求的隧道/LSP，它可以向其上游相邻PE发送标签释放消息，状态代码设置为“拒绝-无法使用建议的隧道/LSP”（0x0000003B）。此外，如果接收到的PSN隧道/LSP端点与PW段端点不匹配，则接收PE必须回复标签释放消息，状态代码设置为“拒绝-无法使用建议的隧道/LSP”（0x0000003B），并且还必须携带接收到的PSN隧道绑定TLV。
For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit, reset the S-bit, and indicate the suggested tunnel/LSP in the PSN Tunnel sub-TLV to the next-hop S-PE (S-PE1).
对于共路由绑定，发起PE（T-PE1）必须设置C位，重置S位，并将PSN隧道子TLV中建议的隧道/LSP指示给下一跳S-PE（S-PE1）。
During the MS-PW setup, the PEs have the option of ignoring the suggested tunnel/LSP, and to select another tunnel/LSP for the segment PW between itself and its upstream PE in reverse direction only if the tunnel/LSP is co-routed with the forward one. Otherwise, the procedure is the same as the strict binding.
在MS-PW设置过程中，PEs可以选择忽略建议的隧道/LSP，并且仅当隧道/LSP与正向隧道/LSP共路由时，PEs才可以选择另一个隧道/LSP作为PW段自身与其上游PE之间的反向隧道/LSP。否则，程序与严格绑定相同。
The tunnel/LSPs may change after a MS-PW has been established. When a tunnel/LSP has changed, the PE that detects the change SHOULD select an alternative tunnel/LSP for temporary use while negotiating with other PEs following the procedure described in this section.
MS-PW建立后，隧道/LSP可能会发生变化。当隧道/LSP发生变化时，检测到变化的PE应选择替代隧道/LSP临时使用，同时按照本节所述程序与其他PE协商。
As stated in Section 1, the PSN tunnel that is used for binding can be either a co-routed bidirectional LSP or two LSPs with the same route. The co-routed bidirectional LSP has the characteristics that both directions not only cross the same nodes and links, but have the same life span. But for the two LSPs case, even if they have the same route at the beginning, it cannot be guaranteed that they will always have the same route all the time. For example, when Fast ReRoute (FRR) [RFC4090] is deployed for the LSPs, link or node failure may make the two LSPs use different routes. So, if the network supports co-routed bidirectional LSPs, it is RECOMMENDED that a co-routed bidirectional LSP should be used; otherwise, two LSPs with the same route may be used.
如第1节所述，用于绑定的PSN隧道可以是共路由双向LSP，也可以是具有相同路由的两个LSP。共路由双向LSP的特点是，两个方向不仅穿过相同的节点和链路，而且具有相同的寿命。但对于两个LSP的情况，即使它们在开始时具有相同的路由，也不能保证它们始终具有相同的路由。例如，当为LSP部署快速重路由（FRR）[RFC4090]时，链路或节点故障可能使两个LSP使用不同的路由。因此，如果网络支持共路由双向LSP，建议使用共路由双向LSP；否则，可以使用具有相同路由的两个LSP。
The ability to control which LSP is used to carry traffic from a PW can be a potential security risk both for denial of service and traffic interception. It is RECOMMENDED that PEs not accept the use of LSPs identified in the PSN Tunnel Binding TLV unless the LSP endpoints match the PW or PW segment endpoints. Furthermore, it is RECOMMENDED that PEs implement the LDP security mechanisms described in [RFC5036] and [RFC5920].
控制哪个LSP用于承载来自PW的流量的能力可能是拒绝服务和流量拦截的潜在安全风险。建议PEs不接受使用PSN隧道绑定TLV中标识的LSP，除非LSP端点与PW或PW段端点匹配。此外，建议PEs实施[RFC5036]和[RFC5920]中所述的LDP安全机制。
This document defines a new TLV (Section 3.1) for inclusion in the LDP Label Mapping message. IANA has assigned TLV type value 0x0973 from the "LDP TLV Type Name Space" registry.
本文件定义了一个新的TLV（第3.1节），用于包含在LDP标签映射消息中。IANA已从“LDP TLV类型名称空间”注册表中分配了TLV类型值0x0973。
This document defines two sub-TLVs (Section 3.1.1) for the PSN Tunnel Binding TLV. IANA has created a new PWE3 subregistry titled "PSN Tunnel Sub-TLV Name Space" for PSN Tunnel sub-TLVs and has assigned Sub-TLV type values to the following sub-TLVs:
本文件为PSN隧道绑定TLV定义了两个子TLV（第3.1.1节）。IANA为PSN隧道子TLV创建了一个名为“PSN隧道子TLV名称空间”的新PWE3子区，并为以下子TLV分配了子TLV类型值：
IPv4 PSN Tunnel sub-TLV - 1
IPv4 PSN隧道子TLV-1
IPv6 PSN Tunnel sub-TLV - 2
IPv6 PSN隧道子TLV-2
In addition, the values 0 and 255 in this new registry should be reserved, and values 1-254 will be allocated by IETF Review [RFC5226].
此外，新注册表中的值0和255应保留，值1-254将由IETF Review[RFC5226]分配。
This document defines two new LDP status codes, IANA has assigned status codes to these new defined codes from the "LDP Status Code Name Space" registry.
本文件定义了两个新的LDP状态码，IANA已将状态码从“LDP状态码名称空间”注册表分配给这些新定义的代码。
"Reject - unable to use the suggested tunnel/LSPs" - 0x0000003B
"Reject - unable to use the suggested tunnel/LSPs" - 0x0000003B
"The C-bit or S-bit unknown" - 0x0000003C
“C位或S位未知”-0x0000003C
The E bit is set to 1 for both new codes.
两个新代码的E位均设置为1。
[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>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, DOI 10.17487/RFC4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，DOI 10.17487/RFC4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[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>.
[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>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC3985]Bryant，S.，Ed.和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 3985，DOI 10.17487/RFC3985，2005年3月<http://www.rfc-editor.org/info/rfc3985>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 4090，DOI 10.17487/RFC4090，2005年5月<http://www.rfc-editor.org/info/rfc4090>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[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>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 6073，DOI 10.17487/RFC6073，2011年1月<http://www.rfc-editor.org/info/rfc6073>.
[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>.
[RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts, "MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions", RFC 6923, DOI 10.17487/RFC6923, May 2013, <http://www.rfc-editor.org/info/rfc6923>.
[RFC6923]Winter，R.，Gray，E.，van Helvoort，H.，和M.Betts，“遵循ITU-T公约的MPLS传输配置文件（MPLS-TP）标识符”，RFC 6923，DOI 10.17487/RFC6923，2013年5月<http://www.rfc-editor.org/info/rfc6923>.
[RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., "Dynamic Placement of Multi-Segment Pseudowires", RFC 7267, DOI 10.17487/RFC7267, June 2014, <http://www.rfc-editor.org/info/rfc7267>.
[RFC7267]Martini，L.，Ed.，Bocci，M.，Ed.，和F.Balus，Ed.，“多段伪导线的动态放置”，RFC 7267，DOI 10.17487/RFC7267，2014年6月<http://www.rfc-editor.org/info/rfc7267>.
Acknowledgements
致谢
The authors would like to thank Adrian Farrel, Kamran Raza, Xinchun Guo, Mingming Zhu, and Li Xue for their comments and help in preparing this document. Also this document benefits from the discussions with Nabil Bitar, Paul Doolan, Frederic Journay, Andy Malis, Curtis Villamizar, Luca Martini, Alexander Vainshtein, Huub van Helvoort, Daniele Ceccarelli, and Stewart Bryant.
作者感谢Adrian Farrel、Kamran Raza、郭新春、朱明明和李雪在编写本文件过程中的评论和帮助。此外，本文件还得益于与纳比尔·比塔尔、保罗·杜兰、弗雷德里克·乔雷、安迪·马里、柯蒂斯·维拉米扎、卢卡·马蒂尼、亚历山大·范恩斯坦、胡布·范·赫尔沃特、达涅利·塞卡雷利和斯图尔特·布莱恩特的讨论。
We would especially like to acknowledge Ping Pan, a coauthor on the early draft versions of this document. It was a privilege to have known him.
我们特别要感谢潘平，他是本文件早期草稿的合著者。认识他是一种荣幸。
The coauthors of this document, the working group chairs, the responsible AD, and the PALS working group wish to dedicate this RFC to the memory of our friend and colleague Ping Pan, in recognition for his devotion and hard work at the IETF.
本文件的合著者、工作组主席、负责的AD和PALS工作组希望将本RFC献给我们的朋友和同事潘平，以表彰他在IETF的奉献和辛勤工作。
Authors' Addresses
作者地址
Mach(Guoyi) Chen Huawei
马赫（国一）陈华为
Email: mach.chen@huawei.com
Email: mach.chen@huawei.com
Wei Cao Huawei
曹伟华为
Email: wayne.caowei@huawei.com
Email: wayne.caowei@huawei.com
Attila Takacs Ericsson Laborc u. 1. Budapest 1037 Hungary
爱立信实验室。1.匈牙利布达佩斯1037
Email: attila.takacs@ericsson.com
Email: attila.takacs@ericsson.com
Ping Pan
平盘