Network Working Group B. Niven-Jenkins, Ed.
Request for Comments: 5654 BT
Category: Standards Track D. Brungard, Ed.
AT&T
M. Betts, Ed.
Huawei Technologies
N. Sprecher
Nokia Siemens Networks
S. Ueno
NTT Communications
September 2009
Network Working Group B. Niven-Jenkins, Ed.
Request for Comments: 5654 BT
Category: Standards Track D. Brungard, Ed.
AT&T
M. Betts, Ed.
Huawei Technologies
N. Sprecher
Nokia Siemens Networks
S. Ueno
NTT Communications
September 2009
Requirements of an MPLS Transport Profile
MPLS传输配置文件的要求
Abstract
摘要
This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF 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 International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).
本文件规定了MPLS传输配置文件（MPLS-TP）的要求。本文件是国际电信联盟（ITU）共同努力的成果IETF在IETF MPLS和PWE3体系结构中包括MPLS传输配置文件，以支持国际电信联盟-电信标准化部门（ITU-T）定义的分组传输网络的能力和功能。
This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.
这项工作基于两个需求来源：IETF定义的MPLS和PWE3体系结构，以及ITU-T定义的分组传输网络。
The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements.
本文档中表达的要求针对协议机制和过程的行为，这些协议机制和过程构成构建MPLS传输配置文件的构建块。这些要求不是实施要求。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright and License Notice
版权及许可证公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 7
1.3. Transport Network Overview . . . . . . . . . . . . . . . . 10
1.4. Layer Network Overview . . . . . . . . . . . . . . . . . . 11
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 12
2.1. General Requirements . . . . . . . . . . . . . . . . . . . 13
2.2. Layering Requirements . . . . . . . . . . . . . . . . . . 16
2.3. Data Plane Requirements . . . . . . . . . . . . . . . . . 17
2.4. Control Plane Requirements . . . . . . . . . . . . . . . . 18
2.5. Recovery Requirements . . . . . . . . . . . . . . . . . . 19
2.5.1. Data-Plane Behavior Requirements . . . . . . . . . . . 20
2.5.1.1. Protection . . . . . . . . . . . . . . . . . . . . 20
2.5.1.2. Sharing of Protection Resources . . . . . . . . . 21
2.5.2. Restoration . . . . . . . . . . . . . . . . . . . . . 21
2.5.3. Triggers for Protection, Restoration, and Reversion . 22
2.5.4. Management-Plane Operation of Protection and
Restoration . . . . . . . . . . . . . . . . . . . . . 22
2.5.5. Control Plane and In-Band OAM Operation of Recovery . 23
2.5.6. Topology-Specific Recovery Mechanisms . . . . . . . . 24
2.5.6.1. Ring Protection . . . . . . . . . . . . . . . . . 24
2.6. QoS Requirements . . . . . . . . . . . . . . . . . . . . . 27
3. Requirements Discussed in Other Documents . . . . . . . . . . 27
3.1. Network Management Requirements . . . . . . . . . . . . . 27
3.2. Operation, Administration, and Maintenance (OAM)
Requirements . . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Network Performance-Monitoring Requirements . . . . . . . 28
3.4. Security Requirements . . . . . . . . . . . . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 28
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 7
1.3. Transport Network Overview . . . . . . . . . . . . . . . . 10
1.4. Layer Network Overview . . . . . . . . . . . . . . . . . . 11
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 12
2.1. General Requirements . . . . . . . . . . . . . . . . . . . 13
2.2. Layering Requirements . . . . . . . . . . . . . . . . . . 16
2.3. Data Plane Requirements . . . . . . . . . . . . . . . . . 17
2.4. Control Plane Requirements . . . . . . . . . . . . . . . . 18
2.5. Recovery Requirements . . . . . . . . . . . . . . . . . . 19
2.5.1. Data-Plane Behavior Requirements . . . . . . . . . . . 20
2.5.1.1. Protection . . . . . . . . . . . . . . . . . . . . 20
2.5.1.2. Sharing of Protection Resources . . . . . . . . . 21
2.5.2. Restoration . . . . . . . . . . . . . . . . . . . . . 21
2.5.3. Triggers for Protection, Restoration, and Reversion . 22
2.5.4. Management-Plane Operation of Protection and
Restoration . . . . . . . . . . . . . . . . . . . . . 22
2.5.5. Control Plane and In-Band OAM Operation of Recovery . 23
2.5.6. Topology-Specific Recovery Mechanisms . . . . . . . . 24
2.5.6.1. Ring Protection . . . . . . . . . . . . . . . . . 24
2.6. QoS Requirements . . . . . . . . . . . . . . . . . . . . . 27
3. Requirements Discussed in Other Documents . . . . . . . . . . 27
3.1. Network Management Requirements . . . . . . . . . . . . . 27
3.2. Operation, Administration, and Maintenance (OAM)
Requirements . . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Network Performance-Monitoring Requirements . . . . . . . 28
3.4. Security Requirements . . . . . . . . . . . . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 28
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
Bandwidth demand continues to grow worldwide, stimulated by the accelerating growth and penetration of new packet-based services and multimedia applications:
在新的基于分组的服务和多媒体应用的加速增长和渗透的刺激下，全球带宽需求持续增长：
o Packet-based services such as Ethernet, Voice over IP (VoIP), Layer 2 (L2) / Layer 3 (L3) Virtual Private Networks (VPNs), IP television (IPTV), Radio Access Network (RAN) backhauling, etc.
o 基于分组的服务，如以太网、IP语音（VoIP）、第2层（L2）/第3层（L3）虚拟专用网络（VPN）、IP电视（IPTV）、无线接入网络（RAN）回程等。
o Applications with various bandwidth and Quality of Service (QoS) requirements.
o 具有各种带宽和服务质量（QoS）要求的应用程序。
This growth in demand has resulted in dramatic increases in access rates that are, in turn, driving dramatic increases in metro and core network bandwidth requirements.
这种需求的增长导致访问速率的急剧增加，而这反过来又推动了城域网和核心网络带宽需求的急剧增加。
Over the past two decades, the evolving optical transport infrastructure (Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN)) has provided carriers with a high benchmark for reliability and operational simplicity.
在过去二十年中，不断发展的光传输基础设施（同步光网络（SONET）/同步数字体系（SDH）、光传输网络（OTN））为运营商提供了可靠性和操作简单性的高基准。
With the movement towards packet-based services, the transport network has to evolve to encompass the provision of packet-aware capabilities while enabling carriers to leverage their installed, as well as planned, transport infrastructure investments.
随着向基于分组的服务的发展，传输网络必须不断发展，以包括提供分组感知能力，同时使运营商能够利用其已安装和计划的传输基础设施投资。
Carriers are in need of technologies capable of efficiently supporting packet-based services and applications on their transport networks with guaranteed Service Level Agreements (SLAs). The need to increase their revenue while remaining competitive forces operators to look for the lowest network Total Cost of Ownership (TCO). Investment in equipment and facilities (Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) should be minimized.
运营商需要能够通过保证服务水平协议（SLA）在其传输网络上高效支持基于分组的服务和应用的技术。在保持竞争力的同时增加收入的需要迫使运营商寻求最低的网络总体拥有成本（TCO）。应尽量减少设备和设施投资（资本支出（CAPEX））和运营支出（OPEX）。
There are a number of technology options for carriers to meet the challenge of increased service sophistication and transport efficiency, with increasing usage of hybrid packet-transport and circuit-transport technology solutions. To realize these goals, it is essential that packet-transport technology be available that can support the same high benchmarks for reliability and operational simplicity set by SDH/SONET and OTN technologies.
随着越来越多地使用混合分组传输和电路传输技术解决方案，运营商有许多技术选择来应对服务复杂性和传输效率不断提高的挑战。为了实现这些目标，必须提供能够支持SDH/SONET和OTN技术设置的可靠性和操作简单性的相同高基准的分组传输技术。
Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management.
此外，对于运营商而言，重要的是，此类分组传输网络的操作应保持运营商在部署其光传输网络时已习惯的外观，同时提供公共、多层操作、弹性、控制和多技术管理。
Transport carriers require control and deterministic usage of network resources. They need end-to-end control to engineer network paths and to efficiently utilize network resources. They require capabilities to support static (management-plane-based) or dynamic (control-plane-based) provisioning of deterministic, protected, and secured services and their associated resources.
传输运营商需要控制和确定使用网络资源。他们需要端到端的控制来设计网络路径和有效利用网络资源。它们需要支持静态（基于管理平面）或动态（基于控制平面）提供确定性、受保护和安全的服务及其相关资源的能力。
It is also important to ensure smooth interworking of the packet transport network with other existing/legacy packet networks, and provide mappings to enable packet transport carriage over a variety of transport network infrastructures. The latter has been termed vertical interworking, and is also known as client/server or network interworking. The former has been termed horizontal interworking, and is also known as peer-partition or service interworking. For more details on interworking and some of the issues that may arise (especially with horizontal interworking), see G.805 [ITU.G805.2000] and Y.1401 [ITU.Y1401.2008].
同样重要的是，确保分组传输网络与其他现有/遗留分组网络的平滑互通，并提供映射，以便能够在各种传输网络基础设施上进行分组传输传输。后者被称为垂直互通，也被称为客户机/服务器或网络互通。前者被称为水平互通，也被称为对等分区或服务互通。有关互通和可能出现的一些问题（尤其是水平互通）的更多详细信息，请参见G.805[ITU.G805.2000]和Y.1401[ITU.Y1401.2008]。
Multi-Protocol Label Switching (MPLS) is a maturing packet technology and it is already playing an important role in transport networks and services. However, not all of MPLS's capabilities and mechanisms are needed and/or consistent with transport network operations. There are also transport technology characteristics that are not currently reflected in MPLS. Therefore, there is the need to define an MPLS Transport Profile (MPLS-TP) that supports the capabilities and functionalities needed for packet-transport network services and operations through combining the packet experience of MPLS with the operational experience and practices of existing transport networks.
多协议标签交换（MPLS）是一种成熟的分组技术，已经在传输网络和服务中发挥着重要作用。然而，并非所有MPLS的功能和机制都是必需的和/或与传输网络操作一致的。还有一些传输技术特性目前没有反映在MPLS中。因此，需要定义MPLS传输配置文件（MPLS-TP），通过将MPLS的分组体验与现有传输网络的操作体验和实践相结合，来支持分组传输网络服务和操作所需的能力和功能。
MPLS-TP will enable the deployment of packet-based transport networks that will efficiently scale to support packet services in a simple and cost-effective way. MPLS-TP needs to combine the necessary existing capabilities of MPLS with additional minimal mechanisms in order that it can be used in a transport role.
MPLS-TP将能够部署基于分组的传输网络，该网络将以简单且经济高效的方式有效扩展以支持分组服务。MPLS-TP需要将MPLS的必要现有功能与附加的最小机制结合起来，以便在传输角色中使用。
This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP. The requirements in this document do not
本文件规定了MPLS传输配置文件（MPLS-TP）的要求。这些要求针对协议机制和过程的行为，这些协议机制和过程构成构建MPLS传输配置文件的构建块。也就是说，需求指示MPLS工具包中可供MPLS-TP使用的功能。本文件中的要求不适用
describe what functions an MPLS-TP implementation supports. The purpose of this document is to identify the toolkit and any new protocol work that is required.
描述MPLS-TP实现支持哪些功能。本文件的目的是确定工具包和所需的任何新协议工作。
This document is a product of a joint ITU-T and IETF 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 ITU-T. The document is a requirements specification, but is presented on the Standards Track so that it can be more easily cited as a normative reference from within the work of the ITU-T.
本文件是ITU-T和IETF联合努力的产物，旨在将MPLS传输配置文件纳入IETF MPLS和PWE3体系结构，以支持ITU-T定义的分组传输网络的能力和功能。本文件是一份需求规范，但在标准轨道上呈现，因此它可以更容易地作为ITU-T工作中的规范性参考引用。
This work is based on two sources of requirements, MPLS and PWE3 architectures as defined by IETF and packet transport networks as defined by ITU-T. The requirements of MPLS-TP are provided below. The relevant functions of MPLS and PWE3 are included in MPLS-TP, except where explicitly excluded. Any new functionality that is defined to fulfill the requirements for MPLS-TP must be agreed within the IETF through the IETF consensus process as per [RFC4929].
本工作基于两个需求来源，即IETF定义的MPLS和PWE3体系结构以及ITU-T定义的分组传输网络。MPLS-TP的需求如下所示。MPLS-TP中包含MPLS和PWE3的相关功能，除非明确排除。为满足MPLS-TP要求而定义的任何新功能必须按照[RFC4929]在IETF内通过IETF协商一致过程达成一致。
MPLS-TP transport paths may be established using static or dynamic configuration. It should be noted that the MPLS-TP network and its transport paths can always be operated fully (including OAM and protection capabilities) in the absence of any control plane.
MPLS-TP传输路径可以使用静态或动态配置建立。应该注意的是，在没有任何控制平面的情况下，MPLS-TP网络及其传输路径始终可以完全运行（包括OAM和保护能力）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。尽管本文件不是协议规范，但本语言的使用澄清了协议设计师的指示，以生产满足本文件规定要求的解决方案。
Note: Mapping between the terms in this section and ITU-T terminology is described in [TP-TERMS].
注：本节中的术语与ITU-T术语之间的映射在[TP-terms]中描述。
The recovery requirements in this document use the recovery terminology defined in RFC 4427 [RFC4427]; this is applied to both control-plane- and management-plane-based operations of MPLS-TP transport paths.
本文件中的恢复要求使用RFC 4427[RFC4427]中定义的恢复术语；这适用于MPLS-TP传输路径的基于控制平面和基于管理平面的操作。
ASON: Automatically Switched Optical Network
自动交换光网络
ATM: Asynchronous Transfer Mode
异步传输模式
CAPEX: Capital Expenditure
资本支出：资本支出
CE: Customer Edge
行政长官：顾客优势
FR: Frame Relay
帧中继
GMPLS: Generalized Multi-Protocol Label Switching
广义多协议标签交换
IGP: Interior Gateway Protocol
内部网关协议
IPTV: IP Television
IPTV：IP电视
L2: Layer 2
L2：第2层
L3: Layer 3
L3：第3层
LSP: Label Switched Path
标签交换路径
LSR: Label Switching Router
标签交换路由器
MPLS: Multi-Protocol Label Switching
多协议标签交换
OAM: Operations, Administration, and Maintenance
OAM：运营、管理和维护
OPEX: Operational Expenditure
运营支出：业务支出
OSI: Open Systems Interconnection
开放系统互连
OTN: Optical Transport Network
光传输网
P2MP: Point to Multipoint
P2MP：点对多点
P2P: Point to Point
P2P：点对点
PDU: Protocol Data Unit
协议数据单元
PSC: Protection State Coordination
保护国协调
PW: Pseudowire
伪线
QoS: Quality of Service
QoS：服务质量
SDH: Synchronous Digital Hierarchy
同步数字体系
SLA: Service Level Agreement
SLA：服务级别协议
SLS: Service Level Specification
SLS：服务级别规范
S-PE: Switching Provider Edge
S-PE：交换提供程序边缘
SONET: Synchronous Optical Network
同步光网络
SRLG: Shared Risk Link Group
SRLG：共享风险链接组
TCO: Total Cost of Ownership
TCO：总体拥有成本
T-PE: Terminating Provider Edge
T-PE：终止提供程序边缘
VoIP: Voice over IP
VoIP：IP语音
VPN: Virtual Private Network
虚拟专用网
WDM: Wavelength Division Multiplexing
波分复用
Note: The definition of "segment" in a GMPLS/ASON context (i.e., as defined in RFC4397 [RFC4397]) encompasses both "segment" and "concatenated segment" as defined in this document.
注：GMPLS/ASON上下文中“段”的定义（即RFC4397[RFC4397]中的定义）包括本文件中定义的“段”和“连接段”。
Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points. The forward and backward directions are setup, monitored, and protected independently. As a consequence, they may or may not follow the same route (links and nodes) across the network.
关联双向路径：支持双向交通流的路径，但由一对单向路径（每个方向一条）构成，该路径在路径的入口/出口点处彼此关联。向前和向后方向是独立设置、监控和保护的。因此，它们可能在网络中遵循或不遵循相同的路由（链路和节点）。
Client layer network: In a client/server relationship (see G.805 [ITU.G805.2000]), the client layer network receives a (transport) service from the lower server layer network (usually the layer network under consideration).
客户端层网络：在客户端/服务器关系中（参见G.805[ITU.G805.2000]），客户端层网络从较低的服务器层网络（通常是考虑中的层网络）接收（传输）服务。
Concatenated Segment: A serial-compound link connection as defined in G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part of an LSP or multi-segment PW that comprises a set of segments and their interconnecting nodes in sequence. See also "Segment".
串联段：G.805[ITU.G805.2000]中定义的串行复合链路连接。连接段是LSP或多段PW的一个连续部分，由一组段及其顺序互连节点组成。另见“部分”。
Control Plane: Within the scope of this document, the control plane performs transport path control functions. Through signalling, the control plane sets up, modifies and releases transport paths, and may recover a transport path in case of a failure. The control plane also performs other functions in support of transport path control, such as routing information dissemination.
控制平面：在本文件范围内，控制平面执行传输路径控制功能。通过信令，控制平面设置、修改和释放传输路径，并在发生故障时恢复传输路径。控制平面还执行支持传输路径控制的其他功能，例如路由信息传播。
Co-routed Bidirectional path: A path where the forward and backward directions follow the same route (links and nodes) across the network. Both directions are setup, monitored and protected as a single entity. A transport network path is typically co-routed.
共路由双向路径：向前和向后方向在网络中遵循相同路径（链路和节点）的路径。两个方向都作为一个实体进行设置、监控和保护。传输网络路径通常是共同路由的。
Domain: A domain represents a collection of entities (for example network elements) that are grouped for a particular purpose, examples of which are administrative and/or managerial responsibilities, trust relationships, addressing schemes, infrastructure capabilities, aggregation, survivability techniques, distributions of control functionality, etc. Examples of such domains include IGP areas and Autonomous Systems.
域：域表示为特定目的而分组的实体（例如网络元素）的集合，例如行政和/或管理责任、信任关系、寻址方案、基础设施能力、聚合、生存能力技术、控制功能的分布，此类领域的示例包括IGP区域和自治系统。
Layer network: Layer network is defined in G.805 [ITU.G805.2000]. 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. Section 1.4 provides a more detailed overview of what constitutes a layer network. For additional explanation of how layer networks relate to the OSI concept of layering, see Appendix I of Y.2611 [ITU.Y2611.2006].
层网络：层网络在G.805[ITU.G805.2000]中定义。层网络提供客户端信息的传输和客户端OAM的独立操作。层网络可以在服务上下文中描述如下：一层网络可以向更高的客户端层网络提供（传输）服务，并且反过来可以是低层网络的客户端。层网络是一种逻辑结构，在某种程度上独立于物理网络元素的排列或组成。一个特定的物理网络元素可能在拓扑上属于一个以上的层网络，这取决于它对与逻辑层（例如，标签堆栈）相关联的封装所采取的行动，因此可以建模为多个逻辑元素。层网络可以由一个或多个子层组成。第1.4节提供了构成图层网络的更详细概述。有关分层网络如何与OSI分层概念相关的更多解释，请参见Y.2611[ITU.Y2611.2006]的附录I。
Link: A physical or logical connection between a pair of LSRs that are adjacent at the (sub)layer network under consideration. A link may carry zero, one, or more LSPs or PWs. A packet entering a link will emerge with the same label-stack entry values.
链路：在所考虑的（子）层网络上相邻的一对LSR之间的物理或逻辑连接。链路可以承载零个、一个或多个LSP或PW。进入链路的数据包将显示相同的标签堆栈条目值。
MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a set of LSRs and logical data links (such as MPLS-TP LSP tunnels or MPLS-TP pseudowires) and physical data links that form a ring topology.
MPLS-TP逻辑环：MPLS-TP逻辑环由一组LSR和逻辑数据链路（如MPLS-TP LSP隧道或MPLS-TP伪线）以及形成环拓扑的物理数据链路构成。
Path: See Transport Path.
路径：请参见传输路径。
MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed from a set of LSRs and physical data links that form a ring topology.
MPLS-TP物理环：MPLS-TP物理环由形成环拓扑的一组LSR和物理数据链路构成。
MPLS-TP Ring Topology: In an MPLS-TP ring topology, each LSR is connected to exactly two other LSRs, each via a single point-to-point bidirectional MPLS-TP capable link. A ring may also be constructed from only two LSRs where there are also exactly two links. Rings may be connected to other LSRs to form a larger network. Traffic originating or terminating outside the ring may be carried over the ring. Client network nodes (such as CEs) may be connected directly to an LSR in the ring.
MPLS-TP环形拓扑：在MPLS-TP环形拓扑中，每个LSR通过一个支持MPLS-TP的单点对点双向链路连接到另外两个LSR。环也可以仅由两个LSR构成，其中也正好有两个链路。环可以连接到其他LSR以形成更大的网络。环外始发或终止的流量可通过环进行。客户端网络节点（例如ce）可以直接连接到环中的LSR。
Section Layer Network: A section layer is a server layer (which may be MPLS-TP or a different technology) that provides for the transfer of the section-layer client information between adjacent nodes in the transport-path layer or transport-service layer. A section layer may provide for aggregation of multiple MPLS-TP clients. Note that G.805 [ITU.G805.2000] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network.
节层网络：节层是服务器层（可能是MPLS-TP或其他技术），用于在传输路径层或传输服务层的相邻节点之间传输节层客户端信息。部分层可提供多个MPLS-TP客户端的聚合。注意，G.805[ITU.G805.2000]将截面层定义为传输媒体层网络中的两层网络之一。另一层网络是物理媒体层网络。
Segment: A link connection as defined in G.805 [ITU.G805.2000]. A segment is the part of an LSP that traverses a single link or the part of a PW that traverses a single link (i.e., that connects a pair of adjacent {Switching|Terminating} Provider Edges). See also "Concatenated Segment".
段：G.805[ITU.G805.2000]中定义的链路连接。段是LSP中穿过单个链路的部分或PW中穿过单个链路的部分（即，连接一对相邻的{交换|终止}提供程序边）。另见“连接段”。
Server Layer Network: In a client/server relationship (see G.805 [ITU.G805.2000]), the server layer network provides a (transport) service to the higher client layer network (usually the layer network under consideration).
服务器层网络：在客户机/服务器关系中（参见G.805[ITU.G805.2000]），服务器层网络向更高的客户层网络（通常是考虑中的层网络）提供（传输）服务。
Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The distinction between a layer network and a sublayer is that a sublayer is not directly accessible to clients outside of its encapsulating layer network and offers no direct transport service for a higher layer (client) network.
子层：子层在G.805[ITU.G805.2000]中定义。层网络和子层之间的区别在于，子层不能直接访问其封装层网络之外的客户端，并且不能为更高层（客户端）网络提供直接传输服务。
Switching Provider Edge (S-PE): See [MS-PW-ARCH].
交换提供程序边缘（S-PE）：请参阅[MS-PW-ARCH]。
Terminating Provider Edge (T-PE): See [MS-PW-ARCH].
终止提供程序边缘（T-PE）：请参阅[MS-PW-ARCH]。
Transport Path: A network connection as defined in G.805 [ITU.G805.2000]. In an MPLS-TP environment, a transport path corresponds to an LSP or a PW.
传输路径：G.805[ITU.G805.2000]中定义的网络连接。在MPLS-TP环境中，传输路径对应于LSP或PW。
Transport Path Layer: A (sub)layer network that provides point-to-point or point-to-multipoint transport paths. It provides OAM that is independent of the clients that it is transporting.
传输路径层：提供点对点或点对多点传输路径的（子）层网络。它提供独立于它正在传输的客户端的OAM。
Transport Service Layer: A layer network in which transport paths are used to carry a customer's (individual or bundled) service (may be point-to-point, point-to-multipoint, or multipoint-to-multipoint services).
传输服务层：传输路径用于承载客户（单个或捆绑）服务（可以是点对点、点对多点或多点对多点服务）的层网络。
Transmission Media Layer: A layer network, consisting of a section layer network and a physical layer network as defined in G.805 [ITU.G805.2000], that provides sections (two-port point-to-point connections) to carry the aggregate of network-transport path or network-service layers on various physical media.
传输介质层：一种层网络，由G.805[ITU.G805.2000]中定义的节层网络和物理层网络组成，提供节（两端口点对点连接），以承载各种物理介质上的网络传输路径或网络服务层的集合。
Unidirectional Path: A path that supports traffic flow in only one direction.
单向路径：仅支持单向交通流的路径。
The connectivity service is the basic service provided by a transport network. The purpose of a transport network is to carry its customer traffic (i.e., the stream of customer PDUs or customer bits, including overhead) between end points in the transport network (typically over several intermediate nodes). The connectivity services offered to customers are typically aggregated into large transport paths with long holding times and OAM that is independent (of the client OAM), which contribute to enabling the efficient and reliable operation of the transport network. These transport paths are modified infrequently.
连接服务是由传输网络提供的基本服务。传输网络的目的是在传输网络的端点之间（通常通过几个中间节点）承载其客户流量（即，客户pdu或客户比特流，包括开销）。向客户提供的连接服务通常聚合为具有长等待时间的大型传输路径和独立于客户机OAM的OAM，这有助于实现传输网络的高效可靠运行。这些传输路径很少被修改。
Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee bandwidth, and to control jitter and delay. A transport network must provide the means to meet the quality-of-service objectives of its clients. This is achieved by providing a mechanism for client network service demarcation for the network path together with an associated network resiliency mechanism.
分组传输网络中需要服务质量机制，以确保关键服务的优先级，保证带宽，并控制抖动和延迟。运输网络必须提供满足其客户服务质量目标的手段。这是通过为网络路径提供客户端网络服务划分机制以及相关的网络弹性机制来实现的。
Aggregation is beneficial for achieving scalability and security since:
聚合有利于实现可扩展性和安全性，因为：
1. It reduces the number of provisioning and forwarding states in the network core.
1. 它减少了网络核心中的供应和转发状态数。
2. It reduces load and the cost of implementing service assurance and fault management.
2. 它减少了负载，降低了实施服务保证和故障管理的成本。
3. Customer traffic is encapsulated and layer-associated OAM overhead is added. This allows complete isolation of customer traffic and its management from carrier operations.
3. 封装了客户流量，并添加了与层相关的OAM开销。这使得客户流量及其管理与运营商运营完全隔离。
An important attribute of a transport network is that it is able to function regardless of which clients are using its connection service or over which transmission media it is running. From a functional and operational point of view, the client, transport network, and server layers are independent layer networks. Another key characteristic of transport networks is the capability to maintain the integrity of the client across the transport network. A transport network must also provide a method of service monitoring in order to verify the delivery of an agreed quality of service. This is enabled by means of carrier-grade OAM tools.
传输网络的一个重要属性是，无论哪个客户端正在使用其连接服务或运行在哪个传输介质上，它都能够正常工作。从功能和操作的角度来看，客户端、传输网络和服务器层是独立的层网络。传输网络的另一个关键特征是能够跨传输网络维护客户端的完整性。传输网络还必须提供服务监控方法，以验证约定服务质量的交付。这是通过运营商级OAM工具实现的。
Customer traffic is first encapsulated within the transport-service layer network. The transport service layer network signals may then be aggregated into a transport-path layer network for transport through the network in order to optimize network management. Transport-service layer network OAM is used to monitor the transport integrity of the customer traffic, and transport-path layer network OAM is used to monitor the transport integrity of the aggregates. At any hop, the aggregated signals may be further aggregated in lower-layer transport network paths for transport across intermediate shared links. The transport service layer network signals are extracted at the edges of aggregation domains, and are either delivered to the customer or forwarded to another domain. In the core of the network, only the transport path layer network signals are monitored at intermediate points; individual transport service layer network signals are monitored at the network boundary. Although the connectivity of the transport-service layer network may be point-to-point, point-to-multipoint, or multipoint-to-multipoint, the transport-path layer network only provides point-to-point or point-to-multipoint transport paths, which are used to carry aggregates of transport service layer network traffic.
客户流量首先封装在传输服务层网络中。然后可以将传输服务层网络信号聚合到传输路径层网络中，以便通过网络进行传输，以优化网络管理。传输服务层网络OAM用于监控客户流量的传输完整性，传输路径层网络OAM用于监控聚合的传输完整性。在任何跃点处，可在较低层传输网络路径中进一步聚合聚合聚合信号，以跨中间共享链路进行传输。传输服务层网络信号在聚合域的边缘提取，并传递给客户或转发到另一个域。在网络的核心，只有传输路径层网络信号在中间点被监控；在网络边界处监控各个传输服务层网络信号。尽管传输服务层网络的连接可以是点对点、点对多点或多点对多点，但传输路径层网络仅提供点对点或点对多点传输路径，用于承载传输服务层网络流量的集合。
A layer network provides its clients with a transport service and the operation of the layer network is independent of whatever client happens to use the layer network. Information that passes between any client to the layer network is common to all clients and is the minimum needed to be consistent with the definition of the transport service offered. The client layer network can be connectionless, connection-oriented packet switched, or circuit switched. The transport service transfers a payload such that the client can populate the payload without affecting any operation within the serving layer network. Here, payload means:
层网络为其客户机提供传输服务，层网络的操作独立于使用层网络的任何客户机。在任何客户机之间传递到层网络的信息对于所有客户机来说都是公共的，并且是与所提供的传输服务的定义保持一致所需的最低限度的信息。客户端层网络可以是无连接、面向连接的分组交换或电路交换。传输服务传输有效负载，使得客户端可以填充有效负载而不影响服务层网络内的任何操作。这里，有效载荷是指：
o an individual packet payload (for connectionless networks),
o 单个数据包有效负载（用于无连接网络），
o a sequence of packet payloads (for connection-oriented packet-switched networks), or
o 分组有效载荷序列（用于面向连接的分组交换网络），或
o a deterministic schedule of payloads (for circuit-switched networks).
o 有效载荷的确定性时间表（用于电路交换网络）。
The operations within a layer network that are independent of its clients include the control of forwarding, the control of resource reservation, the control of traffic de-merging, and the OAM and recovery of the transport service. All of these operations are internal to a layer network. By definition, a layer network does not rely on any client information to perform these operations, and therefore all information required to perform these operations is independent of whatever client is using the layer network.
层网络中独立于客户端的操作包括转发控制、资源预留控制、流量解合并控制以及传输服务的OAM和恢复。所有这些操作都是层网络的内部操作。根据定义，层网络不依赖任何客户端信息来执行这些操作，因此执行这些操作所需的所有信息都独立于使用层网络的任何客户端。
A layer network will have consistent features in order to support the control of forwarding, resource reservation, OAM, and recovery. For example, a layer network will have a common addressing scheme for the end points of the transport service and a common set of transport descriptors for the transport service. However, a client may use a different addressing scheme or different traffic descriptors (consistent with performance inheritance).
层网络将具有一致的功能，以支持对转发、资源保留、OAM和恢复的控制。例如，层网络将具有传输服务端点的公共寻址方案和传输服务的公共传输描述符集。但是，客户机可能使用不同的寻址方案或不同的流量描述符（与性能继承一致）。
It is sometimes useful to independently monitor a smaller domain within a layer network (or the transport services that traverse this smaller domain), but the control of forwarding or the control of resource reservation involved retain their common elements. These smaller monitored domains are sublayers.
有时，独立监控层网络中的较小域（或穿越该较小域的传输服务）是有用的，但所涉及的转发控制或资源保留控制保留了它们的公共元素。这些较小的受监控域是子层。
It is sometimes useful to independently control forwarding in a smaller domain within a layer network, but the control of resource reservation and OAM retain their common elements. These smaller domains are partitions of the layer network.
有时，在层网络内的较小域中独立地控制转发是有用的，但对资源保留和OAM的控制保留了它们的公共元素。这些较小的域是层网络的分区。
The MPLS-TP requirements set out in this section are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP.
本节中规定的MPLS-TP要求适用于构成构建MPLS传输配置文件的构建块的协议机制和过程的行为。也就是说，需求指示MPLS工具包中可供MPLS-TP使用的功能。
1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as defined by the IETF. When MPLS offers multiple options in this respect, MPLS-TP SHOULD select the minimum subset (necessary and sufficient subset) applicable to a transport network application.
1 MPLS-TP数据平面必须是IETF定义的MPLS数据平面的子集。当MPLS在这方面提供多种选择时，MPLS-TP应选择适用于传输网络应用的最小子集（必要和足够的子集）。
2 The MPLS-TP design SHOULD as far as reasonably possible reuse existing MPLS standards.
2 MPLS-TP设计应尽可能合理地重用现有MPLS标准。
3 Mechanisms and capabilities MUST be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate.
3机制和能力必须能够与现有的IETF MPLS[RFC3031]和IETF PWE3[RFC3985]控制和数据平面（如适用）进行互操作。
A. Data-plane interoperability MUST NOT require a gateway function.
A.数据平面互操作性不得要求网关功能。
4 MPLS-TP and its interfaces, both internal and external, MUST be sufficiently well-defined that interworking equipment supplied by multiple vendors will be possible both within a single domain and between domains.
4 MPLS-TP及其内部和外部接口必须充分明确定义，以确保多个供应商提供的互通设备在单个域内和域之间都是可行的。
5 MPLS-TP MUST be a connection-oriented packet-switching technology with traffic-engineering capabilities that allow deterministic control of the use of network resources.
5 MPLS-TP必须是一种面向连接的分组交换技术，具有流量工程能力，允许对网络资源的使用进行确定性控制。
6 MPLS-TP MUST support traffic-engineered point-to-point (P2P) and point-to-multipoint (P2MP) transport paths.
6 MPLS-TP必须支持流量工程点对点（P2P）和点对多点（P2MP）传输路径。
7 MPLS-TP MUST support unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths.
7 MPLS-TP必须支持单向、共路由双向和相关的双向点到点传输路径。
8 MPLS-TP MUST support unidirectional point-to-multipoint transport paths.
8 MPLS-TP必须支持单向点对多点传输路径。
9 The end points of a co-routed bidirectional transport path MUST be aware of the pairing relationship of the forward and reverse paths used to support the bidirectional service.
9共同路由的双向传输路径的端点必须知道用于支持双向服务的正向和反向路径的配对关系。
10 All nodes on the path of a co-routed bidirectional transport path in the same (sub)layer as the path MUST be aware of the pairing relationship of the forward and the backward directions of the transport path.
10同一（子）层中的同路由双向传输路径路径上的所有节点必须知道传输路径的前向和后向的配对关系。
11 The end points of an associated bidirectional transport path MUST be aware of the pairing relationship of the forward and reverse paths used to support the bidirectional service.
11相关联的双向传输路径的端点必须知道用于支持双向服务的正向和反向路径的配对关系。
12 Nodes on the path of an associated bidirectional transport path where both the forward and backward directions transit the same node in the same (sub)layer as the path SHOULD be aware of the pairing relationship of the forward and the backward directions of the transport path.
相关双向传输路径路径上的12个节点，其中前向和后向与路径在同一（子）层中通过同一节点，应了解传输路径的前向和后向的配对关系。
13 MPLS-TP MUST support bidirectional transport paths with symmetric bandwidth requirements, i.e., the amount of reserved bandwidth is the same between the forward and backward directions.
13 MPLS-TP必须支持具有对称带宽要求的双向传输路径，即前向和后向之间的保留带宽量相同。
14 MPLS-TP MUST support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions.
14 MPLS-TP必须支持具有非对称带宽要求的双向传输路径，即前向和后向之间的保留带宽量不同。
15 MPLS-TP MUST support the logical separation of the control and management planes from the data plane.
15 MPLS-TP必须支持控制和管理平面与数据平面的逻辑分离。
16 MPLS-TP MUST support the physical separation of the control and management planes from the data plane. That is, it must be possible to operate the control and management planes out-of-band, and no assumptions should be made about the state of the data-plane channels from information about the control or management-plane channels when they are running out-of-band.
16 MPLS-TP必须支持控制和管理平面与数据平面的物理分离。也就是说，必须能够在带外操作控制和管理平面，并且不应根据控制或管理平面通道在带外运行时的信息对数据平面通道的状态进行任何假设。
17 MPLS-TP MUST support static provisioning of transport paths via the management plane.
17 MPLS-TP必须支持通过管理平面静态提供传输路径。
18 A solution MUST be defined to support dynamic provisioning and restoration of MPLS-TP transport paths via a control plane.
18必须定义一个解决方案，以支持通过控制平面动态调配和恢复MPLS-TP传输路径。
19 Static provisioning MUST NOT depend on the presence of any element of a control plane.
19静态配置不得依赖于控制平面的任何元素的存在。
20 MPLS-TP MUST support the coexistence of statically and dynamically provisioned/managed MPLS-TP transport paths within the same layer network or domain.
20 MPLS-TP必须支持同一层网络或域内静态和动态供应/管理的MPLS-TP传输路径共存。
21 Mechanisms in an MPLS-TP layer network that satisfy functional requirements that are common to general transport-layer networks (i.e., independent of technology) SHOULD be operable in a way that is similar to the way the equivalent mechanisms are operated in other transport-layer technologies.
21 MPLS-TP层网络中满足通用传输层网络通用功能要求（即，独立于技术）的机制应以类似于其他传输层技术中等效机制的方式操作。
22 MPLS-TP MUST support the capability for network operation via the management plane (without the use of any control-plane protocols). This includes the configuration and control of OAM and recovery functions.
22 MPLS-TP必须支持通过管理平面进行网络操作的能力（不使用任何控制平面协议）。这包括OAM和恢复功能的配置和控制。
23 The MPLS-TP data plane MUST be capable of
23 MPLS-TP数据平面必须能够
A. forwarding data independent of the control or management plane used to configure and operate the MPLS-TP layer network.
A.独立于用于配置和操作MPLS-TP层网络的控制或管理平面转发数据。
B. taking recovery actions independent of the control or management plane used to configure the MPLS-TP layer network.
B.采取独立于用于配置MPLS-TP层网络的控制或管理平面的恢复操作。
C. operating normally (i.e., forwarding, OAM, and protection MUST continue to operate) if the management plane or control plane that configured the transport paths fails.
C.如果配置传输路径的管理平面或控制平面出现故障，则正常运行（即，转发、OAM和保护必须继续运行）。
24 MPLS-TP MUST support mechanisms to avoid or minimize traffic impact (e.g., packet delay, reordering, and loss) during network reconfiguration.
24 MPLS-TP必须支持在网络重新配置期间避免或最小化流量影响（例如，数据包延迟、重新排序和丢失）的机制。
25 MPLS-TP MUST support transport paths through multiple homogeneous domains.
25 MPLS-TP必须支持通过多个同质域的传输路径。
26 MPLS-TP SHOULD support transport paths through multiple non-homogeneous domains.
26 MPLS-TP应支持通过多个非同质域的传输路径。
27 MPLS-TP MUST NOT dictate the deployment of any particular network topology either physical or logical, however:
27 MPLS-TP不得要求部署任何特定的物理或逻辑网络拓扑，但是：
A. It MUST be possible to deploy MPLS-TP in rings.
A.必须能够在环中部署MPLS-TP。
B. It MUST be possible to deploy MPLS-TP in arbitrarily interconnected rings with one or two points of interconnection.
B.必须能够在具有一个或两个互连点的任意互连环中部署MPLS-TP。
C. MPLS-TP MUST support rings of at least 16 nodes in order to support the upgrade of existing Time-Division Multiplexing (TDM) rings to MPLS-TP. MPLS-TP SHOULD support rings with more than 16 nodes.
C.MPLS-TP必须支持至少16个节点的环，以支持现有时分复用（TDM）环升级到MPLS-TP。MPLS-TP应支持超过16个节点的环。
28 MPLS-TP MUST be able to scale at least as well as existing transport technologies with growing and increasingly complex network topologies as well as with increasing amounts of customers, services, and bandwidth demand.
28 MPLS-TP必须能够与现有传输技术一样，在网络拓扑不断增长和日益复杂的情况下，以及在客户、服务和带宽需求不断增加的情况下进行扩展。
29 MPLS-TP SHOULD support mechanisms to safeguard against the provisioning of transport paths which contain forwarding loops.
29 MPLS-TP应支持防止提供包含转发环路的传输路径的机制。
30 A generic and extensible solution MUST be provided to support the transport of one or more client layer networks (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
30必须提供通用和可扩展的解决方案，以支持通过MPLS-TP层网络传输一个或多个客户端层网络（例如，MPLS-TP、IP、MPLS、以太网、ATM、FR等）。
31 A generic and extensible solution MUST be provided to support the transport of MPLS-TP transport paths over one or more server layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). Requirements for bandwidth management within a server layer network are outside the scope of this document.
31必须提供通用和可扩展的解决方案，以支持通过一个或多个服务器层网络（如MPLS-TP、以太网、SONET/SDH、OTN等）传输MPLS-TP传输路径。服务器层网络内的带宽管理要求不在本文档范围内。
32 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 the server or client layer network.
32在MPLS-TP层网络支持客户端层网络，且MPLS-TP层网络由服务器层网络支持的环境中，MPLS-TP层网络的操作必须能够在不依赖于服务器或客户端层网络的情况下进行。
A. The server layer MUST guarantee that the traffic-loading imposed by other clients does not cause the transport service provided to the MPLS-TP layer to fall below the agreed level. Mechanisms to achieve this are outside the scope of these requirements.
A.服务器层必须保证其他客户端施加的流量负载不会导致提供给MPLS-TP层的传输服务低于商定的水平。实现这一点的机制不在这些要求的范围之内。
B. It MUST be possible to isolate the control and management planes of the MPLS-TP layer network from the control and management planes of the client and server layer networks.
B.必须能够将MPLS-TP层网络的控制和管理平面与客户端和服务器层网络的控制和管理平面隔离开来。
33 A solution MUST be provided to support the transport of a client MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer network.
33必须提供一种解决方案，以支持通过服务器MPLS或MPLS-TP层网络传输客户端MPLS或MPLS-TP层网络。
A. The level of coordination required between the client and server MPLS(-TP) layer networks MUST be minimized (preferably no coordination will be required).
A.必须最小化客户机和服务器MPLS（-TP）层网络之间所需的协调级别（最好不需要协调）。
B. The MPLS(-TP) server layer network MUST be capable of transporting the complete set of packets generated by the client MPLS(-TP) layer network, which may contain packets that are not MPLS packets (e.g., IP or Connectionless Network Protocol (CNLP) packets used by the control/management plane of the client MPLS(-TP) layer network).
B.MPLS（-TP）服务器层网络必须能够传输客户端MPLS（-TP）层网络生成的完整数据包集，其中可能包含非MPLS数据包的数据包（例如，客户端MPLS（-TP）层网络的控制/管理平面使用的IP或无连接网络协议（CNLP）数据包）。
34 It MUST be possible to operate the layers of a multi-layer network that includes an MPLS-TP layer autonomously.
34必须能够自主操作包括MPLS-TP层的多层网络的各层。
The above are not only technology requirements, but also operational requirements. Different administrative groups may be responsible for the same layer network or different layer networks.
以上不仅是技术要求，也是操作要求。不同的管理组可能负责同一层网络或不同层网络。
35 It MUST be possible to hide MPLS-TP layer network addressing and other information (e.g., topology) from client layer networks. However, it SHOULD be possible, at the option of the operator, to leak a limited amount of summarized information (such as SRLGs or reachability) between layers.
35必须能够对客户层网络隐藏MPLS-TP层网络地址和其他信息（如拓扑）。但是，操作员可以选择在层之间泄漏有限数量的汇总信息（如SRLGs或可达性）。
36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label.
36必须能够在MPLS-TP数据平面中没有任何IP转发能力的情况下操作和配置MPLS-TP数据平面。即，数据平面仅在MPLS标签上操作。
37 It MUST be possible for the end points of an MPLS-TP transport path that is carrying an aggregate of client transport paths to be able to decompose the aggregate transport path into its component client transport paths.
37承载客户端传输路径聚合的MPLS-TP传输路径的端点必须能够将聚合传输路径分解为其组件客户端传输路径。
38 A transport path on a link MUST be uniquely identifiable by a single label on that link.
38链路上的传输路径必须由该链路上的单个标签唯一标识。
39 A transport path's source MUST be identifiable at its destination within its layer network.
39传输路径的源必须在其层网络中的目的地可识别。
40 MPLS-TP MUST be capable of using P2MP server (sub)layer capabilities as well as P2P server (sub)layer capabilities when supporting P2MP MPLS-TP transport paths.
40在支持P2MP MPLS-TP传输路径时，MPLS-TP必须能够使用P2MP服务器（子）层功能以及P2P服务器（子）层功能。
41 MPLS-TP MUST be extensible in order to accommodate new types of client layer networks and services.
41 MPLS-TP必须是可扩展的，以适应新类型的客户端层网络和服务。
42 MPLS-TP SHOULD support mechanisms to enable the reserved bandwidth associated with a transport path to be increased without impacting the existing traffic on that transport path provided enough resources are available.
42如果有足够的资源可用，MPLS-TP应支持使与传输路径相关联的保留带宽增加而不影响该传输路径上的现有流量的机制。
43 MPLS-TP SHOULD support mechanisms to enable the reserved bandwidth of a transport path to be decreased without impacting the existing traffic on that transport path, provided that the level of existing traffic is smaller than the reserved bandwidth following the decrease.
43 MPLS-TP应支持使传输路径的保留带宽减少而不影响该传输路径上的现有流量的机制，前提是现有流量的水平小于减少后的保留带宽。
44 MPLS-TP MUST support mechanisms that ensure the integrity of the transported customer's service traffic as required by its associated SLA. Loss of integrity may be defined as packet corruption, reordering, or loss during normal network conditions.
44 MPLS-TP必须支持确保传输的客户服务流量的完整性的机制，以符合其相关SLA的要求。完整性损失可定义为正常网络条件下的数据包损坏、重新排序或丢失。
45 MPLS-TP MUST support mechanisms to detect when loss of integrity of the transported customer's service traffic has occurred.
45 MPLS-TP必须支持检测传输的客户服务流量何时发生完整性丢失的机制。
46 MPLS-TP MUST support an unambiguous and reliable means of distinguishing users' (client) packets from MPLS-TP control packets (e.g., control plane, management plane, OAM, and protection-switching packets).
46 MPLS-TP必须支持明确可靠的方法，将用户（客户端）数据包与MPLS-TP控制数据包（例如，控制平面、管理平面、OAM和保护交换数据包）区分开来。
This section defines the requirements that apply to an MPLS-TP control plane. Note that it MUST be possible to operate an MPLS-TP network without using a control plane.
本节定义了适用于MPLS-TP控制平面的要求。注意，必须能够在不使用控制平面的情况下操作MPLS-TP网络。
The ITU-T has defined an architecture for Automatically Switched Optical Networks (ASONs) in G.8080 [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST fit within the ASON architecture.
ITU-T在G.8080[ITU.G8080.2006]和G.8080修正案1[ITU.G8080.2008]中定义了自动交换光网络（ASON）的体系结构。MPLS-TP的控制平面必须适合ASON架构。
An interpretation of the ASON signaling and routing requirements in the context of GMPLS can be found in [RFC4139] and [RFC4258].
关于GMPLS上下文中ASON信令和路由要求的解释，请参见[RFC4139]和[RFC4258]。
Additionally:
此外：
47 The MPLS-TP control plane MUST support control-plane topology and data-plane topology independence. As a consequence, a failure of the control plane does not imply that there has also been a failure of the data plane.
47 MPLS-TP控制平面必须支持控制平面拓扑和数据平面拓扑独立性。因此，控制平面的故障并不意味着数据平面也发生了故障。
48 The MPLS-TP control plane MUST be able to be operated independently of any particular client- or server-layer control plane.
48 MPLS-TP控制平面必须能够独立于任何特定的客户端或服务器层控制平面进行操作。
49 MPLS-TP SHOULD define a solution to support an integrated control plane encompassing MPLS-TP together with its server and client layer networks when these layer networks belong to the same administrative domain.
49 MPLS-TP应定义一个解决方案，当MPLS-TP及其服务器层和客户端层网络属于同一管理域时，该解决方案应支持一个包含MPLS-TP及其服务器层和客户端层网络的集成控制平面。
50 The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP data plane (i.e., unidirectional P2P, associated bidirectional P2P, co-routed bidirectional P2P, unidirectional P2MP) including configuration of protection functions and any associated maintenance functions.
50 MPLS-TP控制平面必须支持建立为MPLS-TP数据平面定义的所有连接模式（即单向P2P、关联双向P2P、共路由双向P2P、单向P2MP），包括保护功能和任何关联维护功能的配置。
51 The MPLS-TP control plane MUST support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the transport path or transport service is established or modified.
51 MPLS-TP控制平面必须支持OAM维护点的配置和修改，以及在建立或修改传输路径或传输服务时激活/停用OAM。
52 An MPLS-TP control plane MUST support operation of the recovery functions described in Section 2.8.
52 MPLS-TP控制平面必须支持第2.8节所述恢复功能的操作。
53 An MPLS-TP control plane MUST scale gracefully to support a large number of transport paths, nodes, and links.
53 MPLS-TP控制平面必须适度扩展，以支持大量传输路径、节点和链路。
54 If a control plane is used for MPLS-TP, following a control-plane failure, the control plane MUST be capable of restarting and relearning its previous state without impacting forwarding.
54如果控制平面用于MPLS-TP，在控制平面故障后，控制平面必须能够重新启动并重新学习其先前状态，而不会影响转发。
55 An MPLS-TP control plane MUST provide a mechanism for dynamic ownership transfer of the control of MPLS-TP transport paths from the management plane to the control plane and vice versa. The number of reconfigurations required in the data plane MUST be minimized (preferably no data-plane reconfiguration will be required).
55 MPLS-TP控制平面必须提供一种机制，用于将MPLS-TP传输路径的控制权从管理平面动态转移到控制平面，反之亦然。数据平面中所需的重新配置数量必须最小化（最好不需要重新配置数据平面）。
Network survivability plays a critical role in the delivery of reliable services. Network availability is a significant contributor to revenue and profit. Service guarantees in the form of SLAs require a resilient network that rapidly detects facility or node failures and restores network operation in accordance with the terms of the SLA.
网络生存性在提供可靠服务方面起着关键作用。网络可用性是收入和利润的重要贡献者。SLA形式的服务保证需要一个弹性网络，该网络能够快速检测设施或节点故障，并根据SLA条款恢复网络运行。
56 MPLS-TP MUST provide protection and restoration mechanisms.
56 MPLS-TP必须提供保护和恢复机制。
A. MPLS-TP recovery techniques SHOULD be identical (or as similar as possible) to those already used in existing transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement.
A.MPLS-TP恢复技术应与现有传输网络中已使用的恢复技术相同（或尽可能类似），以简化实施和操作。但是，这不得凌驾于任何其他要求之上。
B. Recovery techniques used for P2P and P2MP SHOULD be identical to simplify implementation and operation. However, this MUST NOT override any other requirement.
B.用于P2P和P2MP的恢复技术应相同，以简化实施和操作。但是，这不得凌驾于任何其他要求之上。
57 MPLS-TP recovery mechanisms MUST be applicable at various levels throughout the network including support for link, transport path, segment, concatenated segment, and end-to-end recovery.
57 MPLS-TP恢复机制必须适用于整个网络的各个级别，包括对链路、传输路径、段、连接段和端到端恢复的支持。
58 MPLS-TP recovery paths MUST meet the SLA protection objectives of the service.
58 MPLS-TP恢复路径必须满足服务的SLA保护目标。
A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery times from the moment of fault detection in networks with spans less than 1200 km.
A.MPLS-TP必须提供机制，以保证在跨度小于1200 km的网络中，从故障检测到故障的那一刻起，恢复时间为50 ms。
B. For protection it MUST be possible to require protection of 100% of the traffic on the protected path.
B.为了进行保护，必须能够要求对受保护路径上的100%流量进行保护。
C. Recovery MUST meet SLA requirements over multiple domains.
C.恢复必须满足跨多个域的SLA要求。
59 Recovery objectives SHOULD be configurable per transport path.
59每个传输路径的恢复目标都应该是可配置的。
60 The recovery mechanisms SHOULD be applicable to any topology.
60恢复机制应适用于任何拓扑。
61 The recovery mechanisms MUST support the means to operate in synergy with (including coordination of timing) the recovery mechanisms present in any client or server transport networks (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions between the layers.
61恢复机制必须支持与任何客户端或服务器传输网络（例如，以太网、SDH、OTN、WDM）中存在的恢复机制协同运行（包括时间协调）的方法，以避免层之间的竞争条件。
62 MPLS-TP recovery and reversion mechanisms MUST prevent frequent operation of recovery in the event of an intermittent defect.
62 MPLS-TP恢复和恢复机制必须防止在出现间歇性缺陷时频繁进行恢复操作。
General protection and survivability requirements are expressed in terms of the behavior in the data plane.
一般保护和生存性需求是根据数据平面中的行为来表示的。
Note: Only nodes that are aware of the pairing relationship between the forward and backward directions of an associated bidirectional transport path can be used as end points to protect all or part of that transport path.
注意：只有知道相关双向传输路径的前向和后向之间的配对关系的节点才能用作保护该传输路径的全部或部分的端点。
63 It MUST be possible to provide protection for the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label.
63必须能够在MPLS-TP数据平面中没有任何IP转发能力的情况下为MPLS-TP数据平面提供保护。即，数据平面仅在MPLS标签上操作。
64 MPLS-TP protection mechanisms MUST support revertive and non-revertive behavior.
64 MPLS-TP保护机制必须支持还原和非还原行为。
65 MPLS-TP MUST support 1+1 protection.
65 MPLS-TP必须支持1+1保护。
A. Bidirectional 1+1 protection for P2P connectivity MUST be supported.
A.必须支持P2P连接的双向1+1保护。
B. Unidirectional 1+1 protection for P2P connectivity MUST be supported.
B.必须支持对P2P连接的单向1+1保护。
C. Unidirectional 1+1 protection for P2MP connectivity MUST be supported.
C.必须支持P2MP连接的单向1+1保护。
66 MPLS-TP MUST support the ability to share protection resources amongst a number of transport paths.
66 MPLS-TP必须支持在多条传输路径之间共享保护资源的能力。
67 MPLS-TP MUST support 1:n protection (including 1:1 protection).
67 MPLS-TP必须支持1:n保护（包括1:1保护）。
A. Bidirectional 1:n protection for P2P connectivity MUST be supported and SHOULD be the default behavior for 1:n protection.
A.必须支持P2P连接的双向1:n保护，并且应为1:n保护的默认行为。
B. Unidirectional 1:n protection for P2MP connectivity MUST be supported.
B.必须支持P2MP连接的单向1:n保护。
C. Unidirectional 1:n protection for P2P connectivity is not required and MAY be omitted from the MPLS-TP specifications.
C.不需要对P2P连接进行单向1:n保护，MPLS-TP规范中可省略该保护。
D. The action of protection-switching MUST NOT cause the user data to enter an uncontrolled loop. The protection-switching system MAY cause traffic to pass over a given link more than once, but it must do so in a controlled way such that uncontrolled loops do not form.
D.保护开关的动作不得导致用户数据进入不受控回路。保护切换系统可能会导致流量多次通过给定链路，但必须以受控方式进行，以避免形成不受控回路。
Note: Support for extra traffic (as defined in [RFC4427]) is not required in MPLS-TP and MAY be omitted from the MPLS-TP specifications.
注：MPLS-TP中不需要对额外流量（如[RFC4427]中所定义）的支持，MPLS-TP规范中可以省略。
68 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery.
68 MPLS-TP应支持1:n（包括1:1）共享网格恢复。
69 MPLS-TP MUST support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources.
69 MPLS-TP必须支持保护资源的共享，以便已知不需要并发的保护路径可以共享相同的资源。
70 The restoration transport path MUST be able to share resources with the transport path being replaced (sometimes known as soft rerouting).
70恢复传输路径必须能够与被替换的传输路径共享资源（有时称为软重路由）。
71 Restoration priority MUST be supported so that an implementation can determine the order in which transport paths should be restored (to minimize service restoration time as well as to gain access to available spare capacity on the best paths).
71必须支持恢复优先级，以便实现可以确定恢复传输路径的顺序（以最大限度地减少服务恢复时间，并获得对最佳路径上可用备用容量的访问）。
72 Preemption priority MUST be supported to allow restoration to displace other transport paths in the event of resource constraint.
72必须支持抢占优先权，以允许在资源受限的情况下恢复以替换其他传输路径。
73 MPLS-TP restoration mechanisms MUST support revertive and non-revertive behavior.
73 MPLS-TP恢复机制必须支持恢复和非恢复行为。
Recovery actions may be triggered from different places as follows:
恢复操作可从以下不同位置触发：
74 MPLS-TP MUST support fault indication triggers from lower layers. This includes faults detected and reported by lower-layer protocols, and faults reported directly by the physical medium (for example, loss of light).
74 MPLS-TP必须支持来自较低层的故障指示触发器。这包括由较低层协议检测和报告的故障，以及由物理介质直接报告的故障（例如，失光）。
75 MPLS-TP MUST support OAM-based triggers.
75 MPLS-TP必须支持基于OAM的触发器。
76 MPLS-TP MUST support management-plane triggers (e.g., forced switch, etc.).
76 MPLS-TP必须支持管理平面触发器（例如强制切换等）。
77 There MUST be a mechanism to distinguish administrative recovery actions from recovery actions initiated by other triggers.
77必须有一种机制来区分行政恢复行动和由其他触发器启动的恢复行动。
78 Where a control plane is present, MPLS-TP SHOULD support control-plane restoration triggers.
78当存在控制平面时，MPLS-TP应支持控制平面恢复触发器。
79 MPLS-TP protection mechanisms MUST support priority logic to negotiate and accommodate coexisting requests (i.e., multiple requests) for protection-switching (e.g., administrative requests and requests due to link/node failures).
79 MPLS-TP保护机制必须支持优先级逻辑，以协商和适应保护切换的共存请求（即多个请求）（例如，管理请求和由于链路/节点故障引起的请求）。
All functions described here are for control by the operator.
此处描述的所有功能均由操作员控制。
80 It MUST be possible to configure protection paths and protection-to-working path relationships (sometimes known as protection groups).
80必须能够配置保护路径和保护到工作路径关系（有时称为保护组）。
81 There MUST be support for pre-calculation of recovery paths.
81必须支持恢复路径的预计算。
82 There MUST be support for pre-provisioning of recovery paths.
82必须支持预设置恢复路径。
83 The external controls as defined in [RFC4427] MUST be supported.
83必须支持[RFC4427]中定义的外部控制。
A. External controls overruled by higher priority requests (e.g., administrative requests and requests due to link/node failures) or unable to be signaled to the remote end (e.g., due to a coordination failure of the protection state) MUST be dropped.
A.必须放弃被更高优先级请求（例如，管理请求和由于链路/节点故障导致的请求）否决的外部控制，或无法向远程端发送信号的外部控制（例如，由于保护状态的协调故障）。
84 It MUST be possible to test and validate any protection/ restoration mechanisms and protocols:
84必须能够测试和验证任何保护/恢复机制和协议：
A. Including the integrity of the protection/recovery transport path.
A.包括保护/恢复传输路径的完整性。
B. Without triggering the actual protection/restoration.
B.不触发实际保护/恢复。
C. While the working path is in service.
C.当工作路径处于服务状态时。
D. While the working path is out of service.
D.当工作路径停止工作时。
85 Restoration resources MAY be pre-planned and selected a priori, or computed after failure occurrence.
85恢复资源可以预先规划和选择，或者在故障发生后计算。
86 When preemption is supported for restoration purposes, it MUST be possible for the operator to configure it.
86当出于恢复目的支持抢占时，操作员必须能够对其进行配置。
87 The management plane MUST provide indications of protection events and triggers.
87管理层必须提供保护事件和触发器的指示。
88 The management plane MUST allow the current protection status of all transport paths to be determined.
88管理平面必须允许确定所有传输路径的当前保护状态。
89 The MPLS-TP control plane (which is not mandatory in an MPLS-TP implementation) MUST be capable of supporting:
89 MPLS-TP控制平面（在MPLS-TP实施中不是强制性的）必须能够支持：
A. establishment and maintenance of all recovery entities and functions
A.建立和维持所有恢复实体和职能
B. signaling of administrative control
B.行政控制的信号
C. protection state coordination (PSC). Since control plane network topology is independent from the data plane network topology, the PSC supported by the MPLS-TP control plane MAY run on resources different than the data plane resources handled within the recovery mechanism (e.g., backup).
C.保护状态协调（PSC）。由于控制平面网络拓扑独立于数据平面网络拓扑，因此MPLS-TP控制平面支持的PSC可以在不同于恢复机制内处理的数据平面资源（例如备份）的资源上运行。
90 In-band OAM MUST be capable of supporting:
90带内OAM必须能够支持：
A. signaling of administrative control
A.行政控制的信号
B. protection state coordination (PSC). Since in-band OAM tools share the data plane with the carried transport service, in order to optimize the usage of network resources, the PSC supported by in-band OAM MUST run on protection resources.
B.保护状态协调（PSC）。由于带内OAM工具与承载的传输服务共享数据平面，为了优化网络资源的使用，带内OAM支持的PSC必须在保护资源上运行。
91 MPLS-TP MAY support recovery mechanisms that are optimized for specific network topologies. These mechanisms MUST be interoperable with the mechanisms defined for arbitrary topology (mesh) networks to enable protection of end-to-end transport paths.
91 MPLS-TP可支持针对特定网络拓扑优化的恢复机制。这些机制必须与为任意拓扑（mesh）网络定义的机制互操作，以实现端到端传输路径的保护。
Several service providers have expressed a high level of interest in operating MPLS-TP in ring topologies and require a high level of survivability function in these topologies. The requirements listed below have been collected from these service providers and from the ITU-T.
一些服务提供商对在环形拓扑中运行MPLS-TP表示了高度的兴趣，并要求在这些拓扑中具有高级别的生存性功能。下列要求是从这些服务提供商和ITU-T收集的。
The main objective in considering a specific topology (such as a ring) is to determine whether it is possible to optimize any mechanisms such that the performance of those mechanisms within the topology is significantly better than the performance of the generic mechanisms in the same topology. The benefits of such optimizations are traded against the costs of developing, implementing, deploying, and operating the additional optimized mechanisms noting that the generic mechanisms MUST continue to be supported.
考虑特定拓扑（如环）的主要目标是确定是否有可能优化任何机制，从而使拓扑中的这些机制的性能明显优于相同拓扑中的通用机制的性能。这种优化的好处与开发、实施、部署和运行额外优化机制的成本进行了权衡，注意到必须继续支持通用机制。
Within the context of recovery in MPLS-TP networks, the optimization criteria considered in ring topologies are as follows:
在MPLS-TP网络中的恢复环境中，环形拓扑中考虑的优化标准如下：
a. Minimize the number of OAM entities that are needed to trigger the recovery operation, such that it is less than is required by other recovery mechanisms.
a. 尽量减少触发恢复操作所需的OAM实体的数量，使其少于其他恢复机制所需的数量。
b. Minimize the number of elements of recovery in the ring, such that it is less than is required by other recovery mechanisms.
b. 尽可能减少环中恢复元素的数量，使其少于其他恢复机制所需的数量。
c. Minimize the number of labels required for the protection paths across the ring, such that it is less than is required by other recovery mechanisms.
c. 尽可能减少环上保护路径所需的标签数量，使其少于其他恢复机制所需的数量。
d. Minimize the amount of control and management-plane transactions during a maintenance operation (e.g., ring upgrade), such that it is less than the amount required by other recovery mechanisms.
d. 在维护操作（例如，环升级）期间，尽量减少控制和管理平面事务的数量，使其小于其他恢复机制所需的数量。
e. When a control plane is supported, minimize the impact on signaling and routing information exchange during protection, such that it is less than the impact caused by other recovery mechanisms.
e. 当支持控制平面时，将保护期间对信令和路由信息交换的影响降至最低，以使其小于其他恢复机制造成的影响。
It may be observed that the requirements in Section 2.5.6.1 are fully compatible with the generic requirements expressed in Section 2.5 through Section 2.5.6 inclusive, and that no requirements that are specific to ring topologies have been identified.
可以观察到，第2.5.6.1节中的要求与第2.5节至第2.5.6节（含第2.5.6节）中表达的通用要求完全兼容，并且未确定特定于环形拓扑的要求。
92 MPLS-TP MUST include recovery mechanisms that operate in any single ring supported in MPLS-TP, and continue to operate within the single rings even when the rings are interconnected.
92 MPLS-TP必须包括在MPLS-TP支持的任何单环中运行的恢复机制，并且即使在环互连时仍在单环中运行。
93 When a network is constructed from interconnected rings, MPLS-TP MUST support recovery mechanisms that protect user data that traverses more than one ring. This includes the possibility of failure of the ring-interconnect nodes and links.
93当网络由互连环构成时，MPLS-TP必须支持保护穿越多个环的用户数据的恢复机制。这包括环形互连节点和链路发生故障的可能性。
94 MPLS-TP recovery in a ring MUST protect unidirectional and bidirectional P2P transport paths.
94环中的MPLS-TP恢复必须保护单向和双向P2P传输路径。
95 MPLS-TP recovery in a ring MUST protect unidirectional P2MP transport paths.
环中的95 MPLS-TP恢复必须保护单向P2MP传输路径。
96 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching time within 50 ms from the moment of fault detection in a network with a 16-node ring with less than 1200 km of fiber.
96环中的MPLS-TP 1+1和1:1保护必须支持从故障检测时刻起50 ms内的切换时间，该网络具有16节点环，光纤长度小于1200 km。
97 The protection switching time in a ring MUST be independent of the number of LSPs crossing the ring.
97环中的保护切换时间必须与穿过环的LSP数量无关。
98 The configuration and operation of recovery mechanisms in a ring MUST scale well with:
98环中回收机构的配置和操作必须符合以下要求：
A. the number of transport paths (MUST be better than linear scaling)
A.传输路径的数量（必须优于线性缩放）
B. the number of nodes on the ring (MUST be at least as good as linear scaling)
B.环上的节点数（必须至少与线性缩放相同）
C. the number of ring interconnects (MUST be at least as good as linear scaling)
C.环形互连的数量（必须至少与线性缩放一样好）
99 Recovery techniques used in a ring MUST NOT prevent the ring from being connected to a general MPLS-TP network in any arbitrary way, and MUST NOT prevent the operation of recovery techniques in the rest of the network.
99环中使用的恢复技术不得阻止环以任何任意方式连接到一般MPLS-TP网络，也不得阻止恢复技术在网络其余部分的操作。
100 Recovery techniques in a ring SHOULD be identical (or as similar as possible) to those in general transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement.
100环中的恢复技术应与一般传输网络中的恢复技术相同（或尽可能相似），以简化实施和操作。但是，这不得凌驾于任何其他要求之上。
101 Recovery techniques in logical and physical rings SHOULD be identical to simplify implementation and operation. However, this MUST NOT override any other requirement.
101逻辑环和物理环中的恢复技术应该相同，以简化实现和操作。但是，这不得凌驾于任何其他要求之上。
102 The default recovery scheme in a ring MUST be bidirectional recovery in order to simplify the recovery operation.
102为了简化恢复操作，环中的默认恢复方案必须是双向恢复。
103 The recovery mechanism in a ring MUST support revertive switching, which MUST be the default behavior. This allows optimization of the use of the ring resources, and restores the preferred quality conditions for normal traffic (e.g., delay) when the recovery mechanism is no longer needed.
103环中的恢复机制必须支持恢复切换，这必须是默认行为。这允许优化环资源的使用，并在不再需要恢复机制时恢复正常业务（例如，延迟）的首选质量条件。
104 The recovery mechanisms in a ring MUST support ways to distinguish administrative protection-switching from protection-switching initiated by other triggers.
104环中的恢复机制必须支持区分管理保护切换和由其他触发器启动的保护切换的方法。
105 It MUST be possible to lockout (disable) protection mechanisms on selected links (spans) in a ring (depending on the operator's need). This may require lockout mechanisms to be applied to intermediate nodes within a transport path.
105必须能够锁定（禁用）环中选定链路（跨度）上的保护机制（取决于操作员的需要）。这可能需要将锁定机制应用于传输路径内的中间节点。
106 MPLS-TP recovery mechanisms in a ring:
106环中的MPLS-TP恢复机制：
A. MUST include a mechanism to allow an implementation to handle and coordinate coexisting requests or triggers for protection-switching based on priority. (For example, this includes multiple requests that are not necessarily arriving simultaneously and that are located anywhere in the ring.) Note that such coordination of the ring is equivalent to the use of shared protection groups.
A.必须包括一种机制，允许实现根据优先级处理和协调保护切换的共存请求或触发器。（例如，这包括不一定同时到达且位于环中任何位置的多个请求。）请注意，环的这种协调相当于使用共享保护组。
B. SHOULD protect against multiple failures
B.应防止多重故障
107 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a way to prevent frequent operation of recovery in the event of an intermittent defect.
107环中的MPLS-TP恢复和恢复机制必须提供一种方法，以防止在发生间歇性缺陷时频繁进行恢复操作。
108 MPLS-TP MUST support the sharing of protection bandwidth in a ring by allowing best-effort traffic.
108 MPLS-TP必须通过允许尽力而为的流量来支持环中保护带宽的共享。
109 MPLS-TP MUST support sharing of ring protection resources such that protection paths that are known not to be required concurrently can share the same resources.
109 MPLS-TP必须支持环保护资源的共享，以便已知不需要同时使用的保护路径可以共享相同的资源。
Carriers require advanced traffic-management capabilities to enforce and guarantee the QoS parameters of customers' SLAs.
运营商需要先进的流量管理能力来实施和保证客户SLA的QoS参数。
Quality-of-service mechanisms are REQUIRED in an MPLS-TP network to ensure:
MPLS-TP网络中需要服务质量机制，以确保：
110 Support for differentiated services and different traffic types with traffic class separation associated with different traffic.
110对区分服务和不同流量类型的支持，以及与不同流量相关的流量分类。
111 Enabling the provisioning and the guarantee of Service Level Specifications (SLSs), with support for hard and relative end-to-end bandwidth guaranteed.
111支持服务级别规范（SLS）的提供和保证，并保证对硬带宽和相对端到端带宽的支持。
112 Support of services, which are sensitive to jitter and delay.
112支持对抖动和延迟敏感的服务。
113 Guarantee of fair access, within a particular class, to shared resources.
113保证在特定类别内公平访问共享资源。
114 Guaranteed resources for in-band control and management-plane traffic, regardless of the amount of data-plane traffic.
114带内控制和管理平面通信的保证资源，无论数据平面通信量如何。
115 Carriers are provided with the capability to efficiently support service demands over the MPLS-TP network. This MUST include support for a flexible bandwidth allocation scheme.
115个运营商具备通过MPLS-TP网络有效支持服务需求的能力。这必须包括对灵活带宽分配方案的支持。
For requirements related to network management functionality (Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP Network Management requirements document [TP-NM-REQ].
有关MPLS-TP网络管理功能（ITU-T术语中的管理平面）的相关要求，请参阅MPLS-TP网络管理要求文件[TP-NM-REQ]。
For requirements related to OAM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [TP-OAM-REQS].
有关MPLS-TP的OAM功能的要求，请参阅MPLS-TP OAM要求文档[TP-OAM-REQS]。
For requirements related to performance-monitoring functionality for MPLS-TP, see the MPLS-TP OAM requirements document [TP-OAM-REQS].
有关MPLS-TP性能监控功能的要求，请参阅MPLS-TP OAM要求文档[TP-OAM-REQS]。
For a description of the security threats relevant in the context of MPLS and GMPLS and the defensive techniques to combat those threats, see "Security Framework for MPLS and GMPLS Networks" [G/MPLS-SEC].
有关MPLS和GMPLS环境中相关安全威胁的描述以及应对这些威胁的防御技术，请参阅“MPLS和GMPLS网络的安全框架”[G/MPLS-SEC]。
For a description of additional security threats relevant in the context of MPLS-TP and the defensive techniques to combat those threats see "Security Framework for MPLS-TP" [TP-SEC-FMWK].
有关MPLS-TP环境中相关的其他安全威胁以及应对这些威胁的防御技术的说明，请参阅“MPLS-TP安全框架”[TP-SEC-FMWK]。
See Section 3.4.
见第3.4节。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in the IETF, and the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and specification of the MPLS Transport Profile.
作者要感谢参与MPLS传输概要定义和规范的所有团队成员（联合工作团队、IETF中的MPLS互操作性设计团队和ITU-T中的T-MPLS特设小组）。
The authors would also like to thank Loa Andersson, Dieter Beller, Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve Varma, and Maarten Vissers for their comments and enhancements to the text.
作者还要感谢Loa Andersson、Dieter Beller、Lou Berger、Italo Busi、John Drake、Adrian Farrel、Annamaria Fulignoli、Pietro Grandi、Eric Gray、Neil Harrison、Jia He、Huub van Helvoort、Enrique Hernandez Valencia、Wataru Imajuku、Kam Lam、Andy Malis、Alan McGuire、Julien Meuria、Greg Mirsky、Tom Nadeau、Hiroshi Ohta、Tom Petch、，Andy Reid、Vincenzo Sestito、George Swallow、Lubo Tancevski、Tomonori Takeda、Yuji Tochio、Alexander Vainstein、Eve Varma和Maarten Vissers感谢他们对文本的评论和改进。
An ad hoc discussion group consisting of Stewart Bryant, Italo Busi, Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, Feng Huang, Harald Kullman, Han Li, Hao Long, and Nurit Sprecher provided valuable input to the requirements for deployment and survivability in ring topologies.
由Stewart Bryant、Italo Busi、Andrea Digiglio、Li Fang、Adrian Farrel、Jia He、Huub van Helvoort、Feng Huang、Harald Kullman、Han Li、Hao Long和Nurit Sprecher组成的特设讨论组为环形拓扑的部署和生存能力需求提供了宝贵的意见。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[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月。
[RFC4929] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929]Andersson，L.和A.Farrel，“多协议标签交换（MPLS）和通用MPLS（GMPLS）协议和程序的变更过程”，BCP 129，RFC 49292007年6月。
[ITU.G805.2000] International Telecommunications Union, "Generic functional architecture of transport networks", ITU-T Recommendation G.805, March 2000.
[ITU.G805.2000]国际电信联盟，“传输网络的通用功能架构”，ITU-T建议G.805，2000年3月。
[ITU.G8080.2006] International Telecommunications Union, "Architecture for the automatically switched optical network (ASON)", ITU-T Recommendation G.8080, June 2006.
[ITU.G8080.2006]国际电信联盟，“自动交换光网络（ASON）架构”，ITU-T建议G.8080，2006年6月。
[ITU.G8080.2008] International Telecommunications Union, "Architecture for the automatically switched optical network (ASON) Amendment 1", ITU-T Recommendation G.8080 Amendment 1, March 2008.
[ITU.G8080.2008]国际电信联盟，“自动交换光网络（ASON）体系结构修正案1”，ITU-T建议G.8080修正案1，2008年3月。
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005.
[RFC4139]Papadimitriou，D.，Drake，J.，Ash，J.，Farrel，A.，和L.Ong，“自动交换光网络（ASON）的通用MPLS（GMPLS）信令使用和扩展要求”，RFC 4139，2005年7月。
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258]Brungard，D.“自动交换光网络（ASON）的通用多协议标签交换（GMPLS）路由要求”，RFC 4258，2005年11月。
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006.
[RFC4397]Bryskin，I.和A.Farrel，“在ITU-T自动交换光网络（ASON）体系结构背景下解释通用多协议标签交换（GMPLS）术语的词典编纂”，RFC 4397，2006年2月。
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]Mannie，E.和D.Papadimitriou，“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月。
[TP-SEC-FMWK] Fang, L. and B. Niven-Jenkins, "Security Framework for MPLS-TP", Work in Progress, July 2009.
[TP-SEC-FMWK]Fang，L.和B.Niven Jenkins，“MPLS-TP的安全框架”，正在进行的工作，2009年7月。
[G/MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2009.
[G/MPLS-SEC]Fang，L.，编辑，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2009年7月。
[TP-NM-REQ] Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network Management Requirements", Work in Progress, June 2009.
[TP-NM-REQ]Lam，H.，Mansfield，S.，和E.Gray，“MPLS TP网络管理要求”，正在进行的工作，2009年6月。
[TP-TERMS] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "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, June 2009.
[TP-TERMS]van Helvoort，H.，Ed.，Andersson，L.，Ed.，和N.Sprecher，Ed.，“多协议标签交换传输配置文件（MPLS-TP）草案/RFC和ITU-T传输网络建议中使用的术语词典”，正在进行的工作，2009年6月。
[TP-OAM-REQS] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for OAM in MPLS Transport Networks", Work in Progress, June 2009.
[TP-OAM-REQS]Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的OAM要求”，正在进行的工作，2009年6月。
[MS-PW-ARCH] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", Work in Progress, July 2009.
[MS-PW-ARCH]Bocci，M.和S.Bryant，“多段伪线边到边仿真的体系结构”，正在进行的工作，2009年7月。
[ITU.Y1401.2008] International Telecommunications Union, "Principles of interworking", ITU-T Recommendation Y.1401, February 2008.
[ITU.Y1401.2008]国际电信联盟，“互通原则”，ITU-T建议Y.14012008年2月。
[ITU.Y2611.2006] International Telecommunications Union, "High-level architecture of future packet-based networks", ITU-T Recommendation Y.2611, December 2006.
[ITU.Y2611.2006]国际电信联盟，“未来基于分组的网络的高级架构”，ITU-T建议Y.2611，2006年12月。
Authors' Addresses
作者地址
Ben Niven-Jenkins (editor) BT PP8a, 1st Floor, Orion Building, Adastral Park Ipswich, Suffolk IP5 3RE UK
Ben Niven Jenkins（编辑）英国电信PP8a，英国萨福克郡伊普斯维奇阿达斯特拉尔公园猎户座大厦一楼IP5 3RE
EMail: benjamin.niven-jenkins@bt.com
EMail: benjamin.niven-jenkins@bt.com
Deborah Brungard (editor) AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748 USA
黛博拉·布伦加德（编辑）美国电话电报公司Rm。D1-3C22-美国新泽西州米德尔顿市劳雷尔大道南200号，邮编07748
EMail: dbrungard@att.com
EMail: dbrungard@att.com
Malcolm Betts (editor) Huawei Technologies
Malcolm Betts（编辑）华为技术
EMail: malcolm.betts@huawei.com
EMail: malcolm.betts@huawei.com
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel
Nurit Sprecher诺基亚西门子网络3号哈纳加圣内韦-内曼B Hod Hasharon，以色列45241
EMail: nurit.sprecher@nsn.com
EMail: nurit.sprecher@nsn.com
Satoshi Ueno NTT Communications
Satoshi Ueno NTT通信公司
EMail: satoshi.ueno@ntt.com
EMail: satoshi.ueno@ntt.com