Internet Engineering Task Force (IETF) L. Martini, Ed.
Request for Comments: 7267 Cisco Systems, Inc.
Updates: 6073 M. Bocci, Ed.
Category: Standards Track F. Balus, Ed.
ISSN: 2070-1721 Alcatel-Lucent
June 2014
Internet Engineering Task Force (IETF) L. Martini, Ed.
Request for Comments: 7267 Cisco Systems, Inc.
Updates: 6073 M. Bocci, Ed.
Category: Standards Track F. Balus, Ed.
ISSN: 2070-1721 Alcatel-Lucent
June 2014
Dynamic Placement of Multi-Segment Pseudowires
多段伪导线的动态放置
Abstract
摘要
RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.
RFC 5254描述了跨多个分组交换网络域扩展伪线（PW）覆盖范围的服务提供商要求。多段PW定义为两个或多个连续PW段的集合，其行为和功能与单点对点PW相同。本文档描述了PW控制协议的扩展，以在一组提供商边缘（PE）路由器之间动态放置多段伪线的段。本文件还通过将PW开关点PE Sub TLV类型0x06的长度字段值更新为14来更新RFC 6073。
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/rfc7267.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7267.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Specification of Requirements ..............................4
1.3. Terminology ................................................4
1.4. Architecture Overview ......................................5
2. Applicability ...................................................6
2.1. Changes to Existing PW Signaling ...........................6
3. PW Layer 2 Addressing ...........................................6
3.1. Attachment Circuit Addressing ..............................7
3.2. S-PE Addressing ............................................8
4. Dynamic Placement of MS-PWs .....................................8
4.1. Pseudowire Routing Procedures ..............................8
4.1.1. AII PW Routing Table Lookup Aggregation Rules .......9
4.1.2. PW Static Route .....................................9
4.1.3. Dynamic Advertisement with BGP .....................10
4.2. LDP Signaling .............................................11
4.2.1. Multiple Alternative Paths in PW Routing ...........13
4.2.2. Active/Passive T-PE Election Procedure .............14
4.2.3. Detailed Signaling Procedures ......................15
5. Procedures for Failure Handling ................................16
5.1. PSN Failures ..............................................16
5.2. S-PE Failures .............................................17
5.3. PW Reachability Changes ...................................17
6. Operations, Administration, and Maintenance (OAM) ..............18
7. Security Considerations ........................................18
8. IANA Considerations ............................................19
8.1. Correction ................................................19
8.2. LDP TLV Type Name Space ...................................19
8.3. LDP Status Codes ..........................................20
8.4. BGP SAFI ..................................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Contributors ..................................................22
11. Acknowledgements ..............................................23
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Specification of Requirements ..............................4
1.3. Terminology ................................................4
1.4. Architecture Overview ......................................5
2. Applicability ...................................................6
2.1. Changes to Existing PW Signaling ...........................6
3. PW Layer 2 Addressing ...........................................6
3.1. Attachment Circuit Addressing ..............................7
3.2. S-PE Addressing ............................................8
4. Dynamic Placement of MS-PWs .....................................8
4.1. Pseudowire Routing Procedures ..............................8
4.1.1. AII PW Routing Table Lookup Aggregation Rules .......9
4.1.2. PW Static Route .....................................9
4.1.3. Dynamic Advertisement with BGP .....................10
4.2. LDP Signaling .............................................11
4.2.1. Multiple Alternative Paths in PW Routing ...........13
4.2.2. Active/Passive T-PE Election Procedure .............14
4.2.3. Detailed Signaling Procedures ......................15
5. Procedures for Failure Handling ................................16
5.1. PSN Failures ..............................................16
5.2. S-PE Failures .............................................17
5.3. PW Reachability Changes ...................................17
6. Operations, Administration, and Maintenance (OAM) ..............18
7. Security Considerations ........................................18
8. IANA Considerations ............................................19
8.1. Correction ................................................19
8.2. LDP TLV Type Name Space ...................................19
8.3. LDP Status Codes ..........................................20
8.4. BGP SAFI ..................................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Contributors ..................................................22
11. Acknowledgements ..............................................23
[RFC5254] describes the service provider requirements for extending the reach of pseudowires across multiple Packet Switched Network (PSN) domains. This is achieved using a multi-segment pseudowire (MS-PW). An MS-PW is defined as a set of two or more contiguous pseudowire (PW) segments that behave and function as a single point-to-point PW. This architecture is described in [RFC5659].
[RFC5254]描述了服务提供商在多个分组交换网络（PSN）域中扩展伪线覆盖范围的要求。这是通过使用多段伪导线（MS-PW）实现的。MS-PW定义为一组两个或多个连续的伪导线（PW）段，其行为和功能与单个点对点PW相同。[RFC5659]中描述了该体系结构。
The procedures for establishing PWs that extend across a single PSN domain are described in [RFC4447], while procedures for setting up PWs across multiple PSN domains or control plane domains are described in [RFC6073].
[RFC4447]中描述了建立跨越单个PSN域的PW的程序，而[RFC6073]中描述了跨越多个PSN域或控制平面域建立PW的程序。
The purpose of this document is to specify extensions to the pseudowire control protocol [RFC4447], and [RFC6073] procedures, to enable multi-segment PWs to be dynamically placed. The procedures follow the guidelines defined in [RFC5036] and enable the reuse of existing TLVs, and procedures defined for Single-Segment Pseudowires (SS-PWs) in [RFC4447]. Dynamic placement of point-to-multipoint (P2MP) PWs is for further study and outside the scope of this document.
本文件的目的是指定对伪线控制协议[RFC4447]和[RFC6073]程序的扩展，以便动态放置多段PW。这些程序遵循[RFC5036]中定义的指南，并允许重用现有TLV，以及[RFC4447]中为单段伪导线（SS PW）定义的程序。点对多点（P2MP）PWs的动态布局有待进一步研究，不在本文件范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
[RFC5659] provides terminology for multi-segment pseudowires.
[RFC5659]提供了多段伪导线的术语。
This document defines the following additional terms:
本文件定义了以下附加术语：
- Source Terminating Provider Edge (ST-PE): A Terminating Provider Edge (T-PE) that assumes the active signaling role and initiates the signaling for multi-segment PWs.
- 源端接提供商边缘（ST-PE）：一种端接提供商边缘（T-PE），承担主动信令角色并为多段PWs启动信令。
- Target Terminating Provider Edge (TT-PE): A Terminating Provider Edge (T-PE) that assumes the passive signaling role. It waits and responds to the multi-segment PW signaling message in the reverse direction.
- 目标端接提供商边缘（TT-PE）：承担被动信令角色的端接提供商边缘（T-PE）。它以相反方向等待并响应多段PW信令消息。
- Forward Direction: ST-PE to TT-PE.
- 前进方向：ST-PE至TT-PE。
- Reverse Direction: TT-PE to ST-PE.
- 反向：TT-PE至ST-PE。
- Pseudowire Routing (PW routing): The dynamic placement of the segments that compose an MS-PW, as well as the automatic selection of Switching PEs (S-PEs).
- 伪线布线（PW布线）：组成MS-PW的段的动态放置，以及开关PE（S-PE）的自动选择。
The following figure shows the reference model, derived from [RFC5659], to support PW emulated services using multi-segment PWs.
下图显示了源于[RFC5659]的参考模型，用于支持使用多段PWs的PW模拟服务。
Native |<---------Multi-Segment Pseudowire-------->| Native
Service | PSN PSN | Service
(AC) | |<--Tunnel-->| |<--Tunnel-->| | (AC)
| V V 1 V V 2 V V |
| +-----+ +-----+ +-----+ |
+---+ | |T-PE1|============|S-PE1|============|T-PE2| | +---+
| |------|...... PW.Seg't 1....X....PW.Seg't 3.......|-------| |
|CE1| | | | | | | | | |CE2|
| |------|...... PW.Seg't 2....X....PW.Seg't 4.......|-------| |
+---+ | | |============| |============| | | +---+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| | |
| | |
| PW switching point |
| |
|<-------------------- Emulated Service ------------------>|
Native |<---------Multi-Segment Pseudowire-------->| Native
Service | PSN PSN | Service
(AC) | |<--Tunnel-->| |<--Tunnel-->| | (AC)
| V V 1 V V 2 V V |
| +-----+ +-----+ +-----+ |
+---+ | |T-PE1|============|S-PE1|============|T-PE2| | +---+
| |------|...... PW.Seg't 1....X....PW.Seg't 3.......|-------| |
|CE1| | | | | | | | | |CE2|
| |------|...... PW.Seg't 2....X....PW.Seg't 4.......|-------| |
+---+ | | |============| |============| | | +---+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| | |
| | |
| PW switching point |
| |
|<-------------------- Emulated Service ------------------>|
Figure 1: MS-PW Reference Model
图1:MS-PW参考模型
The PEs that provide services to CE1 and CE2 are Terminating PE1 (T-PE1) and Terminating PE2 (T-PE2), respectively. A PSN tunnel extends from T-PE1 to Switching PE1 (S-PE1), and a second PSN tunnel extends from S-PE1 to T-PE2 . PWs are used to connect the attachment circuits (ACs) attached to PE1 to the corresponding ACs attached to T-PE2.
向CE1和CE2提供服务的PEs分别为端接PE1（T-PE1）和端接PE2（T-PE2）。PSN隧道从T-PE1延伸到交换PE1（S-PE1），第二个PSN隧道从S-PE1延伸到T-PE2。PW用于将连接至PE1的连接电路（ACs）连接至连接至T-PE2的相应ACs。
A PW segment on PSN Tunnel 1 is connected to a PW segment on PSN Tunnel 2 at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching point and is referred to as the switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are segments of the same MS-PW, while PW Segment 2 and PW Segment 4 are segments of another MS-PW. PW segments of the same MS-PW (e.g., PW Segment 1 and PW Segment 3) MUST be of the same PW type, and PSN tunnels can be of the same or a different technology. An S-PE switches an MS-PW from one segment to another based on the PW identifiers (PWid, or Attachment Individual Identifier (AII)). How
PSN隧道1上的PW段连接至S-PE1处PSN隧道2上的PW段，以完成T-PE1和T-PE2之间的多段PW（MS-PW）。因此，S-PE1是PW交换点，被称为交换提供商边缘（S-PE）。PW段1和PW段3是同一MS-PW的段，而PW段2和PW段4是另一MS-PW的段。相同MS-PW的PW段（例如PW段1和PW段3）必须具有相同的PW类型，并且PSN隧道可以具有相同或不同的技术。S-PE基于PW标识符（PWid或附件个人标识符（AII））将MS-PW从一个段切换到另一个段。怎样
the PW protocol data units (PDUs) are switched at the S-PE depends on the PSN tunnel technology: in the case of a Multiprotocol Label Switching (MPLS) PSN to another MPLS PSN, PW switching involves a standard MPLS label swap operation.
PW协议数据单元（PDU）在S-PE处交换取决于PSN隧道技术：在多协议标签交换（MPLS）PSN到另一个MPLS PSN的情况下，PW交换涉及标准MPLS标签交换操作。
Note that although Figure 1 only shows a single S-PE, a PW may transit more than one S-PE along its path. Although [RFC5659] describes MS-PWs that span more than one PSN, this document does not specify how the Label Distribution Protocol (LDP) is used for PW control [RFC4447] in an inter-AS (Autonomous System) environment.
请注意，尽管图1仅显示了一个S-PE，但PW可能会沿着其路径传输多个S-PE。尽管[RFC5659]描述了跨越多个PSN的MS PW，但本文件并未规定如何在AS（自治系统）间环境中将标签分发协议（LDP）用于PW控制[RFC4447]。
This document describes the case where the PSNs carrying the MS-PW are only MPLS PSNs using the Generalized Pseudowire Identifier (PWid) Forwarding Equivalence Class (FEC) element (also known as FEC 129).
本文档描述了承载MS-PW的PSN仅是使用通用伪线标识符（PWid）转发等价类（FEC）元素（也称为FEC 129）的MPLS PSN的情况。
Interactions with an IP PSN using the Layer 2 Tunneling Protocol version 3 (L2TPv3) as described in Section 8 of [RFC6073] are left for further study.
如[RFC6073]第8节所述，使用第2层隧道协议版本3（L2TPv3）与IP PSN的交互留作进一步研究。
The procedures described in this document make use of existing LDP TLVs and related PW signaling procedures described in [RFC4447] and [RFC6073]. The following optional TLV is also defined:
本文件中描述的程序利用了[RFC4447]和[RFC6073]中描述的现有LDP TLV和相关PW信令程序。还定义了以下可选TLV：
- A Bandwidth TLV to address QoS Signaling requirements (see Section 4.2).
- 用于满足QoS信令要求的带宽TLV（见第4.2节）。
This document also updates the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.
本文件还将PW开关点PE Sub TLV类型0x06的长度字段值更新为14。
Single-segment pseudowires on an MPLS PSN can use attachment circuit identifiers for a PW using FEC 129. In the case of a dynamically placed MS-PW, there is a requirement for the attachment circuit identifiers to be globally unique, for the purposes of reachability and manageability of the PW. Referencing Figure 1 above, individual globally unique addresses MUST be allocated to all the ACs and S-PEs of an MS-PW.
MPLS PSN上的单段伪线可以使用FEC 129为PW使用连接电路标识符。在动态放置的MS-PW的情况下，为了PW的可达性和可管理性，要求附件电路标识符是全局唯一的。参考上面的图1，单个全局唯一地址必须分配给MS-PW的所有ACs和S-PE。
The attachment circuit addressing is derived from AII Type 2 [RFC5003], as shown here:
附件电路寻址源自AII类型2[RFC5003]，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (continued) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (continued) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (continued) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (continued) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AII Type 2 TLV Structure
图2:AII 2型TLV结构
The fields are defined in Section 3.2 of [RFC5003].
[RFC5003]第3.2节定义了这些字段。
Addressing schemes based on AII Type 2 permit varying levels of AII summarization, thus reducing the scaling burden on PW routing. PW addressing based on AII Type 2 is suitable for point-to-point provisioning models where auto-discovery of the address at the TT-PE is not required. That is, it is known a priori by provisioning.
基于AII类型2的寻址方案允许不同级别的AII摘要，从而减少PW路由的扩展负担。基于AII类型2的PW寻址适用于不需要在TT-PE自动发现地址的点对点供应模型。也就是说，它是通过设置而预先知道的。
Implementations of the following procedure MUST interpret the AII type to determine the meaning of the address format of the AII, irrespective of the number of segments in the MS-PW. All segments of the PW MUST be signaled with the same AII type.
以下过程的实现必须解释AII类型，以确定AII地址格式的含义，而与MS-PW中的段数无关。PW的所有段必须使用相同的AII类型发出信号。
A unique combination of Global ID, Prefix, and AC ID parts of the AII Type 2 are assigned to each AC. In general, the same Global ID and Prefix are be assigned for all ACs belonging to the same T-PE. This is not a strict requirement, however. A particular T-PE might have more than one Prefix assigned to it, and likewise a fully qualified AII with the same Global ID/Prefix but different AC IDs might belong to different T-PEs.
将AII类型2的全局ID、前缀和AC ID部分的唯一组合分配给每个AC。通常，为属于相同T-PE的所有AC分配相同的全局ID和前缀。然而，这不是一个严格的要求。一个特定的T-PE可能分配了多个前缀，同样，具有相同全局ID/前缀但不同AC ID的完全限定AII可能属于不同的T-PE。
For the purpose of MS-PWs, the AII MUST be globally unique across all PSNs that are spanned by the MS-PW.
就MS-PW而言，AII在MS-PW跨越的所有PSN中必须是全局唯一的。
The AII for a local attachment circuit of a given T-PE of an MS-PW and the AII of the corresponding attachment circuit on a far-end T-PE (with respect to the LDP signaling) are known as the Source Attachment Individual Identifier (SAII) and Target Attachment Individual Identifier (TAII) as per [RFC6074].
根据[RFC6074]，MS-PW给定T-PE的本地连接电路的AII和远端T-PE上相应连接电路的AII（关于LDP信令）称为源连接个体标识符（SAII）和目标连接个体标识符（TAII）。
Each S-PE MUST be assigned an address that uniquely identifies it from a pseudowire perspective, in order to populate the PW Switching Point PE (SP-PE) TLV specified in [RFC6073]. For this purpose, at least one Attachment Identifier (AI) address of the format similar to AII Type 2 [RFC5003] composed of the Global ID, and Prefix part, only, MUST be assigned to each S-PE.
为了填充[RFC6073]中规定的PW开关点PE（SP-PE）TLV，必须为每个S-PE分配一个从伪线角度唯一标识它的地址。为此，必须为每个S-PE分配至少一个附件标识符（AI）地址，其格式类似于AII类型2[RFC5003]，仅由全局ID和前缀部分组成。
If an S-PE is capable of dynamic MS-PW signaling but is not assigned with an S-PE address, then on receiving a dynamic MS-PW Label Mapping message the S-PE MUST return a Label Release with the "Resources Unavailable" (0x38) status code.
如果S-PE能够动态MS-PW信令，但未分配S-PE地址，则在收到动态MS-PW标签映射消息时，S-PE必须返回带有“资源不可用”（0x38）状态代码的标签释放。
[RFC6073] describes a procedure for concatenating multiple pseudowires together. This procedure requires each S-PE to be manually configured with the information required for each segment of the MS-PW. The procedures in the following sections describe a method to extend [RFC6073] by allowing the automatic selection of predefined S-PEs and dynamically establishing an MS-PW between two T-PEs.
[RFC6073]描述了将多条伪线连接在一起的过程。本程序要求每个S-PE手动配置MS-PW各段所需的信息。以下章节中的程序描述了通过允许自动选择预定义的S-PE并在两个T-PE之间动态建立MS-PW来扩展[RFC6073]的方法。
The AII Type 2 described above contains a Global ID, Prefix, and AC ID. The TAII is used by S-PEs to determine the next SS-PW destination for LDP signaling.
上述AII类型2包含全局ID、前缀和AC ID。S-PEs使用TAII确定LDP信令的下一个SS-PW目的地。
Once an S-PE receives an MS-PW Label Mapping message containing a TAII with an AII that is not locally present, the S-PE performs a lookup in a PW AII routing table. If this lookup results in an IP address for the next-hop PE with reachability information for the AII in question, then the S-PE will initiate the necessary LDP messaging procedure to set up the next PW segment. If the PW AII routing table lookup does not result in an IP address for a next-hop PE, the destination AII has become unreachable, and the PW setup MUST fail. In this case, the next PW segment is considered unprovisioned, and a Label Release MUST be returned to the T-PE with a status message of "AII Unreachable".
一旦S-PE接收到MS-PW标签映射消息，该消息包含具有不在本地存在的AII的TAII，S-PE将在PW AII路由表中执行查找。如果该查找导致下一跳PE的IP地址具有相关AII的可达性信息，则S-PE将启动必要的LDP消息传递过程以设置下一PW段。如果PW AII路由表查找未导致下一跳PE的IP地址，则目标AII已无法访问，PW设置必须失败。在这种情况下，下一个PW段被视为未设置，标签发布必须返回给T-PE，状态消息为“AII Unreachable”。
If the TAII of an MS-PW Label Mapping message received by a PE contains the Prefix matching the locally provisioned prefix on that PE but an AC ID that is not provisioned, then the LDP liberal label retention procedures apply, and the Label Mapping message is retained.
如果由PE接收的MS-PW标签映射消息的TAII包含与该PE上本地设置的前缀匹配的前缀，但包含未设置的AC ID，则LDP自由标签保留过程适用，并且标签映射消息被保留。
To allow for dynamic end-to-end signaling of MS-PWs, information MUST be present in S-PEs to support the determination of the next PW signaling hop. Such information can be provisioned (equivalent to a static route) on each S-PE, or disseminated via regular routing protocols (e.g., BGP).
为了允许MS PWs的动态端到端信令，S-PEs中必须存在信息，以支持确定下一个PW信令跳。这些信息可以在每个S-PE上提供（相当于静态路由），或者通过常规路由协议（例如BGP）传播。
All PEs capable of dynamic MS-PW path selection MUST build a PW AII routing table to be used for PW next-hop selection.
所有能够动态MS-PW路径选择的PE必须建立PW AII路由表，用于PW下一跳选择。
The PW addressing scheme (AII Type 2 as defined in [RFC5003]) consists of a Global ID, a 32-bit Prefix, and a 32-bit Attachment Circuit ID.
PW寻址方案（在[RFC5003]中定义的AII类型2）由一个全局ID、一个32位前缀和一个32位连接电路ID组成。
An aggregation scheme similar to that used for classless IPv4 addresses can be employed. A length mask (8 bits) is specified as a number ranging from 0 to 96 that indicates which Most Significant Bits (MSBs) are relevant in the address field when performing the PW address-matching algorithm.
可以采用类似于用于无类IPv4地址的聚合方案。长度掩码（8位）指定为0到96之间的数字，指示在执行PW地址匹配算法时地址字段中哪些最高有效位（MSB）相关。
0 31 32 63 64 95 (bits)
+-----------+--------+--------+
| Global ID | Prefix | AC ID |
+-----------+--------+--------+
0 31 32 63 64 95 (bits)
+-----------+--------+--------+
| Global ID | Prefix | AC ID |
+-----------+--------+--------+
Figure 3: PW Addressing Scheme
图3:PW寻址方案
During the signaling phase, the content of the (fully qualified) TAII Type 2 field from the FEC 129 TLV is compared against routes from the PW routing table. Similar to the IPv4 case, the route with the longest match is selected, determining the next signaling hop and implicitly the next PW segment to be signaled.
在信令阶段，将来自FEC 129 TLV的（完全合格的）TAII Type 2字段的内容与来自PW路由表的路由进行比较。与IPv4情况类似，选择最长匹配的路由，确定下一个信令跳，并隐式地确定下一个要信令的PW段。
For the purpose of determining the next signaling hop for a segment of the pseudowire, the PEs MAY be provisioned with fixed-route entries in the PW next-hop routing table. The static PW entries will follow all the addressing rules and aggregation rules described in the previous sections. The most common use of PW static provisioned routes is this example of the "default" route entry as follows:
为了确定伪线段的下一信令跳，可以在PW下一跳路由表中为PEs提供固定路由条目。静态PW条目将遵循前面章节中描述的所有寻址规则和聚合规则。PW静态配置路由最常见的用法是“默认”路由条目的示例，如下所示：
Global ID = 0 Prefix = 0 AC ID = 0, Prefix Length = 0
Next Signaling Hop = {IP Address of next-hop S-PE or T-PE}
Global ID = 0 Prefix = 0 AC ID = 0, Prefix Length = 0
Next Signaling Hop = {IP Address of next-hop S-PE or T-PE}
Any suitable routing protocol capable of carrying external routing information MAY be used to propagate MS-PW path information among S-PEs and T-PEs. However, T-PEs and S-PEs MAY choose to use the Border Gateway Protocol (BGP) [RFC4271] with the Multiprotocol Extensions as defined in [RFC4760] to propagate PW address information throughout the PSN. PW address information is only propagated by PEs that are capable of PW switching. Therefore, the multiprotocol BGP neighbor topology MUST coincide with the topology of T-PEs and S-PEs.
可以使用能够承载外部路由信息的任何合适的路由协议在S-PEs和T-PEs之间传播MS-PW路径信息。然而，T-PEs和S-PEs可以选择使用边界网关协议（BGP）[RFC4271]和[RFC4760]中定义的多协议扩展，在整个PSN中传播PW地址信息。PW地址信息仅由能够进行PW切换的PE传播。因此，多协议BGP邻居拓扑必须与T-PEs和S-PEs的拓扑一致。
Contrary to Layer 2 VPN signaling methods that use BGP for auto-discovery [RFC6074], in the case of the dynamically placed MS-PW, the source T-PE knows a priori (by provisioning) the AC ID on the terminating T-PE that signaling should use. Hence, there is no need to advertise a "fully qualified" 96-bit address on a per-PW attachment circuit basis. Only the T-PE Global ID, Prefix, and prefix length need to be advertised as part of well-known BGP procedures; see [RFC4760].
与使用BGP进行自动发现[RFC6074]的第2层VPN信令方法相反，在动态放置MS-PW的情况下，源T-PE（通过设置）预先知道信令应使用的终端T-PE上的AC ID。因此，不需要在每个PW连接电路的基础上公布“完全合格”96位地址。作为众所周知的BGP程序的一部分，只需公布T-PE全局ID、前缀和前缀长度；参见[RFC4760]。
Since PW Endpoints are provisioned in the T-PEs, the ST-PE will use this information to obtain the first S-PE hop (i.e., first BGP next hop) to where the first PW segment will be established. Any subsequent S-PEs will use the same information (i.e., the next BGP next hop(s)) to obtain the next signaling hop(s) on the path to the TT-PE.
由于在T-PEs中设置了PW端点，因此ST-PE将使用该信息来获得第一个S-PE跳（即，第一个BGP下一跳），以建立第一PW段。任何后续S-PE将使用相同的信息（即，下一个BGP下一跳）来获得TT-PE路径上的下一个信令跳。
The PW dynamic path Network Layer Reachability Information (NLRI) is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The {AFI, SAFI} value pair used to identify this NLRI is (AFI=25, SAFI=6). A route target MAY also be advertised along with the NLRI.
PW动态路径网络层可达性信息（NLRI）使用MP_REACH_NLRI和MP_UNREACH_NLRI属性在BGP更新消息中公布[RFC4760]。用于标识此NLRI的{AFI，SAFI}值对为（AFI=25，SAFI=6）。路由目标也可以与NLRI一起公布。
The Next Hop field of the MP_REACH_NLRI attribute SHALL be interpreted as an IPv4 address whenever the length of the NextHop address is 4 octets, and as an IPv6 address whenever the length of the NextHop address is 16 octets.
MP_REACH_NLRI属性的下一跳字段应在下一跳地址长度为4个八位字节时解释为IPv4地址，在下一跳地址长度为16个八位字节时解释为IPv6地址。
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix comprising an 8-octet Route Distinguisher, the Global ID, the Prefix, and the AC ID, and encoded as defined in Section 4 of [RFC4760].
MP_REACH_NLRI和MP_UNREACH_NLRI中的NLRI字段是一个前缀，包含8个八位组的路由标识符、全局ID、前缀和AC ID，并按照[RFC4760]第4节中的定义进行编码。
This NLRI is structured as follows:
本NLRI的结构如下所示：
Bit
0 7 8 71 72 103 104 135 136 167
+------+----------------+-----------+--------+--------+
|Length| Route Dist | Global ID | Prefix | AC ID |
+------+----------------+-----------+--------+--------+
Bit
0 7 8 71 72 103 104 135 136 167
+------+----------------+-----------+--------+--------+
|Length| Route Dist | Global ID | Prefix | AC ID |
+------+----------------+-----------+--------+--------+
Figure 4: NLRI Field Structure
图4:NLRI字段结构
The Length field is the prefix length of the Route Distinguisher + Global ID + Prefix + AC ID in bits.
长度字段是路由识别器的前缀长度+全局ID+前缀+AC ID（以位为单位）。
Except for the default PW route, which is encoded as a 0-length Prefix, the minimum value of the Length field is 96 bits. Lengths of 128 bits to 159 bits are invalid, as the AC ID field cannot be aggregated. The maximum value of the Length field is 160 bits. BGP advertisements received with invalid Prefix lengths MUST be rejected as having a bad packet format.
除了默认PW路由（编码为0长度前缀）之外，长度字段的最小值为96位。128位到159位的长度无效，因为无法聚合AC ID字段。长度字段的最大值为160位。接收到的具有无效前缀长度的BGP播发必须被拒绝，因为它具有错误的数据包格式。
The LDP signaling procedures are described in [RFC4447] and expanded in [RFC6073]. No new LDP signaling components are required for setting up a dynamically placed MS-PW. However, some optional signaling extensions are described below.
LDP信令过程在[RFC4447]中进行了描述，并在[RFC6073]中进行了扩展。建立动态放置的MS-PW不需要新的LDP信令组件。然而，下面描述一些可选的信令扩展。
One of the requirements that MUST be met in order to achieve the QoS objectives for a PW on a segment is that a PSN tunnel MUST be selected that can support at least the required class of service and that has sufficient bandwidth available.
为了实现段上PW的QoS目标，必须满足的要求之一是必须选择至少能够支持所需服务类别且具有足够可用带宽的PSN隧道。
Such PSN tunnel selection can be achieved where the next hop for a PW segment is explicitly configured at each PE, whether the PE is a T-PE or an S-PE in the case of a segmented PW, without dynamic path selection (as per [RFC6073]). In these cases, it is possible to explicitly configure the bandwidth required for a PW so that the T-PE or S-PE can reserve that bandwidth on the PSN tunnel.
这种PSN隧道选择可以在每个PE明确配置PW段的下一跳的情况下实现，无论PE是T-PE还是S-PE（在分段PW的情况下），无需动态路径选择（根据[RFC6073]）。在这些情况下，可以显式配置PW所需的带宽，以便T-PE或S-PE可以在PSN隧道上保留该带宽。
Where dynamic path selection is used and the next hop is therefore not explicitly configured by the operator at the S-PE, a mechanism to signal the bandwidth for the PW from the T-PE to the S-PEs is required. This is accomplished by including an optional PW Bandwidth TLV. The PW Bandwidth TLV is specified as follows:
在使用动态路径选择并且因此没有由S-PE处的操作员明确配置下一跳的情况下，需要一种从T-PE向S-PE发送PW带宽信号的机制。这是通过包括可选PW带宽TLV来实现的。PW带宽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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW BW TLV (0x096E) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW BW TLV (0x096E) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PW Bandwidth TLV Structure
图5:PW带宽TLV结构
The PW Bandwidth TLV fields are as follows:
PW带宽TLV字段如下所示：
- TLV Length: The length of the value fields in octets. Value = 64.
- TLV长度：值字段的长度（以八位字节为单位）。值=64。
- Forward SENDER_TSPEC = the SENDER_TSPEC for the forward direction of the PW, as defined in Section 3.1 of [RFC2210].
- 正向发送器_TSPEC=PW正向的发送器_TSPEC，如[RFC2210]第3.1节所定义。
- Reverse SENDER_TSPEC = the SENDER_TSPEC for the reverse direction of the PW, as defined in Section 3.1 of [RFC2210].
- 反向发送器_TSPEC=PW反向的发送器_TSPEC，如[RFC2210]第3.1节所定义。
The complete definitions of the content of the SENDER_TSPEC objects are found in Section 3.1 of [RFC2210]. The forward SENDER_TSPEC refers to the data path in the direction ST-PE to TT-PE. The reverse SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE.
发送方_TSPEC对象内容的完整定义见[RFC2210]第3.1节。前向发送器_TSPEC指ST-PE到TT-PE方向上的数据路径。反向发送器_TSPEC指TT-PE到ST-PE方向上的数据路径。
In the forward direction, after a next-hop selection is determined, a T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine an appropriate PSN tunnel towards the next signaling hop. If such a tunnel exists, the MS-PW signaling procedures are invoked with the inclusion of the PW Bandwidth TLV. When the PE searches for a PSN tunnel, any tunnel that points to a next hop equivalent to the next hop selected will be included in the search (the LDP address TLV is used to determine the next-hop equivalence).
在前进方向上，在确定下一跳选择之后，T/S-PE应参考前向发送方_TSPEC对象以确定朝向下一信令跳的适当PSN隧道。如果存在这样的隧道，则调用MS-PW信令过程，包括PW带宽TLV。当PE搜索PSN隧道时，指向与所选下一跳等效的下一跳的任何隧道都将包括在搜索中（LDP地址TLV用于确定下一跳等效）。
When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is selected, the S/T-PE MUST request the appropriate resources from the PSN. The resources described in the reverse SENDER_TSPEC are allocated from the PSN toward the originator of the message or
当S/T-PE接收到PW带宽TLV时，一旦选择了PW下一跳，S/T-PE必须从PSN请求适当的资源。反向发送方_TSPEC中描述的资源从PSN分配给消息或消息的发起方
previous hop. When resources are allocated from the PSN for a specific PW, the allocation SHOULD account for the resource usage of the PW.
上一跳。当从PSN为特定PW分配资源时，分配应考虑PW的资源使用情况。
In the case where PSN resources towards the previous hop are not available, the following procedure MUST be followed:
如果前一跳的PSN资源不可用，则必须遵循以下步骤：
i. The PSN MAY allocate more QoS resources, e.g., bandwidth, to the PSN tunnel.
i. PSN可以向PSN隧道分配更多QoS资源，例如带宽。
ii. The S-PE MAY attempt to set up another PSN tunnel to accommodate the new PW QoS requirements.
二,。S-PE可尝试建立另一个PSN隧道，以适应新的PW QoS要求。
iii. If the S-PE cannot get enough resources to set up the segment in the MS-PW, a Label Release MUST be returned to the previous hop with a status message of "Bandwidth resources unavailable".
iii.如果S-PE无法获得足够的资源来设置MS-PW中的段，则必须将标签释放返回到上一个跃点，状态消息为“带宽资源不可用”。
In the latter case, the T-PE receiving the status message MUST also withdraw the corresponding PW Label Mapping message for the opposite direction if it has already been successfully set up.
在后一种情况下，接收状态消息的T-PE还必须为相反方向撤回相应的PW标签映射消息（如果已成功设置）。
If an ST-PE receives a Label Mapping message, the following procedure MUST be followed:
如果ST-PE收到标签映射消息，则必须遵循以下步骤：
If the ST-PE has already sent a Label Mapping message for this PW, then the ST-PE MUST check to see if this Label Mapping message originated from the same LDP peer to which the corresponding Label Mapping message for this particular PW was sent. If it is the same peer, the PW is established. If it is a different peer, then the ST-PE MUST send a Label Release message with a status code of "PW Loop Detected" to the PE that originated the LDP Label Mapping message.
如果ST-PE已经为此PW发送了标签映射消息，则ST-PE必须检查此标签映射消息是否来自发送此特定PW的相应标签映射消息的同一LDP对等方。如果是同一对等方，则建立PW。如果是不同的对等方，则ST-PE必须向发起LDP标签映射消息的PE发送状态代码为“PW Loop Detected”的标签释放消息。
If the PE has not yet sent a Label Mapping message for this particular PW, then it MUST send the Label Mapping message to this LDP peer, regardless of what the PW TAII routing lookup result is.
如果PE尚未为此特定PW发送标签映射消息，则无论PW TAII路由查找结果如何，它必须将标签映射消息发送到此LDP对等方。
A next-hop selection for a specific PW may find a match with a PW route that has multiple next hops associated with it. Multiple next hops may be either configured explicitly as static routes or learned through BGP routing procedures. Implementations at an S-PE or T-PE MAY use selection algorithms, such as CRC32 on the FEC TLV or flow-aware transport of PWs [RFC6391], for load balancing of PWs across multiple next hops, so that each PW has a single next hop. The details of such selection algorithms are outside the scope of this document.
特定PW的下一跳选择可能会找到与具有多个下一跳关联的PW路由的匹配。多个下一跳可以显式配置为静态路由，也可以通过BGP路由过程学习。在S-PE或T-PE上的实现可以使用选择算法，例如FEC TLV上的CRC32或PWs的流感知传输[RFC6391]，用于跨多个下一跳对PWs进行负载平衡，以便每个PW具有单个下一跳。此类选择算法的详细信息不在本文件范围内。
When an MS-PW is signaled, each T-PE might independently initiate signaling the MS-PW. This could result in a different path being used by each direction of the PW. To avoid this situation, one T-PE MUST initiate PW signaling (i.e., take an active role), while the other T-PE waits to receive the LDP Label Mapping message before sending the LDP Label Mapping message for the reverse direction of the PW (i.e., take a passive role). The active T-PE (the ST-PE) and the passive T-PE (the TT-PE) MUST be identified before signaling begins for a given MS-PW. Both T-PEs MUST use the same method for identifying which is active and which is passive.
当MS-PW发信号时，每个T-PE可以独立地启动MS-PW发信号。这可能导致PW的每个方向使用不同的路径。为了避免这种情况，一个T-PE必须启动PW信令（即，扮演主动角色），而另一个T-PE在发送用于PW反向的LDP标签映射消息之前等待接收LDP标签映射消息（即，扮演被动角色）。在给定MS-PW的信令开始之前，必须识别有源T-PE（ST-PE）和无源T-PE（TT-PE）。两个T-PE必须使用相同的方法来识别哪个是主动的，哪个是被动的。
A T-PE SHOULD determine whether it assumes the active role or the passive role using procedures similar to those of [RFC5036], Section 2.5.2, Bullet 2. The T-PE compares the Source Attachment Individual Identifier (SAII) [RFC6074] with the Target Attachment Individual Identifier (TAII) [RFC6074] as unsigned integers, and if the SAII > TAII, the T-PE assumes the active role. Otherwise, it assumes the passive role.
T-PE应使用与[RFC5036]第2.5.2节，项目符号2类似的程序确定其承担主动角色还是被动角色。T-PE将源附件个体标识符（SAII）[RFC6074]与目标附件个体标识符（TAII）[RFC6074]作为无符号整数进行比较，如果SAII>TAII，T-PE将承担活动角色。否则，它将扮演被动角色。
The following procedure for comparing the SAII and TAII as unsigned integers SHOULD be used:
应使用以下程序将SAII和TAII作为无符号整数进行比较：
- If the SAII Global ID > TAII Global ID, then the T-PE is active
- 如果SAII全局ID>TAII全局ID，则T-PE处于活动状态
- else if the SAII Global ID < TAII Global ID, then the T-PE is passive
- 否则，如果SAII全局ID<TAII全局ID，则T-PE是被动的
- else if the SAII Prefix > TAII Prefix, then the T-PE is active
- 否则，如果SAII前缀>TAII前缀，则T-PE处于活动状态
- else if the SAII Prefix < TAII Prefix, then the T-PE is passive
- 否则，如果SAII前缀<TAII前缀，则T-PE是被动的
- else if the SAII AC ID > TAII AC ID, then the T-PE is active
- 否则，如果SAII AC ID>TAII AC ID，则T-PE处于活动状态
- else if the SAII AC ID < TAII AC ID, then the T-PE is passive
- 否则，如果SAII AC ID<TAII AC ID，则T-PE是被动的
- else there is a configuration error
- 否则会出现配置错误
On receiving a Label Mapping message, the S-PE MUST inspect the FEC TLV. If the receiving node has no local AII matching the TAII for that Label Mapping message, then the Label Mapping message SHOULD be forwarded on to another S-PE or T-PE. The S-PE will check to see if the FEC is already installed for the forward direction:
收到标签映射消息后，S-PE必须检查FEC TLV。如果接收节点没有与标签映射消息的TAII匹配的本地AII，则标签映射消息应转发到另一个S-PE或T-PE。S-PE将检查前向是否已安装FEC：
- If the FEC is already installed and the received Label Mapping was received from the same LDP peer to which the forward LDP Label Mapping was sent, then this Label Mapping represents signaling in the reverse direction for this MS-PW segment.
- 如果已经安装了FEC，并且接收到的标签映射是从前向LDP标签映射发送到的同一LDP对等方接收的，则该标签映射表示该MS-PW段的反向信令。
- If the FEC is already installed and the received Label Mapping was received from a different LDP peer to which the forward LDP Label Mapping was sent, then the received Label Mapping MUST be released with a status code of "PW Loop Detected".
- 如果FEC已经安装，并且接收到的标签映射是从发送前向LDP标签映射的不同LDP对等方接收的，则必须释放接收到的标签映射，状态代码为“PW Loop Detected”。
- If the FEC is not already installed, then this represents signaling in the forward direction.
- 如果尚未安装FEC，则这表示正向信令。
The following procedures are then executed, depending on whether the Label Mapping was determined to be for the forward or the reverse direction of the MS-PW.
然后执行以下程序，这取决于标签映射是针对MS-PW的正向还是反向确定的。
For the forward direction:
前进方向：
i. Determine the next-hop S-PE or T-PE according to the procedures above. If next-hop reachability is not found in the S-PE's PW AII routing table, then a Label Release MUST be sent with status code "AII Unreachable". If the next-hop S-PE or T-PE is found and is the same LDP peer that sent the Label Mapping message, then a Label Release MUST be returned with status code "PW Loop Detected". If the SAII in the received Label Mapping is local to the S-PE, then a Label Release MUST be returned with status code "PW Loop Detected".
i. 根据上述步骤确定下一跳的S-PE或T-PE。如果在S-PE的PW AII路由表中未找到下一跳可达性，则必须发送状态代码为“AII Unreachable”的标签释放。如果找到下一跳S-PE或T-PE，并且是发送标签映射消息的同一LDP对等方，则必须返回标签释放，状态代码为“PW Loop Detected”。如果收到的标签映射中的SAII是S-PE本地的，则必须返回标签释放，状态代码为“PW Loop Detected”。
ii. Check to see if a PSN tunnel exists to the next-hop S-PE or T-PE. If no tunnel exists to the next-hop S-PE or T-PE, the S-PE MAY attempt to set up a PSN tunnel.
二,。检查是否存在到下一跳S-PE或T-PE的PSN隧道。如果不存在到下一跳S-PE或T-PE的隧道，则S-PE可尝试建立PSN隧道。
iii. Check to see if a PSN tunnel exists to the previous hop. If no tunnel exists to the previous-hop S-PE or T-PE, the S-PE MAY attempt to set up a PSN tunnel.
iii.检查前一跳是否存在PSN隧道。如果不存在到前一跳S-PE或T-PE的隧道，则S-PE可尝试建立PSN隧道。
iv. If the S-PE cannot get enough PSN resources to set up the segment to the next-hop or previous-hop S-PE or T-PE, a Label Release MUST be returned to the T-PE with a status message of "Resources Unavailable".
iv.如果S-PE无法获得足够的PSN资源来将网段设置到下一跳或上一跳S-PE或T-PE，则必须向T-PE返回标签释放，并显示状态消息“资源不可用”。
v. If the Label Mapping message contains a Bandwidth TLV, allocate the required resources on the PSN tunnels in the forward and reverse directions according to the procedures above.
v. 如果标签映射消息包含带宽TLV，请按照上述步骤在PSN隧道的正向和反向上分配所需的资源。
vi. Allocate a new PW label for the forward direction.
vi.为前进方向分配一个新的PW标签。
vii. Install the FEC for the forward direction.
七,。安装前进方向的FEC。
viii. Send the Label Mapping message with the new forward label and the FEC to the next-hop S-PE/T-PE.
八,。将带有新转发标签和FEC的标签映射消息发送到下一跳S-PE/T-PE。
For the reverse direction:
对于反向：
i. Install the FEC received in the Label Mapping message for the reverse direction.
i. 安装反向标签映射消息中接收到的FEC。
ii. Determine the next signaling hop by referencing the LDP sessions used to set up the PW in the forward direction.
二,。通过参考用于在前进方向上设置PW的LDP会话来确定下一个信令跳。
iii. Allocate a new PW label for the next hop in the reverse direction.
iii.为反向的下一跳分配一个新的PW标签。
iv. Install the FEC for the next hop in the reverse direction.
iv.以相反方向安装下一跳的FEC。
v. Send the Label Mapping message with a new label and the FEC to the next-hop S-PE/ST-PE.
v. 将带有新标签和FEC的标签映射消息发送到下一跳S-PE/ST-PE。
Failures of the PSN tunnel MUST be handled by PSN mechanisms. An example of such a PSN mechanism is MPLS fast reroute [RFC4090]. If the PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD follow the procedures defined in Section 10 of [RFC6073].
PSN隧道的故障必须由PSN机制处理。这种PSN机制的一个例子是MPLS快速重路由[RFC4090]。如果PSN无法重建PSN隧道，则S-PE应遵循[RFC6073]第10节中规定的程序。
For defects in an S-PE, the procedures defined in [RFC6073] SHOULD be followed. A T-PE or S-PE may receive an unsolicited Label Release message from another S-PE or T-PE with various failure codes, such as "Loop Detected", "PW Loop Detected", "Resources Unavailable", "Bad Strict Node Error", or "AII Unreachable". All these failure codes indicate a generic class of PW failures at an S-PE or T-PE.
对于S-PE中的缺陷，应遵循[RFC6073]中规定的程序。T-PE或S-PE可从另一S-PE或T-PE接收具有各种故障代码的未经请求的标签释放消息，例如“检测到循环”、“检测到PW循环”、“资源不可用”、“严重节点错误”或“AII不可访问”。所有这些故障代码都表示S-PE或T-PE的PW故障的一般类别。
If an unsolicited Label Release message with such a failure status code is received at a T-PE, then it is RECOMMENDED that the T-PE attempt to re-establish the PW immediately. However, the T-PE MUST throttle its PW setup message retry attempts with an exponential backoff in situations where PW setup messages are being constantly released. It is also RECOMMENDED that a T-PE detecting such a situation take action to notify an operator.
如果T-PE收到带有此类故障状态代码的未经请求的标签发布消息，则建议T-PE立即尝试重新建立PW。然而，在PW设置消息不断被释放的情况下，T-PE必须通过指数退避来限制其PW设置消息重试尝试。还建议检测到这种情况的T-PE采取行动通知操作员。
S-PEs that receive an unsolicited Label Release message with a failure status code SHOULD follow this procedure:
接收带有故障状态代码的未经请求的标签发布消息的S-PEs应遵循以下程序：
i. If the Label Release is received from an S-PE or T-PE in the forward or reverse signaling direction, then the S-PE MUST tear down both segments of the PW. The status code received in the Label Release message SHOULD be propagated when sending the Label Release for the next segment.
i. 如果在正向或反向信令方向上从S-PE或T-PE接收到标签释放，则S-PE必须拆除PW的两个段。在发送下一段的标签发布时，应传播标签发布消息中接收到的状态代码。
In general, an established MS-PW will not be affected by next-hop changes in AII reachability information.
通常，已建立的MS-PW不会受到AII可达性信息中下一跳变化的影响。
If there is a next-hop change in AII reachability information in the forward direction, the T-PE MAY elect to tear down the MS-PW by sending a Label Withdraw message to the downstream S-PE or T-PE. The teardown MUST also be accompanied by an unsolicited Label Release message and will be followed by an attempt by the T-PE to re-establish the MS-PW.
如果在前进方向上AII可达性信息中存在下一跳改变，则T-PE可以选择通过向下游S-PE或T-PE发送标签撤回消息来拆除MS-PW。拆卸还必须伴随一条未经请求的标签发布消息，随后T-PE将尝试重新建立MS-PW。
If there is a change in the AII reachability information in the forward direction at an S-PE, the S-PE MAY elect to tear down the MS-PW in both directions. A label withdrawal is sent in each direction followed by an unsolicited Label Release. The unsolicited Label Release messages MUST be accompanied by the status code "AII Unreachable". This procedure is OPTIONAL. Note that this procedure is likely to be disruptive to the emulated service. PW Redundancy [RFC6718] MAY be used to maintain the connectivity used by the emulated service in the case of a failure of the PSN or S-PE.
如果在S-PE处前向上的AII可达性信息发生变化，则S-PE可以选择在两个方向上拆除MS-PW。标签撤回在每个方向发送，然后是未经请求的标签释放。未经请求的标签发布消息必须附有状态代码“AII Unreachable”。此过程是可选的。请注意，此过程可能会中断模拟服务。PW冗余[RFC6718]可用于在PSN或S-PE发生故障时维持仿真服务使用的连接。
A change in AII reachability information in the reverse direction has no effect on an MS-PW.
在相反方向上所有I可达性信息的变化对MS-PW没有影响。
The OAM procedures defined in [RFC6073] may also be used for dynamically placed MS-PWs. A PW Switching Point PE TLV [RFC6073] is used to record the switching points that the PW traverses.
[RFC6073]中定义的OAM程序也可用于动态放置的MS PW。PW开关点PE TLV[RFC6073]用于记录PW穿过的开关点。
In the case of an MS-PW where the PW Endpoints are identified by using globally unique AII addresses based on FEC 129, there is no pseudowire identifier (PWid) defined on a per-segment basis. Each individual PW segment is identified by the address of the adjacent S-PE(s) in conjunction with the SAII and TAII.
在使用基于FEC 129的全局唯一AII地址来标识PW端点的MS-PW的情况下，不存在基于每段定义的伪线标识符（PWid）。每个单独的PW段由相邻S-PE的地址与SAII和TAII一起标识。
In this case, the following TLV type (0x06) MUST be used in place of type 0x01 in the PW Switching Point PE TLV:
在这种情况下，必须使用以下TLV类型（0x06）代替PW开关点PE TLV中的0x01类型：
Type Length Description
---- ------ -----------------------------------
0x06 14 L2 PW address of PW Switching Point
Type Length Description
---- ------ -----------------------------------
0x06 14 L2 PW address of PW Switching Point
The above sub-TLV MUST be included in the PW Switching Point PE TLV once per individual PW switching point, following the same rules and procedures as those described in [RFC6073]. A more detailed description of this sub-TLV is also given in Section 7.4.1 of [RFC6073]. However, the length value MUST be set to 14 ([RFC6073] states that the length value is 12, but this does not correctly represent the actual length of the TLV).
上述子TLV必须包含在PW开关点PE TLV中，每个PW开关点一次，遵循与[RFC6073]中所述相同的规则和程序。[RFC6073]第7.4.1节也给出了该子TLV的更详细说明。但是，长度值必须设置为14（[RFC6073]表示长度值为12，但这不能正确表示TLV的实际长度）。
This document specifies extensions to the protocols already defined in [RFC4447] and [RFC6073]. The extensions defined in this document do not affect the security considerations for those protocols, but [RFC4447] and [RFC6073] do impose a set of security considerations that are applicable to the protocol extensions specified in this document.
本文件规定了[RFC4447]和[RFC6073]中已经定义的协议的扩展。本文件中定义的扩展不影响这些协议的安全注意事项，但[RFC4447]和[RFC6073]施加了一组适用于本文件中指定的协议扩展的安全注意事项。
It should be noted that the dynamic path selection mechanisms specified in this document enable the network to automatically select the S-PEs that are used to forward packets on the MS-PW. Appropriate tools, such as the Virtual Circuit Connectivity Verification (VCCV) trace mechanisms specified in [RFC6073], can be used by an operator of the network to verify the path taken by the MS-PW and therefore be satisfied that the path does not represent an additional security risk.
应注意，本文件中规定的动态路径选择机制使网络能够自动选择用于在MS-PW上转发数据包的S-PE。网络运营商可使用适当的工具，如[RFC6073]中规定的虚拟电路连通性验证（VCCV）跟踪机制，验证MS-PW所采用的路径，从而确保该路径不代表额外的安全风险。
Note that the PW control protocol may be used to establish and maintain an MS-PW across administrative boundaries. Section 13 of [RFC6073] specifies security considerations applicable to LDP used in this manner, including considerations for establishing the integrity of, and authenticating, LDP control messages. These considerations also apply to the protocol extensions specified in this document.
注意，PW控制协议可用于跨行政边界建立和维护MS-PW。[RFC6073]第13节规定了适用于以这种方式使用的LDP的安全注意事项，包括建立LDP控制消息完整性和认证的注意事项。这些注意事项也适用于本文档中指定的协议扩展。
Note that the protocols for dynamically distributing AII reachability information may have their own security considerations. However, those protocol specifications are outside the scope of this document.
注意，用于动态分发AII可达性信息的协议可能有其自身的安全考虑。但是，这些协议规范不在本文件的范围内。
IANA has corrected a minor error in the "Pseudowire Switching Point PE sub-TLV Type" registry. The entry 0x06 "L2 PW address of the PW Switching Point" has been corrected to Length 14 and the reference changed to [RFC6073] and this document as follows:
IANA已更正“伪线交换点PE sub TLV类型”注册表中的一个小错误。条目0x06“PW开关点的L2 PW地址”已更正为长度14，参考更改为[RFC6073]，本文件如下：
Type Length Description Reference
---- ------ ----------------------------------- ------------------
0x06 14 L2 PW Address of PW Switching Point [RFC6073][RFC7267]
Type Length Description Reference
---- ------ ----------------------------------- ------------------
0x06 14 L2 PW Address of PW Switching Point [RFC6073][RFC7267]
This document defines one new LDP TLV type. IANA already maintains a registry for LDP TLV types, called the "TLV Type Name Space" registry, within the "Label Distribution Protocol (LDP) Parameters" registry as defined by [RFC5036]. IANA has assigned the following value.
本文件定义了一种新的LDP TLV类型。IANA已经在[RFC5036]定义的“标签分发协议（LDP）参数”注册表中维护了LDP TLV类型的注册表，称为“TLV类型名称空间”注册表。IANA已指定以下值。
Value Description Reference Notes/Registration Date
------ ------------- ------------- -----------------------
0x096E Bandwidth TLV This document
Value Description Reference Notes/Registration Date
------ ------------- ------------- -----------------------
0x096E Bandwidth TLV This document
This document defines three new LDP status codes. IANA maintains a registry of these codes, called the "Status Code Name Space" registry, in the "Label Distribution Protocol (LDP) Parameters" registry as defined by [RFC5036]. The IANA has assigned the following values.
本文件定义了三个新的LDP状态码。IANA在[RFC5036]定义的“标签分发协议（LDP）参数”注册表中维护这些代码的注册表，称为“状态代码名称空间”注册表。IANA已分配以下值。
Range/Value E Description Reference
----------- ----- ------------------------------- -------------
0x00000037 0 Bandwidth resources unavailable This document
0x00000038 0 Resources Unavailable This document
0x00000039 0 AII Unreachable This document
Range/Value E Description Reference
----------- ----- ------------------------------- -------------
0x00000037 0 Bandwidth resources unavailable This document
0x00000038 0 Resources Unavailable This document
0x00000039 0 AII Unreachable This document
IANA has allocated a new BGP SAFI for "Network Layer Reachability Information used for Dynamic Placement of Multi-Segment Pseudowires" in the IANA "SAFI Values" registry [RFC4760] within the "Subsequent Address Family Identifiers (SAFI) Parameters" registry. The IANA has assigned the following value.
IANA已为“后续地址族标识符（SAFI）参数”注册表中的IANA“SAFI值”注册表[RFC4760]中的“用于动态放置多段伪线的网络层可达性信息”分配了一个新的BGP SAFI。IANA已指定以下值。
Value Description Reference
----- ------------------------------------------- -------------
6 Network Layer Reachability Information This document
used for Dynamic Placement of Multi-Segment
Pseudowires
Value Description Reference
----- ------------------------------------------- -------------
6 Network Layer Reachability Information This document
used for Dynamic Placement of Multi-Segment
Pseudowires
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[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, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003]Metz，C.，Martini，L.，Balus，F.，和J.Sugimoto，“聚合的附件个人标识符（AII）类型”，RFC 5003，2007年9月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 60732011年1月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254]Bitar，N.，Ed.，Bocci，M.，Ed.，和L.Martini，Ed.，“多段伪线仿真边到边（PWE3）的要求”，RFC 5254，2008年10月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659]Bocci，M.和S.Bryant，“多段伪线边到边仿真的体系结构”，RFC 5659，2009年10月。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，2011年1月。
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6391]Bryant，S.，Ed.，Filsfils，C.，Drafz，U.，Kompella，V.，Regan，J.，和S.Amante，“MPLS分组交换网络上伪线的流感知传输”，RFC 63912011年11月。
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", RFC 6718, August 2012.
[RFC6718]Muley，P.，Aissaoui，M.和M.Bocci，“伪线冗余”，RFC 67182012年8月。
The editors gratefully acknowledge the following people for their contributions to this document:
编辑们感谢以下人士对本文件的贡献：
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 US
美国马萨诸塞州沃尔瑟姆Sylvan路40号Nabil Bitar Verizon 02145
EMail: nabil.bitar@verizon.com
EMail: nabil.bitar@verizon.com
Himanshu Shah Ciena Corp. 35 Nagog Park Acton, MA 01720 US
Himanshu Shah Ciena公司美国马萨诸塞州纳戈公园阿克顿35号01720
EMail: hshah@ciena.com
EMail: hshah@ciena.com
Mustapha Aissaoui Alcatel-Lucent 600 March Road Kanata ON, Canada
Mustapha Aissaoui Alcatel-Lucent 600 March Road Kanata，加拿大
EMail: mustapha.aissaoui@alcatel-lucent.com
EMail: mustapha.aissaoui@alcatel-lucent.com
Jason Rusmisel Alcatel-Lucent 600 March Road Kanata ON, Canada
杰森·罗斯米塞尔阿尔卡特-朗讯加拿大卡纳塔三月路600号
EMail: Jason.rusmisel@alcatel-lucent.com
EMail: Jason.rusmisel@alcatel-lucent.com
Andrew G. Malis Huawei 2330 Central Expressway Santa Clara, CA 95050 US
美国加利福尼亚州圣克拉拉中央高速公路2330号安德鲁·G·马里斯华为95050
EMail: agmalis@gmail.com
EMail: agmalis@gmail.com
Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 US
Chris Metz Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3700号，邮编95134
EMail: chmetz@cisco.com
EMail: chmetz@cisco.com
David McDysan Verizon 22001 Loudoun County Pkwy. Ashburn, VA 20147 US
David McDysan Verizon 22001卢顿县Pkwy。弗吉尼亚州阿什本市20147美国
EMail: dave.mcdysan@verizon.com
EMail: dave.mcdysan@verizon.com
Jeff Sugimoto Alcatel-Lucent 701 E. Middlefield Rd. Mountain View, CA 94043 US
Jeff Sugimoto Alcatel-Lucent美国加利福尼亚州山景城米德菲尔德东路701号，邮编94043
EMail: jeffery.sugimoto@alcatel-lucent.com
EMail: jeffery.sugimoto@alcatel-lucent.com
Mike Loomis Alcatel-Lucent 701 E. Middlefield Rd. Mountain View, CA 94043 US
美国加利福尼亚州山景城米德尔菲尔德东路701号Mike Loomis Alcatel-Lucent 94043
EMail: mike.loomis@alcatel-lucent.com
EMail: mike.loomis@alcatel-lucent.com
The editors also gratefully acknowledge the input of the following people: Paul Doolan, Mike Duckett, Pranjal Dutta, Ping Pan, Prayson Pate, Vasile Radoaca, Yeongil Seo, Yetik Serbest, and Yuichiro Wada.
编辑们还非常感谢以下人士的意见：保罗·杜兰、迈克·达克特、普兰贾尔·杜塔、潘平、佩特、瓦西里·拉多卡、杨吉尔·塞、耶提克·塞维斯特和和和田一郎。
Authors' Addresses
作者地址
Luca Martini (editor) Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US
卢卡·马蒂尼（编辑）思科系统公司，地址：美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Matthew Bocci (editor) Alcatel-Lucent Voyager Place Shoppenhangers Road Maidenhead Berks, UK
Matthew Bocci（编辑）Alcatel-Lucent Voyager Place Shoppenigers Road Maidenhead Berks，英国
EMail: matthew.bocci@alcatel-lucent.com
EMail: matthew.bocci@alcatel-lucent.com
Florin Balus (editor) Alcatel-Lucent 701 E. Middlefield Rd. Mountain View, CA 94043 US
Florin Balus（编辑）美国加利福尼亚州山景城米德菲尔德东路701号阿尔卡特朗讯94043
EMail: florin@nuagenetworks.net
EMail: florin@nuagenetworks.net