Internet Engineering Task Force (IETF) M. Bocci, Ed.
Request for Comments: 5921 Alcatel-Lucent
Category: Informational S. Bryant, Ed.
ISSN: 2070-1721 D. Frost, Ed.
Cisco Systems
L. Levrau
Alcatel-Lucent
L. Berger
LabN
July 2010
Internet Engineering Task Force (IETF) M. Bocci, Ed.
Request for Comments: 5921 Alcatel-Lucent
Category: Informational S. Bryant, Ed.
ISSN: 2070-1721 D. Frost, Ed.
Cisco Systems
L. Levrau
Alcatel-Lucent
L. Berger
LabN
July 2010
A Framework for MPLS in Transport Networks
一种传输网络中的MPLS框架
Abstract
摘要
This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.
本文件规定了多协议标签交换（MPLS）应用于分组交换传输网络建设的体系结构框架。它描述了一组常见的协议功能——MPLS传输配置文件（MPLS-TP）——支持此类网络的典型操作模型和功能，包括信号或显式提供的双向连接导向路径、保护和恢复机制、综合操作、管理、，和维护（OAM）功能，以及在没有动态控制平面或IP转发支持的情况下的网络操作。其中一些功能在现有MPLS规范中定义，而其他功能则需要对现有规范进行扩展以满足MPLS-TP的要求。
This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.
本文档定义了通常适用于点到点传输路径的MPLS-TP子集。其余子集，特别适用于点对多点传输路径，不在本文档范围内。
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/rfc5921.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5921.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 7
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 10
1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 10
1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10
1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10
1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10
1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11
1.3.13. Additional Definitions and Terminology . . . . . . . . 11
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16
3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16
3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17
3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18
3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25
3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33
3.7. Operations, Administration, and Maintenance (OAM) . . . . 36
3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 38
3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 39
3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39
3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 40
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 40
3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40
3.10. Inter-Domain Connectivity . . . . . . . . . . . . . . . . 43
3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 43
3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 44
3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 45
3.14. Network Management . . . . . . . . . . . . . . . . . . . . 47
4. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 7
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 10
1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 10
1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10
1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10
1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10
1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11
1.3.13. Additional Definitions and Terminology . . . . . . . . 11
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16
3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16
3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17
3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18
3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25
3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33
3.7. Operations, Administration, and Maintenance (OAM) . . . . 36
3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 38
3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 39
3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39
3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 40
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 40
3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40
3.10. Inter-Domain Connectivity . . . . . . . . . . . . . . . . 43
3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 43
3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 44
3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 45
3.14. Network Management . . . . . . . . . . . . . . . . . . . . 47
4. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . . 51
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . . 51
This document describes an architectural framework for the application of MPLS to the construction of packet-switched transport networks. It specifies the common set of protocol functions that meet the requirements in [RFC5654], and that together constitute the MPLS Transport Profile (MPLS-TP) for point-to-point transport paths. The remaining MPLS-TP functions, applicable specifically to point-to-multipoint transport paths, are outside the scope of this document.
本文档描述了MPLS应用于分组交换传输网络构建的体系结构框架。它规定了满足[RFC5654]要求的通用协议功能集，这些功能共同构成点到点传输路径的MPLS传输配置文件（MPLS-TP）。其余的MPLS-TP功能，特别适用于点对多点传输路径，不在本文档的范围内。
Historically, the optical transport infrastructure -- Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) -- has provided carriers with a high benchmark for reliability and operational simplicity. To achieve this, transport technologies have been designed with specific characteristics:
从历史上看，光传输基础设施——同步光网络/同步数字体系（SONET/SDH）和光传输网络（OTN）——为运营商提供了可靠性和操作简单性的高基准。为实现这一目标，运输技术的设计具有以下特点：
o Strictly connection-oriented connectivity, which may be long-lived and may be provisioned manually, for example, by network management systems or direct node configuration using a command line interface.
o 严格面向连接的连接，可以是长期的，并且可以通过网络管理系统或使用命令行界面的直接节点配置等方式手动配置。
o A high level of availability.
o 高水平的可用性。
o Quality of service.
o 服务质量。
o Extensive Operations, Administration, and Maintenance (OAM) capabilities.
o 广泛的操作、管理和维护（OAM）能力。
Carriers wish to evolve such transport networks to take advantage of the flexibility and cost benefits of packet switching technology and to support packet-based services more efficiently. While MPLS is a maturing packet technology that already plays an important role in transport networks and services, not all MPLS capabilities and mechanisms are needed in, or consistent with, the transport network operational model. There are also transport technology characteristics that are not currently reflected in MPLS.
运营商希望发展这样的传输网络，以利用分组交换技术的灵活性和成本优势，并更有效地支持基于分组的服务。虽然MPLS是一种成熟的分组技术，已经在传输网络和服务中发挥了重要作用，但并非所有的MPLS功能和机制都需要在传输网络运营模型中，或与之一致。还有一些传输技术特性目前没有反映在MPLS中。
There are thus two objectives for MPLS-TP:
因此，MPLS-TP有两个目标：
1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies.
1. 使MPLS能够部署在传输网络中，并以与现有传输技术类似的方式运行。
2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks.
2. 使MPLS能够以与现有传输网络中类似程度的可预测性支持分组传输服务。
In order to achieve these objectives, there is a need to define a common set of MPLS protocol functions -- an MPLS Transport Profile -- for the use of MPLS in transport networks and applications. Some of the necessary functions are provided by existing MPLS specifications, while others require additions to the MPLS tool-set. Such additions should, wherever possible, be applicable to MPLS networks in general as well as those that conform strictly to the transport network model.
为了实现这些目标，需要定义一组通用的MPLS协议功能（MPLS传输配置文件），以便在传输网络和应用程序中使用MPLS。现有MPLS规范提供了一些必要的功能，而其他功能则需要添加到MPLS工具集。在可能的情况下，此类添加应适用于一般MPLS网络以及严格符合传输网络模型的网络。
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 PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
本文件是联合互联网工程任务组（IETF）/国际电信联盟电信标准化部门（ITU-T）的产品努力在IETF MPLS和PWE3体系结构中包括MPLS传输配置文件，以支持ITU-T定义的分组传输网络的能力和功能。
This document describes an architectural framework for the application of MPLS to the construction of packet-switched transport networks. It specifies the common set of protocol functions that meet the requirements in [RFC5654], and that together constitute the MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport paths. The remaining MPLS-TP functions, applicable specifically to point-to-multipoint transport paths, are outside the scope of this document.
本文档描述了MPLS应用于分组交换传输网络构建的体系结构框架。它规定了满足[RFC5654]要求的一组通用协议功能，这些功能共同构成了点到点MPLS-TP传输路径的MPLS传输配置文件（MPLS-TP）。其余的MPLS-TP功能，特别适用于点对多点传输路径，不在本文档的范围内。
Term Definition
---------- ----------------------------------------------------------
AC Attachment Circuit
ACH Associated Channel Header
Adaptation The mapping of client information into a format suitable
for transport by the server layer
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
CE Customer Edge
Term Definition
---------- ----------------------------------------------------------
AC Attachment Circuit
ACH Associated Channel Header
Adaptation The mapping of client information into a format suitable
for transport by the server layer
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
CE Customer Edge
CL-PS Connectionless - Packet Switched CM Configuration Management CO-CS Connection Oriented - Circuit Switched CO-PS Connection Oriented - Packet Switched DCN Data Communication Network EMF Equipment Management Function FCAPS Fault, Configuration, Accounting, Performance, and Security FM Fault Management G-ACh Generic Associated Channel GAL G-ACh Label LER Label Edge Router LSP Label Switched Path LSR Label Switching Router MAC Media Access Control MCC Management Communication Channel ME Maintenance Entity MEG Maintenance Entity Group MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate Point MPLS Multiprotocol Label Switching MPLS-TP MPLS Transport Profile MPLS-TP P MPLS-TP Provider LSR MPLS-TP PE MPLS-TP Provider Edge LSR MS-PW Multi-Segment Pseudowire Native The traffic belonging to the client of the MPLS-TP network Service OAM Operations, Administration, and Maintenance (see [OAM-DEF]) OSI Open Systems Interconnection OTN Optical Transport Network PDU Protocol Data Unit PM Performance Monitoring PSN Packet Switching Network PW Pseudowire SCC Signaling Communication Channel SDH Synchronous Digital Hierarchy S-PE PW Switching Provider Edge SPME Sub-Path Maintenance Element SS-PW Single-Segment Pseudowire T-PE PW Terminating Provider Edge TE LSP Traffic Engineered Label Switched Path VCCV Virtual Circuit Connectivity Verification
CL-PS无连接-分组交换CM配置管理面向CO-CS连接-电路交换面向CO-PS连接-分组交换DCN数据通信网络EMF设备管理功能FCAPS故障、配置、计费、性能、，和安全FM故障管理G-ACh通用关联通道GAL G-ACh标签LER标签边缘路由器LSP标签交换路径LSR标签交换路由器MAC介质访问控制MCC管理通信通道ME维护实体MEG维护实体组MEP维护实体组端点MIP维护实体组中间点MPLS多协议标签交换MPLS-TP MPLS传输配置文件MPLS-TP MPLS-TP提供程序LSR MPLS-TP PE MPLS-TP提供程序边缘LSR MS-PW多段伪线本机属于MPLS-TP网络服务OAM操作、管理和维护客户端的通信量（请参阅[OAM-DEF]）OSI开放系统互连OTN光传输网络PDU协议数据单元PM性能监测PSN分组交换网络PW伪线SCC信令通信信道SDH同步数字体系S-PE PW交换提供商边缘SPME子路径维护元件SS-PW单段伪线T-PE PW端接提供商边缘TE LSP流量工程标签交换路径VCCV虚拟电路连接验证
A Transport Network provides transparent transmission of user traffic between attached client devices by establishing and maintaining point-to-point or point-to-multipoint connections between such devices. The architecture of networks supporting point-to-multipoint connections is outside the scope of this document. A Transport Network is independent of any higher-layer network that may exist between clients, except to the extent required to supply this transmission service. In addition to client traffic, a Transport Network may carry traffic to facilitate its own operation, such as that required to support connection control, network management, and Operations, Administration, and Maintenance (OAM) functions.
传输网络通过在连接的客户端设备之间建立和维护点对点或点对多点连接来提供用户通信量的透明传输。支持点对多点连接的网络体系结构不在本文档范围内。传输网络独立于客户端之间可能存在的任何更高层网络，但提供此传输服务所需的范围除外。除了客户端流量之外，传输网络还可以承载流量以促进其自身的操作，例如支持连接控制、网络管理以及操作、管理和维护（OAM）功能所需的流量。
See also the definition of packet transport service in Section 3.1.
另见第3.1节中分组传输服务的定义。
The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions that meet the requirements in [RFC5654]. Note that MPLS is defined to include any present and future MPLS capability specified by the IETF, including those capabilities specifically added to support transport network requirements [RFC5654].
MPLS传输配置文件（MPLS-TP）是满足[RFC5654]要求的MPLS功能的子集。注意，MPLS被定义为包括IETF规定的任何当前和未来的MPLS能力，包括专门为支持传输网络需求而添加的那些能力[RFC5654]。
MPLS-TP sections are defined in [DATA-PLANE]. See also the definition of "section layer network" in Section 1.2.2 of [RFC5654].
MPLS-TP部分在[DATA-PLANE]中定义。另请参见[RFC5654]第1.2.2节中“截面层网络”的定义。
An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a subset of the capabilities of an MPLS LSP in order to meet the requirements of an MPLS transport network as set out in [RFC5654]. The characteristics of an MPLS-TP LSP are primarily that it:
MPLS-TP标签交换路径（MPLS-TP LSP）是使用MPLS LSP功能子集的LSP，以满足[RFC5654]中规定的MPLS传输网络的要求。MPLS-TP LSP的特点主要是：
1. Uses a subset of the MPLS OAM tools defined in [OAM-FRAMEWORK].
1. 使用[OAM-FRAMEWORK]中定义的MPLS OAM工具的子集。
2. Supports 1+1, 1:1, and 1:N protection functions.
2. 支持1+1、1:1和1:N保护功能。
3. Is traffic engineered.
3. 是交通工程。
4. May be established and maintained via the management plane, or using GMPLS protocols when a control plane is used.
4. 可通过管理平面建立和维护，或在使用控制平面时使用GMPLS协议。
5. Is either point-to-point or point-to-multipoint. Multipoint-to-point and multipoint-to-multipoint LSPs are not supported.
5. 是点对点或点对多点。不支持多点对点和多点对多点LSP。
6. It is either unidirectional, associated bidirectional, or co-routed bidirectional (i.e., the forward and reverse components of a bidirectional LSP follow the same path, and the intermediate nodes are aware of their association). These are further defined in [DATA-PLANE].
6. 它是单向的、相关联的双向的或共同路由的双向的（即，双向LSP的正向和反向组件遵循相同的路径，并且中间节点知道它们的关联）。这些在[数据平面]中有进一步的定义。
Note that an MPLS LSP is defined to include any present and future MPLS capability, including those specifically added to support the transport network requirements.
注意，MPLS LSP被定义为包括任何当前和未来的MPLS能力，包括那些专门添加以支持传输网络需求的能力。
See [DATA-PLANE] for further details on the types and data-plane properties of MPLS-TP LSPs.
有关MPLS-TP LSP的类型和数据平面属性的更多详细信息，请参阅[数据平面]。
The lowest server layer provided by MPLS-TP is an MPLS-TP LSP. The client layers of an MPLS-TP LSP may be network-layer protocols, MPLS LSPs, or PWs. The relationship of an MPLS-TP LSP to its client layers is described in detail in Section 3.4.
MPLS-TP提供的最低服务器层是MPLS-TP LSP。MPLS-TP LSP的客户端层可以是网络层协议、MPLS LSP或PWs。第3.4节详细描述了MPLS-TP LSP与其客户端层的关系。
An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP, as defined below. The terms MPLS-TP PE router and MPLS-TP P router describe logical functions; a specific node may undertake only one of these roles on a given LSP.
MPLS-TP标签交换路由器（LSR）是给定LSP的MPLS-TP提供商边缘（PE）路由器或MPLS-TP提供商（P）路由器，定义如下。术语MPLS-TP PE路由器和MPLS-TP路由器描述逻辑功能；特定节点在给定LSP上只能承担其中一个角色。
Note that the use of the term "router" in this context is historic and neither requires nor precludes the ability to perform IP forwarding.
请注意，在此上下文中使用术语“路由器”是历史性的，既不要求也不排除执行IP转发的能力。
An MPLS-TP Label Edge Router (LER) is an LSR that exists at the endpoints of an LSP and therefore pushes or pops the LSP label, i.e., does not perform a label swap on the particular LSP under consideration.
MPLS-TP标签边缘路由器（LER）是存在于LSP端点处的LSR，因此推送或弹出LSP标签，即不在所考虑的特定LSP上执行标签交换。
An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts client traffic and encapsulates it to be transported over an MPLS-TP LSP. Encapsulation may be as simple as pushing a label, or it may require the use of a pseudowire. An MPLS-TP PE exists at the interface between a pair of layer networks. For an MS-PW, an MPLS-TP PE may be either an S-PE or a T-PE, as defined in [RFC5659] (see below). A PE that pushes or pops an LSP label is an LER for that LSP.
MPLS-TP提供商边缘（PE）路由器是一种MPLS-TP LSR，它适应客户端流量并将其封装以通过MPLS-TP LSP传输。封装可能像推标签一样简单，也可能需要使用假导线。MPLS-TP PE存在于一对层网络之间的接口处。对于MS-PW，MPLS-TP PE可以是[RFC5659]中定义的S-PE或T-PE（见下文）。推动或弹出LSP标签的PE是该LSP的LER。
The term Provider Edge refers to the node's role within a provider's network. A provider edge router resides at the edge of a given MPLS-TP network domain, in which case it has links to another MPLS-TP network domain or to a CE, except for the case of a pseudowire switching provider edge (S-PE) router, which is not restricted to the edge of an MPLS-TP network domain.
术语提供者边缘是指节点在提供者网络中的角色。提供商边缘路由器位于给定MPLS-TP网络域的边缘，在这种情况下，它具有到另一个MPLS-TP网络域或到CE的链接，但伪线交换提供商边缘（S-PE）路由器除外，该路由器不限于MPLS-TP网络域的边缘。
An MPLS-TP Provider router is an MPLS-TP LSR that does not provide MPLS-TP PE functionality for a given LSP. An MPLS-TP P router switches LSPs that carry client traffic, but does not adapt client traffic and encapsulate it to be carried over an MPLS-TP LSP. The term Provider Router refers to the node's role within a provider's network. A provider router does not have links to other MPLS-TP network domains.
MPLS-TP提供程序路由器是不为给定LSP提供MPLS-TP PE功能的MPLS-TP LSR。MPLS-TP路由器交换承载客户端流量的LSP，但不调整客户端流量并将其封装为通过MPLS-TP LSP承载。术语提供者路由器指的是节点在提供者网络中的角色。提供商路由器没有到其他MPLS-TP网络域的链接。
RFC 5659 [RFC5659] defines an S-PE as:
RFC 5659[RFC5659]将S-PE定义为：
A PE capable of switching the control and data planes of the preceding and succeeding PW segments in an MS-PW. The S-PE terminates the PSN tunnels of the preceding and succeeding segments of the MS-PW. It therefore includes a PW switching point for an MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to set up and manage PW segments with other PW switching points and terminating PEs. An S-PE can exist anywhere a PW must be processed or policy applied. It is therefore not limited to the edge of a provider network.
一种能够在MS-PW中切换前一个PW段和后一个PW段的控制平面和数据平面的PE。S-PE终止MS-PW之前和后续段的PSN隧道。因此，它包括MS-PW的PW开关点。PW切换点绝不是同一MS-PW的S-PE和T-PE。PW交换点运行必要的协议，以设置和管理与其他PW交换点和终端PE的PW段。S-PE可以存在于必须处理PW或应用策略的任何位置。因此，它不限于提供商网络的边缘。
Note that it was originally anticipated that S-PEs would only be deployed at the edge of a provider network where they would be used to switch the PWs of different service providers. However, as the design of MS-PW progressed, other applications for MS-PW were recognized. By this time S-PE had become the accepted term for the equipment, even though they were no longer universally deployed at the provider edge.
请注意，最初预计S-PEs将仅部署在提供商网络的边缘，用于切换不同服务提供商的PWs。然而，随着MS-PW设计的进展，MS-PW的其他应用也得到了认可。此时，S-PE已成为设备的公认术语，尽管它们不再普遍部署在提供商边缘。
RFC 5659 [RFC5659] defines a T-PE as:
RFC 5659[RFC5659]将T-PE定义为：
A PE where the customer-facing attachment circuits (ACs) are bound to a PW forwarder. A terminating PE is present in the first and last segments of an MS-PW. This incorporates the functionality of a PE as defined in RFC 3985.
一种PE，其中面向客户的连接电路（ACs）绑定到PW转发器。终端PE出现在MS-PW的第一段和最后一段中。这包括RFC 3985中定义的PE功能。
A Customer Edge (CE) is the client function that sources or sinks native service traffic to or from the MPLS-TP network. CEs on either side of the MPLS-TP network are peers and view the MPLS-TP network as a single link.
客户边缘（CE）是向MPLS-TP网络发送或接收本机服务流量的客户端功能。MPLS-TP网络两侧的CE是对等方，将MPLS-TP网络视为单个链路。
A Transport LSP is an LSP between a pair of PEs that may transit zero or more MPLS-TP provider routers. When carrying PWs, the Transport LSP is equivalent to the PSN tunnel LSP in [RFC3985] terminology.
传输LSP是一对PE之间的LSP，可传输零个或多个MPLS-TP提供商路由器。当携带PWs时，传输LSP相当于[RFC3985]术语中的PSN隧道LSP。
A service LSP is an LSP that carries a single client service.
服务LSP是承载单个客户端服务的LSP。
A layer network is defined in [G.805] and described in [RFC5654]. A layer network provides for the transfer of client information and independent operation of the client OAM. A layer network may be described in a service context as follows: one layer network may provide a (transport) service to a higher client layer network and may, in turn, be a client to a lower-layer network. A layer network is a logical construction somewhat independent of arrangement or composition of physical network elements. A particular physical network element may topologically belong to more than one layer network, depending on the actions it takes on the encapsulation associated with the logical layers (e.g., the label stack), and thus could be modeled as multiple logical elements. A layer network may consist of one or more sublayers.
层网络在[G.805]中定义，并在[RFC5654]中描述。层网络提供客户端信息的传输和客户端OAM的独立操作。层网络可以在服务上下文中描述如下：一层网络可以向更高的客户端层网络提供（传输）服务，并且反过来可以是低层网络的客户端。层网络是一种逻辑结构，在某种程度上独立于物理网络元素的排列或组成。一个特定的物理网络元素可能在拓扑上属于一个以上的层网络，这取决于它对与逻辑层（例如，标签堆栈）相关联的封装所采取的行动，因此可以建模为多个逻辑元素。层网络可以由一个或多个子层组成。
This document uses the term Network Layer in the same sense as it is used in [RFC3031] and [RFC3032]. Network-layer protocols are synonymous with those belonging to Layer 3 of the Open System Interconnect (OSI) network model [X.200].
本文件使用术语网络层的含义与[RFC3031]和[RFC3032]中使用的含义相同。网络层协议与属于开放系统互连（OSI）网络模型第3层的协议同义[X.200]。
The packet transport service provided by MPLS-TP is provided at a service interface. Two types of service interfaces are defined:
MPLS-TP提供的分组传输服务在服务接口处提供。定义了两种类型的服务接口：
o User-Network Interface (UNI) (see Section 3.4.3.1).
o 用户网络接口（UNI）（见第3.4.3.1节）。
o Network-Network Interface (NNI) (see Section 3.4.3.2).
o 网络接口（NNI）（见第3.4.3.2节）。
A UNI service interface may be a Layer 2 interface that carries only network layer clients. MPLS-TP LSPs are both necessary and sufficient to support this service interface as described in Section 3.4.3. Alternatively, it may be a Layer 2 interface that carries both network-layer and non-network-layer clients. To support this service interface, a PW is required to adapt the client traffic received over the service interface. This PW in turn is a client of the MPLS-TP server layer. This is described in Section 3.4.2.
UNI服务接口可以是仅承载网络层客户端的第2层接口。如第3.4.3节所述，MPLS-TP LSP对于支持该服务接口是必要的，并且是足够的。或者，它可以是承载网络层和非网络层客户端的第2层接口。为了支持此服务接口，需要一个PW来调整通过服务接口接收的客户端通信量。该PW又是MPLS-TP服务器层的客户机。第3.4.2节对此进行了说明。
An NNI service interface may be to an MPLS LSP or a PW. To support this case, an MPLS-TP PE participates in the service interface signaling.
NNI服务接口可以是MPLS LSP或PW。为了支持这种情况，MPLS-TP PE参与服务接口信令。
The native service is the client layer network service that is transported by the MPLS-TP network, whether a pseudowire or an LSP is used for the adaptation (see Section 3.4).
本机服务是由MPLS-TP网络传输的客户端层网络服务，无论适配使用的是伪线还是LSP（参见第3.4节）。
Detailed definitions and additional terminology may be found in [RFC5654] and [ROSETTA-STONE].
详细定义和附加术语可参见[RFC5654]和[ROSETTA-STONE]。
The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], and [NM-REQ]. This section provides a brief reminder to guide the reader. It is not normative or intended as a substitute for these documents.
[RFC5654]、[RFC5860]和[NM-REQ]中规定了MPLS-TP的要求。本节提供了一个简短的提示，以指导读者。它不是规范性文件，也不是这些文件的替代品。
MPLS-TP must not modify the MPLS forwarding architecture and must be based on existing pseudowire and LSP constructs.
MPLS-TP不得修改MPLS转发体系结构，必须基于现有的伪线和LSP结构。
Point-to-point LSPs may be unidirectional or bidirectional, and it must be possible to construct congruent bidirectional LSPs.
点对点LSP可以是单向的或双向的，并且必须能够构造全等的双向LSP。
MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it must be possible to detect if a merged LSP has been created.
MPLS-TP LSP不会在MPLS-TP LSR处与其他LSP合并，并且必须能够检测是否已创建合并的LSP。
It must be possible to forward packets solely based on switching the MPLS or PW label. It must also be possible to establish and maintain LSPs and/or pseudowires both in the absence or presence of a dynamic control plane. When static provisioning is used, there must be no dependency on dynamic routing or signaling.
必须能够仅基于交换MPLS或PW标签转发数据包。还必须能够在没有或存在动态控制平面的情况下建立和维护LSP和/或伪线。当使用静态资源调配时，必须不依赖于动态路由或信令。
OAM and protection mechanisms, and forwarding of data packets, must be able to operate without IP forwarding support.
OAM和保护机制以及数据包的转发必须能够在没有IP转发支持的情况下运行。
It must be possible to monitor LSPs and pseudowires through the use of OAM in the absence of control-plane or routing functions. In this case, information gained from the OAM functions is used to initiate path recovery actions at either the PW or LSP layers.
在没有控制平面或路由功能的情况下，必须能够通过使用OAM来监控LSP和伪线。在这种情况下，从OAM功能获得的信息用于在PW或LSP层启动路径恢复操作。
One objective of MPLS-TP is to enable MPLS networks to provide packet transport services with a similar degree of predictability to that found in existing transport networks. Such packet transport services exhibit a number of characteristics, defined in [RFC5654]:
MPLS-TP的一个目标是使MPLS网络能够提供与现有传输网络中类似程度的可预测性的分组传输服务。此类分组传输服务具有[RFC5654]中定义的许多特征：
o 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 operation of the MPLS-TP layer network must be possible without any dependencies on either the server or client layer network.
o 在MPLS-TP层网络支持客户端层网络，且MPLS-TP层网络由服务器层网络支持的环境中，MPLS-TP层网络的运行必须能够在不依赖于服务器或客户端层网络的情况下进行。
o The service provided by the MPLS-TP network to a given client will not fall below the agreed level as a result of the traffic loading of other clients.
o MPLS-TP网络向给定客户机提供的服务不会由于其他客户机的流量负载而低于约定的水平。
o The control and management planes of any client network layer that uses the service is isolated from the control and management planes of the MPLS-TP layer network, where the client network layer is considered to be the native service of the MPLS-TP network.
o 使用该服务的任何客户端网络层的控制和管理平面与MPLS-TP层网络的控制和管理平面隔离，其中客户端网络层被视为MPLS-TP网络的本机服务。
o Where a client network makes use of an MPLS-TP server that provides a packet transport service, the level of coordination required between the client and server layer networks is minimal (preferably no coordination will be required).
o 在客户机网络使用提供分组传输服务的MPLS-TP服务器的情况下，客户机和服务器层网络之间所需的协调级别是最小的（优选地，不需要协调）。
o The complete set of packets generated by a client MPLS(-TP) layer network using the packet transport service, which may contain packets that are not MPLS packets (e.g., IP or CLNS (Connectionless Network Service) packets used by the control/ management plane of the client MPLS(-TP) layer network), are transported by the MPLS-TP server layer network.
o 客户端MPLS（-TP）层网络使用数据包传输服务生成的完整数据包集，其中可能包含不是MPLS数据包的数据包（例如，客户端MPLS（-TP）层网络的控制/管理平面使用的IP或CLN（无连接网络服务）数据包），通过MPLS-TP服务器层网络传输。
o The packet transport service enables the MPLS-TP layer network addressing and other information (e.g., topology) to be hidden from any client layer networks using that service, and vice-versa.
o 分组传输服务使得MPLS-TP层网络寻址和其他信息（例如，拓扑）能够从使用该服务的任何客户端层网络隐藏，反之亦然。
These characteristics imply that a packet transport service does not support a connectionless packet-switched forwarding mode. However, this does not preclude it carrying client traffic associated with a connectionless service.
这些特征意味着分组传输服务不支持无连接分组交换转发模式。但是，这并不排除它承载与无连接服务相关联的客户端流量。
Figure 1 illustrates the scope of MPLS-TP. MPLS-TP solutions are primarily intended for packet transport applications. MPLS-TP is a strict subset of MPLS, and comprises only those functions that are necessary to meet the requirements of [RFC5654]. This includes MPLS functions that were defined prior to [RFC5654] but that meet the requirements of [RFC5654], together with additional functions defined to meet those requirements. Some MPLS functions defined before [RFC5654] such as Equal Cost Multi-Path (ECMP), LDP signaling when used in such a way that it creates multipoint-to-point LSPs, and IP forwarding in the data plane are explicitly excluded from MPLS-TP by that requirements specification.
图1说明了MPLS-TP的范围。MPLS-TP解决方案主要用于分组传输应用。MPLS-TP是MPLS的严格子集，仅包含满足[RFC5654]要求所需的功能。这包括[RFC5654]之前定义但满足[RFC5654]要求的MPLS功能，以及为满足这些要求而定义的其他功能。在[RFC5654]之前定义的一些MPLS功能，如等成本多径（ECMP）、LDP信令（当以创建多点对点LSP的方式使用时）以及数据平面中的IP转发，根据该需求规范明确从MPLS-TP中排除。
Note that MPLS as a whole will continue to evolve to include additional functions that do not conform to the MPLS Transport Profile or its requirements, and thus fall outside the scope of MPLS-TP.
请注意，MPLS作为一个整体将继续发展，以包括不符合MPLS传输配置文件或其要求的附加功能，因此不属于MPLS-TP的范围。
|<============================== MPLS ==============================>|
{ Post-RFC5654 }
{ non-Transport }
{ Functions }
|<========== Pre-RFC5654 MPLS ===========>|
{ ECMP }
{ LDP/non-TE LSPs }
{ IP forwarding }
|<============================== MPLS ==============================>|
{ Post-RFC5654 }
{ non-Transport }
{ Functions }
|<========== Pre-RFC5654 MPLS ===========>|
{ ECMP }
{ LDP/non-TE LSPs }
{ IP forwarding }
|<======== MPLS-TP ============>|
{ Additional }
{ Transport }
{ Functions }
|<======== MPLS-TP ============>|
{ Additional }
{ Transport }
{ Functions }
Figure 1: Scope of MPLS-TP
图1:MPLS-TP的范围
MPLS-TP can be used to construct packet networks and is therefore applicable in any packet network context. A subset of MPLS-TP is also applicable to ITU-T-defined packet transport networks, where the transport network operational model is deemed attractive.
MPLS-TP可用于构建分组网络，因此适用于任何分组网络环境。MPLS-TP的一个子集也适用于ITU-T定义的分组传输网络，其中传输网络操作模型被认为是有吸引力的。
MPLS-TP comprises the following architectural elements:
MPLS-TP包含以下体系结构元素：
o A standard MPLS data plane [RFC3031] as profiled in [DATA-PLANE].
o [data-plane]中描述的标准MPLS数据平面[RFC3031]。
o Sections, LSPs, and PWs that provide a packet transport service for a client network.
o 为客户端网络提供数据包传输服务的部分、LSP和PW。
o Proactive and on-demand Operations, Administration, and Maintenance (OAM) functions to monitor and diagnose the MPLS-TP network, as outlined in [OAM-FRAMEWORK].
o 主动式和按需操作、管理和维护（OAM）功能，用于监控和诊断MPLS-TP网络，如[OAM-FRAMEWORK]中所述。
o Control planes for LSPs and PWs, as well as support for static provisioning and configuration, as outlined in [CP-FRAMEWORK].
o LSP和PWs的控制平面，以及对静态资源调配和配置的支持，如[CP-FRAMEWORK]所述。
o Path protection mechanisms to ensure that the packet transport service survives anticipated failures and degradations of the MPLS-TP network, as outlined in [SURVIVE-FWK].
o 路径保护机制，以确保分组传输服务在MPLS-TP网络的预期故障和降级中生存，如[SURVIVE-FWK]所述。
o Control-plane-based restoration mechanisms, as outlined in [SURVIVE-FWK].
o 基于控制平面的恢复机制，如[SURVIVE-FWK]所述。
o Network management functions, as outlined in [NM-FRAMEWORK].
o 网络管理功能，如[NM-FRAMEWORK]所述。
The MPLS-TP architecture for LSPs and PWs includes the following two sets of functions:
LSP和PWs的MPLS-TP体系结构包括以下两组功能：
o MPLS-TP native service adaptation
o MPLS-TP本机服务适配
o MPLS-TP forwarding
o MPLS-TP转发
The adaptation functions interface the native service (i.e., the client layer network service) to MPLS-TP. This includes the case where the native service is an MPLS-TP LSP.
自适应功能将本机服务（即客户端层网络服务）连接到MPLS-TP。这包括本机服务是MPLS-TP LSP的情况。
The forwarding functions comprise the mechanisms required for forwarding the encapsulated native service traffic over an MPLS-TP server layer network, for example, PW and LSP labels.
转发功能包括通过MPLS-TP服务器层网络（例如PW和LSP标签）转发封装的本机服务流量所需的机制。
The MPLS-TP native service adaptation functions interface the client layer network service to MPLS-TP. For pseudowires, these adaptation functions are the payload encapsulation described in Section 4.4 of [RFC3985] and Section 6 of [RFC5659]. For network layer client services, the adaptation function uses the MPLS encapsulation format as defined in [RFC3032].
MPLS-TP本机服务适配功能将客户端层网络服务连接到MPLS-TP。对于伪导线，这些自适应功能是[RFC3985]第4.4节和[RFC5659]第6节中描述的有效负载封装。对于网络层客户端服务，自适应功能使用[RFC3032]中定义的MPLS封装格式。
The purpose of this encapsulation is to abstract the data plane of the client layer network from the MPLS-TP data plane, thus contributing to the independent operation of the MPLS-TP network.
这种封装的目的是从MPLS-TP数据平面中提取客户层网络的数据平面，从而有助于MPLS-TP网络的独立操作。
MPLS-TP is itself a client of an underlying server layer. MPLS-TP is thus also bounded by a set of adaptation functions to this server layer network, which may itself be MPLS-TP. These adaptation functions provide encapsulation of the MPLS-TP frames and for the transparent transport of those frames over the server layer network. The MPLS-TP client inherits its Quality of Service (QoS) from the MPLS-TP network, which in turn inherits its QoS from the server layer. The server layer therefore needs to provide the necessary QoS to ensure that the MPLS-TP client QoS commitments can be satisfied.
MPLS-TP本身就是底层服务器层的客户机。因此，MPLS-TP也受到一组与该服务器层网络相适应的功能的限制，该服务器层网络本身可能是MPLS-TP。这些适配功能提供MPLS-TP帧的封装，并用于通过服务器层网络透明传输这些帧。MPLS-TP客户端从MPLS-TP网络继承其服务质量（QoS），而MPLS-TP网络又从服务器层继承其QoS。因此，服务器层需要提供必要的QoS，以确保能够满足MPLS-TP客户机QoS承诺。
The forwarding functions comprise the mechanisms required for forwarding the encapsulated native service traffic over an MPLS-TP server layer network, for example, PW and LSP labels.
转发功能包括通过MPLS-TP服务器层网络（例如PW和LSP标签）转发封装的本机服务流量所需的机制。
MPLS-TP LSPs use the MPLS label switching operations and Time-to-Live (TTL) processing procedures defined in [RFC3031], [RFC3032], and [RFC3443], as profiled in [DATA-PLANE]. These operations are highly optimized for performance and are not modified by the MPLS-TP profile.
MPLS-TP LSP使用[RFC3031]、[RFC3032]和[RFC3443]中定义的MPLS标签交换操作和生存时间（TTL）处理过程，如[DATA-PLANE]中所述。这些操作针对性能进行了高度优化，不受MPLS-TP配置文件的修改。
In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW forwarding operations defined in [RFC3985] and [RFC5659].
此外，MPLS-TP PWs使用[RFC3985]和[RFC5659]中定义的SS-PW和可选MS-PW转发操作。
Per-platform label space is used for PWs. Either per-platform, per-interface, or other context-specific label space [RFC5331] may be used for LSPs.
每个平台的标签空间用于PWs。每个平台、每个接口或其他特定于上下文的标签空间[RFC5331]可用于LSP。
MPLS-TP forwarding is based on the label that identifies the transport path (LSP or PW). The label value specifies the processing operation to be performed by the next hop at that level of encapsulation. A swap of this label is an atomic operation in which the contents of the packet after the swapped label are opaque to the forwarder. The only event that interrupts a swap operation is TTL expiry. This is a fundamental architectural construct of MPLS to be taken into account when designing protocol extensions (such as those for OAM) that require packets to be sent to an intermediate LSR.
MPLS-TP转发基于标识传输路径（LSP或PW）的标签。标签值指定下一跳在该封装级别执行的处理操作。该标签的交换是一种原子操作，其中交换标签后的数据包内容对转发器是不透明的。中断交换操作的唯一事件是TTL到期。这是MPLS的一个基本架构构造，在设计需要将数据包发送到中间LSR的协议扩展（如OAM的协议扩展）时需要考虑到这一点。
Further processing to determine the context of a packet occurs when a swap operation is interrupted in this manner, or a pop operation exposes a specific reserved label at the top of the stack, or the
当交换操作以这种方式中断，或者pop操作在堆栈顶部公开特定的保留标签，或者
packet is received with the GAL (Section 3.6) at the top of stack. Otherwise, the packet is forwarded according to the procedures in [RFC3032].
通过堆栈顶部的GAL（第3.6节）接收数据包。否则，根据[RFC3032]中的程序转发数据包。
MPLS-TP supports Quality of Service capabilities via the MPLS Differentiated Services (Diffserv) architecture [RFC3270]. Both E-LSP and L-LSP MPLS Diffserv modes are supported.
MPLS-TP通过MPLS区分服务（Diffserv）体系结构支持服务质量功能[RFC3270]。支持E-LSP和L-LSP MPLS区分服务模式。
Further details of MPLS-TP forwarding can be found in [DATA-PLANE].
有关MPLS-TP转发的更多详细信息，请参见[数据平面]。
This document describes the architecture for two native service adaptation mechanisms, which provide encapsulation and demultiplexing for native service traffic traversing an MPLS-TP network:
本文档描述了两种本机服务适配机制的体系结构，它们为穿过MPLS-TP网络的本机服务流量提供封装和解复用：
o A PW
o 一个
o An MPLS LSP
o MPLS-LSP协议
MPLS-TP uses IETF-defined pseudowires to emulate certain services, for example, Ethernet, Frame Relay, or PPP / High-Level Data Link Control (HDLC). A list of PW types is maintained by IANA in the "MPLS Pseudowire Type" registry. When the native service adaptation is via a PW, the mechanisms described in Section 3.4.4 are used.
MPLS-TP使用IETF定义的伪线来模拟某些服务，例如以太网、帧中继或PPP/高级数据链路控制（HDLC）。IANA在“MPLS伪线类型”注册表中维护PW类型列表。当本机服务自适应通过PW时，使用第3.4.4节中描述的机制。
An MPLS LSP can also provide the adaptation, in which case any native service traffic type supported by [RFC3031] and [RFC3032] is allowed. Examples of such traffic types include IP packets and MPLS-labeled packets. Note that the latter case includes TE-LSPs [RFC3209] and LSP-based applications such as PWs, Layer 2 VPNs [RFC4664], and Layer 3 VPNs [RFC4364]. When the native service adaptation is via an MPLS label, the mechanisms described in Section 3.4.5 are used.
MPLS LSP还可以提供自适应，在这种情况下，允许[RFC3031]和[RFC3032]支持的任何本机服务流量类型。此类流量类型的示例包括IP分组和MPLS标记的分组。注意，后一种情况包括TE LSP[RFC3209]和基于LSP的应用，如PWs、第2层VPN[RFC4664]和第3层VPN[RFC4364]。当本机服务自适应通过MPLS标签时，使用第3.4.5节中描述的机制。
The relationship between the client layer network and the MPLS-TP server layer network is defined by the MPLS-TP network boundary and the label context. It is not explicitly indicated in the packet. In terms of the MPLS label stack, when the native service traffic type is itself MPLS-labeled, then the S bits of all the labels in the MPLS-TP label stack carrying that client traffic are zero; otherwise, the bottom label of the MPLS-TP label stack has the S bit set to 1. In other words, there can be only one S bit set in a label stack.
客户层网络和MPLS-TP服务器层网络之间的关系由MPLS-TP网络边界和标签上下文定义。数据包中没有明确指出。就MPLS标签栈而言，当本机服务流量类型本身为MPLS标签时，则MPLS-TP标签栈中承载该客户端流量的所有标签的S位为零；否则，MPLS-TP标签堆栈的底部标签将S位设置为1。换句话说，标签堆栈中只能设置一个S位。
The data-plane behavior of MPLS-TP is the same as the best current practice for MPLS. This includes the setting of the S bit. In each case, the S bit is set to indicate the bottom (i.e., innermost) label
MPLS-TP的数据平面行为与MPLS的当前最佳实践相同。这包括S位的设置。在每种情况下，S位都被设置为指示底部（即最内层）标签
in the label stack that is contiguous between the MPLS-TP LSP and its payload, and only one label stack entry (LSE) contains the S bit (Bottom of Stack bit) set to 1. Note that this best current practice differs slightly from [RFC3032], which uses the S bit to identify when MPLS label processing stops and network layer processing starts.
在MPLS-TP LSP与其有效负载相邻的标签堆栈中，只有一个标签堆栈条目（LSE）包含设置为1的S位（堆栈底部位）。请注意，此最佳当前实践与[RFC3032]略有不同，后者使用S位来标识MPLS标签处理何时停止以及网络层处理何时开始。
The relationship of MPLS-TP to its clients is illustrated in Figure 2. Note that the label stacks shown in the figure are divided between those inside the MPLS-TP network and those within the client network when the client network is MPLS(-TP). They illustrate the smallest number of labels possible. These label stacks could also include more labels.
MPLS-TP与其客户端的关系如图2所示。请注意，当客户机网络为MPLS（-TP）时，图中所示的标签堆栈分为MPLS-TP网络内的标签堆栈和客户机网络内的标签堆栈。它们说明了尽可能少的标签。这些标签堆栈还可以包含更多标签。
PW-Based MPLS Labeled IP
Services Services Transport
|------------| |-----------------------------| |------------|
PW-Based MPLS Labeled IP
Services Services Transport
|------------| |-----------------------------| |------------|
Emulated PW over LSP IP over LSP IP
Service
+------------+
| PW Payload |
+------------+ +------------+ (CLIENTS)
|PW Lbl(S=1) | | IP |
+------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)| . . .
+------------+ . . . (MPLS-TP)
. . . .
.
.
Emulated PW over LSP IP over LSP IP
Service
+------------+
| PW Payload |
+------------+ +------------+ (CLIENTS)
|PW Lbl(S=1) | | IP |
+------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)| . . .
+------------+ . . . (MPLS-TP)
. . . .
.
.
~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary
~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary
Figure 2: MPLS-TP - Client Relationship
图2:MPLS-TP-客户端关系
An MPLS-TP network consists logically of two layers: the Transport Service layer and the Transport Path layer.
MPLS-TP网络在逻辑上由两层组成：传输服务层和传输路径层。
The Transport Service layer provides the interface between Customer Edge (CE) nodes and the MPLS-TP network. Each packet transmitted by a CE node for transport over the MPLS-TP network is associated at the receiving MPLS-TP Provider Edge (PE) node with a single logical point-to-point connection at the Transport Service layer between this
传输服务层提供客户边缘（CE）节点与MPLS-TP网络之间的接口。由CE节点发送用于通过MPLS-TP网络传输的每个分组在接收MPLS-TP提供商边缘（PE）节点处与该节点之间的传输服务层处的单个逻辑点到点连接相关联
(ingress) PE and the corresponding (egress) PE to which the peer CE is attached. Such a connection is called an MPLS-TP Transport Service Instance, and the set of client packets belonging to the native service associated with such an instance on a particular CE-PE link is called a client flow.
（入口）PE和对等CE连接到的相应（出口）PE。这种连接称为MPLS-TP传输服务实例，并且在特定CE-PE链路上属于与这种实例相关联的本机服务的客户端分组集称为客户端流。
The Transport Path layer provides aggregation of Transport Service Instances over MPLS-TP transport paths (LSPs), as well as aggregation of transport paths (via LSP hierarchy).
传输路径层通过MPLS-TP传输路径（LSP）提供传输服务实例的聚合，以及传输路径的聚合（通过LSP层次结构）。
Awareness of the Transport Service layer need exist only at PE nodes. MPLS-TP Provider (P) nodes need have no awareness of this layer. Both PE and P nodes participate in the Transport Path layer. A PE terminates (i.e., is an LER with respect to) the transport paths it supports, and is responsible for multiplexing and demultiplexing of Transport Service Instance traffic over such transport paths.
只有在PE节点上才需要知道传输服务层。MPLS-TP提供程序（P）节点不需要知道该层。PE和P节点都参与传输路径层。PE终止（即，是其支持的传输路径的LER），并负责在此类传输路径上复用和解复用传输服务实例流量。
An MPLS-TP PE node can provide two types of interface to the Transport Service layer. The MPLS-TP User-Network Interface (UNI) provides the interface between a CE and the MPLS-TP network. The MPLS-TP Network-Network Interface (NNI) provides the interface between two MPLS-TP PEs in different administrative domains.
MPLS-TP PE节点可以向传输服务层提供两种类型的接口。MPLS-TP用户网络接口（UNI）提供CE和MPLS-TP网络之间的接口。MPLS-TP网络接口（NNI）提供不同管理域中两个MPLS-TP PE之间的接口。
When MPLS-TP is used to provide a transport service for, e.g., IP services that are a part of a Layer 3 VPN, then packets are transported in the same manner as specified in [RFC4364].
当MPLS-TP用于提供传输服务（例如，作为第3层VPN一部分的IP服务）时，则按照[RFC4364]中规定的相同方式传输数据包。
The MPLS-TP User-Network interface (UNI) is illustrated in Figure 3. The UNI for a particular client flow may or may not involve signaling between the CE and PE, and if signaling is used, it may or may not traverse the same attachment circuit that supports the client flow.
MPLS-TP用户网络接口（UNI）如图3所示。用于特定客户端流的UNI可以或可以不涉及CE和PE之间的信令，并且如果使用信令，它可以或可以不穿过支持客户端流的相同连接电路。
: User-Network Interface : MPLS-TP
:<-------------------------------------->: Network <----->
: :
-:------------- --------------:------------------
: | | : Transport |
: | | Transport : Path |
: | | Service : Mux/Demux |
: | | Control : -- |
: | | Plane : | | Transport|
: ---------- | Signaling | ---------- : | | Path |
:|Signaling |_|___________|_|Signaling | : | | --------->
:|Controller| | | |Controller| : | | |
: ---------- | | ---------- : | | --------->
: :......|...........|......: : | | |
: | Control | : | | Transport|
: | Channel | : | | Path |
: | | : | | --------->
: | | : | | -+----------->TSI
: | | Transport : | | | --------->
: | Client | Service : | | | |
: | Traffic | Data Plane : | | | |
: ---------- | Flows | -------------- | | |Transport|
:|Signaling |-|-----------|-|Client/Service|-| |- Path |
:|Controller|=|===========|=| Traffic | | | --------->
: ---------- | | | Processing |=| |===+===========>TSI
: | | | -------------- | | --------->
: |______|___________|______| : | | |
: | Data Link | : | | |
: | | : -- |
: | | : Transport |
: | | : Service |
: | | : Data Plane|
--------------- ---------------------------------
Customer Edge Node MPLS-TP Provider Edge Node
: User-Network Interface : MPLS-TP
:<-------------------------------------->: Network <----->
: :
-:------------- --------------:------------------
: | | : Transport |
: | | Transport : Path |
: | | Service : Mux/Demux |
: | | Control : -- |
: | | Plane : | | Transport|
: ---------- | Signaling | ---------- : | | Path |
:|Signaling |_|___________|_|Signaling | : | | --------->
:|Controller| | | |Controller| : | | |
: ---------- | | ---------- : | | --------->
: :......|...........|......: : | | |
: | Control | : | | Transport|
: | Channel | : | | Path |
: | | : | | --------->
: | | : | | -+----------->TSI
: | | Transport : | | | --------->
: | Client | Service : | | | |
: | Traffic | Data Plane : | | | |
: ---------- | Flows | -------------- | | |Transport|
:|Signaling |-|-----------|-|Client/Service|-| |- Path |
:|Controller|=|===========|=| Traffic | | | --------->
: ---------- | | | Processing |=| |===+===========>TSI
: | | | -------------- | | --------->
: |______|___________|______| : | | |
: | Data Link | : | | |
: | | : -- |
: | | : Transport |
: | | : Service |
: | | : Data Plane|
--------------- ---------------------------------
Customer Edge Node MPLS-TP Provider Edge Node
TSI = Transport Service Instance
TSI = Transport Service Instance
Figure 3: MPLS-TP PE Containing a UNI
图3：包含UNI的MPLS-TP PE
--------------From UNI-------> :
-------------------------------------------:------------------
| | Client Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Transport |
| | Service Instance : Encapsulation |
| | Identification : |
-------------------------------------------:------------------
:
:
-------------------------------------------:------------------
| | : Service Instance |
| | : Transport |
| Link-Layer-Specific | Client Traffic Unit : Decapsulation |
| Processing | Link Encapsulation : & |
| | : Service Instance |
| | : Identification |
-------------------------------------------:------------------
<-------------To UNI --------- :
--------------From UNI-------> :
-------------------------------------------:------------------
| | Client Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Transport |
| | Service Instance : Encapsulation |
| | Identification : |
-------------------------------------------:------------------
:
:
-------------------------------------------:------------------
| | : Service Instance |
| | : Transport |
| Link-Layer-Specific | Client Traffic Unit : Decapsulation |
| Processing | Link Encapsulation : & |
| | : Service Instance |
| | : Identification |
-------------------------------------------:------------------
<-------------To UNI --------- :
Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages
图4:MPLS-TP UNI客户端-服务器流量处理阶段
Figure 4 shows the logical processing steps involved in a PE both for traffic flowing from the CE to the MPLS-TP network (left to right), and from the network to the CE (right to left).
图4显示了PE中涉及的逻辑处理步骤，包括从CE到MPLS-TP网络（从左到右）和从网络到CE（从右到左）的流量。
In the first case, when a packet from a client flow is received by the PE from the CE over the data-link, the following steps occur:
在第一种情况下，当PE通过数据链路从CE接收到来自客户端流的分组时，发生以下步骤：
1. Link-layer-specific pre-processing, if any, is performed. An example of such pre-processing is the PREP function illustrated in Figure 3 of [RFC3985]. Such pre-processing is outside the scope of MPLS-TP.
1. 执行链路层特定的预处理（如果有）。这种预处理的一个例子是[RFC3985]图3所示的准备功能。这种预处理超出了MPLS-TP的范围。
2. The packet is extracted from the data-link frame, if necessary, and associated with a Transport Service Instance. At this point, UNI processing has completed.
2. 必要时，从数据链路帧提取分组，并与传输服务实例相关联。此时，UNI处理已完成。
3. A transport service encapsulation is associated with the packet, if necessary, for transport over the MPLS-TP network.
3. 如有必要，传输服务封装与包相关联，用于通过MPLS-TP网络进行传输。
4. The packet is mapped to a transport path based on its associated Transport Service Instance, the transport path encapsulation is added, if necessary, and the packet is transmitted over the transport path.
4. 分组基于其相关联的传输服务实例被映射到传输路径，如有必要，添加传输路径封装，并且分组通过传输路径传输。
In the second case, when a packet associated with a Transport Service Instance arrives over a transport path, the following steps occur:
在第二种情况下，当与传输服务实例关联的数据包通过传输路径到达时，发生以下步骤：
1. The transport path encapsulation is disposed of.
1. 处理传输路径封装。
2. The transport service encapsulation is disposed of and the Transport Service Instance and client flow identified.
2. 处理传输服务封装，并标识传输服务实例和客户端流。
3. At this point, UNI processing begins. A data-link encapsulation is associated with the packet for delivery to the CE based on the client flow.
3. 此时，UNI处理开始。数据链路封装与分组相关联，以便基于客户端流将其传送到CE。
4. Link-layer-specific postprocessing, if any, is performed. Such postprocessing is outside the scope of MPLS-TP.
4. 执行特定于链路层的后处理（如果有）。这种后处理超出了MPLS-TP的范围。
The MPLS-TP NNI is illustrated in Figure 5. The NNI for a particular Transport Service Instance may or may not involve signaling between the two PEs; and if signaling is used, it may or may not traverse the same data-link that supports the service instance.
MPLS-TP NNI如图5所示。特定传输服务实例的NNI可能涉及也可能不涉及两个PEs之间的信令；并且，如果使用信令，则它可以也可以不通过支持服务实例的同一数据链路。
: Network-Network Interface :
:<--------------------------------->:
: :
------------:------------- -------------:------------
| Transport : | | : Transport |
| Path : Transport | | Transport : Path |
| Mux/Demux : Service | | Service : Mux/Demux |
| -- : Control | | Control : -- |
| | | : Plane |Sig- | Plane : | | |
|TP | | : ---------- | naling| ---------- : | | TP|
<--- | | :|Signaling |_|_______|_|Signaling |: | | --->
TSI<-+- | | :|Controller| | | |Controller|: | | |
<--- | | | : ---------- | | ---------- : | | --->
| | | | : :......|.......|......: : | | |
| | | | : |Control| : | | |
|TP | | | : |Channel| : | | TP|
<--- | | | : | | : | | --->
| | | | : | | : | | -+->TSI
<--- | | | : Transport | | Transport : | | | --->
| | | | : Service |Service| Service : | | | |
| | | | : Data Plane |Traffic| Data Plane : | | | |
| | | | ------------- | Flows | ------------- | | | |
|TP -| |-| Service |-|-------|-| Service |-| |- TP|
<--- | | | Traffic | | | | Traffic | | | --->
TSI<=+===| |=| Processing |=|=======|=| Processing |=| |===+=>TSI
<--- | | ------------- | | ------------- | | --->
| | | : |______|_______|______| : | | |
| | | : | Data | : | | |
| -- : | Link | : -- |
| : | | : |
-------------------------- --------------------------
MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node
: Network-Network Interface :
:<--------------------------------->:
: :
------------:------------- -------------:------------
| Transport : | | : Transport |
| Path : Transport | | Transport : Path |
| Mux/Demux : Service | | Service : Mux/Demux |
| -- : Control | | Control : -- |
| | | : Plane |Sig- | Plane : | | |
|TP | | : ---------- | naling| ---------- : | | TP|
<--- | | :|Signaling |_|_______|_|Signaling |: | | --->
TSI<-+- | | :|Controller| | | |Controller|: | | |
<--- | | | : ---------- | | ---------- : | | --->
| | | | : :......|.......|......: : | | |
| | | | : |Control| : | | |
|TP | | | : |Channel| : | | TP|
<--- | | | : | | : | | --->
| | | | : | | : | | -+->TSI
<--- | | | : Transport | | Transport : | | | --->
| | | | : Service |Service| Service : | | | |
| | | | : Data Plane |Traffic| Data Plane : | | | |
| | | | ------------- | Flows | ------------- | | | |
|TP -| |-| Service |-|-------|-| Service |-| |- TP|
<--- | | | Traffic | | | | Traffic | | | --->
TSI<=+===| |=| Processing |=|=======|=| Processing |=| |===+=>TSI
<--- | | ------------- | | ------------- | | --->
| | | : |______|_______|______| : | | |
| | | : | Data | : | | |
| -- : | Link | : -- |
| : | | : |
-------------------------- --------------------------
MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node
TP = Transport Path TSI = Transport Service Instance
TP=传输路径TSI=传输服务实例
Figure 5: MPLS-TP PE Containing an NNI
图5：包含NNI的MPLS-TP PE
:
--------------From NNI-------> :
--------------------------------------------:------------------
| | Service Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Encapsulation |
| | Service Instance : Normalization |
| | Identification : |
--------------------------------------------:------------------
:
:
--------------------------------------------:------------------
| | : Service Instance |
| | : Identification |
| Link-Layer-Specific | Service Traffic Unit : & |
| Processing | Link Encapsulation : Service Instance |
| | : Encapsulation |
| | : Normalization |
--------------------------------------------:------------------
<-------------To NNI --------- :
:
--------------From NNI-------> :
--------------------------------------------:------------------
| | Service Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Encapsulation |
| | Service Instance : Normalization |
| | Identification : |
--------------------------------------------:------------------
:
:
--------------------------------------------:------------------
| | : Service Instance |
| | : Identification |
| Link-Layer-Specific | Service Traffic Unit : & |
| Processing | Link Encapsulation : Service Instance |
| | : Encapsulation |
| | : Normalization |
--------------------------------------------:------------------
<-------------To NNI --------- :
Figure 6: MPLS-TP NNI Service Traffic Processing Stages
图6:MPLS-TP NNI业务流量处理阶段
Figure 6 shows the logical processing steps involved in a PE for traffic flowing both from the peer PE (left to right) and to the peer PE (right to left).
图6显示了从对等PE（从左到右）和从对等PE（从右到左）的流量的PE中涉及的逻辑处理步骤。
In the first case, when a packet from a Transport Service Instance is received by the PE from the peer PE over the data-link, the following steps occur:
在第一种情况下，当PE通过数据链路从对等PE接收到来自传输服务实例的分组时，发生以下步骤：
1. Link-layer specific pre-processing, if any, is performed. Such pre-processing is outside the scope of MPLS-TP.
1. 执行链路层特定的预处理（如果有）。这种预处理超出了MPLS-TP的范围。
2. The packet is extracted from the data-link frame if necessary, and associated with a Transport Service Instance. At this point, NNI processing has completed.
2. 必要时，从数据链路帧提取分组，并与传输服务实例相关联。此时，NNI处理已完成。
3. The transport service encapsulation of the packet is normalized for transport over the MPLS-TP network. This step allows a different transport service encapsulation to be used over the NNI than that used in the internal MPLS-TP network. An example of such normalization is a swap of a label identifying the Transport Service Instance.
3. 数据包的传输服务封装被规范化，以便通过MPLS-TP网络进行传输。此步骤允许在NNI上使用不同于内部MPLS-TP网络中使用的传输服务封装。这种规范化的一个例子是交换标识传输服务实例的标签。
4. The packet is mapped to a transport path based on its associated Transport Service Instance, the transport path encapsulation is added, if necessary, and the packet is transmitted over the transport path.
4. 分组基于其相关联的传输服务实例被映射到传输路径，如有必要，添加传输路径封装，并且分组通过传输路径传输。
In the second case, when a packet associated with a Transport Service Instance arrives over a transport path, the following steps occur:
在第二种情况下，当与传输服务实例关联的数据包通过传输路径到达时，发生以下步骤：
1. The transport path encapsulation is disposed of.
1. 处理传输路径封装。
2. The Transport Service Instance is identified from the transport service encapsulation, and this encapsulation is normalized for delivery over the NNI (see Step 3 above).
2. 传输服务实例由传输服务封装标识，该封装被规范化，以便通过NNI交付（请参见上面的步骤3）。
3. At this point, NNI processing begins. A data-link encapsulation is associated with the packet for delivery to the peer PE based on the normalized Transport Service Instance.
3. 此时，NNI处理开始。数据链路封装与分组相关联，以便基于标准化传输服务实例将其传送到对等PE。
4. Link-layer-specific postprocessing, if any, is performed. Such postprocessing is outside the scope of MPLS-TP.
4. 执行特定于链路层的后处理（如果有）。这种后处理超出了MPLS-TP的范围。
This section considers some special cases of UNI processing for particular transport service types. These are illustrative, and do not preclude other transport service types.
本节考虑特定运输服务类型的UNI处理的一些特殊情况。这些都是说明性的，并不排除其他运输服务类型。
In this example the MPLS-TP network is providing a point-to-point Layer 2 transport service between attached CE nodes. This service is provided by a Transport Service Instance consisting of a PW established between the associated PE nodes. The client flows associated with this Transport Service Instance are the sets of all Layer 2 frames transmitted and received over the attachment circuits.
在此示例中，MPLS-TP网络在连接的CE节点之间提供点对点第2层传输服务。该服务由传输服务实例提供，该实例由在相关PE节点之间建立的PW组成。与此传输服务实例相关联的客户端流是通过连接电路发送和接收的所有第2层帧的集合。
The processing steps in this case for a frame received from the CE are:
在这种情况下，对于从CE接收的帧的处理步骤是：
1. Link-layer specific pre-processing, if any, is performed, corresponding to the PREP function illustrated in Figure 3 of [RFC3985].
1. 与[RFC3985]图3所示的准备功能相对应，执行链路层特定的预处理（如有）。
2. The frame is associated with a Transport Service Instance based on the attachment circuit over which it was received.
2. 该帧基于接收它的连接电路与传输服务实例相关联。
3. A transport service encapsulation, consisting of the PW control word and PW label, is associated with the frame.
3. 由PW控制字和PW标签组成的传输服务封装与帧相关联。
4. The resulting packet is mapped to an LSP, the LSP label is pushed, and the packet is transmitted over the outbound interface associated with the LSP.
4. 结果分组被映射到LSP，LSP标签被推送，并且分组通过与LSP相关联的出站接口被传输。
For PW packets received over the LSP, the steps are performed in the reverse order.
对于通过LSP接收的PW数据包，步骤按相反顺序执行。
In this example, the MPLS-TP network is providing a point-to-point IP transport service between CE1, CE2, and CE3, as follows. One point-to-point Transport Service Instance delivers IPv4 packets between CE1 and CE2, and another instance delivers IPv6 packets between CE1 and CE3.
在此示例中，MPLS-TP网络在CE1、CE2和CE3之间提供点对点IP传输服务，如下所示。一个点到点传输服务实例在CE1和CE2之间传递IPv4数据包，另一个实例在CE1和CE3之间传递IPv6数据包。
The processing steps in this case for an IP packet received from CE1 are:
在这种情况下，对于从CE1接收的IP分组的处理步骤是：
1. No link-layer-specific processing is performed.
1. 不执行链接层特定的处理。
2. The IP packet is extracted from the link-layer frame and associated with a Service LSP based on the source MAC address (CE1) and the IP protocol version.
2. 从链路层帧提取IP分组，并基于源MAC地址（CE1）和IP协议版本与服务LSP相关联。
3. A transport service encapsulation, consisting of the Service LSP label, is associated with the packet.
3. 由服务LSP标签组成的传输服务封装与数据包相关联。
4. The resulting packet is mapped to a tunnel LSP, the tunnel LSP label is pushed, and the packet is transmitted over the outbound interface associated with the LSP.
4. 生成的分组映射到隧道LSP，推送隧道LSP标签，并且分组通过与LSP相关联的出站接口传输。
For packets received over a tunnel LSP carrying the Service LSP label, the steps are performed in the reverse order.
对于通过携带服务LSP标签的隧道LSP接收的分组，步骤按相反顺序执行。
MPLS-TP uses pseudowires to provide a Virtual Private Wire Service (VPWS), a Virtual Private Local Area Network Service (VPLS), a Virtual Private Multicast Service (VPMS), and an Internet Protocol Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are described in [RFC4664]. VPMS is described in [VPMS-REQS].
MPLS-TP使用伪线提供虚拟专用线服务（VPWS）、虚拟专用局域网服务（VPLS）、虚拟专用多播服务（VPMS）和Internet协议局域网服务（IPLS）。[RFC4664]中描述了VPW、VLP和IPL。VPMS在[VPMS-REQS]中有描述。
If the MPLS-TP network provides a layer 2 interface (that can carry both network-layer and non-network-layer traffic) as a service interface, then a PW is required to support the service interface. The PW is a client of the MPLS-TP LSP server layer. The architecture for an MPLS-TP network that provides such services is based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures. Multi-segment
如果MPLS-TP网络提供第2层接口（可承载网络层和非网络层流量）作为服务接口，则需要PW来支持服务接口。PW是MPLS-TP LSP服务器层的客户端。提供此类服务的MPLS-TP网络的体系结构基于MPLS[RFC3031]和伪线[RFC3985]体系结构。多段
pseudowires may optionally be used to provide a packet transport service, and their use is consistent with the MPLS-TP architecture. The use of MS-PWs may be motivated by, for example, the requirements specified in [RFC5254]. If MS-PWs are used, then the MS-PW architecture [RFC5659] also applies.
伪线可以可选地用于提供分组传输服务，并且它们的使用与MPLS-TP架构一致。MS PWs的使用可能出于[RFC5254]中规定的要求。如果使用MS PW，则MS-PW体系结构[RFC5659]也适用。
Figure 7 shows the architecture for an MPLS-TP network using single-segment PWs. Note that, in this document, the client layer is equivalent to the emulated service described in [RFC3985], while the Transport LSP is equivalent to the Packet Switched Network (PSN) tunnel of [RFC3985].
图7显示了使用单段PWs的MPLS-TP网络的体系结构。注意，在本文档中，客户端层相当于[RFC3985]中描述的模拟服务，而传输LSP相当于[RFC3985]中的分组交换网络（PSN）隧道。
|<----------------- Client Layer ------------------->|
| |
| |<-------- Pseudowire -------->| |
| | encapsulated, packet | |
| | transport service | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
|<----------------- Client Layer ------------------->|
| |
| |<-------- Pseudowire -------->| |
| | encapsulated, packet | |
| | transport service | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
Figure 7: MPLS-TP Architecture (Single Segment PW)
图7:MPLS-TP体系结构（单段PW）
Figure 8 shows the architecture for an MPLS-TP network when multi-segment pseudowires are used. Note that as in the SS-PW case, P-routers may also exist.
图8显示了使用多段伪线时MPLS-TP网络的体系结构。注意，在SS-PW的情况下，P路由器也可能存在。
|<--------------------- Client Layer ------------------------>|
| |
| Pseudowire encapsulated, |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ | |
| TE LSP | TE LSP |
| P-router |
Native Service Native Service
|<--------------------- Client Layer ------------------------>|
| |
| Pseudowire encapsulated, |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ | |
| TE LSP | TE LSP |
| P-router |
Native Service Native Service
PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while PW2-segment1 and PW2-segment2 are segments of another MS-PW.
PW1-段1和PW1-段2是同一MS-PW的段，而PW2-段1和PW2-段2是另一MS-PW的段。
Figure 8: MPLS-TP Architecture (Multi-Segment PW)
图8:MPLS-TP体系结构（多段PW）
The corresponding MPLS-TP protocol stacks including PWs are shown in Figure 9. In this figure, the Transport Service layer [RFC5654] is identified by the PW demultiplexer (Demux) label, and the Transport Path layer [RFC5654] is identified by the LSP Demux Label.
包括PWs的相应MPLS-TP协议栈如图9所示。在该图中，传输服务层[RFC5654]由PW解复用器（Demux）标签标识，而传输路径层[RFC5654]由LSP解复用器标签标识。
+-------------------+ /===================\ /===================\
| Client Layer | H OAM PDU H H OAM PDU H
/===================\ H-------------------H H-------------------H
H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
+-------------------+ /===================\ /===================\
| Client Layer | H OAM PDU H H OAM PDU H
/===================\ H-------------------H H-------------------H
H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM
用户流量PW OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack considered in this document.
注：H（IGHLIGHT）表示本文档中考虑的协议栈部分。
Figure 9: MPLS-TP Label Stack Using Pseudowires
图9：使用伪线的MPLS-TP标签堆栈
PWs and their associated labels may be configured or signaled. See Section 3.11 for additional details related to configured service types. See Section 3.9 for additional details related to signaled service types.
PWs及其相关标签可以配置或发出信号。有关配置服务类型的更多详细信息，请参见第3.11节。有关信号服务类型的更多详细信息，请参见第3.9节。
MPLS-TP LSPs can be used to transport network-layer clients. This document uses the term Network Layer in the same sense as it is used in [RFC3031] and [RFC3032]. The network-layer protocols supported by [RFC3031] and [RFC3032] can be transported between service interfaces. Support for network-layer clients follows the MPLS architecture for support of network-layer protocols as specified in [RFC3031] and [RFC3032].
MPLS-TP LSP可用于传输网络层客户端。本文件使用术语网络层的含义与[RFC3031]和[RFC3032]中使用的含义相同。[RFC3031]和[RFC3032]支持的网络层协议可以在服务接口之间传输。对网络层客户端的支持遵循MPLS体系结构，以支持[RFC3031]和[RFC3032]中规定的网络层协议。
With network-layer adaptation, the MPLS-TP domain provides either a unidirectional or bidirectional point-to-point connection between two PEs in order to deliver a packet transport service to attached customer edge (CE) nodes. For example, a CE may be an IP, MPLS, or MPLS-TP node. As shown in Figure 10, there is an attachment circuit between the CE node on the left and its corresponding provider edge (PE) node (which provides the service interface), a bidirectional LSP across the MPLS-TP network to the corresponding PE node on the right, and an attachment circuit between that PE node and the corresponding CE node for this service.
通过网络层适配，MPLS-TP域在两个PE之间提供单向或双向点到点连接，以便向连接的客户边缘（CE）节点提供分组传输服务。例如，CE可以是IP、MPLS或MPLS-TP节点。如图10所示，左侧的CE节点与其对应的提供商边缘（PE）节点（提供服务接口）之间存在连接电路，右侧的PE节点通过MPLS-TP网络具有双向LSP，以及该PE节点和用于该服务的对应CE节点之间的连接电路。
The attachment circuits may be heterogeneous (e.g., any combination of SDH, PPP, Frame Relay, etc.) and network-layer protocol payloads arrive at the service interface encapsulated in the Layer 1 / Layer 2
连接电路可以是异构的（例如，SDH、PPP、帧中继等的任何组合），并且网络层协议有效载荷到达封装在第1层/第2层中的服务接口
encoding defined for that access link type. It should be noted that the set of network-layer protocols includes MPLS, and hence MPLS-encoded packets with an MPLS label stack (the client MPLS stack) may appear at the service interface.
为该访问链接类型定义的编码。应当注意的是，网络层协议的集合包括MPLS，因此具有MPLS标签栈（客户端MPLS栈）的MPLS编码的分组可以出现在服务接口处。
The following figures illustrate the reference models for network-layer adaptation. The details of these figures are described further in the following paragraphs.
下图说明了网络层自适应的参考模型。这些数字的细节将在以下段落中进一步描述。
|<------------- Client Network Layer --------------->|
| |
| |<----------- Packet --------->| |
| | Transport Service | |
| | | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|..Svc LSP1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|..Svc LSP2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
|<------------- Client Network Layer --------------->|
| |
| |<----------- Packet --------->| |
| | Transport Service | |
| | | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|..Svc LSP1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|..Svc LSP2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
Figure 10: MPLS-TP Architecture for Network-Layer Clients
图10：网络层客户端的MPLS-TP体系结构
|<--------------------- Client Layer ------------------------>|
| |
| |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | | PE1|===============\ /=====| PE2|==========| PE3| | +---+
| |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ ^ | |
| TE LSP | | TE LSP |
| P-router | |
Native Service (LSR for | Native Service
T'port LSP1) |
|
LSR for Service LSPs
LER for Transport LSPs
|<--------------------- Client Layer ------------------------>|
| |
| |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | | PE1|===============\ /=====| PE2|==========| PE3| | +---+
| |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ ^ | |
| TE LSP | | TE LSP |
| P-router | |
Native Service (LSR for | Native Service
T'port LSP1) |
|
LSR for Service LSPs
LER for Transport LSPs
Figure 11: MPLS-TP Architecture for Network Layer Adaptation, Showing Service LSP Switching
图11：用于网络层适配的MPLS-TP体系结构，显示了服务LSP交换
Client packets are received at the ingress service interface. The PE pushes one or more labels onto the client packets that are then label switched over the transport network. Correspondingly, the egress PE pops any labels added by the MPLS-TP networks and transmits the packet for delivery to the attached CE via the egress service interface.
在入口服务接口处接收客户端数据包。PE将一个或多个标签推送到客户端数据包上，然后通过传输网络进行标签交换。相应地，出口PE弹出由MPLS-TP网络添加的任何标签，并通过出口服务接口将分组传送到所附CE。
/===================\
H OAM PDU H
+-------------------+ H-------------------H /===================\
| Client Layer | H GACh H H OAM PDU H
/===================\ H-------------------H H-------------------H
H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
/===================\
H OAM PDU H
+-------------------+ H-------------------H /===================\
| Client Layer | H GACh H H OAM PDU H
/===================\ H-------------------H H-------------------H
H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic Service LSP OAM LSP OAM
用户流量服务LSP OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack considered in this document.
注：H（IGHLIGHT）表示本文档中考虑的协议栈部分。
Figure 12: MPLS-TP Label Stack for IP and LSP Clients
图12:IP和LSP客户端的MPLS-TP标签堆栈
In the figures above, the Transport Service layer [RFC5654] is identified by the Service LSP (SvcLSP) demultiplexer (Demux) label, and the Transport Path layer [RFC5654] is identified by the Transport (Trans) LSP Demux Label. Note that the functions of the Encapsulation Label (Encap Label) and the Service Label (SvcLSP Demux) shown above may alternatively be represented by a single label stack entry. Note that the S bit is always zero when the client layer is MPLS-labeled. It may be necessary to swap a service LSP label at an intermediate node. This is shown in Figure 11.
在上图中，传输服务层[RFC5654]由服务LSP（SvcLSP）解复用器（Demux）标签标识，传输路径层[RFC5654]由传输（Trans）LSP解复用器标签标识。注意，上面所示的封装标签（Encap标签）和服务标签（SvcLSP Demux）的功能也可以由单个标签堆栈条目表示。请注意，当客户端层标记为MPLS时，S位始终为零。可能需要在中间节点交换服务LSP标签。如图11所示。
Within the MPLS-TP transport network, the network-layer protocols are carried over the MPLS-TP network using a logically separate MPLS label stack (the server stack). The server stack is entirely under the control of the nodes within the MPLS-TP transport network and it is not visible outside that network. Figure 12 shows how a client network protocol stack (which may be an MPLS label stack and payload) is carried over a network layer client service over an MPLS-TP transport network.
在MPLS-TP传输网络中，网络层协议使用逻辑上独立的MPLS标签堆栈（服务器堆栈）在MPLS-TP网络上传输。服务器堆栈完全由MPLS-TP传输网络内的节点控制，在该网络外不可见。图12显示了客户机网络协议栈（可能是MPLS标签栈和有效负载）如何通过MPLS-TP传输网络上的网络层客户机服务进行传输。
A label may be used to identify the network-layer protocol payload type. Therefore, when multiple protocol payload types are to be carried over a single service LSP, a unique label stack entry needs to be present for each payload type. Such labels are referred to as "Encapsulation Labels", one of which is shown in Figure 12. An Encapsulation Label may be either configured or signaled.
标签可用于标识网络层协议有效负载类型。因此，当多个协议有效负载类型要通过单个服务LSP承载时，需要为每个有效负载类型提供唯一的标签堆栈条目。此类标签称为“封装标签”，其中一个如图12所示。封装标签可以是配置的，也可以是信号的。
Both an Encapsulation Label and a Service Label should be present in the label stack when a particular packet transport service is supporting more than one network-layer protocol payload type. For example, if both IP and MPLS are to be carried, then two Encapsulation Labels are mapped on to a common Service Label.
当特定分组传输服务支持多个网络层协议有效负载类型时，标签堆栈中应同时存在封装标签和服务标签。例如，如果同时携带IP和MPLS，则两个封装标签映射到公共服务标签上。
Note: The Encapsulation Label may be omitted when the service LSP is supporting only one network-layer protocol payload type. For example, if only MPLS labeled packets are carried over a service, then the Service Label (stack entry) provides both the payload type indication and service identification. The Encapsulation Label cannot have any of the reserved label values [RFC3032].
注意：当服务LSP仅支持一种网络层协议有效负载类型时，可以省略封装标签。例如，如果在服务上仅携带带有MPLS标签的数据包，则服务标签（堆栈条目）提供有效负载类型指示和服务标识。封装标签不能有任何保留标签值[RFC3032]。
Service labels are typically carried over an MPLS-TP Transport LSP edge-to-edge (or transport path layer). An MPLS-TP Transport LSP is represented as an LSP Transport Demux label, as shown in Figure 12. Transport LSP is commonly used when more than one service exists between two PEs.
服务标签通常携带在MPLS-TP传输LSP边到边（或传输路径层）上。MPLS-TP传输LSP表示为LSP传输解复用标签，如图12所示。当两个PE之间存在多个服务时，通常使用传输LSP。
Note that, if only one service exists between two PEs, the functions of the Transport LSP label and the Service LSP Label may be combined into a single label stack entry. For example, if only one service is carried between two PEs, then a single label could be used to provide both the service indication and the MPLS-TP Transport LSP. Alternatively, if multiple services exist between a pair of PEs, then a per-client Service Label would be mapped on to a common MPLS-TP Transport LSP.
请注意，如果两个PE之间仅存在一个服务，则传输LSP标签和服务LSP标签的功能可以组合到单个标签堆栈条目中。例如，如果两个PE之间仅承载一个服务，则可以使用单个标签来提供服务指示和MPLS-TP传输LSP。或者，如果一对PE之间存在多个服务，则每个客户端服务标签将映射到公共MPLS-TP传输LSP。
As noted above, the Layer 2 and Layer 1 protocols used to carry the network-layer protocol over the attachment circuits are not transported across the MPLS-TP network. This enables the use of different Layer 2 and Layer 1 protocols on the two attachment circuits.
如上所述，用于在连接电路上承载网络层协议的第2层和第1层协议不在MPLS-TP网络上传输。这允许在两个连接电路上使用不同的第2层和第1层协议。
At each service interface, Layer 2 addressing needs to be used to ensure the proper delivery of a network-layer packet to the adjacent node. This is typically only an issue for LAN media technologies (e.g., Ethernet) that have Media Access Control (MAC) addresses. In cases where a MAC address is needed, the sending node sets the destination MAC address to an address that ensures delivery to the adjacent node. That is, the CE sets the destination MAC address to an address that ensures delivery to the PE, and the PE sets the destination MAC address to an address that ensures delivery to the CE. The specific address used is technology type specific and is not specified in this document. In some technologies, the MAC address will need to be configured.
在每个服务接口上，需要使用第2层寻址来确保将网络层数据包正确地传送到相邻节点。这通常只是具有媒体访问控制（MAC）地址的LAN媒体技术（如以太网）的一个问题。在需要MAC地址的情况下，发送节点将目的地MAC地址设置为确保传送到相邻节点的地址。即，CE将目的地MAC地址设置为确保向PE递送的地址，并且PE将目的地MAC地址设置为确保向CE递送的地址。所使用的特定地址是特定于技术类型的，本文档中未指定。在某些技术中，需要配置MAC地址。
Note that when two CEs, which peer with each other, operate over a network layer transport service and run a routing protocol such as IS-IS or OSPF, some care should be taken to configure the routing protocols to use point-to-point adjacencies. The specifics of such configuration is outside the scope of this document. See [RFC5309] for additional details.
请注意，当相互对等的两个CE在网络层传输服务上运行并运行IS-IS或OSPF等路由协议时，应注意将路由协议配置为使用点对点邻接。此类配置的细节不在本文档的范围内。有关更多详细信息，请参见[RFC5309]。
The CE-to-CE service types and corresponding labels may be configured or signaled.
CE到CE服务类型和相应标签可以被配置或发信号。
Identifiers are used to uniquely distinguish entities in an MPLS-TP network. These include operators, nodes, LSPs, pseudowires, and their associated maintenance entities. MPLS-TP defined two types of sets of identifiers: those that are compatible with IP, and those that are compatible with ITU-T transport-based operations. The definition of these sets of identifiers is outside the scope of this document and is provided by [IDENTIFIERS].
标识符用于唯一区分MPLS-TP网络中的实体。其中包括运营商、节点、LSP、伪线及其关联的维护实体。MPLS-TP定义了两种类型的标识符集：与IP兼容的标识符集和与基于ITU-T传输的操作兼容的标识符集。这些标识符集的定义不在本文件范围内，由[标识符]提供。
For correct operation of OAM mechanisms, it is important that OAM packets fate-share with the data packets. In addition, in MPLS-TP it is necessary to discriminate between user data payloads and other types of payload. For example, a packet may be associated with a Signaling Communication Channel (SCC) or a channel used for a protocol to coordinate path protection state. This is achieved by carrying such packets in either:
为了正确操作OAM机制，OAM数据包的命运与数据包共享是很重要的。此外，在MPLS-TP中，有必要区分用户数据有效载荷和其他类型的有效载荷。例如，分组可与信令通信信道（SCC）或用于协议以协调路径保护状态的信道相关联。这是通过以下方式之一携带此类数据包实现的：
o A generic control channel associated to the LSP, PW, or section, with no IP encapsulation, e.g., in a similar manner to Bidirectional Forwarding Detection for Virtual Circuit Connectivity Verification (VCCV-BFD) with PW ACH encapsulation [RFC5885]).
o 与LSP、PW或段相关联的通用控制信道，无IP封装，例如，采用与PW ACH封装的虚拟电路连接验证双向转发检测（VCCV-BFD）[RFC5885]）类似的方式。
o An IP encapsulation where IP capabilities are present, e.g., PW ACH encapsulation with IP headers for VCCV-BFD [RFC5885] or IP encapsulation for MPLS BFD [RFC5884].
o 存在IP功能的IP封装，例如，VCCV-BFD[RFC5885]的带有IP头的PW ACH封装或MPLS BFD[RFC5884]的IP封装。
MPLS-TP makes use of such a generic associated channel (G-ACh) to support Fault, Configuration, Accounting, Performance, and Security (FCAPS) functions by carrying packets related to OAM, a protocol used to coordinate path protection state, SCC, MCC or other packet types in-band over LSPs, PWs, or sections. The G-ACh is defined in [RFC5586] and is similar to the Pseudowire Associated Channel [RFC4385], which is used to carry OAM packets over pseudowires. The G-ACh is indicated by an Associated Channel Header (ACH), similar to
MPLS-TP利用这种通用关联信道（G-ACh）来支持故障、配置、计费、性能和安全（FCAPS）功能，方法是通过承载与OAM相关的数据包，OAM是一种用于协调路径保护状态、SCC、MCC或LSP、PWs或段上带内其他数据包类型的协议。G-ACh在[RFC5586]中定义，类似于伪线相关信道[RFC4385]，用于通过伪线承载OAM数据包。G-ACh由相关信道头（ACh）指示，类似于
the Pseudowire VCCV control word; this header is present for all sections, LSPs, and PWs that make use of FCAPS functions supported by the G-ACh.
伪线VCCV控制字；此标题适用于使用G-ACh支持的FCAPS功能的所有区段、LSP和PW。
As specified in [RFC5586], the G-ACh must only be used for channels that are an adjunct to the data service. Examples of these are OAM, a protocol used to coordinate path protection state, MCC, and SCC, but the use is not restricted to these services. The G-ACh must not be used to carry additional data for use in the forwarding path, i.e., it must not be used as an alternative to a PW control word, or to define a PW type.
如[RFC5586]所述，G-ACh只能用于作为数据服务附件的通道。例如OAM，一种用于协调路径保护状态、MCC和SCC的协议，但使用并不限于这些服务。G-ACh不得用于承载在转发路径中使用的附加数据，即不得用作PW控制字的替代品，或用于定义PW类型。
At the server layer, bandwidth and QoS commitments apply to the gross traffic on the LSP, PW, or section. Since the G-ACh traffic is indistinguishable from the user data traffic, protocols using the G-ACh need to take into consideration the impact they have on the user data with which they are sharing resources. Conversely, capacity needs to be made available for important G-ACh uses such as protection and OAM. In addition, the security and congestion considerations described in [RFC5586] apply to protocols using the G-ACh.
在服务器层，带宽和QoS承诺适用于LSP、PW或段上的总流量。由于G-ACh流量与用户数据流量无法区分，因此使用G-ACh的协议需要考虑它们对共享资源的用户数据的影响。相反，需要为重要的G-ACh用途（如保护和OAM）提供容量。此外，[RFC5586]中描述的安全和拥塞注意事项适用于使用G-ACh的协议。
Figure 13 shows the reference model depicting how the control channel is associated with the pseudowire protocol stack. This is based on the reference model for VCCV shown in Figure 2 of [RFC5085].
图13显示了描述控制信道如何与伪线协议栈关联的参考模型。这基于[RFC5085]图2中所示的VCCV参考模型。
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < ACH for PW > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < ACH for PW > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 13: PWE3 Protocol Stack Reference Model Showing the G-ACh
图13：显示G-ACh的PWE3协议栈参考模型
PW-associated channel messages are encapsulated using the PWE3 encapsulation, so that they are handled and processed in the same manner (or in some cases, an analogous manner) as the PW PDUs for which they provide a control channel.
PW关联的通道消息使用PWE3封装进行封装，以便以与它们提供控制通道的PW PDU相同的方式（或在某些情况下，以类似的方式）处理和处理它们。
Figure 14 shows the reference model depicting how the control channel is associated with the LSP protocol stack.
图14显示了描述控制信道如何与LSP协议栈关联的参考模型。
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 14: MPLS Protocol Stack Reference Model Showing the LSP Associated Control Channel
图14：显示LSP相关控制信道的MPLS协议栈参考模型
The MPLS-TP OAM architecture supports a wide range of OAM functions to check continuity, to verify connectivity, to monitor path performance, and to generate, filter, and manage local and remote defect alarms. These functions are applicable to any layer defined within MPLS-TP, i.e., to MPLS-TP sections, LSPs, and PWs.
MPLS-TP OAM体系结构支持广泛的OAM功能，以检查连续性、验证连接性、监控路径性能以及生成、过滤和管理本地和远程缺陷警报。这些功能适用于MPLS-TP中定义的任何层，即MPLS-TP段、LSP和PWs。
The MPLS-TP OAM tool-set is able to operate without relying on a dynamic control plane or IP functionality in the data path. In the case of an MPLS-TP deployment in a network in which IP functionality is available, all existing IP/MPLS OAM functions (e.g., LSP Ping, BFD, and VCCV) may be used. Since MPLS-TP can operate in environments where IP is not used in the forwarding plane, the default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated Channel (Section 3.6). Forwarding based on IP addresses for OAM or user data packets is not required for MPLS-TP.
MPLS-TP OAM工具集能够在不依赖数据路径中的动态控制平面或IP功能的情况下运行。在IP功能可用的网络中部署MPLS-TP的情况下，可以使用所有现有的IP/MPLS OAM功能（例如，LSP Ping、BFD和VCCV）。由于MPLS-TP可以在转发平面中不使用IP的环境中运行，因此MPLS-TP LSP和PWs中OAM解复用的默认机制是通用关联信道（第3.6节）。MPLS-TP不需要基于OAM或用户数据包的IP地址进行转发。
[RFC4379] and BFD for MPLS LSPs [RFC5884] have defined alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when the OAM packets are encapsulated in an IP header. These alert mechanisms are based on TTL expiration and/or use an IP destination address in the range 127/8 for IPv4 and that same range embedded as IPv4-mapped IPv6 addresses for IPv6 [RFC4379]. When the
[RFC4379]和BFD for MPLS LSP[RFC5884]定义了警报机制，使MPLS LSR能够在OAM数据包封装在IP报头中时识别和处理MPLS OAM数据包。这些警报机制基于TTL过期和/或使用IPv4 127/8范围内的IP目标地址，以及与IPv6的IPv4映射IPv6地址相同的嵌入范围[RFC4379]。当
OAM packets are encapsulated in an IP header, these mechanisms are the default mechanisms for MPLS networks (in general) for identifying MPLS OAM packets, although the mechanisms defined in [RFC5586] can also be used. MPLS-TP is able to operate in environments where IP forwarding is not supported, and thus the G-ACh/GAL is the default mechanism to demultiplex OAM packets in MPLS-TP in these environments.
OAM数据包封装在IP报头中，这些机制是MPLS网络（通常）用于识别MPLS OAM数据包的默认机制，尽管也可以使用[RFC5586]中定义的机制。MPLS-TP能够在不支持IP转发的环境中运行，因此G-ACh/GAL是在这些环境中解复用MPLS-TP中的OAM数据包的默认机制。
MPLS-TP supports a comprehensive set of OAM capabilities for packet transport applications, with equivalent capabilities to those provided in SONET/SDH.
MPLS-TP支持用于分组传输应用的一整套OAM功能，其功能与SONET/SDH中提供的功能相当。
MPLS-TP requires [RFC5860] that a set of OAM capabilities is available to perform fault management (e.g., fault detection and localization) and performance monitoring (e.g., packet delay and loss measurement) of the LSP, PW, or section. The framework for OAM in MPLS-TP is specified in [OAM-FRAMEWORK].
MPLS-TP要求[RFC5860]提供一组OAM功能，以执行LSP、PW或段的故障管理（例如，故障检测和定位）和性能监控（例如，数据包延迟和丢失测量）。MPLS-TP中的OAM框架在[OAM-framework]中指定。
MPLS-TP OAM packets share the same fate as their corresponding data packets, and are identified through the Generic Associated Channel mechanism [RFC5586]. This uses a combination of an Associated Channel Header (ACH) and a G-ACh Label (GAL) to create a control channel associated to an LSP, section, or PW.
MPLS-TP OAM数据包与其对应的数据包具有相同的命运，并通过通用关联信道机制[RFC5586]进行识别。这使用关联通道头（ACH）和G-ACH标签（GAL）的组合来创建与LSP、区段或PW关联的控制通道。
OAM and monitoring in MPLS-TP is based on the concept of maintenance entities, as described in [OAM-FRAMEWORK]. A Maintenance Entity (ME) can be viewed as the association of two Maintenance Entity Group End Points (MEPs). A Maintenance Entity Group (MEG) is a collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group. The MEPs that form an ME limit the OAM responsibilities of an OAM flow to within the domain of a transport path or segment, in the specific layer network that is being monitored and managed.
MPLS-TP中的OAM和监视基于维护实体的概念，如[OAM-FRAMEWORK]中所述。维修实体（ME）可被视为两个维修实体组端点（MEP）的关联。维护实体组（MEG）是属于同一传输路径并作为一个组进行维护和监控的一个或多个MEs的集合。构成ME的MEP将OAM流的OAM责任限制在被监视和管理的特定层网络中的传输路径或段的域内。
A MEG may also include a set of Maintenance Entity Group Intermediate Points (MIPs).
MEG还可包括一组维护实体组中间点（MIP）。
A G-ACh packet may be directed to an individual MIP along the path of an LSP or MS-PW by setting the appropriate TTL in the label stack entry for the G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and the vccv-trace mode of [SEGMENTED-PW]. Note that this works when the location of MIPs along the LSP or PW path is known by the MEP. There may be circumstances where this is not the case, e.g., following restoration using a facility bypass LSP. In these cases, tools to trace the path of the LSP may be used to determine the appropriate setting for the TTL to reach a specific MIP.
根据LSP Ping[RFC4379]的跟踪路由模式和[SEGMENTED-PW]的vccv跟踪模式，通过在G-ACh分组的标签栈条目中设置适当的TTL，可以将G-ACh分组定向到沿着LSP或MS-PW的路径的单个MIP。请注意，当MEP知道沿LSP或PW路径的MIP位置时，这种方法有效。在某些情况下可能并非如此，例如，在使用设施旁路LSP进行恢复之后。在这些情况下，可以使用跟踪LSP路径的工具来确定TTL到达特定MIP的适当设置。
Within an LSR or PE, MEPs and MIPs can only be placed where MPLS layer processing is performed on a packet. The MPLS architecture mandates that MPLS layer processing occurs at least once on an LSR.
在LSR或PE中，MEP和MIPs只能放置在对数据包执行MPLS层处理的位置。MPLS体系结构要求在LSR上至少进行一次MPLS层处理。
Any node on an LSP can send an OAM packet on that LSP. Likewise, any node on a PW can send OAM packets on a PW, including S-PEs.
LSP上的任何节点都可以在该LSP上发送OAM数据包。同样，PW上的任何节点都可以在PW上发送OAM数据包，包括S-PEs。
An OAM packet can only be received to be processed at an LSP endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the LSP or PW label stack entry.
OAM数据包只能在LSP端点、PW端点（T-PE）或LSP或PW标签堆栈项中的TTL到期时接收以进行处理。
Management, control, and OAM protocol functions may require response packets to be delivered from the receiver back to the originator of a message exchange. This section provides a summary of the return path options in MPLS-TP networks. Although this section describes the case of an MPLS-TP LSP, it is also applicable to a PW.
管理、控制和OAM协议功能可能需要将响应数据包从接收方发送回消息交换的发起方。本节概述MPLS-TP网络中的返回路径选项。尽管本节描述了MPLS-TP LSP的情况，但它也适用于PW。
In this description, U and D are LSRs that terminate MPLS-TP LSPs (i.e., LERs), and Y is an intermediate LSR along the LSP. Note that U is the upstream LER, and D is the downstream LER with respect to a particular direction of an LSP. This reference model is shown in Figure 15.
在该描述中，U和D是终止MPLS-TP LSP（即，ler）的LSR，Y是沿着LSP的中间LSR。注意，U是上游LER，D是相对于LSP特定方向的下游LER。该参考模型如图15所示。
LSP LSP
LSP
U ========= Y ========= D
U ========= Y ========= D
LER LSR LER
LER-LSR-LER
---------> Direction of user traffic flow
---------> Direction of user traffic flow
Figure 15: Return Path Reference Model
图15：返回路径参考模型
The following cases are described for the various types of LSPs:
针对各种类型的LSP，描述了以下情况：
Case 1 Return path packet transmission from D to U
案例1从D到U的返回路径数据包传输
Case 2 Return path packet transmission from Y to U
案例2从Y到U的返回路径数据包传输
Case 3 Return path packet transmission from D to Y
案例3从D到Y的返回路径数据包传输
Note that a return path may not always exist (or may exist but be disabled), and that packet transmission in one or more of the above cases may not be possible. In general, the existence and nature of return paths for MPLS-TP LSPs is determined by operational provisioning.
注意，返回路径可能并不总是存在（或者可能存在但被禁用），并且在上述一种或多种情况下可能不可能进行分组传输。通常，MPLS-TP LSP的返回路径的存在和性质由操作资源调配决定。
There are two types of return path that may be used for the delivery of traffic from a downstream node D to an upstream node U. Either:
有两种类型的返回路径可用于从下游节点D向上游节点U传送业务。或者：
a. The LSP between U and D is bidirectional, and therefore D has a path via the MPLS-TP LSP to return traffic back to U, or
a. U和D之间的LSP是双向的，因此D有一条通过MPLS-TP LSP将流量返回给U的路径，或者
b. D has some other unspecified means of directing traffic back to U.
b. D还有其他一些未指明的方法将交通引导回美国。
The first option is referred to as an "in-band" return path, the second as an "out-of-band" return path.
第一个选项称为“带内”返回路径，第二个选项称为“带外”返回路径。
There are various possibilities for "out-of-band" return paths. Such a path may, for example, be based on ordinary IP routing. In this case, packets would be forwarded as usual to a destination IP address associated with U. In an MPLS-TP network that is also an IP/MPLS network, such a forwarding path may traverse the same physical links or logical transport paths used by MPLS-TP. An out-of-band return path may also be indirect, via a distinct Data Communication Network (DCN) (provided, for example, by the method specified in [RFC5718]); or it may be via one or more other MPLS-TP LSPs.
“带外”返回路径有多种可能性。例如，这样的路径可以基于普通IP路由。在这种情况下，分组将像往常一样转发到与U相关联的目的地IP地址。在也是IP/MPLS网络的MPLS-TP网络中，这样的转发路径可以穿过MPLS-TP使用的相同物理链路或逻辑传输路径。带外返回路径也可以是间接的，通过不同的数据通信网络（DCN）（例如，通过[RFC5718]中规定的方法提供）；或者可以通过一个或多个其他MPLS-TP LSP。
Case 1 If an in-band return path is required to deliver traffic from D back to U, it is recommended for reasons of operational simplicity that point-to-point unidirectional LSPs be provisioned as associated bidirectional LSPs (which may also be co-routed) whenever return traffic from D to U is required. Note that the two directions of such an LSP may have differing bandwidth allocations and QoS characteristics. The discussion below for such LSPs applies.
情况1如果需要带内返回路径来将业务从D传送回U，则出于操作简单性的原因，建议在需要从D传送回U时，将点对点单向LSP提供为相关联的双向LSP（也可以是共路由的）。注意，这样的LSP的两个方向可以具有不同的带宽分配和QoS特性。以下讨论适用于此类LSP。
As an alternative, an out-of-band return path may be used.
作为替代方案，可以使用带外返回路径。
Case 2 In this case, only the out-of-band return path option is available. However, an additional out-of-band possibility is worthy of note here: if D is known to have a return path to U, then Y can arrange to deliver return traffic to U by first sending it to D along the original LSP. The mechanism by which D recognizes the need for and performs this forwarding operation is protocol specific.
案例2在这种情况下，只有带外返回路径选项可用。然而，这里值得注意的是另外一种带外可能性：如果已知D有到U的返回路径，那么Y可以通过首先沿原始LSP将返回流量发送到D来安排向U发送返回流量。D识别并执行此转发操作的机制是特定于协议的。
Case 3 In this case, only the out-of-band return path option is available. However, if D has a return path to U, then (in a manner analogous to the previous case) D can arrange to
案例3在这种情况下，只有带外返回路径选项可用。然而，如果D有一个到U的返回路径，那么（以类似于前一种情况的方式）D可以安排
deliver return traffic to Y by first sending it to U along that return path. The mechanism by which U recognizes the need for and performs this forwarding operation is protocol specific.
通过首先沿返回路径将返回流量发送给U，将返回流量发送给Y。U识别并执行此转发操作的机制是特定于协议的。
For Case 1, D has a natural in-band return path to U, the use of which is typically preferred for return traffic, although out-of-band return paths are also applicable.
对于情况1，D具有到U的自然带内返回路径，虽然带外返回路径也适用，但对于返回业务通常首选使用该路径。
For Cases 2 and 3, the considerations are the same as those for point-to-point unidirectional LSPs.
对于情况2和3，考虑事项与点对点单向LSP相同。
For all of Cases 1, 2, and 3, a natural in-band return path exists in the form of the LSP itself, and its use is preferred for return traffic. Out-of-band return paths, however, are also applicable, primarily as an alternative means of delivery in case the in-band return path has failed.
对于所有情况1、2和3，自然带内返回路径以LSP本身的形式存在，并且其用于返回业务是优选的。然而，带外返回路径也适用，主要作为带内返回路径发生故障时的替代交付方式。
A distributed dynamic control plane may be used to enable dynamic service provisioning in an MPLS-TP network. Where the requirements specified in [RFC5654] can be met, the MPLS Transport Profile uses existing standard control-plane protocols for LSPs and PWs.
分布式动态控制平面可用于在MPLS-TP网络中实现动态服务供应。如果可以满足[RFC5654]中规定的要求，MPLS传输配置文件将使用LSP和PWs的现有标准控制平面协议。
Note that a dynamic control plane is not required in an MPLS-TP network. See Section 3.11 for further details on statically configured and provisioned MPLS-TP services.
注意，MPLS-TP网络中不需要动态控制平面。有关静态配置和提供的MPLS-TP服务的更多详细信息，请参见第3.11节。
Figure 16 illustrates the relationship between the MPLS-TP control plane, the forwarding plane, the management plane, and OAM for point-to-point MPLS-TP LSPs or PWs.
图16说明了点对点MPLS-TP LSP或PWs的MPLS-TP控制平面、转发平面、管理平面和OAM之间的关系。
+------------------------------------------------------------------+
| |
| Network Management System and/or |
| |
| Control Plane for Point-to-Point Connections |
| |
+------------------------------------------------------------------+
| | | | | |
.............|.....|... ....|.....|.... ....|.....|............
: +---+ | : : +---+ | : : +---+ | :
: |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
/: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
+------------------------------------------------------------------+
| |
| Network Management System and/or |
| |
| Control Plane for Point-to-Point Connections |
| |
+------------------------------------------------------------------+
| | | | | |
.............|.....|... ....|.....|.... ....|.....|............
: +---+ | : : +---+ | : : +---+ | :
: |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
/: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: 1) NMS may be centralized or distributed. Control plane is distributed. 2) 'Edge' functions refers to those functions present at the edge of a PSN domain, e.g., native service processing or classification. 3) The control plane may be transported over the server layer, an LSP, or a G-ACh.
注：1）网管可以是集中式的，也可以是分布式的。控制平面是分布式的。2） “边缘”功能是指存在于PSN域边缘的那些功能，例如本机服务处理或分类。3） 控制平面可以在服务器层、LSP或G-ACh上传输。
Figure 16: MPLS-TP Control Plane Architecture Context
图16:MPLS-TP控制平面架构上下文
The MPLS-TP control plane is based on existing MPLS and PW control plane protocols, and is consistent with the Automatically Switched Optical Network (ASON) architecture [G.8080]. MPLS-TP uses:
MPLS-TP控制平面基于现有的MPLS和PW控制平面协议，并与自动交换光网络（ASON）架构一致[G.8080]。MPLS-TP使用：
o Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473]) for LSPs, and
o LSP的通用MPLS（GMPLS）信令（[RFC3945]、[RFC3471]、[RFC3473]），以及
o Targeted LDP (T-LDP) signaling ([RFC4447], [SEGMENTED-PW], [DYN-MS-PW]) for pseudowires.
o 针对伪线的目标LDP（T-LDP）信令（[RFC4447]、[SEGMENTED-PW]、[DYN-MS-PW]）。
MPLS-TP requires that any control-plane traffic be capable of being carried over an out-of-band signaling network or a signaling control channel such as the one described in [RFC5718]. Note that while T-LDP signaling is traditionally carried in-band in IP/MPLS networks, this does not preclude its operation over out-of-band channels. References to T-LDP in this document do not preclude the definition of alternative PW control protocols for use in MPLS-TP.
MPLS-TP要求任何控制平面业务能够通过带外信令网络或信令控制信道（如[RFC5718]中所述）进行。注意，虽然传统上在IP/MPLS网络中T-LDP信令在带内进行，但这并不排除其在带外信道上的操作。本文件中对T-LDP的引用并不排除MPLS-TP中使用的替代PW控制协议的定义。
PW control (and maintenance) takes place separately from LSP tunnel signaling. The main coordination between LSP and PW control will occur within the nodes that terminate PWs. The control planes for PWs and LSPs may be used independently, and one may be employed without the other. This translates into the 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. The PW and LSP control planes, collectively, need to satisfy the MPLS-TP control plane requirements reviewed in the MPLS-TP Control Plane Framework [CP-FRAMEWORK]. 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 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.
PW控制（和维护）与LSP隧道信令分开进行。LSP和PW控制之间的主要协调将发生在终止PWs的节点内。PWs和LSP的控制平面可以单独使用，一个可以不使用另一个。这转化为四种可能的情况：（1）不使用控制平面；（2） LSP和PWs均使用控制平面；（3） 控制平面用于LSP，但不用于PWs；（4） 控制平面用于PWs，但不用于LSP。PW和LSP控制平面共同需要满足MPLS-TP控制平面框架[CP-Framework]中审查的MPLS-TP控制平面要求。当通过LSP直接提供客户服务时，LSP控制平面必须满足所有要求。当通过PWs提供客户服务时，PW和LSP控制平面组合运行，一些功能可能通过PW控制平面得到满足，而其他功能则由LSP控制平面提供给PWs。
Note that if MPLS-TP is being used in a multi-layer network, a number of control protocol types and instances may be used. This is consistent with the MPLS architecture, which permits each label in the label stack to be allocated and signaled by its own control protocol.
注意，如果在多层网络中使用MPLS-TP，则可以使用许多控制协议类型和实例。这与MPLS体系结构一致，MPLS体系结构允许标签堆栈中的每个标签由其自己的控制协议进行分配和发送信号。
The distributed MPLS-TP control plane may provide the following functions:
分布式MPLS-TP控制平面可以提供以下功能：
o Signaling
o 信号
o Routing
o 路由
o Traffic engineering and constraint-based path computation
o 交通工程与基于约束的路径计算
In a multi-domain environment, the MPLS-TP control plane supports different types of interfaces at domain boundaries or within the domains. These include the User-Network Interface (UNI), Internal Network-Network Interface (I-NNI), and External Network-Network Interface (E-NNI). Note that different policies may be defined that control the information exchanged across these interface types.
在多域环境中，MPLS-TP控制平面在域边界或域内支持不同类型的接口。这些包括用户网络接口（UNI）、内部网络接口（I-NNI）和外部网络接口（E-NNI）。注意，可以定义不同的策略来控制这些接口类型之间交换的信息。
The MPLS-TP control plane is capable of activating MPLS-TP OAM functions as described in the OAM section of this document Section 3.7, e.g., for fault detection and localization in the event of a failure in order to efficiently restore failed transport paths.
MPLS-TP控制平面能够激活本文件第3.7节OAM部分所述的MPLS-TP OAM功能，例如，在发生故障时进行故障检测和定位，以便有效恢复故障传输路径。
The MPLS-TP control plane supports all MPLS-TP data-plane connectivity patterns that are needed for establishing transport paths, including protected paths as described in Section 3.12.
MPLS-TP控制平面支持建立传输路径所需的所有MPLS-TP数据平面连接模式，包括第3.12节所述的受保护路径。
Examples of the MPLS-TP data-plane connectivity patterns are LSPs utilizing the fast reroute backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or 1:1 protected LSPs.
MPLS-TP数据平面连接模式的示例是使用[RFC4090]中定义的快速重路由备份方法的LSP和入口到出口1+1或1:1保护的LSP。
The MPLS-TP control plane provides functions to ensure its own survivability and to enable it to recover gracefully from failures and degradations. These include graceful restart and hot redundant configurations. Depending on how the control plane is transported, varying degrees of decoupling between the control plane and data plane may be achieved. In all cases, however, the control plane is logically decoupled from the data plane such that a control-plane failure does not imply a failure of the existing transport paths.
MPLS-TP控制平面提供了确保其自身生存能力的功能，并使其能够从故障和降级中正常恢复。这些包括优雅的重启和热冗余配置。根据控制平面的传输方式，可以实现控制平面和数据平面之间不同程度的解耦。然而，在所有情况下，控制平面从逻辑上与数据平面解耦，使得控制平面故障并不意味着现有传输路径的故障。
A number of methods exist to support inter-domain operation of MPLS-TP, including the data-plane, OAM, and configuration aspects, for example:
存在许多方法来支持MPLS-TP的域间操作，包括数据平面、OAM和配置方面，例如：
o Inter-domain TE LSPs [RFC4726]
o 域间TE LSP[RFC4726]
o Multi-segment Pseudowires [RFC5659]
o 多段伪导线[RFC5659]
o LSP stitching [RFC5150]
o LSP缝合[RFC5150]
o Back-to-back attachment circuits [RFC5659]
o 背靠背连接电路[RFC5659]
An important consideration in selecting an inter-domain connectivity mechanism is the degree of layer network isolation and types of OAM required by the operator. The selection of which technique to use in a particular deployment scenario is outside the scope of this document.
选择域间连接机制时的一个重要考虑因素是层网络隔离的程度和运营商所需的OAM类型。在特定部署场景中使用哪种技术的选择超出了本文档的范围。
A PW or LSP may be statically configured without the support of a dynamic control plane. This may be either by direct configuration of the PEs/LSRs or via a network management system. Static operation is independent for a specific PW or LSP instance. Thus, it should be possible for a PW to be statically configured, while the LSP supporting it is set up by a dynamic control plane. When static configuration mechanisms are used, care must be taken to ensure that loops are not created. Note that the path of an LSP or PW may be dynamically computed, while the LSP or PW itself is established through static configuration.
PW或LSP可以在没有动态控制平面支持的情况下静态配置。这可以通过直接配置PEs/LSR或通过网络管理系统实现。静态操作对于特定PW或LSP实例是独立的。因此，PW应该可以静态配置，而支持它的LSP由动态控制平面设置。使用静态配置机制时，必须注意确保不创建循环。注意，LSP或PW的路径可以动态计算，而LSP或PW本身是通过静态配置建立的。
The survivability architecture for MPLS-TP is specified in [SURVIVE-FWK].
MPLS-TP的生存性体系结构在[SURVIVE-FWK]中规定。
A wide variety of resiliency schemes have been developed to meet the various network and service survivability objectives. For example, as part of the MPLS/PW paradigms, MPLS provides methods for local repair using back-up LSP tunnels ([RFC4090]), while pseudowire redundancy [PW-REDUNDANCY] supports scenarios where the protection for the PW cannot be fully provided by the underlying LSP (i.e., where the backup PW terminates on a different target PE node than the working PW in dual-homing scenarios, or where protection of the S-PE is required). Additionally, GMPLS provides a well-known set of control-plane-driven protection and restoration mechanisms [RFC4872]. MPLS-TP provides additional protection mechanisms that are optimized for both linear topologies and ring topologies and that operate in the absence of a dynamic control plane. These are specified in [SURVIVE-FWK].
为了满足各种网络和服务生存性目标，已经开发了各种各样的恢复方案。例如，作为MPLS/PW范例的一部分，MPLS提供了使用备用LSP隧道（[RFC4090]）进行本地修复的方法，而伪线冗余[PW-redundancy]支持无法完全由底层LSP提供PW保护的场景（即，在双归宿场景中，备份PW终止于与工作PW不同的目标PE节点，或者需要保护S-PE）。此外，GMPLS提供了一套众所周知的控制平面驱动的保护和恢复机制[RFC4872].MPLS-TP提供了额外的保护机制，这些机制针对线性拓扑和环形拓扑进行了优化，并在没有动态控制平面的情况下运行。这些机制在[SURVIVE-FWK]中规定。
Different protection schemes apply to different deployment topologies and operational considerations. Such protection schemes may provide different levels of resiliency, for example:
不同的保护方案适用于不同的部署拓扑和操作考虑。此类保护方案可提供不同级别的弹性，例如：
o two concurrent traffic paths (1+1).
o 两条并发通信路径（1+1）。
o one active and one standby path with guaranteed bandwidth on both paths (1:1).
o 一条活动路径和一条备用路径，两条路径上的带宽都有保证（1:1）。
o one active path and a standby path the resources of which are shared by one or more other active paths (shared protection).
o 一个活动路径和一个备用路径，其资源由一个或多个其他活动路径共享（共享保护）。
The applicability of any given scheme to meet specific requirements is outside the scope of this document.
任何给定方案满足特定要求的适用性不在本文件范围内。
The characteristics of MPLS-TP resiliency mechanisms are as follows:
MPLS-TP弹性机制的特点如下：
o Optimized for linear, ring, or meshed topologies.
o 针对线性、环形或网状拓扑进行了优化。
o Use OAM mechanisms to detect and localize network faults or service degenerations.
o 使用OAM机制来检测和定位网络故障或服务退化。
o Include protection mechanisms to coordinate and trigger protection switching actions in the absence of a dynamic control plane.
o 包括在没有动态控制平面的情况下协调和触发保护切换动作的保护机制。
o MPLS-TP recovery schemes are applicable to all levels in the MPLS-TP domain (i.e., section, LSP, and PW) providing segment and end-to-end recovery.
o MPLS-TP恢复方案适用于MPLS-TP域中的所有级别（即区段、LSP和PW），提供段和端到端恢复。
o MPLS-TP recovery mechanisms support the coordination of protection switching at multiple levels to prevent race conditions occurring between a client and its server layer.
o MPLS-TP恢复机制支持在多个级别上协调保护切换，以防止在客户端及其服务器层之间发生竞争情况。
o MPLS-TP recovery mechanisms can be data-plane, control-plane, or management-plane based.
o MPLS-TP恢复机制可以是基于数据平面、控制平面或管理平面的。
o MPLS-TP supports revertive and non-revertive behavior.
o MPLS-TP支持还原和非还原行为。
In order to monitor, protect, and manage a portion (i.e., segment or concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be instantiated. A hierarchical LSP instantiated for this purpose is called a Sub-Path Maintenance Element (SPME). Note that by definition an SPME does not carry user traffic as a direct client.
为了监视、保护和管理LSP的一部分（即段或连接段），可以实例化分层LSP[RFC3031]。为此目的而实例化的分层LSP称为子路径维护元素（SPME）。请注意，根据定义，SPME不作为直接客户端承载用户流量。
An SPME is defined between the edges of the portion of the LSP that needs to be monitored, protected or managed. The SPME forms an MPLS-TP Section [DATA-PLANE] that carries the original LSP over this portion of the network as a client. OAM messages can be initiated at the edge of the SPME and sent to the peer edge of the SPME or to a MIP along the SPME by setting the TTL value of the LSE at the corresponding hierarchical LSP level. A P router only pushes or pops a label if it is at the end of a SPME. In this mode, it is an LER for the SPME.
SPME定义在需要监控、保护或管理的LSP部分的边缘之间。SPME形成一个MPLS-TP段[数据平面]，作为客户端在网络的这一部分承载原始LSP。OAM消息可以在SPME的边缘启动，并通过在相应的分层LSP级别设置LSE的TTL值，发送到SPME的对等边缘或沿着SPME发送到MIP。P路由器仅在SPME末尾推送或弹出标签。在此模式下，它是SPME的LER。
For example, in Figure 17, two SPMEs are configured to allow monitoring, protection, and management of the LSP concatenated segments. One SPME is defined between LER2 and LER3, and a second SPME is set up between LER4 and LER5. Each of these SPMEs may be monitored, protected, or managed independently.
例如，在图17中，两个SPME配置为允许监控、保护和管理LSP连接段。在LER2和LER3之间定义一个SPME，在LER4和LER5之间设置第二个SPME。每个SPME都可以独立地进行监控、保护或管理。
|<============================= LSP =============================>|
|<============================= LSP =============================>|
|<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
|<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
|LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6|
|LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6|
|====== SPME =========| |====== SPME =========|
(Carrier 1) (Carrier 2)
|====== SPME =========| |====== SPME =========|
(Carrier 1) (Carrier 2)
Note 1: LER2, LER3, LER4, and LER5 are with respect to the SPME, but LSRs with respect to the LSP. Note 2: The LSP terminates in LERs outside of Carrier 1 and Carrier 2, for example, LER1 and LER6.
注1：LER2、LER3、LER4和LER5与SPME有关，但LSR与LSP有关。注2：LSP终止于载波1和载波2之外的LER，例如，LER1和LER6。
Figure 17: SPMEs in Inter-Carrier Network
图17：载波间网络中的SPME
The end-to-end traffic of the LSP, including data traffic and control traffic (OAM, Protection Switching Control, management and signaling messages) is tunneled within the hierarchical LSP by means of label stacking as defined in [RFC3031].
LSP的端到端通信量，包括数据通信量和控制通信量（OAM、保护交换控制、管理和信令消息），通过[RFC3031]中定义的标签堆叠在分层LSP中进行隧道传输。
The mapping between an LSP and a SPME can be 1:1, in which case it is similar to the ITU-T Tandem Connection Element [G.805]. The mapping can also be 1:N to allow aggregated monitoring, protection, and management of a set of LSP segments or concatenated LSP segments. Figure 18 shows a SPME that is used to aggregate a set of concatenated LSP segments for the LSP from LERx to LERt and the LSP from LERa to LERd. Note that such a construct is useful, for example, when the LSPs traverse a common portion of the network and they have the same Traffic Class.
LSP和SPME之间的映射可以是1:1，在这种情况下，它类似于ITU-T串联连接元件[G.805]。映射也可以是1:N，以允许对一组LSP段或连接的LSP段进行聚合监视、保护和管理。图18显示了一个SPME，用于为从LERx到LERt的LSP和从LERa到LERd的LSP聚合一组连接的LSP段。注意，例如，当LSP穿过网络的公共部分并且它们具有相同的通信量类别时，这样的构造是有用的。
The QoS aspects of a SPME are network specific. [OAM-FRAMEWORK] provides further considerations on the QoS aspects of OAM.
SPME的QoS方面是特定于网络的。[OAM-FRAMEWORK]提供了关于OAM的QoS方面的进一步考虑。
|LERx|--|LSRy|-+ +-|LSRz|--|LERt|
| |
| |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+
|LER1 | |LSR| |LSR| |LER2 |
+--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ |
| |============ SPME ==============| |
|LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
|LERx|--|LSRy|-+ +-|LSRz|--|LERt|
| |
| |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+
|LER1 | |LSR| |LSR| |LER2 |
+--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ |
| |============ SPME ==============| |
|LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
Figure 18: SPME for a Set of Concatenated LSP Segments
图18：一组串联LSP段的SPME
SPMEs can be provisioned either statically or using control-plane signaling procedures. The make-before-break procedures which are supported by MPLS allow the creation of a SPME on existing LSPs in-service without traffic disruption, as described in [SURVIVE-FWK]. A SPME can be defined corresponding to one or more end-to-end LSPs. New end-to-end LSPs that are tunneled within the SPME can be set up, which may require coordination across administrative boundaries. Traffic of the existing LSPs is switched over to the new end-to-end tunneled LSPs. The old end-to-end LSPs can then be torn down.
可以静态地或使用控制平面信令过程来供应SPME。MPLS支持的先通后断过程允许在现有LSP上创建SPME，而不会造成流量中断，如[SURVIVE-FWK]中所述。可以对应于一个或多个端到端LSP定义SPME。可以在SPME内设置隧道的新端到端LSP，这可能需要跨管理边界进行协调。现有LSP的流量切换到新的端到端隧道LSP。然后可以拆下旧的端到端LSP。
Hierarchical label stacking, in a similar manner to that described above, can be used to implement Sub-Path Maintenance Elements on pseudowires, as described in [OAM-FRAMEWORK].
如[OAM-FRAMEWORK]中所述，以与上述类似的方式，分层标签堆叠可用于在伪线上实现子路径维护元素。
The network management architecture and requirements for MPLS-TP are specified in [NM-FRAMEWORK] and [NM-REQ]. These derive from the generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. They also incorporate the OAM requirements for MPLS Networks [RFC4377] and MPLS-TP Networks [RFC5860] and expand on those requirements to cover the modifications necessary for fault, configuration, performance, and security in a transport network.
MPLS-TP的网络管理架构和要求在[NM-FRAMEWORK]和[NM-REQ]中有详细说明。这些规范源自ITU-T G.7710/Y.1701[G.7710]中描述的传输技术通用规范。它们还结合了MPLS网络[RFC4377]和MPLS-TP网络[RFC5860]的OAM要求，并对这些要求进行了扩展，以涵盖传输网络中故障、配置、性能和安全性所需的修改。
The Equipment Management Function (EMF) of an MPLS-TP Network Element (NE) (i.e., LSR, LER, PE, S-PE, or T-PE) provides the means through which a management system manages the NE. The Management Communication Channel (MCC), realized by the G-ACh, provides a logical operations channel between NEs for transferring management information. The Network Management System (NMS) can be used to provision and manage an end-to-end connection across a network. Maintenance operations are run on a connection (LSP or PW) in a manner that is independent of the provisioning mechanism. Segments may be created or managed by, for example, Netconf [RFC4741], SNMP [RFC3411], or CORBA (Common Object Request Broker Architecture) interfaces, but not all segments need to be created or managed using the same type of interface. Where an MPLS-TP NE is managed by an NMS, at least one of these standard management mechanisms is required for interoperability, but this document imposes no restriction on which of these standard management protocols is used. In MPLS-TP, the EMF needs to support statically provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any associated MEPs and MIPs, as per Section 3.11.
MPLS-TP网元（即，LSR、LER、PE、S-PE或T-PE）的设备管理功能（EMF）提供了管理系统管理网元的手段。由G-ACh实现的管理通信信道（MCC）在网元之间提供逻辑操作信道，用于传输管理信息。网络管理系统（NMS）可用于提供和管理跨网络的端到端连接。维护操作以独立于配置机制的方式在连接（LSP或PW）上运行。段可以由例如Netconf[RFC4741]、SNMP[RFC3411]或CORBA（公共对象请求代理体系结构）接口创建或管理，但并非所有段都需要使用相同类型的接口创建或管理。如果MPLS-TP网元由NMS管理，则互操作性至少需要这些标准管理机制中的一个，但本文档对使用这些标准管理协议中的哪一个没有限制。在MPLS-TP中，根据第3.11节，EMF需要支持LSR或LER的静态配置LSP，PE的PWs，以及任何相关的MEP和MIP。
Fault Management (FM) functions within the EMF of an MPLS-TP NE enable the supervision, detection, validation, isolation, correction, and alarm handling of abnormal conditions in the MPLS-TP network and its environment. FM needs to provide for the supervision of transmission (such as continuity, connectivity, etc.), software processing, hardware, and environment. Alarm handling includes alarm severity assignment, alarm suppression/aggregation/correlation, alarm reporting control, and alarm reporting.
MPLS-TP网元的EMF中的故障管理（FM）功能能够对MPLS-TP网络及其环境中的异常情况进行监视、检测、验证、隔离、纠正和报警处理。FM需要提供对传输（如连续性、连接性等）、软件处理、硬件和环境的监督。报警处理包括报警严重性分配、报警抑制/聚合/关联、报警报告控制和报警报告。
Configuration Management (CM) provides functions to control, identify, collect data from, and provide data to MPLS-TP NEs. In addition to general configuration for hardware, software protection switching, alarm reporting control, and date/time setting, the EMF of the MPLS-TP NE also supports the configuration of maintenance entity identifiers (such as Maintenance Entity Group Endpoint (MEP) ID and MEG Intermediate Point (MIP) ID). The EMF also supports the configuration of OAM parameters as a part of connectivity management to meet specific operational requirements. These may specify whether
配置管理（CM）提供控制、识别、从MPLS-TP网元收集数据以及向MPLS-TP网元提供数据的功能。除了硬件、软件保护切换、报警报告控制和日期/时间设置的一般配置外，MPLS-TP网元的EMF还支持维护实体标识符（如维护实体组端点（MEP）ID和MEG中间点（MIP）ID）的配置。EMF还支持将OAM参数的配置作为连接管理的一部分，以满足特定的操作需求。这些可能会说明
the operational mode is one-time on-demand or is periodic at a specified frequency.
操作模式为一次性按需或以指定频率周期性。
The Performance Management (PM) functions within the EMF of an MPLS-TP NE support the evaluation and reporting of the behavior of the NEs and the network. One particular requirement for PM is to provide coherent and consistent interpretation of the network behavior in a hybrid network that uses multiple transport technologies. Packet loss measurement and delay measurements may be collected and used to detect performance degradation. This is reported via fault management to enable corrective actions to be taken (e.g., protection switching) and via performance monitoring for Service Level Agreement (SLA) verification and billing. Collection mechanisms for performance data should be capable of operating on-demand or proactively.
MPLS-TP网元的EMF中的性能管理（PM）功能支持对网元和网络的行为进行评估和报告。PM的一个特殊要求是，在使用多种传输技术的混合网络中，对网络行为提供连贯一致的解释。分组丢失测量和延迟测量可被收集并用于检测性能退化。这通过故障管理报告，以便采取纠正措施（例如，保护切换），并通过服务水平协议（SLA）验证和计费的性能监控报告。性能数据的收集机制应能够按需或主动操作。
The introduction of MPLS-TP into transport networks means that the security considerations applicable to both MPLS [RFC3031] and PWE3 [RFC3985] apply to those transport networks. When an MPLS function is included in the MPLS transport profile, the security considerations pertinent to that function apply to MPLS-TP. Furthermore, when general MPLS networks that utilize functionality outside of the strict MPLS Transport Profile are used to support packet transport services, the security considerations of that additional functionality also apply.
将MPLS-TP引入传输网络意味着适用于MPLS[RFC3031]和PWE3[RFC3985]的安全注意事项适用于这些传输网络。当MPLS传输配置文件中包含MPLS功能时，与该功能相关的安全注意事项适用于MPLS-TP。此外，当利用严格MPLS传输配置文件之外的功能的一般MPLS网络用于支持分组传输服务时，该附加功能的安全考虑也适用。
For pseudowires, the security considerations of [RFC3985] and [RFC5659] apply.
对于伪线，[RFC3985]和[RFC5659]的安全注意事项适用。
MPLS-TP nodes that implement the G-ACh create a Control Channel (CC) associated with a pseudowire, LSP, or section. This control channel can be signaled or statically configured. Over this control channel, control channel messages related to network maintenance functions such as OAM, signaling, or network management are sent. Therefore, three different areas are of concern from a security standpoint.
实现G-ACh的MPLS-TP节点创建与伪线、LSP或段相关联的控制信道（CC）。此控制通道可通过信号发送或静态配置。通过该控制信道，发送与网络维护功能（如OAM、信令或网络管理）相关的控制信道消息。因此，从安全角度来看，有三个不同的领域值得关注。
The first area of concern relates to control plane parameter and status message attacks, that is, attacks that concern the signaling of G-ACh capabilities. MPLS-TP Control Plane security is discussed in [RFC5920].
第一个关注领域涉及控制平面参数和状态消息攻击，即涉及G-ACh能力信令的攻击。[RFC5920]中讨论了MPLS-TP控制平面安全性。
A second area of concern centers on data-plane attacks, that is, attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh mechanisms are subject to additional data-plane denial-of-service attacks as follows:
第二个关注领域是数据平面攻击，即对G-ACh本身的攻击。实现G-ACh机制的MPLS-TP节点会受到以下额外的数据平面拒绝服务攻击：
An intruder could intercept or inject G-ACh packets effectively disrupting the protocols carried over the G-ACh.
入侵者可以截获或注入G-ACh数据包，从而有效地破坏G-ACh上的协议。
An intruder could deliberately flood a peer MPLS-TP node with G-ACh messages to deny services to others.
入侵者可能故意向对等MPLS-TP节点发送G-ACh消息，以拒绝向其他节点提供服务。
A misconfigured or misbehaving device could inadvertently flood a peer MPLS-TP node with G-ACh messages that could result in denial of services. In particular, if a node has either implicitly or explicitly indicated that it cannot support one or all of the types of G-ACh protocol, but is sent those messages in sufficient quantity, it could result in a denial of service.
配置错误或行为不当的设备可能会无意中向对等MPLS-TP节点发送G-ACh消息，从而导致拒绝服务。特别是，如果一个节点隐式或显式地表示它不能支持一种或所有类型的G-ACh协议，但发送了足够数量的这些消息，则可能导致拒绝服务。
To protect against these potential (deliberate or unintentional) attacks, multiple mitigation techniques can be employed:
为防止这些潜在（故意或无意）攻击，可采用多种缓解技术：
G-ACh message throttling mechanisms can be used, especially in distributed implementations that have a centralized control-plane processor with various line cards attached by some control-plane data path. In these architectures, G-ACh messages may be processed on the central processor after being forwarded there by the receiving line card. In this case, the path between the line card and the control processor may become saturated if appropriate G-ACh traffic throttling is not employed, which could lead to a complete denial of service to users of the particular line card. Such filtering is also useful for preventing the processing of unwanted G-ACh messages, such as those which are sent on unwanted (and perhaps unadvertised) control channel types.
可以使用G-ACh消息限制机制，特别是在分布式实现中，这些实现具有一个集中控制平面处理器，该处理器具有由一些控制平面数据路径连接的各种线路卡。在这些体系结构中，G-ACh消息在被接收线路卡转发到中央处理器后，可以在中央处理器上进行处理。在这种情况下，如果不采用适当的G-ACh流量节流，线路卡和控制处理器之间的路径可能会饱和，这可能导致对特定线路卡用户的完全拒绝服务。这种过滤对于防止不需要的G-ACh消息的处理也很有用，例如那些在不需要的（也许是未经广告的）控制信道类型上发送的消息。
A third and last area of concern relates to the processing of the actual contents of G-ACh messages. It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security measures.
第三个也是最后一个关注的领域涉及G-ACh消息的实际内容的处理。使用这些通过G-ACh传输的消息的协议定义必须包括适当的安全措施。
Additional security considerations apply to each MPLS-TP solution. These are discussed further in [SEC-FRAMEWORK].
附加的安全注意事项适用于每个MPLS-TP解决方案。这些将在[SEC-FRAMEWORK]中进一步讨论。
The security considerations in [RFC5920] apply.
[RFC5920]中的安全注意事项适用。
IANA considerations resulting from specific elements of MPLS-TP functionality will be detailed in the documents specifying that functionality.
由MPLS-TP功能的特定元素引起的IANA注意事项将在指定该功能的文档中详细说明。
This document introduces no additional IANA considerations in itself.
本文档本身不介绍其他IANA注意事项。
The editors wish to thank the following for their contributions to this document:
编辑们感谢以下各方对本文件的贡献：
o Rahul Aggarwal
o 拉胡尔·阿加瓦尔
o Dieter Beller
o 迪特尔·贝勒
o Malcolm Betts
o 马尔科姆·贝茨
o Italo Busi
o Italo Busi
o John E Drake
o 约翰·德雷克
o Hing-Kam Lam
o 兴鉴林
o Marc Lasserre
o 马克·拉塞尔
o Vincenzo Sestito
o 文琴佐·塞斯蒂托
o Nurit Sprecher
o 努里特斯普雷彻
o Martin Vigoureux
o 马丁·维古鲁
o Yaacov Weingarten
o 亚科夫·温加滕
o The participants of ITU-T SG15
o ITU-T SG15的参与者
[G.7710] ITU-T, "Common equipment management function requirements", ITU-T Recommendation G.7710/Y.1701, July 2007.
[G.7710]ITU-T，“通用设备管理功能要求”，ITU-T建议G.7710/Y.17012007年7月。
[G.805] ITU-T, "Generic Functional Architecture of Transport Networks", ITU-T Recommendation G.805, November 1995.
[G.805]ITU-T，“传输网络的通用功能架构”，ITU-T建议G.805，1995年11月。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[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月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[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., 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.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Rekhter，Y.，和D.Papadimitriou，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Vigoureux，M.，和S.Bryant，“MPLS通用关联信道”，RFC 55862009年6月。
[CP-FRAMEWORK] Andersson, L., Berger, L., Fang, L., Bitar, N., Takacs, A., Vigoureux, M., Bellagamba, E., and E. Gray, "MPLS-TP Control Plane Framework", Work in Progress, March 2010.
[CP-FRAMEWORK]Andersson，L.，Berger，L.，Fang，L.，Bitar，N.，Takacs，A.，Vigoureux，M.，Bellagamba，E.，和E.Gray，“MPLS-TP控制平面框架”，正在进行的工作，2010年3月。
[DATA-PLANE] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", Work in Progress, July 2010.
[DATA-PLANE]Frost，D.，Bryant，S.，和M.Bocci，“MPLS传输配置文件数据平面架构”，正在进行的工作，2010年7月。
[DYN-MS-PW] Martini, L., Bocci, M., Balus, F., Bitar, N., Shah, H., Aissaoui, M., Rusmisel, J., Serbest, Y., Malis, A., Metz, C., McDysan, D., Sugimoto, J., Duckett, M., Loomis, M., Doolan, P., Pan, P., Pate, P., Radoaca, V., Wada, Y., and Y. Seo, "Dynamic Placement of Multi Segment Pseudo Wires", Work in Progress, October 2009.
[DYN-MS-PW]Martini，L.，Bocci，M.，Balus，F.，Bitar，N.，Shah，H.，Aissaoui，M.，Rusmisel，J.，Serbest，Y.，Malis，A.，Metz，C.，McDysan，D.，Sugimoto，J.，Duckett，M.，Lomis，M.，Doolan，P.，Pan，P.，Pate，P.，Radoaca，V.，Wada，Y.，和Y.Seo，“多段伪电线的动态放置”，正在进行中的工作，2009年10月。
[G.8080] ITU-T, "Architecture for the automatically switched optical network (ASON)", ITU-T Recommendation G.8080/Y.1304, 2005.
[G.8080]ITU-T，“自动交换光网络（ASON）的体系结构”，ITU-T建议G.8080/Y.13042005。
[IDENTIFIERS] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", Work in Progress, March 2010.
[标识符]Bocci，M.和G.Swallow，“MPLS-TP标识符”，正在进行的工作，2010年3月。
[NM-FRAMEWORK] Mansfield, S., Ed., Gray, E., Ed., and H. Lam, Ed., "MPLS-TP Network Management Framework", Work in Progress, February 2010.
[NM-FRAMEWORK]Mansfield，S.，Ed.，Gray，E.，Ed.，和H.Lam，Ed.，“MPLS-TP网络管理框架”，正在进行的工作，2010年2月。
[NM-REQ] Mansfield, S. and K. Lam, "MPLS TP Network Management Requirements", Work in Progress, October 2009.
[NM-REQ]Mansfield，S.和K.Lam，“MPLS TP网络管理要求”，正在进行的工作，2009年10月。
[OAM-DEF] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "The OAM Acronym Soup", Work in Progress, June 2010.
[OAM-DEF]Andersson，L.，Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“OAM缩写词汤”，正在进行的工作，2010年6月。
[OAM-FRAMEWORK] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed., "MPLS-TP OAM Framework", Work in Progress, April 2010.
[OAM-FRAMEWORK]Busi，I.，Ed.，Niven Jenkins，B.，Ed.，和D.Allan，Ed.，“MPLS-TP OAM框架”，正在进行的工作，2010年4月。
[PW-REDUNDANCY] Muley, P., "Pseudowire (PW) Redundancy", Work in Progress, May 2010.
[PW-冗余]Muley，P.，“伪线（PW）冗余”，正在进行的工作，2010年5月。
[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月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]Andersson，L.和E.Rosen，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]Enns，R.，“网络配置协议”，RFC 47412006年12月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254]Bitar，N.，Bocci，M.，和L.Martini，“多段伪线仿真边到边（PWE3）的要求”，RFC 5254，2008年10月。
[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, October 2008.
[RFC5309]Shen，N.和A.Zinin，“链路状态路由协议下局域网上的点对点操作”，RFC 5309，2008年10月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[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月。
[RFC5718] Beller, D. and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010.
[RFC5718]Beller，D.和A.Farrel，“MPLS传输模式的带内数据通信网络”，RFC 5718，2010年1月。
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860]Vigoureux，M.，Ward，D.，和M.Betts，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，2010年5月。
[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. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（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月。
[ROSETTA-STONE] Sprecher, N., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.", Work in Progress, May 2010.
[ROSETTA-STONE]Sprecher，N.，“多协议标签交换传输配置文件（MPLS-TP）草案/RFC和ITU-T传输网络建议中所用术语的同义词表”，正在进行的工作，2010年5月。
[SEC-FRAMEWORK] Fang, L. and B. Niven-Jenkins, "Security Framework for MPLS-TP", Work in Progress, March 2010.
[SEC-FRAMEWORK]Fang，L.和B.Niven Jenkins，“MPLS-TP的安全框架”，正在进行的工作，2010年3月。
[SEGMENTED-PW] Martini, L., Nadeau, T., Metz, C., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", Work in Progress, June 2010.
[SEGMENTED-PW]Martini，L.，Nadeau，T.，Metz，C.，Bocci，M.，和M.Aissaoui，“分段伪线”，正在进行的工作，2010年6月。
[SURVIVE-FWK] Sprecher, N. and A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", Work in Progress, June 2010.
[SURVIVE-FWK]Sprecher，N.和A.Farrel，“多协议标签交换传输配置文件生存性框架”，正在进行的工作，2010年6月。
[VPMS-REQS] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., and L. Jin, "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Work in Progress, October 2009.
[VPMS-REQS]Kamite，Y.，JOUNAY，F.，Niven Jenkins，B.，Brungard，D.，和L.Jin，“虚拟专用多播服务（VPMS）的框架和要求”，正在进行的工作，2009年10月。
[X.200] ITU-T, "Information Technology - Open Systems Interconnection - Basic reference Model: The Basic Model", ITU-T Recommendation X.200, 1994.
[X.200]ITU-T，“信息技术-开放系统互连-基本参考模型：基本模型”，ITU-T建议X.200，1994年。
Authors' Addresses
作者地址
Matthew Bocci (editor) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ United Kingdom
Matthew Bocci（编辑）阿尔卡特朗讯航行者广场，英国伯克斯市梅登黑德路Shoppenigers路SL6 2PJ
EMail: matthew.bocci@alcatel-lucent.com
EMail: matthew.bocci@alcatel-lucent.com
Stewart Bryant (editor) Cisco Systems 250 Longwater Ave Reading RG2 6GB United Kingdom
Stewart Bryant（编辑）Cisco Systems 250 Longwater Ave Reading RG2 6GB英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Dan Frost (editor) Cisco Systems
Dan Frost（编辑）思科系统公司
EMail: danfrost@cisco.com
EMail: danfrost@cisco.com
Lieven Levrau Alcatel-Lucent 7-9, Avenue Morane Sulnier Velizy 78141 France
法国法兰西莫兰苏尔尼耶大道7-9号利文·列夫劳·阿尔卡特·朗讯78141
EMail: lieven.levrau@alcatel-lucent.com
EMail: lieven.levrau@alcatel-lucent.com
Lou Berger LabN Consulting, L.L.C.
Lou Berger LabN咨询公司，L.L.C。
EMail: lberger@labn.net
EMail: lberger@labn.net