Internet Engineering Task Force (IETF) L. Andersson, Ed.
Request for Comments: 6373 Ericsson
Category: Informational L. Berger, Ed.
ISSN: 2070-1721 LabN
L. Fang, Ed.
Cisco
N. Bitar, Ed.
Verizon
E. Gray, Ed.
Ericsson
September 2011
Internet Engineering Task Force (IETF) L. Andersson, Ed.
Request for Comments: 6373 Ericsson
Category: Informational L. Berger, Ed.
ISSN: 2070-1721 LabN
L. Fang, Ed.
Cisco
N. Bitar, Ed.
Verizon
E. Gray, Ed.
Ericsson
September 2011
MPLS Transport Profile (MPLS-TP) Control Plane Framework
MPLS传输配置文件（MPLS-TP）控制平面框架
Abstract
摘要
The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document.
MPLS传输配置文件（MPLS-TP）支持通过网络管理系统（NMS）静态提供传输路径，以及通过控制平面动态提供传输路径。本文档提供了MPLS-TP动态资源调配框架，涵盖了控制平面寻址、路由、路径计算、信令、流量工程和路径恢复。MPLS-TP使用GMPLS作为MPLS-TP标签交换路径（LSP）的控制平面。MPLS-TP还将伪线（PW）控制平面用于伪线。管理平面功能不在本文件范围内。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
本文件是联合互联网工程任务组（IETF）/国际电信联盟电信标准化部门（ITU-T）努力的成果，旨在将MPLS传输配置文件纳入IETF MPLS和伪线仿真边到边（PWE3）中支持ITU-T定义的分组传输网络的能力和功能的体系结构。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6373.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6373.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
1.1. Scope ......................................................4
1.2. Basic Approach .............................................4
1.3. Reference Model ............................................6
2. Control-Plane Requirements ......................................9
2.1. Primary Requirements .......................................9
2.2. Requirements Derived from the MPLS-TP Framework ...........18
2.3. Requirements Derived from the OAM Framework ...............20
2.4. Security Requirements .....................................25
2.5. Identifier Requirements ...................................25
3. Relationship of PWs and TE LSPs ................................26
4. TE LSPs ........................................................27
4.1. GMPLS Functions and MPLS-TP LSPs ..........................27
4.1.1. In-Band and Out-of-Band Control ....................27
4.1.2. Addressing .........................................29
4.1.3. Routing ............................................29
4.1.4. TE LSPs and Constraint-Based Path Computation ......29
4.1.5. Signaling ..........................................30
4.1.6. Unnumbered Links ...................................30
4.1.7. Link Bundling ......................................30
4.1.8. Hierarchical LSPs ..................................31
4.1.9. LSP Recovery .......................................31
4.1.10. Control-Plane Reference Points (E-NNI,
I-NNI, UNI) .......................................32
4.2. OAM, MEP (Hierarchy), MIP Configuration and Control .......32
4.2.1. Management-Plane Support ...........................33
4.3. GMPLS and MPLS-TP Requirements Table ......................34
1. Introduction ....................................................3
1.1. Scope ......................................................4
1.2. Basic Approach .............................................4
1.3. Reference Model ............................................6
2. Control-Plane Requirements ......................................9
2.1. Primary Requirements .......................................9
2.2. Requirements Derived from the MPLS-TP Framework ...........18
2.3. Requirements Derived from the OAM Framework ...............20
2.4. Security Requirements .....................................25
2.5. Identifier Requirements ...................................25
3. Relationship of PWs and TE LSPs ................................26
4. TE LSPs ........................................................27
4.1. GMPLS Functions and MPLS-TP LSPs ..........................27
4.1.1. In-Band and Out-of-Band Control ....................27
4.1.2. Addressing .........................................29
4.1.3. Routing ............................................29
4.1.4. TE LSPs and Constraint-Based Path Computation ......29
4.1.5. Signaling ..........................................30
4.1.6. Unnumbered Links ...................................30
4.1.7. Link Bundling ......................................30
4.1.8. Hierarchical LSPs ..................................31
4.1.9. LSP Recovery .......................................31
4.1.10. Control-Plane Reference Points (E-NNI,
I-NNI, UNI) .......................................32
4.2. OAM, MEP (Hierarchy), MIP Configuration and Control .......32
4.2.1. Management-Plane Support ...........................33
4.3. GMPLS and MPLS-TP Requirements Table ......................34
4.4. Anticipated MPLS-TP-Related Extensions and Definitions ....37
4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking ..37
4.4.2. Associated Bidirectional LSPs ......................38
4.4.3. Asymmetric Bandwidth LSPs ..........................38
4.4.4. Recovery for P2MP LSPs .............................38
4.4.5. Test Traffic Control and Other OAM Functions .......38
4.4.6. Diffserv Object Usage in GMPLS .....................39
4.4.7. Support for MPLS-TP LSP Identifiers ................39
4.4.8. Support for MPLS-TP Maintenance Identifiers ........39
5. Pseudowires ....................................................39
5.1. LDP Functions and Pseudowires .............................39
5.1.1. Management-Plane Support ...........................40
5.2. PW Control (LDP) and MPLS-TP Requirements Table ...........40
5.3. Anticipated MPLS-TP-Related Extensions ....................44
5.3.1. Extensions to Support Out-of-Band PW Control .......44
5.3.2. Support for Explicit Control of PW-to-LSP Binding ..45
5.3.3. Support for Dynamic Transfer of PW
Control/Ownership ..................................45
5.3.4. Interoperable Support for PW/LSP Resource
Allocation .........................................46
5.3.5. Support for PW Protection and PW OAM
Configuration ......................................46
5.3.6. Client Layer and Cross-Provider Interfaces
to PW Control ......................................47
5.4. ASON Architecture Considerations ..........................47
6. Security Considerations ........................................47
7. Acknowledgments ................................................48
8. References .....................................................48
8.1. Normative References ......................................48
8.2. Informative References ....................................51
9. Contributing Authors ...........................................56
4.4. Anticipated MPLS-TP-Related Extensions and Definitions ....37
4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking ..37
4.4.2. Associated Bidirectional LSPs ......................38
4.4.3. Asymmetric Bandwidth LSPs ..........................38
4.4.4. Recovery for P2MP LSPs .............................38
4.4.5. Test Traffic Control and Other OAM Functions .......38
4.4.6. Diffserv Object Usage in GMPLS .....................39
4.4.7. Support for MPLS-TP LSP Identifiers ................39
4.4.8. Support for MPLS-TP Maintenance Identifiers ........39
5. Pseudowires ....................................................39
5.1. LDP Functions and Pseudowires .............................39
5.1.1. Management-Plane Support ...........................40
5.2. PW Control (LDP) and MPLS-TP Requirements Table ...........40
5.3. Anticipated MPLS-TP-Related Extensions ....................44
5.3.1. Extensions to Support Out-of-Band PW Control .......44
5.3.2. Support for Explicit Control of PW-to-LSP Binding ..45
5.3.3. Support for Dynamic Transfer of PW
Control/Ownership ..................................45
5.3.4. Interoperable Support for PW/LSP Resource
Allocation .........................................46
5.3.5. Support for PW Protection and PW OAM
Configuration ......................................46
5.3.6. Client Layer and Cross-Provider Interfaces
to PW Control ......................................47
5.4. ASON Architecture Considerations ..........................47
6. Security Considerations ........................................47
7. Acknowledgments ................................................48
8. References .....................................................48
8.1. Normative References ......................................48
8.2. Informative References ....................................51
9. Contributing Authors ...........................................56
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is defined as a joint effort between the International Telecommunication Union (ITU) and the IETF. The requirements for MPLS-TP are defined in the requirements document, see [RFC5654]. These requirements state that "A solution MUST be defined to support dynamic provisioning of MPLS-TP transport paths via a control plane". This document provides the framework for such dynamic provisioning. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functions of a packet transport network as defined by the ITU-T.
多协议标签交换传输协议（MPLS-TP）被定义为国际电信联盟（ITU）和IETF之间的共同努力。MPLS-TP的要求在要求文件中定义，请参见[RFC5654]。这些要求说明“必须定义一个解决方案，以支持通过控制平面动态提供MPLS-TP传输路径”。本文档提供了这种动态资源调配的框架。本文件是联合互联网工程任务组（IETF）/国际电信联盟电信标准化部门（ITU-T）努力的成果，旨在将MPLS传输配置文件纳入IETF MPLS和伪线仿真边到边（PWE3）中支持ITU-T定义的分组传输网络的能力和功能的体系结构。
This document covers the control-plane functions involved in establishing MPLS-TP Label Switched Paths (LSPs) and pseudowires (PWs). The control-plane requirements for MPLS-TP are defined in the MPLS-TP requirements document [RFC5654]. These requirements define the role of the control plane in MPLS-TP. In particular, Section 2.4 of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] provide specific control-plane requirements.
本文档涵盖了建立MPLS-TP标签交换路径（LSP）和伪线（PW）所涉及的控制平面功能。MPLS-TP的控制平面要求在MPLS-TP要求文件[RFC5654]中定义。这些要求定义了控制平面在MPLS-TP中的作用。具体而言，[RFC5654]第2.4节和[RFC5654]第2节剩余部分提供了具体的控制平面要求。
The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS, and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to carry client signals other than IP or MPLS. The relationship between PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs in an MPLS Packet Switched Network (PSN). The PW encapsulation over MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs over MPLS in an MPLS network. MPLS-TP also defines protection and restoration (or, collectively, recovery) functions; see [RFC5654] and [RFC4427]. The MPLS-TP control plane provides methods to establish, remove, and control MPLS-TP LSPs and PWs. This includes control of Operations, Administration, and Maintenance (OAM), data-plane, and recovery functions.
MPLS-TP提供的LSP用作IP、MPLS和PWs以及其他隧道MPLS-TP LSP的服务器层。PWs用于传输除IP或MPLS以外的客户端信号。PWs和MPLS-TP LSP之间的关系与MPLS分组交换网络（PSN）中PWs和MPLS LSP之间的关系完全相同。MPLS-TP网络中使用的MPLS-TP LSP上的PW封装也与MPLS网络中MPLS上的PW封装相同。MPLS-TP还定义了保护和恢复（或统称为恢复）功能；参见[RFC5654]和[RFC4427]。MPLS-TP控制平面提供了建立、删除和控制MPLS-TP LSP和PWs的方法。这包括对操作、管理和维护（OAM）、数据平面和恢复功能的控制。
A general framework for MPLS-TP has been defined in [RFC5921], and a survivability framework for MPLS-TP has been defined in [RFC6372]. These documents scope the approaches and protocols that are the foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the IETF protocols that serve as the foundation of the MPLS-TP control plane. The PW control plane is based on the existing PW control plane (see [RFC4447]) and the PWE3 architecture (see [RFC3985]). The LSP control plane is based on GMPLS (see [RFC3945]), which is built on MPLS Traffic Engineering (TE) and its numerous extensions. [RFC6372] focuses on the recovery functions that must be supported within MPLS-TP. It does not specify which control-plane mechanisms are to be used.
[RFC5921]中定义了MPLS-TP的通用框架，[RFC6372]中定义了MPLS-TP的生存性框架。这些文件涵盖了MPLS- TP的基础和方法和协议。值得注意的是，[fc5921]的第3.5节描述了作为MPLS- TP控制平面的基础的IETF协议。PW控制平面基于现有PW控制平面（参见[RFC4447]）和PWE3架构（参见[RFC3985]）。LSP控制平面基于GMPLS（参见[RFC3945]），GMPLS基于MPLS流量工程（TE）及其众多扩展。[RFC6372]重点介绍MPLS-TP中必须支持的恢复功能。它没有指定要使用的控制平面机构。
The remainder of this document discusses the impact of the MPLS-TP requirements on the GMPLS signaling and routing protocols that are used to control MPLS-TP LSPs, and on the control of PWs as specified in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].
本文件的其余部分讨论了MPLS-TP要求对用于控制MPLS-TP LSP的GMPLS信令和路由协议以及[RFC4447]、[RFC6073]和[MS-PW-DYNAMIC]中规定的PWs控制的影响。
The basic approach taken in defining the MPLS-TP control-plane framework includes the following:
定义MPLS-TP控制平面框架时采用的基本方法包括：
1) MPLS technology as defined by the IETF is the foundation for the MPLS Transport Profile.
1) 由IETF定义的MPLS技术是MPLS传输配置文件的基础。
2) The data plane for MPLS-TP is a standard MPLS data plane [RFC3031] as profiled in [RFC5960].
2) MPLS-TP的数据平面是[RFC5960]中描述的标准MPLS数据平面[RFC3031]。
3) MPLS PWs are used by MPLS-TP including the use of targeted Label Distribution Protocol (LDP) as the foundation for PW signaling [RFC4447]. This also includes the use of Open Shortest Path First with Traffic Engineering (OSPF-TE), Intermediate System to Intermediate System (IS-IS) with Traffic Engineering (ISIS-TE), or Multiprotocol Border Gateway Protocol (MP-BGP) as they apply for Multi-Segment Pseudowire (MS-PW) routing. However, the PW can be encapsulated over an MPLS-TP LSP (established using methods and procedures for MPLS-TP LSP establishment) in addition to the presently defined methods of carrying PWs over LSP-based PSNs. That is, the MPLS-TP domain is a PSN from a PWE3 architecture perspective [RFC3985].
3) MPLS PWS由MPLS- TP使用，包括使用有针对性的标签分发协议（LDP）作为PW信令的基础[RCF447 ]。这还包括使用开放最短路径优先与流量工程（OSPF-TE）、中间系统到中间系统（IS-IS）与流量工程（ISIS-TE）或多协议边界网关协议（MP-BGP），因为它们适用于多段伪线（MS-PW）路由。然而，除了当前定义的通过基于LSP的psn承载PW的方法之外，还可以将PW封装在MPLS-TP LSP（使用用于MPLS-TP LSP建立的方法和过程建立）上。也就是说，从PWE3体系结构的角度来看，MPLS-TP域是一个PSN[RFC3985]。
4) The MPLS-TP LSP control plane builds on the GMPLS control plane as defined by the IETF for transport LSPs. The protocols within scope are Resource Reservation Protocol with Traffic Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203] [RFC5392], and ISIS-TE [RFC5307] [RFC5316]. Automatically Switched Optical Network (ASON) signaling and routing requirements in the context of GMPLS can be found in [RFC4139] and [RFC4258].
4) MPLS-TP LSP控制平面建立在IETF为传输LSP定义的GMPLS控制平面上。范围内的协议是具有流量工程的资源预留协议（RSVP-TE）[RFC3473]、OSPF-TE[RFC4203][RFC5392]和ISIS-TE[RFC5307][RFC5316]。GMPLS环境下的自动交换光网络（ASON）信令和路由要求见[RFC4139]和[RFC4258]。
5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group Internet-Drafts should be reused wherever possible.
5) 应尽可能重复使用现有的IETF MPLS和GMPLS RFC以及不断发展的工作组互联网草案。
6) If needed, extensions for the MPLS-TP control plane should first be based on the existing and evolving IETF work, and secondly be based on work by other standard bodies only when IETF decides that the work is out of the IETF's scope. New extensions may be defined otherwise.
6) 如果需要，MPLS-TP控制平面的扩展应首先基于现有的和不断发展的IETF工作，其次仅当IETF确定工作超出IETF的范围时，才基于其他标准机构的工作。新的扩展可以另行定义。
7) Extensions to the control plane may be required in order to fully automate functions related to MPLS-TP LSPs and PWs.
7) 为了完全自动化与MPLS-TP LSP和PWs相关的功能，可能需要对控制平面进行扩展。
8) Control-plane software upgrades to existing equipment are acceptable and expected.
8) 现有设备的控制平面软件升级是可接受的，也是预期的。
9) It is permissible for functions present in the GMPLS and PW control planes to not be used in MPLS-TP networks.
9) 允许在MPLS-TP网络中不使用GMPLS和PW控制平面中存在的功能。
10) One possible use of the control plane is to configure, enable, and generally control OAM functionality. This will require extensions to existing control-plane specifications that will be usable in MPLS-TP as well as MPLS networks.
10） 控制平面的一个可能用途是配置、启用和通常控制OAM功能。这将需要对现有控制平面规范进行扩展，这些规范将在MPLS-TP以及MPLS网络中可用。
11) The foundation for MPLS-TP control-plane requirements is primarily found in Section 2.4 of [RFC5654] and relevant portions of the remainder of Section 2 of [RFC5654].
11）MPLS- TP控制平面需求的基础主要损坏在[RCF5654 ]的第2.4节和[RCF5654 ]第2节的其余部分。
The control-plane reference model is based on the general MPLS-TP reference model as defined in the MPLS-TP framework [RFC5921] and further refined in [RFC6215] on the MPLS-TP User-to-Network and Network-to-Network Interfaces (UNI and NNI, respectively). Per the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic routing within an MPLS-TP domain.
控制平面参考模型基于MPLS-TP框架[RFC5921]中定义的通用MPLS-TP参考模型，并在[RFC6215]中进一步完善了MPLS-TP用户到网络和网络到网络接口（分别为UNI和NNI）。根据MPLS-TP框架[RFC5921]，MPLS-TP控制平面基于GMPLS，RSVP-TE用于LSP信令，目标LDP用于PW信令。在这两种情况下，带有GMPLS扩展的OSPF-TE或ISIS-TE用于MPLS-TP域内的动态路由。
Note that in this context, "targeted LDP" (or T-LDP) means LDP as defined in RFC 5036, using Targeted Hello messages. See Section 2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the extended discovery mechanism is specified in Section 5 ("LDP") of [RFC4447].
注意，在此上下文中，“目标LDP”（或T-LDP）是指使用目标Hello消息的RFC 5036中定义的LDP。参见[RFC5036]第2.4.2节（“扩展发现机制”）。[RFC4447]第5节（“LDP”）规定了扩展发现机制的使用。
From a service perspective, MPLS-TP client services may be supported via both PWs and LSPs. PW client interfaces, or adaptations, are defined on an interface-technology basis, e.g., Ethernet over PW [RFC4448]. In the context of MPLS-TP LSP, the client interface is provided at the network layer and may be controlled via a GMPLS-based UNI, see [RFC4208], or statically provisioned. As discussed in [RFC5921] and [RFC6215], MPLS-TP also presumes an NNI reference point.
从服务的角度来看，MPLS-TP客户端服务可以通过PWs和LSP来支持。PW客户端接口或适配是基于接口技术定义的，例如PW上的以太网[RFC4448]。在MPLS-TP LSP的上下文中，客户机接口在网络层提供，并且可以通过基于GMPLS的UNI进行控制，参见[RFC4208]，或者静态配置。如[RFC5921]和[RFC6215]中所述，MPLS-TP还假定NNI参考点。
The MPLS-TP end-to-end control-plane reference model is shown in Figure 1. The figure shows the control-plane protocols used by MPLS-TP, as well as the UNI and NNI reference points, in the case of a Single-Segment PW supported by an end-to-end LSP without any hierarchical LSPs. (The MS-PW case is not shown.) Each service provider node's participation in routing and signaling (both GMPLS RSVP-TE and PW LDP) is represented. Note that only the service end points participate in PW LDP signaling, while all service provider nodes participate in GMPLS TE LSP routing and signaling.
MPLS-TP端到端控制平面参考模型如图1所示。该图显示了MPLS-TP使用的控制平面协议，以及在单段PW受端到端LSP支持且无任何分层LSP的情况下的UNI和NNI参考点。（MS-PW案例未显示）表示每个服务提供商节点参与路由和信令（GMPLS RSVP-TE和PW LDP）。注意，只有服务端点参与PW LDP信令，而所有服务提供商节点参与GMPLS TE LSP路由和信令。
|< ---- client signal (e.g., IP / MPLS / L2) -------- >|
|< --------- SP1 ---------- >|< ------- SP2 ----- >|
|< ---------- MPLS-TP End-to-End PW --------- >|
|< -------- MPLS-TP End-to-End LSP ------ >|
|< ---- client signal (e.g., IP / MPLS / L2) -------- >|
|< --------- SP1 ---------- >|< ------- SP2 ----- >|
|< ---------- MPLS-TP End-to-End PW --------- >|
|< -------- MPLS-TP End-to-End LSP ------ >|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
GMPLS
TE-RTG, |<-----|------|------|-------|------|----->|
& RSVP-TE
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
GMPLS
TE-RTG, |<-----|------|------|-------|------|----->|
& RSVP-TE
PW LDP |< ---------------------------------------- >|
PW LDP |< ---------------------------------------- >|
Figure 1. End-to-End MPLS-TP Control-Plane Reference Model
图1。端到端MPLS-TP控制平面参考模型
Legend: CE: Customer Edge Client signal: defined in MPLS-TP Requirements L2: Any layer 2 signal that may be carried over a PW, e.g., Ethernet NNI: Network-to-Network Interface P: Provider PE: Provider Edge SP: Service Provider TE-RTG: GMPLS OSPF-TE or ISIS-TE UNI: User-to-Network Interface
图例：CE：客户边缘客户信号：在MPLS-TP要求中定义L2：可通过PW传输的任何第2层信号，例如以太网NNI：网络到网络接口P：提供商PE：提供商边缘SP：服务提供商TE-RTG：GMPLS OSPF-TE或ISIS-TE UNI：用户到网络接口
Note: The MS-PW case is not shown.
注：未显示MS-PW外壳。
Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". These segments are present to support scaling, OAM, and Maintenance Entity Group End Points (MEPs), see [RFC6371], within each provider domain and across the inter-provider NNI. (H-LSPs are used to implement Sub-Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The MEPs are used to collect performance information, support diagnostic and fault management functions, and support OAM triggered survivability schemes as discussed in [RFC6372]. Each H-LSP may be protected or restored using any of the schemes discussed in [RFC6372]. End-to-end monitoring is supported via MEPs at the end-to-end LSP and PW end points. Note that segment MEPs may be co-located with MIPs of the next higher-layer (e.g., end-to-end) LSPs. (The MS-PW case is not shown.)
图2添加了三个分层LSP段，标记为“H-LSP”。这些段用于支持每个提供商域内和跨提供商间NNI的扩展、OAM和维护实体组端点（MEP），请参见[RFC6371]。（H-LSP用于实施[RFC5921]中定义的子路径维护元件（SPME）。MEP用于收集性能信息，支持诊断和故障管理功能，并支持[RFC6372]中讨论的OAM触发的生存性方案。可以使用[RFC6372]中讨论的任何方案来保护或恢复每个H-LSP。通过端到端LSP和PW端点的MEP支持端到端监控。注意，段MEP可与下一更高层（例如，端到端）LSP的MIP共存。（MS-PW外壳未显示。）
|< ------- client signal (e.g., IP / MPLS / L2) ----- >|
|< -------- SP1 ----------- >|< ------- SP2 ----- >|
|< ----------- MPLS-TP End-to-End PW -------- >|
|< ------- MPLS-TP End-to-End LSP ------- >|
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
|< ------- client signal (e.g., IP / MPLS / L2) ----- >|
|< -------- SP1 ----------- >|< ------- SP2 ----- >|
|< ----------- MPLS-TP End-to-End PW -------- >|
|< ------- MPLS-TP End-to-End LSP ------- >|
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
..... .....
End2end |MEP|--------------------------------------|MEP|
PW OAM ''''' '''''
..... ..... ..... .....
End2end |MEP|----------------|MIP|---|MIP|---------|MEP|
LSP OAM ''''' ''''' ''''' '''''
..... ..... ..... ......... ......... ..... .....
Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
LSP OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
..... .....
End2end |MEP|--------------------------------------|MEP|
PW OAM ''''' '''''
..... ..... ..... .....
End2end |MEP|----------------|MIP|---|MIP|---------|MEP|
LSP OAM ''''' ''''' ''''' '''''
..... ..... ..... ......... ......... ..... .....
Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
LSP OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''
H-LSP GMPLS
TE-RTG |<-----|------|----->||<---->||<-----|----->|
&RSVP-TE (within an MPLS-TP network)
H-LSP GMPLS
TE-RTG |<-----|------|----->||<---->||<-----|----->|
&RSVP-TE (within an MPLS-TP network)
E2E GMPLS
TE-RTG |< ------------------|--------|------------>|
&RSVP-TE
E2E GMPLS
TE-RTG |< ------------------|--------|------------>|
&RSVP-TE
PW LDP |< ---------------------------------------- >|
PW LDP |< ---------------------------------------- >|
Figure 2. MPLS-TP Control-Plane Reference Model with OAM
图2。基于OAM的MPLS-TP控制平面参考模型
Legend: CE: Customer Edge Client signal: defined in MPLS-TP Requirements E2E: End-to-End L2: Any layer 2 signal that may be carried over a PW, e.g., Ethernet H-LSP: Hierarchical LSP MEP: Maintenance Entity Group End Point MIP: Maintenance Entity Group Intermediate Point NNI: Network-to-Network Interface P: Provider PE: Provider Edge SP: Service Provider TE-RTG: GMPLS OSPF-TE or ISIS-TE
图例：CE：客户边缘客户端信号：在MPLS-TP要求E2E：端到端L2中定义：可通过PW传输的任何第2层信号，例如。，以太网H-LSP：分层LSP MEP:维护实体组端点MIP:维护实体组中间点NNI:网络到网络接口P:提供商PE:提供商边缘SP:服务提供商TE-RTG:GMPLS OSPF-TE或ISIS-TE
Note: The MS-PW case is not shown.
注：未显示MS-PW外壳。
While not shown in the figures above, the MPLS-TP control plane must support the addressing separation and independence between the data, control, and management planes. Address separation between the planes is already included in GMPLS. Such separation is also already included in LDP as LDP session end point addresses are never automatically associated with forwarding.
尽管上图中未显示，但MPLS-TP控制平面必须支持数据、控制和管理平面之间的寻址分离和独立性。GMPLS中已经包含了平面之间的地址分隔。这种分离也已经包括在LDP中，因为LDP会话端点地址永远不会自动与转发关联。
The requirements for the MPLS-TP control plane are derived from the MPLS-TP requirements and framework documents, specifically [RFC5654], [RFC5921], [RFC5860], [RFC6371], and [RFC6372]. The requirements are summarized in this section, but do not replace those documents. If there are differences between this section and those documents, those documents shall be considered authoritative.
MPLS-TP控制平面的要求源自MPLS-TP要求和框架文件，具体为[RFC5654]、[RFC5921]、[RFC5860]、[RFC6371]和[RFC6372]。本节概述了这些要求，但不替换这些文件。如果本节与这些文件之间存在差异，则这些文件应被视为具有权威性。
These requirements are based on Section 2 of [RFC5654]:
这些要求基于[RFC5654]第2节：
1. Any new functionality that is defined to fulfill the requirements for MPLS-TP must be agreed within the IETF through the IETF consensus process as per [RFC4929] and Section 1, paragraph 15 of [RFC5654].
1. 根据[RFC4929]和[RFC5654]第1节第15段，为满足MPLS-TP要求而定义的任何新功能必须在IETF内通过IETF协商一致过程达成一致。
2. The MPLS-TP control-plane design should as far as reasonably possible reuse existing MPLS standards ([RFC5654], requirement 2).
2. MPLS-TP控制平面设计应尽可能合理地重用现有MPLS标准（[RFC5654]，要求2）。
3. The MPLS-TP control plane must be able to interoperate with existing IETF MPLS and PWE3 control planes where appropriate ([RFC5654], requirement 3).
3. MPLS-TP控制平面必须能够在适当情况下与现有的IETF MPLS和PWE3控制平面进行互操作（[RFC5654]，要求3）。
4. The MPLS-TP control plane must be sufficiently well-defined to ensure that the interworking between equipment supplied by multiple vendors will be possible both within a single domain and between domains ([RFC5654], requirement 4).
4. MPLS-TP控制平面必须充分定义，以确保多个供应商提供的设备之间的互通在单个域内和域之间都是可能的（[RFC5654]，要求4）。
5. The MPLS-TP control plane must support a connection-oriented packet switching model with traffic engineering capabilities that allow deterministic control of the use of network resources ([RFC5654], requirement 5).
5. MPLS-TP控制平面必须支持面向连接的分组交换模型，该模型具有流量工程功能，允许对网络资源的使用进行确定性控制（[RFC5654]，要求5）。
6. The MPLS-TP control plane must support traffic-engineered point-to-point (P2P) and point-to-multipoint (P2MP) transport paths ([RFC5654], requirement 6).
6. MPLS-TP控制平面必须支持流量工程点对点（P2P）和点对多点（P2MP）传输路径（[RFC5654]，要求6）。
7. The MPLS-TP control plane must support unidirectional, associated bidirectional and co-routed bidirectional point-to-point transport paths ([RFC5654], requirement 7).
7. MPLS-TP控制平面必须支持单向、关联双向和共路由双向点到点传输路径（[RFC5654]，要求7）。
8. The MPLS-TP control plane must support unidirectional point-to-multipoint transport paths ([RFC5654], requirement 8).
8. MPLS-TP控制平面必须支持单向点对多点传输路径（[RFC5654]，要求8）。
9. The MPLS-TP control plane must enable all nodes (i.e., ingress, egress, and intermediate) to be aware about the pairing relationship of the forward and the backward directions belonging to the same co-routed bidirectional transport path ([RFC5654], requirement 10).
9. MPLS-TP控制平面必须使所有节点（即入口、出口和中间节点）能够了解属于同一共路由双向传输路径的前向和后向的配对关系（[RFC5654]，要求10）。
10. The MPLS-TP control plane must enable edge nodes (i.e., ingress and egress) to be aware of the pairing relationship of the forward and the backward directions belonging to the same associated bidirectional transport path ([RFC5654], requirement 11).
10. MPLS-TP控制平面必须使边缘节点（即入口和出口）能够意识到属于同一关联双向传输路径的前向和后向的配对关系（[RFC5654]，要求11）。
11. The MPLS-TP control plane should enable common transit nodes to be aware of the pairing relationship of the forward and the backward directions belonging to the same associated bidirectional transport path ([RFC5654], requirement 12).
11. MPLS-TP控制平面应使公共传输节点能够意识到属于同一关联双向传输路径的前向和后向的配对关系（[RFC5654]，要求12）。
12. The MPLS-TP control plane must support bidirectional transport paths with symmetric bandwidth requirements, i.e., the amount of reserved bandwidth is the same in the forward and backward directions ([RFC5654], requirement 13).
12. MPLS-TP控制平面必须支持具有对称带宽要求的双向传输路径，即前向和后向预留带宽量相同（[RFC5654]，要求13）。
13. The MPLS-TP control plane must support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs in the forward and backward directions ([RFC5654], requirement 14).
13. MPLS-TP控制平面必须支持具有非对称带宽要求的双向传输路径，即保留带宽的数量在前向和后向上不同（[RFC5654]，要求14）。
14. The MPLS-TP control plane must support the logical separation of the control plane from the management and data planes ([RFC5654], requirement 15). Note that this implies that the addresses used in the control plane are independent from the addresses used in the management and data planes.
14. MPLS-TP控制平面必须支持控制平面与管理平面和数据平面的逻辑分离（[RFC5654]，要求15）。注意，这意味着控制平面中使用的地址独立于管理平面和数据平面中使用的地址。
15. The MPLS-TP control plane must support the physical separation of the control plane from the management and data plane, and no assumptions should be made about the state of the data-plane channels from information about the control- or management-plane channels when they are running out-of-band ([RFC5654], requirement 16).
15. MPLS-TP控制平面必须支持控制平面与管理平面和数据平面的物理分离，并且当控制平面或管理平面信道在频带外运行时，不应根据控制平面信道或管理平面信道的信息对数据平面信道的状态作出任何假设（[RFC5654]，要求16）。
16. A control plane must be defined to support dynamic provisioning and restoration of MPLS-TP transport paths, but its use is a network operator's choice ([RFC5654], requirement 18).
16. 必须定义控制平面以支持MPLS-TP传输路径的动态供应和恢复，但其使用是网络运营商的选择（[RFC5654]，要求18）。
17. The presence of a control plane must not be required for static provisioning of MPLS-TP transport paths ([RFC5654], requirement 19).
17. MPLS-TP传输路径的静态供应不得要求存在控制平面（[RFC5654]，要求19）。
18. The MPLS-TP control plane must permit the coexistence of statically and dynamically provisioned/managed MPLS-TP transport paths within the same layer network or domain ([RFC5654], requirement 20).
18. MPLS-TP控制平面必须允许静态和动态供应/管理的MPLS-TP传输路径在同一层网络或域内共存（[RFC5654]，要求20）。
19. The MPLS-TP control plane should be operable in a way that is similar to the way the control plane operates in other transport-layer technologies ([RFC5654], requirement 21).
19. MPLS-TP控制平面的操作方式应类似于控制平面在其他传输层技术中的操作方式（[RFC5654]，要求21）。
20. The MPLS-TP control plane must avoid or minimize traffic impact (e.g., packet delay, reordering, and loss) during network reconfiguration ([RFC5654], requirement 24).
20. MPLS-TP控制平面必须避免或最小化网络重新配置期间的流量影响（例如，数据包延迟、重新排序和丢失）（[RFC5654]，要求24）。
21. The MPLS-TP control plane must work across multiple homogeneous domains ([RFC5654], requirement 25), i.e., all domains use the same MPLS-TP control plane.
21. MPLS-TP控制平面必须跨多个同质域工作（[RFC5654]，要求25），即所有域使用相同的MPLS-TP控制平面。
22. The MPLS-TP control plane should work across multiple non-homogeneous domains ([RFC5654], requirement 26), i.e., some domains use the same control plane and other domains use static provisioning at the domain boundary.
22. MPLS-TP控制平面应跨多个非同质域工作（[RFC5654]，要求26），即某些域使用相同的控制平面，而其他域在域边界使用静态资源调配。
23. The MPLS-TP control plane must not dictate any particular physical or logical topology ([RFC5654], requirement 27).
23. MPLS-TP控制平面不得规定任何特定的物理或逻辑拓扑（[RFC5654]，要求27）。
24. The MPLS-TP control plane must include support of ring topologies that may be deployed with arbitrary interconnection and support of rings of at least 16 nodes ([RFC5654], requirements 27.A, 27.B, and 27.C).
24. MPLS-TP控制平面必须包括对可通过任意互连部署的环拓扑的支持，以及对至少16个节点的环的支持（[RFC5654]，要求27.A、27.B和27.C）。
25. The MPLS-TP control plane must scale gracefully to support a large number of transport paths, nodes, and links. That is, it must be able to scale at least as well as control planes in existing transport technologies with growing and increasingly complex network topologies as well as with increasing bandwidth demands, number of customers, and number of services ([RFC5654], requirements 53 and 28).
25. MPLS-TP控制平面必须适度扩展，以支持大量传输路径、节点和链路。也就是说，它必须能够在现有传输技术中，随着网络拓扑的不断增长和日益复杂，以及带宽需求、客户数量和服务数量的不断增加，至少能够扩展和控制平面（[RFC5654]，要求53和28）。
26. The MPLS-TP control plane should not provision transport paths that contain forwarding loops ([RFC5654], requirement 29).
26. MPLS-TP控制平面不应提供包含转发环路的传输路径（[RFC5654]，要求29）。
27. The MPLS-TP control plane must support multiple client layers (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, Frame Relay, etc.) ([RFC5654], requirement 30).
27. MPLS-TP控制平面必须支持多个客户端层（例如，MPLS-TP、IP、MPLS、以太网、ATM、帧中继等）（[RFC5654]，要求30）。
28. The MPLS-TP control plane must provide a generic and extensible solution to support the transport of MPLS-TP transport paths over one or more server-layer networks (such as MPLS-TP, Ethernet, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Network (OTN), etc.). Requirements for bandwidth management within a server-layer network are outside the scope of this document ([RFC5654], requirement 31).
28. MPLS-TP控制平面必须提供通用和可扩展的解决方案，以支持通过一个或多个服务器层网络（如MPLS-TP、以太网、同步光网络/同步数字体系（SONET/SDH）、光传输网络（OTN）等）传输MPLS-TP传输路径。服务器层网络内的带宽管理要求不在本文件范围内（[RFC5654]，要求31）。
29. In an environment where an MPLS-TP layer network is supporting a client-layer network, and the MPLS-TP layer network is supported by a server-layer network, then the control-plane operation of the MPLS-TP layer network must be possible without any dependencies on the server or client-layer network ([RFC5654], requirement 32).
29. 在MPLS-TP层网络支持客户端层网络且MPLS-TP层网络受服务器层网络支持的环境中，MPLS-TP层网络的控制平面操作必须能够在不依赖服务器或客户端层网络的情况下进行（[RFC5654]，要求32）。
30. The MPLS-TP control plane must allow for the transport of a client MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer network ([RFC5654], requirement 33).
30. MPLS-TP控制平面必须允许通过服务器MPLS或MPLS-TP层网络传输客户端MPLS或MPLS-TP层网络（[RFC5654]，要求33）。
31. The MPLS-TP control plane must allow the autonomous operation of the layers of a multi-layer network that includes an MPLS-TP layer ([RFC5654], requirement 34).
31. MPLS-TP控制平面必须允许包括MPLS-TP层的多层网络的各层自主操作（[RFC5654]，要求34）。
32. The MPLS-TP control plane must allow the hiding of MPLS-TP layer network addressing and other information (e.g., topology) from client-layer networks. However, it should be possible, at the option of the operator, to leak a limited amount of summarized information, such as Shared Risk Link Groups (SRLGs) or reachability, between layers ([RFC5654], requirement 35).
32. MPLS-TP控制平面必须允许从客户端层网络隐藏MPLS-TP层网络寻址和其他信息（例如拓扑）。但是，运营商可以选择在各层之间泄漏有限数量的汇总信息，如共享风险链接组（SRLGs）或可达性（[RFC5654]，要求35）。
33. The MPLS-TP control plane must allow for the identification of a transport path on each link within and at the destination (egress) of the transport network ([RFC5654], requirements 38 and 39).
33. MPLS-TP控制平面必须允许在传输网络的目的地（出口）内和目的地（出口）的每个链路上识别传输路径（[RFC5654]，要求38和39）。
34. The MPLS-TP control plane must allow for the use of P2MP server (sub-)layer capabilities as well as P2P server (sub-)layer capabilities when supporting P2MP MPLS-TP transport paths ([RFC5654], requirement 40).
34. MPLS-TP控制平面必须允许在支持P2MP MPLS-TP传输路径时使用P2MP服务器（子）层功能以及P2P服务器（子）层功能（[RFC5654]，要求40）。
35. The MPLS-TP control plane must be extensible in order to accommodate new types of client-layer networks and services ([RFC5654], requirement 41).
35. MPLS-TP控制平面必须是可扩展的，以适应新类型的客户端层网络和服务（[RFC5654]，要求41）。
36. The MPLS-TP control plane should support the reserved bandwidth associated with a transport path to be increased without impacting the existing traffic on that transport path, provided enough resources are available ([RFC5654], requirement 42)).
36. MPLS-TP控制平面应支持与要增加的传输路径相关联的保留带宽，而不影响该传输路径上的现有流量，前提是有足够的资源可用（[RFC5654]，要求42））。
37. The MPLS-TP control plane should support the reserved bandwidth of a transport path being decreased without impacting the existing traffic on that transport path, provided that the level of existing traffic is smaller than the reserved bandwidth following the decrease ([RFC5654], requirement 43).
37. MPLS-TP控制平面应支持正在减少的传输路径的保留带宽，而不影响该传输路径上的现有流量，前提是现有流量的级别小于减少后的保留带宽（[RFC5654]，要求43）。
38. The control plane for MPLS-TP must fit within the ASON (control-plane) architecture. The ITU-T has defined an architecture for ASONs in G.8080 [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An interpretation of the ASON signaling and routing requirements in the context of GMPLS can be found in [RFC4139], [RFC4258], and Section 2.4, paragraphs 2 and 3 of [RFC5654].
38. MPLS-TP的控制平面必须适合ASON（控制平面）体系结构。ITU-T在G.8080[ITU.G8080.2006]和G.8080修正案1[ITU.G8080.2008]中定义了ASON的体系结构。关于GMPLS中ASON信令和路由要求的解释，请参见[RFC4139]、[RFC4258]和[RFC5654]第2和3段第2.4节。
39. The MPLS-TP control plane must support control-plane topology and data-plane topology independence ([RFC5654], requirement 47).
39. MPLS-TP控制平面必须支持控制平面拓扑和数据平面拓扑独立性（[RFC5654]，要求47）。
40. A failure of the MPLS-TP control plane must not interfere with the delivery of service or recovery of established transport paths ([RFC5654], requirement 47).
40. MPLS-TP控制平面的故障不得干扰服务的提供或已建立传输路径的恢复（[RFC5654]，要求47）。
41. The MPLS-TP control plane must be able to operate independent of any particular client- or server-layer control plane ([RFC5654], requirement 48).
41. MPLS-TP控制平面必须能够独立于任何特定的客户端或服务器层控制平面运行（[RFC5654]，要求48）。
42. The MPLS-TP control plane should support, but not require, an integrated control plane encompassing MPLS-TP together with its server- and client-layer networks when these layer networks belong to the same administrative domain ([RFC5654], requirement 49).
42. 当MPLS-TP及其服务器层和客户端层网络属于同一管理域时，MPLS-TP控制平面应支持但不要求包含MPLS-TP及其服务器层和客户端层网络的集成控制平面（[RFC5654]，要求49）。
43. The MPLS-TP control plane must support configuration of protection functions and any associated maintenance (OAM) functions ([RFC5654], requirements 50 and 7).
43. MPLS-TP控制平面必须支持保护功能和任何相关维护（OAM）功能的配置（[RFC5654]，要求50和7）。
44. The MPLS-TP control plane must support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM when the transport path or transport service is established or modified ([RFC5654], requirement 51).
44. MPLS-TP控制平面必须支持OAM维护点的配置和修改，以及在建立或修改传输路径或传输服务时激活/停用OAM（[RFC5654]，要求51）。
45. The MPLS-TP control plane must be capable of restarting and relearning its previous state without impacting forwarding ([RFC5654], requirement 54).
45. MPLS-TP控制平面必须能够在不影响转发的情况下重新启动和重新学习其先前状态（[RFC5654]，要求54）。
46. The MPLS-TP control plane must provide a mechanism for dynamic ownership transfer of the control of MPLS-TP transport paths from the management plane to the control plane and vice versa. The number of reconfigurations required in the data plane must be minimized; preferably no data-plane reconfiguration will be required ([RFC5654], requirement 55). Note, such transfers cover all transport path control functions including control of recovery and OAM.
46. MPLS-TP控制平面必须提供一种机制，用于将MPLS-TP传输路径的控制权从管理平面动态转移到控制平面，反之亦然。数据平面中所需的重新配置数量必须最小化；最好不需要重新配置数据平面（[RFC5654]，要求55）。注意，此类传输涵盖所有传输路径控制功能，包括恢复和OAM控制。
47. The MPLS-TP control plane must support protection and restoration mechanisms, i.e., recovery ([RFC5654], requirement 52).
47. MPLS-TP控制平面必须支持保护和恢复机制，即恢复（[RFC5654]，要求52）。
Note that the MPLS-TP survivability framework document [RFC6372] provides additional useful information related to recovery.
请注意，MPLS-TP生存能力框架文档[RFC6372]提供了与恢复相关的其他有用信息。
48. The MPLS-TP control-plane mechanisms should be identical (or as similar as possible) to those already used in existing transport networks to simplify implementation and operations. However, this must not override any other requirement ([RFC5654], requirement 56 A).
48. MPLS-TP控制平面机制应与现有传输网络中已使用的机制相同（或尽可能类似），以简化实现和操作。但是，这不得超过任何其他要求（[RFC5654]，要求56a）。
49. The MPLS-TP control-plane mechanisms used for P2P and P2MP recovery should be identical to simplify implementation and operation. However, this must not override any other requirement ([RFC5654], requirement 56 B).
49. 用于P2P和P2MP恢复的MPLS-TP控制平面机制应相同，以简化实现和操作。但是，这不得超过任何其他要求（[RFC5654]，要求56 B）。
50. The MPLS-TP control plane must support recovery mechanisms that are applicable at various levels throughout the network including support for link, transport path, segment, concatenated segment, and end-to-end recovery ([RFC5654], requirement 57).
50. MPLS-TP控制平面必须支持适用于整个网络各个级别的恢复机制，包括对链路、传输路径、段、连接段和端到端恢复的支持（[RFC5654]，要求57）。
51. The MPLS-TP control plane must support recovery paths that meet the Service Level Agreement (SLA) protection objectives of the service ([RFC5654], requirement 58). These include:
51. MPLS-TP控制平面必须支持满足服务的服务级别协议（SLA）保护目标的恢复路径（[RFC5654]，要求58）。这些措施包括：
a. Guarantee 50-ms recovery times from the moment of fault detection in networks with spans less than 1200 km.
a. 在跨度小于1200 km的网络中，从故障检测开始，保证50 ms的恢复时间。
b. Protection of 100% of the traffic on the protected path.
b. 100%保护受保护路径上的流量。
c. Recovery must meet SLA requirements over multiple domains.
c. 恢复必须满足跨多个域的SLA要求。
52. The MPLS-TP control plane should support per-transport-path recovery objectives ([RFC5654], requirement 59).
52. MPLS-TP控制平面应支持每传输路径恢复目标（[RFC5654]，要求59）。
53. The MPLS-TP control plane must support recovery mechanisms that are applicable to any topology ([RFC5654], requirement 60).
53. MPLS-TP控制平面必须支持适用于任何拓扑的恢复机制（[RFC5654]，要求60）。
54. The MPLS-TP control plane must operate in synergy with (including coordination of timing/timer settings) the recovery mechanisms present in any client or server transport networks (for example, Ethernet, SDH, OTN, Wavelength Division Multiplexing (WDM)) to avoid race conditions between the layers ([RFC5654], requirement 61).
54. MPLS-TP控制平面必须与任何客户端或服务器传输网络（例如，以太网、SDH、OTN、波分复用（WDM））中存在的恢复机制协同工作（包括定时/定时器设置的协调），以避免层之间的竞争条件（[RFC5654]，要求61）。
55. The MPLS-TP control plane must support recovery and reversion mechanisms that prevent frequent operation of recovery in the event of an intermittent defect ([RFC5654], requirement 62).
55. MPLS-TP控制平面必须支持恢复和恢复机制，以防止在发生间歇性缺陷时频繁运行恢复（[RFC5654]，要求62）。
56. The MPLS-TP control plane must support revertive and non-revertive protection behavior ([RFC5654], requirement 64).
56. MPLS-TP控制平面必须支持回复和非回复保护行为（[RFC5654]，要求64）。
57. The MPLS-TP control plane must support 1+1 bidirectional protection for P2P transport paths ([RFC5654], requirement 65 A).
57. MPLS-TP控制平面必须支持P2P传输路径的1+1双向保护（[RFC5654]，要求65A）。
58. The MPLS-TP control plane must support 1+1 unidirectional protection for P2P transport paths ([RFC5654], requirement 65 B).
58. MPLS-TP控制平面必须支持P2P传输路径的1+1单向保护（[RFC5654]，要求65 B）。
59. The MPLS-TP control plane must support 1+1 unidirectional protection for P2MP transport paths ([RFC5654], requirement 65 C).
59. MPLS-TP控制平面必须支持P2MP传输路径的1+1单向保护（[RFC5654]，要求65 C）。
60. The MPLS-TP control plane must support the ability to share protection resources amongst a number of transport paths ([RFC5654], requirement 66).
60. MPLS-TP控制平面必须支持在多条传输路径之间共享保护资源的能力（[RFC5654]，要求66）。
61. The MPLS-TP control plane must support 1:n bidirectional protection for P2P transport paths. Bidirectional 1:n protection should be the default for 1:n protection ([RFC5654], requirement 67 A).
61. MPLS-TP控制平面必须支持P2P传输路径的1:n双向保护。双向1:n保护应为1:n保护的默认值（[RFC5654]，要求67 A）。
62. The MPLS-TP control plane must support 1:n unidirectional protection for P2MP transport paths ([RFC5654], requirement 67 B).
62. MPLS-TP控制平面必须支持P2MP传输路径的1:n单向保护（[RFC5654]，要求67 B）。
63. The MPLS-TP control plane may support 1:n unidirectional protection for P2P transport paths ([RFC5654], requirement 65 C).
63. MPLS-TP控制平面可支持对P2P传输路径的1:n单向保护（[RFC5654]，要求65 C）。
64. The MPLS-TP control plane may support the control of extra-traffic type traffic ([RFC5654], note after requirement 67).
64. MPLS-TP控制平面可支持额外业务类型业务的控制（[RFC5654]，在要求67之后注释）。
65. The MPLS-TP control plane should support 1:n (including 1:1) shared mesh recovery ([RFC5654], requirement 68).
65. MPLS-TP控制平面应支持1:n（包括1:1）共享网格恢复（[RFC5654]，要求68）。
66. The MPLS-TP control plane must support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources ([RFC5654], requirement 69).
66. MPLS-TP控制平面必须支持保护资源的共享，以便已知不需要同时使用的保护路径可以共享相同的资源（[RFC5654]，要求69）。
67. The MPLS-TP control plane must support the sharing of resources between a restoration transport path and the transport path being replaced ([RFC5654], requirement 70).
67. MPLS-TP控制平面必须支持恢复传输路径和被替换传输路径之间的资源共享（[RFC5654]，要求70）。
68. The MPLS-TP control plane must support restoration priority so that an implementation can determine the order in which transport paths should be restored ([RFC5654], requirement 71).
68. MPLS-TP控制平面必须支持恢复优先级，以便实现可以确定传输路径应恢复的顺序（[RFC5654]，要求71）。
69. The MPLS-TP control plane must support preemption priority in order to allow restoration to displace other transport paths in the event of resource constraints ([RFC5654], requirements 72 and 86).
69. MPLS-TP控制平面必须支持抢占优先级，以便在资源受限的情况下允许恢复以替换其他传输路径（[RFC5654]，要求72和86）。
70. The MPLS-TP control plane must support revertive and non-revertive restoration behavior ([RFC5654], requirement 73).
70. MPLS-TP控制平面必须支持恢复和非恢复恢复行为（[RFC5654]，要求73）。
71. The MPLS-TP control plane must support recovery being triggered by physical (lower) layer fault indications ([RFC5654], requirement 74).
71. MPLS-TP控制平面必须支持由物理（较低）层故障指示触发的恢复（[RFC5654]，要求74）。
72. The MPLS-TP control plane must support recovery being triggered by OAM ([RFC5654], requirement 75).
72. MPLS-TP控制平面必须支持由OAM触发的恢复（[RFC5654]，要求75）。
73. The MPLS-TP control plane must support management-plane recovery triggers (e.g., forced switch, etc.) ([RFC5654], requirement 76).
73. MPLS-TP控制平面必须支持管理平面恢复触发器（例如强制切换等）（[RFC5654]，要求76）。
74. The MPLS-TP control plane must support the differentiation of administrative recovery actions from recovery actions initiated by other triggers ([RFC5654], requirement 77).
74. MPLS-TP控制平面必须支持区分管理恢复操作和其他触发器启动的恢复操作（[RFC5654]，要求77）。
75. The MPLS-TP control plane should support control-plane restoration triggers (e.g., forced switch, etc.) ([RFC5654], requirement 78).
75. MPLS-TP控制平面应支持控制平面恢复触发器（例如强制开关等）（[RFC5654]，要求78）。
76. The MPLS-TP control plane must support priority logic to negotiate and accommodate coexisting requests (i.e., multiple requests) for protection switching (e.g., administrative requests and requests due to link/node failures) ([RFC5654], requirement 79).
76. MPLS-TP控制平面必须支持优先级逻辑，以协商和适应保护切换的共存请求（即多个请求）（例如，管理请求和由于链路/节点故障引起的请求）（[RFC5654]，要求79）。
77. The MPLS-TP control plane must support the association of protection paths and working paths (sometimes known as protection groups) ([RFC5654], requirement 80).
77. MPLS-TP控制平面必须支持保护路径和工作路径的关联（有时称为保护组）（[RFC5654]，要求80）。
78. The MPLS-TP control plane must support pre-calculation of recovery paths ([RFC5654], requirement 81).
78. MPLS-TP控制平面必须支持恢复路径的预计算（[RFC5654]，要求81）。
79. The MPLS-TP control plane must support pre-provisioning of recovery paths ([RFC5654], requirement 82).
79. MPLS-TP控制平面必须支持恢复路径的预设置（[RFC5654]，要求82）。
80. The MPLS-TP control plane must support the external commands defined in [RFC4427]. External controls overruled by higher priority requests (e.g., administrative requests and requests due to link/node failures) or unable to be signaled to the remote end (e.g., because of a protection state coordination fail) must be ignored/dropped ([RFC5654], requirement 83).
80. MPLS-TP控制平面必须支持[RFC4427]中定义的外部命令。必须忽略/放弃被更高优先级请求（例如，管理请求和由于链路/节点故障导致的请求）否决或无法向远程端发送信号（例如，由于保护状态协调失败）的外部控制（[RFC5654]，要求83）。
81. The MPLS-TP control plane must permit the testing and validation of the integrity of the protection/recovery transport path ([RFC5654], requirement 84 A).
81. MPLS-TP控制平面必须允许测试和验证保护/恢复传输路径的完整性（[RFC5654]，要求84 A）。
82. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms without triggering the actual protection/restoration ([RFC5654], requirement 84 B).
82. MPLS-TP控制平面必须允许在不触发实际保护/恢复的情况下测试和验证保护/恢复机制（[RFC5654]，要求84 B）。
83. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms while the working path is in service ([RFC5654], requirement 84 C).
83. MPLS-TP控制平面必须允许在工作路径运行时测试和验证保护/恢复机制（[RFC5654]，要求84 C）。
84. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms while the working path is out of service ([RFC5654], requirement 84 D).
84. MPLS-TP控制平面必须允许在工作路径停止服务时测试和验证保护/恢复机制（[RFC5654]，要求84 D）。
85. The MPLS-TP control plane must support the establishment and maintenance of all recovery entities and functions ([RFC5654], requirement 89 A).
85. MPLS-TP控制平面必须支持所有恢复实体和功能的建立和维护（[RFC5654]，要求89 A）。
86. The MPLS-TP control plane must support signaling of recovery administrative control ([RFC5654], requirement 89 B).
86. MPLS-TP控制平面必须支持恢复管理控制的信令（[RFC5654]，要求89 B）。
87. The MPLS-TP control plane must support protection state coordination. Since control-plane network topology is independent from the data-plane network topology, the protection state coordination supported by the MPLS-TP control plane may run on resources different than the data-plane resources handled within the recovery mechanism (e.g., backup) ([RFC5654], requirement 89 C).
87. MPLS-TP控制平面必须支持保护状态协调。由于控制平面网络拓扑独立于数据平面网络拓扑，MPLS-TP控制平面支持的保护状态协调可能运行在不同于恢复机制内处理的数据平面资源的资源上（例如备份）（[RFC5654]，要求89 C）。
88. When present, the MPLS-TP control plane must support recovery mechanisms that are optimized for specific network topologies. These mechanisms must be interoperable with the mechanisms defined for arbitrary topology (mesh) networks to enable protection of end-to-end transport paths ([RFC5654], requirement 91).
88. 存在时，MPLS-TP控制平面必须支持针对特定网络拓扑优化的恢复机制。这些机制必须与为任意拓扑（mesh）网络定义的机制互操作，以实现端到端传输路径的保护（[RFC5654]，要求91）。
89. When present, the MPLS-TP control plane must support the control of ring-topology-specific recovery mechanisms ([RFC5654], Section 2.5.6.1).
89. 当存在时，MPLS-TP控制平面必须支持特定于环形拓扑的恢复机制的控制（[RFC5654]，第2.5.6.1节）。
90. The MPLS-TP control plane must include support for differentiated services and different traffic types with traffic class separation associated with different traffic ([RFC5654], requirement 110).
90. MPLS-TP控制平面必须包括对区分服务和不同流量类型的支持，以及与不同流量相关联的流量等级分离（[RFC5654]，要求110）。
91. The MPLS-TP control plane must support the provisioning of services that provide guaranteed Service Level Specifications (SLSs), with support for hard ([RFC3209] style) and relative ([RFC3270] style) end-to-end bandwidth guarantees ([RFC5654], requirement 111).
91. MPLS-TP控制平面必须支持提供有保证的服务级别规范（SLS）的服务供应，并支持硬（[RFC3209]样式）和相对（[RFC3270]样式）端到端带宽保证（[RFC5654]，要求111）。
92. The MPLS-TP control plane must support the provisioning of services that are sensitive to jitter and delay ([RFC5654], requirement 112).
92. MPLS-TP控制平面必须支持提供对抖动和延迟敏感的服务（[RFC5654]，要求112）。
The following additional requirements are based on [RFC5921], [TP-P2MP-FWK], and [RFC5960]:
以下附加要求基于[RFC5921]、[TP-P2MP-FWK]和[RFC5960]：
93. Per-packet Equal Cost Multi-Path (ECMP) load balancing is currently outside the scope of MPLS-TP ([RFC5960], Section 3.1.1, paragraph 6).
93. 每包等成本多路径（ECMP）负载平衡目前不在MPLS-TP（[RFC5960]，第3.1.1节，第6段）的范围内。
94. Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs by default ([RFC5960], Section 3.1.1, paragraph 7).
94. 默认情况下，必须在MPLS-TP LSP上禁用倒数第二跳弹出（PHP）（[RFC5960]，第3.1.1节，第7段）。
95. The MPLS-TP control plane must support both E-LSP (Explicitly TC-encoded-PSC LSP) and L-LSP (Label-Only-Inferred-PSC LSP) MPLS Diffserv modes as specified in [RFC3270], [RFC5462], and Section 3.3.2, paragraph 12 of [RFC5960].
95. MPLS-TP控制平面必须支持[RFC3270]、[RFC5462]和[RFC5960]第3.3.2节第12段中规定的E-LSP（显式TC编码的PSC LSP）和L-LSP（仅标签推断的PSC LSP）MPLS区分服务模式。
96. Both Single-Segment PWs (see [RFC3985]) and Multi-Segment PWs (see [RFC5659]) shall be supported by the MPLS-TP control plane. MPLS-TP shall use the definition of Multi-Segment PWs as defined by the IETF ([RFC5921], Section 3.4.4).
96. MPLS-TP控制平面应支持单段PW（见[RFC3985]）和多段PW（见[RFC5659]）。MPLS-TP应使用IETF定义的多段PW定义（[RFC5921]，第3.4.4节）。
97. The MPLS-TP control plane must support the control of PWs and their associated labels ([RFC5921], Section 3.4.4).
97. MPLS-TP控制平面必须支持PWs及其相关标签的控制（[RFC5921]，第3.4.4节）。
98. The MPLS-TP control plane must support network-layer clients, i.e., clients whose traffic is transported over an MPLS-TP network without the use of PWs ([RFC5921], Section 3.4.5).
98. MPLS-TP控制平面必须支持网络层客户端，即通过MPLS-TP网络传输流量而不使用PWs的客户端（[RFC5921]，第3.4.5节）。
a. The MPLS-TP control plane must support the use of network-layer protocol-specific LSPs and labels ([RFC5921], Section 3.4.5).
a. MPLS-TP控制平面必须支持使用网络层协议特定的LSP和标签（[RFC5921]，第3.4.5节）。
b. The MPLS-TP control plane must support the use of a client-service-specific LSPs and labels ([RFC5921], Section 3.4.5).
b. MPLS-TP控制平面必须支持使用特定于客户端服务的LSP和标签（[RFC5921]，第3.4.5节）。
99. The MPLS-TP control plane for LSPs must be based on the GMPLS control plane. More specifically, GMPLS RSVP-TE [RFC3473] and related extensions are used for LSP signaling, and GMPLS OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing ([RFC5921], Section 3.9).
99. LSP的MPLS-TP控制平面必须基于GMPLS控制平面。更具体地说，GMPLS RSVP-TE[RFC3473]和相关扩展用于LSP信令，GMPLS OSPF-TE[RFC5392]和ISIS-TE[RFC5316]用于路由（[RFC5921]，第3.9节）。
100. The MPLS-TP control plane for PWs must be based on the MPLS control plane for PWs, and more specifically, targeted LDP (T-LDP) [RFC4447] is used for PW signaling ([RFC5921], Section 3.9, paragraph 5).
100PWs的MPLS-TP控制平面必须基于PWs的MPLS控制平面，更具体地说，目标LDP（T-LDP）[RFC4447]用于PW信令（[RFC5921]，第3.9节，第5段）。
101. The MPLS-TP control plane must ensure its own survivability and be able to recover gracefully from failures and degradations. These include graceful restart and hot redundant configurations ([RFC5921], Section 3.9, paragraph 16).
101MPLS-TP控制平面必须确保其自身的生存能力，并能够从故障和降级中正常恢复。这些包括正常重启和热冗余配置（[RFC5921]，第3.9节，第16段）。
102. The MPLS-TP control plane must support linear, ring, and meshed protection schemes ([RFC5921], Section 3.12, paragraph 3).
102MPLS-TP控制平面必须支持线性、环形和网状保护方案（[RFC5921]，第3.12节，第3段）。
103. The MPLS-TP control plane must support the control of SPMEs (hierarchical LSPs) for new or existing end-to-end LSPs ([RFC5921], Section 3.12, paragraph 7).
103MPLS-TP控制平面必须支持新的或现有的端到端LSP的SPME（分层LSP）控制（[RFC5921]，第3.12节，第7段）。
The following additional requirements are based on [RFC5860] and [RFC6371]:
以下附加要求基于[RFC5860]和[RFC6371]：
104. The MPLS-TP control plane must support the capability to enable/disable OAM functions as part of service establishment ([RFC5860], Section 2.1.6, paragraph 1. Note that OAM functions are applicable regardless of the label stack depth (i.e., level of LSP hierarchy or PW) ([RFC5860], Section 2.1.1, paragraph 3).
104MPLS-TP控制平面必须支持作为服务建立的一部分启用/禁用OAM功能的能力（[RFC5860]，第2.1.6节，第1段。注意，OAM功能适用于标签堆栈深度（即LSP层次或PW的级别）（[RFC5860]，第2.1.1节，第3段）。
105. The MPLS-TP control plane must support the capability to enable/disable OAM functions after service establishment. In such cases, the customer must not perceive service degradation as a result of OAM enabling/disabling ([RFC5860], Section 2.1.6, paragraphs 1 and 2).
105MPLS-TP控制平面必须支持在服务建立后启用/禁用OAM功能的能力。在这种情况下，客户不得认为OAM启用/禁用导致服务降级（[RFC5860]，第2.1.6节，第1段和第2段）。
106. The MPLS-TP control plane must support dynamic control of any of the existing IP/MPLS and PW OAM protocols, e.g., LSP-Ping [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD [RFC5885] ([RFC5860], Section 2.1.4, paragraph 2).
106MPLS-TP控制平面必须支持对任何现有IP/MPLS和PW OAM协议的动态控制，例如LSP Ping[RFC4379]、MPLS-BFD[RFC5884]、VCCV[RFC5085]和VCCV-BFD[RFC5885]（[RFC5860]，第2.1.4节，第2段）。
107. The MPLS-TP control plane must allow for the ability to support experimental OAM functions. These functions must be disabled by default ([RFC5860], Section 2.2, paragraph 2).
107MPLS-TP控制平面必须能够支持实验性OAM功能。默认情况下必须禁用这些功能（[RFC5860]，第2.2节，第2段）。
108. The MPLS-TP control plane must support the choice of which (if any) OAM function(s) to use and to which PW, LSP or Section it applies ([RFC5860], Section 2.2, paragraph 3).
108MPLS-TP控制平面必须支持选择使用哪个（如果有）OAM功能，以及应用哪个PW、LSP或章节（[RFC5860]，第2.2节，第3段）。
109. The MPLS-TP control plane must allow (e.g., enable/disable) mechanisms that support the localization of faults and the notification of appropriate nodes ([RFC5860], Section 2.2.1, paragraph 1).
109MPLS-TP控制平面必须允许（例如，启用/禁用）支持故障定位和适当节点通知的机制（[RFC5860]，第2.2.1节，第1段）。
110. The MPLS-TP control plane may support mechanisms that permit the service provider to be informed of a fault or defect affecting the service(s) it provides, even if the fault or defect is located outside of his domain ([RFC5860], Section 2.2.1, paragraph 2).
110MPLS-TP控制平面可支持允许服务提供商被告知影响其提供的服务的故障或缺陷的机制，即使故障或缺陷位于其域之外（[RFC5860]，第2.2.1节，第2段）。
111. Information exchange between various nodes involved in the MPLS-TP control plane should be reliable such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes ([RFC5860], Section 2.2.1, paragraph 3).
111MPLS-TP控制平面中涉及的各个节点之间的信息交换应该是可靠的，例如，缺陷或故障被正确检测，或者状态变化被适当的节点有效地知道（[RFC5860]，第2.2.1节，第3段）。
112. The MPLS-TP control plane must provide functionality to control an end point's ability to monitor the liveness of a PW, LSP, or Section ([RFC5860], Section 2.2.2, paragraph 1).
112MPLS-TP控制平面必须提供控制端点监控PW、LSP或区段活动性的功能（[RFC5860]，第2.2.2节，第1段）。
113. The MPLS-TP control plane must provide functionality to control an end point's ability to determine whether or not it is connected to specific end point(s) by means of the expected PW, LSP, or Section ([RFC5860], Section 2.2.3, paragraph 1).
113MPLS-TP控制平面必须提供控制端点能力的功能，以确定其是否通过预期PW、LSP或章节（RFC5860，第2.2.3节，第1段）连接到特定端点。
a. The MPLS-TP control plane must provide mechanisms to control an end point's ability to perform this function proactively ([RFC5860], Section 2.2.3, paragraph 2).
a. MPLS-TP控制平面必须提供机制来控制端点主动执行此功能的能力（[RFC5860]，第2.2.3节，第2段）。
b. The MPLS-TP control plane must provide mechanisms to control an end point's ability to perform this function on-demand ([RFC5860], Section 2.2.3, paragraph 3).
b. MPLS-TP控制平面必须提供机制来控制端点按需执行此功能的能力（[RFC5860]，第2.2.3节，第3段）。
114. The MPLS-TP control plane must provide functionality to control diagnostic testing on a PW, LSP or Section ([RFC5860], Section 2.2.5, paragraph 1).
114MPLS-TP控制平面必须提供控制PW、LSP或部分（[RFC5860]，第2.2.5节，第1段）诊断测试的功能。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.5, paragraph 2).
a. MPLS-TP控制平面必须提供按需控制此功能性能的机制（[RFC5860]，第2.2.5节，第2段）。
115. The MPLS-TP control plane must provide functionality to enable an end point to discover the Intermediate Point(s) (if any) and end point(s) along a PW, LSP, or Section, and more generally to trace (record) the route of a PW, LSP, or Section ([RFC5860], Section 2.2.4, paragraph 1).
115MPLS-TP控制平面必须提供功能，使端点能够沿PW、LSP或区段发现中间点（如有）和端点，更一般地说，能够跟踪（记录）PW、LSP或区段的路线（[RFC5860]，第2.2.4节，第1段）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.4, paragraph 2).
a. MPLS-TP控制平面必须提供按需控制该功能性能的机制（[RFC5860]，第2.2.4节，第2段）。
116. The MPLS-TP control plane must provide functionality to enable an end point of a PW, LSP, or Section to instruct its associated end point(s) to lock the PW, LSP, or Section ([RFC5860], Section 2.2.6, paragraph 1).
116MPLS-TP控制平面必须提供功能，使PW、LSP或区段的端点能够指示其相关端点锁定PW、LSP或区段（[RFC5860]，第2.2.6节，第1段）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.6, paragraph 2).
a. MPLS-TP控制平面必须提供按需控制该功能性能的机制（[RFC5860]，第2.2.6节，第2段）。
117. The MPLS-TP control plane must provide functionality to enable an Intermediate Point of a PW or LSP to report, to an end point of that same PW or LSP, a lock condition indirectly affecting that PW or LSP ([RFC5860], Section 2.2.7, paragraph 1).
117MPLS-TP控制平面必须提供功能，使PW或LSP的中间点能够向该PW或LSP的端点报告间接影响该PW或LSP的锁定状态（[RFC5860]，第2.2.7节，第1段）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.7, paragraph 2).
a. MPLS-TP控制平面必须提供主动控制该功能性能的机制（[RFC5860]，第2.2.7节，第2段）。
118. The MPLS-TP control plane must provide functionality to enable an Intermediate Point of a PW or LSP to report, to an end point of that same PW or LSP, a fault or defect condition affecting that PW or LSP ([RFC5860], Section 2.2.8, paragraph 1).
118MPLS-TP控制平面必须提供功能，使PW或LSP的中间点能够向该PW或LSP的端点报告影响该PW或LSP的故障或缺陷状况（[RFC5860]，第2.2.8节，第1段）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.8, paragraph 2).
a. MPLS-TP控制平面必须提供主动控制该功能性能的机制（[RFC5860]，第2.2.8节，第2段）。
119. The MPLS-TP control plane must provide functionality to enable an end point to report, to its associated end point, a fault or defect condition that it detects on a PW, LSP, or Section for which they are the end points ([RFC5860], Section 2.2.9, paragraph 1).
119MPLS-TP控制平面必须提供功能，以使端点能够向其相关端点报告其在PW、LSP或其作为端点的截面上检测到的故障或缺陷状况（[RFC5860]，第2.2.9节，第1段）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.9, paragraph 2).
a. MPLS-TP控制平面必须提供主动控制该功能性能的机制（[RFC5860]，第2.2.9节，第2段）。
120. The MPLS-TP control plane must provide functionality to enable the propagation, across an MPLS-TP network, of information pertaining to a client defect or fault condition detected at an end point of a PW or LSP, if the client-layer mechanisms do not provide an alarm notification/propagation mechanism ([RFC5860], Section 2.2.10, paragraph 1).
120如果客户端层机制不提供报警通知/传播机制（[RFC5860]，第2.2.10节，第1段），则MPLS-TP控制平面必须提供功能，以便在MPLS-TP网络上传播与PW或LSP端点处检测到的客户端缺陷或故障状况有关的信息。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.10, paragraph 2).
a. MPLS-TP控制平面必须提供主动控制该功能性能的机制（[RFC5860]，第2.2.10节，第2段）。
121. The MPLS-TP control plane must provide functionality to enable the control of quantification of packet loss ratio over a PW, LSP, or Section ([RFC5860], Section 2.2.11, paragraph 1).
121MPLS-TP控制平面必须提供功能，以便能够控制PW、LSP或区段上的分组丢失率量化（[RFC5860]，第2.2.11节，第1段）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively and on-demand ([RFC5860], Section 2.2.11, paragraph 4).
a. MPLS-TP控制平面必须提供主动和按需控制此功能性能的机制（[RFC5860]，第2.2.11节，第4段）。
122. The MPLS-TP control plane must provide functionality to control the quantification and reporting of the one-way, and if appropriate, the two-way, delay of a PW, LSP, or Section ([RFC5860], Section 2.2.12, paragraph 1).
122MPLS-TP控制平面必须提供功能，以控制PW、LSP或区段（第2.2.12节，第1段，[RFC5860]）的单向和双向延迟的量化和报告。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively and on-demand ([RFC5860], Section 2.2.12, paragraph 6).
a. MPLS-TP控制平面必须提供主动和按需控制此功能性能的机制（[RFC5860]，第2.2.12节，第6段）。
123. The MPLS-TP control plane must support the configuration of OAM functional components that include Maintenance Entities (MEs) and Maintenance Entity Groups (MEGs) as instantiated in MEPs, MIPs, and SPMEs ([RFC6371], Section 3.6).
123MPLS-TP控制平面必须支持OAM功能组件的配置，这些组件包括MEP、MIPs和SPME中实例化的维护实体（ME）和维护实体组（MEG）（[RFC6371]，第3.6节）。
124. For dynamically established transport paths, the control plane must support the configuration of OAM operations ([RFC6371], Section 5).
124对于动态建立的传输路径，控制平面必须支持OAM操作的配置（[RFC6371]，第5节）。
a. The MPLS-TP control plane must provide mechanisms to configure proactive monitoring for a MEG at, or after, transport path creation time.
a. MPLS-TP控制平面必须提供机制，以便在传输路径创建时或之后为MEG配置主动监控。
b. The MPLS-TP control plane must provide mechanisms to configure the operational characteristics of in-band measurement transactions (e.g., Connectivity Verification (CV), Loss Measurement (LM), etc.) at MEPs (associated with a transport path).
b. MPLS-TP控制平面必须提供机制，以配置MEP（与传输路径相关）处带内测量事务（例如，连接验证（CV）、损耗测量（LM）等）的操作特性。
c. The MPLS-TP control plane may provide mechanisms to configure server-layer event reporting by intermediate nodes.
c. MPLS-TP控制平面可以提供通过中间节点配置服务器层事件报告的机制。
d. The MPLS-TP control plane may provide mechanisms to configure the reporting of measurements resulting from proactive monitoring.
d. MPLS-TP控制平面可以提供机制来配置由主动监视产生的测量报告。
125. The MPLS-TP control plane must support the control of the loss of continuity (LOC) traffic block consequent action ([RFC6371], Section 5.1.2, paragraph 4).
125MPLS-TP控制平面必须支持连续性丧失（LOC）通信阻塞后续行动的控制（[RFC6371]，第5.1.2节，第4段）。
126. For dynamically established transport paths that have a proactive Continuity Check and Connectivity Verification (CC-V) function enabled, the control plane must support the signaling of the following MEP configuration information ([RFC6371], Section 5.1.3):
126对于启用了主动连续性检查和连接验证（CC-V）功能的动态建立的传输路径，控制平面必须支持以下MEP配置信息的信令（[RFC6371]，第5.1.3节）：
a. The MPLS-TP control plane must provide mechanisms to configure the MEG identifier to which the MEP belongs.
a. MPLS-TP控制平面必须提供配置MEP所属MEG标识符的机制。
b. The MPLS-TP control plane must provide mechanisms to configure a MEP's own identity inside a MEG.
b. MPLS-TP控制平面必须提供在MEG内配置MEP自身身份的机制。
c. The MPLS-TP control plane must provide mechanisms to configure the list of the other MEPs in the MEG.
c. MPLS-TP控制平面必须提供配置MEG中其他MEP列表的机制。
d. The MPLS-TP control plane must provide mechanisms to configure the CC-V transmission rate / reception period (covering all application types).
d. MPLS-TP控制平面必须提供配置CC-V传输速率/接收周期（涵盖所有应用类型）的机制。
127. The MPLS-TP control plane must provide mechanisms to configure the generation of Alarm Indication Signal (AIS) packets for each MEG ([RFC6371], Section 5.3, paragraph 9).
127MPLS-TP控制平面必须提供机制，以配置每个MEG的报警指示信号（AIS）包的生成（[RFC6371]，第5.3节，第9段）。
128. The MPLS-TP control plane must provide mechanisms to configure the generation of Lock Report (LKR) packets for each MEG ([RFC6371], Section 5.4, paragraph 9).
128MPLS-TP控制平面必须提供机制，为每个MEG配置锁报告（LKR）包的生成（[RFC6371]，第5.4节，第9段）。
129. The MPLS-TP control plane must provide mechanisms to configure the use of proactive Packet Loss Measurement (LM), and the transmission rate and Per-Hop Behavior (PHB) class associated with the LM OAM packets originating from a MEP ([RFC6371], Section 5.5.1, paragraph 1).
129MPLS-TP控制平面必须提供机制来配置主动数据包丢失测量（LM）的使用，以及与源自MEP的LM OAM数据包相关联的传输速率和每跳行为（PHB）类（[RFC6371]，第5.5.1节，第1段）。
130. The MPLS-TP control plane must provide mechanisms to configure the use of proactive Packet Delay Measurement (DM), and the transmission rate and PHB class associated with the DM OAM packets originating from a MEP ([RFC6371], Section 5.6.1, paragraph 1).
130MPLS-TP控制平面必须提供机制来配置主动数据包延迟测量（DM）的使用，以及与源自MEP的DM OAM数据包相关联的传输速率和PHB等级（[RFC6371]，第5.6.1节，第1段）。
131. The MPLS-TP control plane must provide mechanisms to configure the use of Client Failure Indication (CFI), and the transmission rate and PHB class associated with the CFI OAM packets originating from a MEP ([RFC6371], Section 5.7.1, paragraph 1).
131MPLS-TP控制平面必须提供机制来配置客户端故障指示（CFI）的使用，以及与源自MEP的CFI OAM数据包相关联的传输速率和PHB等级（[RFC6371]，第5.7.1节，第1段）。
132. The MPLS-TP control plane should provide mechanisms to control the use of on-demand CV packets ([RFC6371], Section 6.1).
132MPLS-TP控制平面应提供控制按需CV数据包使用的机制（[RFC6371]，第6.1节）。
a. The MPLS-TP control plane should provide mechanisms to configure the number of packets to be transmitted/received in each burst of on-demand CV packets and their packet size ([RFC6371], Section 6.1.1, paragraph 1).
a. MPLS-TP控制平面应提供机制，以配置每个按需CV数据包突发中要发送/接收的数据包数量及其数据包大小（[RFC6371]，第6.1.1节，第1段）。
b. When an on-demand CV packet is used to check connectivity toward a target MIP, the MPLS-TP control plane should provide mechanisms to configure the number of hops to reach the target MIP ([RFC6371], Section 6.1.1, paragraph 2).
b. 当使用按需CV数据包检查与目标MIP的连接时，MPLS-TP控制平面应提供机制来配置到达目标MIP的跳数（[RFC6371]，第6.1.1节，第2段）。
c. The MPLS-TP control plane should provide mechanisms to configure the PHB of on-demand CV packets ([RFC6371], Section 6.1.1, paragraph 3).
c. MPLS-TP控制平面应提供配置按需CV数据包PHB的机制（[RFC6371]，第6.1.1节，第3段）。
133. The MPLS-TP control plane should provide mechanisms to control the use of on-demand LM, including configuration of the beginning and duration of the LM procedures, the transmission rate, and PHB associated with the LM OAM packets originating from a MEP ([RFC6371], Section 6.2.1).
133MPLS-TP控制平面应提供控制按需LM使用的机制，包括配置LM过程的开始和持续时间、传输速率以及与源自MEP的LM OAM数据包相关的PHB（[RFC6371]，第6.2.1节）。
134. The MPLS-TP control plane should provide mechanisms to control the use of throughput estimation ([RFC6371], Section 6.3.1).
134MPLS-TP控制平面应提供控制吞吐量估计使用的机制（[RFC6371]，第6.3.1节）。
135. The MPLS-TP control plane should provide mechanisms to control the use of on-demand DM, including configuration of the beginning and duration of the DM procedures, the transmission rate, and PHB associated with the DM OAM packets originating from a MEP ([RFC6371], Section 6.5.1).
135MPLS-TP控制平面应提供控制按需DM使用的机制，包括DM过程开始和持续时间的配置、传输速率以及与源自MEP的DM OAM数据包相关的PHB（[RFC6371]，第6.5.1节）。
There are no specific MPLS-TP control-plane security requirements. The existing framework for MPLS and GMPLS security is documented in [RFC5920], and that document applies equally to MPLS-TP.
没有具体的MPLS-TP控制平面安全要求。[RFC5920]中记录了MPLS和GMPLS安全的现有框架，该文件同样适用于MPLS-TP。
The following are requirements based on [RFC6370]:
以下是基于[RFC6370]的要求：
136. The MPLS-TP control plane must support MPLS-TP point-to-point tunnel identifiers of the forms defined in Section 5.1 of [RFC6370].
136MPLS-TP控制平面必须支持[RFC6370]第5.1节中定义的形式的MPLS-TP点对点隧道标识符。
137. The MPLS-TP control plane must support MPLS-TP LSP identifiers of the forms defined in Section 5.2 of [RFC6370], and the mappings to GMPLS as defined in Section 5.3 of [RFC6370].
137MPLS-TP控制平面必须支持[RFC6370]第5.2节中定义的形式的MPLS-TP LSP标识符，以及[RFC6370]第5.3节中定义的到GMPLS的映射。
138. The MPLS-TP control plane must support pseudowire path identifiers of the form defined in Section 6 of [RFC6370].
138MPLS-TP控制平面必须支持[RFC6370]第6节中定义的形式的伪线路径标识符。
139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs as defined in Section 7.1.1 of [RFC6370].
139MPLS-TP控制平面必须支持[RFC6370]第7.1.1节中定义的LSP和PW的MEG_ID。
140. The MPLS-TP control plane must support IP-compatible MEG_IDs for LSPs and PWs as defined in Section 7.1.2 of [RFC6370].
140MPLS-TP控制平面必须支持[RFC6370]第7.1.2节中定义的LSP和PW的IP兼容MEG_ID。
141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs of the forms defined in Section 7.2.1 of [RFC6370].
141MPLS-TP控制平面必须支持[RFC6370]第7.2.1节中定义的LSP和PW的MEP_ID。
142. The MPLS-TP control plane must support IP-based MEP_IDs for MPLS-TP LSP of the forms defined in Section 7.2.2.1 of [RFC6370].
142MPLS-TP控制平面必须支持[RFC6370]第7.2.2.1节中定义的形式的MPLS-TP LSP的基于IP的MEP_ID。
143. The MPLS-TP control plane must support IP-based MEP_IDs for Pseudowires of the form defined in Section 7.2.2.2 of [RFC6370].
143MPLS-TP控制平面必须支持[RFC6370]第7.2.2.2节中定义形式的伪线的基于IP的MEP_ID。
The data-plane relationship between PWs and LSPs is inherited from standard MPLS and is reviewed in the MPLS-TP framework [RFC5921]. Likewise, the control-plane relationship between PWs and LSPs is inherited from standard MPLS. This relationship is reviewed in this document. The relationship between the PW and LSP control planes in MPLS-TP is the same as the relationship found in the PWE3 Maintenance Reference Model as presented in the PWE3 architecture; see Figure 6 of [RFC3985]. The PWE3 architecture [RFC3985] states: "The PWE3 protocol-layering model is intended to minimize the differences between PWs operating over different PSN types". Additionally, PW control (maintenance) takes place separately from LSP signaling. [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of LDP as the control plane for PWs. This control can provide PW control without providing LSP control.
PWs和LSP之间的数据平面关系继承自标准MPLS，并在MPLS-TP框架[RFC5921]中进行审查。同样，PWs和LSP之间的控制平面关系继承自标准MPLS。本文件对这种关系进行了审查。MPLS-TP中PW和LSP控制平面之间的关系与PWE3体系结构中PWE3维护参考模型中的关系相同；参见[RFC3985]的图6。PWE3体系结构[RFC3985]指出：“PWE3协议分层模型旨在最大限度地减少在不同PSN类型上运行的PWs之间的差异”。此外，PW控制（维护）与LSP信令分开进行。[RFC4447]和[MS-PW-DYNAMIC]为将LDP用作PWs的控制平面提供了此类扩展。此控件可以提供PW控制而不提供LSP控制。
In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS RSVP-TE. While RSVP-TE could be extended to support PW control much as LDP was extended in [RFC4447], such extensions are out of scope of this document. This means that the control of PWs and LSPs will operate largely independently. The main coordination between LSP and PW control will occur within the nodes that terminate PWs or PW segments. See Section 5.3.2 for an additional discussion on such coordination.
在MPLS-TP的上下文中，LSP隧道信令通过GMPLS RSVP-TE提供。虽然RSVP-TE可以扩展以支持PW控制，就像[RFC4447]中扩展了LDP一样，但此类扩展超出了本文件的范围。这意味着PWs和LSP的控制将在很大程度上独立运行。LSP和PW控制之间的主要协调将发生在终止PWs或PW段的节点内。有关此类协调的更多讨论，请参见第5.3.2节。
It is worth noting that the control planes for PWs and LSPs may be used independently, and that one may be employed without the other. This translates into four possible scenarios: (1) no control plane is employed; (2) a control plane is used for both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs; (4) a control plane is used for PWs, but not LSPs.
值得注意的是，PWs和LSP的控制平面可以单独使用，一个可以不使用另一个。这转化为四种可能的情况：（1）没有使用控制平面；（2） LSP和PWs均使用控制平面；（3） 控制平面用于LSP，但不用于PWs；（4） 控制平面用于PWs，但不用于LSP。
The PW and LSP control planes, collectively, must satisfy the MPLS-TP control-plane requirements reviewed in this document. When client services are provided directly via LSPs, all requirements must be satisfied by the LSP control plane. When client services are provided via PWs, the PW and LSP control planes can operate in combination, and some functions may be satisfied via the PW control plane while others are provided to PWs by the LSP control plane. For
PW和LSP控制平面必须共同满足本文件中审查的MPLS-TP控制平面要求。当通过LSP直接提供客户服务时，LSP控制平面必须满足所有要求。当通过PWs提供客户服务时，PW和LSP控制平面可以组合运行，一些功能可以通过PW控制平面满足，而其他功能则由LSP控制平面提供给PWs。对于
example, to support the recovery functions described in [RFC6372], this document focuses on the control of the recovery functions at the LSP layer. PW-based recovery is under development at this time and may be used once defined.
例如，为了支持[RFC6372]中描述的恢复功能，本文档重点介绍LSP层的恢复功能控制。基于PW的恢复目前正在开发中，一旦定义，即可使用。
MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see [RFC3945], as the control plane for LSPs. The GMPLS control plane is based on the MPLS control plane. GMPLS includes support for MPLS labeled data and transport data planes. GMPLS includes most of the transport-centric features required to support MPLS-TP LSPs. This section will first review the features of GMPLS relevant to MPLS-TP LSPs, then identify how specific requirements can be met using existing GMPLS functions, and will conclude with extensions that are anticipated to support the remaining MPLS-TP control-plane requirements.
MPLS-TP使用通用MPLS（GMPLS）信令和路由，参见[RFC3945]，作为LSP的控制平面。GMPLS控制平面基于MPLS控制平面。GMPLS包括对MPLS标记的数据和传输数据平面的支持。GMPLS包括支持MPLS-TP LSP所需的大多数以传输为中心的功能。本节将首先回顾与MPLS-TP LSP相关的GMPLS功能，然后确定如何使用现有GMPLS功能满足特定要求，并将以支持剩余MPLS-TP控制平面要求的扩展作为结束。
This section reviews how existing GMPLS functions can be applied to MPLS-TP.
本节回顾如何将现有的GMPLS功能应用于MPLS-TP。
GMPLS supports both in-band and out-of-band control. The terms "in-band" and "out-of-band", in the context of this document, refer to the relationship of the control plane relative to the management and data planes. The terms may be used to refer to the control plane independent of the management plane, or to both of them in concert. The remainder of this section describes the relationship of the control plane to the management and data planes.
GMPLS支持带内和带外控制。在本文件的上下文中，“带内”和“带外”是指控制平面与管理平面和数据平面之间的关系。这些术语可用于指独立于管理平面的控制平面，或同时指两者。本节的其余部分描述了控制平面与管理平面和数据平面的关系。
There are multiple uses of both terms "in-band" and "out-of-band". The terms may relate to a channel, a path, or a network. Each of these can be used independently or in combination. Briefly, some typical usage of the terms is as follows:
“带内”和“带外”这两个术语有多种用途。这些术语可能与频道、路径或网络有关。每一个都可以单独使用或组合使用。简而言之，这些术语的一些典型用法如下：
o In-band This term is used to refer to cases where control-plane traffic is sent in the same communication channel used to transport associated user data or management traffic. IP, MPLS, and Ethernet networks are all examples where control traffic is typically sent in-band with the data traffic. An example of this case in the context of MPLS-TP is where control-plane traffic is sent via the MPLS Generic Associated Channel (G-ACh), see [RFC5586], using the same LSP as controlled user traffic.
o 带内该术语用于指控制平面业务在用于传输相关用户数据或管理业务的同一通信信道中发送的情况。IP、MPLS和以太网都是控制流量通常和数据流量一起在频带内发送的示例。在MPLS-TP的上下文中，这种情况的一个示例是，使用与受控用户通信相同的LSP，通过MPLS通用关联信道（G-ACh）发送控制平面通信，参见[RFC5586]。
o Out-of-band, in-fiber (same physical connection) This term is used to refer to cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control communication channel resides in the same fiber as either the management or data traffic. An example of this case in the context of MPLS-TP is where control-plane traffic is sent via the G-ACh using a dedicated LSP on the same link (interface) that carries controlled user traffic.
o 带外光纤（相同物理连接）此术语用于指使用与相关数据或管理通信不同的通信信道发送控制平面通信的情况，并且控制通信信道与管理或数据通信驻留在同一光纤中。在MPLS-TP的上下文中，这种情况的一个示例是，在承载受控用户业务的同一链路（接口）上，使用专用LSP经由G-ACh发送控制平面业务。
o Out-of-band, aligned topology This term is used to refer to the cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic follows the same node-to-node path as either the data or management traffic.
o 带外对齐拓扑该术语用于指使用与相关数据或管理通信不同的通信信道发送控制平面通信的情况，并且控制通信遵循与数据或管理通信相同的节点到节点路径。
Such topologies are usually supported using a parallel fiber or other configurations where multiple data channels are available and one is (dynamically) selected as the control channel. An example of this case in the context of MPLS-TP is where control-plane traffic is sent along the same nodal path, but not necessarily the same links (interfaces), as the corresponding controlled user traffic.
通常使用并行光纤或其他配置支持这种拓扑，其中多个数据通道可用，并且（动态）选择一个作为控制通道。在MPLS-TP的上下文中，这种情况的一个示例是，控制平面业务沿着与相应的受控用户业务相同的节点路径发送，但不一定是相同的链路（接口）。
o Out-of-band, independent topology This term is used to refer to the cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic may follow a path that is completely independent of the data traffic.
o 带外独立拓扑该术语用于指使用与相关数据或管理业务不同的通信信道发送控制平面业务的情况，并且控制业务可以遵循完全独立于数据业务的路径。
Such configurations are a superset of the other cases and do not preclude the use of in-fiber or aligned topology links, but alignment is not required. An example of this case in the context of MPLS-TP is where control-plane traffic is sent between controlling nodes using any available path and links, completely without regard for the path(s) taken by corresponding management or user traffic.
这种配置是其他情况的超集，不排除使用光纤内或对齐拓扑链路，但不需要对齐。在MPLS-TP的上下文中，这种情况的一个示例是使用任何可用路径和链路在控制节点之间发送控制平面业务，完全不考虑相应管理或用户业务所采用的路径。
In the context of MPLS-TP requirements, requirement 14 (see Section 2 above) can be met using out-of-band in-fiber or aligned topology types of control. Requirement 15 can only be met by using out-of-band, independent topology. G-ACh is likely to be used extensively in MPLS-TP networks to support the MPLS-TP control (and management) planes.
在MPLS-TP要求的上下文中，可以使用带外光纤或对齐拓扑类型的控制来满足要求14（见上文第2节）。只有使用带外独立拓扑才能满足要求15。G-ACh很可能在MPLS-TP网络中广泛使用，以支持MPLS-TP控制（和管理）平面。
MPLS-TP reuses and supports the addressing mechanisms supported by MPLS. The MPLS-TP identifiers document (see [RFC6370]) provides additional context on how IP addresses are used within MPLS-TP. MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address families to identify MPLS-TP nodes by default for network management and signaling purposes. The address spaces and neighbor adjacencies in the control, management, and data planes used in an MPLS-TP network may be completely separated or combined at the discretion of an MPLS-TP operator and based on the equipment capabilities of a vendor. The separation of the control and management planes from the data plane allows each plane to be independently addressable. Each plane may use addresses that are not mutually reachable, e.g., it is likely that the data plane will not be able to reach an address from the management or control planes and vice versa. Each plane may also use a different address family. It is even possible to reuse addresses in each plane, but this is not recommended as it may lead to operational confusion. As previously mentioned, the G-ACh mechanism defined in [RFC5586] is expected to be used extensively in MPLS-TP networks to support the MPLS-TP control (and management) planes.
MPLS-TP重用并支持MPLS支持的寻址机制。MPLS-TP标识符文档（参见[RFC6370]）提供了有关如何在MPLS-TP中使用IP地址的附加上下文。默认情况下，MPLS和MPLS-TP使用IPv4和IPv6地址族来标识MPLS-TP节点，用于网络管理和信令目的。MPLS-TP网络中使用的控制、管理和数据平面中的地址空间和邻居邻接可以由MPLS-TP运营商根据供应商的设备能力完全分离或组合。控制和管理平面与数据平面的分离允许每个平面独立寻址。每个平面可能使用相互无法访问的地址，例如，数据平面可能无法从管理或控制平面访问地址，反之亦然。每个平面也可以使用不同的地址族。甚至可以在每个平面中重用地址，但不建议这样做，因为这可能会导致操作混乱。如前所述，[RFC5586]中定义的G-ACh机制预计将在MPLS-TP网络中广泛使用，以支持MPLS-TP控制（和管理）平面。
Routing support for MPLS-TP LSPs is based on GMPLS routing. GMPLS routing builds on TE routing and has been extended to support multiple switching technologies per [RFC3945] and [RFC4202] as well as multiple levels of packet switching within a single network. IS-IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF extensions for GMPLS are defined in [RFC4203] and [RFC5392], which build on the TE extensions to OSPF defined in [RFC3630]. The listed RFCs should be viewed as a starting point rather than a comprehensive list as there are other IS-IS and OSPF extensions, as defined in IETF RFCs, that can be used within an MPLS-TP network.
MPLS-TP LSP的路由支持基于GMPLS路由。GMPLS路由建立在TE路由的基础上，并已扩展为支持[RFC3945]和[RFC4202]中的多种交换技术，以及单个网络中的多级分组交换。[RFC5307]和[RFC5316]中定义了GMPLS的IS-IS扩展，它们建立在[RFC5305]中定义的IS-IS扩展的基础上。[RFC4203]和[RFC5392]中定义了GMPLS的OSPF扩展，它们基于[RFC3630]中定义的OSPF TE扩展。列出的RFC应被视为起点，而不是综合列表，因为还有其他IS-IS和OSPF扩展，如IETF RFC中定义的，可在MPLS-TP网络中使用。
Both MPLS and GMPLS allow for traffic engineering and constraint-based path computation. MPLS path computation provides paths for MPLS-TE unidirectional P2P and P2MP LSPs. GMPLS path computation adds bidirectional LSPs, explicit recovery path computation, as well as support for the other functions discussed in this section.
MPLS和GMPLS都允许流量工程和基于约束的路径计算。MPLS路径计算为MPLS-TE单向P2P和P2MP LSP提供路径。GMPLS路径计算增加了双向LSP、显式恢复路径计算以及对本节讨论的其他函数的支持。
Both MPLS and GMPLS path computation allow for the restriction of path selection based on the use of Explicit Route Objects (EROs) and other LSP attributes; see [RFC3209] and [RFC3473]. In all cases, no
MPLS和GMPLS路径计算都允许基于使用显式路由对象（ERO）和其他LSP属性来限制路径选择；参见[RFC3209]和[RFC3473]。在所有情况下，都不是
specific algorithm is standardized by the IETF. This is anticipated to continue to be the case for MPLS-TP LSPs.
具体算法由IETF标准化。预计MPLS-TP LSP的情况将继续如此。
Path Computation Element (PCE)-based approaches, see [RFC4655], may be used for path computation of a GMPLS LSP, and consequently an MPLS-TP LSP, across domains and in a single domain. In cases where PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], will be used to communicate PCE-related requests and responses. MPLS-TP-specific extensions to PCEP are currently out of scope of the MPLS-TP project and this document.
基于路径计算元素（PCE）的方法（参见[RFC4655]）可用于跨域和单个域的GMPLS LSP以及MPLS-TP LSP的路径计算。在使用PCE的情况下，PCE通信协议（PCEP）（参见[RFC5440]）将用于通信PCE相关的请求和响应。PCEP的MPLS TP特定扩展目前不在MPLS-TP项目和本文档的范围内。
GMPLS signaling is defined in [RFC3471] and [RFC3473] and is based on RSVP-TE [RFC3209]. Constraint-based Routed LDP (CR-LDP) GMPLS (see [RFC3472]) is no longer under active development within the IETF, i.e., it is deprecated (see [RFC3468]) and must not be used for MPLS nor MPLS-TP consequently. In general, all RSVP-TE extensions that apply to MPLS may also be used for GMPLS and consequently MPLS-TP. Most notably, this includes support for P2MP signaling as defined in [RFC4875].
GMPLS信令在[RFC3471]和[RFC3473]中定义，并基于RSVP-TE[RFC3209]。基于约束的路由LDP（CR-LDP）GMPLS（参见[RFC3472]）不再在IETF中积极开发，即，它已被弃用（参见[RFC3468]），因此不得用于MPLS或MPLS-TP。通常，适用于MPLS的所有RSVP-TE扩展也可用于GMPLS，因此也可用于MPLS-TP。最值得注意的是，这包括对[RFC4875]中定义的P2MP信令的支持。
GMPLS signaling includes a number of MPLS-TP required functions -- notably, support for out-of-band control, bidirectional LSPs, and independent control- and data-plane fault management. There are also numerous other GMPLS and MPLS extensions that can be used to provide specific functions in MPLS-TP networks. Specific references are provided below.
GMPLS信令包括许多MPLS-TP所需的功能——特别是支持带外控制、双向LSP以及独立的控制和数据平面故障管理。还有许多其他GMPLS和MPLS扩展可用于在MPLS-TP网络中提供特定功能。具体参考资料如下。
Support for unnumbered links (i.e., links that do not have IP addresses) is permitted in MPLS-TP and its usage is at the discretion of the network operator. Support for unnumbered links is included for routing using OSPF [RFC4203] and IS-IS [RFC5307], and for signaling in [RFC3477].
MPLS-TP允许支持未编号的链路（即没有IP地址的链路），其使用由网络运营商自行决定。对于使用OSPF[RFC4203]和is-is[RFC5307]的路由以及[RFC3477]中的信令，包括对未编号链路的支持。
Link bundling provides a local construct that can be used to improve scaling of TE routing when multiple data links are shared between node pairs. Link bundling for MPLS and GMPLS networks is defined in [RFC4201]. Link bundling may be used in MPLS-TP networks, and its use is at the discretion of the network operator.
链路绑定提供了一种本地构造，当节点对之间共享多个数据链路时，可用于改进TE路由的扩展。MPLS和GMPLS网络的链路捆绑在[RFC4201]中定义。链路捆绑可用于MPLS-TP网络，其使用由网络运营商自行决定。
This section reuses text from [RFC6107].
本节重用[RFC6107]中的文本。
[RFC3031] describes how MPLS labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of protocol mechanisms for the establishment of a hierarchical LSP that can carry one or more other LSPs.
[RFC3031]描述了如何堆叠MPLS标签，以便LSP可以与一个LSP嵌套在另一个LSP中。分层LSP（H-LSP）的概念在[RFC4206]中通过一组协议机制形式化，用于建立可承载一个或多个其他LSP的分层LSP。
[RFC4206] goes on to explain that a hierarchical LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable network, the hierarchical LSP can carry other packet switch capable LSPs using the MPLS label stack.
[RFC4206]接着解释了分层LSP只能根据其切换类型携带其他LSP。这是标签携带方式的一个功能。在支持分组交换的网络中，分层LSP可以使用MPLS标签栈承载其他支持分组交换的LSP。
Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to be treated as a single hop in the path of another LSP. This mechanism is also sometimes known as "non-adjacent signaling", see [RFC4208].
[RFC4206]中定义的信令机制允许将分层LSP视为另一LSP路径中的单跳。这种机制有时也称为“非相邻信令”，参见[RFC4208]。
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same instance of the control plane that advertises the TE links from which the LSP is constructed. The LSP itself is called an FA-LSP. FA-LSPs are analogous to MPLS-TP Sections as discussed in [RFC5960].
转发邻接（FA）在[RFC4206]中定义为从LSP创建的数据链路，并在控制平面的同一实例中播发，该控制平面播发LSP从中构建的TE链路。LSP本身称为FA-LSP。FA LSP类似于[RFC5960]中讨论的MPLS-TP部分。
Thus, a hierarchical LSP may form an FA such that it is advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that the LSP traverses.
因此，分层LSP可以形成FA，使得其在路由协议的同一实例中作为TE链路被通告，该实例与用于通告LSP所穿越的TE链路的实例相同。
As observed in [RFC4206], the nodes at the ends of an FA would not usually have a routing adjacency.
正如在[RFC4206]中所观察到的，FA末端的节点通常不会有路由邻接。
LSP hierarchy is expected to play an important role in MPLS-TP networks, particularly in the context of scaling and recovery as well as supporting SPMEs.
LSP层次结构有望在MPLS-TP网络中发挥重要作用，特别是在扩展和恢复以及支持SPME的环境中。
GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs recovery in [RFC4872] and segment recovery in [RFC4873]. GMPLS segment recovery provides a superset of the function in end-to-end recovery. End-to-end recovery can be viewed as a special case of segment recovery where there is a single recovery domain whose borders coincide with the ingress and egress of the LSP, although specific procedures are defined.
GMPLS定义了RSVP-TE扩展，以支持[RFC4872]中的端到端GMPLS LSP恢复和[RFC4873]中的段恢复。GMPLS段恢复提供了端到端恢复功能的超集。端到端恢复可被视为段恢复的一种特殊情况，其中有一个恢复域，其边界与LSP的入口和出口重合，尽管定义了具体的程序。
The five defined types of recovery defined in GMPLS are:
GMPLS中定义的五种回收类型为：
- 1+1 bidirectional protection for P2P LSPs - 1+1 unidirectional protection for P2MP LSPs - 1:n (including 1:1) protection with or without extra traffic - Rerouting without extra traffic (sometimes known as soft rerouting), including shared mesh restoration - Full LSP rerouting
- P2P LSP的1+1双向保护-P2MP LSP的1+1单向保护-1:n（包括1:1）保护，有或没有额外流量-无额外流量的重路由（有时称为软重路由），包括共享网格恢复-完全LSP重路由
Recovery for MPLS-TP LSPs, as discussed in [RFC6372], is signaled using the mechanism defined in [RFC4872] and [RFC4873]. Note that when MEPs are required for the OAM CC function and the MEPs exist at LSP transit nodes, each MEP is instantiated at a hierarchical LSP end point, and protection is provided end-to-end for the hierarchical LSP. (Protection can be signaled using either [RFC4872] or [RFC4873] defined procedures.) The use of Notify messages to trigger protection switching and recovery is not required in MPLS-TP, as this function is expected to be supported via OAM. However, its use is not precluded.
如[RFC6372]所述，MPLS-TP LSP的恢复使用[RFC4872]和[RFC4873]中定义的机制发出信号。注意，当OAM CC功能需要MEP并且MEP存在于LSP传输节点时，每个MEP在分层LSP端点处实例化，并且为分层LSP提供端到端保护。（可以使用[RFC4872]或[RFC4873]定义的过程发出保护信号。）MPLS-TP中不需要使用通知消息来触发保护切换和恢复，因为预期通过OAM支持此功能。然而，它的使用并不排除。
The majority of RFCs about the GMPLS control plane define the control plane from the context of an internal Network-to-Network Interface (I-NNI). In the MPLS-TP context, some operators may choose to deploy signaled interfaces across User-to-Network Interfaces (UNIs) and across inter-provider, external Network-to-Network Interfaces (E-NNIs). Such support is embodied in [RFC4208] for UNIs and in [RFC5787] for routing areas in support of E-NNIs. This work may require extensions in order to meet the specific needs of an MPLS-TP UNI and E-NNI.
关于GMPLS控制平面的大多数RFC从内部网络到网络接口（I-NNI）的上下文定义控制平面。在MPLS-TP上下文中，一些运营商可能选择跨用户到网络接口（UNI）和跨提供商间、外部网络到网络接口（E-NNI）部署信号接口。这种支持体现在[RFC4208]中用于UNIs，以及[RFC5787]中用于支持E-NNI的路由区域。这项工作可能需要扩展以满足MPLS-TP UNI和E-NNI的特定需求。
MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM functions. The MPLS-TP control plane will not itself provide OAM functions, but it will be used to instantiate and otherwise control MPLS-TP OAM functions.
MPLS-TP定义为支持一组全面的MPLS-TP OAM功能。MPLS-TP控制平面本身不会提供OAM功能，但它将用于实例化和控制MPLS-TP OAM功能。
Specific OAM requirements for MPLS-TP are documented in [RFC5860]. This document also states that it is required that the control plane be able to configure and control OAM entities. This requirement is not yet addressed by the existing RFCs, but such work is now under way, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT].
MPLS-TP的特定OAM要求记录在[RFC5860]中。本文件还规定，要求控制平面能够配置和控制OAM实体。现有的RFC尚未解决这一要求，但此类工作正在进行中，例如，[CCAMP-OAM-FWK]和[CCAMP-OAM-EXT]。
Many OAM functions occur on a per-LSP basis, are typically in-band, and are initiated immediately after LSP establishment. Hence, it is desirable that such functions be established and activated via the
许多OAM功能以每个LSP为基础，通常在频带内，并在LSP建立后立即启动。因此，希望通过网络建立和激活这些功能
same control-plane signaling used to set up the LSP, as this effectively synchronizes OAM with the LSP lifetime and avoids the extra overhead and potential errors associated with separate OAM configuration mechanisms.
用于设置LSP的相同控制平面信令，因为这有效地将OAM与LSP生存期同步，并避免与单独的OAM配置机制相关联的额外开销和潜在错误。
There is no MPLS-TP requirement for a standardized management interface to the MPLS-TP control plane. That said, MPLS and GMPLS support a number of standardized management functions. These include the MPLS-TE/GMPLS TE Database Management Information Base [TE-MIB]; the MPLS-TE MIB [RFC3812]; the MPLS LSR MIB [RFC3813]; the GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB [RFC4803]. These MIB modules may be used in MPLS-TP networks. A general overview of MPLS-TP related MIB modules can be found in [TP-MIB]. Network management requirements for MPLS-based transport networks are provided in [RFC5951].
对于MPLS-TP控制平面的标准化管理接口，不存在MPLS-TP要求。也就是说，MPLS和GMPLS支持许多标准化的管理功能。其中包括MPLS-TE/GMPLS-TE数据库管理信息库[TE-MIB]；MPLS-TE MIB[RFC3812]；MPLS LSR MIB[RFC3813]；GMPLS TE MIB[RFC4802]；和GMPLS LSR MIB[RFC4803]。这些MIB模块可用于MPLS-TP网络。有关MPLS-TP相关MIB模块的概述，请参见[TP-MIB]。[RFC5951]中提供了基于MPLS的传输网络的网络管理要求。
The GMPLS control plane allows for management-plane recovery triggers and directly supports control-plane recovery triggers. Support for control-plane recovery triggers is defined in [RFC4872], which refers to the triggers as "Recovery Commands". These commands can be used with both end-to-end and segment recovery, but are always controlled on an end-to-end basis. The recovery triggers/commands defined in [RFC4872] are:
GMPLS控制平面允许管理平面恢复触发器，并直接支持控制平面恢复触发器。[RFC4872]中定义了对控制平面恢复触发器的支持，将触发器称为“恢复命令”。这些命令可用于端到端和段恢复，但始终以端到端为基础进行控制。[RFC4872]中定义的恢复触发器/命令包括：
a. Lockout of recovery LSP
a. 恢复LSP的锁定
b. Lockout of normal traffic
b. 封锁正常交通
c. Forced switch for normal traffic
c. 正常交通的强制开关
d. Requested switch for normal traffic
d. 正常通信请求的交换机
e. Requested switch for recovery LSP
e. 为恢复LSP请求的交换机
Note that control-plane triggers are typically invoked in response to a management-plane request at the ingress.
请注意，控制平面触发器通常是在入口响应管理平面请求时调用的。
In networks where both the control plane and management plane are provided, LSP provisioning can be done either by the control plane or management plane. As mentioned in the requirements section above, it must be possible to transfer, or handover, a management-plane-created LSP to the control-plane domain and vice versa. [RFC5493] defines
在同时提供控制平面和管理平面的网络中，LSP供应可以由控制平面或管理平面来完成。如上述需求部分所述，必须能够将LSP创建的管理平面转移或移交到控制平面域，反之亦然。[RFC5493]定义了
the specific requirements for an LSP ownership handover procedure. It must be possible for the control plane to provide the management plane, in a reliable manner, with the status or result of an operation performed by the management plane. This notification may be either synchronous or asynchronous with respect to the operation. Moreover, it must be possible for the management plane to monitor the status of the control plane, for example, the status of a TE link, its available resources, etc. This monitoring may be based on queries initiated by the management plane or on notifications generated by the control plane. A mechanism must be made available by the control plane to the management plane to log operation of a control-plane LSP; that is, it must be possible from the NMS to have a clear view of the life (traffic hit, action performed, signaling, etc.) of a given LSP. The LSP handover procedure for MPLS-TP LSPs is supported via [RFC5852].
LSP所有权移交程序的具体要求。控制平面必须能够以可靠的方式向管理平面提供管理平面执行的操作的状态或结果。此通知对于操作可以是同步的，也可以是异步的。此外，管理平面必须能够监控控制平面的状态，例如TE链路的状态、其可用资源等。该监控可以基于管理平面发起的查询或控制平面生成的通知。控制平面必须向管理平面提供机制，以记录控制平面LSP的操作；也就是说，必须能够从NMS清楚地了解给定LSP的寿命（流量命中、执行的操作、信令等）。通过[RFC5852]支持MPLS-TP LSP的LSP切换过程。
The following table shows how the MPLS-TP control-plane requirements can be met using the existing GMPLS control plane (which builds on the MPLS control plane). Areas where additional specifications are required are also identified. The table lists references based on the control-plane requirements as identified and numbered above in Section 2.
下表显示了如何使用现有的GMPLS控制平面（构建在MPLS控制平面上）满足MPLS-TP控制平面要求。还确定了需要附加规范的区域。该表列出了基于控制平面要求的参考，如上文第2节所述。
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 3 | [RFC5145] + Formal Definition (See Section 4.4.1) |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 6 | [RFC3471], [RFC3473], [RFC4875] |
| 7 | [RFC3471], [RFC3473] + |
| | Associated bidirectional LSPs (See Section 4.4.2) |
| 8 | [RFC4875] |
| 9 | [RFC3473] |
| 10 | Associated bidirectional LSPs (See Section 4.4.2) |
| 11 | Associated bidirectional LSPs (See Section 4.4.2) |
| 12 | [RFC3473] |
| 13 | [RFC5467] (Currently Experimental; See Section 4.4.3) |
| 14 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 15 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 16 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 17 | [RFC3945], [RFC4202] + proper vendor implementation |
| 18 | [RFC3945], [RFC4202] + proper vendor implementation |
| 19 | [RFC3945], [RFC4202] |
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 3 | [RFC5145] + Formal Definition (See Section 4.4.1) |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 6 | [RFC3471], [RFC3473], [RFC4875] |
| 7 | [RFC3471], [RFC3473] + |
| | Associated bidirectional LSPs (See Section 4.4.2) |
| 8 | [RFC4875] |
| 9 | [RFC3473] |
| 10 | Associated bidirectional LSPs (See Section 4.4.2) |
| 11 | Associated bidirectional LSPs (See Section 4.4.2) |
| 12 | [RFC3473] |
| 13 | [RFC5467] (Currently Experimental; See Section 4.4.3) |
| 14 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 15 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 16 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 17 | [RFC3945], [RFC4202] + proper vendor implementation |
| 18 | [RFC3945], [RFC4202] + proper vendor implementation |
| 19 | [RFC3945], [RFC4202] |
| 20 | [RFC3473] |
| 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC6107] |
| 26 | [RFC3473], [RFC4875] |
| 27 | [RFC3473], [RFC4875] |
| 28 | [RFC3945], [RFC3471], [RFC4202] |
| 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 30 | [RFC3945], [RFC3471], [RFC4202] |
| 31 | [RFC3945], [RFC3471], [RFC4202] |
| 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] |
| 33 | [RFC3473], [RFC4875] |
| 34 | [RFC4875] |
| 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 36 | [RFC3473], [RFC3209] (Make-before-break) |
| 37 | [RFC3473], [RFC3209] (Make-before-break) |
| 38 | [RFC4139], [RFC4258], [RFC5787] |
| 39 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 40 | [RFC3473], [RFC5063] |
| 41 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] |
| 42 | [RFC3945], [RFC3471], [RFC4202] |
| 43 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 44 | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 45 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 46 | [RFC5493] |
| 47 | [RFC4872], [RFC4873] |
| 48 | [RFC3945], [RFC3471], [RFC4202] |
| 49 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 50 | [RFC4872], [RFC4873] |
| 51 | [RFC4872], [RFC4873] + proper vendor implementation |
| 52 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 53 | [RFC4872], [RFC4873] |
| 54 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] |
| | Timers are a local implementation matter |
| 55 | [RFC4872], [RFC4873], [GMPLS-PS] + |
| | implementation of timers |
| 56 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 57 | [RFC4872], [RFC4873] |
| 58 | [RFC4872], [RFC4873] |
| 59 | [RFC4872], [RFC4873] |
| 60 | [RFC4872], [RFC4873], [RFC6107] |
| 61 | [RFC4872], [RFC4873] |
| 62 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 20 | [RFC3473] |
| 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC6107] |
| 26 | [RFC3473], [RFC4875] |
| 27 | [RFC3473], [RFC4875] |
| 28 | [RFC3945], [RFC3471], [RFC4202] |
| 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 30 | [RFC3945], [RFC3471], [RFC4202] |
| 31 | [RFC3945], [RFC3471], [RFC4202] |
| 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] |
| 33 | [RFC3473], [RFC4875] |
| 34 | [RFC4875] |
| 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 36 | [RFC3473], [RFC3209] (Make-before-break) |
| 37 | [RFC3473], [RFC3209] (Make-before-break) |
| 38 | [RFC4139], [RFC4258], [RFC5787] |
| 39 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 40 | [RFC3473], [RFC5063] |
| 41 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] |
| 42 | [RFC3945], [RFC3471], [RFC4202] |
| 43 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 44 | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 45 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 46 | [RFC5493] |
| 47 | [RFC4872], [RFC4873] |
| 48 | [RFC3945], [RFC3471], [RFC4202] |
| 49 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 50 | [RFC4872], [RFC4873] |
| 51 | [RFC4872], [RFC4873] + proper vendor implementation |
| 52 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 53 | [RFC4872], [RFC4873] |
| 54 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] |
| | Timers are a local implementation matter |
| 55 | [RFC4872], [RFC4873], [GMPLS-PS] + |
| | implementation of timers |
| 56 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 57 | [RFC4872], [RFC4873] |
| 58 | [RFC4872], [RFC4873] |
| 59 | [RFC4872], [RFC4873] |
| 60 | [RFC4872], [RFC4873], [RFC6107] |
| 61 | [RFC4872], [RFC4873] |
| 62 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 63 | [RFC4872], [RFC4873] |
| 64 | [RFC4872], [RFC4873] |
| 65 | [RFC4872], [RFC4873] |
| 66 | [RFC4872], [RFC4873], [RFC6107] |
| 67 | [RFC4872], [RFC4873] |
| 68 | [RFC3473], [RFC4872], [RFC4873] |
| 69 | [RFC3473] |
| 70 | [RFC3473], [RFC4872], [GMPLS-PS] |
| 71 | [RFC3473], [RFC4872] |
| 72 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 73 | [RFC4426], [RFC4872], [RFC4873] |
| 74 | [RFC4426], [RFC4872], [RFC4873] |
| 75 | [RFC4426], [RFC4872], [RFC4873] |
| 76 | [RFC4426], [RFC4872], [RFC4873] |
| 77 | [RFC4426], [RFC4872], [RFC4873] |
| 78 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation |
| 79 | [RFC4426], [RFC4872], [RFC4873] |
| 80 | [RFC4426], [RFC4872], [RFC4873] |
| 81 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 85 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 86 | [RFC4872], [RFC4873] |
| 87 | [RFC4872], [RFC4873] |
| 88 | [RFC4872], [RFC4873], [TP-RING] |
| 89 | [RFC4872], [RFC4873], [TP-RING] |
| 90 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 91 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 92 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] |
| 93 | Generic requirement on data plane (correct implementation)|
| 94 | [RFC3473], [NO-PHP] |
| 95 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 96 | PW only requirement; see PW Requirements Table (5.2) |
| 97 | PW only requirement; see PW Requirements Table (5.2) |
| 98 | [RFC3945], [RFC3473], [RFC6107] |
| 99 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + |
| | [RFC5392] and [RFC5316] |
| 100 | PW only requirement; see PW Requirements Table (5.2) |
| 101 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 102 | [RFC4872], [RFC4873], [TP-RING] |
| 103 | [RFC3945], [RFC3473], [RFC6107] |
| 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 105 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 106 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 109 | [RFC3473], [RFC4872], [RFC4873] |
| 63 | [RFC4872], [RFC4873] |
| 64 | [RFC4872], [RFC4873] |
| 65 | [RFC4872], [RFC4873] |
| 66 | [RFC4872], [RFC4873], [RFC6107] |
| 67 | [RFC4872], [RFC4873] |
| 68 | [RFC3473], [RFC4872], [RFC4873] |
| 69 | [RFC3473] |
| 70 | [RFC3473], [RFC4872], [GMPLS-PS] |
| 71 | [RFC3473], [RFC4872] |
| 72 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 73 | [RFC4426], [RFC4872], [RFC4873] |
| 74 | [RFC4426], [RFC4872], [RFC4873] |
| 75 | [RFC4426], [RFC4872], [RFC4873] |
| 76 | [RFC4426], [RFC4872], [RFC4873] |
| 77 | [RFC4426], [RFC4872], [RFC4873] |
| 78 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation |
| 79 | [RFC4426], [RFC4872], [RFC4873] |
| 80 | [RFC4426], [RFC4872], [RFC4873] |
| 81 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 85 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 86 | [RFC4872], [RFC4873] |
| 87 | [RFC4872], [RFC4873] |
| 88 | [RFC4872], [RFC4873], [TP-RING] |
| 89 | [RFC4872], [RFC4873], [TP-RING] |
| 90 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 91 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 92 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] |
| 93 | Generic requirement on data plane (correct implementation)|
| 94 | [RFC3473], [NO-PHP] |
| 95 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 96 | PW only requirement; see PW Requirements Table (5.2) |
| 97 | PW only requirement; see PW Requirements Table (5.2) |
| 98 | [RFC3945], [RFC3473], [RFC6107] |
| 99 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + |
| | [RFC5392] and [RFC5316] |
| 100 | PW only requirement; see PW Requirements Table (5.2) |
| 101 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 102 | [RFC4872], [RFC4873], [TP-RING] |
| 103 | [RFC3945], [RFC3473], [RFC6107] |
| 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 105 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 106 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 109 | [RFC3473], [RFC4872], [RFC4873] |
| 110 | [RFC3473], [RFC4872], [RFC4873] |
| 111 | [RFC3473], [RFC4783] |
| 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 115 | [RFC3473] |
| 116 | [RFC4426], [RFC4872], [RFC4873] |
| 117 | [RFC3473], [RFC4872], [RFC4873] |
| 118 | [RFC3473], [RFC4783] |
| 119 | [RFC3473] |
| 120 | [RFC3473], [RFC4783] |
| 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] |
| 124 - | |
| 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 136a | [RFC3473] |
| 136b | [RFC3473] + (See Sec. 4.4.7) |
| 137a | [RFC3473] |
| 137b | [RFC3473] + (See Sec. 4.4.7) |
| 138 | PW only requirement; see PW Requirements Table (5.2) |
| 139 - | |
| 143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) |
+=======+===========================================================+
| 110 | [RFC3473], [RFC4872], [RFC4873] |
| 111 | [RFC3473], [RFC4783] |
| 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 115 | [RFC3473] |
| 116 | [RFC4426], [RFC4872], [RFC4873] |
| 117 | [RFC3473], [RFC4872], [RFC4873] |
| 118 | [RFC3473], [RFC4783] |
| 119 | [RFC3473] |
| 120 | [RFC3473], [RFC4783] |
| 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] |
| 124 - | |
| 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 136a | [RFC3473] |
| 136b | [RFC3473] + (See Sec. 4.4.7) |
| 137a | [RFC3473] |
| 137b | [RFC3473] + (See Sec. 4.4.7) |
| 138 | PW only requirement; see PW Requirements Table (5.2) |
| 139 - | |
| 143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) |
+=======+===========================================================+
Table 1: GMPLS and MPLS-TP Requirements Table
表1:GMPLS和MPLS-TP要求表
This section identifies the extensions and other documents that have been identified as likely to be needed to support the full set of MPLS-TP control-plane requirements.
本节确定了支持全套MPLS-TP控制平面要求可能需要的扩展和其他文件。
While no interworking function is expected in the data plane to support the interconnection of MPLS-TE and MPLS-TP networking, this is not the case for the control plane. MPLS-TE networks typically use LSP signaling based on [RFC3209], while MPLS-TP LSPs will be signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies a set of solutions that are aimed to aid in the interworking of MPLS-TE and GMPLS control planes. [RFC5145] work will serve as the foundation for a formal definition of MPLS to MPLS-TP control-plane interworking.
虽然在数据平面中不需要任何互通功能来支持MPLS-TE和MPLS-TP网络的互连，但控制平面的情况并非如此。MPLS-TE网络通常使用基于[RFC3209]的LSP信令，而MPLS-TP LSP将使用GMPLS RSVP-TE（即[RFC3473]）信令。[RFC5145]确定了一组旨在帮助MPLS-TE和GMPLS控制平面互通的解决方案。[RCF5145]工作将作为MPLS到MPLS- TP控制平面互通的形式化定义的基础。
GMPLS signaling, [RFC3473], supports unidirectional and co-routed, bidirectional point-to-point LSPs. MPLS-TP also requires support for associated bidirectional point-to-point LSPs. Such support will require an extension or a formal definition of how the LSP end points supporting an associated bidirectional service will coordinate the two LSPs used to provide such a service. Per requirement 11, transit nodes that support an associated bidirectional service should be aware of the association of the LSPs used to support the service when both LSPs are supported on that transit node. There are several existing protocol mechanisms on which to base such support, including, but not limited to:
GMPLS信令[RFC3473]支持单向和共路由、双向点到点LSP。MPLS-TP还需要支持相关的双向点到点LSP。这种支持需要扩展或正式定义支持相关双向服务的LSP端点如何协调用于提供这种服务的两个LSP。根据要求11，当两个LSP都在传输节点上受支持时，支持相关双向服务的传输节点应了解用于支持服务的LSP的关联。有几种现有的协议机制可作为此类支持的基础，包括但不限于：
o GMPLS calls [RFC4974].
o GMPLS呼叫[RFC4974]。
o The ASSOCIATION object [RFC4872].
o 关联对象[RFC4872]。
o The LSP_TUNNEL_INTERFACE_ID object [RFC6107].
o LSP_隧道_接口_ID对象[RFC6107]。
[RFC5467] defines support for bidirectional LSPs that have different (asymmetric) bandwidth requirements for each direction. That RFC can be used to meet the related MPLS-TP technical requirement, but it is currently an Experimental RFC. To fully satisfy the MPLS-TP requirement, RFC 5467 will need to become a Standards Track RFC.
[RFC5467]定义了对双向LSP的支持，双向LSP对每个方向的带宽要求不同（不对称）。RFC可用于满足相关MPLS-TP技术要求，但目前它是一种实验性RFC。为了完全满足MPLS-TP要求，RFC 5467需要成为标准跟踪RFC。
The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and [RFC4873], do not explicitly cover their interactions. MPLS-TP requires a formal definition of recovery techniques for P2MP LSPs. Such a formal definition will be based on existing RFCs and may not require any new protocol mechanisms but, nonetheless, must be documented.
P2MP、[RFC4875]和GMPLS恢复、[RFC4872]和[RFC4873]的定义并未明确涵盖它们之间的相互作用。MPLS-TP要求对P2MP LSP的恢复技术进行正式定义。此类正式定义将基于现有的RFC，可能不需要任何新的协议机制，但必须记录在案。
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related control extensions to GMPLS. These extensions cover a portion of, but not all, OAM-related control functions that have been identified in the context of MPLS-TP. As discussed above, the MPLS-TP control plane must support the selection of which OAM function(s) (if any) to use (including support to select experimental OAM functions) and what OAM functionality to run, including Continuity Check (CC),
[CCAMP-OAM-FWK]和[CCAMP-OAM-EXT]是GMPLS的OAM相关控制扩展的示例。这些扩展包括在MPLS-TP上下文中识别的部分但不是全部与OAM相关的控制功能。如上所述，MPLS-TP控制平面必须支持选择要使用的OAM功能（如果有）（包括支持选择实验性OAM功能）以及要运行的OAM功能，包括连续性检查（CC），
Connectivity Verification (CV), packet loss, delay quantification, and diagnostic testing of a service. Such support may be included in the listed documents or in other documents.
服务的连接性验证（CV）、数据包丢失、延迟量化和诊断测试。此类支持可包含在所列文件或其他文件中。
[RFC3270] and [RFC4124] define support for Diffserv-enabled MPLS LSPs. While [RFC4124] references GMPLS signaling, there is no explicit discussion on the use of the Diffserv-related objects in GMPLS signaling. A (possibly Informational) document on how GMPLS supports Diffserv LSPs is likely to prove useful in the context of MPLS-TP.
[RFC3270]和[RFC4124]定义了对支持区分服务的MPLS LSP的支持。虽然[RFC4124]参考了GMPLS信令，但没有明确讨论在GMPLS信令中使用Diffserv相关对象。一份关于GMPLS如何支持区分服务LSP的（可能是信息性的）文档可能在MPLS-TP的上下文中被证明是有用的。
MPLS-TP uses two forms of LSP identifiers, see [RFC6370]. One form is based on existing GMPLS fields. The other form is based on either the globally unique Attachment Interface Identifier (AII) defined in [RFC5003] or the ITU Carrier Code (ICC) defined in ITU-T Recommendation M.1400. Neither form is currently supported in GMPLS, and such extensions will need to be documented.
MPLS-TP使用两种形式的LSP标识符，请参见[RFC6370]。一个表单基于现有的GMPLS字段。另一种形式基于[RFC5003]中定义的全球唯一附件接口标识符（AII）或ITU-T建议M.1400中定义的ITU载波代码（ICC）。GMPLS目前不支持这两种形式，并且需要记录此类扩展。
MPLS-TP defines several forms of maintenance-entity-related identifiers. Both node-unique and global forms are defined. Extensions will be required to GMPLS to support these identifiers. These extensions may be added to existing works in progress, such as [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent documents.
MPLS-TP定义了几种形式的维护实体相关标识符。定义了节点唯一形式和全局形式。GMPLS需要扩展以支持这些标识符。这些扩展可以添加到正在进行的现有工程中，如[CCAMP-OAM-FWK]和[CCAMP-OAM-EXT]，或者可以在独立文件中定义。
MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for emulated services over an MPLS Packet Switched Network (PSN). Several types of PWs have been defined: (1) Ethernet PWs providing for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2) High-Level Data Link Control (HDLC) / PPP PW providing for HDLC/PPP leased line transport over MPLS [RFC4618], (3) ATM PWs [RFC4816], (4) Frame Relay PWs [RFC4619], and (5) circuit Emulation PWs [RFC4553].
MPLS PWs在[RFC3985]和[RFC5659]中定义，并通过MPLS分组交换网络（PSN）提供模拟服务。定义了几种类型的PW：（1）通过MPLS[RFC4448]提供以太网端口或以太网VLAN传输的以太网PW，（2）通过MPLS[RFC4618]提供HDLC/PPP专线传输的高级数据链路控制（HDLC）/PPP PW，（3）ATM PWs[RFC4816]，（4）帧中继PWs[RFC4619]，以及（5）电路仿真PWs[RFC4553]。
Today's transport networks based on Plesiochronous Digital Hierarchy (PDH), WDM, or SONET/SDH provide transport for PDH or SONET (e.g., ATM over SONET or Packet PPP over SONET) client signals with no payload awareness. Implementing PW capability allows for the use of an existing technology to substitute the Time-Division Multiplexing
当今基于准同步数字体系（PDH）、WDM或SONET/SDH的传输网络为PDH或SONET（例如，SONET上的ATM或SONET上的分组PPP）客户端信号提供传输，而无需有效负载感知。实现PW能力允许使用现有技术来替代时分复用
(TDM) transport with packet-based transport, using well-defined PW encapsulation methods for carrying various packet services over MPLS, and providing for potentially better bandwidth utilization.
（TDM）使用基于分组的传输，使用定义良好的PW封装方法通过MPLS承载各种分组服务，并提供潜在更好的带宽利用率。
There are two general classes of PWs: (1) Single-Segment Pseudowires (SS-PWs) [RFC3985] and (2) Multi-segment Pseudowires (MS-PWs) [RFC5659]. An MPLS-TP network domain may transparently transport a PW whose end points are within a client network. Alternatively, an MPLS-TP edge node may be the Terminating PE (T-PE) for a PW, performing adaptation from the native attachment circuit technology (e.g., Ethernet 802.1Q) to an MPLS PW that is then transported in an LSP over an MPLS-TP network. In this way, the PW is analogous to a transport channel in a TDM network, and the LSP is equivalent to a container of multiple non-concatenated channels, albeit they are packet containers. An MPLS-TP network may also contain Switching PEs (S-PEs) for a Multi-Segment PW whereby the T-PEs may be at the edge of an MPLS-TP network or in a client network. In the latter case, a T-PE in a client network performs the adaptation of the native service to MPLS and the MPLS-TP network performs pseudowire switching.
PWs有两大类：（1）单段伪线（SS PWs）[RFC3985]和（2）多段伪线（MS PWs）[RFC5659]。MPLS-TP网络域可以透明地传输其端点在客户端网络内的PW。或者，MPLS-TP边缘节点可以是用于PW的终端PE（T-PE），执行从本机连接电路技术（例如，以太网802.1Q）到MPLS PW的适配，然后通过MPLS-TP网络在LSP中传输该MPLS PW。这样，PW类似于TDM网络中的传输信道，并且LSP等效于多个非级联信道的容器，尽管它们是分组容器。MPLS-TP网络还可包含用于多段PW的交换PE（S-PE），其中T-PE可位于MPLS-TP网络的边缘或客户端网络中。在后一种情况下，客户端网络中的T-PE执行本机服务到MPLS的适配，并且MPLS-TP网络执行伪线交换。
The SS-PW signaling control plane is based on targeted LDP (T-LDP) with specific procedures defined in [RFC4447]. The MS-PW signaling control plane is also based on T-LDP as allowed for in [RFC5659], [RFC6073], and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the same PW signaling protocols and procedures for placing SS-PWs and MS-PWs. This will leverage existing technology as well as facilitate interoperability with client networks with native attachment circuits or PW segments that are switched across an MPLS-TP network.
SS-PW信令控制平面基于目标LDP（T-LDP），具体程序见[RFC4447]。MS-PW信令控制平面也基于[RFC5659]、[RFC6073]和[MS-PW-DYNAMIC]中允许的T-LDP。MPLS-TP网络应使用相同的PW信令协议和程序来放置SS PW和MS PW。这将利用现有技术，并促进与具有本机连接电路或PW段的客户端网络的互操作性，这些本机连接电路或PW段通过MPLS-TP网络交换。
There is no MPLS-TP requirement for a standardized management interface to the MPLS-TP control plane. A general overview of MPLS-TP-related MIB modules can be found in [TP-MIB]. Network management requirements for MPLS-based transport networks are provided in [RFC5951].
对于MPLS-TP控制平面的标准化管理接口，不存在MPLS-TP要求。有关MPLS TP相关MIB模块的概述，请参见[TP-MIB]。[RFC5951]中提供了基于MPLS的传输网络的网络管理要求。
The following table shows how the MPLS-TP control-plane requirements can be met using the existing LDP control plane for pseudowires (targeted LDP). Areas where additional specifications are required are also identified. The table lists references based on the control-plane requirements as identified and numbered above in Section 2.
下表显示了如何使用用于伪线（目标LDP）的现有LDP控制平面来满足MPLS-TP控制平面要求。还确定了需要附加规范的区域。该表列出了基于控制平面要求的参考，如上文第2节所述。
In the table below, several of the requirements shown are addressed -- in part or in full -- by the use of MPLS-TP LSPs to carry pseudowires. This is reflected by including "TP-LSPs" as a reference for those requirements. Section 5.3.2 provides additional context for the binding of PWs to TP-LSPs.
在下表中，通过使用MPLS-TP LSP来承载伪线，部分或全部满足了所示的若干要求。包括“TP LSP”作为这些要求的参考，反映了这一点。第5.3.2节提供了PWs与TP LSP绑定的附加上下文。
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) |
| 3 | [RFC3985], [RFC4447] |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3985], [RFC4447], Together with TP-LSPs |
| 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs |
| 7 | [RFC3985], [RFC4447], + TP-LSPs |
| 8 | [PW-P2MPR], [PW-P2MPE] |
| 9 | [RFC3985], end-node only involvement for PW |
| 10 | [RFC3985], proper vendor implementation |
| 11 | [RFC3985], end-node only involvement for PW |
| 12-13 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 14 | [RFC3985], [RFC4447] |
| 15 | [RFC4447], [RFC3478], proper vendor implementation |
| 16 | [RFC3985], [RFC4447] |
| 17-18 | [RFC3985], proper vendor implementation |
| 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation |
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] |
| | [RFC4842], [RFC5287] |
| 28 | [RFC3985] |
| 29-31 | [RFC3985], [RFC4447] |
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6 |
| 33 | [RFC4385], [RFC4447], [RFC5586] |
| 34 | [PW-P2MPR], [PW-P2MPE] |
| 35 | [RFC4863] |
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 38 | Provided by TP-LSPs |
| 39 | [RFC3985], [RFC4447], + TP-LSPs |
| 40 | [RFC3478] |
| 41-42 | [RFC3985], [RFC4447] |
| 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 |
| 45 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs |
| 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 |
| 47 | [PW-RED], [PW-REDB] |
| 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 50-52 | Provided by TP-LSPs, and Section 5.3.5 |
| 53-55 | [RFC3985], [RFC4447], See Section 5.3.5 |
| 56 | [PW-RED], [PW-REDB] |
| | revertive/non-revertive behavior is a local matter for PW |
| 57-58 | [PW-RED], [PW-REDB] |
| 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 82-83 | [RFC5085], [RFC5586], [RFC5885] |
| 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 96 | [RFC4447], [MS-PW-DYNAMIC] |
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) |
| 3 | [RFC3985], [RFC4447] |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3985], [RFC4447], Together with TP-LSPs |
| 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs |
| 7 | [RFC3985], [RFC4447], + TP-LSPs |
| 8 | [PW-P2MPR], [PW-P2MPE] |
| 9 | [RFC3985], end-node only involvement for PW |
| 10 | [RFC3985], proper vendor implementation |
| 11 | [RFC3985], end-node only involvement for PW |
| 12-13 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 14 | [RFC3985], [RFC4447] |
| 15 | [RFC4447], [RFC3478], proper vendor implementation |
| 16 | [RFC3985], [RFC4447] |
| 17-18 | [RFC3985], proper vendor implementation |
| 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation |
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] |
| | [RFC4842], [RFC5287] |
| 28 | [RFC3985] |
| 29-31 | [RFC3985], [RFC4447] |
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6 |
| 33 | [RFC4385], [RFC4447], [RFC5586] |
| 34 | [PW-P2MPR], [PW-P2MPE] |
| 35 | [RFC4863] |
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 38 | Provided by TP-LSPs |
| 39 | [RFC3985], [RFC4447], + TP-LSPs |
| 40 | [RFC3478] |
| 41-42 | [RFC3985], [RFC4447] |
| 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 |
| 45 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs |
| 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 |
| 47 | [PW-RED], [PW-REDB] |
| 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 50-52 | Provided by TP-LSPs, and Section 5.3.5 |
| 53-55 | [RFC3985], [RFC4447], See Section 5.3.5 |
| 56 | [PW-RED], [PW-REDB] |
| | revertive/non-revertive behavior is a local matter for PW |
| 57-58 | [PW-RED], [PW-REDB] |
| 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 82-83 | [RFC5085], [RFC5586], [RFC5885] |
| 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 96 | [RFC4447], [MS-PW-DYNAMIC] |
| 97 | [RFC4447] |
| 98 - | |
| 99 | Not Applicable to PW |
| 100 | [RFC4447] |
| 101 | [RFC3478] |
| 102 | [RFC3985], + TP-LSPs |
| 103 | Not Applicable to PW |
| 104 | [PW-OAM] |
| 105 | [PW-OAM] |
| 106 - | |
| 108 | [RFC5085], [RFC5586], [RFC5885] |
| 109 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 110 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 111 | [RFC4447] |
| 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] |
| 113 | [RFC5085], [RFC5586], [RFC5885] |
| 114 | [RFC5085], [RFC5586], [RFC5885] |
| 115 | path traversed by PW is determined by LSP path; see |
| | GMPLS and MPLS-TP Requirements Table, Section 4.3 |
| 116 | [PW-RED], [PW-REDB], administrative control of redundant |
| | PW is a local matter at the PW head-end |
| 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] |
| 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 119 | [RFC4447] |
| 120 - | |
| 125 | [RFC5085], [RFC5586], [RFC5885] |
| 126 - | |
| 130 | [PW-OAM] |
| 131 | Section 5.3.5 |
| 132 | [PW-OAM] |
| 133 | [PW-OAM] |
| 134 | Section 5.3.5 |
| 135 | [PW-OAM] |
| 136 | Not Applicable to PW |
| 137 | Not Applicable to PW |
| 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] |
| 139 - | |
| 143 | [PW-OAM] |
+=======+===========================================================+
| 97 | [RFC4447] |
| 98 - | |
| 99 | Not Applicable to PW |
| 100 | [RFC4447] |
| 101 | [RFC3478] |
| 102 | [RFC3985], + TP-LSPs |
| 103 | Not Applicable to PW |
| 104 | [PW-OAM] |
| 105 | [PW-OAM] |
| 106 - | |
| 108 | [RFC5085], [RFC5586], [RFC5885] |
| 109 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 110 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 111 | [RFC4447] |
| 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] |
| 113 | [RFC5085], [RFC5586], [RFC5885] |
| 114 | [RFC5085], [RFC5586], [RFC5885] |
| 115 | path traversed by PW is determined by LSP path; see |
| | GMPLS and MPLS-TP Requirements Table, Section 4.3 |
| 116 | [PW-RED], [PW-REDB], administrative control of redundant |
| | PW is a local matter at the PW head-end |
| 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] |
| 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 119 | [RFC4447] |
| 120 - | |
| 125 | [RFC5085], [RFC5586], [RFC5885] |
| 126 - | |
| 130 | [PW-OAM] |
| 131 | Section 5.3.5 |
| 132 | [PW-OAM] |
| 133 | [PW-OAM] |
| 134 | Section 5.3.5 |
| 135 | [PW-OAM] |
| 136 | Not Applicable to PW |
| 137 | Not Applicable to PW |
| 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] |
| 139 - | |
| 143 | [PW-OAM] |
+=======+===========================================================+
Table 2: PW Control (LDP) and MPLS-TP Requirements Table
表2:PW控制（LDP）和MPLS-TP要求表
Existing control protocol and procedures will be reused as much as possible to support MPLS-TP. However, when using PWs in MPLS-TP, a set of new requirements is defined that may require extensions of the existing control mechanisms. This section clarifies the areas where extensions are needed based on the requirements that are related to the PW control plane and documented in [RFC5654].
现有的控制协议和程序将尽可能重复使用，以支持MPLS-TP。然而，当在MPLS-TP中使用PWs时，定义了一组可能需要扩展现有控制机制的新需求。本节根据与PW控制平面相关并记录在[RFC5654]中的要求，澄清了需要扩展的区域。
Table 2 lists how requirements defined in [RFC5654] are expected to be addressed.
表2列出了如何满足[RFC5654]中定义的要求。
The baseline requirement for extensions to support transport applications is that any new mechanisms and capabilities must be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate. Hence, extensions of the PW control plane must be in-line with the procedures defined in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].
支持传输应用的扩展的基线要求是，任何新的机制和能力必须能够与现有的IETF MPLS[RFC3031]和IETF PWE3[RFC3985]控制和数据平面（如适用）进行互操作。因此，PW控制平面的扩展必须符合[RFC4447]、[RFC6073]和[MS-PW-DYNAMIC]中定义的程序。
For MPLS-TP, it is required that the data and control planes can be both logically and physically separated. That is, the PW control plane must be able to operate out-of-band (OOB). This separation ensures, among other things, that in the case of control-plane failures the data plane is not affected and can continue to operate normally. This was not a design requirement for the current PW control plane. However, due to the PW concept, i.e., PWs are connecting logical entities ('forwarders'), and the operation of the PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part in the signaling exchanges: moving T-LDP out-of-band seems to be, theoretically, a straightforward exercise.
对于MPLS-TP，要求数据和控制平面在逻辑和物理上都可以分离。也就是说，PW控制平面必须能够在带外（OOB）运行。除其他外，这种分离确保在控制平面故障的情况下，数据平面不受影响，并且可以继续正常运行。这不是当前PW控制平面的设计要求。然而，由于PW概念，即PW连接逻辑实体（“转发器”），以及PW控制协议的操作，即只有边缘PE节点（T-PE，S-PE）参与信令交换：从理论上讲，将T-LDP移出频带似乎是一个简单的练习。
In fact, as a strictly local matter, ensuring that targeted LDP (T-LDP) uses out-of-band signaling requires only that the local implementation is configured in such a way that reachability for a target LSR address is via the out-of-band channel.
事实上，作为严格的本地事项，确保目标LDP（T-LDP）使用带外信令只需要本地实现以这样的方式配置，即目标LSR地址的可达性是通过带外信道的。
More precisely, if IP addressing is used in the MPLS-TP control plane, then T-LDP addressing can be maintained, although all addresses will refer to control-plane entities. Both the PWid Forwarding Equivalence Class (FEC) and Generalized PWid FEC Elements can possibly be used in an OOB case as well. (Detailed evaluation is outside the scope of this document.) The PW label allocation and exchange mechanisms should be reused without change.
更准确地说，如果在MPLS-TP控制平面中使用IP寻址，则可以保持T-LDP寻址，尽管所有地址都将引用控制平面实体。PWid转发等价类（FEC）和广义PWid FEC元素也可能用于OOB情况。（详细评估不在本文件范围内。）PW标签分配和交换机制应重复使用，不得更改。
Binding a PW to an LSP, or PW segments to LSPs, is left to nodes acting as T-PEs and S-PEs or a control-plane entity that may be the same one signaling the PW. However, an extension of the PW signaling protocol is required to allow the LSR at the signal initiation end to inform the targeted LSR (at the signal termination end) to which LSP the resulting PW is to be bound, in the event that more than one such LSP exists and the choice of LSPs is important to the service being setup (for example, if the service requires co-routed bidirectional paths). This is also particularly important to support transport path (symmetric and asymmetric) bandwidth requirements.
将PW绑定到LSP，或将PW段绑定到LSP，留给充当T-PEs和S-PEs的节点，或者可能是同一个向PW发送信号的控制平面实体。然而，如果存在多个这样的LSP并且LSP的选择对于正在设置的服务很重要，则需要PW信令协议的扩展以允许信号起始端的LSR通知（信号终止端的）目标LSR，所产生的PW将绑定到哪个LSP（例如，如果服务需要共同路由的双向路径）。这对于支持传输路径（对称和非对称）带宽要求也特别重要。
For transport services, MPLS-TP requires support for bidirectional traffic that follows congruent paths. Currently, each direction of a PW or a PW segment is bound to a unidirectional LSP that extends between two T-PEs, two S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in both directions are not required to follow congruent paths, and therefore both directions of a PW may not follow congruent paths, i.e., they are associated bidirectional paths. The only requirement in [RFC5659] is that a PW or a PW segment shares the same T-PEs in both directions and the same S-PEs in both directions.
对于传输服务，MPLS-TP需要支持遵循一致路径的双向流量。目前，PW或PW段的每个方向都绑定到在两个T-PE、两个S-PE或一个T-PE和一个S-PE之间延伸的单向LSP。两个方向上的单向lsp不需要遵循一致路径，因此PW的两个方向可能不遵循一致路径，即，它们是相关联的双向路径。[RFC5659]中的唯一要求是PW或PW段在两个方向上共享相同的T-PE，在两个方向上共享相同的S-PE。
MPLS-TP imposes new requirements on the PW control plane, in requiring that both end points map the PW or PW segment to the same transport path for the case where this is an objective of the service. When a bidirectional LSP is selected on one end to transport the PW, a mechanism is needed that signals to the remote end which LSP has been selected locally to transport the PW. This would be accomplished by adding a new TLV to PW signaling.
MPLS-TP对PW控制平面提出了新的要求，要求两个端点将PW或PW段映射到相同的传输路径，以实现服务的目标。当在一端选择双向LSP来传输PW时，需要一种机制，向远程端发送信号，表明本地选择了哪个LSP来传输PW。这将通过向PW信令添加新的TLV来实现。
Note that this coincides with the gap identified for OOB support: a new mechanism is needed to allow explicit binding of a PW to the supporting transport LSP.
注意，这与为OOB支持确定的差距是一致的：需要一种新的机制来允许PW与支持传输LSP的显式绑定。
The case of unidirectional transport paths may also require additional protocol mechanisms, as today's PWs are always bidirectional. One potential approach for providing a unidirectional PW-based transport path is for the PW to associate different (asymmetric) bandwidths in each direction, with a zero or minimal bandwidth for the return path. This approach is consistent with Section 3.8.2 of [RFC5921] but does not address P2MP paths.
单向传输路径的情况也可能需要额外的协议机制，因为今天的PW总是双向的。提供基于单向PW的传输路径的一种潜在方法是，PW将每个方向上的不同（不对称）带宽与返回路径的零或最小带宽相关联。该方法与[RFC5921]第3.8.2节一致，但不涉及P2MP路径。
In order to satisfy requirement 47 (as defined in Section 2), it will be necessary to specify methods for transfer of PW ownership from the management to the control plane (and vice versa).
为了满足要求47（如第2节所定义），有必要规定将PW所有权从管理层转移到控制层的方法（反之亦然）。
Transport applications may require resource guarantees. For such transport LSPs, resource reservation mechanisms are provided via RSVP-TE and the use of Diffserv. If multiple PWs are multiplexed into the same transport LSP resources, contention may occur. However, local policy at PEs should ensure proper resource sharing among PWs mapped into a resource-guaranteed LSP. In the case of MS-PWs, signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable admission control of a PW segment over a resource-guaranteed LSP.
传输应用程序可能需要资源保证。对于这种传输LSP，通过RSVP-TE和Diffserv的使用提供资源预留机制。如果多个PW被多路复用到相同的传输LSP资源中，则可能发生争用。然而，PEs的本地政策应确保映射到资源保证LSP的PW之间的适当资源共享。在MS-PWs的情况下，信令携带PW业务参数[MS-PW-DYNAMIC]，以便能够通过资源保证LSP对PW段进行接纳控制。
In conjunction with explicit PW-to-LSP binding, existing mechanisms may be sufficient; however, this needs to be verified in detailed evaluation.
结合明确的PW到LSP绑定，现有机制可能就足够了；然而，这需要在详细的评估中加以验证。
Many of the requirements listed in Section 2 are intended to support connectivity and performance monitoring (grouped together as OAM), as well as protection conformant with the transport services model.
第2节中列出的许多要求旨在支持连接性和性能监控（组合为OAM），以及符合传输服务模型的保护。
In general, protection of MPLS-TP transported services is provided by way of protection of transport LSPs. PW protection requires that mechanisms be defined to support redundant pseudowires, including a mechanism already described above for associating such pseudowires with specific protected ("working" and "protection") LSPs. Also required are definitions of local protection control functions, to include test/verification operations, and protection status signals needed to ensure that PW termination points are in agreement as to which of a set of redundant pseudowires are in use for which transport services at any given point in time.
通常，通过保护传输LSP来提供MPLS-TP传输服务的保护。PW保护要求定义支持冗余伪线的机制，包括上文已描述的用于将此类伪线与特定受保护（“工作”和“保护”）LSP关联的机制。还需要定义本地保护控制功能，包括测试/验证操作和保护状态信号，以确保PW终端点与在任何给定时间点使用的传输服务的一组冗余伪线一致。
Much of this work is currently being done in documents [PW-RED] and [PW-REDB] that define, respectively, how to establish redundant pseudowires and how to indicate which is in use. Additional work may be required.
这方面的大部分工作目前正在[PW-RED]和[PW-REDB]文件中完成，这两个文件分别定义了如何建立冗余伪线以及如何指示正在使用的伪线。可能需要额外的工作。
Protection switching may be triggered manually by the operator, or as a result of loss of connectivity (detected using the mechanisms of [RFC5085] and [RFC5586]), or service degradation (detected using mechanisms yet to be defined).
保护切换可由操作员手动触发，或由于连接丢失（使用[RFC5085]和[RFC5586]的机制检测）或服务降级（使用尚未定义的机制检测）而触发。
Automated protection switching is just one of the functions for which a transport service requires OAM. OAM is generally referred to as either "proactive" or "on-demand", where the distinction is whether a specific OAM tool is being used continuously over time (for the purpose of detecting a need for protection switching, for example) or
自动保护交换只是传输服务需要OAM的功能之一。OAM通常被称为“主动”或“按需”，区别在于特定的OAM工具是否在一段时间内持续使用（例如，为了检测保护切换的需要），或者
is only used -- either a limited number of times or over a short period of time -- when explicitly enabled (for diagnostics, for example).
仅在显式启用（例如，对于诊断）时使用（次数有限或时间较短）。
PW OAM currently consists of connectivity verification defined by [RFC5085]. Work is currently in progress to extend PW OAM to include bidirectional forwarding detection (BFD) in [RFC5885], and work has begun on extending BFD to include performance-related monitor functions.
PW OAM目前由[RFC5085]定义的连接验证组成。目前正在进行扩展PW OAM的工作，以在[RFC5885]中包括双向转发检测（BFD），并已开始扩展BFD，以包括性能相关的监控功能。
Additional work is likely to be required to define consistent access by a client-layer network, as well as between provider networks, to control information available to each type of network, for example, about the topology of an MS-PW. This information may be required by the client-layer network in order to provide hints that may help to avoid establishment of fate-sharing alternate paths. Such work will need to fit within the ASON architecture; see requirement 38 above.
可能需要额外的工作来定义客户端层网络以及提供商网络之间的一致访问，以控制每种类型网络可用的信息，例如关于MS-PW拓扑的信息。客户端层网络可能需要该信息，以便提供可能有助于避免建立命运共享备用路径的提示。此类工作需要符合ASON架构；见上文要求38。
MPLS-TP PWs are always transported using LSPs, and these LSPs will either have been statically provisioned or signaled using GMPLS.
MPLS-TP PW始终使用LSP传输，并且这些LSP将使用GMPLS进行静态配置或发信号。
For LSPs signaled using the MPLS-TP LSP control plane (GMPLS), conformance with the ASON architecture is as described in Section 1.2 ("Basic Approach"), bullet 4, of this framework document.
对于使用MPLS-TP LSP控制平面（GMPLS）发送信号的LSP，与ASON架构的一致性如本框架文件第1.2节（“基本方法”）项目符号4所述。
As discussed above in Section 5.3, there are anticipated extensions in the following areas that may be related to ASON architecture:
如上文第5.3节所述，在以下可能与ASON体系结构相关的领域中有预期的扩展：
- PW-to-LSP binding (Section 5.3.2) - PW/LSP resource allocation (Section 5.3.4) - PW protection and OAM configuration (Section 5.3.5) - Client-layer interfaces for PW control (Section 5.3.6)
- PW到LSP绑定（第5.3.2节）-PW/LSP资源分配（第5.3.4节）-PW保护和OAM配置（第5.3.5节）-PW控制的客户端层接口（第5.3.6节）
This work is expected to be consistent with ASON architecture and may require additional specification in order to achieve this goal.
这项工作预计将与ASON架构保持一致，并且可能需要额外的规范来实现这一目标。
This document primarily describes how existing mechanisms can be used to meet the MPLS-TP control-plane requirements. The documents that describe each mechanism contain their own security considerations sections. For a general discussion on MPLS- and GMPLS-related
本文档主要描述如何使用现有机制来满足MPLS-TP控制平面要求。描述每种机制的文档都包含各自的安全注意事项部分。有关MPLS和GMPLS的一般性讨论
security issues, see the MPLS/GMPLS security framework [RFC5920]. As mentioned above in Section 2.4, there are no specific MPLS-TP control-plane security requirements.
安全问题，请参阅MPLS/GMPLS安全框架[RFC5920]。如上文第2.4节所述，没有具体的MPLS-TP控制平面安全要求。
This document also identifies a number of needed control-plane extensions. It is expected that the documents that define such extensions will also include any appropriate security considerations.
本文件还确定了许多需要的控制平面扩展。预计定义此类扩展的文件还将包括任何适当的安全考虑。
The authors would like to acknowledge the contributions of Yannick Brehon, Diego Caviglia, Nic Neate, Dave Mcdysan, Dan Frost, and Eric Osborne to this work. We also thank Dan Frost in his help responding to Last Call comments.
作者要感谢Yannick Brehon、Diego Caviglia、Nic Neate、Dave Mcdysan、Dan Frost和Eric Osborne对这项工作的贡献。我们还感谢Dan Frost在回复上次通话评论时提供的帮助。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211]Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478]Leelanivas，M.，Rekhter，Y.，和R.Aggarwal，“标签分发协议的优雅重启机制”，RFC 3478，2003年2月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，RFC 41242005年6月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[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月。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, April 2007.
[RFC4842]Malis，A.，Pate，P.，Cohen，R.，Ed.，和D.Zelig，“同步光网络/同步数字体系（SONET/SDH）分组电路仿真（CEP）”，RFC 4842，2007年4月。
[RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", RFC 4863, May 2007.
[RFC4863]Martini，L.和G.Swallow，“通配符伪线类型”，RFC 4863，2007年5月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929]Andersson，L.，Ed.，和A.Farrel，Ed.“多协议标签交换（MPLS）和通用MPLS（GMPLS）协议和程序的变更过程”，BCP 129，RFC 49292007年6月。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
[RFC4974]Papadimitriou，D.和A.Farrel，“支持呼叫的通用MPLS（GMPLS）RSVP-TE信令扩展”，RFC 4974，2007年8月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063]Satyanarayana，A.，Ed.，和R.Rahman，Ed.，“GMPLS资源预留协议（RSVP）优雅重启的扩展”，RFC 5063，2007年10月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151]Farrel，A.，Ed.，Ayyangar，A.，和JP。Vasseur，“域间MPLS和GMPLS流量工程——资源预留协议流量工程（RSVP-TE）扩展”，RFC 51512008年2月。
[RFC5287] Vainshtein, A. and Y(J). Stein, "Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks", RFC 5287, August 2008.
[RFC5287]Vainstein，A.和Y（J）。Stein，“MPLS网络中时分复用（TDM）伪线设置的控制协议扩展”，RFC 5287，2008年8月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008.
[RFC5316]Chen，M.，Zhang，R.，和X.Duan，“支持自治系统（AS）MPLS和GMPLS流量工程的ISIS扩展”，RFC 5316，2008年12月。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009.
[RFC5392]Chen，M.，Zhang，R.，和X.Duan，“支持跨自治系统（AS）MPLS和GMPLS流量工程的OSPF扩展”，RFC 5392，2009年1月。
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009.
[RFC5467]Berger，L.，Takacs，A.，Caviglia，D.，Fedyk，D.，和J.Meuria，“GMPLS非对称带宽双向标签交换路径（LSP）”，RFC 54672009年3月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860]Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 58602010年5月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960]Frost，D.，Ed.，Bryant，S.，Ed.，和M.Bocci，Ed.，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371]Busi，I.，Ed.和D.Allan，Ed.“基于MPLS的传输网络的操作、管理和维护框架”，RFC 63712011年9月。
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[RFC6372]Sprecher，N.，Ed.，和A.Farrel，Ed.，“MPLS传输配置文件（MPLS-TP）生存能力框架”，RFC 6372，2011年9月。
[CCAMP-OAM-EXT] Bellagamba, E., Ed., Andersson, L., Ed., Skoldstrom, P., Ed., Ward, D., and A. Takacs, "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE", Work in Progress, July 2011.
[CCAMP-OAM-EXT]Bellagamba，E.，Ed.，Andersson，L.，Ed.，Skoldstrom，P.，Ed.，Ward，D.，和A.Takacs，“使用RSVP-TE为基于MPLS的传输网络配置主动操作、管理和维护（OAM）功能”，在建工程，2011年7月。
[CCAMP-OAM-FWK] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE extensions for OAM Configuration", Work in Progress, July 2011.
[CCAMP-OAM-FWK]Takacs，A.，Fedyk，D.，和J.He，“OAM配置的GMPLS RSVP-TE扩展”，正在进行的工作，2011年7月。
[GMPLS-PS] Takacs, A., Fondelli, F., and B. Tremblay, "GMPLS RSVP-TE Recovery Extension for data plane initiated reversion and protection timer signalling", Work in Progress, April 2011.
[GMPLS-PS]Takacs，A.，Fondelli，F.和B.Tremblay，“数据平面启动的恢复和保护定时器信令的GMPLS RSVP-TE恢复扩展”，正在进行的工作，2011年4月。
[ITU.G8080.2006] International Telecommunication Union, "Architecture for the automatically switched optical network (ASON)", ITU-T Recommendation G.8080, June 2006.
[ITU.G8080.2006]国际电信联盟，“自动交换光网络（ASON）架构”，ITU-T建议G.8080，2006年6月。
[ITU.G8080.2008] International Telecommunication Union, "Architecture for the automatically switched optical network (ASON) Amendment 1", ITU-T Recommendation G.8080 Amendment 1, March 2008.
[ITU.G8080.2008]国际电信联盟，“自动交换光网络（ASON）体系结构修正案1”，ITU-T建议G.8080修正案1，2008年3月。
[MS-PW-DYNAMIC] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., "Dynamic Placement of Multi Segment Pseudowires", Work in Progress, July 2011.
[MS-PW-DYNAMIC]Martini，L.，Ed.，Bocci，M.，Ed.，和F.Balus，Ed.，“多段伪导线的动态放置”，正在进行的工作，2011年7月。
[NO-PHP] Ali, z., et al, "Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths", Work in Progress, August 2011.
[NO-PHP]Ali，z.等人，“RSVP-TE标签交换路径的非倒数第二跳弹出行为和带外映射”，正在进行的工作，2011年8月。
[PW-OAM] Zhang, F., Ed., Wu, B., Ed., and E. Bellagamba, Ed., " Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire", Work in Progress, August 2011.
[PW-OAM]Zhang，F.，Ed.，Wu，B.，Ed.，和E.Bellagamba，Ed.，“用于动态MPLS传输配置文件伪线的主动操作、管理和维护配置的标签分发协议扩展”，正在进行的工作，2011年8月。
[PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint Pseudo-Wire Encapsulation", Work in Progress, March 2010.
[PW-P2MPE]Aggarwal，R.和F.Jounay，“点对多点伪线封装”，正在进行的工作，2010年3月。
[PW-P2MPR] Jounay, F., Ed., Kamite, Y., Heron, G., and M. Bocci, "Requirements and Framework for Point-to-Multipoint Pseudowire", Work in Progress, July 2011.
[PW-P2MPR]Jounay，F.，Ed.，Kamite，Y.，Heron，G.，和M.Bocci，“点对多点伪线的要求和框架”，正在进行的工作，2011年7月。
[PW-RED] Muley, P., Ed., Aissaoui, M., Ed., and M. Bocci, "Pseudowire Redundancy", Work in Progress, July 2011.
[PW-RED]Muley，P.，Ed.，Aissaoui，M.，Ed.，和M.Bocci，“伪线冗余”，在建工程，2011年7月。
[PW-REDB] Muley, P., Ed., and M. Aissaoui, Ed., "Preferential Forwarding Status Bit", Work in Progress, March 2011.
[PW-REDB]Muley，P.，Ed.，和M.Aissaoui，Ed.，“优先转发状态比特”，正在进行的工作，2011年3月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.
[RFC3468]Andersson，L.和G.Swallow，“多协议标签交换（MPLS）工作组关于MPLS信令协议的决定”，RFC 3468，2003年2月。
[RFC3472] Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472]Ashwood Smith，P.，Ed.，和L.Berger，Ed.，“基于广义多协议标签交换（GMPLS）信令约束的路由标签分发协议（CR-LDP）扩展”，RFC 3472，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）标签交换路由器（LSR）管理信息库（MIB）”，RFC 38132004年6月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005.
[RFC4139]Papadimitriou，D.，Drake，J.，Ash，J.，Farrel，A.，和L.Ong，“自动交换光网络（ASON）的通用MPLS（GMPLS）信令使用和扩展要求”，RFC 4139，2005年7月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，2005年10月。
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258]Brungard，D.，Ed.“自动交换光网络（ASON）的通用多协议标签交换（GMPLS）路由要求”，RFC 4258，2005年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.
[RFC4426]Lang，J.，Ed.，Rajagopalan，B.，Ed.，和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）恢复功能规范”，RFC 4426，2006年3月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553]Vainstein，A.，Ed.，和YJ。Stein，Ed.“数据包上的结构不可知时分复用（TDM）（SAToP）”，RFC4553，2006年6月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618]Martini，L.，Rosen，E.，Heron，G.，和A.Malis，“通过MPLS网络传输PPP/高级数据链路控制（HDLC）的封装方法”，RFC 4618，2006年9月。
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619]Martini，L.，Ed.，Kawa，C.，Ed.，和A.Malis，Ed.，“多协议标签交换（MPLS）网络上帧中继传输的封装方法”，RFC 4619，2006年9月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783]Berger，L.，Ed.“GMPLS-报警信息的通信”，RFC 4783，2006年12月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802]Nadeau，T.，Ed.，和A.Farrel，Ed.，“通用多协议标签交换（GMPLS）流量工程管理信息库”，RFC 4802，2007年2月。
[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007.
[RFC4803]Nadeau，T.，Ed.，和A.Farrel，Ed.，“通用多协议标签交换（GMPLS）标签交换路由器（LSR）管理信息库”，RFC 4803，2007年2月。
[RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service", RFC 4816, February 2007.
[RFC4816]Malis，A.，Martini，L.，Brayley，J.，和T.Walsh，“伪线仿真边到边（PWE3）异步传输模式（ATM）透明信元传输服务”，RFC 4816，2007年2月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[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月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008.
[RFC5145]Shiomoto，K.，Ed.“MPLS-TE到GMPLS迁移的框架”，RFC 51452008年3月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009.
[RFC5493]Caviglia，D.，Bramanti，D.，Li，D.，和D.McDysan，“通用多协议标签交换（GMPLS）网络中永久连接和交换连接之间转换的要求”，RFC 5493，2009年4月。
[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月。
[RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing", RFC 5787, March 2010.
[RFC5787]Papadimitriou，D.，“自动交换光网络（ASON）路由的OSPFv2路由协议扩展”，RFC 5787，2010年3月。
[RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. Bardalai, "RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network", RFC 5852, April 2010.
[RFC5852]Caviglia，D.，Ceccarelli，D.，Bramanti，D.，Li，D.，和S.Bardalai，“在启用GMPLS的传输网络中，用于LSP从管理平面切换到控制平面的RSVP-TE信令扩展”，RFC 5852，2010年4月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC5885] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“用于伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 58852010年6月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010.
[RFC5951]Lam，K.，Mansfield，S.，和E.Gray，“基于MPLS的传输网络的网络管理要求”，RFC 59512010年9月。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC6001]Papadimitriou，D.，Vigoureux，M.，Shiomoto，K.，Brungard，D.，和JL。Le Roux，“多层和多区域网络（MLN/MRN）的通用MPLS（GMPLS）协议扩展”，RFC 60012010年。
[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月。
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011.
[RFC6107]Shiomoto，K.，Ed.，和A.Farrel，Ed.“动态信号分层标签交换路径的程序”，RFC 61072011年2月。
[RFC6215] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile User-to-Network and Network-to-Network Interfaces", RFC 6215, April 2011.
[RFC6215]Bocci，M.，Levrau，L.，和D.Frost，“MPLS传输配置文件用户到网络和网络到网络接口”，RFC 62152011年4月。
[TE-MIB] Miyazawa, M., Otani, T., Kumaki, K., and T. Nadeau, "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Work in Progress, July 2011.
[TE-MIB]Miyazawa，M.，Otani，T.，Kumaki，K.，和T.Nadeau，“支持MPLS-TE/GMPLS的交通工程数据库管理信息库”，正在进行的工作，2011年7月。
[TP-MIB] King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview", Work in Progress, August 2011.
[TP-MIB]King，D.，Ed.，和M.Venkatesan，Ed.，“多协议标签交换传输配置文件（MPLS-TP）基于MIB的管理概述”，正在进行的工作，2011年8月。
[TP-P2MP-FWK] Frost, D., Ed., Bocci, M., Ed., and L. Berger, Ed., "A Framework for Point-to-Multipoint MPLS in Transport Networks", Work in Progress, July 2011.
[TP-P2MP-FWK]Frost，D.，Bocci，M.，Ed.，和L.Berger，Ed.，“传输网络中点对多点MPLS的框架”，正在进行的工作，2011年7月。
[TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", Work in Progress, June 2011
[TP-RING]Weingarten，Y.，编辑，“MPLS-TP环保护”，正在进行的工作，2011年6月
Attila Takacs Ericsson 1. Laborc u. Budapest 1037 HUNGARY EMail: attila.takacs@ericsson.com
阿提拉·塔卡茨·爱立信1号。劳工大学。布达佩斯1037匈牙利电子邮件：attila。takacs@ericsson.com
Martin Vigoureux Alcatel-Lucent EMail: martin.vigoureux@alcatel-lucent.fr
Martin Vigoureux Alcatel-Lucent电子邮件：Martin。vigoureux@alcatel-朗讯
Elisa Bellagamba Ericsson Farogatan, 6 164 40, Kista, Stockholm SWEDEN EMail: elisa.bellagamba@ericsson.com
Elisa Bellagamba Ericsson Farogatan，6164 40，瑞典斯德哥尔摩Kista电子邮件：Elisa。bellagamba@ericsson.com
Authors' Addresses
作者地址
Loa Andersson (editor) Ericsson Phone: +46 10 717 52 13 EMail: loa.andersson@ericsson.com
Loa Andersson（编辑）爱立信电话：+46 10 717 52 13电子邮件：Loa。andersson@ericsson.com
Lou Berger (editor) LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger（编辑）LabN Consulting，L.L.C.电话：+1-301-468-9228电子邮件：lberger@labn.net
Luyuan Fang (editor) Cisco Systems, Inc. 111 Wood Avenue South Iselin, NJ 08830 USA EMail: lufang@cisco.com
方陆元（编辑）思科系统有限公司，地址：美国新泽西州伊塞林南伍德大道111号，邮编：08830电子邮件：lufang@cisco.com
Nabil Bitar (editor) Verizon 60 Sylvan Road Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
Nabil Bitar（编辑）Verizon 60 Sylvan Road Waltham，马萨诸塞州02451美国电子邮件：Nabil.n。bitar@verizon.com
Eric Gray (editor) Ericsson 900 Chelmsford Street Lowell, MA 01851 USA Phone: +1 978 275 7470 EMail: Eric.Gray@Ericsson.com
Eric Gray（编辑）爱立信900 Chelmsford Street Lowell，马萨诸塞州01851美国电话：+1 978 275 7470电子邮件：Eric。Gray@Ericsson.com