Internet Engineering Task Force (IETF) N. Sprecher, Ed.
Request for Comments: 6372 Nokia Siemens Networks
Category: Informational A. Farrel, Ed.
ISSN: 2070-1721 Juniper Networks
September 2011
Internet Engineering Task Force (IETF) N. Sprecher, Ed.
Request for Comments: 6372 Nokia Siemens Networks
Category: Informational A. Farrel, Ed.
ISSN: 2070-1721 Juniper Networks
September 2011
MPLS Transport Profile (MPLS-TP) Survivability Framework
MPLS传输配置文件（MPLS-TP）生存性框架
Abstract
摘要
Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.
网络生存性是指网络在网络资源发生故障或退化后恢复通信量交付的能力。生存性对于提供有保障的网络服务至关重要，例如受严格服务水平协议（SLA）约束的网络服务，这些协议对服务可能降级或不可用的时间长度设定了最大限制。
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.
多协议标签交换（MPLS-TP）传输配置文件是一种基于MPLS数据平面的基于分组的传输技术，可重用MPLS管理和控制平面的许多方面。
This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.
本文件包括在MPLS-TP网络中提供生存性的框架；它描述了恢复元素、类型、方法和拓扑注意事项。为了实现数据平面恢复，可通过控制平面、管理平面以及操作、管理和维护（OAM）功能来支持生存性。本文档描述了恢复MPLS-TP标签交换路径（LSP）的机制。对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-based 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
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非所有文件
approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
经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/rfc6372.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6372.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Recovery Schemes ...........................................4
1.2. Recovery Action Initiation .................................5
1.3. Recovery Context ...........................................6
1.4. Scope of This Framework ....................................7
2. Terminology and References ......................................8
3. Requirements for Survivability .................................10
4. Functional Architecture ........................................10
4.1. Elements of Control .......................................10
4.1.1. Operator Control ...................................11
4.1.2. Defect-Triggered Actions ...........................12
4.1.3. OAM Signaling ......................................12
4.1.4. Control-Plane Signaling ............................12
4.2. Recovery Scope ............................................13
4.2.1. Span Recovery ......................................13
4.2.2. Segment Recovery ...................................13
4.2.3. End-to-End Recovery ................................14
4.3. Grades of Recovery ........................................15
4.3.1. Dedicated Protection ...............................15
4.3.2. Shared Protection ..................................16
4.3.3. Extra Traffic ......................................17
4.3.4. Restoration ........................................19
4.3.5. Reversion ..........................................20
4.4. Mechanisms for Protection .................................20
1. Introduction ....................................................4
1.1. Recovery Schemes ...........................................4
1.2. Recovery Action Initiation .................................5
1.3. Recovery Context ...........................................6
1.4. Scope of This Framework ....................................7
2. Terminology and References ......................................8
3. Requirements for Survivability .................................10
4. Functional Architecture ........................................10
4.1. Elements of Control .......................................10
4.1.1. Operator Control ...................................11
4.1.2. Defect-Triggered Actions ...........................12
4.1.3. OAM Signaling ......................................12
4.1.4. Control-Plane Signaling ............................12
4.2. Recovery Scope ............................................13
4.2.1. Span Recovery ......................................13
4.2.2. Segment Recovery ...................................13
4.2.3. End-to-End Recovery ................................14
4.3. Grades of Recovery ........................................15
4.3.1. Dedicated Protection ...............................15
4.3.2. Shared Protection ..................................16
4.3.3. Extra Traffic ......................................17
4.3.4. Restoration ........................................19
4.3.5. Reversion ..........................................20
4.4. Mechanisms for Protection .................................20
4.4.1. Link-Level Protection ..............................20
4.4.2. Alternate Paths and Segments .......................21
4.4.3. Protection Tunnels .................................22
4.5. Recovery Domains ..........................................23
4.6. Protection in Different Topologies ........................24
4.7. Mesh Networks .............................................25
4.7.1. 1:n Linear Protection ..............................26
4.7.2. 1+1 Linear Protection ..............................28
4.7.3. P2MP Linear Protection .............................29
4.7.4. Triggers for the Linear Protection
Switching Action ...................................30
4.7.5. Applicability of Linear Protection for LSP
Segments ...........................................31
4.7.6. Shared Mesh Protection .............................32
4.8. Ring Networks .............................................33
4.9. Recovery in Layered Networks ..............................34
4.9.1. Inherited Link-Level Protection ....................35
4.9.2. Shared Risk Groups .................................35
4.9.3. Fault Correlation ..................................36
5. Applicability and Scope of Survivability in MPLS-TP ............37
6. Mechanisms for Providing Survivability for MPLS-TP LSPs ........39
6.1. Management Plane ..........................................39
6.1.1. Configuration of Protection Operation ..............40
6.1.2. External Manual Commands ...........................41
6.2. Fault Detection ...........................................41
6.3. Fault Localization ........................................42
6.4. OAM Signaling .............................................43
6.4.1. Fault Detection ....................................44
6.4.2. Testing for Faults .................................44
6.4.3. Fault Localization .................................45
6.4.4. Fault Reporting ....................................45
6.4.5. Coordination of Recovery Actions ...................46
6.5. Control Plane .............................................46
6.5.1. Fault Detection ....................................47
6.5.2. Testing for Faults .................................47
6.5.3. Fault Localization .................................48
6.5.4. Fault Status Reporting .............................48
6.5.5. Coordination of Recovery Actions ...................49
6.5.6. Establishment of Protection and Restoration LSPs ...49
7. Pseudowire Recovery Considerations .............................50
7.1. Utilization of Underlying MPLS-TP Recovery ................50
7.2. Recovery in the Pseudowire Layer ..........................51
8. Manageability Considerations ...................................51
9. Security Considerations ........................................52
10. Acknowledgments ...............................................52
11. References ....................................................53
11.1. Normative References .....................................53
11.2. Informative References ...................................54
4.4.1. Link-Level Protection ..............................20
4.4.2. Alternate Paths and Segments .......................21
4.4.3. Protection Tunnels .................................22
4.5. Recovery Domains ..........................................23
4.6. Protection in Different Topologies ........................24
4.7. Mesh Networks .............................................25
4.7.1. 1:n Linear Protection ..............................26
4.7.2. 1+1 Linear Protection ..............................28
4.7.3. P2MP Linear Protection .............................29
4.7.4. Triggers for the Linear Protection
Switching Action ...................................30
4.7.5. Applicability of Linear Protection for LSP
Segments ...........................................31
4.7.6. Shared Mesh Protection .............................32
4.8. Ring Networks .............................................33
4.9. Recovery in Layered Networks ..............................34
4.9.1. Inherited Link-Level Protection ....................35
4.9.2. Shared Risk Groups .................................35
4.9.3. Fault Correlation ..................................36
5. Applicability and Scope of Survivability in MPLS-TP ............37
6. Mechanisms for Providing Survivability for MPLS-TP LSPs ........39
6.1. Management Plane ..........................................39
6.1.1. Configuration of Protection Operation ..............40
6.1.2. External Manual Commands ...........................41
6.2. Fault Detection ...........................................41
6.3. Fault Localization ........................................42
6.4. OAM Signaling .............................................43
6.4.1. Fault Detection ....................................44
6.4.2. Testing for Faults .................................44
6.4.3. Fault Localization .................................45
6.4.4. Fault Reporting ....................................45
6.4.5. Coordination of Recovery Actions ...................46
6.5. Control Plane .............................................46
6.5.1. Fault Detection ....................................47
6.5.2. Testing for Faults .................................47
6.5.3. Fault Localization .................................48
6.5.4. Fault Status Reporting .............................48
6.5.5. Coordination of Recovery Actions ...................49
6.5.6. Establishment of Protection and Restoration LSPs ...49
7. Pseudowire Recovery Considerations .............................50
7.1. Utilization of Underlying MPLS-TP Recovery ................50
7.2. Recovery in the Pseudowire Layer ..........................51
8. Manageability Considerations ...................................51
9. Security Considerations ........................................52
10. Acknowledgments ...............................................52
11. References ....................................................53
11.1. Normative References .....................................53
11.2. Informative References ...................................54
Network survivability is the network's ability to recover traffic delivery following the failure or degradation of traffic delivery caused by a network fault or a denial-of-service attack on the network. Survivability plays a critical role in the delivery of reliable services in transport networks. Guaranteed services in the form of Service Level Agreements (SLAs) require a resilient network that very rapidly detects facility or node degradation or failures, and immediately starts to recover network operations in accordance with the terms of the SLA.
网络生存性是指在网络故障或拒绝服务攻击导致流量传输失败或降级后，网络恢复流量传输的能力。生存性在传输网络中提供可靠服务方面起着关键作用。以服务水平协议（SLA）形式提供的有保障服务需要一个弹性网络，该网络能够非常快速地检测设施或节点降级或故障，并根据SLA的条款立即开始恢复网络运行。
The MPLS Transport Profile (MPLS-TP) is described in [RFC5921]. MPLS-TP is designed to be consistent with existing transport network operations and management models, while providing survivability mechanisms, such as protection and restoration. The functionality provided is intended to be similar to or better than that found in established transport networks that set a high benchmark for reliability. That is, it is intended to provide the operator with functions with which they are familiar through their experience with other transport networks, although this does not preclude additional techniques.
[RFC5921]中描述了MPLS传输配置文件（MPLS-TP）。MPLS-TP旨在与现有传输网络运营和管理模型保持一致，同时提供保护和恢复等生存机制。所提供的功能旨在类似于或优于为可靠性设定高基准的已建立传输网络中的功能。也就是说，它旨在向运营商提供他们通过其他传输网络的经验熟悉的功能，尽管这并不排除其他技术。
This document provides a framework for MPLS-TP-based survivability that meets the recovery requirements specified in [RFC5654]. It uses the recovery terminology defined in [RFC4427], which draws heavily on [G.808.1], and it refers to the requirements specified in [RFC5654].
本文档提供了一个基于MPLS TP的可生存性框架，该框架满足[RFC5654]中规定的恢复要求。它使用了[RFC4427]中定义的恢复术语，该术语大量借鉴了[G.808.1]，并引用了[RFC5654]中规定的要求。
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-based transport network, as defined by the ITU-T.
本文件是联合互联网工程任务组（IETF）/国际电信联盟电信标准化部门（ITU-T）努力的成果，旨在将MPLS传输配置文件纳入IETF MPLS和PWE3体系结构，以支持基于分组的传输网络的能力和功能，根据ITU-T的定义。
Various recovery schemes (for protection and restoration) and processes have been defined and analyzed in [RFC4427] and [RFC4428]. These schemes can also be applied in MPLS-TP networks to re-establish end-to-end traffic delivery according to the agreed service parameters, and to trigger recovery from "failed" or "degraded" transport entities. In the context of this document, transport entities are nodes, links, transport path segments, concatenated transport path segments, and entire transport paths. Recovery actions are initiated by the detection of a defect, or by an external request (e.g., an operator's request for manual control of protection switching).
[RFC4427]和[RFC4428]中定义并分析了各种恢复方案（用于保护和恢复）和过程。这些方案还可以应用于MPLS-TP网络中，以根据商定的服务参数重新建立端到端业务交付，并触发从“故障”或“降级”传输实体的恢复。在本文档的上下文中，传输实体是节点、链接、传输路径段、连接的传输路径段和整个传输路径。通过检测缺陷或外部请求（例如，操作员请求手动控制保护开关）启动恢复操作。
[RFC4427] makes a distinction between protection switching and restoration mechanisms.
[RFC4427]对保护切换和恢复机制进行了区分。
- Protection switching uses pre-assigned capacity between nodes, where the simplest scheme has a single, dedicated protection entity for each working entity, while the most complex scheme has m protection entities shared between n working entities (m:n).
- 保护切换在节点之间使用预先分配的容量，其中最简单的方案为每个工作实体提供一个单独的专用保护实体，而最复杂的方案在n个工作实体（m:n）之间共享m个保护实体。
- Restoration uses any capacity available between nodes and usually involves rerouting. The resources used for restoration may be pre-planned (i.e., predetermined, but not yet allocated to the recovery path), and recovery priority may be used as a differentiation mechanism to determine which services are recovered and which are not recovered.
- 恢复使用节点之间的任何可用容量，通常涉及重新路由。用于恢复的资源可以是预先规划的（即，预定的，但尚未分配给恢复路径），并且恢复优先级可以用作区分机制，以确定哪些服务被恢复，哪些服务未被恢复。
Both protection switching and restoration may be either unidirectional or bidirectional; unidirectional implies that protection switching is performed independently for each direction of a bidirectional transport path, while bidirectional means that both directions are switched simultaneously using appropriate coordination, even if the fault applies to only one direction of the path.
保护切换和恢复可以是单向的，也可以是双向的；单向意味着对双向传输路径的每个方向独立地执行保护切换，而双向意味着使用适当的协调同时切换两个方向，即使故障仅适用于路径的一个方向。
Both protection and restoration mechanisms may be either revertive or non-revertive as described in Section 4.11 of [RFC4427].
如[RFC4427]第4.11节所述，保护和恢复机制可以是可逆的或非可逆的。
Preemption priority may be used to determine which services are sacrificed to enable the recovery of other services. Restoration may also be either unidirectional or bidirectional. In general, protection actions are completed within time frames amounting to tens of milliseconds, while automated restoration actions are normally completed within periods ranging from hundreds of milliseconds to a maximum of a few seconds. Restoration is not guaranteed (for example, because network resources may not be available at the time of the defect).
抢占优先级可用于确定牺牲哪些服务以实现其他服务的恢复。恢复也可以是单向的或双向的。一般来说，保护操作在数十毫秒的时间范围内完成，而自动恢复操作通常在数百毫秒到最多几秒钟的时间范围内完成。无法保证恢复（例如，因为网络资源在出现缺陷时可能不可用）。
The recovery schemes described in [RFC4427] and evaluated in [RFC4428] are presented in the context of control-plane-driven actions (such as the configuration of the protection entities and functions, etc.). The presence of a distributed control plane in an MPLS-TP network is optional. However, the absence of such a control plane does not affect the operation of the network and the use of MPLS-TP forwarding, Operations, Administration, and Maintenance (OAM), and survivability capabilities. In particular, the concepts
[RFC4427]中描述并在[RFC4428]中评估的恢复方案是在控制平面驱动动作（如保护实体和功能的配置等）的背景下提出的。MPLS-TP网络中是否存在分布式控制平面是可选的。然而，缺少这样的控制平面并不影响网络的操作以及MPLS-TP转发、操作、管理和维护（OAM）以及生存能力的使用。特别是概念
discussed in [RFC4427] and [RFC4428] refer to recovery actions effected in the data plane; they are equally applicable in MPLS-TP, with or without the use of a control plane.
[RFC4427]和[RFC4428]中讨论的是数据平面中影响的恢复操作；无论是否使用控制平面，它们同样适用于MPLS-TP。
Thus, some of the MPLS-TP recovery mechanisms do not depend on a control plane and use MPLS-TP OAM mechanisms or management actions to trigger recovery actions.
因此，一些MPLS-TP恢复机制不依赖于控制平面，而是使用MPLS-TP OAM机制或管理动作来触发恢复动作。
The principles of MPLS-TP protection-switching actions are similar to those described in [RFC4427], since the protection mechanism is based on the capability to detect certain defects in the transport entities within the recovery domain. The protection-switching controller does not care which initiation method is used, provided that it can be given information about the status of the transport entities within the recovery domain (e.g., OK, signal failure, signal degradation, etc.).
MPLS-TP保护切换动作的原理类似于[RFC4427]中所述，因为保护机制基于检测恢复域内传输实体中某些缺陷的能力。保护切换控制器不关心使用哪种启动方法，前提是可以向其提供关于恢复域内传输实体的状态的信息（例如，OK、信号故障、信号降级等）。
In the context of MPLS-TP, it is imperative to ensure that performing switchovers is possible, regardless of the way in which the network is configured and managed (for example, regardless of whether a control-plane, management-plane, or OAM initiation mechanism is used).
在MPLS-TP的上下文中，必须确保执行切换是可能的，而不管网络的配置和管理方式如何（例如，不管是否使用控制平面、管理平面或OAM发起机制）。
All MPLS and GMPLS protection mechanisms [RFC4428] are applicable in an MPLS-TP environment. It is also possible to provision and manage the related protection entities and functions defined in MPLS and GMPLS using the management plane [RFC5654]. Regardless of whether an OAM, management, or control plane initiation mechanism is used, the protection-switching operation is a data-plane operation.
所有MPLS和GMPLS保护机制[RFC4428]都适用于MPLS-TP环境。还可以使用管理平面[RFC5654]提供和管理MPLS和GMPLS中定义的相关保护实体和功能。无论是使用OAM、管理还是控制平面启动机制，保护切换操作都是数据平面操作。
In some recovery schemes (such as bidirectional protection switching), it is necessary to coordinate the protection state between the edges of the recovery domain to achieve initiation of recovery actions for both directions. An MPLS-TP protocol may be used as an in-band (i.e., data-plane based) control protocol in order to coordinate the protection state between the edges of the protection domain. When the MPLS-TP control plane is in use, a control-plane-based mechanism can also be used to coordinate the protection states between the edges of the protection domain.
在某些恢复方案（如双向保护切换）中，需要协调恢复域边缘之间的保护状态，以实现双向恢复动作的启动。MPLS-TP协议可用作带内（即，基于数据平面的）控制协议，以协调保护域边缘之间的保护状态。当使用MPLS-TP控制平面时，还可以使用基于控制平面的机制来协调保护域边缘之间的保护状态。
An MPLS-TP Label Switched Path (LSP) may be subject to any part of or all of MPLS-TP link recovery, path-segment recovery, or end-to-end recovery, where:
MPLS-TP标签交换路径（LSP）可接受MPLS-TP链路恢复、路径段恢复或端到端恢复的任何部分或全部，其中：
o MPLS-TP link recovery refers to the recovery of an individual link (and hence all or a subset of the LSPs routed over the link) between two MPLS-TP nodes. For example, link recovery may be provided by server-layer recovery.
o MPLS-TP链路恢复是指恢复两个MPLS-TP节点之间的单个链路（以及通过链路路由的所有LSP或LSP的子集）。例如，链路恢复可以由服务器层恢复提供。
o Segment recovery refers to the recovery of an LSP segment (i.e., segment and concatenated segment in the language of [RFC5654]) between two nodes and is used to recover from the failure of one or more links or nodes.
o 段恢复是指在两个节点之间恢复LSP段（即[RFC5654]语言中的段和连接段），用于从一个或多个链路或节点的故障中恢复。
o End-to-end recovery refers to the recovery of an entire LSP, from its ingress to its egress node.
o 端到端恢复是指将整个LSP从其入口节点恢复到其出口节点。
For additional resiliency, more than one of these recovery techniques may be configured concurrently for a single path.
为了获得额外的恢复能力，可以为单个路径同时配置这些恢复技术中的多个。
Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows both directions of the LSP to follow the same route through the network. In this scenario, the operator often requires the directions to fate-share (that is, if one direction fails, both directions should cease to operate).
共路由双向MPLS-TP LSP的定义方式允许LSP的两个方向在网络中遵循相同的路由。在这种情况下，操作员通常要求方向共享命运（即，如果一个方向失败，两个方向都应停止运行）。
Associated bidirectional MPLS-TP LSPs exist where the two directions of a bidirectional LSP follow different paths through the network. An operator may also request fate-sharing for associated bidirectional LSPs.
存在相关联的双向MPLS-TP LSP，其中双向LSP的两个方向在网络中遵循不同的路径。操作员还可以请求相关联的双向lsp的命运共享。
The requirement for fate-sharing causes a direct interaction between the recovery processes affecting the two directions of an LSP, so that both directions of the bidirectional LSP are recovered at the same time. This mode of recovery is termed bidirectional recovery and may be seen as a consequence of fate-sharing.
命运共享的要求导致影响LSP的两个方向的恢复过程之间的直接交互，使得双向LSP的两个方向同时恢复。这种恢复模式被称为双向恢复，可被视为命运共享的结果。
The recovery scheme operating at the data-plane level can function in a multi-domain environment (in the wider sense of a "domain" [RFC4726]). It can also protect against a failure of a boundary node in the case of inter-domain operation. MPLS-TP recovery schemes are intended to protect client services when they are sent across the MPLS-TP network.
在数据平面级别运行的恢复方案可以在多域环境中运行（在更广义的“域”[RFC4726]）。在域间操作的情况下，它还可以防止边界节点发生故障。MPLS-TP恢复方案旨在保护通过MPLS-TP网络发送的客户端服务。
This framework introduces the architecture of the MPLS-TP recovery domain and describes the recovery schemes in MPLS-TP (based on the recovery types defined in [RFC4427]) as well as the principles of operation, recovery states, recovery triggers, and information exchanges between the different elements that support the reference model.
该框架介绍了MPLS-TP恢复域的体系结构，并描述了MPLS-TP中的恢复方案（基于[RFC4427]中定义的恢复类型），以及操作原理、恢复状态、恢复触发器以及支持参考模型的不同元素之间的信息交换。
The framework also describes the qualitative grades of the survivability functions that can be provided, such as dedicated recovery, shared protection, restoration, etc. In the event of a network failure, the grade of recovery directly affects the service grade provided to the end-user.
该框架还描述了可提供的生存性功能的定性等级，如专用恢复、共享保护、恢复等。在网络故障的情况下，恢复等级直接影响提供给最终用户的服务等级。
The general description of the functional architecture is applicable to both LSPs and pseudowires (PWs); however, PW recovery is only introduced in Section 7, and the relevant details are beyond the scope of this document and are for further study.
功能架构的一般描述适用于LSP和伪线（PW）；然而，PW回收仅在第7节中介绍，相关细节超出了本文件的范围，有待进一步研究。
This framework applies to general recovery schemes as well as to mechanisms that are optimized for specific topologies and are tailored to efficiently handle protection switching.
该框架适用于一般恢复方案以及针对特定拓扑进行优化的机制，并经过调整以有效处理保护切换。
This document addresses the need for the coordination of protection switching across multiple layers and at sub-layers (for clarity, we use the term "layer" to refer equally to layers and sub-layers). This allows an operator to prevent race conditions and allows the protection-switching mechanism of one layer to recover from a failure before switching is invoked at another layer.
本文件阐述了跨多个层和子层保护切换协调的必要性（为清楚起见，我们使用术语“层”来平等地指代层和子层）。这允许操作员防止竞争条件，并允许一层的保护切换机制在另一层调用切换之前从故障中恢复。
This framework also specifies the functions that must be supported by MPLS-TP to provide the recovery mechanisms. MPLS-TP introduces a tool kit to enable recovery in MPLS-TP-based networks and to ensure that affected services are recovered in the event of a failure.
该框架还指定了MPLS-TP必须支持的功能，以提供恢复机制。MPLS-TP引入了一个工具包，用于在基于MPLS-TP的网络中实现恢复，并确保在发生故障时恢复受影响的服务。
Generally, network operators aim to provide the fastest, most stable, and best protection mechanism at a reasonable cost in accordance with customer requirements. The greater the grade of protection required, the greater the number of resources will be consumed. It is therefore expected that network operators will offer a wide spectrum of service grade. MPLS-TP-based recovery offers the flexibility to select a recovery mechanism, define the granularity at which traffic delivery is to be protected, and choose the specific traffic types that are to be protected. With MPLS-TP-based recovery, it should be possible to provide different grades of protection for different traffic classes within the same path based on the service requirements.
一般来说，网络运营商的目标是根据客户要求以合理的成本提供最快、最稳定、最好的保护机制。所需的保护等级越高，消耗的资源数量就越大。因此，预计网络运营商将提供广泛的服务等级。基于MPLS TP的恢复提供了选择恢复机制、定义要保护的流量传递的粒度以及选择要保护的特定流量类型的灵活性。使用基于MPLS TP的恢复，应该可以根据服务需求为同一路径中的不同流量等级提供不同级别的保护。
The terminology used in this document is consistent with that defined in [RFC4427]. The latter is consistent with [G.808.1].
本文件中使用的术语与[RFC4427]中定义的术语一致。后者与[G.808.1]一致。
However, certain protection concepts (such as ring protection) are not discussed in [RFC4427]; for those concepts, the terminology used in this document is drawn from [G.841].
但是，[RFC4427]中未讨论某些保护概念（如环保护）；对于这些概念，本文件中使用的术语取自[G.841]。
Readers should refer to those documents for normative definitions.
读者应参考这些文件了解规范性定义。
This document supplies brief summaries of a number of terms for reasons of clarity and to assist the reader, but it does not redefine terms.
本文件提供了一些术语的简要摘要，以便于澄清和帮助读者，但并未重新定义术语。
Note, in particular, the distinction and definitions made in [RFC4427] for the following three terms:
请特别注意[RFC4427]中对以下三个术语的区别和定义：
o Protection: re-establishing end-to-end traffic delivery using pre-allocated resources.
o 保护：使用预先分配的资源重新建立端到端流量交付。
o Restoration: re-establishing end-to-end traffic delivery using resources allocated at the time of need; sometimes referred to as "repair" of a service, LSP, or the traffic.
o 恢复：使用在需要时分配的资源重新建立端到端流量交付；有时被称为服务、LSP或流量的“修复”。
o Recovery: a generic term covering both Protection and Restoration.
o 恢复：涵盖保护和恢复的通用术语。
Note that the term "survivability" is used in [RFC5654] to cover the functional elements of "protection" and "restoration", which are collectively known as "recovery".
请注意，[RFC5654]中使用了术语“生存能力”，以涵盖“保护”和“恢复”的功能要素，统称为“恢复”。
Important background information on survivability can be found in [RFC3386], [RFC3469], [RFC4426], [RFC4427], and [RFC4428].
关于生存能力的重要背景信息可在[RFC3386]、[RFC3469]、[RFC4426]、[RFC4427]和[RFC4428]中找到。
In this document, the following additional terminology is applied:
在本文件中，使用了以下附加术语：
o "Fault Management", as defined in [RFC5950].
o [RFC5950]中定义的“故障管理”。
o The terms "defect" and "failure" are used interchangeably to indicate any defect or failure in the sense that they are defined in [G.806]. The terms also include any signal degradation event as defined in [G.806].
o 术语“缺陷”和“失效”可互换使用，以表示[G.806]中定义的任何缺陷或失效。这些术语还包括[G.806]中定义的任何信号退化事件。
o A "fault" is a fault or fault cause as defined in [G.806].
o “故障”是指[G.806]中定义的故障或故障原因。
o "Trigger" indicates any event that may initiate a recovery action. See Section 4.1 for a more detailed discussion of triggers.
o “触发器”表示可能启动恢复操作的任何事件。有关触发器的更详细讨论，请参见第4.1节。
o The acronym "OAM" is defined as Operations, Administration, and Maintenance, consistent with [RFC6291].
o 首字母缩略词“OAM”定义为运营、管理和维护，与[RFC6291]一致。
o A "Transport Entity" is a node, link, transport path segment, concatenated transport path segment, or entire transport path.
o “传输实体”是节点、链路、传输路径段、串联传输路径段或整个传输路径。
o A "Working Entity" is a transport entity that carries traffic during normal network operation.
o “工作实体”是在正常网络运行期间承载流量的传输实体。
o A "Protection Entity" is a transport entity that is pre-allocated and used to protect and transport traffic when the working entity fails.
o “保护实体”是预先分配的传输实体，用于在工作实体发生故障时保护和传输通信量。
o A "Recovery Entity" is a transport entity that is used to recover and transport traffic when the working entity fails.
o “恢复实体”是一种传输实体，用于在工作实体出现故障时恢复和传输通信量。
o "Survivability Actions" are the steps that may be taken by network nodes to communicate faults and to switch traffic from faulted or degraded paths to other paths. This may include sending messages and establishing new paths.
o “生存性行动”是网络节点可能采取的步骤，用于通信故障，并将流量从故障或降级路径切换到其他路径。这可能包括发送消息和建立新路径。
General terminology for MPLS-TP is found in [RFC5921] and [ROSETTA]. Background information on MPLS-TP requirements can be found in [RFC5654].
MPLS-TP的通用术语见[RFC5921]和[ROSETTA]。有关MPLS-TP要求的背景信息，请参见[RFC5654]。
MPLS-TP requirements are presented in [RFC5654] and serve as normative references for the definition of all MPLS-TP functionality, including survivability. Survivability is presented in [RFC5654] as playing a critical role in the delivery of reliable services, and the requirements for survivability are set out using the recovery terminology defined in [RFC4427].
MPLS-TP要求在[RFC5654]中给出，并作为定义所有MPLS-TP功能（包括生存性）的标准参考。[RFC5654]中介绍了生存能力，认为它在提供可靠服务方面起着关键作用，并使用[RFC4427]中定义的恢复术语阐述了生存能力的要求。
This section presents an overview of the elements relating to the functional architecture for survivability within an MPLS-TP network. The components are presented separately to demonstrate the way in which they may be combined to provide the different grades of recovery needed to meet the requirements set out in the previous section.
本节概述了与MPLS-TP网络内生存性功能架构相关的要素。这些组成部分单独列出，以演示如何将它们组合起来，以提供满足上一节所述要求所需的不同回收等级。
Recovery is achieved by implementing specific actions. These actions aim to repair network resources or redirect traffic along paths that avoid failures in the network. They may be triggered automatically by the MPLS-TP network nodes upon detection of a network defect, or they may be triggered by an operator. Automated actions may be enhanced by in-band (i.e., data-plane-based) OAM mechanisms, or by in-band or out-of-band control-plane signaling.
恢复是通过实施具体行动来实现的。这些操作旨在修复网络资源或沿路径重定向流量，以避免网络故障。它们可以在检测到网络缺陷时由MPLS-TP网络节点自动触发，也可以由运营商触发。可通过带内（即，基于数据平面的）OAM机制，或通过带内或带外控制平面信令来增强自动化操作。
The survivability behavior of the network as a whole, and the reaction of each transport path when a fault is reported, may be controlled by the operator. This control can be split into two sets of functions: policies and actions performed when the transport path is set up, and commands used to control or force recovery actions for established transport paths.
网络作为一个整体的生存性行为，以及报告故障时每条传输路径的反应，可以由操作员控制。此控制可分为两组功能：设置传输路径时执行的策略和操作，以及用于控制或强制恢复已建立传输路径的操作的命令。
The operator may establish network-wide or local policies that determine the actions that will be taken when various defects are reported that affect different transport paths. Also, when a service request is made that causes the establishment of one or more transport paths in the network, the operator (or requesting application) may define a particular grade of service, and this will be mapped to specific survivability actions taken before and during transport path setup, after the discovery of a failure of network resources, and upon recovery of those resources.
运营商可制定网络范围或本地政策，以确定在报告影响不同传输路径的各种缺陷时将采取的措施。此外，当发出导致在网络中建立一个或多个传输路径的服务请求时，运营商（或请求应用程序）可以定义特定的服务等级，并且这将映射到在传输路径设置之前和期间采取的特定生存性行动，在发现网络资源故障后，以及在恢复这些资源后。
It should be noted that it is unusual to present a user or customer with options directly related to recovery actions. Instead, the user/customer enters into an SLA with the network provider, and the network operator maps the terms of the SLA (for example, for guaranteed delivery, availability, or reliability) to recovery schemes within the network.
应注意，向用户或客户提供与恢复操作直接相关的选项是不常见的。相反，用户/客户与网络提供商签订SLA，网络运营商将SLA的条款（例如，保证交付、可用性或可靠性）映射到网络内的恢复方案。
The operator can also issue commands to control recovery actions and events. For example, the operator may perform the following actions:
操作员还可以发出命令来控制恢复操作和事件。例如，操作员可执行以下操作：
o Enable or disable the survivability function.
o 启用或禁用生存能力功能。
o Invoke the simulation of a network fault.
o 调用网络故障的模拟。
o Force a switchover from a working path to a recovery path or vice versa.
o 强制从工作路径切换到恢复路径，反之亦然。
Forced switchover may be performed for network optimization purposes with minimal service interruption, such as when modifying protected or unprotected services, when replacing MPLS-TP network nodes, etc. In some circumstances, a fault may be reported to the operator, and the operator may then select and initiate the appropriate recovery action. A description of the different operator commands is found in Section 4.12 of [RFC4427].
出于网络优化的目的，可以在最小的服务中断情况下执行强制切换，例如在修改受保护或未受保护的服务时，在更换MPLS-TP网络节点时等。在某些情况下，可能会向运营商报告故障，运营商随后可以选择并启动适当的恢复操作。不同操作员命令的说明见[RFC4427]第4.12节。
Survivability actions may be directly triggered by network defects. This means that the device that detects the defect (for example, notification of an issue reported from equipment in a lower layer, failure to receive an OAM Continuity message, or receipt of an OAM message reporting a failure condition) may immediately perform a survivability action.
生存能力行动可能直接由网络缺陷触发。这意味着检测到缺陷的设备（例如，从较低层的设备报告的问题的通知、未能接收到OAM连续性消息或接收到报告故障状况的OAM消息）可以立即执行生存性操作。
The action is directly triggered by events in the data plane. Note, however, that coordination of recovery actions between the edges of the recovery domain may require message exchanges for some recovery functions or for performing a bidirectional recovery action.
该操作由数据平面中的事件直接触发。但是，请注意，恢复域边缘之间恢复操作的协调可能需要为某些恢复功能或执行双向恢复操作交换消息。
OAM signaling refers to data-plane OAM message exchange. Such messages may be used to detect and localize faults or to indicate a degradation in the operation of the network. However, in this context these messages are used to control or trigger survivability actions. The mechanisms to achieve this are discussed in [RFC6371].
OAM信令指数据平面OAM消息交换。此类消息可用于检测和定位故障或指示网络运行中的降级。然而，在这种情况下，这些消息用于控制或触发生存性操作。[RFC6371]中讨论了实现这一点的机制。
OAM signaling may also be used to coordinate recovery actions within the protection domain.
OAM信令还可用于协调保护域内的恢复操作。
Control-plane signaling is responsible for setup, maintenance, and teardown of transport paths that do not fall under management-plane control. The control plane may also be used to coordinate the detection, localization, and reaction to network defects pertaining to peer relationships (neighbor-to-neighbor or end-to-end). Thus, control-plane signaling may initiate and coordinate survivability actions.
控制平面信令负责设置、维护和拆除不属于管理平面控制的传输路径。控制平面还可用于协调与对等关系（邻居到邻居或端到端）有关的网络缺陷的检测、定位和反应。因此，控制平面信令可以发起和协调生存能力行动。
The control plane can also be used to distribute topology and information relating to resource availability. In this way, the "graceful shutdown" [RFC5817] of resources may be affected by withdrawing them; this can be used to invoke a survivability action in a similar way to that used when reporting or discovering a fault, as described in the previous sections.
控制平面还可用于分发拓扑和与资源可用性相关的信息。这样，撤回资源可能会影响资源的“正常关闭”[RFC5817]；这可用于以类似于报告或发现故障时使用的方式调用生存性操作，如前几节所述。
The use of a control plane for MPLS-TP is discussed in [RFC6373].
[RFC6373]中讨论了MPLS-TP控制平面的使用。
This section describes the elements of recovery. These are the quantitative aspects of recovery, that is, the parts of the network for which recovery can be provided.
本节介绍恢复的要素。这些是恢复的定量方面，即可以提供恢复的网络部分。
Note that the terminology in this section is consistent with [RFC4427]. Where the terms differ from those in [RFC5654], mapping is provided.
请注意，本节中的术语与[RFC4427]一致。如果术语与[RFC5654]中的术语不同，则提供映射。
A span is a single hop between neighboring MPLS-TP nodes in the same network layer. A span is sometimes referred to as a link, and this may cause some confusion between the concept of a data link and a traffic engineering (TE) link. LSPs traverse TE links between neighboring MPLS-TP nodes in the MPLS-TP network layer. However, a TE link may be provided by any of the following:
跨距是同一网络层中相邻MPLS-TP节点之间的单跳。跨距有时被称为链路，这可能会导致数据链路和流量工程（TE）链路概念之间的混淆。LSP在MPLS-TP网络层的相邻MPLS-TP节点之间遍历TE链路。但是，TE链路可以由以下任何一种方式提供：
o A single data link.
o 单个数据链路。
o A series of data links in a lower layer, established as an LSP and presented to the upper layer as a single TE link.
o 下层中的一系列数据链路，作为LSP建立，并作为单个TE链路呈现给上层。
o A set of parallel data links in the same layer, presented either as a bundle of TE links, or as a collection of data links that together provide a data-link-layer protection scheme.
o 同一层中的一组并行数据链路，以TE链路束或数据链路集合的形式呈现，共同提供数据链路层保护方案。
Thus, span recovery may be provided by any of the following:
因此，跨度恢复可通过以下任一方式提供：
o Selecting a different TE link from a bundle.
o 从捆绑中选择不同的TE链接。
o Moving the TE link so that it is supported by a different data link between the same pair of neighbors.
o 移动TE链路，以便同一对邻居之间的不同数据链路支持它。
o Rerouting the LSP in the lower layer.
o 在较低层中重新路由LSP。
Moving the protected LSP to another TE link between the same pair of neighbors is a form of segment recovery and not a form of span recovery. Segment Recovery is described in Section 4.2.2.
将受保护的LSP移动到同一对邻居之间的另一个TE链路是段恢复的一种形式，而不是跨度恢复的形式。第4.2.2节描述了段恢复。
An LSP segment comprises one or more continuous hops on the path of the LSP. [RFC5654] defines two terms. A "segment" is a single hop along the path of an LSP, while a "concatenated segment" is more than one hop along the path of an LSP. In the context of this document, a segment covers both of these concepts.
LSP段包括LSP路径上的一个或多个连续跳。[RFC5654]定义了两个术语。“段”是沿LSP路径的单跳，而“串联段”是沿LSP路径的多跳。在本文件中，有一部分涵盖了这两个概念。
A PW segment refers to a Single-Segment PW (SS-PW) or to a single segment of a Multi-Segment PW (MS-PW) that is set up between two PE devices that may be Terminating PEs (T-PEs) or Switching PEs (S-PEs) so that the full set of possibilities is T-PE to S-PE, S-PE to S-PE, S-PE to T-PE, or T-PE to T-PE (for the SS-PW case). As indicated in Section 1, the recovery of PWs and PW segments is beyond the scope of this document; however, see Section 7.
PW段是指单段PW（SS-PW）或多段PW（MS-PW）的单段，设置在两个PE设备之间，可端接PEs（T-PEs）或切换PEs（S-PEs），因此全套可能性为T-PE到S-PE、S-PE到S-PE、S-PE到T-PE或T-PE到T-PE（对于SS-PW情况）。如第1节所述，PWs和PW段的恢复超出了本文件的范围；但是，见第7节。
Segment recovery involves redirecting or copying traffic at the source end of a segment onto an alternate path leading to the other end of the segment. According to the required grade of recovery (described in Section 4.3), traffic may be either redirected to a pre-established segment, through rerouting the protected segment, or tunneled to the far end of the protected segment through a "bypass" LSP. For details on recovery mechanisms, see Section 4.4.
段恢复涉及将段源端的流量重定向或复制到通向段另一端的备用路径上。根据所需的恢复等级（如第4.3节所述），可以通过重新路由受保护段将流量重定向到预先建立的段，或者通过“旁路”LSP将流量隧道到受保护段的远端。有关恢复机制的详细信息，请参见第4.4节。
Note that protecting a transport path against node failure requires the use of segment recovery or end-to-end recovery, while a link failure can be protected using span, segment, or end-to-end recovery.
请注意，针对节点故障保护传输路径需要使用段恢复或端到端恢复，而链路故障可以使用跨距、段或端到端恢复进行保护。
End-to-end recovery is a special case of segment recovery where the protected segment comprises the entire transport path. End-to-end recovery may be provided as link-diverse or node-diverse recovery where the recovery path shares no links or no nodes with the working path.
端到端恢复是段恢复的一种特殊情况，其中受保护的段包括整个传输路径。端到端恢复可以作为链路多样性或节点多样性恢复提供，其中恢复路径与工作路径不共享链路或节点。
Note that node-diverse paths are necessarily link-diverse and that full, end-to-end node-diversity is required to guarantee recovery.
请注意，节点多样性路径必然是链路多样性的，并且需要完整的端到端节点多样性来保证恢复。
Two observations need to be made about end-to-end recovery.
需要对端到端恢复进行两项观察。
- Firstly, there may be circumstances where node-diverse end-to-end paths do not guarantee recovery. The ingress and egress nodes will themselves be single points of failure. Additionally, there may be shared risks of failure (for example, geographic collocation, shared resources, etc.) between diverse nodes as described in Section 4.9.2.
- 首先，可能存在节点不同的端到端路径不能保证恢复的情况。入口和出口节点本身将是单点故障。此外，如第4.9.2节所述，不同节点之间可能存在共同的故障风险（例如，地理配置、共享资源等）。
- Secondly, it is possible to use end-to-end recovery techniques even when there is not full diversity and the working and protection paths share links or nodes.
- 其次，即使在没有完全分集且工作和保护路径共享链路或节点时，也可以使用端到端恢复技术。
This section describes the qualitative grades of survivability that can be provided. In the event of a network failure, the grade of recovery offered directly affects the service grade provided to the end-user. This will be observed as the amount of data lost when a network fault occurs, and the length of time required to recover connectivity.
本节描述了可提供的生存能力的定性等级。在网络发生故障的情况下，提供的恢复级别直接影响向最终用户提供的服务级别。这将被视为发生网络故障时丢失的数据量，以及恢复连接所需的时间长度。
In general, there is a correlation between the recovery service grade (i.e., the speed of recovery and reduction of data loss) and the amount of resources used in the network; better service grades require the pre-allocation of resources to the recovery paths, and those resources cannot be used for other purposes if high-quality recovery is required. An operator will consider how providing different grades of recovery may require that network resources be provisioned and allocated for exclusive use of the recovery paths such that the resources cannot be used to support other customer services.
通常，恢复服务等级（即恢复速度和数据丢失的减少）与网络中使用的资源量之间存在相关性；更好的服务级别要求将资源预先分配给恢复路径，如果需要高质量的恢复，则这些资源不能用于其他目的。运营商将考虑如何提供不同等级的恢复可能需要提供和分配网络资源以专用于恢复路径，使得资源不能用于支持其他客户服务。
Sections 6 and 7 of [RFC4427] provide a full breakdown of the protection and recovery schemes. This section summarizes the qualitative grades available.
[RFC4427]第6节和第7节提供了保护和恢复方案的完整分解。本节总结了可用的定性等级。
Note that, in the context of recovery, a useful discussion of the term "resource" and its interpretation in both the IETF and ITU-T contexts may be found in Section 3.2 of [RFC4397].
请注意，在恢复方面，[RFC4397]的第3.2节对术语“资源”及其在IETF和ITU-T上下文中的解释进行了有益的讨论。
The selection of the recovery grade and schemes to satisfy the service grades for an LSP using available network resources is subject to network and local policy and may be pre-designated through network planning or may be dynamically determined by the network.
使用可用网络资源来满足LSP的服务等级的恢复等级和方案的选择取决于网络和本地策略，并且可以通过网络规划预先指定，或者可以由网络动态确定。
In dedicated protection, the resources for the recovery entity are pre-assigned for the sole use of the protected transport path. This will clearly be the case in 1+1 protection, and may also be the case in 1:1 protection where extra traffic (see Section 4.3.3) is not supported.
在专用保护中，恢复实体的资源预先分配给受保护传输路径的唯一用途。这显然是1+1保护中的情况，也可能是1:1保护中不支持额外流量（见第4.3.3节）的情况。
Note that when using protection tunnels (see Section 4.4.3), resources may also be dedicated to the protection of a specific transport path. In some cases (1:1 protection), the entire bypass tunnel may be dedicated to providing recovery for a specific transport path, while in other cases (such as facility backup), a subset of the resources associated with the bypass tunnel may be pre-assigned for the recovery of a specific service.
请注意，当使用保护隧道时（见第4.4.3节），资源也可专用于保护特定运输路径。在某些情况下（1:1保护），整个旁通隧道可专用于为特定传输路径提供恢复，而在其他情况下（如设施备份），与旁通隧道相关联的资源子集可预分配用于恢复特定服务。
However, as described in Section 4.4.3, the bypass tunnel method can also be used for shared protection (Section 4.3.2), either to carry extra traffic (Section 4.3.3) or to achieve best-effort recovery without the need for resource reservation.
但是，如第4.4.3节所述，旁路隧道法也可用于共享保护（第4.3.2节），以承载额外流量（第4.3.3节）或在不需要资源预留的情况下实现尽最大努力恢复。
In shared protection, the resources for the recovery entities of several services are shared. These may be shared as 1:n or m:n and are shared on individual links. Link-by-link resource sharing may be managed and operated along LSP segments, on PW segments, or on end-to-end transport paths (LSP or PW). Note that there is no requirement for m:n recovery in the list of MPLS-TP requirements documented in [RFC5654]. Shared protection can be applied in different topologies (mesh, ring, etc.) and can utilize different protection mechanisms (linear, ring, etc.).
在共享保护中，多个服务的恢复实体的资源是共享的。这些可以作为1:n或m:n共享，并在各个链接上共享。逐链路资源共享可沿LSP段、PW段或端到端传输路径（LSP或PW）进行管理和操作。请注意，[RFC5654]中记录的MPLS-TP要求列表中没有m:n恢复要求。共享保护可应用于不同的拓扑（网格、环等），并可利用不同的保护机制（线性、环等）。
End-to-end shared protection shares resources between a number of paths that have common end points. Thus, a number of paths (n paths) are all protected by one or more protection paths (m paths, where m may equal 1). When there have been m failures, there are no more available protection paths, and the n paths are no longer protected. Thus, in 1:n protection, one fault can be protected against before all the n paths are unprotected. The fact that the paths have become unprotected needs to be conveyed to the path end points since they may need to report the change in service grade or may need to take further action to increase their protection. In end-to-end shared protection, this communication is simple since the end points are common.
端到端共享保护在多个具有公共端点的路径之间共享资源。因此，多条路径（n条路径）都由一条或多条保护路径（m条路径，其中m可以等于1）保护。当出现m个故障时，不再有可用的保护路径，并且n个路径不再受保护。因此，在1:n保护中，可以在所有n条路径解除保护之前保护一个故障。由于路径可能需要报告服务等级的变化，或者可能需要采取进一步措施来增加其保护，因此需要将路径变得不受保护的事实传达给路径端点。在端到端共享保护中，这种通信很简单，因为端点是公共的。
In shared mesh protection (see Section 4.7.6), the paths that share the protection resources do not necessarily have the same end points. This provides a more flexible resource-sharing scheme, but the network planning and the coordination of protection state after a recovery action are more complex.
在共享网格保护中（参见第4.7.6节），共享保护资源的路径不一定具有相同的端点。这提供了更灵活的资源共享方案，但网络规划和恢复操作后保护状态的协调更为复杂。
Where a bypass tunnel is used (Section 4.4.3), the tunnel might not have sufficient resources to simultaneously protect all of the paths for which it offers protection; in the event that all paths were affected by network defects and failures at the same time, not all of them would be recovered. Policy would dictate how this situation should be handled: some paths might be protected, while others would simply fail; the traffic for some paths would be guaranteed, while traffic on other paths would be treated as best-effort with the risk of dropped packets. Alternatively, it is possible that protection would not be attempted according to local policy at the nodes that perform the recovery actions.
如果使用旁通隧道（第4.4.3节），隧道可能没有足够的资源来同时保护其提供保护的所有路径；如果所有路径同时受到网络缺陷和故障的影响，则并非所有路径都能恢复。政策将规定如何处理这种情况：一些路径可能会受到保护，而另一些路径则会失败；某些路径上的流量将得到保证，而其他路径上的流量将被视为最大努力，存在丢包的风险。或者，可能不会根据执行恢复操作的节点的本地策略尝试保护。
Shared protection is a trade-off between assigning network resources to protection (which is not required most of the time) and risking unrecoverable services in the event that multiple network defects or failures occur. Rapid recovery can be achieved with dedicated protection, but it is delayed by message exchanges in the management, control, or data planes for shared protection. This means that there is also a trade-off between rapid recovery and resource sharing. In some cases, shared protection might not meet the speed required for protection, but it may still be faster than restoration.
共享保护是在将网络资源分配给保护（大多数情况下不需要）和在出现多个网络缺陷或故障时承担无法恢复的服务风险之间的权衡。使用专用保护可以实现快速恢复，但由于共享保护的管理、控制或数据平面中的消息交换而延迟。这意味着在快速恢复和资源共享之间也存在权衡。在某些情况下，共享保护可能无法满足保护所需的速度，但仍可能比恢复快。
These trade-offs may be somewhat mitigated by the following:
这些权衡可能通过以下方式有所缓解：
o Adjusting the value of n in 1:n protection.
o 调整1:n保护中的n值。
o Using m:n protection for a value of m > 1.
o 对m>1的值使用m:n保护。
o Establishing new protection paths as each available protection path is put into use.
o 在每个可用保护路径投入使用时建立新的保护路径。
In an MPLS-TP network, the degree to which a resource is shared between LSPs is a policy issue. This policy may be applied to the resource or to the LSPs, and may be pre-configured, configured per LSP and installed during LSP establishment, or may be dynamically configured.
在MPLS-TP网络中，LSP之间共享资源的程度是一个策略问题。该策略可以应用于资源或LSP，并且可以预先配置、根据LSP配置并在LSP建立期间安装，或者可以动态配置。
Section 2.5.1.1 of [RFC5654] says: "Support for extra traffic (as defined in [RFC4427]) is not required in MPLS-TP and MAY be omitted from the MPLS-TP specifications". This document observes that extra traffic facilities may therefore be provided as part of the MPLS-TP survivability toolkit depending upon the development of suitable solution specifications. The remainder of this section explains the concepts of extra traffic without prejudging the decision to specify or not specify such solutions.
[RFC5654]的第2.5.1.1节说：“MPLS-TP中不需要对额外流量（如[RFC4427]中所定义）的支持，MPLS-TP规范中可以省略。”。本文件指出，根据适当解决方案规范的开发，额外的通信设施可作为MPLS-TP生存能力工具包的一部分提供。本节剩余部分将解释额外流量的概念，而不会预先判断是否指定此类解决方案。
Network resources allocated for protection represent idle capacity during the time that recovery is not actually required, and can be utilized by carrying other traffic, referred to as "extra traffic".
分配用于保护的网络资源表示实际不需要恢复期间的空闲容量，并且可以通过承载其他流量（称为“额外流量”）来使用。
Note that extra traffic does not need to start or terminate at the ends of the entity (e.g., LSP) that it uses.
请注意，额外的流量不需要在其使用的实体（例如LSP）的末端开始或终止。
When a network resource carrying extra traffic is required for the recovery of protected traffic from the failed working path, the extra traffic is disrupted. This disruption make take one of two forms:
当需要承载额外流量的网络资源来从故障工作路径恢复受保护的流量时，额外的流量会中断。这种破坏可以采取以下两种形式之一：
- In "hard preemption", the extra traffic is excluded from the protection resource. The disruption of the extra traffic is total, and the service supported by the extra traffic must be dropped, or some form of rerouting or restoration must be applied to the extra traffic LSP in order to recover the service.
- 在“硬抢占”中，额外的流量被排除在保护资源之外。额外流量的中断是完全中断的，必须丢弃额外流量支持的服务，或者必须对额外流量LSP应用某种形式的重新路由或恢复，以便恢复服务。
Hard preemption is achieved by "setting a switch" on the path of the extra traffic such that it no longer flows. This situation may be detected by OAM and reported as a fault, or may be proactively reported through OAM or control-plane signaling.
硬抢占是通过在额外流量的路径上“设置一个开关”，使其不再流动来实现的。这种情况可由OAM检测并报告为故障，或可通过OAM或控制平面信令主动报告。
- In "soft preemption", the extra traffic is not explicitly excluded from the protection resource, but is given lower priority than the protected traffic. In a packet network (such as MPLS-TP), this can result in oversubscription of the protection resource with the result that the extra traffic receives "best-effort" delivery. Depending on the volume of protection and extra traffic, and the level of oversubscription, the extra traffic may be slightly or heavily impacted.
- 在“软抢占”中，额外的流量没有明确地从保护资源中排除，而是被赋予比受保护的流量更低的优先级。在分组网络（如MPLS-TP）中，这可能导致保护资源的过度订阅，从而导致额外的流量收到“尽力而为”的交付。根据保护和额外流量的大小以及超额订阅的程度，额外流量可能会受到轻微或严重的影响。
The event of soft preemption may be detected by OAM and reported as a degradation of traffic delivery or as a fault. It may also be proactively reported through OAM or control-plane signaling.
OAM可以检测到软抢占事件，并将其报告为流量交付降级或故障。也可以通过OAM或控制平面信令主动报告。
Note that both hard and soft preemption may utilize additional message exchanges in the management, control, or data planes. These messages do not necessarily mean that recovery is delayed, but may increase the complexity of the protection system. Thus, the benefits of carrying extra traffic must be weighed against the disadvantages of delayed recovery, additional network overhead, and the impact on the services that support the extra traffic according to the details of the solutions selected.
注意，硬抢占和软抢占都可以利用管理、控制或数据平面中的附加消息交换。这些消息并不一定意味着恢复延迟，但可能会增加保护系统的复杂性。因此，必须根据所选解决方案的细节，权衡承载额外流量的好处与延迟恢复的缺点、额外的网络开销以及对支持额外流量的服务的影响。
Note that extra traffic is not protected by definition, but may be restored.
请注意，额外流量不受定义保护，但可以恢复。
Extra traffic is not supported on dedicated protection resources, which, by definition, are used for 1+1 protection (Section 4.3.1), but it can be supported in other protection schemes, including shared protection (Section 4.3.2) and tunnel protection (Section 4.4.3).
专用保护资源不支持额外流量，根据定义，专用保护资源用于1+1保护（第4.3.1节），但可在其他保护方案中支持额外流量，包括共享保护（第4.3.2节）和隧道保护（第4.4.3节）。
Best-effort traffic should not be confused with extra traffic. For best-effort traffic, the network does not guarantee data delivery, and the user does not receive guaranteed quality of service (e.g., in terms of jitter, packet loss, delay, etc.). Best-effort traffic depends on the current traffic load. However, for extra traffic, quality can only be guaranteed until resources are required for recovery. At this point, the extra traffic may be completely
尽力而为的流量不应与额外流量混淆。对于尽力而为的流量，网络不保证数据传输，用户也不保证服务质量（例如，在抖动、数据包丢失、延迟等方面）。尽力而为的流量取决于当前的流量负载。但是，对于额外的流量，只有在恢复需要资源之前，才能保证质量。在这一点上，额外的流量可能会完全消失
displaced, may be treated as best effort, or may itself be recovered (for example, by restoration techniques).
移位的，可以被视为尽最大努力，或者可以自行恢复（例如，通过恢复技术）。
This section refers to LSP restoration. Restoration for PWs is beyond the scope of this document (but see Section 7).
本节涉及LSP恢复。PWs的恢复超出了本文件的范围（但请参见第7节）。
Restoration represents the most effective use of network resources, since no resources are reserved for recovery. However, restoration requires the computation of a new path and the activation of a new LSP (through the management or control plane). It may be more time-consuming to perform these steps than to implement recovery using protection techniques.
恢复是对网络资源的最有效利用，因为没有为恢复保留任何资源。但是，恢复需要计算新路径并激活新LSP（通过管理或控制平面）。执行这些步骤可能比使用保护技术实现恢复更耗时。
Furthermore, there is no guarantee that restoration will be able to recover the service. It may be that all suitable network resources are already in use for other LSPs, so that no new path can be found. This problem can be partially mitigated by using LSP setup priorities, so that recovery LSPs can preempt existing LSPs with lower priorities.
此外，无法保证恢复将能够恢复服务。可能所有合适的网络资源都已用于其他LSP，因此无法找到新路径。使用LSP设置优先级可以部分缓解此问题，因此恢复LSP可以抢占优先级较低的现有LSP。
Additionally, when a network defect occurs, multiple LSPs may be disrupted by the same event. These LSPs may have been established by different Network Management Stations (NMSes) or they may have been signaled by different head-end MPLS-TP nodes, meaning that multiple points in the network will try to compute and establish recovery LSPs at the same time. This can lead to a lack of resources within the network and cause recovery failures; some recovery actions will need to be retried, resulting in even slower recovery times for some services.
此外，当发生网络缺陷时，多个LSP可能会被同一事件中断。这些LSP可能是由不同的网络管理站（NMS）建立的，也可能是由不同的头端MPLS-TP节点发信号通知的，这意味着网络中的多个点将尝试同时计算和建立恢复LSP。这可能导致网络内资源不足，并导致恢复失败；某些恢复操作将需要重试，从而导致某些服务的恢复时间更慢。
Both hard and soft LSP restoration may be supported. For hard LSP restoration, the resources of the working LSP are released before the recovery LSP is fully established (i.e., break-before-make). For soft LSP restoration, the resources of the working LSP are released after an alternate LSP is fully established (i.e., make-before-break). Note that in the case of reversion (Section 4.3.5), the resources associated with the working LSP are not released.
可以支持硬LSP恢复和软LSP恢复。对于硬LSP恢复，工作LSP的资源在恢复LSP完全建立之前释放（即先断后通）。对于软LSP恢复，工作LSP的资源在完全建立备用LSP后释放（即，先通后断）。请注意，在恢复的情况下（第4.3.5节），与工作LSP相关的资源不会释放。
The restoration resources may be pre-calculated and even pre-signaled before the restoration action starts, but not pre-allocated. This is known as pre-planned LSP restoration. The complete establishment/activation of the restoration LSP occurs only when the restoration action starts. Pre-planning may occur periodically and provides the most accurate information about the available resources in the network.
在恢复操作开始之前，可以预先计算恢复资源，甚至预先发出信号，但不预先分配。这称为预先计划的LSP恢复。仅当恢复操作开始时，恢复LSP才会完全建立/激活。预先规划可能会定期进行，并提供有关网络中可用资源的最准确信息。
After a service has been recovered and traffic is flowing along the recovery LSP, the defective network resource may be replaced. Traffic can be redirected back onto the original working LSP (known as "reversion"), or it can be left where it is on the recovery LSP ("non-revertive" behavior).
在服务已经恢复并且流量沿着恢复LSP流动之后，可以替换有缺陷的网络资源。流量可以重定向回原始工作LSP（称为“恢复”），也可以留在恢复LSP上（“非恢复”行为）。
It should be possible to specify the reversion behavior of each service; this might even be configured for each recovery instance.
应该可以指定每个服务的恢复行为；这甚至可以为每个恢复实例配置。
In non-revertive mode, an additional operational option is possible where protection roles are switched, so that the recovery LSP becomes the working LSP, while the previous working path (or the resources used by the previous working path) are used for recovery in the event of an additional fault.
在非恢复模式下，在切换保护角色的情况下，可以使用额外的操作选项，以便恢复LSP成为工作LSP，而在发生额外故障时，使用先前的工作路径（或先前工作路径使用的资源）进行恢复。
In revertive mode, it is important to prevent excessive swapping between the working and recovery paths in the case of an intermittent defect. This can be addressed by using a reversion delay timer (the Wait-To-Restore timer), which controls the length of time to wait before reversion following the repair of a fault on the original working path. It should be possible for an operator to configure this timer per LSP, and a default value should be defined.
在恢复模式下，在间歇性缺陷的情况下，防止工作路径和恢复路径之间过度交换非常重要。这可以通过使用恢复延迟计时器（等待恢复计时器）来解决，该计时器控制修复原始工作路径上的故障后恢复前等待的时间长度。操作员应该可以根据LSP配置此计时器，并且应该定义默认值。
This section provides general descriptions (MPLS-TP non-specific) of the mechanisms that can be used for protection purposes. As indicated above, while the functional architecture applies to both LSPs and PWs, the mechanism for recovery described in this document refers to LSPs and LSP segments only. Recovery mechanisms for pseudowires and pseudowire segments are for further study and will be described in a separate document (see also Section 7).
本节提供可用于保护目的的机制的一般说明（MPLS-TP非特定）。如上所述，虽然功能架构同时适用于LSP和PWs，但本文档中描述的恢复机制仅适用于LSP和LSP段。伪导线和伪导线段的恢复机制有待进一步研究，将在单独的文件中描述（另见第7节）。
Link-level protection refers to two paradigms: (1) where protection is provided in a lower network layer and (2) where protection is provided by the MPLS-TP link layer.
链路级保护指的是两种范例：（1）在较低的网络层提供保护，（2）在MPLS-TP链路层提供保护。
Note that link-level protection mechanisms do not protect the nodes at each end of the entity (e.g., a link or span) that is protected. End-to-end or segment protection should be used in conjunction with link-level protection to protect against a failure of the edge nodes.
请注意，链路级保护机制不会保护受保护实体（例如，链路或跨度）每一端的节点。端到端或段保护应与链路级保护结合使用，以防止边缘节点出现故障。
Link-level protection offers the following grades of protection:
链路级保护提供以下级别的保护：
o Full protection where a dedicated protection entity (e.g., a link or span) is pre-established to protect a working entity. When the working entity fails, the protected traffic is switched to the protecting entity. In this scenario, all LSPs carried over the working entity are recovered (in one protection operation) when there is a failure condition. This is referred to in [RFC4427] as "bulk recovery".
o 全面保护，其中预先建立了专用保护实体（例如链路或跨度），以保护工作实体。当工作实体出现故障时，受保护的通信量将切换到保护实体。在这种情况下，当出现故障情况时，将恢复工作实体上携带的所有LSP（在一次保护操作中）。这在[RFC4427]中称为“批量回收”。
o Partial protection where only a subset of the LSPs or traffic carried over a selected entity is recovered when there is a failure condition. The decision as to which LSPs will be recovered and which will not depends on local policy.
o 部分保护，当出现故障条件时，仅恢复通过选定实体承载的LSP或通信量的子集。将恢复哪些LSP以及恢复哪些LSP的决定不取决于当地政策。
When there is no failure on the working entity, the protection entity may transport extra traffic that may be preempted when protection switching occurs.
当工作实体上没有故障时，保护实体可以传输额外的流量，这些流量在发生保护切换时可能被抢占。
If link-level protection is available, it may be desirable to allow this to be attempted before attempting other recovery mechanisms for the transport paths affected by the fault because link-level protection may be faster and more conservative of network resources. This can be achieved both by limiting the propagation of fault condition notifications and by delaying the other recovery actions. This consideration of other protection can be compared with the discussion of recovery domains (Section 4.5) and recovery in multi-layer networks (Section 4.9).
如果链路级保护可用，则可能希望允许在尝试其他受故障影响的传输路径的恢复机制之前尝试此操作，因为链路级保护可能更快、更保守的网络资源。这可以通过限制故障条件通知的传播和延迟其他恢复操作来实现。这种对其他保护的考虑可以与恢复域（第4.5节）和多层网络中的恢复（第4.9节）的讨论进行比较。
A protection mechanism may be provided at the MPLS-TP link layer (which connects two MPLS-TP nodes). Such a mechanism can make use of the procedures defined in [RFC5586] to set up in-band communication channels at the MPLS-TP Section level, to use these channels to monitor the health of the MPLS-TP link, and to coordinate the protection states between the ends of the MPLS-TP link.
可以在MPLS-TP链路层（连接两个MPLS-TP节点）提供保护机制。这种机制可以利用[RFC5586]中定义的程序在MPLS-TP段级建立带内通信信道，使用这些信道监测MPLS-TP链路的健康状况，并协调MPLS-TP链路两端之间的保护状态。
The use of alternate paths and segments refers to the paradigm whereby protection is performed in the network layer in which the protected LSP is located; this applies either to the entire end-to-end LSP or to a segment of the LSP. In this case, hierarchical LSPs are not used (compare with Section 4.4.3).
备用路径和段的使用是指在受保护LSP所在的网络层中执行保护的范例；这适用于整个端到端LSP或LSP的一段。在这种情况下，不使用分层LSP（与第4.4.3节相比）。
Different grades of protection may be provided:
可提供不同等级的保护：
o Dedicated protection where a dedicated entity (e.g., LSP or LSP segment) is (fully) pre-established to protect a working entity
o 专用保护，其中（完全）预先建立专用实体（如LSP或LSP段）以保护工作实体
(e.g., LSP or LSP segment). When a failure condition occurs on the working entity, traffic is switched onto the protection entity. Dedicated protection may be performed using 1:1 or 1+1 linear protection schemes. When the failure condition is eliminated, the traffic may revert to the working entity. This is subject to local configuration.
（例如，LSP或LSP段）。当工作实体出现故障情况时，通信量切换到保护实体。可使用1:1或1+1线性保护方案执行专用保护。当故障条件消除时，通信量可能会恢复到工作实体。这取决于本地配置。
o Shared protection where one or more protection entities is pre-established to protect against a failure of one or more working entities (1:n or m:n).
o 共享保护，其中预先建立了一个或多个保护实体，以防止一个或多个工作实体（1:n或m:n）出现故障。
When the fault condition on the working entity is eliminated, the traffic should revert back to the working entity in order to allow other related working entities to be protected by the shared protection resource.
当工作实体上的故障条件消除后，通信量应恢复到工作实体，以允许其他相关工作实体受到共享保护资源的保护。
A protection tunnel is pre-provisioned in order to protect against a failure condition along a sequence of spans in the network. This may be achieved using LSP heirarchy. We call such a sequence a network segment. A failure of a network segment may affect one or more LSPs that transit the network segment.
预先设置保护隧道，以防止网络中一系列跨距发生故障。这可以通过使用LSP继承权来实现。我们称这种序列为网段。网段故障可能会影响传输网段的一个或多个LSP。
When a failure condition occurs in the network segment (detected either by OAM on the network segment, or by OAM on a concatenated segment of one of the LSPs transiting the network segment), one or more of the protected LSPs are switched over at the ingress point of the network segment and are transmitted over the protection tunnel. This is implemented through label stacking. Label mapping may be an option as well.
当网段中出现故障情况时（由网段上的OAM或通过网段传输的LSP之一的级联段上的OAM检测），一个或多个受保护LSP在网段的入口点切换并通过保护隧道传输。这是通过标签堆叠实现的。标签映射也可以是一个选项。
Different grades of protection may be provided:
可提供不同等级的保护：
o Dedicated protection where the protection tunnel reserves sufficient resources to provide protection for all protected LSPs without causing service degradation.
o 专用保护，其中保护隧道保留足够的资源为所有受保护的LSP提供保护，而不会导致服务降级。
o Partial protection where the protection tunnel has enough resources to protect some of the protected LSPs, but not all of them simultaneously. Policy dictates how this situation should be handled: it is possible that some LSPs would be protected, while others would simply fail; it is possible that traffic would be guaranteed for some LSPs, while for other LSPs it would be treated as best effort with the risk of packets being dropped. Alternatively, it is possible that protection would not be attempted.
o 部分保护，即保护隧道有足够的资源保护部分受保护的LSP，但不能同时保护所有LSP。政策规定了应如何处理这种情况：一些LSP可能会受到保护，而其他LSP可能会失败；对于某些LSP，流量可能会得到保证，而对于其他LSP，流量可能会被视为最大努力，存在数据包被丢弃的风险。或者，可能不会尝试保护。
Protection and restoration are performed in the context of a recovery domain. A recovery domain is defined between two or more recovery reference end points that are located at the edges of the recovery domain and that border on the element on which recovery can be provided (as described in Section 4.2). This element can be an end-to-end path, a segment, or a span.
保护和恢复是在恢复域的上下文中执行的。恢复域定义在两个或多个恢复参考端点之间，这些端点位于恢复域的边缘和可提供恢复的元件的边界（如第4.2节所述）。此图元可以是端到端路径、段或跨度。
An end-to-end path can be observed as a special segment case where the ingress and egress Label Edge Routers (LERs) serve as the recovery reference end points.
端到端路径可以看作是一种特殊的段情况，其中入口和出口标签边缘路由器（LER）用作恢复参考端点。
In this simple case of a point-to-point (P2P) protected entity, two end points reside at the boundary of the protection domain. An LSP can enter through one reference end point and exit the recovery domain through another reference end point.
在这个简单的点对点（P2P）保护实体的情况下，两个端点位于保护域的边界。LSP可以通过一个参考端点进入恢复域，并通过另一个参考端点退出恢复域。
In the case of unidirectional point-to-multipoint (P2MP), three or more end points reside at the boundary of the protection domain. One of the end points is referred to as the source/root, while the others are referred to as sinks/leaves. An LSP can enter the recovery domain through the root point and exit the recovery domain through the leaf points.
在单向点对多点（P2MP）的情况下，三个或更多端点位于保护域的边界处。其中一个端点称为源/根，而其他端点称为汇/叶。LSP可以通过根点进入恢复域，并通过叶点退出恢复域。
The recovery mechanism should restore traffic that was interrupted by a facility (link or node) fault within the recovery domain. Note that a single link may be part of several recovery domains. If two recovery domains have common links, one recovery domain must be contained within the other. This can be referred to as nested recovery domains. The boundaries of recovery domains may coincide, but recovery domains must not overlap.
恢复机制应恢复由恢复域内的设施（链路或节点）故障中断的通信量。请注意，单个链接可能是多个恢复域的一部分。如果两个恢复域具有公共链接，则一个恢复域必须包含在另一个恢复域中。这可以称为嵌套恢复域。恢复域的边界可能重合，但恢复域不得重叠。
Note that the edges of a recovery domain are not protected, and unless the whole domain is contained within another recovery domain, the edges form a single point of failure.
请注意，恢复域的边缘不受保护，除非整个域包含在另一个恢复域中，否则这些边缘将形成单个故障点。
A recovery group is defined within a recovery domain and consists of a working (primary) entity and one or more recovery (backup) entities that reside between the end points of the recovery domain. To guarantee protection in all situations, a dedicated recovery entity should be pre-provisioned using disjoint resources in the recovery domain, in order to protect against a failure of a working entity. Of course, mechanisms to detect faults and to trigger protection switching are also needed.
恢复组在恢复域中定义，由工作（主）实体和位于恢复域端点之间的一个或多个恢复（备份）实体组成。为了保证在所有情况下都能提供保护，应使用恢复域中不相交的资源预先配置专用恢复实体，以防止工作实体出现故障。当然，还需要检测故障和触发保护切换的机制。
The method used to monitor the health of the recovery element is beyond the scope of this document. The end points that are
用于监视恢复元素运行状况的方法超出了本文档的范围。结束点是
responsible for the recovery action must receive information on its condition. The condition of the recovery element may be 'OK', 'failed', or 'degraded'.
负责恢复行动的人员必须收到有关其状况的信息。恢复元素的状态可能为“正常”、“失败”或“降级”。
When the recovery operation is to be triggered by OAM mechanisms, an OAM Maintenance Entity Group must be defined for each of the working and protection entities.
当恢复操作由OAM机制触发时，必须为每个工作实体和保护实体定义OAM维护实体组。
The recovery entities and functions in a recovery domain can be configured using a management plane or a control plane. A management plane may be used to configure the recovery domain by setting the reference points, the working and recovery entities, and the recovery type (e.g., 1:1 bidirectional linear protection, ring protection, etc.). Additional parameters associated with the recovery process may also be configured. For more details, see Section 6.1.
可以使用管理平面或控制平面配置恢复域中的恢复实体和功能。管理平面可用于通过设置参考点、工作和恢复实体以及恢复类型（例如，1:1双向线性保护、环保护等）来配置恢复域。还可以配置与恢复过程相关联的其他参数。有关更多详细信息，请参见第6.1节。
When a control plane is used, the ingress LERs may communicate with the recovery reference points that request that protection or restoration be configured across a recovery domain. For details, see Section 6.5.
当使用控制平面时，入口LER可与请求跨恢复域配置保护或恢复的恢复参考点通信。有关详细信息，请参见第6.5节。
Cases of multiple interconnections between distinct recovery domains create a hierarchical arrangement of recovery domains, since a single top-level recovery domain is created from the concatenation of two recovery domains with multiple interconnections. In this case, recovery actions may be taken both in the individual, lower-level recovery domains to protect any LSP segment that crosses the domain, and within the higher-level recovery domain to protect the longer LSP segment that traverses the higher-level domain.
不同恢复域之间存在多个互连的情况会创建恢复域的分层排列，因为单个顶级恢复域是由两个具有多个互连的恢复域串联而成的。在这种情况下，可以在单个较低级别恢复域中采取恢复操作，以保护跨域的任何LSP段，也可以在较高级别恢复域中采取恢复操作，以保护跨较高级别域的较长LSP段。
The MPLS-TP recovery mechanism can be arranged to ensure coordination between domains. In interconnected rings, for example, it may be preferable to allow the upstream ring to perform recovery before the downstream ring, in order to ensure that recovery takes place in the ring in which the defect occurred. Coordination of recovery actions is particularly important in nested domains and is discussed further in Section 4.9.
可以安排MPLS-TP恢复机制以确保域之间的协调。例如，在互连环中，最好允许上游环在下游环之前执行恢复，以确保在发生缺陷的环中进行恢复。在嵌套域中，恢复操作的协调尤为重要，第4.9节将对此进行进一步讨论。
As described in the requirements listed in Section 3 and detailed in [RFC5654], the selected recovery techniques may be optimized for different network topologies if the optimized mechanisms perform significantly better than the generic mechanisms in the same topology.
如第3节列出的要求所述，并在[RFC5654]中详细说明，如果优化机制的性能明显优于相同拓扑中的通用机制，则可针对不同的网络拓扑对所选恢复技术进行优化。
These mechanisms are required (R91 of [RFC5654]) to interoperate with the mechanisms defined for arbitrary topologies, in order to allow
需要这些机制（RFC5654的R91）与为任意拓扑定义的机制进行互操作，以便允许
end-to-end protection and to ensure that consistent protection techniques are used across the entire network. In this context, 'interoperate' means that the use of one technique must not inhibit the use of another technique in an adjacent part of the network for use on the same end-to-end transport path, and must not prohibit the use of end-to-end protection mechanisms.
端到端保护，并确保在整个网络中使用一致的保护技术。在这种情况下，“互操作”意味着一种技术的使用不得禁止在网络的相邻部分使用另一种技术，以便在相同的端到端传输路径上使用，并且不得禁止使用端到端保护机制。
The next sections (4.7 and 4.8) describe two different topologies and explain how recovery may be markedly different in those different scenarios. They also develop the concept of a recovery domain and show how end-to-end survivability may be achieved through a concatenation of recovery domains, each providing some grade of recovery in part of the network.
接下来的章节（4.7和4.8）描述了两种不同的拓扑结构，并解释了在这些不同的场景中恢复可能会有显著的不同。他们还提出了恢复域的概念，并展示了如何通过连接恢复域来实现端到端的生存能力，每个恢复域在部分网络中提供一定级别的恢复。
A mesh network is any network where there is arbitrary interconnectivity between nodes in the network. Mesh networks are usually contrasted with more specific topologies such as hub-and-spoke or ring (see Section 4.8), although such networks are actually examples of mesh networks. This section is limited to the discussion of protection techniques in the context of mesh networks. That is, it does not include optimizations for specific topologies.
网状网络是网络中节点之间存在任意互连的任何网络。网状网络通常与更具体的拓扑（如轮毂和轮辐或环形）形成对比（见第4.8节），尽管此类网络实际上是网状网络的示例。本节仅限于讨论网状网络环境中的保护技术。也就是说，它不包括针对特定拓扑的优化。
Linear protection is a protection mechanism that provides rapid and simple protection switching. In a mesh network, linear protection provides a very suitable protection mechanism because it can operate between any pair of points within the network. It can protect against a defect in a node, a span, a transport path segment, or an end-to-end transport path. Linear protection gives a clear indication of the protection status.
线性保护是一种保护机制，提供快速、简单的保护切换。在网状网络中，线性保护提供了一种非常合适的保护机制，因为它可以在网络中的任何一对点之间运行。它可以防止节点、跨距、传输路径段或端到端传输路径中的缺陷。线性保护给出了保护状态的明确指示。
Linear protection operates in the context of a protection domain. A protection domain is a special type of recovery domain (see Section 4.5) associated with the protection function. A protection domain is composed of the following architectural elements:
线性保护在保护域的上下文中运行。保护域是与保护功能相关的一种特殊类型的恢复域（见第4.5节）。保护域由以下体系结构元素组成：
o A set of end points that reside at the boundary of the protection domain. In the simple case of 1:n or 1+1 P2P protection, two end points reside at the boundary of the protection domain. In each transmission direction, one of the end points is referred to as the source, and the other is referred to as the sink. For unidirectional P2MP protection, three or more end points reside at the boundary of the protection domain. One of the end points is referred to as the source/root, while the others are referred to as sinks/leaves.
o 位于保护域边界处的一组端点。在1:n或1+1 P2P保护的简单情况下，两个端点位于保护域的边界。在每个传输方向上，一个端点称为源，另一个端点称为汇。对于单向P2MP保护，三个或更多端点位于保护域的边界处。其中一个端点称为源/根，而其他端点称为汇/叶。
o A Protection Group consists of one or more working (primary) paths and one or more protection (backup) paths that run between the end points belonging to the protection domain. To guarantee protection in all scenarios, a dedicated protection path should be pre-provisioned to protect against a defect of a working path (i.e., 1:1 or 1+1 protection schemes). In addition, the working and the protection paths should be disjoint; i.e., the physical routes of the working and the protection paths should be physically diverse in every respect.
o 保护组由一个或多个工作（主）路径和一个或多个在属于保护域的端点之间运行的保护（备份）路径组成。为保证在所有情况下的保护，应预先设置专用保护路径，以防止工作路径出现缺陷（即1:1或1+1保护方案）。此外，工作路径和保护路径应不相交；i、 例如，工作和保护路径的物理路径应在各个方面具有物理多样性。
Note that if the resources of the protection path are less than those of the working path, the protection path may not have sufficient resources to protect the traffic of the working path.
注意，如果保护路径的资源小于工作路径的资源，则保护路径可能没有足够的资源来保护工作路径的通信量。
As mentioned in Section 4.3.2, the resources of the protection path may be shared as 1:n. In this scenario, the protection path will not have sufficient resources to protect all the working paths at a specific time.
如第4.3.2节所述，保护路径的资源可共享为1:n。在此场景中，保护路径将没有足够的资源在特定时间保护所有工作路径。
For bidirectional P2P paths, both unidirectional and bidirectional protection switching are supported. If a defect occurs when bidirectional protection switching is defined, the protection actions are performed in both directions (even if the defect is unidirectional). The protection state is required to operate with a level of coordination between the end points of the protection domain.
对于双向P2P路径，支持单向和双向保护切换。如果定义双向保护切换时出现缺陷，则在两个方向上执行保护动作（即使缺陷是单向的）。保护状态需要在保护域端点之间的协调水平下运行。
In unidirectional protection switching, the protection actions are only performed in the affected direction.
在单向保护切换中，保护动作仅在受影响的方向上执行。
Revertive and non-revertive operations are provided as options for the network operator.
网络运营商可选择恢复和非恢复操作。
Linear protection supports the protection schemes described in the following sub-sections.
线性保护支持以下小节中描述的保护方案。
In the 1:1 scheme, a protection path is allocated to protect against a defect, failure, or a degradation in a working path. As described above, to guarantee protection, the protection entity should support the full capacity and bandwidth, although it may be configured (for example, because of limited network resource availability) to offer a degraded service when compared with the working entity.
在1:1方案中，分配保护路径以防止工作路径中出现缺陷、故障或降级。如上所述，为了保证保护，保护实体应支持全部容量和带宽，尽管与工作实体相比，保护实体可能被配置（例如，由于有限的网络资源可用性）以提供降级服务。
Figure 1 presents 1:1 protection architecture. In normal conditions, data traffic is transmitted over the working entity, while the protection entity functions in the idle state. (OAM may run on the
图1显示了1:1保护体系结构。在正常情况下，数据流量通过工作实体传输，而保护实体在空闲状态下工作。（OAM可以在计算机上运行
protection entity to verify its state.) Normal conditions are defined when there is no defect, failure, or degradation on the working entity, and no administrative configuration or request causes traffic to flow over the protection entity.
当工作实体上没有缺陷、故障或降级，并且没有管理配置或请求导致流量流过保护实体时，将定义正常条件。
|-----------------Protection Domain---------------|
|-----------------Protection Domain---------------|
==============================
/**********Working path***********\
+--------+ ============================== +--------+
| Node /| |\ Node |
| A {< | | >} B |
| | | |
+--------+ ============================== +--------+
Protection path
==============================
==============================
/**********Working path***********\
+--------+ ============================== +--------+
| Node /| |\ Node |
| A {< | | >} B |
| | | |
+--------+ ============================== +--------+
Protection path
==============================
Figure 1: 1:1 Protection Architecture
图1:1:1保护体系结构
If there is a defect on the working entity or a specific administrative request, traffic is switched to the protection entity.
如果工作实体上存在缺陷或特定的管理请求，则通信量将切换到保护实体。
Note that when operating with non-revertive behavior (see Section 4.3.5), after the conditions causing the switchover have been cleared, the traffic continues to flow on the protection path, but the working and protection roles are not switched.
请注意，当以非恢复性行为（见第4.3.5节）运行时，在导致切换的条件被清除后，通信量继续在保护路径上流动，但工作和保护角色不会切换。
In each transmission direction, the protection domain source bridges traffic onto the appropriate entity, while the sink selects traffic from the appropriate entity. The source and the sink need to coordinate the protection states to ensure that bridging and selection are performed to and from the same entity. For this reason, a signaling coordination protocol (either a data-plane in-band signaling protocol or a control-plane-based signaling protocol) is required.
在每个传输方向上，保护域源将通信桥接到适当的实体上，而接收器从适当的实体选择通信。源和接收器需要协调保护状态，以确保在同一实体之间执行桥接和选择。因此，需要信令协调协议（带内数据平面信令协议或基于控制平面的信令协议）。
In bidirectional protection switching, both ends of the protection domain are switched to the protection entity (even when the fault is unidirectional). This requires a protocol to coordinate the protection state between the two end points of the protection domain.
在双向保护切换中，保护域的两端都切换到保护实体（即使故障是单向的）。这需要一个协议来协调保护域的两个端点之间的保护状态。
When there is no defect, the bandwidth resources of the idle entity may be used for traffic with lower priority. When protection switching is performed, the traffic with lower priority may be preempted by the protected traffic through tearing down the LSP with lower priority, reporting a fault on the LSP with lower priority, or by treating the traffic with lower priority as best effort and discarding it when there is congestion.
当不存在缺陷时，空闲实体的带宽资源可用于具有较低优先级的业务。当执行保护切换时，通过拆除低优先级的LSP、在低优先级的LSP上报告故障，或者将低优先级的流量视为尽力而为并在出现拥塞时丢弃，受保护的流量可以抢占低优先级的流量。
In the general case of 1:n linear protection, one protection entity is allocated to protect n working entities. The protection entity might not have sufficient resources to protect all the working entities that may be affected by fault conditions at a specific time. In this case, in order to guaranteed protection, the protection entity should support enough capacity and bandwidth to protect any of the n working entities.
在1:n线性保护的一般情况下，分配一个保护实体来保护n个工作实体。保护实体可能没有足够的资源来保护在特定时间可能受故障条件影响的所有工作实体。在这种情况下，为了保证保护，保护实体应该支持足够的容量和带宽来保护n个工作实体中的任何一个。
When defects or failures occur along multiple working entities, the entity to be protected should be prioritized. The protection states between the edges of the protection domain should be fully coordinated to ensure consistent behavior. As explained in Section 4.3.5, revertive behavior is recommended when 1:n is supported.
当多个工作实体出现缺陷或故障时，应优先考虑要保护的实体。保护域边缘之间的保护状态应完全协调，以确保行为一致。如第4.3.5节所述，当支持1:n时，建议采用回复行为。
In the 1+1 protection scheme, a fully dedicated protection entity is allocated.
在1+1保护方案中，分配了一个完全专用的保护实体。
As depicted in Figure 2, data traffic is copied and fed at the source to both the working and the protection entities. The traffic on the working and the protection entities is transmitted simultaneously to the sink of the protection domain, where selection between the working and protection entities is performed (based on some predetermined criteria).
如图2所示，数据通信量在源位置被复制并馈送到工作实体和保护实体。工作实体和保护实体上的业务被同时发送到保护域的接收器，在该接收器中执行工作实体和保护实体之间的选择（基于一些预定标准）。
|---------------Protection Domain---------------|
|---------------Protection Domain---------------|
==============================
/**********Working path************\
+--------+ ============================== +--------+
| Node /| |\ Node |
| A {< | | >} Z |
| \| |/ |
+--------+ ============================== +--------+
\**********Protection path*********/
==============================
==============================
/**********Working path************\
+--------+ ============================== +--------+
| Node /| |\ Node |
| A {< | | >} Z |
| \| |/ |
+--------+ ============================== +--------+
\**********Protection path*********/
==============================
Figure 2: 1+1 Protection Architecture
图2:1+1保护体系结构
Note that control traffic between the edges of the protection domain (such as OAM or a control protocol to coordinate the protection state, etc.) may be transmitted on an entity that differs from the one used for the protected traffic. These packets should not be discarded by the sink.
注意，保护域边缘之间的控制通信量（例如OAM或协调保护状态的控制协议等）可以在不同于用于受保护通信量的实体上传输。接收器不应丢弃这些数据包。
In 1+1 unidirectional protection switching, there is no need to coordinate the protection state between the protection controllers at both ends of the protection domain. In 1+1 bidirectional protection switching, a protocol is required to coordinate the protection state between the edges of the protection domain.
在1+1单向保护切换中，保护域两端的保护控制器之间无需协调保护状态。在1+1双向保护交换中，需要一个协议来协调保护域边缘之间的保护状态。
In both protection schemes, traffic flows end-to-end on the working entity after the conditions causing the switchover have been cleared. Data selection may return to selecting traffic from the working entity if reversion is enabled, and it will require coordination of the protection state between the edges of the protection domain. To avoid frequent switching caused by intermittent defects or failures when the network is not stable, traffic is not selected from the working entity before the Wait-To-Restore (WTR) timer has expired.
在这两种保护方案中，在导致切换的条件被清除后，工作实体上的交通流是端到端的。如果启用了恢复，数据选择可能返回到从工作实体选择流量，并且需要协调保护域边缘之间的保护状态。为了避免网络不稳定时间歇性缺陷或故障导致的频繁切换，在等待恢复（WTR）计时器过期之前，不会从工作实体中选择流量。
Linear protection may be applied to protect unidirectional P2MP entities using 1+1 protection architecture. The source/root MPLS-TP node bridges the user traffic to both the working and protection entities. Each sink/leaf MPLS-TP node selects the traffic from one entity according to some predetermined criteria. Note that when there is a fault condition on one of the branches of the P2MP path, some leaf MPLS-TP nodes may select the working entity, while other leaf MPLS-TP nodes may select traffic from the protection entity.
线性保护可用于使用1+1保护架构保护单向P2MP实体。源/根MPLS-TP节点将用户流量桥接到工作实体和保护实体。每个接收器/叶MPLS-TP节点根据一些预定标准从一个实体选择流量。注意，当P2MP路径的一个分支上存在故障条件时，一些叶MPLS-TP节点可以选择工作实体，而其他叶MPLS-TP节点可以选择来自保护实体的流量。
In a 1:1 P2MP protection scheme, the source/root MPLS-TP node needs to identify the existence of a fault condition on any of the branches of the network. This means that the sink/leaf MPLS-TP nodes need to notify the source/root MPLS-TP node of any fault condition. This also necessitates a return path from the sinks/leaves to the source/root MPLS-TP node. When protection switching is triggered, the source/root MPLS-TP node selects the protection transport path for traffic transfer.
在1:1 P2MP保护方案中，源/根MPLS-TP节点需要识别网络任何分支上是否存在故障条件。这意味着接收器/叶MPLS-TP节点需要将任何故障情况通知源/根MPLS-TP节点。这还需要从汇/叶到源/根MPLS-TP节点的返回路径。触发保护切换时，源/根MPLS-TP节点选择保护传输路径进行流量传输。
A form of "segment recovery for P2MP LSPs" could be constructed. Given a P2MP LSP, one can protect any possible point of failure (link or node) using N backup P2MP LSPs. Each backup P2MP LSP originates from the upstream node with respect to a different possible failure point and terminates at all of the destinations downstream of the potential failure point. In case of a failure, traffic is redirected to the backup P2MP path.
可以构造一种“P2MP LSP的段恢复”形式。给定P2MP LSP，可以使用N个备份P2MP LSP保护任何可能的故障点（链路或节点）。每个备份P2MP LSP从上游节点针对不同的可能故障点发起，并在潜在故障点下游的所有目的地终止。如果出现故障，流量将重定向到备份P2MP路径。
Note that such mechanisms do not yet exist, and their exact behavior is for further study.
请注意，此类机制尚不存在，其确切行为有待进一步研究。
A 1:n protection scheme for P2MP transport paths is also required by [RFC5654]. Such a mechanism is for future study.
[RFC5654]还需要P2MP传输路径的1:n保护方案。这一机制有待进一步研究。
Protection switching may be performed when:
在下列情况下，可进行保护切换：
o A defect condition is detected on the working entity, and the protection entity has "no" or an inferior condition. Proactive in-band OAM Continuity Check and Connectivity Verification (CC-V) monitoring of both the working and the protection entities may be used to enable the rapid detection of a fault condition. For protection switching, it is common to run a CC-V every 3.33 ms. In the absence of three consecutive CC-V messages, a fault condition is declared. In order to monitor the working and the protection entities, an OAM Maintenance Entity Group should be defined for each entity. OAM indications associated with fault conditions should be provided at the edges of the protection domain that is responsible for the protection-switching operation. Input from OAM performance monitoring that indicates degradation in the working entity may also be used as a trigger for protection switching. In the case of degradation, switching to the protection entity is needed only if the protection entity can exhibit better operating conditions.
o 在工作实体上检测到缺陷状态，并且保护实体具有“无”或劣质状态。对工作实体和保护实体的主动带内OAM连续性检查和连接验证（CC-V）监控可用于快速检测故障状况。对于保护切换，通常每3.33 ms运行一次CC-V。在没有三条连续CC-V消息的情况下，会宣布故障状态。为了监控工作实体和保护实体，应该为每个实体定义一个OAM维护实体组。应在负责保护切换操作的保护域边缘提供与故障条件相关的OAM指示。来自OAM性能监视的输入指示工作实体中的降级，也可用作保护切换的触发器。在降级的情况下，仅当保护实体能够表现出更好的运行条件时，才需要切换到保护实体。
o An indication is received from a lower-layer server that there is a defect in the lower layer.
o 从下层服务器接收到下层存在缺陷的指示。
o An external operator command is received (e.g., 'Forced Switch', 'Manual Switch'). For details, see Section 6.1.2.
o 接收到外部操作员命令（例如，“强制开关”、“手动开关”）。有关详细信息，请参见第6.1.2节。
o A request to switch over is received from the far end. The far end may initiate this request, for example, on receipt of an administrative request to switch over, or when bidirectional 1:1 protection switching is supported and a defect occurred that could only be detected by the far end, etc.
o 从远端接收到切换请求。远端可以发起该请求，例如，在接收到切换的管理请求时，或者在支持双向1:1保护切换并且发生了只能由远端检测到的缺陷时，等等。
As described above, the protection state should be coordinated between the end points of the protection domain. Control messages should be exchanged between the edges of the protection domain to coordinate the protection state of the edge nodes. Control messages can be delivered using an in-band, data-plane-driven control protocol or a control-plane-based protocol.
如上所述，保护状态应在保护域的端点之间进行协调。应在保护域的边缘之间交换控制消息，以协调边缘节点的保护状态。可以使用带内、数据平面驱动的控制协议或基于控制平面的协议来传递控制消息。
For 50-ms protection switching, it is recommended that an in-band, data-plane-driven signaling protocol be used in order to coordinate the protection states. An in-band, data-plane protocol for use in MPLS-TP networks is documented in [MPLS-TP-LP] for linear protection (ring protection is discussed in Section 4.8 of this document). This protocol is also used to detect mismatches between the configurations provisioned at the ends of the protection domain.
对于50 ms的保护切换，建议使用带内数据平面驱动的信令协议来协调保护状态。用于MPLS-TP网络的带内数据平面协议记录在[MPLS-TP-LP]中，用于线性保护（本文件第4.8节讨论了环保护）。此协议还用于检测在保护域末端提供的配置之间的不匹配。
As described in Section 6.5, the GMPLS control plane already includes procedures and message elements to coordinate the protection states between the edges of the protection domain. These procedures and protocol messages are specified in [RFC4426], [RFC4872], and [RFC4873]. However, these messages lack the capability to coordinate the revertive/non-revertive behavior and the consistency of configured timers at the edges of the protection domain (timers such as WTR, hold-off timer, etc.).
如第6.5节所述，GMPLS控制平面已经包括程序和消息元素，用于协调保护域边缘之间的保护状态。[RFC4426]、[RFC4872]和[RFC4873]中规定了这些过程和协议消息。但是，这些消息缺乏协调恢复/非恢复行为的能力，以及在保护域边缘配置的计时器（如WTR、延迟计时器等）的一致性。
In order to implement data-plane-based linear protection on LSP segments, use is made of the Sub-Path Maintenance Element (SPME), an MPLS-TP architectural element defined in [RFC5921]. Maintenance operations (e.g., monitoring, protection, or management) engage with message transmission (e.g., OAM, Protection Path Coordination, etc.) in the maintained domain. Further discussion of the architecture for OAM and SPME is found in [RFC5921] and [RFC6371]. An SPME is an LSP that is basically defined and used for the purposes of OAM monitoring, protection, or management of LSP segments. The SPME uses the MPLS construct of a hierarchical, nested LSP, as defined in [RFC3031].
为了在LSP段上实现基于数据平面的线性保护，使用了子路径维护元素（SPME），[RFC5921]中定义的MPLS-TP体系结构元素。维护操作（例如，监控、保护或管理）与维护域中的消息传输（例如，OAM、保护路径协调等）相结合。[RFC5921]和[RFC6371]中进一步讨论了OAM和SPME的体系结构。SPME是一种LSP，它基本上是为了对LSP段进行OAM监视、保护或管理而定义和使用的。SPME使用[RFC3031]中定义的分层嵌套LSP的MPLS结构。
For linear protection, SPMEs should be defined over the working and protection entities between the edges of a protection domain. OAM messages and messages used to coordinate protection state can be initiated at the edge of the SPME and sent to the peer edge of the SPME. Note that these messages are sent over the Generic Associated Channel (G-ACh) within the SPME, and that they use a two-label stack, the SPME label, and, at the bottom of the stack, the G-ACh label (GAL) [RFC5586].
对于线性保护，应在保护域边缘之间的工作和保护实体上定义SPME。OAM消息和用于协调保护状态的消息可以在SPME的边缘启动，并发送到SPME的对等边缘。请注意，这些消息是通过SPME内的通用关联通道（G-ACh）发送的，它们使用两个标签堆栈，即SPME标签，以及堆栈底部的G-ACh标签（GAL）[RFC5586]。
The end-to-end traffic of the LSP, which includes data traffic and control traffic (messages for OAM, management, signaling, and to coordinate protection state), is tunneled within the SPMEs by means of label stacking, as defined in [RFC3031].
LSP的端到端通信量，包括数据通信量和控制通信量（用于OAM、管理、信令和协调保护状态的消息），通过标签堆叠在SPME内进行隧道传输，如[RFC3031]中所定义。
Mapping between an LSP and an SPME can be 1:1; this is similar to the ITU-T Tandem Connection element that defines a sub-layer corresponding to a segment of a path. Mapping can also be 1:n to allow the scalable protection of a set of LSP segments traversing the part of the network in which a protection domain is defined. Note that each of these LSPs can be initiated or terminated at different end points in the network, but that they all traverse the protection domain and share similar constraints (such as requirements for quality of service (QoS), terms of protection, etc.).
LSP和SPME之间的映射可以是1:1；这类似于ITU-T串联连接元件，该元件定义了对应于路径段的子层。映射也可以是1:n，以允许对穿过定义保护域的网络部分的一组LSP段进行可伸缩保护。请注意，这些LSP中的每一个都可以在网络中的不同端点处启动或终止，但它们都会穿越保护域并共享类似的约束（例如服务质量（QoS）要求、保护条款等）。
Note also that in the context of segment protection, the SPMEs serve as the working and protection entities.
还应注意，在段保护的情况下，SPME充当工作和保护实体。
For shared mesh protection, the protection resources are used to protect multiple LSPs that do not all share the same end points; for example, in Figure 3 there are two paths, ABCDE and VWXYZ. These paths do not share end points and cannot, therefore, make use of 1:n linear protection, even though they do not have any common points of failure.
对于共享网格保护，保护资源用于保护不共享相同端点的多个LSP；例如，在图3中有两条路径，ABCDE和VWXYZ。这些路径不共享端点，因此无法使用1:n线性保护，即使它们没有任何共同的故障点。
ABCDE may be protected by the path APQRE, while VWXYZ can be protected by the path VPQRZ. In both cases, 1:1 or 1+1 protection may be used. However, it can be seen that if 1:1 protection is used for both paths, the PQR network segment does not carry traffic when no failures affect either of the two working paths. Furthermore, in the event of only one failure, the PQR segment carries traffic from only one of the working paths.
ABCDE可以通过路径APQRE进行保护，而VWXYZ可以通过路径VPQRZ进行保护。在这两种情况下，都可以使用1:1或1+1保护。但是，可以看出，如果对两条路径都使用1:1保护，当没有故障影响两条工作路径中的任何一条时，PQR网段不承载流量。此外，在仅发生一次故障的情况下，PQR段仅承载来自其中一条工作路径的流量。
Thus, it is possible for the network resources on the PQR segment to be shared by the two recovery paths. In this way, mesh protection can substantially reduce the number of network resources that have to be reserved in order to provide 1:n protection.
因此，PQR段上的网络资源可能由两条恢复路径共享。这样，网状网保护可以大大减少为了提供1:n保护而必须保留的网络资源的数量。
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
Figure 3: A Shared Mesh Protection Topology
图3：共享网格保护拓扑
As the network becomes more complex and the number of LSPs increases, the potential for shared mesh protection also increases. However, this can quickly become unmanageable owing to the increased complexity. Therefore, shared mesh protection is normally pre-planned and configured by the operator, although an automated system cannot be ruled out.
随着网络变得更加复杂，LSP数量增加，共享网格保护的潜力也随之增加。但是，由于复杂性的增加，这可能很快变得难以管理。因此，共享网格保护通常由操作员预先规划和配置，但不能排除自动系统的可能性。
Note that shared mesh protection operates as 1:n linear protection (see Section 4.7.1). However, the protection state needs to be coordinated between a larger number of nodes: the end points of the shared concatenated protection segment (nodes P and R in the example)
请注意，共享网格保护作为1:n线性保护运行（见第4.7.1节）。但是，保护状态需要在更多节点之间进行协调：共享连接保护段的端点（示例中的节点P和R）
as well as the end points of the protected LSPs (nodes A, E, V, and Z in the example).
以及受保护LSP的端点（示例中的节点A、E、V和Z）。
Additionally, note that the shared-protection resources could be used to carry extra traffic. For example, in Figure 4, an LSP JPQRK could be a preemptable LSP that constitutes extra traffic over the PQR hops; it would be displaced in the event of a protection event. In this case, it should be noted that the protection state must also be coordinated with the ends of the extra-traffic LSPs.
此外，请注意，共享保护资源可用于承载额外流量。例如，在图4中，LSP JPQRK可以是可抢占的LSP，其构成PQR跳上的额外通信量；如果发生保护事件，它将被替换。在这种情况下，应注意保护状态还必须与额外业务lsp的端部协调。
A----B----C----D----E
\ /
\ /
\ /
J-----P-----Q-----R-----K
/ \
/ \
/ \
V----W----X----Y----Z
A----B----C----D----E
\ /
\ /
\ /
J-----P-----Q-----R-----K
/ \
/ \
/ \
V----W----X----Y----Z
Figure 4: Shared Mesh Protection with Extra Traffic
图4：具有额外流量的共享网格保护
Several service providers have expressed great interest in the operation of MPLS-TP in ring topologies; they demand a high degree of survivability functionality in these topologies.
一些服务提供商对环形拓扑中MPLS-TP的运行表示了极大的兴趣；在这些拓扑中，它们需要高度的可生存性功能。
Various criteria for optimization are considered in ring topologies, such as:
环形拓扑中考虑了各种优化标准，例如：
1. Simplification in ring operation in terms of the number of OAM Maintenance Entities that are needed to trigger the recovery actions, the number of recovery elements, the number of management-plane transactions during maintenance operations, etc.
1. 根据触发恢复操作所需的OAM维护实体的数量、恢复元素的数量、维护操作期间管理平面事务的数量等简化环操作。
2. Optimization of resource consumption around the ring, such as the number of labels needed for the protection paths that traverse the network, the total bandwidth required in the ring to ensure path protection, etc. (see R91 of [RFC5654]).
2. 优化环周围的资源消耗，如穿越网络的保护路径所需的标签数量、环中确保路径保护所需的总带宽等（参见[RFC5654]的R91）。
[RFC5654] introduces a list of requirements for ring protection covering the recovery mechanisms needed to protect traffic in a single ring as well as traffic that traverses more than one ring. Note that configuration and the operation of the recovery mechanisms in a ring must scale well with the number of transport paths, the number of nodes, and the number of ring interconnects.
[RFC5654]介绍了环保护的要求列表，包括保护单个环中的流量以及穿越多个环的流量所需的恢复机制。请注意，环中恢复机制的配置和操作必须与传输路径的数量、节点的数量和环互连的数量保持良好的比例。
The requirements for ring protection are fully compatible with the generic requirements for recovery.
环形保护的要求与恢复的一般要求完全兼容。
The architecture and the mechanisms for ring protection are specified in separate documents. These mechanisms need to be evaluated against the requirements specified in [RFC5654], which includes guidance on the principles for the development of new mechanisms.
环保护的体系结构和机制在单独的文档中指定。这些机制需要根据[RFC5654]中规定的要求进行评估，其中包括新机制开发原则的指导。
In multi-layer or multi-regional networking [RFC5212], recovery may be performed at multiple layers or across nested recovery domains.
在多层或多区域联网[RFC5212]中，可以在多层或跨嵌套恢复域执行恢复。
The MPLS-TP recovery mechanism must ensure that the timing of recovery is coordinated in order to avoid race scenarios. This also allows the recovery mechanism of the server layer to fix the problem before recovery takes place in the MPLS-TP layer, or the MPLS-TP layer to perform recovery before a client network.
MPLS-TP恢复机制必须确保恢复时间得到协调，以避免竞争情况。这还允许服务器层的恢复机制在MPLS-TP层中进行恢复之前修复问题，或者MPLS-TP层在客户端网络之前执行恢复。
A hold-off timer is required to coordinate recovery timing in multiple layers or across nested recovery domains. Setting this configurable timer involves a trade-off between rapid recovery and the creation of a race condition where multiple layers respond to the same fault, potentially allocating resources in an inefficient manner. Thus, the detection of a defect condition in the MPLS-TP layer should not immediately trigger the recovery process if the hold-off timer is configured as a value other than zero. Instead, the hold-off timer should be started when the defect is detected and, on expiry, the recovery element should be checked to determine whether the defect condition still exists. If it does exist, the defect triggers the recovery operation.
需要一个延迟计时器来协调多层或嵌套恢复域中的恢复时间。设置此可配置计时器需要在快速恢复和创建竞态条件之间进行权衡，在竞态条件下，多个层响应同一故障，从而可能以低效的方式分配资源。因此，如果延迟计时器被配置为非零的值，则MPLS-TP层中缺陷条件的检测不应立即触发恢复过程。相反，当检测到缺陷时，应启动暂停计时器，到期时，应检查恢复元件，以确定缺陷条件是否仍然存在。如果该缺陷确实存在，则会触发恢复操作。
The hold-off timer should be configurable.
延迟计时器应该是可配置的。
In other configurations, where the lower layer does not have a restoration capability, or where it is not expected to provide protection, the lower layer needs to trigger the higher layer to immediately perform recovery. Although this can be forced by configuring the hold-off timer as zero, it may be that because of layer independence, the higher layer does not know whether the lower layer will perform restoration. In this case, the higher layer will configure a non-zero hold-off timer and rely on the receipt of a specific notification from the lower layer if the lower layer cannot perform restoration. Since layer boundaries are always within nodes, such coordination is implementation-specific and does not need to be covered here.
在其他配置中，如果较低层不具有恢复能力，或者不希望提供保护，则较低层需要触发较高层立即执行恢复。尽管这可以通过将保持计时器配置为零来强制执行，但可能是由于层独立性，高层不知道下层是否将执行恢复。在这种情况下，如果较低层无法执行恢复，则较高层将配置一个非零延迟计时器，并依赖于从较低层接收到的特定通知。因为层边界总是在节点内，所以这种协调是特定于实现的，不需要在这里讨论。
Reference should be made to [RFC3386], which discusses the interaction between layers in survivable networks.
应参考[RFC3386]，其中讨论了可生存网络中各层之间的交互。
Where a link in the MPLS-TP network is formed through connectivity (i.e., a packet or non-packet LSP) in a lower-layer network, that connectivity may itself be protected; for example, the LSP in the lower-layer network may be provisioned with 1+1 protection. In this case, the link in the MPLS-TP network has an inherited grade of protection.
在MPLS-TP网络中的链路通过下层网络中的连接（即，分组或非分组LSP）形成的情况下，该连接本身可以被保护；例如，较低层网络中的LSP可以提供1+1保护。在这种情况下，MPLS-TP网络中的链路具有继承的保护等级。
An LSP in the MPLS-TP network may be provisioned with protection in the MPLS-TP network, as already described, or it may be provisioned to utilize only those links that have inherited protection.
如前所述，MPLS-TP网络中的LSP可以在MPLS-TP网络中设置保护，或者可以设置为仅利用具有继承保护的那些链路。
By classifying the links in the MPLS-TP network according to the grade of protection that they inherited from the server network, it is possible to compute an end-to-end path in the MPLS-TP network that uses only those links with a specific or superior grade of inherited protection. This means that the end-to-end MPLS-TP LSP can be protected at the grade necessary to conform to the SLA without needing to provide any additional protection in the MPLS-TP layer. This reduces complexity, saves network resources, and eliminates protection-switching coordination problems.
通过根据从服务器网络继承的保护等级对MPLS-TP网络中的链路进行分类，可以计算MPLS-TP网络中仅使用具有特定或更高继承保护等级的链路的端到端路径。这意味着端到端MPLS-TP LSP可以在符合SLA所需的级别上受到保护，而无需在MPLS-TP层中提供任何额外的保护。这降低了复杂性，节省了网络资源，并消除了保护切换协调问题。
When the requisite grade of inherited protection is not available on all segments along the path in the MPLS-TP network, segment protection may be used to achieve the desired protection grade.
当在MPLS-TP网络中沿路径的所有段上没有必要的继承保护等级时，可以使用段保护来实现所需的保护等级。
It should be noted, however, that inherited protection only applies to links. Nodes cannot be protected in this way. An operator will need to perform an analysis of the relative likelihood and consequences of node failure if this approach is taken without providing protection in the MPLS-TP LSP or PW layer to handle node failure.
但是，应该注意的是，继承的保护只适用于链接。不能以这种方式保护节点。如果采用这种方法而不在MPLS-TP LSP或PW层提供保护来处理节点故障，则运营商需要对节点故障的相对可能性和后果进行分析。
When an MPLS-TP protection scheme is established, it is important that the working and protection paths do not share resources in the network. If this is not achieved, a single defect may affect both the working and the protection paths with the result that traffic cannot be delivered -- since under such a condition the traffic was not protected.
建立MPLS-TP保护方案时，工作路径和保护路径不共享网络中的资源非常重要。如果无法实现这一点，则单个缺陷可能会影响工作路径和保护路径，从而导致无法传输流量，因为在这种情况下，流量没有得到保护。
Note that this restriction does not apply to restoration, since this takes place after the fault has occurred, which means that the point of failure can be avoided if an available path exists.
请注意，此限制不适用于恢复，因为恢复发生在故障发生后，这意味着如果存在可用路径，则可以避免故障点。
When planning a recovery scheme, it is possible to use a topology map of the MPLS-TP layer to select paths that use diverse links and nodes within the MPLS-TP network. However, this does not guarantee that the paths are truly diverse; for example, two separate links in an MPLS-TP network may be provided by two lambdas in the same optical fiber, or by two fibers that cross the same bridge. Moreover, two completely separate MPLS-TP nodes might be situated in the same building with a shared power supply.
在规划恢复方案时，可以使用MPLS-TP层的拓扑图来选择在MPLS-TP网络中使用不同链路和节点的路径。然而，这并不能保证道路是真正多样的；例如，MPLS-TP网络中的两个独立链路可以由同一光纤中的两个lambda提供，或者由穿过同一网桥的两个光纤提供。此外，两个完全独立的MPLS-TP节点可能位于具有共享电源的同一建筑物中。
Thus, in order to achieve proper recovery planning, the MPLS-TP network must have an understanding of the groups of lower-layer resources that share a common risk of failure. From this, MPLS-TP shared risk groups can be constructed that show which MPLS-TP resources share a common risk of failure. Diversity of working and protection paths can be planned, not only with regard to nodes and links but also in order to refrain from using resources from the same shared risk groups.
因此，为了实现适当的恢复规划，MPLS-TP网络必须了解共享常见故障风险的低层资源组。由此，可以构建MPLS-TP共享风险组，以显示哪些MPLS-TP资源共享共同的故障风险。可以规划工作和保护路径的多样性，不仅针对节点和链路，而且为了避免使用来自相同共享风险组的资源。
In a layered network, a low-layer fault may be detected and reported by multiple layers and may sometimes lead to the generation of multiple fault reports from the same layer. For example, a failure of a data link may be reported by the line cards in an MPLS-TP node, but it could also be detected and reported by the MPLS-TP OAM.
在分层网络中，低层故障可能由多个层检测和报告，有时可能导致从同一层生成多个故障报告。例如，数据链路故障可由MPLS-TP节点中的线路卡报告，但也可由MPLS-TP OAM检测和报告。
Section 4.6 explains how it is important to coordinate the survivability actions configured and operated in a multi-layer network in a way that will avoid over-equipping the survivability resources in the network, while ensuring that recovery actions are performed in only one layer at a time.
第4.6节解释了协调在多层网络中配置和运行的生存能力行动的重要性，其方式将避免过度配置网络中的生存能力资源，同时确保一次仅在一层中执行恢复行动。
Fault correlation is about understanding which single event has generated a set of fault reports, so that recovery actions can be coordinated, and so that the fault logging system does not become overloaded. Fault correlation depends on understanding resource use at lower layers, shared risk groups, and a wider view with regard to the way in which the layers are interrelated.
故障关联是指了解哪个单一事件已生成一组故障报告，以便协调恢复操作，并使故障记录系统不会过载。断层相关性取决于了解较低层的资源使用情况、共享风险组以及对各层相互关联方式的更广泛看法。
Fault correlation is most easily performed at the point of fault detection; for example, an MPLS-TP node that receives a fault notification from the lower layer, and detects a fault on an LSP in the MPLS-TP layer, can easily correlate these two events. Furthermore, if the same node detects multiple faults on LSPs that
故障关联最容易在故障检测点执行；例如，从较低层接收故障通知并在MPLS-TP层的LSP上检测到故障的MPLS-TP节点可以轻松地将这两个事件关联起来。此外，如果同一节点在LSP上检测到多个故障
share the same faulty data link, it can easily correlate them. Such a node may use correlation to perform group-based recovery actions and can reduce the number of alarm events that it generates to its management station.
共享同一个故障数据链路，它可以轻松地将它们关联起来。这样的节点可以使用关联来执行基于组的恢复操作，并且可以减少它向其管理站生成的报警事件的数量。
Fault correlation may also be performed at a management station that receives fault reports from different layers and different nodes in the network. This enables the management station to coordinate management-originated recovery actions and to present consolidated fault information to the user and automated management systems.
故障关联还可以在从网络中的不同层和不同节点接收故障报告的管理站处执行。这使管理站能够协调源于管理的恢复操作，并向用户和自动化管理系统提供整合的故障信息。
It is also necessary to correlate fault information detected and reported through OAM. This function would enable a fault detected at a lower layer, and reported at a transit node of an MPLS-TP LSP, to be correlated with an MPLS-TP-layer fault detected at a Maintenance End Point (MEP) -- for example, the egress of the MPLS-TP LSP. Such correlation allows the coordination of recovery actions performed at the MEP, but it also requires that the lower-layer fault information is propagated to the MEP, which is most easily achieved using a control plane, management plane, or OAM message.
还需要关联通过OAM检测和报告的故障信息。此功能将使在较低层检测到并在MPLS-TP LSP的传输节点上报告的故障能够与在维护端点（MEP）检测到的MPLS-TP层故障相关联——例如，MPLS-TP LSP的出口。这种关联允许协调在MEP处执行的恢复操作，但它还要求将较低层故障信息传播到MEP，这是使用控制平面、管理平面或OAM消息最容易实现的。
The MPLS-TP network can be viewed as two layers (the MPLS LSP layer and the PW layer). The MPLS-TP network operates over data-link connections and data-link networks whereby the MPLS-TP links are provided by individual data links or by connections in a lower-layer network. The MPLS LSP layer is a mandatory part of the MPLS-TP network, while the PW layer is an optional addition for supporting specific services.
MPLS-TP网络可以看作是两层（MPLS LSP层和PW层）。MPLS-TP网络通过数据链路连接和数据链路网络运行，其中MPLS-TP链路由单个数据链路或较低层网络中的连接提供。MPLS LSP层是MPLS-TP网络的必需部分，而PW层是支持特定服务的可选附加层。
MPLS-TP survivability provides recovery from failure of the links and nodes in the MPLS-TP network. The link defects and failures are typically caused by defects or failures in the underlying data-link connections and networks, but this section is only concerned with recovery actions performed in the MPLS-TP network, which must recover from the manifestation of any problem as a defect failure in the MPLS-TP network.
MPLS-TP生存性提供了从MPLS-TP网络中的链路和节点故障中恢复的功能。链路缺陷和故障通常是由底层数据链路连接和网络中的缺陷或故障引起的，但本节仅涉及在MPLS-TP网络中执行的恢复操作，这些操作必须从MPLS-TP网络中出现的缺陷故障中恢复。
This section lists the recovery elements (see Section 1) supported in each of the two layers that can recover from defects or failures of nodes or links in the MPLS-TP network.
本节列出了两层中每一层支持的恢复元素（见第1节），它们可以从MPLS-TP网络中节点或链路的缺陷或故障中恢复。
+--------------+---------------------+------------------------------+
| Recovery | MPLS LSP Layer | PW Layer |
| Element | | |
+--------------+---------------------+------------------------------+
| Link | MPLS LSP recovery | The PW layer is not aware of |
| Recovery | can be used to | the underlying network. |
| | survive the failure | This function is not |
| | of an MPLS-TP link. | supported. |
+--------------+---------------------+------------------------------+
| Segment/Span | An individual LSP | For an SS-PW, segment |
| Recovery | segment can be | recovery is the same as |
| | recovered to | end-to-end recovery. |
| | survive the failure | Segment recovery for an MS-PW|
| | of an MPLS-TP link. | is for future study, and |
| | | this function is now |
| | | provided using end-to-end |
| | | recovery. |
+--------------+---------------------+------------------------------+
| Concatenated | A concatenated LSP | Concatenated segment |
| Segment | segment can be | recovery (in an MS-PW) is for|
| Recovery | recovered to | future study, and this |
| | survive the failure | function is now provided |
| | of an MPLS-TP link | using end-to-end recovery. |
| | or node. | |
+--------------+---------------------+------------------------------+
| End-to-End | An end-to-end LSP | End-to-end PW recovery can |
| Recovery | can be recovered to | be applied to survive any |
| | survive any node or | node (including S-PE) or |
| | link failure, | link failure, except for |
| | except for the | failure of the ingress or |
| | failure of the | egress T-PE. |
| | ingress or egress | |
| | node. | |
+--------------+---------------------+------------------------------+
| Service | The MPLS LSP layer | PW-layer service recovery |
| Recovery | is service- | requires surviving faults in |
| | agnostic. This | T-PEs or on Attachment |
| | function is not | Circuits (ACs). This is |
| | supported. | currently out of scope for |
| | | MPLS-TP. |
+--------------+---------------------+------------------------------+
+--------------+---------------------+------------------------------+
| Recovery | MPLS LSP Layer | PW Layer |
| Element | | |
+--------------+---------------------+------------------------------+
| Link | MPLS LSP recovery | The PW layer is not aware of |
| Recovery | can be used to | the underlying network. |
| | survive the failure | This function is not |
| | of an MPLS-TP link. | supported. |
+--------------+---------------------+------------------------------+
| Segment/Span | An individual LSP | For an SS-PW, segment |
| Recovery | segment can be | recovery is the same as |
| | recovered to | end-to-end recovery. |
| | survive the failure | Segment recovery for an MS-PW|
| | of an MPLS-TP link. | is for future study, and |
| | | this function is now |
| | | provided using end-to-end |
| | | recovery. |
+--------------+---------------------+------------------------------+
| Concatenated | A concatenated LSP | Concatenated segment |
| Segment | segment can be | recovery (in an MS-PW) is for|
| Recovery | recovered to | future study, and this |
| | survive the failure | function is now provided |
| | of an MPLS-TP link | using end-to-end recovery. |
| | or node. | |
+--------------+---------------------+------------------------------+
| End-to-End | An end-to-end LSP | End-to-end PW recovery can |
| Recovery | can be recovered to | be applied to survive any |
| | survive any node or | node (including S-PE) or |
| | link failure, | link failure, except for |
| | except for the | failure of the ingress or |
| | failure of the | egress T-PE. |
| | ingress or egress | |
| | node. | |
+--------------+---------------------+------------------------------+
| Service | The MPLS LSP layer | PW-layer service recovery |
| Recovery | is service- | requires surviving faults in |
| | agnostic. This | T-PEs or on Attachment |
| | function is not | Circuits (ACs). This is |
| | supported. | currently out of scope for |
| | | MPLS-TP. |
+--------------+---------------------+------------------------------+
Table 1: Recovery Elements Supported by the MPLS LSP Layer and PW Layer
表1:MPLS LSP层和PW层支持的恢复元素
Section 6 provides a description of mechanisms for MPLS-TP-LSP survivability. Section 7 provides a brief overview of mechanisms for MPLS-TP-PW survivability.
第6节描述了MPLS-TP-LSP生存性的机制。第7节简要概述了MPLS-TP-PW生存性机制。
This section describes the existing mechanisms that provide LSP protection within MPLS-TP networks and highlights areas where new work is required.
本节介绍了在MPLS-TP网络中提供LSP保护的现有机制，并重点介绍了需要开展新工作的领域。
As described above, a fundamental requirement of MPLS-TP is that recovery mechanisms should be capable of functioning in the absence of a control plane. Recovery may be triggered by MPLS-TP OAM fault management functions or by external requests (e.g., an operator's request for manual control of protection switching). Recovery LSPs (and in particular Restoration LSPs) may be provisioned through the management plane.
如上所述，MPLS-TP的基本要求是恢复机制应能够在没有控制平面的情况下工作。恢复可能由MPLS-TP OAM故障管理功能或外部请求触发（例如，操作员请求手动控制保护切换）。恢复lsp（尤其是恢复lsp）可以通过管理平面来供应。
The management plane may be used to configure the recovery domain by setting the reference end-point points (which control the recovery actions), the working and the recovery entities, and the recovery type (e.g., 1:1 bidirectional linear protection, ring protection, etc.).
管理平面可用于通过设置参考端点（控制恢复动作）、工作和恢复实体以及恢复类型（例如，1:1双向线性保护、环保护等）来配置恢复域。
Additional parameters associated with the recovery process (such as WTR and hold-off timers, revertive/non-revertive operation, etc.) may also be configured.
还可以配置与恢复过程相关的附加参数（例如WTR和保持定时器、恢复/非恢复操作等）。
In addition, the management plane may initiate manual control of the recovery function. A priority should be set for the fault conditions and the operator's requests.
此外，管理平面可启动恢复功能的手动控制。应为故障条件和操作员的请求设置优先级。
Since provisioning the recovery domain involves the selection of a number of options, mismatches may occur at the different reference points. The MPLS-TP protocol to coordinate protection state, which is specified in [MPLS-TP-LP], may be used as an in-band (i.e., data-plane-based) control protocol to coordinate the protection states between the end points of the recovery domain, and to check the consistency of configured parameters (such as timers, revertive/non-revertive behavior, etc.) with discovered inconsistencies that are reported to the operator.
由于配置恢复域涉及到许多选项的选择，因此可能会在不同的参考点发生不匹配。[MPLS-TP-LP]中规定的用于协调保护状态的MPLS-TP协议可用作带内（即基于数据平面的）控制协议，以协调恢复域端点之间的保护状态，并检查配置参数（如定时器、恢复/非恢复行为等）的一致性向操作员报告发现的不一致。
It should also be possible for the management plane to track the recovery status by receiving reports or by issuing polls.
管理层还可以通过接收报告或发布调查来跟踪恢复状态。
To implement the protection-switching mechanisms, the following entities and information should be configured and provisioned:
要实现保护切换机制，应配置和提供以下实体和信息：
o The end points of a recovery domain. As described above, these end points border on the element of recovery to which recovery is applied.
o 恢复域的端点。如上所述，这些端点与应用恢复的恢复元素相邻。
o The protection group, which, depending on the required protection scheme, consists of a recovery entity and one or more working entities. In 1:1 or 1+1 P2P protection, the paths of the working entity and the recovery entities must be physically diverse in every respect (i.e., not share any resources or physical locations), in order to guarantee protection.
o 保护组由一个恢复实体和一个或多个工作实体组成，具体取决于所需的保护方案。在1:1或1+1 P2P保护中，工作实体和恢复实体的路径必须在各个方面具有物理多样性（即，不共享任何资源或物理位置），以确保保护。
o As defined in Section 4.8, the SPME must be supported in order to implement data-plane-based LSP segment recovery, since related control messages (e.g., for OAM, Protection Path Coordination, etc.) can be initiated and terminated at the edges of a path where push and pop operations are enabled. The SPME is an end-to-end LSP that in this context corresponds to the recovery entities (working and protection) and makes use of the MPLS construct of hierarchical nested LSP, as defined in [RFC3031]. OAM messages and messages to coordinate protection state can be initiated at the edge of the SPME and sent over G-ACH to the peer edge of the SPME. It is necessary to configure the related SPMEs and map between the LSP segments being protected and the SPME. Mapping can be 1:1 or 1:N to allow scalable protection of a set of LSP segments traversing the part of the network in which a protection domain is defined.
o 如第4.8节所定义，必须支持SPME以实现基于数据平面的LSP段恢复，因为相关控制消息（例如，对于OAM、保护路径协调等）可以在启用推送和pop操作的路径边缘启动和终止。SPME是一种端到端LSP，在此上下文中，它对应于恢复实体（工作和保护），并使用[RFC3031]中定义的分层嵌套LSP的MPLS结构。OAM消息和协调保护状态的消息可以在SPME的边缘启动，并通过G-ACH发送到SPME的对等边缘。有必要配置相关的SPME，并在受保护的LSP段和SPME之间进行映射。映射可以是1:1或1:N，以允许对穿过定义了保护域的网络部分的一组LSP段进行可伸缩保护。
Note that each of these LSPs can be initiated or terminated at different end points in the network, but that they all traverse the protection domain and share similar constraints (such as requirements for QoS, terms of protection, etc.).
请注意，这些LSP中的每一个都可以在网络中的不同端点处启动或终止，但它们都会穿越保护域并共享类似的约束（例如QoS要求、保护条款等）。
o The protection type that should be defined (e.g., unidirectional 1:1, bidirectional 1+1, etc.)
o 应定义的保护类型（如单向1:1、双向1+1等）
o Revertive/non-revertive behavior should be configured.
o 应配置还原/非还原行为。
o Timers (such as WTR, hold-off timer, etc.) should be set.
o 应设置定时器（如WTR、暂停定时器等）。
The following external, manual commands may be provided for manual control of the protection-switching operation. These commands apply to a protection group; they are listed in descending order of priority:
可提供以下外部手动命令，用于手动控制保护开关操作。这些命令适用于保护组；它们按优先级降序排列：
o Blocked protection action - a manual command to prevent data traffic from switching to the recovery entity. This command actually disables the protection group.
o 阻止的保护操作—一种手动命令，用于防止数据流量切换到恢复实体。此命令实际上禁用保护组。
o Force protection action - a manual command that forces a switch of normal data traffic to the recovery entity.
o 强制保护操作—强制将正常数据流量切换到恢复实体的手动命令。
o Manual protection action - a manual command that forces a switch of data traffic to the recovery entity only when there is no defect in the recovery entity.
o 手动保护操作—仅当恢复实体中没有缺陷时，才强制将数据流量切换到恢复实体的手动命令。
o Clear switching command - the operator may request that a previous administrative switch command (manual or force switch) be cleared.
o 清除开关命令-操作员可以请求清除以前的管理开关命令（手动或强制开关）。
Fault detection is a fundamental part of recovery and survivability. In all schemes, with the exception of some types of 1+1 protection, the actions required for the recovery of traffic delivery depend on the discovery of some kind of fault. In 1+1 protection, the selector (at the receiving end) may simply be configured to choose the better signal; thus, it does not detect a fault or degradation of itself, but simply identifies the path that is better for data delivery.
故障检测是恢复和生存能力的基本组成部分。在所有方案中，除某些类型的1+1保护外，恢复流量传输所需的操作取决于某种故障的发现。在1+1保护中，选择器（在接收端）可以简单地配置为选择更好的信号；因此，它不会检测自身的故障或降级，而只是确定更适合数据传输的路径。
Faults may be detected in a number of ways depending on the traffic pattern and the underlying hardware. End-to-end faults may be reported by the application or by knowledge of the application's data pattern, but this is an unusual approach. There are two more common mechanisms for detecting faults in the MPLS-TP layer:
根据流量模式和底层硬件，可以通过多种方式检测故障。端到端故障可能由应用程序报告，也可能由对应用程序数据模式的了解报告，但这是一种不寻常的方法。MPLS-TP层中有两种更常见的故障检测机制：
o Faults reported by the lower layers.
o 下层报告的断层。
o Faults detected by protocols within the MPLS-TP layer.
o MPLS-TP层内协议检测到的故障。
In an IP/MPLS network, the second mechanism may utilize control-plane protocols (such as the routing protocols) to detect a failure of adjacency between neighboring nodes. In an MPLS-TP network, it is possible that no control plane will be present. Even if a control plane is present, it will be a GMPLS control plane [RFC3945], which logically separates control channels from data channels; thus, no conclusion about the health of a data channel can be drawn from the
在IP/MPLS网络中，第二机制可以利用控制平面协议（例如路由协议）来检测相邻节点之间的邻接故障。在MPLS-TP网络中，可能不存在控制平面。即使存在一个控制平面，它也将是一个GMPLS控制平面[RFC3945]，在逻辑上将控制通道与数据通道分开；因此，数据通道的健康状况无法从
failure of an associated control channel. MPLS-TP-layer faults are, therefore, only detected through the use of OAM protocols, as described in Section 6.4.1.
相关控制通道故障。因此，MPLS TP层故障仅通过使用OAM协议检测，如第6.4.1节所述。
Faults may, however, be reported by a lower layer. These generally show up as interface failures or data-link failures (sometimes known as connectivity failures) within the MPLS-TP network, for example, an underlying optical link may detect loss of light and report a failure of the MPLS-TP link that uses it. Alternatively, an interface card failure may be reported to the MPLS-TP layer.
但是，较低层可能会报告断层。这些故障通常表现为MPLS-TP网络内的接口故障或数据链路故障（有时称为连接故障），例如，底层光链路可能检测到光丢失并报告使用它的MPLS-TP链路的故障。或者，可以向MPLS-TP层报告接口卡故障。
Faults reported by lower layers are only visible in specific nodes within the MPLS-TP network (i.e., at the adjacent end points of the MPLS-TP link). This would only allow recovery to be performed locally, so, to enable recovery to be performed by nodes that are not immediately local to the fault, the fault must be reported (Sections 6.4.3 and 6.5.4).
较低层报告的故障仅在MPLS-TP网络内的特定节点中可见（即，在MPLS-TP链路的相邻端点处）。这将只允许在本地执行恢复，因此，为了使故障不在本地的节点能够执行恢复，必须报告故障（第6.4.3节和第6.5.4节）。
If an MPLS-TP node detects that there is a fault in an LSP (that is, not a network fault reported from a lower layer, but a fault detected by examining the LSP), it can immediately perform a recovery action. However, unless the location of the fault is known, the only practical options are:
如果MPLS-TP节点检测到LSP中存在故障（即，不是从较低层报告的网络故障，而是通过检查LSP检测到的故障），它可以立即执行恢复操作。但是，除非已知故障位置，否则唯一可行的选择是：
o Perform end-to-end recovery.
o 执行端到端恢复。
o Perform some other recovery as a speculative act.
o 作为推测行为执行其他一些恢复。
Since the speculative acts are not guaranteed to achieve the desired results and could consume resources unnecessarily, and since end-to-end recovery can require a lot of network resources, it is important to be able to localize the fault.
由于投机行为不能保证达到预期的结果，并且可能会不必要地消耗资源，而且端到端恢复可能需要大量网络资源，因此能够定位故障非常重要。
Fault localization may be achieved by dividing the network into protection domains. End-to-end protection is thereby operated on LSP segments, depending on the domain in which the fault is discovered. This necessitates monitoring of the LSP at the domain edges.
可以通过将网络划分为保护域来实现故障定位。因此，端到端保护在LSP段上运行，具体取决于发现故障的域。这就需要在域边缘监控LSP。
Alternatively, a proactive mechanism of fault localization through OAM (Section 6.4.3) or through the control plane (Section 6.5.3) is required.
或者，需要通过OAM（第6.4.3节）或通过控制平面（第6.5.3节）进行故障定位的主动机制。
Fault localization is particularly important for restoration because a new path must be selected that avoids the fault. It may not be practical or desirable to select a path that avoids the entire failed
故障定位对于恢复尤其重要，因为必须选择一条避免故障的新路径。选择一条能够避免整个故障的路径可能是不实际的，也不可取的
working path, and it is therefore necessary to isolate the fault's location.
工作路径，因此有必要隔离故障位置。
MPLS-TP provides a comprehensive set of OAM tools for fault management and performance monitoring at different nested levels (end-to-end, a portion of a path (LSP or PW), and at the link level) [RFC6371].
MPLS-TP提供了一套全面的OAM工具，用于在不同嵌套级别（端到端、路径的一部分（LSP或PW）和链路级别）进行故障管理和性能监控[RFC6371]。
These tools support proactive and on-demand fault management (for fault detection and fault localization) as well as performance monitoring (to measure the quality of the signals and detect degradation).
这些工具支持主动和按需故障管理（用于故障检测和故障定位）以及性能监控（用于测量信号质量和检测降级）。
To support fast recovery, it is useful to use some of the proactive tools to detect fault conditions (e.g., link/node failure or degradation) and to trigger the recovery action.
为了支持快速恢复，可以使用一些主动式工具来检测故障状况（例如，链路/节点故障或降级）并触发恢复操作。
The MPLS-TP OAM messages run in-band with the traffic and support unidirectional and bidirectional P2P paths as well as P2MP paths.
MPLS-TP OAM消息与流量一起在频带内运行，支持单向和双向P2P路径以及P2MP路径。
As described in [RFC6371], MPLS-TP OAM operates in the context of a Maintenance Entity that borders on the OAM responsibilities and represents the portion of a path between two points that is monitored and maintained, and along which OAM messages are exchanged. [RFC6371] refers also to a Maintenance Entity Group (MEG), which is a collection of one or more Maintenance Entities (MEs) that belong to the same transport path (e.g., P2MP transport path) and which are maintained and monitored as a group.
如[RFC6371]中所述，MPLS-TP OAM在维护实体的上下文中运行，该维护实体与OAM职责相邻，表示两个点之间被监视和维护的路径部分，OAM消息沿着该路径进行交换。[RFC6371]还指维护实体组（MEG），它是属于同一传输路径（如P2MP传输路径）的一个或多个维护实体（ME）的集合，并作为一个组进行维护和监控。
An ME includes two MEPs (Maintenance Entity Group End Points) that reside at the boundaries of an ME, and a set of zero or more MIPs (Maintenance Entity Group Intermediate Points) that reside within the Maintenance Entity along the path. A MEP is capable of initiating and terminating OAM messages, and as such can only be located at the edges of a path where push and pop operations are supported. In order to define an ME over a portion of path, it is necessary to support SPMEs.
ME包括位于ME边界处的两个MEP（维护实体组端点）和沿路径位于维护实体内的一组零个或多个MIP（维护实体组中间点）。MEP能够启动和终止OAM消息，因此只能位于支持推送和pop操作的路径边缘。为了在路径的一部分上定义ME，有必要支持SPME。
The SPME is an end-to-end LSP that in this context corresponds to the ME; it uses the MPLS construct of hierarchical nested LSPs, which is defined in [RFC3031]. OAM messages can be initiated at the edge of the SPME and sent over G-ACH to the peer edge of the SPME.
SPME是一个端到端LSP，在此上下文中对应于ME；它使用分层嵌套LSP的MPLS构造，定义见[RFC3031]。OAM消息可以在SPME的边缘启动，并通过G-ACH发送到SPME的对等边缘。
The related SPMEs must be configured, and mapping must be performed between the LSP segments being monitored and the SPME. Mapping can be 1:1 or 1:N to allow scalable operation. Note that each of these
必须配置相关的SPME，并且必须在被监控的LSP段和SPME之间执行映射。映射可以是1:1或1:N，以允许可伸缩的操作。请注意，这些
LSPs can be initiated or terminated at different end points in the network and can share similar constraints (such as requirements for QoS, terms of protection, etc.).
LSP可以在网络中的不同端点处启动或终止，并且可以共享类似的约束（例如QoS要求、保护条款等）。
With regard to recovery, where MPLS-TP OAM is supported, an OAM Maintenance Entity Group is defined for each of the working and protection entities.
关于恢复，在支持MPLS-TP OAM的情况下，为每个工作和保护实体定义OAM维护实体组。
MPLS-TP OAM tools may be used proactively to detect the following fault conditions between MEPs:
MPLS-TP OAM工具可主动用于检测MEP之间的以下故障：
o Loss of continuity and misconnectivity - the proactive Continuity Check (CC) function is used to detect loss of continuity between two MEPs in an MEG. The proactive Connectivity Verification (CV) allows a sink MEP to detect a misconnectivity defect (e.g., mismerge or misconnection) with its peer source MEP when the received packet carries an incorrect ME identifier. For protection switching, it is common to run a CC-V (Continuity Check and Connectivity Verification) message every 3.33 ms. In the absence of three consecutive CC-V messages, loss of continuity is declared and is notified locally to the edge of the recovery domain in order to trigger a recovery action. In some cases, when a slower recovery time is acceptable, it is also possible to lengthen the transmission rate.
o 连续性丧失和误连接-主动连续性检查（CC）功能用于检测MEG中两个MEP之间的连续性丧失。当接收到的数据包带有错误的ME标识符时，主动连接验证（CV）允许接收端MEP检测其对等源MEP的错误连接缺陷（例如，错误合并或错误连接）。对于保护切换，通常每3.33毫秒运行一次CC-V（连续性检查和连接验证）消息。如果没有三条连续的CC-V消息，则会宣布连续性丧失，并在本地通知恢复域的边缘，以触发恢复操作。在某些情况下，当可以接受较慢的恢复时间时，也可以延长传输速率。
o Signal degradation - notification from OAM performance monitoring indicating degradation in the working entity may also be used as a trigger for protection switching. In the event of degradation, switching to the recovery entity is necessary only if the recovery entity can guarantee better conditions. Degradation can be measured by proactively activating MPLS-TP OAM packet loss measurement or delay measurement.
o 信号降级-来自OAM性能监控的通知，指示工作实体中的降级也可用作保护切换的触发器。在降级的情况下，只有当恢复实体能够保证更好的条件时，才需要切换到恢复实体。可以通过主动激活MPLS-TP OAM丢包测量或延迟测量来测量降级。
o A MEP can receive an indication from its sink MEP of a Remote Defect Indication and locally notify the end point of the recovery domain regarding the fault condition, in order to trigger the recovery action.
o MEP可以从其接收器MEP接收远程缺陷指示，并本地通知恢复域的端点有关故障状况，以便触发恢复操作。
The management plane may be used to initiate the testing of links, LSP segments, or entire LSPs.
管理平面可用于启动链路、LSP段或整个LSP的测试。
MPLS-TP provides OAM tools that may be manually invoked on-demand for a limited period, in order to troubleshoot links, LSP segments, or entire LSPs (e.g., diagnostics, connectivity verification, packet
MPLS-TP提供了OAM工具，可以在有限的时间内按需手动调用这些工具，以便对链路、LSP段或整个LSP（例如，诊断、连接验证、数据包管理）进行故障排除
loss measurements, etc.). On-demand monitoring covers a combination of "in-service" and "out-of-service" monitoring functions. Out-of-service testing is supported by the OAM on-demand lock operation. The lock operation temporarily disables the transport entity (LSP, LSP segment, or link), preventing the transmission of all types of traffic, with the exceptions of test traffic and OAM (dedicated to the locked entity).
损耗测量等）。按需监控包括“在用”和“停用”监控功能的组合。OAM按需锁定操作支持停止服务测试。锁定操作暂时禁用传输实体（LSP、LSP段或链路），防止传输所有类型的流量，测试流量和OAM（专用于锁定实体）除外。
[RFC6371] describes the operations of the OAM functions that may be initiated on-demand and provides some considerations.
[RFC6371]描述了可按需启动的OAM功能的操作，并提供了一些注意事项。
MPLS-TP also supports in-service and out-of-service testing of the recovery (protection and restoration) mechanism, the integrity of the protection/recovery transport paths, and the coordination protocol between the end points of the recovery domain. The testing operation emulates a protection-switching request but does not perform the actual switching action.
MPLS-TP还支持恢复（保护和恢复）机制的服务内和服务外测试、保护/恢复传输路径的完整性以及恢复域端点之间的协调协议。测试操作模拟保护切换请求，但不执行实际切换操作。
MPLS-TP provides OAM tools to locate a fault and determine its precise location. Fault detection often only takes place at key points in the network (such as at LSP end points or at MEPs). This means that a fault may be located anywhere within a segment of the relevant LSP. Finer information granularity is needed to implement optimal recovery actions or to diagnose the fault. On-demand tools like trace-route, loopback, and on-demand CC-V can be used to localize a fault.
MPLS-TP提供OAM工具来定位故障并确定其精确位置。故障检测通常只发生在网络中的关键点（如LSP端点或MEP）。这意味着故障可能位于相关LSP段内的任何位置。需要更精细的信息粒度来实施最佳恢复操作或诊断故障。按需工具（如跟踪路由、环回和按需CC-V）可用于定位故障。
The information may be notified locally to the end point of the recovery domain to allow implementation of optimal recovery action. This may be useful for the re-calculation of a recovery path.
可以将信息本地通知到恢复域的端点，以允许执行最佳恢复操作。这可能有助于重新计算恢复路径。
The information should also be reported to network management for diagnostic purposes.
还应将信息报告给网络管理部门，以便进行诊断。
The end points of a recovery domain should be able to detect fault conditions in the recovery domain and to notify the management plane.
恢复域的端点应能够检测恢复域中的故障状况并通知管理平面。
In addition, a node within a recovery domain that detects a fault condition should also be able to report this to network management. Network management should be capable of correlating the fault reports and identifying the source of the fault.
此外，恢复域中检测到故障状况的节点还应能够向网络管理部门报告此情况。网络管理应能够关联故障报告并识别故障源。
MPLS-TP OAM tools support a function where an intermediate node along a path is able to send an alarm report message to the MEP, indicating
MPLS-TP OAM工具支持这样一种功能，即路径上的中间节点能够向MEP发送报警报告消息，指示
the presence of a fault condition in the server layer that connects it to its adjacent node. This capability allows a MEP to suppress alarms that may be generated as a result of a failure condition in the server layer.
连接到相邻节点的服务器层中存在故障。此功能允许MEP抑制可能因服务器层中的故障条件而生成的警报。
As described above, in some cases (such as in bidirectional protection switching, etc.) it is necessary to coordinate the protection states between the edges of the recovery domain. [MPLS-TP-LP] defines procedures, protocol messages, and elements for this purpose.
如上所述，在某些情况下（例如在双向保护切换等中），有必要在恢复域的边缘之间协调保护状态。[MPLS-TP-LP]定义了用于此目的的过程、协议消息和元素。
The protocol is also used to signal administrative requests (e.g., manual switch, etc.), but only when these are provisioned at the edge of the recovery domain.
该协议还用于向管理请求（例如，手动切换等）发送信号，但仅当这些请求在恢复域的边缘提供时。
The protocol also enables mismatches to be detected between the configurations at the ends of the protection domain (such as timers, revertive/non-revertive behavior); these mismatches can subsequently be reported to the management plane.
该协议还允许检测保护域末端的配置之间的不匹配（例如定时器、回复/非回复行为）；这些不匹配随后可以报告给管理层。
In the absence of suitable coordination (owing to failures in the delivery or processing of the coordination protocol messages), protection switching will fail. This means that the operation of the protocol that coordinates the protection state is a fundamental part of protection switching.
在缺乏适当协调的情况下（由于协调协议消息的传递或处理失败），保护切换将失败。这意味着协调保护状态的协议操作是保护切换的基本部分。
The GMPLS control plane has been proposed as the control plane for MPLS-TP [RFC5317]. Since GMPLS was designed for use in transport networks, and since it has been implemented and deployed in many networks, it is not surprising that it contains many features that support a high degree of survivability.
GMPLS控制平面被提议作为MPLS-TP的控制平面[RFC5317]。由于GMPLS设计用于传输网络，并且已经在许多网络中实施和部署，因此它包含许多支持高度生存性的功能也就不足为奇了。
The signaling elements of the GMPLS control plane utilize extensions to the Resource Reservation Protocol (RSVP) (as described in a series of documents commencing with [RFC3471] and [RFC3473]), although it is based on [RFC3209] and [RFC2205]. The architecture for GMPLS is provided in [RFC3945], while [RFC4426] gives a functional description of the protocol extensions needed to support GMPLS-based recovery (i.e., protection and restoration).
GMPLS控制平面的信令元件利用对资源预留协议（RSVP）的扩展（如从[RFC3471]和[RFC3473]开始的一系列文件中所述），尽管它基于[RFC3209]和[RFC2205]。[RFC3945]提供了GMPLS的体系结构，而[RFC4426]给出了支持基于GMPLS的恢复（即保护和恢复）所需的协议扩展的功能描述。
A further control-plane protocol called the Link Management Protocol (LMP) [RFC4204] is part of the GMPLS protocol family and can be used to coordinate fault localization and reporting.
另一种称为链路管理协议（LMP）[RFC4204]的控制平面协议是GMPLS协议系列的一部分，可用于协调故障定位和报告。
Clearly, the control-plane techniques described here only apply where an MPLS-TP control plane is deployed and operated. All mandatory MPLS-TP survivability features must be enabled, even in the absence of the control plane. However, when present, the control plane may be used to provide alternative mechanisms that may be desirable, since they offer simple automation or a richer feature set.
显然，这里描述的控制平面技术仅适用于部署和操作MPLS-TP控制平面的情况。即使在没有控制平面的情况下，也必须启用所有强制性MPLS-TP生存性功能。然而，当存在时，控制平面可用于提供可能需要的替代机制，因为它们提供简单的自动化或更丰富的特征集。
The control plane is unable to detect data-plane faults. However, it does provide mechanisms that detect control-plane faults, and these can be used to recognize data-plane faults when it is evident that the control and data planes are fate-sharing. Although [RFC5654] specifies that MPLS-TP must support an out-of-band control channel, it does not insist that it be used exclusively. This means that there may be deployments where an in-band (or at least an in-fiber) control channel is used. In this scenario, failure of the control channel can be used to infer that there is a failure of the data channel, or, at least, it can be used to trigger an investigation of the health of the data channel.
控制平面无法检测数据平面故障。然而，它确实提供了检测控制平面故障的机制，当控制平面和数据平面明显共享命运时，这些机制可用于识别数据平面故障。尽管[RFC5654]规定MPLS-TP必须支持带外控制信道，但并不坚持只使用该信道。这意味着可能存在使用带内（或至少光纤内）控制信道的部署。在这种情况下，控制信道的故障可用于推断数据信道存在故障，或者至少可用于触发对数据信道的健康状况的调查。
Both RSVP and LMP provide a control channel "keep-alive" mechanism (called the Hello message in both cases). Failure to receive a message in the configured/negotiated time period indicates a control-plane failure. GMPLS routing protocols ([RFC4203] and [RFC5307]) also include keep-alive mechanisms designed to detect routing adjacency failures. Although these keep-alive mechanisms tend to operate at a relatively low frequency (on the order of seconds), it is still possible that the first indication of a control-plane fault will be received through the routing protocol.
RSVP和LMP都提供了一种控制通道“保持活动”机制（在这两种情况下都称为Hello消息）。未能在配置/协商的时间段内接收消息表示控制平面故障。GMPLS路由协议（[RFC4203]和[RFC5307]）还包括设计用于检测路由邻接故障的保持活动机制。尽管这些保持活动的机制往往以相对较低的频率（以秒为单位）运行，但仍有可能通过路由协议接收到控制平面故障的第一个指示。
Note, however, that care must be taken to ascertain that a specific failure is not caused by a problem in the control-plane software or in a processor component at the far end of a link.
但是，请注意，必须小心确定特定故障不是由控制平面软件或链路远端的处理器组件中的问题引起的。
Because of the various issues involved, it is not recommended that the control plane be used as the primary mechanism for fault detection in an MPLS-TP network.
由于涉及各种问题，不建议将控制平面用作MPLS-TP网络中故障检测的主要机制。
The control plane may be used to initiate and coordinate the testing of links, LSP segments, or entire LSPs. This is important in some technologies where it is necessary to halt data transmission while testing, but it may also be useful where testing needs to be specifically enabled or configured.
控制平面可用于启动和协调链路、LSP段或整个LSP的测试。这在某些技术中很重要，因为在测试时需要停止数据传输，但在需要专门启用或配置测试的情况下，这也很有用。
LMP provides a control-plane mechanism to test the continuity and connectivity (and naming) of individual links. A single management operation is required to initiate the test at one end of the link, while the LMP handles the coordination with the other end of the link. The test mechanism for an MPLS packet link relies on the LMP Test message inserted into the data stream at one end of the link and extracted at the other end of the link. This mechanism need not disrupt data flowing over the link.
LMP提供了一种控制平面机制来测试各个链路的连续性和连通性（以及命名）。当LMP处理与链路另一端的协调时，需要单个管理操作来启动链路一端的测试。MPLS分组链路的测试机制依赖于在链路一端插入数据流并在链路另一端提取的LMP测试消息。这种机制不需要中断链路上的数据流。
Note that a link in the LMP may, in fact, be an LSP tunnel used to form a link in the MPLS-TP network.
注意，LMP中的链路实际上可以是用于在MPLS-TP网络中形成链路的LSP隧道。
GMPLS signaling (RSVP) offers two mechanisms that may also assist with fault testing. The first mechanism [RFC3473] defines the Admin_Status object that allows an LSP to be set into "testing mode". The interpretation of this mode is implementation-specific and could be documented more precisely for MPLS-TP. The mode sets the whole LSP into a state where it can be tested; this need not be disruptive to data traffic.
GMPLS信令（RSVP）提供了两种机制，也可以帮助进行故障测试。第一种机制[RFC3473]定义允许LSP设置为“测试模式”的管理状态对象。这种模式的解释是特定于实现的，可以更精确地记录在MPLS-TP中。该模式将整个LSP设置为可测试的状态；这不需要中断数据通信。
The second mechanism provided by GMPLS to support testing is described in [GMPLS-OAM]. This protocol extension supports the configuration (including enabling and disabling) of OAM mechanisms for a specific LSP.
GMPLS提供的支持测试的第二种机制在[GMPLS-OAM]中描述。此协议扩展支持特定LSP的OAM机制配置（包括启用和禁用）。
Fault localization is the process whereby the exact location of a fault is determined. Fault detection often only takes place at key points in the network (such as at LSP end points or at MEPs). This means that a fault may be located anywhere within a segment of the relevant LSP.
故障定位是确定故障准确位置的过程。故障检测通常只发生在网络中的关键点（如LSP端点或MEP）。这意味着故障可能位于相关LSP段内的任何位置。
If segment or end-to-end protection is in use, this level of information is often sufficient to repair the LSP. However, if finer information granularity is required (either to implement optimal recovery actions or to diagnose a fault), it is necessary to localize the specific fault.
如果正在使用段或端到端保护，此级别的信息通常足以修复LSP。但是，如果需要更精细的信息粒度（实施最佳恢复操作或诊断故障），则有必要定位特定故障。
LMP provides a cascaded test-and-propagate mechanism that is designed specifically for this purpose.
LMP提供了专门为此目的设计的级联测试和传播机制。
GMPLS signaling uses the Notify message to report fault status [RFC3473]. The Notify message can apply to a single LSP or can carry fault information for a set of LSPs, in order to improve the scalability of fault notification.
GMPLS信令使用通知消息报告故障状态[RFC3473]。Notify消息可以应用于单个LSP，也可以携带一组LSP的故障信息，以提高故障通知的可伸缩性。
Since the Notify message is targeted at a specific node, it can be delivered rapidly without requiring hop-by-hop processing. It can be targeted at LSP end points or at segment end points (such as MEPs). The target points for Notify messages can be manually configured within the network, or they may be signaled when the LSP is set up.
由于Notify消息是针对特定节点的，因此无需逐跳处理即可快速传递。它可以针对LSP端点或段端点（如MEP）。Notify消息的目标点可以在网络中手动配置，也可以在设置LSP时发出信号。
This enables the process to be made consistent with segment protection as well as with the concept of Maintenance Entities.
这使得该过程与段保护以及维护实体的概念保持一致。
GMPLS signaling also provides a slower, hop-by-hop mechanism for reporting individual LSP faults on a hop-by-hop basis using PathErr and ResvErr messages.
GMPLS信令还提供了一种较慢的逐跳机制，用于使用PathErr和ResvErr消息逐跳报告单个LSP故障。
[RFC4783] provides a mechanism to coordinate alarms and other event or fault information through GMPLS signaling. This mechanism is useful for understanding the status of the resources used by an LSP and for providing information as to why an LSP is not functioning; however, it is not intended to replace other fault-reporting mechanisms.
[RFC4783]提供通过GMPLS信号协调报警和其他事件或故障信息的机制。该机制有助于了解LSP使用的资源的状态，并提供LSP无法运行的原因信息；但是，它并不打算取代其他故障报告机制。
GMPLS routing protocols [RFC4203] and [RFC5307] are used to advertise link availability and capabilities within a GMPLS-enabled network. Thus, the routing protocols can also provide indirect information about network faults; that is, the protocol may stop advertising or may withdraw the advertisement for a failed link, or it may advertise that the link is about to be shut down gracefully [RFC5817]. This mechanisms is, however, not normally considered to be fast enough for use as a trigger for protection switching.
GMPLS路由协议[RFC4203]和[RFC5307]用于在启用GMPLS的网络中公布链路可用性和功能。因此，路由协议还可以提供有关网络故障的间接信息；也就是说，协议可以停止播发，或者可以撤销故障链路的播发，或者可以播发链路即将正常关闭[RFC5817]。然而，这种机制通常被认为不够快，不能用作保护切换的触发器。
Fault coordination is an important feature for certain protection mechanisms (such as bidirectional 1:1 protection). The use of the GMPLS Notify message for this purpose is described in [RFC4426]; however, specific message field values have not yet been defined for this operation.
故障协调是某些保护机制（如双向1:1保护）的一个重要特征。[RFC4426]中描述了为此目的使用GMPLS Notify消息；但是，尚未为此操作定义特定的消息字段值。
Further work is needed in GMPLS for control and configuration of reversion behavior for end-to-end and segment protection, and the coordination of timer values.
在GMPLS中，需要进一步的工作来控制和配置端到端和段保护的反转行为，以及协调计时器值。
The management plane may be used to set up protection and recovery LSPs, but, when present, the control plane may be used.
管理平面可用于设置保护和恢复LSP，但当存在时，可使用控制平面。
Several protocol extensions exist that simplify this process:
存在几种简化此过程的协议扩展：
o [RFC4872] provides features that support end-to-end protection switching.
o [RFC4872]提供支持端到端保护切换的功能。
o [RFC4873] describes the establishment of a single, segment-protected LSP. Note that end-to-end protection is a special case of segment protection, and [RFC4872] can also be used to provide end-to-end protection.
o [RFC4873]描述了单个段保护LSP的建立。注意，端到端保护是段保护的一种特殊情况，[RFC4872]也可用于提供端到端保护。
o [RFC4874] allows an LSP to be signaled with a request that its path exclude specified resources such as links, nodes, and shared risk link groups (SRLGs). This allows a disjoint protection path to be requested or a recovery path to be set up to avoid failed resources.
o [RFC4874]允许向LSP发出信号，请求其路径排除指定资源，如链路、节点和共享风险链路组（SRLGs）。这允许请求不相交的保护路径或设置恢复路径，以避免出现资源故障。
o Lastly, it should be noted that [RFC5298] provides an overview of the GMPLS techniques available to achieve protection in multi-domain environments.
o 最后，应注意的是[RFC5298]概述了可用于在多域环境中实现保护的GMPLS技术。
Pseudowires provide end-to-end connectivity over the MPLS-TP network and may comprise a single pseudowire segment, or multiple segments "stitched" together to provide end-to-end connectivity.
伪线通过MPLS-TP网络提供端到端连接，并可包括单个伪线段，或多个“缝合”在一起以提供端到端连接的段。
The pseudowire may, itself, require protection, in order to meet the service-level guarantees of its SLA. This protection could be provided by the MPLS-TP LSPs that support the pseudowire, or could be a feature of the pseudowire layer itself.
伪线本身可能需要保护，以满足其SLA的服务级别保证。这种保护可以由支持伪线的MPLS-TP LSP提供，也可以是伪线层本身的特性。
As indicated above, the functional architecture described in this document applies to both LSPs and pseudowires. However, the recovery mechanisms for pseudowires are for further study and will be defined in a separate document by the PWE3 working group.
如上所述，本文档中描述的功能体系结构适用于LSP和伪线。然而，伪导线的恢复机制有待进一步研究，将由PWE3工作组在单独的文件中定义。
MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. Such protection can take any of the forms described in this document. The choice of recovery scheme will depend on the required speed of recovery and the traffic loss that is acceptable for the SLA that the PW is providing.
MPLS-TP PW在MPLS-TP LSP内通过网络传输。因此，为PW提供保护的一个明显方法是保护携带它的LSP。此类保护可采用本文件中所述的任何形式。恢复方案的选择将取决于所需的恢复速度和PW提供的SLA可接受的流量损失。
If the PW is a Multi-Segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an
如果PW是多段PW，则LSP恢复只能保护单个段中的PW。这意味着单个LSP恢复操作无法防止PW开关点（an）故障
S-PE), nor can it protect more than one segment at a time, since the LSP tunnel is terminated at each S-PE. In this respect, LSP protection of a PW is very similar to link-level protection offered to the MPLS-TP LSP layer by an underlying network layer (see Section 4.9).
由于LSP隧道在每个S-PE处终止，因此它也不能一次保护多个段。在这方面，PW的LSP保护非常类似于由底层网络层提供给MPLS-TP LSP层的链路级保护（参见第4.9节）。
Recovery in the PW layer can be provided by simply running separate PWs end-to-end. Other recovery mechanisms in the PW layer, such as segment or concatenated segment recovery, or service-level recovery involving survivability of T-PE or AC faults will be described in a separate document.
PW层中的恢复可以通过简单地端到端运行单独的PWs来实现。PW层中的其他恢复机制，如段或连接段恢复，或涉及T-PE或AC故障生存能力的服务级别恢复，将在单独的文档中描述。
As with any recovery mechanism, it is important to coordinate between layers. This coordination is necessary to ensure that actions associated with recovery mechanisms are only performed in one layer at a time (that is, the recovery of an underlying LSP needs to be coordinated with the recovery of the PW itself). It also makes sure that the working and protection PWs do not both use the same MPLS resources within the network (for example, by running over the same LSP tunnel; see also Section 4.9).
与任何恢复机制一样，层之间的协调非常重要。这种协调是必要的，以确保与恢复机制相关的操作一次只能在一个层中执行（即，底层LSP的恢复需要与PW本身的恢复进行协调）。它还确保工作PW和保护PW在网络中不同时使用相同的MPLS资源（例如，通过运行相同的LSP隧道；另请参见第4.9节）。
Manageability of MPLS-TP networks and their functions is discussed in [RFC5950]. OAM features are discussed in [RFC6371].
[RFC5950]中讨论了MPLS-TP网络的可管理性及其功能。[RFC6371]中讨论了OAM特性。
Survivability has some key interactions with management, as described in this document. In particular:
如本文件所述，生存能力与管理层有一些关键的互动。特别地：
o Recovery domains may be configured in a way that prevents one-to-one correspondence between the MPLS-TP network and the recovery domains.
o 可以以防止MPLS-TP网络和恢复域之间的一对一对应的方式来配置恢复域。
o Survivability policies may be configured per network, per recovery domain, or per LSP.
o 可生存性策略可以根据网络、恢复域或LSP进行配置。
o Configuration of OAM may involve the selection of MEPs; enabling OAM on network segments, spans, and links; and the operation of OAM on LSPs, concatenated LSP segments, and LSP segments.
o OAM的配置可能涉及MEP的选择；在网段、跨距和链路上启用OAM；以及在LSP、连接的LSP段和LSP段上的OAM操作。
o Manual commands may be used to control recovery functions, including forcing recovery and locking recovery actions.
o 手动命令可用于控制恢复功能，包括强制恢复和锁定恢复操作。
See also the considerations regarding security for management and OAM in Section 9 of this document.
另请参见本文件第9节中有关管理和OAM安全的注意事项。
This framework does not introduce any new security considerations; general issues relating to MPLS security can be found in [RFC5920].
该框架没有引入任何新的安全考虑；有关MPLS安全性的一般问题，请参见[RFC5920]。
However, several points about MPLS-TP survivability should be noted here.
然而，这里应该注意关于MPLS-TP生存性的几点。
o If an attacker is able to force a protection switch-over, this may result in a small perturbation to user traffic and could result in extra traffic being preempted or displaced from the protection resources. In the case of 1:n protection or shared mesh protection, this may result in other traffic becoming unprotected. Therefore, it is important that OAM protocols for detecting or notifying faults use adequate security to prevent them from being used (through the insertion of bogus messages or through the capture of legitimate messages) to falsely trigger a recovery event.
o 如果攻击者能够强制进行保护切换，这可能会对用户流量造成轻微干扰，并可能导致额外流量被抢占或从保护资源中转移。在1:n保护或共享网格保护的情况下，这可能会导致其他通信变得不受保护。因此，用于检测或通知故障的OAM协议必须使用足够的安全性来防止（通过插入虚假消息或捕获合法消息）被用于错误触发恢复事件。
o If manual commands are modified, captured, or simulated (including replay), it might be possible for an attacker to perform forced recovery actions or to impose lock-out. These actions could impact the capability to provide the recovery function and could also affect the normal operation of the network for other traffic. Therefore, management protocols used to perform manual commands must allow the operator to use appropriate security mechanisms. This includes verification that the user who performs the commands has appropriate authorization.
o 如果修改、捕获或模拟手动命令（包括回放），攻击者可能会执行强制恢复操作或实施锁定。这些操作可能会影响提供恢复功能的能力，也可能会影响其他流量的网络正常运行。因此，用于执行手动命令的管理协议必须允许操作员使用适当的安全机制。这包括验证执行命令的用户是否具有适当的授权。
o If the control plane is used to configure or operate recovery mechanisms, the control-plane protocols must also be capable of providing adequate security.
o 如果控制平面用于配置或操作恢复机制，则控制平面协议还必须能够提供足够的安全性。
Thanks to the following people for useful comments and discussions: Italo Busi, David McWalter, Lou Berger, Yaacov Weingarten, Stewart Bryant, Dan Frost, Lievren Levrau, Xuehui Dai, Liu Guoman, Xiao Min, Daniele Ceccarelli, Scott Bradner, Francesco Fondelli, Curtis Villamizar, Maarten Vissers, and Greg Mirsky.
感谢以下人士提供有用的评论和讨论：Italo Busi、David McWalter、Lou Berger、Yaacov Weingarten、Stewart Bryant、Dan Frost、Lievren Levrau、戴学辉、刘国满、肖敏、丹尼尔·塞卡雷利、斯科特·布拉德纳、弗朗西斯科·丰德利、柯蒂斯·维拉米扎、马丁·维瑟斯和格雷格·米尔斯基。
The Editors would like to thank the participants in ITU-T Study Group 15 for their detailed review.
编辑们要感谢ITU-T第15研究组的参与者进行了详细的审查。
Some figures and text on shared mesh protection were borrowed from [MPLS-TP-MESH] with thanks to Tae-sik Cheung and Jeong-dong Ryoo.
关于共享网格保护的一些图形和文本是从[MPLS-TP-mesh]借用的，这要感谢Tae sik Cheung和Jeong dong Ryoo。
[G.806] ITU-T, "Characteristics of transport equipment - Description methodology and generic functionality", Recommendation G.806, January 2009.
[G.806]ITU-T，“运输设备的特性——描述方法和通用功能”，建议G.806，2009年1月。
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and subnetwork protection", Recommendation G.808.1, December 2003.
[G.808.1]ITU-T，“通用保护交换——线性线路和子网保护”，建议G.808.1，2003年12月。
[G.841] ITU-T, "Types and Characteristics of SDH Network Protection Architectures", Recommendation G.841, October 1998.
[G.841]ITU-T，“SDH网络保护体系结构的类型和特征”，建议G.841，1998年10月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月。
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006.
[RFC4428]Papadimitriou，D.，Ed.，和E.Mannie，Ed.，“基于通用多协议标签交换（GMPLS）的恢复机制分析（包括保护和恢复）”，RFC 4428，2006年3月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月。
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317]Bryant，S.，Ed.，和L.Andersson，Ed.，“联合工作组（JWT）关于传输配置文件的MPLS体系结构考虑的报告”，RFC 53172009年2月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC5950] Mansfield, S., Ed., Gray, E., Ed., and K. Lam, Ed., "Network Management Framework for MPLS-based Transport Networks", RFC 5950, September 2010.
[RFC5950]Mansfield，S.，Ed.，Gray，E.，Ed.，和K.Lam，Ed.，“基于MPLS的传输网络的网络管理框架”，RFC 59502010年9月。
[RFC6371] Buci, I., Ed. and B. Niven-Jenkins, Ed., "A Framework for MPLS in Transport Networks", RFC 6371, September 2011.
[RFC6371]Buci，I.，Ed.和B.Niven Jenkins，Ed.，“传输网络中MPLS的框架”，RFC 63712011年9月。
[GMPLS-OAM] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE extensions for OAM Configuration", Work in Progress, July 2011.
[GMPLS-OAM]Takacs，A.，Fedyk，D.，和J.He，“用于OAM配置的GMPLS RSVP-TE扩展”，正在进行的工作，2011年7月。
[MPLS-TP-LP] Weingarten, Y., Osborne, E., Sprecher, N., Fulignoli, A., Ed., and Y. Weingarten, Ed., "MPLS-TP Linear Protection", Work in Progress, August 2011.
[MPLS-TP-LP]Y.温加滕、E.奥斯本、N.斯普雷彻、F.弗利诺利和Y.温加滕，“MPLS-TP线性保护”，在建工程，2011年8月。
[MPLS-TP-MESH] Cheung, T. and J. Ryoo, "MPLS-TP Shared Mesh Protection", Work in Progress, April 2011.
[MPLS-TP-MESH]Cheung，T.和J.Ryoo，“MPLS-TP共享网格保护”，正在进行的工作，2011年4月。
[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月。
[RFC3386] Lai, W., Ed., and D. McDysan, Ed., "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[RFC3386]Lai，W.，Ed.，和D.McDysan，Ed.，“网络层次结构和多层生存能力”，RFC 3386，2002年11月。
[RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469]Sharma，V.，Ed.，和F.Hellstrand，Ed.，“基于多协议标签交换（MPLS）的恢复框架”，RFC 3469，2003年2月。
[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月。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.
[RFC4426]Lang，J.，Ed.，Rajagopalan，B.，Ed.，和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）恢复功能规范”，RFC 4426，2006年3月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783]Berger，L.，Ed.“GMPLS-报警信息的通信”，RFC 4783，2006年12月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 48742007年4月。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 52122008年7月。
[RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. Vasseur, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", RFC 5298, August 2008.
[RFC5298]Takeda，T.，Ed.，Farrel，A.，Ed.，Ikejiri，Y.，和JP。Vasseur，“域间标签交换路径（LSP）恢复分析”，RFC 5298，2008年8月。
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817, April 2010.
[RFC5817]Ali，Z.，Vasseur，JP.，Zamfir，A.，和J.Newton，“MPLS和广义MPLS流量工程网络中的优雅关机”，RFC 58172010年4月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., and Bitar, N., Ed, and E. Gray, Ed., "MPLS-TP Control Plane Framework", RFC 6373, September 2011.
[RFC6373]Andersson，L.，Ed.，Berger，L.，Ed.，Fang，L.，Ed.，和Bitar，N.，Ed，和E.Gray，Ed.，“MPLS-TP控制平面框架”，RFC 63732011年9月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 62912011年6月。
[ROSETTA] 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 2011.
[ROSETTA]Van Helvoort，H.，Ed.，Andersson，L.，Ed.，和N.Sprecher，Ed.，“多协议标签交换传输配置文件（MPLS-TP）草案/RFC和ITU-T传输网络建议中使用的术语词典”，进展中的工作，2011年6月。
Authors' Addresses
作者地址
Nurit Sprecher (editor) Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel
努瑞特·斯普雷彻（编辑）诺基亚西门子网络3号，以色列内韦-内曼哈沙隆市，邮编：45241
EMail: nurit.sprecher@nsn.com
EMail: nurit.sprecher@nsn.com
Adrian Farrel (editor) Juniper Networks
Adrian Farrel（编辑）Juniper Networks
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk