Network Working Group J. Lang, Ed.
Request for Comments: 4426 B. Rajagopalan, Ed.
Category: Standards Track D. Papadimitriou, Ed.
March 2006
Network Working Group J. Lang, Ed.
Request for Comments: 4426 B. Rajagopalan, Ed.
Category: Standards Track D. Papadimitriou, Ed.
March 2006
Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification
通用多协议标签交换（GMPLS）恢复功能规范
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents.
本文档介绍了支持基于通用多协议标签交换（GMPLS）的恢复（即保护和恢复）所需的协议扩展的功能描述。协议特定的格式和机制将在配套文件中描述。
Table of Contents
目录
1. Introduction ................................................. 2
1.1. Conventions Used in This Document ...................... 3
2. Span Protection .............................................. 3
2.1. Unidirectional 1+1 Dedicated Protection ................ 4
2.2. Bi-directional 1+1 Dedicated Protection ................ 5
2.3. Dedicated 1:1 Protection with Extra Traffic ............ 6
2.4. Shared M:N Protection .................................. 8
2.5. Messages ............................................... 10
2.5.1. Failure Indication Message ..................... 10
2.5.2. Switchover Request Message ..................... 11
2.5.3. Switchover Response Message .................... 11
2.6. Preventing Unintended Connections ...................... 12
3. End-to-End (Path) Protection and Restoration ................. 12
3.1. Unidirectional 1+1 Protection .......................... 12
3.2. Bi-directional 1+1 Protection .......................... 12
3.2.1. Identifiers .................................... 13
3.2.2. Nodal Information .............................. 14
1. Introduction ................................................. 2
1.1. Conventions Used in This Document ...................... 3
2. Span Protection .............................................. 3
2.1. Unidirectional 1+1 Dedicated Protection ................ 4
2.2. Bi-directional 1+1 Dedicated Protection ................ 5
2.3. Dedicated 1:1 Protection with Extra Traffic ............ 6
2.4. Shared M:N Protection .................................. 8
2.5. Messages ............................................... 10
2.5.1. Failure Indication Message ..................... 10
2.5.2. Switchover Request Message ..................... 11
2.5.3. Switchover Response Message .................... 11
2.6. Preventing Unintended Connections ...................... 12
3. End-to-End (Path) Protection and Restoration ................. 12
3.1. Unidirectional 1+1 Protection .......................... 12
3.2. Bi-directional 1+1 Protection .......................... 12
3.2.1. Identifiers .................................... 13
3.2.2. Nodal Information .............................. 14
3.2.3. End-to-End Failure Indication Message .......... 14
3.2.4. End-to-End Failure Acknowledgement Message ..... 15
3.2.5. End-to-End Switchover Request Message .......... 15
3.2.6. End-to-End Switchover Response Message ......... 15
3.3. Shared Mesh Restoration ................................ 15
3.3.1. End-to-End Failure Indication and
Acknowledgement Message ........................ 16
3.3.2. End-to-End Switchover Request Message .......... 16
3.3.3. End-to-End Switchover Response Message ......... 17
4. Reversion and Other Administrative Procedures ................ 17
5. Discussion ................................................... 18
5.1. LSP Priorities During Protection ....................... 18
6. Security Considerations ...................................... 19
7. Contributors ................................................. 20
8. References ................................................... 21
8.1. Normative References ................................... 21
8.2. Informative References ................................. 22
3.2.3. End-to-End Failure Indication Message .......... 14
3.2.4. End-to-End Failure Acknowledgement Message ..... 15
3.2.5. End-to-End Switchover Request Message .......... 15
3.2.6. End-to-End Switchover Response Message ......... 15
3.3. Shared Mesh Restoration ................................ 15
3.3.1. End-to-End Failure Indication and
Acknowledgement Message ........................ 16
3.3.2. End-to-End Switchover Request Message .......... 16
3.3.3. End-to-End Switchover Response Message ......... 17
4. Reversion and Other Administrative Procedures ................ 17
5. Discussion ................................................... 18
5.1. LSP Priorities During Protection ....................... 18
6. Security Considerations ...................................... 19
7. Contributors ................................................. 20
8. References ................................................... 21
8.1. Normative References ................................... 21
8.2. Informative References ................................. 22
A requirement for the development of a common control plane for both optical and electronic switching equipment is that there must be signaling, routing, and link management mechanisms that support data plane fault recovery. In this document, the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are used only when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery period (see [RFC4427]).
为光和电子交换设备开发通用控制平面的一个要求是必须有支持数据平面故障恢复的信令、路由和链路管理机制。在本文件中，“恢复”一词一般用于表示保护和恢复；只有在需要区分时，才使用特定术语“保护”和“恢复”。保护和恢复之间的细微区别基于恢复期间完成的资源分配（请参见[RFC4427]）。
A label-switched path (LSP) may be subject to local (span), segment, and/or end-to-end recovery. Local span protection refers to the protection of the link (and hence all the LSPs marked as required for span protection and routed over the link) between two neighboring switches. Segment protection refers to the recovery of an LSP segment (i.e., an SNC in the ITU-T terminology) between two nodes, i.e., the boundary nodes of the segment. End-to-end protection refers to the protection of an entire LSP from the ingress to the egress port. The end-to-end recovery models discussed in this document apply to segment protection where the source and destination refer to the protected segment rather than the entire LSP. Multiple recovery levels may be used concurrently by a single LSP for added resiliency; however, the interaction between levels affects any one direction of the LSP results in both directions of the LSP being switched to a new span, segment, or end-to-end path.
标签交换路径（LSP）可以进行本地（span）、段和/或端到端恢复。本地范围保护是指保护两个相邻交换机之间的链路（因此所有标记为需要范围保护并通过链路路由的LSP）。段保护是指在两个节点（即段的边界节点）之间恢复LSP段（即ITU-T术语中的SNC）。端到端保护是指从入口到出口的整个LSP的保护。本文档中讨论的端到端恢复模型适用于段保护，其中源和目标指的是受保护的段，而不是整个LSP。单个LSP可同时使用多个恢复级别，以增加恢复能力；然而，层之间的交互影响LSP的任何一个方向，导致LSP的两个方向切换到新的跨度、段或端到端路径。
Unless otherwise stated, all references to "link" in this document indicate a bi-directional link (which may be realized as a pair of unidirectional links).
除非另有说明，本文件中对“链路”的所有引用均表示双向链路（可实现为一对单向链路）。
Consider the control plane message flow during the establishment of an LSP. This message flow proceeds from an initiating (or source) node to a terminating (or destination) node, via a sequence of intermediate nodes. A node along the LSP is said to be "upstream" from another node if the former occurs first in the sequence. The latter node is said to be "downstream" from the former node. That is, an "upstream" node is closer to the initiating node than a node further "downstream". Unless otherwise stated, all references to "upstream" and "downstream" are in terms of the control plane message flow.
考虑LSP建立过程中的控制平面消息流。该消息流通过一系列中间节点从发起（或源）节点前进到终止（或目的）节点。如果LSP上的节点在序列中首先出现，则称其为另一节点的“上游”。后一个节点被称为前一个节点的“下游”。也就是说，“上游”节点比“下游”节点更靠近发起节点。除非另有说明，所有对“上游”和“下游”的引用都是根据控制平面消息流。
The flow of the data traffic is defined from ingress (source node) to egress (destination node). Note that for bi-directional LSPs, there are two different data plane flows, one for each direction of the LSP. This document presents a protocol functional description to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol-specific formats, encoding, and mechanisms will be described in companion documents.
数据通信流定义为从入口（源节点）到出口（目的节点）。请注意，对于双向LSP，有两个不同的数据平面流，LSP的每个方向一个。本文档介绍了支持基于通用多协议标签交换（GMPLS）的恢复（即保护和恢复）的协议功能描述。协议特定的格式、编码和机制将在配套文件中描述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition, the reader is assumed to be familiar with the terminology used in [RFC3945], [RFC3471] and referenced as well as [RFC4427].
此外，假定读者熟悉[RFC3945]、[RFC3471]和[RFC4427]中引用的术语。
Consider a (working) link i between two nodes A and B. There are two fundamental models for span protection. The first is referred to as 1+1 protection. Under this model, a dedicated link j is pre-assigned to protect link i. LSP traffic is permanently bridged onto both links i and j at the ingress node, and the egress node selects the signal (i.e., normal traffic) from i or j, based on a selection function (e.g., signal quality). Under unidirectional 1+1 span protection (Section 2.1), each node A and B acts autonomously to select the signal from the working link i or the protection link j. Under bi-directional 1+1 span protection (Section 2.2) the two nodes A and B coordinate the selection function such that they select the signal from the same link, i or j.
考虑两个节点A和B之间的（工作）链路I。跨度保护的基本模型有两种。第一种称为1+1保护。在此模型下，预先分配专用链路j以保护链路i。LSP业务被永久地桥接到入口节点处的链路i和j上，并且出口节点基于选择功能（例如，信号质量）从i或j选择信号（即，正常业务）。在单向1+1跨距保护（第2.1节）下，每个节点A和B自主地从工作链路i或保护链路j选择信号。在双向1+1跨距保护（第2.2节）下，两个节点A和B协调选择功能，以便从同一链路i或j选择信号。
Under the second model, a set of N working links are protected by a set of M protection links, usually with M =< N. A failure in any of the N working links results in traffic being switched to one of the M protection links that is available. This is typically a three-step process: first the data plane failure is detected at the egress node and reported (notification), then a protection link is selected, and finally, the LSPs on the failed link are moved to the protection link. If reversion is supported, a fourth step is included, i.e., return of the traffic to the working link (when the working link has recovered from the failure). In Section 2.3, 1:1 span protection is described. In Section 2.4, M:N span protection is described, where M =< N.
在第二种模式下，一组N个工作链路由一组M个保护链路保护，通常M=<N。N个工作链路中的任何一个出现故障都会导致流量切换到可用的M个保护链路之一。这通常是一个三步过程：首先在出口节点检测并报告（通知）数据平面故障，然后选择保护链路，最后将故障链路上的LSP移动到保护链路。如果支持恢复，则包括第四个步骤，即将业务返回到工作链路（当工作链路已从故障中恢复时）。在第2.3节中，描述了1:1跨度保护。在第2.4节中，描述了M:N跨距保护，其中M=<N。
Suppose a bi-directional LSP is routed over link i between two nodes A and B. Under unidirectional 1+1 protection, a dedicated link j is pre-assigned to protect the working link i. LSP traffic is permanently bridged on both links at the ingress node, and the egress node selects the normal traffic from one of the links, i or j. If a node (A or B) detects a failure of a span, it autonomously invokes a process to receive the traffic from the protection span. Thus, it is possible that node A selects the signal from link i in the B to A direction of the LSP, and node B selects the signal from link j in the A to B direction.
假设双向LSP在两个节点a和B之间的链路i上路由。在单向1+1保护下，预先分配专用链路j以保护工作链路i。LSP业务在入口节点的两条链路上永久桥接，并且出口节点从其中一条链路i或j选择正常业务。如果节点（a或B）检测到范围故障，它将自动调用进程以接收来自保护范围的流量。因此，节点A可能在LSP的B到A方向上选择来自链路i的信号，并且节点B在A到B方向上选择来自链路j的信号。
The following functionality is required for 1+1 unidirectional span protection:
1+1单向跨距保护需要以下功能：
o Routing: A single TE link encompassing both working and protection links SHOULD be announced with a Link Protection Type "Dedicated 1+1", along with the bandwidth parameters for the working link. As the resources are consumed/released, the bandwidth parameters of the TE link are adjusted accordingly. Encoding of the Link Protection Type and bandwidth parameters in IS-IS is specified in [RFC4205]. Encoding of this information in OSPF is specified in [RFC4203].
o 路由：包含工作链路和保护链路的单个TE链路应使用链路保护类型“专用1+1”以及工作链路的带宽参数进行公布。当资源被消耗/释放时，TE链路的带宽参数被相应地调整。IS-IS中链路保护类型和带宽参数的编码在[RFC4205]中规定。[RFC4203]中规定了OSPF中该信息的编码。
o Signaling: The Link Protection object/TLV SHOULD be used to request "Dedicated 1+1" link protection for that LSP. This object/TLV is defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy. No additional signaling is required when a fail-over occurs.
o 信令：应使用链路保护对象/TLV为该LSP请求“专用1+1”链路保护。此对象/TLV在[RFC3471]中定义。如果未使用链路保护对象/TLV，则链路选择取决于本地策略。发生故障转移时，不需要额外的信号。
o Link management: Both nodes MUST have a consistent view of the link protection association for the spans. This can be done using the Link Management Protocol (LMP) [RFC4204], or if LMP is not used, this MUST be configured manually.
o 链路管理：两个节点都必须具有跨度的链路保护关联的一致视图。这可以使用链路管理协议（LMP）[RFC4204]完成，或者如果未使用LMP，则必须手动配置。
Suppose a bi-directional LSP is routed over link i between two nodes A and B. Under bi-directional 1+1 protection, a dedicated link j is pre-assigned to protect the working link i. LSP traffic is permanently duplicated on both links, and under normal conditions, the traffic from link i is received by nodes A and B (in the appropriate directions). A failure affecting link i results in both A and B switching to the traffic on link j in the respective directions. Note that some form of signaling is required to ensure that both A and B start receiving traffic from the protection link.
假设在两个节点a和B之间的链路i上路由双向LSP。在双向1+1保护下，预先分配专用链路j以保护工作链路i。LSP业务在两个链路上永久复制，并且在正常情况下，来自链路i的业务由节点A和B（在适当的方向上）接收。影响链路i的故障导致A和B在各自方向上切换到链路j上的业务。注意，需要某种形式的信令来确保A和B开始从保护链路接收通信量。
The basic steps in 1+1 bi-directional span protection are as follows:
1+1双向跨距保护的基本步骤如下：
1. If a node (A or B) detects the failure of the working link (or a degradation of signal quality over the working link), it SHOULD begin receiving on the protection link and send a Switchover Request message reliably to the other node (B or A, respectively). This message SHOULD indicate the identity of the failed working link and provide other relevant information.
1. 如果节点（a或B）检测到工作链路故障（或工作链路上的信号质量下降），则应开始在保护链路上接收并向另一节点（分别为B或a）可靠地发送切换请求消息。此消息应指示故障工作链路的标识，并提供其他相关信息。
2. Upon receipt of the Switchover Request message, a node MUST begin receiving from the protection link and send a Switchover Response message to the other node (A or B, respectively). Because both the working/protect spans are exposed to routing and signaling as a single link, the switchover SHOULD be transparent to routing and signaling.
2. 在收到切换请求消息后，节点必须开始从保护链路接收并向另一节点（分别为a或B）发送切换响应消息。由于工作/保护跨距都作为单个链路暴露于路由和信令，因此切换对路由和信令应该是透明的。
The following functionality is required for 1+1 bi-directional span protection:
1+1双向跨距保护需要以下功能：
o The routing procedures are the same as in 1+1 unidirectional.
o 布线程序与1+1单向布线相同。
o The signaling procedures are the same as in 1+1 unidirectional.
o 信号程序与1+1单向中的相同。
o In addition to the procedures described in 1+1 (unidirectional), a Switchover Request message MUST be used to signal the Switchover Request. This can be done using LMP [RFC4204]. Note that GMPLS-based mechanisms MAY not be necessary when the underlying span (transport) technology provides such a mechanism.
o 除了1+1（单向）中描述的程序外，还必须使用切换请求消息来发出切换请求的信号。这可以使用LMP[RFC4204]实现。请注意，当基础span（传输）技术提供这种机制时，可能不需要基于GMPLS的机制。
Consider two adjacent nodes, A and B. Under 1:1 protection, a dedicated link j between A and B is pre-assigned to protect working link i. Link j may be carrying (pre-emptable) Extra Traffic. A failure affecting link i results in the corresponding LSP(s) being restored to link j. Extra Traffic being routed over link j may need to be pre-empted to accommodate the LSPs that have to be restored.
考虑两个相邻的节点A和B，在1:1保护下，预先分配A和B之间的专用链路J，以保护工作链路I。链路j可能承载（可抢占）额外流量。影响链路i的故障导致相应的LSP被恢复到链路j。通过链路j路由的额外流量可能需要被预先占用，以容纳必须恢复的LSP。
Once a fault is isolated/localized, the affected LSP(s) must be moved to the protection link. The process of moving an LSP from a failed (working) link to a protection link must be initiated by one of the nodes, A or B. This node is referred to as the "master". The other node is called the "slave". The determination of the master and the slave may be based on configured information or protocol specific requirements.
一旦故障被隔离/定位，受影响的LSP必须移动到保护链路。将LSP从故障（工作）链路移动到保护链路的过程必须由其中一个节点a或B启动。该节点称为“主节点”。另一个节点称为“从节点”。主设备和从设备的确定可以基于配置信息或协议特定要求。
The basic steps in dedicated 1:1 span protection (ignoring reversion) are as follows:
专用1:1量程保护（忽略反向）的基本步骤如下：
1. If the master detects/localizes a link failure event, it invokes a process to allocate the protection link to the affected LSP(s).
1. 如果主机检测到/定位链路故障事件，它将调用一个进程将保护链路分配给受影响的LSP。
2. If the slave detects a link failure event, it informs the master of the failure using a failure indication message. The master then invokes the same procedure as (1) to move the LSPs to the protection link. If the protection link is carrying Extra Traffic, the slave stops using the span for the Extra Traffic.
2. 如果从机检测到链路故障事件，它将使用故障指示消息通知主机故障。然后，主机调用与（1）相同的过程将LSP移动到保护链路。如果保护链路承载额外的通信量，则从机停止使用额外通信量的跨度。
3. Once the span protection procedure is invoked in the master, it requests the slave to switch the affected LSP(s) to the protection link. Prior to this, if the protection link is carrying Extra Traffic, the master stops using the span for this traffic (i.e., the traffic is dropped by the master and not forwarded into or out of the protection link).
3. 一旦在主设备中调用span保护程序，它将请求从设备将受影响的LSP切换到保护链路。在此之前，如果保护链路承载额外的通信量，则主机停止使用该通信量的跨度（即，该通信量由主机丢弃，而不是转发到保护链路或转发出保护链路）。
4. The slave sends an acknowledgement to the master. Prior to this, the slave stops using the link for Extra Traffic (i.e., the traffic is dropped by the slave and not forwarded into or out of the protection link). It then starts sending the normal traffic on the selected protection link.
4. 从属设备向主设备发送确认信息。在此之前，从机停止使用链路进行额外通信（即，从机丢弃通信，而不是转发到保护链路或从保护链路转发出去）。然后，它开始在所选保护链路上发送正常通信量。
5. When the master receives the acknowledgement, it starts sending and receiving the normal traffic over the new link. The switchover of the LSPs is thus completed.
5. 当主机收到确认时，它开始通过新链路发送和接收正常通信量。这样就完成了LSP的切换。
Note: Although this mechanism implies more traffic dropped than necessary, it is preferred over possible misconnections during the recovery process.
注意：尽管此机制意味着丢弃的流量超过了需要的流量，但在恢复过程中，与可能的错误连接相比，它是首选的。
From the description above, it is clear that 1:1 span protection may require up to three signaling messages for each failed span: a failure indication message, an LSP Switchover Request message, and an LSP Switchover Response message. Furthermore, it may be possible to switch multiple LSPs from the working span to the protection span simultaneously.
从上面的描述可以清楚地看出，1:1跨度保护对于每个故障跨度可能需要最多三条信令消息：故障指示消息、LSP切换请求消息和LSP切换响应消息。此外，可以同时将多个LSP从工作范围切换到保护范围。
The following functionality is required for dedicated 1:1 span protection:
专用1:1量程保护需要以下功能：
o Pre-emption MUST be supported to accommodate Extra Traffic.
o 必须支持抢占，以适应额外的流量。
o Routing: A single TE link encompassing both working and protection links is announced with a Link Protection Type "Dedicated 1:1". If Extra Traffic is supported over the protection link, then the bandwidth parameters for the protection link MUST also be announced. The differentiation between bandwidth for working and protect links is made using priority mechanisms. In other words, the network MUST be configured such that bandwidth at priority X or lower is considered Extra Traffic.
o 路由：包含工作链路和保护链路的单个TE链路以链路保护类型“专用1:1”发布。如果通过保护链路支持额外流量，则还必须公布保护链路的带宽参数。使用优先级机制区分工作链路和保护链路的带宽。换句话说，必须对网络进行配置，以便将优先级为X或更低的带宽视为额外流量。
If there is a failure on the working link, then the normal traffic is switched to the protection link, pre-empting Extra Traffic if necessary. The bandwidth for the protection link MUST be adjusted accordingly.
如果工作链路上出现故障，则正常通信量将切换到保护链路，如有必要，可抢占额外通信量。必须相应地调整保护链路的带宽。
o Signaling: To establish an LSP on the working link, the Link Protection object/TLV indicating "Dedicated 1:1" SHOULD be included in the signaling request message for that LSP. To establish an LSP on the protection link, the appropriate priority (indicating Extra Traffic) SHOULD be used for that LSP. These objects/TLVs are defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy.
o 信令：为了在工作链路上建立LSP，指示“专用1:1”的链路保护对象/TLV应包含在该LSP的信令请求消息中。要在保护链路上建立LSP，应为该LSP使用适当的优先级（指示额外流量）。[RFC3471]中定义了这些对象/TLV。如果未使用链路保护对象/TLV，则链路选择取决于本地策略。
o Link management: Both nodes MUST have a consistent view of the link protection association for the spans. This can be done using LMP [RFC4204] or via manual configuration.
o 链路管理：两个节点都必须具有跨度的链路保护关联的一致视图。这可以使用LMP[RFC4204]或通过手动配置完成。
o When a link failure is detected at the slave, a failure indication message MUST be sent to the master informing the node of the link failure.
o 当从机检测到链路故障时，必须向主机发送故障指示消息，通知节点链路故障。
Shared M:N protection is described with respect to two neighboring nodes, A and B. The scenario considered is as follows:
共享M:N保护针对两个相邻节点A和B进行描述。考虑的场景如下：
o At any point in time, there are two sets of links between A and B, i.e., a working set of N (bi-directional) links carrying traffic subject to protection and a protection set of M (bi-directional) links. A protection link may be carrying Extra Traffic. There is no a priori relationship between the two sets of links, but the value of M and N MAY be pre-configured. The specific links in the protection set MAY be pre-configured to be physically diverse to avoid the possibility of failure events affecting a large proportion of protection links (along with working links).
o 在任何时间点，A和B之间存在两组链路，即，承载受保护业务的N个（双向）链路的工作集和M个（双向）链路的保护集。保护链路可能承载额外的流量。两组链路之间没有先验关系，但是M和N的值可以预先配置。保护组中的特定链路可以预先配置为物理多样性，以避免故障事件影响大部分保护链路（以及工作链路）的可能性。
o When a link in the working set is affected by a failure, the normal traffic is diverted to a link in the protection set, if such a link is available. Note that such a link might be carrying more than one LSP, e.g., an OC-192 link carrying four STS-48 LSPs.
o 当工作组中的链路受到故障影响时，如果保护组中的链路可用，则正常通信量将转移到该链路。注意，这样的链路可能承载多个LSP，例如，承载四个STS-48 LSP的OC-192链路。
o More than one link in the working set may be affected by the same failure event. In this case, there may not be an adequate number of protection links to accommodate all of the affected traffic carried by failed working links. The set of affected working links that are actually restored over available protection links is then subject to policies (e.g., based on relative priority of working traffic). These policies are not specified in this document.
o 同一故障事件可能会影响工作集中的多个链路。在这种情况下，可能没有足够数量的保护链路来容纳故障工作链路承载的所有受影响流量。然后，通过可用保护链路实际恢复的受影响工作链路集受策略约束（例如，基于工作流量的相对优先级）。本文档中未指定这些策略。
o When normal traffic must be diverted from a failed link in the working set to a protection link, the decision as to which protection link is chosen is always made by one of the nodes, A or B. This node is considered the "master" and it is required to both apply any policies and select specific protection links to divert working traffic. The other node is considered the "slave". The determination of the master and the slave MAY be based on configured information, protocol-specific requirements, or as a result of running a neighbor discovery procedure.
o 当正常流量必须从工作集中的故障链路转移到保护链路时，选择哪个保护链路的决定总是由其中一个节点a或B做出的。该节点被视为“主节点”，需要应用任何策略并选择特定的保护链路来转移工作流量。另一个节点被视为“从节点”。主设备和从设备的确定可以基于配置信息、协议特定要求，或者作为运行邻居发现过程的结果。
o Failure events are detected by transport layer mechanisms, if available (e.g., SONET Alarm Indication Signal (AIS)/Remote Defect Indication (RDI)). Since the bi-directional links are formed by a pair of unidirectional links, a failure in the link from A to B is typically detected by B, and a failure in the opposite direction is detected by A. It is possible for a
o 故障事件由传输层机制检测（如果可用）（例如SONET报警指示信号（AIS）/远程缺陷指示（RDI））。由于双向链路由一对单向链路形成，因此从a到B的链路中的故障通常由B检测，而相反方向的故障由a检测。a是可能的
failure to simultaneously affect both directions of the bi-directional link. In this case, A and B will concurrently detect failures, in the B-to-A direction and in the A-to-B direction, respectively.
未能同时影响双向链路的两个方向。在这种情况下，A和B将分别在B-to-A方向和A-to-B方向同时检测故障。
The basic steps in M:N protection (ignoring reversion) are as follows:
M:N保护（忽略恢复）的基本步骤如下：
1. If the master detects a failure of a working link, it autonomously invokes a process to allocate a protection link to the affected traffic.
1. 如果主机检测到工作链路出现故障，它将自动调用一个进程，将保护链路分配给受影响的流量。
2. If the slave detects a failure of a working link, it MUST inform the master of the failure using a failure indication message. The master then invokes the same procedure as above to allocate a protection link. (It is possible that the master has itself detected the same failure, for example, a failure simultaneously affecting both directions of a link.)
2. 如果从机检测到工作链路故障，则必须使用故障指示消息通知主机故障。然后，主机调用与上面相同的过程来分配保护链路。（主机本身可能检测到相同的故障，例如，同时影响链路两个方向的故障。）
3. Once the master has determined the identity of the protection link, it indicates this to the slave and requests the switchover of the traffic (using a "Switchover Request" message). Prior to this, if the protection link is carrying Extra Traffic, the master stops using the link for this traffic (i.e., the traffic is dropped by the master and not forwarded into or out of the protection link).
3. 一旦主设备确定了保护链路的标识，它就会向从设备指示该标识，并请求业务的切换（使用“切换请求”消息）。在此之前，如果保护链路承载额外的通信量，则主机将停止使用该通信量的链路（即，该通信量由主机丢弃，而不是转发到保护链路或转发出保护链路）。
4. The slave sends a "Switchover Response" message back to the master. Prior to this, if the selected protection link is carrying traffic that could be pre-empted, the slave stops using the link for this traffic (i.e., the traffic is dropped by the slave and not forwarded into or out of the protection link). It then starts sending the normal traffic on the selected protection link.
4. 从机向主机发送“切换响应”消息。在此之前，如果所选的保护链路承载可能被抢占的通信量，则从机将停止使用该通信量的链路（即，该通信量由从机丢弃，而不是转发到保护链路或转发出保护链路）。然后，它开始在所选保护链路上发送正常通信量。
5. When the master receives the Switchover Response, it starts sending and receiving the traffic that was previously carried on the now-failed link over the new link.
5. 当主机接收到切换响应时，它开始通过新链路发送和接收先前在现在故障的链路上承载的通信量。
Note: Although this mechanism implies more traffic dropped than necessary, it is preferred over possible misconnections during the recovery process.
注意：尽管此机制意味着丢弃的流量超过了需要的流量，但在恢复过程中，与可能的错误连接相比，它是首选的。
From the description above, it is clear that M:N span restoration (involving LSP local recovery) MAY require up to three messages for each working link being switched: a failure indication message, a Switchover Request message, and a Switchover Response message.
从上面的描述可以清楚地看出，M:N跨度恢复（涉及LSP本地恢复）可能需要为每个正在切换的工作链路提供最多三条消息：故障指示消息、切换请求消息和切换响应消息。
The following functionality is required for M:N span restoration:
M:N跨度恢复需要以下功能：
o Pre-emption MUST be supported to accommodate Extra Traffic.
o 必须支持抢占，以适应额外的流量。
o Routing: A single TE link encompassing both sets of working and protect links should be announced with a Link Protection Type "Shared M:N". If Extra Traffic is supported over a set of the protection links, then the bandwidth parameters for the set of protection links MUST also be announced. The differentiation between bandwidth for working and protect links is made using priority mechanisms.
o 路由：包含两组工作和保护链路的单个TE链路应使用链路保护类型“共享M:N”进行公布。如果在一组保护链路上支持额外流量，则还必须公布该组保护链路的带宽参数。使用优先级机制区分工作链路和保护链路的带宽。
If there is a failure on a working link, then the affected LSP(s) MUST be switched to a protection link, pre-empting Extra Traffic if necessary. The bandwidth for the protection link MUST be adjusted accordingly.
如果工作链路上出现故障，则受影响的LSP必须切换到保护链路，如有必要，可抢占额外流量。必须相应地调整保护链路的带宽。
o Signaling: To establish an LSP on the working link, the Link Protection object/TLV indicating "Shared M:N" SHOULD be included in the signaling request message for that LSP. To establish an LSP on the protection link, the appropriate priority (indicating Extra Traffic) SHOULD be used. These objects/TLVs are defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy.
o 信令：为了在工作链路上建立LSP，指示“共享M:N”的链路保护对象/TLV应包括在该LSP的信令请求消息中。要在保护链路上建立LSP，应使用适当的优先级（表示额外流量）。[RFC3471]中定义了这些对象/TLV。如果未使用链路保护对象/TLV，则链路选择取决于本地策略。
o For link management, both nodes MUST have a consistent view of the link protection association for the links. This can be done using LMP [RFC4204] or via manual configuration.
o 对于链路管理，两个节点必须具有链路的链路保护关联的一致视图。这可以使用LMP[RFC4204]或通过手动配置完成。
The following messages are used in local span protection procedures.
以下消息用于本地量程保护程序。
These messages SHOULD be delivered reliably. Therefore, the protocol mechanisms used to deliver these messages SHOULD provide sequencing, acknowledgement, and retransmission. The protocol SHOULD also handle situations where the message(s) cannot be delivered.
这些信息应该可靠地传递。因此，用于传递这些消息的协议机制应该提供排序、确认和重传。协议还应处理无法传递消息的情况。
The messages described in the following subsections are abstract; their format and encoding will be described in separate documents.
以下小节中描述的消息是抽象的；其格式和编码将在单独的文件中描述。
This message is sent from the slave to the master to indicate the identities of one or more failed working links. This message MAY not be necessary when the transport plane technology itself provides for such a notification.
此消息从从机发送到主机，以指示一个或多个故障工作链路的标识。当运输机技术本身提供此类通知时，可能不需要此消息。
The number of links included in the message depends on the number of failures detected within a window of time by the sending node. A node MAY choose to send separate failure indication messages in the interest of completing the recovery for a given link within an implementation-dependent time constraint.
消息中包含的链接数取决于发送节点在一个时间窗口内检测到的故障数。为了在依赖于实现的时间约束内完成给定链路的恢复，节点可以选择发送单独的故障指示消息。
Under bi-directional 1+1 span protection, this message is used to coordinate the selecting function at both nodes. This message originated at the node that detected the failure.
在双向1+1跨距保护下，此消息用于协调两个节点的选择功能。此消息起源于检测到故障的节点。
Under dedicated 1:1 and shared M:N span protection, this message is used as an LSP Switchover Request. This message is sent from the master node to the slave node (reliably) to indicate that the LSP(s) on the (failed) working link can be switched to an available protection link. If so, the ID of the protection link, as well as the LSP labels (if necessary), MUST be indicated. These identifiers MUST be consistent with those used in GMPLS signaling.
在专用1:1和共享M:N跨度保护下，此消息用作LSP切换请求。此消息从主节点发送到从节点（可靠），以指示（故障）工作链路上的LSP可以切换到可用的保护链路。如果是，则必须指示保护链路的ID以及LSP标签（如有必要）。这些标识符必须与GMPLS信令中使用的标识符一致。
A working link may carry multiple LSPs. Since the normal traffic carried over the working link is switched to the protection link, it MAY be possible for the LSPs on the working link to be mapped to the protection link without re-signaling each individual LSP. For example, if link bundling [RFC4201] is used where the working and protect links are mapped to component links, and the labels are the same on the working and protection links, it MAY be possible to change the component links without needing to re-signal each individual LSP. Optionally, the labels MAY need to be explicitly coordinated between the two nodes. In this case, the Switchover Request message SHOULD carry the new label mappings.
一个工作链路可以承载多个LSP。由于通过工作链路携带的正常业务被切换到保护链路，因此工作链路上的LSP可能被映射到保护链路，而无需对每个单独的LSP重新发信号。例如，如果在工作链路和保护链路映射到组件链路的情况下使用链路捆绑[RFC4201]，并且工作链路和保护链路上的标签相同，则可以更改组件链路，而无需重新向每个LSP发送信号。或者，可能需要在两个节点之间显式协调标签。在这种情况下，切换请求消息应该带有新的标签映射。
The master may not be able to find protection links to accommodate all failed working links. Thus, if this message is generated in response to a Failure Indication message from the slave, then the set of failed links in the message MAY be a sub-set of the links received in the Failure Indication message. Depending on time constraints, the master may switch the normal traffic from the set of failed links in smaller batches. Thus, a single failure indication message MAY result in the master sending more than one Switchover Request message to the same slave node.
主机可能无法找到保护链路以容纳所有故障工作链路。因此，如果该消息是响应于来自从机的故障指示消息而生成的，则该消息中的故障链路集可以是在故障指示消息中接收的链路的子集。根据时间限制，主机可以以较小的批量从故障链路集中切换正常通信量。因此，单个故障指示消息可能导致主节点向同一从节点发送多个切换请求消息。
This message is sent from the slave to the master (reliably) to indicate the completion (or failure) of switchover at the slave. In this message, the slave MAY indicate that it cannot switch over to the corresponding free link for some reason. In this case, the
此消息从从机发送到主机（可靠），以指示从机切换的完成（或失败）。在该消息中，从机可能表示由于某种原因无法切换到相应的空闲链路。在这种情况下
master and slave notify the user (operator) of the failed switchover. A notification of the failure MAY also be used as a trigger in an end-to-end recovery.
主设备和从设备通知用户（操作员）切换失败。故障通知也可以用作端到端恢复中的触发器。
An unintended connection occurs when traffic from the wrong source is delivered to a receiver. This MUST be prevented during protection switching. This is primarily a concern when the protection link is being used to carry Extra Traffic. In this case, it MUST be ensured that the LSP traffic being switched from the (failed) working link to the protection link is not delivered to the receiver of the pre-empted traffic. Thus, in the message flow described above, the master node MUST disconnect (any) pre-empted traffic on the selected protection link before sending the Switchover Request. The slave node MUST also disconnect pre-empted traffic before sending the Switchover Response. In addition, the master node SHOULD start receiving traffic for the protected LSP from the protection link. Finally, the master node SHOULD start sending protected traffic on the protection link upon receipt of the Switchover Response.
当来自错误来源的通信量传送到接收器时，会发生意外连接。在保护切换期间必须防止这种情况。当保护链路用于承载额外流量时，这主要是一个问题。在这种情况下，必须确保从（故障）工作链路切换到保护链路的LSP业务不会被发送到抢占业务的接收器。因此，在上述消息流中，主节点必须在发送切换请求之前断开所选保护链路上的（任何）先占通信量。在发送切换响应之前，从属节点还必须断开抢占通信。此外，主节点应开始从保护链路接收受保护LSP的通信量。最后，主节点应在收到切换响应后开始在保护链路上发送受保护的通信量。
End-to-end path protection and restoration refer to the recovery of an entire LSP from the initiator to the terminator. Suppose the primary path of an LSP is routed from the initiator (Node A) to the terminator (Node B) through a set of intermediate nodes.
端到端路径保护和恢复是指将整个LSP从启动器恢复到终端。假设LSP的主路径通过一组中间节点从发起方（节点A）路由到终止方（节点B）。
The following subsections describe three previously proposed end-to-end protection schemes and the functional steps needed to implement them.
以下小节描述了之前提出的三种端到端保护方案以及实施这些方案所需的功能步骤。
A dedicated, resource-disjoint alternate path is pre-established to protect the LSP. Traffic is simultaneously sent on both paths and received from one of the functional paths by the end nodes A and B.
预先建立专用的、资源不相交的备用路径以保护LSP。通信量在两条路径上同时发送，并由终端节点A和B从其中一条功能路径接收。
There is no explicit signaling involved with this mode of protection.
这种保护模式没有明确的信号。
A dedicated, resource-disjoint alternate path is pre-established to protect the LSP. Traffic is simultaneously sent on both paths; under normal conditions, the traffic from the working path is received by nodes A and B (in the appropriate directions). A failure affecting the working path results in both A and B switching to the traffic on the protection path in the respective directions.
预先建立专用的、资源不相交的备用路径以保护LSP。在两条路径上同时发送通信量；在正常情况下，节点A和B（在适当的方向上）接收来自工作路径的通信量。影响工作路径的故障会导致A和B在各自方向上切换到保护路径上的流量。
Note that this requires coordination between the end nodes to switch to the protection path.
请注意，这需要终端节点之间的协调以切换到保护路径。
The basic steps in bi-directional 1+1 path protection are as follows:
双向1+1路径保护的基本步骤如下：
o Failure detection: There are two possibilities for this.
o 故障检测：有两种可能性。
1. A node in the working path detects a failure event. Such a node MUST send a Failure Indication message toward the upstream or/and downstream end node of the LSP (node A or B). This message MAY be forwarded along the working path or routed over a different path if the network has general routing intelligence.
1. 工作路径中的节点检测到故障事件。这样的节点必须向LSP的上游或/和下游端节点（节点a或B）发送故障指示消息。如果网络具有通用路由智能，则该消息可沿工作路径转发或通过不同路径路由。
Mechanisms provided by the data transport plane MAY also be used for this, if available.
如果可用，数据传输平面提供的机制也可用于此目的。
2. The end nodes (A or B) detect the failure themselves (e.g., loss of signal).
2. 终端节点（A或B）自身检测故障（例如，信号丢失）。
o Switchover: The action taken when an end node detects a failure in the working path is as follows: Start receiving from the protection path; at the same time, send a Switchover Request message to the other end node to enable switching at the other end.
o 切换：当终端节点在工作路径中检测到故障时所采取的操作如下：开始从保护路径接收；同时，向另一端节点发送切换请求消息，以启用另一端的切换。
The action taken when an end node receives a Switchover Request message is as follows:
终端节点收到切换请求消息时采取的操作如下：
- Start receiving from the protection path; at the same time, send a Switchover Response message to the other end node.
- 从保护路径开始接收；同时，向另一端节点发送切换响应消息。
GMPLS signaling mechanisms MAY be used to (reliably) signal the Failure Indication message, as well as the Switchover Request and Response message. These messages MAY be forwarded along the protection path if no other routing intelligence is available in the network.
GMPLS信令机制可用于（可靠地）向故障指示消息以及切换请求和响应消息发送信号。如果网络中没有其他路由智能可用，则这些消息可以沿保护路径转发。
LSP Identifier: A unique identifier for each LSP. The LSP identifier is within the scope of the Source ID and Destination ID.
LSP标识符：每个LSP的唯一标识符。LSP标识符在源ID和目标ID的范围内。
Source ID: ID of the source (e.g., IP address).
源ID：源的ID（例如IP地址）。
Destination ID: ID of the destination (e.g., IP address).
目的地ID：目的地的ID（例如IP地址）。
Each node that is on the working or protection path of an LSP MUST have knowledge of the LSP identifier. If the network does not provide routing intelligence, nodal information MAY also include previous and next nodes in the LSP so that restoration-related messages can be forwarded properly. When the network provides general routing intelligence, messages MAY be forwarded along paths other than that of the LSP.
位于LSP的工作或保护路径上的每个节点都必须知道LSP标识符。如果网络不提供路由智能，节点信息还可以包括LSP中的前一个和下一个节点，以便可以正确地转发与恢复相关的消息。当网络提供一般路由智能时，消息可以沿着LSP以外的路径转发。
At the end-point nodes, the working and protection paths MUST be associated. The association of these paths MAY be either provisioned using signaling or MAY be configured when LSP provisioning does not involve signaling (e.g., provisioning through a management system). The related association information MUST remain until the LSP is explicitly de-provisioned.
在端点节点上，必须关联工作路径和保护路径。这些路径的关联可以使用信令进行配置，或者可以在LSP配置不涉及信令时进行配置（例如，通过管理系统进行配置）。相关关联信息必须保留，直到LSP被显式取消配置。
This message is sent (reliably) by an intermediate node toward the source of an LSP. For instance, such a node might have attempted local span protection and failed. This message MAY not be necessary if the data transport layer provides mechanisms for the notification of LSP failure by the endpoints (i.e., if LSP endpoints are co-located with a corresponding data (transport) maintenance/recovery domain).
该消息由中间节点（可靠地）发送到LSP的源。例如，这样的节点可能尝试了本地范围保护，但失败了。如果数据传输层提供端点通知LSP失败的机制（即，如果LSP端点与相应的数据（传输）维护/恢复域位于同一位置），则可能不需要此消息。
Consider a node that detects a link failure. The node MUST determine the identities of all LSPs that are affected by the failure of the link and send an End-to-End Failure Indication message to the source of each LSP. For scalability reasons, Failure Indication messages MAY contain the identity and the status of multiple LSPs rather than a single one. Each intermediate node receiving such a message MUST forward the message to the appropriate next node such that the message would ultimately reach the LSP source. However, there is no requirement that this message flows toward the source along the same path as the failed LSP. Furthermore, if an intermediate node is itself generating a Failure Indication message, there SHOULD be a mechanism to suppress all but one source of Failure Indication messages. Finally, the Failure Indication message MUST be sent reliably from the node detecting the failure to the LSP source. Reliability MAY be achieved, for example, by retransmitting the message until an acknowledgement is received. However, retransmission of Failure Indication messages SHOULD not cause further message drops. This MAY be achieved through the appropriate configuration and use of congestion and flow control mechanisms.
考虑一个检测链路故障的节点。节点必须确定受链路故障影响的所有LSP的标识，并向每个LSP的源发送端到端故障指示消息。出于可伸缩性原因，故障指示消息可能包含多个LSP的标识和状态，而不是单个LSP。接收此类消息的每个中间节点必须将消息转发到适当的下一个节点，以便消息最终到达LSP源。但是，不要求此消息沿着与故障LSP相同的路径流向源。此外，如果中间节点本身正在生成故障指示消息，则应该有一种机制来抑制除一个故障指示消息源之外的所有故障指示消息源。最后，故障指示消息必须从检测故障的节点可靠地发送到LSP源。例如，可以通过重新传输消息直到接收到确认来实现可靠性。但是，故障指示消息的重新传输不应导致进一步的消息丢失。这可以通过适当配置和使用拥塞和流量控制机制来实现。
This message is sent by the source node to acknowledge the receipt of an End-to-End Failure Indication message. This message is sent to the originator of the Failure Indication message. The Acknowledge message SHOULD be sent for each Failure Indication Message received. Each intermediate node receiving the Failure Acknowledgement message MUST forward it toward the destination of the message. However, there is no requirement that this message flows toward the destination along the same path as the failed LSP.
此消息由源节点发送，以确认接收到端到端故障指示消息。此消息发送给故障指示消息的发起人。应为收到的每个故障指示消息发送确认消息。接收故障确认消息的每个中间节点必须将其转发到消息的目的地。但是，不要求此消息沿着与故障LSP相同的路径流向目标。
This message MAY not be required if other means of ensuring reliable message delivery are used.
如果使用了其他确保可靠消息传递的方法，则可能不需要此消息。
This message is generated by the source node receiving an indication of failure in an LSP. It is sent to the LSP destination, and it carries the identifier of the LSP being restored. The End-to-End Switchover Request message MUST be sent reliably from the source to the destination of the LSP.
此消息由接收LSP中故障指示的源节点生成。它被发送到LSP目的地，并携带正在恢复的LSP的标识符。端到端切换请求消息必须从LSP的源可靠地发送到目标。
This message is sent by the destination node receiving an End-to-End Switchover Request message toward the source of the LSP. This message SHOULD identify the LSP being switched over. This message MUST be transmitted in response to each End-to-End Switchover Request message received and MAY indicate either a positive or negative outcome.
该消息由接收端到端切换请求消息的目标节点向LSP的源发送。此消息应标识正在切换的LSP。必须发送此消息，以响应接收到的每个端到端切换请求消息，并可能指示正面或负面结果。
Shared mesh restoration refers to schemes under which protection paths for multiple LSPs share common link and node resources. Under these schemes, the protection capacity is pre-reserved, i.e., link capacity is allocated to protect one or more LSPs, but explicit action is required to instantiate a specific protection LSP. This requires restoration signaling along the protection path. Typically, the protection capacity is shared only amongst LSPs whose working paths are physically diverse. This criterion can be enforced when provisioning the protection path. Specifically, provisioning-related signaling messages may carry information about the working path to nodes along the protection path. This can be used as call admission control to accept/reject connections along the protection path based on the identification of the resources used for the primary path.
共享网格恢复是指多个LSP的保护路径共享公共链路和节点资源的方案。在这些方案下，保护容量是预先保留的，即，分配链路容量以保护一个或多个LSP，但需要显式操作来实例化特定的保护LSP。这需要沿保护路径发送恢复信令。通常，保护容量仅在工作路径物理上不同的LSP之间共享。在设置保护路径时，可以强制执行此标准。具体地，供应相关的信令消息可以携带关于沿保护路径到节点的工作路径的信息。这可以用作呼叫允许控制，以基于用于主路径的资源的标识来接受/拒绝沿保护路径的连接。
Thus, shared mesh restoration is designed to protect an LSP after a single failure event, i.e., a failure that affects the working path of at most one LSP sharing the protection capacity. It is possible that a protection path may not be successfully activated when multiple, concurrent failure events occur. In this case, shared mesh restoration capacity may be claimed for more than one failed LSP and the protection path can be activated only for one of them (at most).
因此，共享网格恢复设计用于在单个故障事件后保护LSP，即影响最多一个共享保护容量的LSP的工作路径的故障。当发生多个并发故障事件时，可能无法成功激活保护路径。在这种情况下，可以为多个发生故障的LSP申请共享网格恢复容量，并且只能为其中一个（最多）激活保护路径。
For implementing shared mesh restoration, the identifier and nodal information related to signaling along the control path are as defined for 1+1 protection in Sections 3.2.1 and 3.2.2. In addition, each node MUST also keep (local) information needed to establish the data plane of the protection path. This information MUST indicate the local resources to be allocated, the fabric cross-connect to be established to activate the path, etc. The precise nature of this information would depend on the type of node and LSP (the GMPLS signaling document describes different type of switches [RFC3471]). It would also depend on whether the information is fine or coarse-grained. For example, fine-grained information would indicate pre-selection of all details pertaining to protection path activation, such as outgoing link, labels, etc. Coarse-grained information, on the other hand, would allow some details to be determined during protection path activation. For example, protection resources may be pre-selected at the level of a TE link, while the selection of the specific component link and label occurs during protection path activation.
为了实现共享网格恢复，与控制路径上的信令相关的标识符和节点信息如第3.2.1节和第3.2.2节中针对1+1保护所定义。除此之外，每个节点还必须建立本地路径来保护数据。该信息必须指明要分配的本地资源、要建立的用于激活路径的结构交叉连接等。该信息的确切性质取决于节点和LSP的类型（GMPLS信令文档描述了不同类型的交换机[RFC3471]）。这还取决于信息是细粒度还是粗粒度。例如，细粒度信息将指示预选与保护路径激活有关的所有细节，例如传出链接、标签等。另一方面，粗粒度信息将允许在保护路径激活期间确定一些细节。例如，保护资源可以在TE链路级别预先选择，而特定组件链路和标签的选择发生在保护路径激活期间。
While the coarser specification allows some flexibility in the selection of the precise resource to activate, it also adds complexity in decision making and signaling during the time-critical restoration phase. Furthermore, the procedures for the assignment of bandwidth to protection paths MUST take into account the total resources in a TE link so that single-failure survivability requirements are satisfied.
虽然粗糙的规范允许在选择要激活的精确资源时具有一定的灵活性，但它也增加了时间关键恢复阶段的决策和信令的复杂性。此外，为保护路径分配带宽的程序必须考虑TE链路中的总资源，以便满足单故障生存性要求。
The End-to-End failure indication and acknowledgement procedures and messages are as defined in Sections 3.2.3 and 3.2.4.
端到端故障指示和确认程序及信息如第3.2.3节和第3.2.4节所述。
This message is generated by the source node receiving an indication of failure in an LSP. It is sent to the LSP destination along the protection path, and it identifies the LSP being restored. If any intermediate node is unable to establish cross-connects for the protection path, then it is desirable that no other node in the path
此消息由接收LSP中故障指示的源节点生成。它沿保护路径发送到LSP目标，并标识正在恢复的LSP。如果任何中间节点无法为保护路径建立交叉连接，则希望路径中没有其他节点
establishes cross-connects for the path. This would allow shared mesh restoration paths to be efficiently utilized.
为路径建立交叉连接。这将允许有效利用共享网格恢复路径。
The End-to-End Switchover message MUST be sent reliably from the source to the destination of the LSP along the protection path.
端到端切换消息必须沿着保护路径从源可靠地发送到LSP的目标。
This message is sent by the destination node receiving an End-to-End Switchover Request message toward the source of the LSP, along the protection path. This message SHOULD identify the LSP that is being switched over. Prior to activating the secondary bandwidth at each hop along the path, Extra Traffic (if used) MUST be dropped and not forwarded.
该消息由接收端到端切换请求消息的目标节点沿保护路径向LSP源发送。此消息应标识正在切换的LSP。在沿路径的每个跃点激活辅助带宽之前，必须丢弃额外流量（如果使用），而不是转发。
This message MUST be transmitted in response to each End-to-End Switchover Request message received.
必须发送此消息以响应接收到的每个端到端切换请求消息。
Reversion refers to the process of moving an LSP back to the original working path after a failure is cleared and the path is repaired. Reversion applies both to local span and end-to-end path-protected LSPs. Reversion is desired for the following reasons. First, the protection path may not be optimal in comparison to the working path from a routing and resource consumption point of view. Second, moving an LSP to its working path allows the protection resources to be used to protect other LSPs. Reversion has the disadvantage of causing a second service disruption. Use of reversion is at the option of the operator. Reversion implies that a working path remains allocated to the LSP that was originally routed over it, even after a failure. It is important to have mechanisms that allow reversion to be performed with minimal service disruption to the customer. This can be achieved using a "bridge-and-switch" approach (often referred to as make-before-break).
恢复是指在清除故障并修复路径后，将LSP移回原始工作路径的过程。反转同时适用于本地范围和端到端路径保护的LSP。出于以下原因，需要恢复。首先，从路由和资源消耗的角度来看，与工作路径相比，保护路径可能不是最优的。其次，将LSP移动到其工作路径允许使用保护资源来保护其他LSP。恢复的缺点是会导致第二次服务中断。操作员可选择使用反转。恢复意味着即使在发生故障后，工作路径仍然分配给最初在其上路由的LSP。重要的是要有一种机制，允许在对客户的服务中断最小的情况下执行恢复。这可以通过“桥和开关”方法（通常称为先通后断）实现。
The basic steps involved in bridge-and-switch are as follows:
桥接和切换涉及的基本步骤如下：
1. The source node commences the process by "bridging" the normal traffic onto both the working and the protection paths (or links in the case of span protection).
1. 源节点通过将正常通信量“桥接”到工作路径和保护路径（或跨度保护情况下的链路）开始该过程。
2. Once the bridging process is complete, the source node sends a Bridge and Switch Request message to the destination, identifying the LSP and other information necessary to perform reversion. Upon receipt of this message, the destination
2. 桥接过程完成后，源节点向目的地发送桥接和交换机请求消息，标识LSP和执行恢复所需的其他信息。收到此消息后，目标
selects the traffic from the working path. At the same time, it bridges the transmitted traffic onto both the working and protection paths.
从工作路径中选择流量。同时，它将传输的流量桥接到工作路径和保护路径上。
3. The destination then sends a Bridge and Switch Response message to the source confirming the completion of the operation.
3. 然后，目标向源发送网桥和交换机响应消息，确认操作完成。
4. When the source receives this message, it switches to receive from the working path, and stops transmitting traffic on the protection path. The source then sends a Bridge and Switch Completed message to the destination confirming that the LSP has been reverted.
4. 当源收到此消息时，它将切换到从工作路径接收，并停止在保护路径上传输流量。然后，源向目标发送桥接和交换机完成消息，确认LSP已恢复。
5. Upon receipt of this message, the destination stops transmitting along the protection path and de-activates the LSP along this path. The de-activation procedure should remove the crossed connections along the protection path (and frees the resources to be used for restoring other failures).
5. 收到此消息后，目的地停止沿保护路径传输，并沿此路径停用LSP。解除激活过程应删除沿保护路径的交叉连接（并释放用于恢复其他故障的资源）。
Administrative procedures other than reversion include the ability to force a switchover (from working to protection or vice versa) and locking out switchover, i.e., preventing an LSP from moving from working to protection administratively. These administrative conditions have to be supported by signaling.
除恢复以外的管理程序包括强制切换（从工作切换到保护，反之亦然）和锁定切换的能力，即防止LSP从工作切换到保护。这些管理条件必须有信号支持。
Under span protection, a failure event could affect more than one working link and there could be fewer protection links than the number of failed working links. Furthermore, a working link may contain multiple LSPs of varying priority. Under this scenario, a decision must be made as to which working links (and therefore LSPs) should be protected. This decision MAY be based on LSP priorities.
在span保护下，故障事件可能影响多个工作链路，并且保护链路可能少于故障工作链路的数量。此外，工作链路可包含具有不同优先级的多个lsp。在这种情况下，必须决定应该保护哪些工作链路（因此也包括LSP）。该决定可能基于LSP优先级。
In general, a node might detect failures sequentially, i.e., all failed working links may not be detected simultaneously, but only sequentially. In this case, as per the proposed signaling procedures, LSPs on a working link MAY be switched over to a given protection link, but another failure (of a working link carrying higher priority LSPs) may be detected soon afterward. In this case, the new LSPs may bump the ones previously switched over the protection link.
通常，节点可能会按顺序检测故障，即，可能不会同时检测到所有故障工作链路，而只能按顺序检测。在这种情况下，根据所提议的信令过程，工作链路上的lsp可以切换到给定的保护链路，但是（承载更高优先级lsp的工作链路的）另一故障可能随后很快被检测到。在这种情况下，新的LSP可能会碰撞先前通过保护链路切换的LSP。
In the case of end-to-end shared mesh restoration, priorities MAY be implemented for allocating shared link resources under multiple failure scenarios. As described in Section 3.3, more than one LSP
在端到端共享网格恢复的情况下，可以实现优先级，以便在多个故障场景下分配共享链路资源。如第3.3节所述，不止一个LSP
can claim shared resources under multiple failure scenarios. If such resources are first allocated to a lower-priority LSP, they MAY have to be reclaimed and allocated to a higher-priority LSP.
可以在多个故障场景下声明共享资源。如果这些资源首先分配给较低优先级的LSP，那么它们可能必须被回收并分配给较高优先级的LSP。
There are a number of security threats that MAY be experienced due to the exchange of messages and information, as detailed in this document. Some examples include interception, spoofing, modification, and replay of control messages. Therefore, the following security requirements are applicable to the mechanisms of this document.
如本文档所述，由于消息和信息的交换，可能会遇到许多安全威胁。一些示例包括拦截、欺骗、修改和重播控制消息。因此，以下安全要求适用于本文件的机制。
o Signaling MUST be able to provide authentication, integrity, and protection against replay attacks.
o 信令必须能够提供身份验证、完整性和防止重播攻击的保护。
o Privacy and confidentiality are not required. Only authentication is required to ensure that the signaling messages are originating from the right place and have not been modified in transit.
o 不需要隐私和保密。只需要进行身份验证，以确保信令消息来自正确的位置，并且在传输过程中未被修改。
o Protection of the identity of the data plane end-points (in Failure Indication messages) is not required
o 不需要保护数据平面端点的标识（在故障指示消息中）
The consequences of poorly secured protection may increase the risk of triggering recovery actions under false Failure Indication messages, including LSP identifiers that are not under failure. Such information could subsequently trigger the initiation of "false" recovery actions while there are no reasons to do so. Additionally, if the identification of the LSP is tampered with from a Failure Indication message, recovery actions will involve nodes for which the LSPs do not indicate any failure condition or for which no Failure Indication message has been received. The consequences of such actions is unpredictable and MAY lead to de-synchronisation between the control and the data plane, as well as increase the risk of misconnections. Moreover, the consequences of poorly applied protection may increase the risk of misconnection. In particular, when Extra Traffic is involved, it is easily possible to deliver the wrong traffic to the wrong destination. Similarly, an intrusion that sets up what appears to be a valid protection LSP and then causes a fault may be able to divert traffic.
安全性差的保护的后果可能会增加在错误故障指示消息（包括未发生故障的LSP标识符）下触发恢复操作的风险。此类信息可能会在没有理由的情况下引发“虚假”恢复行动。此外，如果从故障指示消息篡改LSP的标识，则恢复操作将涉及LSP未指示任何故障条件或未接收到故障指示消息的节点。此类操作的后果是不可预测的，可能导致控件和数据平面之间的不同步，并增加错误连接的风险。此外，保护应用不当的后果可能会增加错误连接的风险。特别是，当涉及额外流量时，很容易将错误的流量传递到错误的目的地。类似地，设置看似有效的保护LSP然后导致故障的入侵可能会转移流量。
Moreover, tampering with a routing information exchange may also have an effect on traffic engineering. Therefore, any mechanisms used for securing and authenticating the transmission of routing information SHOULD be applied in the present context.
此外，篡改路由信息交换也可能对流量工程产生影响。因此，用于保护和认证路由信息传输的任何机制都应该应用于本上下文中。
This document was the product of many individuals working together in the CCAMP WG Protection and Restoration design team. The following are the authors that contributed to this document:
本文件是CCAMP WG保护和修复设计团队中许多人共同工作的成果。以下是对本文件作出贡献的作者：
Deborah Brungard (AT&T) 200 S. Laurel Ave. Middletown, NJ 07748, USA
Deborah Brungard（美国电话电报公司）美国新泽西州米德尔敦S.Laurel大道200号，邮编07748
EMail: dbrungard@att.com
EMail: dbrungard@att.com
Sudheer Dharanikota
苏德尔·达兰尼科塔
EMail: sudheer@ieee.org
EMail: sudheer@ieee.org
Jonathan P. Lang (Sonos) 223 East De La Guerra Street Santa Barbara, CA 93101, USA
乔纳森·P·朗（索诺斯）美国加利福尼亚州圣巴巴拉东德拉格拉街223号，邮编93101
EMail: jplang@ieee.org
EMail: jplang@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA
美国新泽西州弗罗勒姆公园公园公园大道180号广志里（AT&T）07932
EMail: gli@research.att.com
EMail: gli@research.att.com
Eric Mannie
埃里克·曼尼
EMail: eric_mannie@hotmail.com
EMail: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou（阿尔卡特）Francis Welleslein，1 B-2018比利时安特卫普
EMail: dimitri.papadimitriou@alcatel.be
EMail: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
巴拉·拉贾戈帕兰微软印度发展中心，印度海得拉巴
EMail: balar@microsoft.com
EMail: balar@microsoft.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
亚科夫·雷克特（Juniper）美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[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月。
[RFC4205] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的中间系统到中间系统（IS-IS）扩展”，RFC 4205，2005年10月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年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月。
Editors' Addresses
编辑地址
Jonathan P. Lang Sonos, Inc. 223 East De La Guerra Street Santa Barbara, CA 93101
Jonathan P.Lang Sonos，Inc.加利福尼亚州圣巴巴拉东德拉格拉街223号，邮编93101
EMail: jplang@ieee.org
EMail: jplang@ieee.org
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
巴拉·拉贾戈帕兰微软印度发展中心，印度海得拉巴
Ph: +91-40-5502-7423
EMail: balar@microsoft.com
Ph: +91-40-5502-7423
EMail: balar@microsoft.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
迪米特里·帕帕迪米特里奥·阿尔卡特·弗朗西斯·韦勒斯普林，1 B-2018比利时安特卫普
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。