Internet Engineering Task Force (IETF) X. Zhang
Request for Comments: 8131 H. Zheng, Ed.
Category: Informational Huawei Technologies
ISSN: 2070-1721 R. Gandhi, Ed.
Z. Ali
Cisco Systems, Inc.
P. Brzozowski
ADVA Optical
March 2017
Internet Engineering Task Force (IETF) X. Zhang
Request for Comments: 8131 H. Zheng, Ed.
Category: Informational Huawei Technologies
ISSN: 2070-1721 R. Gandhi, Ed.
Z. Ali
Cisco Systems, Inc.
P. Brzozowski
ADVA Optical
March 2017
RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing
用于端到端GMPLS恢复和资源共享的RSVP-TE信令过程
Abstract
摘要
In non-packet transport networks, there are requirements where the Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.
在非分组传输网络中，存在通用多协议标签交换（GMPLS）端到端恢复方案需要采用恢复标签交换路径（LSP）的要求，同时在故障发生后保留用于工作和/或保护LSP的资源。
This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.
本文档回顾了在使用恢复LSP时，如何在GMPLS端到端恢复方案的上下文中使用资源预留协议-流量工程（RSVP-TE）信令来提供LSP关联，其中失败的LSP不会被拆除。此外，本文档还讨论了基于资源共享的LSP设置和拆卸以及LSP恢复过程。本文件未定义任何新的信令扩展，且本质上是严格的信息性扩展。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8131.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8131.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
2.1. Terminology ................................................4
2.2. Abbreviations ..............................................4
3. Overview ........................................................4
3.1. Examples of Restoration Schemes ............................5
3.1.1. 1+R Restoration .....................................5
3.1.2. 1+1+R Restoration ...................................6
3.1.2.1. 1+1+R Restoration - Variants ...............7
3.2. Resource Sharing by Restoration LSP ........................7
4. RSVP-TE Signaling Procedure .....................................8
4.1. Restoration LSP Association ................................8
4.2. Resource Sharing-Based Restoration LSP Setup ...............8
4.3. LSP Reversion .............................................10
4.3.1. Make-While-Break Reversion .........................10
4.3.2. Make-Before-Break Reversion ........................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................13
Acknowledgements .................................................14
Contributors ......................................................14
Authors' Addresses ................................................15
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
2.1. Terminology ................................................4
2.2. Abbreviations ..............................................4
3. Overview ........................................................4
3.1. Examples of Restoration Schemes ............................5
3.1.1. 1+R Restoration .....................................5
3.1.2. 1+1+R Restoration ...................................6
3.1.2.1. 1+1+R Restoration - Variants ...............7
3.2. Resource Sharing by Restoration LSP ........................7
4. RSVP-TE Signaling Procedure .....................................8
4.1. Restoration LSP Association ................................8
4.2. Resource Sharing-Based Restoration LSP Setup ...............8
4.3. LSP Reversion .............................................10
4.3.1. Make-While-Break Reversion .........................10
4.3.2. Make-Before-Break Reversion ........................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................13
Acknowledgements .................................................14
Contributors ......................................................14
Authors' Addresses ................................................15
Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] defines a set of protocols, including Open Shortest Path First - Traffic Engineering (OSPF-TE) [RFC4203] and Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used to set up Label Switched Paths (LSPs) in non-packet transport networks. The GMPLS protocol extends MPLS to support interfaces capable of Time Division Multiplexing (TDM), Lambda Switching and Fiber Switching. These switching technologies provide several protection schemes [RFC4426] [RFC4427] (e.g., 1+1, 1:N, and M:N).
广义多协议标签交换（GMPLS）[RFC3945]定义了一组协议，包括开放最短路径优先-流量工程（OSPF-TE）[RFC4203]和资源预留协议-流量工程（RSVP-TE）[RFC3473]。这些协议可用于在非分组传输网络中建立标签交换路径（LSP）。GMPLS协议扩展了MPLS，以支持能够进行时分复用（TDM）、Lambda交换和光纤交换的接口。这些交换技术提供了几种保护方案[RFC4426][RFC4427]（例如，1+1、1:N和M:N）。
RSVP-TE signaling has been extended to support various GMPLS recovery schemes, such as end-to-end recovery [RFC4872] and segment recovery [RFC4873]. As described in [RFC6689], an ASSOCIATION object with Association Type "Recovery" [RFC4872] can be signaled in the RSVP Path message to identify the LSPs for restoration. Also, an ASSOCIATION object with Association Type "Resource Sharing" [RFC4873] can be signaled in the RSVP Path message to identify the LSPs for resource sharing. Section 2.2 of [RFC6689] reviews the procedure for providing LSP associations for GMPLS end-to-end recovery, and Section 2.4 of that document reviews the procedure for providing LSP associations for sharing resources.
RSVP-TE信令已经扩展到支持各种GMPLS恢复方案，例如端到端恢复[RFC4872]和段恢复[RFC4873]。如[RFC6689]所述，可以在RSVP Path消息中用信号通知关联类型为“Recovery”[RFC4872]的关联对象，以识别要恢复的LSP。此外，具有关联类型“资源共享”[RFC4873]的关联对象可以在RSVP Path消息中发出信号，以标识用于资源共享的LSP。[RFC6689]第2.2节审查了为GMPLS端到端恢复提供LSP关联的程序，该文件第2.4节审查了为共享资源提供LSP关联的程序。
Generally, GMPLS end-to-end recovery schemes have the restoration LSP set up after the failure has been detected and notified on the working LSP. For a recovery scheme with revertive behavior, a restoration LSP is set up while the working LSP and/or protecting LSP are not torn down in the control plane due to a failure. In non-packet transport networks, because working LSPs are typically set up over preferred paths, service providers would like to keep resources associated with the working LSPs reserved. This is to make sure that the service can be reverted to the preferred path (working LSP) when the failure is repaired to provide deterministic behavior and a guaranteed Service Level Agreement (SLA).
一般来说，GMPLS端到端恢复方案在检测到故障并在工作LSP上通知后设置恢复LSP。对于具有恢复行为的恢复方案，当工作LSP和/或保护LSP未因故障而在控制平面中拆除时，设置恢复LSP。在非分组传输网络中，由于工作LSP通常在首选路径上设置，服务提供商希望保留和工作LSP相关的资源。这是为了确保在修复故障时，服务可以恢复到首选路径（工作LSP），以提供确定性行为和有保证的服务级别协议（SLA）。
In this document, we review procedures for GMPLS LSP associations, resource-sharing-based LSP setup, teardown, and LSP reversion for non-packet transport networks, including the following:
在本文档中，我们回顾了非分组传输网络的GMPLS LSP关联、基于资源共享的LSP设置、拆卸和LSP恢复的程序，包括以下内容：
o The procedure for providing LSP associations for the GMPLS end-to-end recovery using restoration LSP where working and protecting LSPs are not torn down and resources are kept reserved in the network after the failure.
o 使用恢复LSP为GMPLS端到端恢复提供LSP关联的过程，在该过程中，工作和保护LSP不会中断，并且故障后资源保留在网络中。
o The procedure for resource sharing using the Shared Explicit (SE) flag in conjunction with an ASSOCIATION object. In [RFC3209], the Make-Before-Break (MBB) method assumes the old and new LSPs share
o 将共享显式（SE）标志与关联对象结合使用的资源共享过程。在[RFC3209]中，先通后断（MBB）方法假定旧LSP和新LSP共享
the SESSION object and signal SE flag in the SESSION_ATTRIBUTE object for sharing resources. According to [RFC6689], an ASSOCIATION object with Association Type "Resource Sharing" in the Path message enables the sharing of resources across LSPs with different SESSION objects.
用于共享资源的SESSION_属性对象中的SESSION对象和signal SE标志。根据[RFC6689]，Path消息中关联类型为“Resource Share”的关联对象允许通过不同会话对象跨LSP共享资源。
o The procedures for LSP reversion and resource sharing, when using end-to-end recovery scheme with revertive behavior.
o 当使用具有恢复行为的端到端恢复方案时，LSP恢复和资源共享的过程。
This document is strictly informative in nature and does not define any RSVP-TE signaling extensions.
本文件本质上是严格的信息性文件，未定义任何RSVP-TE信令扩展。
The reader is assumed to be familiar with the terminology in [RFC3209], [RFC3473], [RFC4872], and [RFC4873]. The terminology for GMPLS recovery is defined in [RFC4427].
假定读者熟悉[RFC3209]、[RFC3473]、[RFC4872]和[RFC4873]中的术语。[RFC4427]中定义了GMPLS恢复的术语。
GMPLS: Generalized Multiprotocol Label Switching
广义多协议标签交换
LSP: Label Switched Path
标签交换路径
MBB: Make-Before-Break
MBB：先做后休息
MPLS: Multiprotocol Label Switching
多协议标签交换
RSVP: Resource Reservation Protocol
资源预留协议
SE: Shared Explicit (flag)
SE：共享显式（标志）
TDM: Time Division Multiplexing
时分复用
TE: Traffic Engineering
交通工程
The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and discussed in this document, switches normal traffic to an alternate LSP that is not even partially established only after the working LSP failure occurs. The new alternate route is selected at the LSP head-end node, it may reuse resources of the failed LSP at intermediate nodes and may include additional intermediate nodes and/or links.
[RFC4872]中定义并在本文档中讨论的GMPLS端到端恢复方案将正常通信量切换到备用LSP，该备用LSP甚至在工作LSP故障发生后才部分建立。在LSP头端节点处选择新的备用路由，它可以在中间节点处重用失败的LSP的资源，并且可以包括额外的中间节点和/或链路。
Two forms of end-to-end recovery schemes, 1+R restoration and 1+1+R restoration, are described in the following sections. Other forms of end-to-end recovery schemes also exist, and they can use these signaling techniques.
以下各节介绍了两种形式的端到端恢复方案：1+R恢复和1+1+R恢复。还存在其他形式的端到端恢复方案，它们可以使用这些信令技术。
One example of the recovery scheme considered in this document is 1+R recovery. The 1+R recovery scheme is exemplified in Figure 1. In this example, a working LSP on path A-B-C-Z is pre-established. Typically, after a failure detection and notification on the working LSP, a second LSP on path A-H-I-J-Z is established as a restoration LSP. Unlike a protecting LSP, which is set up before the failure, a restoration LSP is set up when needed, after the failure.
本文档中考虑的恢复方案的一个示例是1+R恢复。图1举例说明了1+R恢复方案。在此示例中，预先建立了路径a-B-C-Z上的工作LSP。通常，在工作LSP上进行故障检测和通知之后，路径a-H-I-J-Z上的第二个LSP被建立为恢复LSP。与故障前设置的保护LSP不同，恢复LSP是在故障后根据需要设置的。
+-----+ +-----+ +-----+ +-----+
| A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+
\ /
\ /
+--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J |
+-----+ +-----+ +-----+
+-----+ +-----+ +-----+ +-----+
| A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+
\ /
\ /
+--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J |
+-----+ +-----+ +-----+
Figure 1: An Example of 1+R Recovery Scheme
图1:1+R恢复方案示例
During failure switchover with 1+R recovery scheme, in general, working LSP resources are not released so that working and restoration LSPs coexist in the network. Nonetheless, working and restoration LSPs can share network resources. Typically, when the failure has recovered on the working LSP, the restoration LSP is no longer required and is torn down while the traffic is reverted to the original working LSP.
在使用1+R恢复方案进行故障切换期间，通常不会释放工作LSP资源，因此工作LSP和恢复LSP在网络中共存。尽管如此，工作和恢复LSP可以共享网络资源。通常，当故障已在工作LSP上恢复时，不再需要恢复LSP，并在业务恢复到原始工作LSP时将其拆除。
Another example of the recovery scheme considered in this document is 1+1+R. In 1+1+R, a restoration LSP is set up for the working LSP and/or the protecting LSP after the failure has been detected; this recovery scheme is exemplified in Figure 2.
本文件中考虑的恢复方案的另一个示例是1+1+R。在1+1+R中，检测到故障后，为工作LSP和/或保护LSP设置恢复LSP；此恢复方案如图2所示。
+-----+ +-----+ +-----+
| D +-------+ E +--------+ F |
+--+--+ +-----+ +--+--+
/ \
/ \
+--+--+ +-----+ +-----+ +--+--+
| A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+
\ /
\ /
+--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J |
+-----+ +-----+ +-----+
+-----+ +-----+ +-----+
| D +-------+ E +--------+ F |
+--+--+ +-----+ +--+--+
/ \
/ \
+--+--+ +-----+ +-----+ +--+--+
| A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+
\ /
\ /
+--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J |
+-----+ +-----+ +-----+
Figure 2: An Example of 1+1+R Recovery Scheme
Figure 2: An Example of 1+1+R Recovery Scheme
In this example, a working LSP on path A-B-C-Z and a protecting LSP on path A-D-E-F-Z are pre-established. After a failure detection and notification on the working LSP or protecting LSP, a third LSP on path A-H-I-J-Z is established as a restoration LSP. The restoration LSP, in this case, provides protection against failure of both the working and protecting LSPs. During failure switchover with the 1+1+R recovery scheme, in general, failed LSP resources are not released so that working, protecting, and restoration LSPs coexist in the network. The restoration LSP can share network resources with the working LSP, and it can share network resources with the protecting LSP. Typically, the restoration LSP is torn down when the traffic is reverted to the original LSP and is no longer needed.
在此示例中，预先建立了路径a-B-C-Z上的工作LSP和路径a-D-E-F-Z上的保护LSP。在工作LSP或保护LSP上进行故障检测和通知后，路径a-H-I-J-Z上的第三个LSP被建立为恢复LSP。在这种情况下，恢复LSP为工作LSP和保护LSP的故障提供保护。在使用1+1+R恢复方案进行故障切换期间，通常不会释放故障LSP资源，因此工作、保护和恢复LSP在网络中共存。恢复LSP可以与工作LSP共享网络资源，也可以与保护LSP共享网络资源。通常，当业务恢复到原始LSP且不再需要时，恢复LSP被拆除。
There are two possible models when using a restoration LSP with 1+1+R recovery scheme:
使用带有1+1+R恢复方案的恢复LSP时，有两种可能的模式：
o A restoration LSP is set up after either a working or a protecting LSP fails. Only one restoration LSP is present at a time.
o 恢复LSP在工作或保护LSP失败后设置。一次仅存在一个恢复LSP。
o A restoration LSP is set up after both the working and protecting LSPs fail. Only one restoration LSP is present at a time.
o 在工作LSP和保护LSP都失败后，将建立恢复LSP。一次仅存在一个恢复LSP。
Two other possible variants exist when using a restoration LSP with 1+1+R recovery scheme:
使用带有1+1+R恢复方案的恢复LSP时，还存在两种可能的变体：
o A restoration LSP is set up after either a working or protecting LSP fails. Two different restoration LSPs may be present, one for the working LSP and one for the protecting LSP.
o 恢复LSP在工作或保护LSP失败后设置。可能存在两个不同的恢复LSP，一个用于工作LSP，另一个用于保护LSP。
o Two different restoration LSPs are set up after both working and protecting LSPs fail, one for the working LSP and one for the protecting LSP.
o 在工作LSP和保护LSP均失败后，将设置两个不同的恢复LSP，一个用于工作LSP，另一个用于保护LSP。
In all these models, if a restoration LSP also fails, it is torn down and a new restoration LSP is set up.
在所有这些模型中，如果恢复LSP也出现故障，则会将其拆下并设置新的恢复LSP。
+-----+ +-----+
| F +------+ G +--------+
+--+--+ +-----+ |
| |
| |
+-----+ +-----+ +--+--+ +-----+ +--+--+
| A +----+ B +-----+ C +--X---+ D +-----+ E |
+-----+ +-----+ +-----+ +-----+ +-----+
+-----+ +-----+
| F +------+ G +--------+
+--+--+ +-----+ |
| |
| |
+-----+ +-----+ +--+--+ +-----+ +--+--+
| A +----+ B +-----+ C +--X---+ D +-----+ E |
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 3: Resource Sharing in 1+R Recovery Scheme
图3:1+R恢复方案中的资源共享
Using the network shown in Figure 3 as an example using 1+R recovery scheme, LSP1 (A-B-C-D-E) is the working LSP; assume it allows for resource sharing when the LSP traffic is dynamically restored. Upon detecting the failure of a link along the LSP1, e.g., Link C-D, node A needs to decide which alternative path it will use to signal restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is chosen as the restoration LSP path, and the resources on the path segment A-B-C are reused by this LSP. The working LSP is not torn down and coexists with the restoration LSP. When the head-end node A signals the restoration LSP, nodes C, F, G, and E reconfigure the resources (as listed in Table 1 of this document) to set up the LSP by sending cross-connection command to the data plane.
以图3所示的网络为例，使用1+R恢复方案，LSP1（A-B-C-D-E）是工作LSP；假设它允许在动态恢复LSP流量时共享资源。在检测到沿着LSP1的链路（例如链路C-D）的故障时，节点a需要决定它将使用哪个替代路径来信号恢复LSP和重新路由业务。在这种情况下，选择A-B-C-F-G-E作为恢复LSP路径，并且路径段A-B-C上的资源被该LSP重用。工作LSP不会被拆除，而是与恢复LSP共存。当前端节点A向恢复LSP发送信号时，节点C、F、G和E通过向数据平面发送交叉连接命令来重新配置资源（如本文档表1所列）以设置LSP。
In the recovery scheme employing revertive behavior, after the failure is repaired, the resources on nodes C and E need to be reconfigured to set up the working LSP (using a procedure described in Section 4.3 of this document) by sending cross-connection command to the data plane. The traffic is then reverted back to the original working LSP.
在采用回复行为的恢复方案中，故障修复后，需要重新配置节点C和E上的资源，通过向数据平面发送交叉连接命令来设置工作LSP（使用本文档第4.3节中描述的过程）。然后，通信量恢复为原始工作LSP。
Where GMPLS end-to-end recovery scheme needs to employ a restoration LSP while keeping resources for the working and/or protecting LSPs reserved in the network after the failure, the restoration LSP is set up with an ASSOCIATION object that has the Association Type set to "Recovery" [RFC4872], the Association ID and the Association Source set to the corresponding Association ID and the Association Source signaled in the Path message of the LSP it is restoring. For example, when a restoration LSP is signaled for a failed working LSP, the ASSOCIATION object in the Path message of the restoration LSP contains the Association ID and Association Source set to the Association ID and Association Source signaled in the working LSP for the "Recovery" Association Type. Similarly, when a restoration LSP is set up for a failed protecting LSP, the ASSOCIATION object in the Path message of the restoration LSP contains the Association ID and Association Source is set to the Association ID and Association Source signaled in the protecting LSP for the "Recovery" Association Type.
如果GMPLS端到端恢复方案需要使用恢复LSP，同时保留故障后网络中保留的用于工作和/或保护LSP的资源，则使用关联类型设置为“恢复”[RFC4872]的关联对象设置恢复LSP，关联ID和关联源设置为相应的关联ID，并且关联源在正在恢复的LSP的路径消息中发出信号。例如，当为故障工作LSP发送恢复LSP信号时，恢复LSP路径消息中的关联对象包含关联ID和关联源，该关联ID和关联源设置为工作LSP中为“恢复”关联类型发送的关联ID和关联源。类似地，当为失败的保护LSP设置恢复LSP时，恢复LSP的路径消息中的关联对象包含关联ID，关联源被设置为保护LSP中针对“恢复”关联类型发出信号的关联ID和关联源。
The procedure for signaling the PROTECTION object is specified in [RFC4872]. Specifically, the restoration LSP used for a working LSP is set up with the P bit cleared in the PROTECTION object in the Path message of the restoration LSP and the restoration LSP used for a protecting LSP is set up with the P bit set in the PROTECTION object in the Path message of the restoration LSP.
[RFC4872]中规定了向保护对象发送信号的程序。具体地，使用恢复LSP的路径消息中的保护对象中清除的P位设置用于工作LSP的恢复LSP，并且使用恢复LSP的路径消息中的保护对象中设置的P位设置用于保护LSP的恢复LSP。
GMPLS LSPs can share resources during LSP setup if they have the Shared Explicit (SE) flag set in the SESSION_ATTRIBUTE objects [RFC3209] in the Path messages that create them and:
如果GMPLS LSP在创建它们的路径消息中的会话_属性对象[RFC3209]中设置了共享显式（SE）标志，则它们可以在LSP设置期间共享资源，并且：
o As defined in [RFC3209], LSPs have identical SESSION objects, and/or
o 如[RFC3209]中所定义，LSP具有相同的会话对象，和/或
o As defined in [RFC6689], LSPs have matching ASSOCIATION objects with the Association Type set to "Resource Sharing" signaled in their Path messages. In this case, LSPs can have different SESSION objects i.e., a different Tunnel ID, Source and/or Destination signaled in their Path messages.
o 如[RFC6689]中所定义，LSP具有匹配的关联对象，其关联类型设置为“资源共享”，并在其路径消息中发出信号。在这种情况下，LSP可以具有不同的会话对象，即，在其路径消息中发出信号的不同隧道ID、源和/或目的地。
As described in Section 2.5 of [RFC3209], the purpose of make-before-break is not to disrupt traffic, or adversely impact network operations while TE tunnel rerouting is in progress. In non-packet transport networks, during the RSVP-TE signaling procedure, the nodes
如[RFC3209]第2.5节所述，在TE隧道重新路由过程中，先通后断的目的不是中断交通，或对网络运行产生不利影响。在非分组传输网络中，在RSVP-TE信令过程中，节点
set up cross-connections along the LSP accordingly. Because the cross-connection cannot simultaneously connect a shared resource to different resources in two alternative LSPs, nodes may not be able to fulfill this request when LSPs share resources.
相应地沿LSP设置交叉连接。由于交叉连接无法同时将共享资源连接到两个备选LSP中的不同资源，因此当LSP共享资源时，节点可能无法满足此请求。
For LSP restoration upon failure, as explained in Section 11 of [RFC4872], the reroute procedure may reuse existing resources. The action of the intermediate nodes during the rerouting process to reconfigure cross-connections does not further impact the traffic since it has been interrupted due to the already failed LSP.
对于故障时的LSP恢复，如[RFC4872]第11节所述，重路由程序可重用现有资源。中间节点在重新路由过程中重新配置交叉连接的操作不会进一步影响通信量，因为它已因已发生故障的LSP而中断。
The node actions for setting up the restoration LSP can be categorized into the following:
用于设置恢复LSP的节点操作可分为以下几类：
-----------------------------------+---------------------------------
| Category | Action |
-----------------------------------+---------------------------------
| Reusing existing resource on | This type of node needs to |
| both input and output interfaces | reserve the existing resources |
| (nodes A & B in Figure 3). | and no cross-connection |
| | command is needed. |
-----------------------------------+---------------------------------
| Reusing an existing resource only| This type of node needs to |
| on one of the interfaces, either | reserve the resources and send |
| input or output interfaces, and | the reconfiguration |
| using new resource on the | cross-connection command to its|
| other interfaces. | corresponding data plane |
| (nodes C & E in Figure 3). | node on the interfaces where |
| | new resources are needed, and |
| | it needs to reuse the existing |
| | resources on the other |
| | interfaces. |
-----------------------------------+---------------------------------
| Using new resources on both | This type of node needs to |
| interfaces. | reserve the new resources |
| (nodes F & G in Figure 3). | and send the cross-connection |
| | command on both interfaces. |
-----------------------------------+---------------------------------
-----------------------------------+---------------------------------
| Category | Action |
-----------------------------------+---------------------------------
| Reusing existing resource on | This type of node needs to |
| both input and output interfaces | reserve the existing resources |
| (nodes A & B in Figure 3). | and no cross-connection |
| | command is needed. |
-----------------------------------+---------------------------------
| Reusing an existing resource only| This type of node needs to |
| on one of the interfaces, either | reserve the resources and send |
| input or output interfaces, and | the reconfiguration |
| using new resource on the | cross-connection command to its|
| other interfaces. | corresponding data plane |
| (nodes C & E in Figure 3). | node on the interfaces where |
| | new resources are needed, and |
| | it needs to reuse the existing |
| | resources on the other |
| | interfaces. |
-----------------------------------+---------------------------------
| Using new resources on both | This type of node needs to |
| interfaces. | reserve the new resources |
| (nodes F & G in Figure 3). | and send the cross-connection |
| | command on both interfaces. |
-----------------------------------+---------------------------------
Table 1: Node Actions during Restoration LSP Setup
表1：恢复LSP设置期间的节点操作
Depending on whether or not the resource is reused, the node actions differ. This deviates from normal LSP setup, since some nodes do not need to reconfigure the cross-connection. Also, the judgment of whether the control plane node needs to send a cross-connection setup or modification command to its corresponding data plane node(s) relies on the check whether the LSPs are sharing resources.
根据资源是否被重用，节点操作会有所不同。这与正常的LSP设置不同，因为有些节点不需要重新配置交叉连接。此外，控制平面节点是否需要向其相应的数据平面节点发送交叉连接设置或修改命令的判断依赖于lsp是否共享资源的检查。
If the end-to-end LSP recovery scheme employs the revertive behavior, as described in Section 3 of this document, traffic can be reverted from the restoration LSP to the working or protecting LSP after its failure is recovered. The LSP reversion can be achieved using two methods:
如本文件第3节所述，如果端到端LSP恢复方案采用恢复行为，则在恢复故障后，可以将恢复LSP的通信量恢复到工作或保护LSP。可使用两种方法实现LSP恢复：
1. Make-While-Break Reversion: resources associated with a working or protecting LSP are reconfigured while removing reservations for the restoration LSP.
1. 边通边断恢复：在删除恢复LSP的保留时，将重新配置与工作或保护LSP关联的资源。
2. Make-Before-Break Reversion: resources associated with a working or protecting LSP are reconfigured before removing reservations for the restoration LSP.
2. 先通后断恢复：在删除恢复LSP的保留之前，将重新配置与工作或保护LSP关联的资源。
In non-packet transport networks, both of the above reversion methods will result in some traffic disruption when the restoration LSP and the LSP being restored are sharing resources and the cross-connections need to be reconfigured on intermediate nodes.
在非分组传输网络中，当恢复LSP和正在恢复的LSP共享资源并且需要在中间节点上重新配置交叉连接时，上述两种恢复方法都将导致一些业务中断。
In this reversion method, restoration LSP is simply requested to be deleted by the head-end. Removing reservations for restoration LSP triggers reconfiguration of resources associated with a working or protecting LSP on every node where resources are shared. The working or protecting LSP state was not removed from the nodes when the failure occurred. Whenever reservation for restoration LSP is removed from a node, data plane configuration changes to reflect reservations of working or protecting LSP as signaling progresses. Eventually, after the whole restoration LSP is deleted, data plane configuration will fully match working or protecting LSP reservations on the whole path. Thus, reversion is complete.
在这种恢复方法中，恢复LSP仅由前端请求删除。删除恢复LSP的保留会触发与共享资源的每个节点上的工作或保护LSP相关联的资源的重新配置。发生故障时，未从节点中删除工作或保护LSP状态。无论何时从节点删除恢复LSP的保留，数据平面配置都会随着信令的进行而改变，以反映工作或保护LSP的保留。最终，在删除整个恢复LSP后，数据平面配置将完全匹配整个路径上的工作或保护LSP保留。因此，回归是完全的。
Make-while-break, while being relatively simple in its logic, has a few limitations as follows which may not be acceptable in some networks:
通断虽然在逻辑上相对简单，但有以下一些限制，在某些网络中可能无法接受：
o No rollback
o 无回滚
If, for some reason, reconfiguration of the data plane on one of the nodes, to match working or protecting LSP reservations, fails, falling back to restoration LSP is no longer an option, as its state might have already been removed from other nodes.
如果出于某种原因，其中一个节点上的数据平面重新配置（以匹配工作或保护LSP保留）失败，则退回到恢复LSP不再是一个选项，因为其状态可能已从其他节点上移除。
o No completion guarantee
o 无竣工担保
Deletion of an LSP provides no guarantees of completion. In particular, if RSVP packets are lost due to a node or link failure, it is possible for an LSP to be only partially deleted. To mitigate this, RSVP could maintain soft state reservations and, hence, eventually remove remaining reservations due to refresh timeouts. This approach is not feasible in non-packet transport networks, however, where control and data channels are often separated; hence, soft state reservations are not useful.
删除LSP不能保证完成。特别地，如果RSVP分组由于节点或链路故障而丢失，则LSP可能仅被部分删除。为了缓解这种情况，RSVP可以保持软状态保留，并因此最终删除由于刷新超时而剩余的保留。然而，这种方法在非分组传输网络中是不可行的，因为在非分组传输网络中，控制信道和数据信道通常是分开的；因此，软状态保留没有用处。
Finally, one could argue that graceful LSP deletion [RFC3473] would provide a guarantee of completion. While this is true for most cases, many implementations will time out graceful deletion if LSP is not removed within certain amount of time, e.g., due to a transit node fault. After that, deletion procedures that provide no completion guarantees will be attempted. Hence, in corner cases a completion guarantee cannot be provided.
最后，有人可能会说，优雅的LSP删除[RFC3473]将提供完成的保证。虽然这在大多数情况下是正确的，但如果LSP在一定时间内未被删除（例如，由于传输节点故障），许多实现将超时删除。之后，将尝试执行不提供完成保证的删除过程。因此，在极端情况下，无法提供完工担保。
o No explicit notification of completion to head-end node
o 没有向前端节点发出明确的完成通知
In some cases, it may be useful for a head-end node to know when the data plane has been reconfigured to match working or protecting LSP reservations. This knowledge could be used for initiating operations like enabling alarm monitoring, power equalization, and others. Unfortunately, for the reasons mentioned above, make-while-break reversion lacks such explicit notification.
在某些情况下，头端节点知道数据平面何时被重新配置以匹配工作或保护LSP保留可能是有用的。这些知识可用于启动报警监控、功率均衡等操作。不幸的是，出于上述原因，边做边断的恢复缺乏这种明确的通知。
This reversion method can be used to overcome limitations of make-while-break reversion. It is similar in spirit to the MBB concept used for re-optimization. Instead of relying on deletion of the restoration LSP, the head-end chooses to establish a new reversion LSP that duplicates the configuration of the resources on the working or protecting LSP and uses identical ASSOCIATION and PROTECTION objects in the Path message of that LSP. Only if the setup of this LSP is successful will other (restoration and working or protecting) LSPs be deleted by the head-end. MBB reversion consists of two parts:
这种恢复方法可以用来克服边通边断恢复的局限性。这在精神上与用于重新优化的MBB概念类似。不依赖于恢复LSP的删除，前端选择建立新的恢复LSP，该恢复LSP复制工作或保护LSP上的资源配置，并在该LSP的路径消息中使用相同的关联和保护对象。只有当此LSP的设置成功时，其他（恢复、工作或保护）LSP才会被前端删除。MBB复归由两部分组成：
A) Make part:
A） 组成部分：
Creating a new reversion LSP following working or protecting the LSP. The reversion LSP shares all of the resources of the working or protecting LSP and may share resources with the restoration LSP. As the reversion LSP is created, resources are
在处理或保护LSP后创建新的恢复LSP。恢复LSP共享工作或保护LSP的所有资源，并且可以与恢复LSP共享资源。在创建恢复LSP时，资源将
reconfigured to match its reservations. Hence, after the reversion LSP is created, data plane configuration reflects working or protecting LSP reservations.
重新配置以匹配其保留。因此，在创建恢复LSP之后，数据平面配置反映工作或保护LSP保留。
B) Break part:
B） 断开部分：
After the "make" part is finished, the original working or protecting and restoration LSPs are torn down, and the reversion LSP becomes the new working or protecting LSP. Removing reservations for working or restoration LSPs does not cause any resource reconfiguration on the reversion LSP -- nodes follow same procedures for the "break" part of any MBB operation. Hence, after working or protecting and restoration LSPs are removed, the data plane configuration is exactly the same as before starting restoration. Thus, reversion is complete.
“制造”部分完成后，原始工作或保护和恢复LSP被拆除，恢复LSP成为新的工作或保护LSP。删除工作或恢复LSP的保留不会导致恢复LSP上的任何资源重新配置——对于任何MBB操作的“中断”部分，节点遵循相同的过程。因此，在移除工作或保护和恢复LSP之后，数据平面配置与开始恢复之前完全相同。因此，回归是完全的。
MBB reversion uses make-before-break characteristics to overcome challenges related to make-while-break reversion as follow:
MBB恢复使用先通后断的特性来克服与边通边断恢复相关的挑战，如下所示：
o Rollback
o 回降
If the "make" part fails, the (existing) restoration LSP will still be used to carry existing traffic as the restoration LSP state was not removed. Same logic applies here as for any MBB operation failure.
如果“make”部分失败，则（现有）恢复LSP仍将用于承载现有流量，因为恢复LSP状态未被删除。此处适用于任何MBB操作故障的逻辑。
o Completion guarantee
o 竣工担保
LSP setup is resilient against RSVP message loss, as Path and Resv messages are refreshed periodically. Hence, given that the network recovers from node and link failures eventually, reversion LSP setup is guaranteed to finish with either success or failure.
LSP设置对RSVP消息丢失具有弹性，因为Path和Resv消息会定期刷新。因此，如果网络最终从节点和链路故障中恢复，则可以保证恢复LSP设置成功或失败。
o Explicit notification of completion to head-end node
o 向前端节点发出明确的完成通知
The head-end knows that the data plane has been reconfigured to match working or protecting LSP reservations on the intermediate nodes when it receives a Resv message for the reversion LSP.
当接收到回复LSP的Resv消息时，前端知道数据平面已被重新配置以匹配中间节点上的工作或保护LSP保留。
This document reviews procedures defined in [RFC3209], [RFC4872], [RFC4873], and [RFC6689] and does not define any new procedures. This document does not introduce any new security issues; security issues were already covered in [RFC3209], [RFC4872], [RFC4873], and [RFC6689].
本文件审查了[RFC3209]、[RFC4872]、[RFC4873]和[RFC6689]中定义的程序，未定义任何新程序。本文件未引入任何新的安全问题；[RFC3209]、[RFC4872]、[RFC4873]和[RFC6689]中已经讨论了安全问题。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[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, DOI 10.17487/RFC4872, May 2007, <http://www.rfc-editor.org/info/rfc4872>.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，DOI 10.17487/RFC4872，2007年5月<http://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <http://www.rfc-editor.org/info/rfc4873>.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，DOI 10.17487/RFC4873，2007年5月<http://www.rfc-editor.org/info/rfc4873>.
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, DOI 10.17487/RFC6689, July 2012, <http://www.rfc-editor.org/info/rfc6689>.
[RFC6689]Berger，L.“RSVP关联对象的使用”，RFC 6689，DOI 10.17487/RFC6689，2012年7月<http://www.rfc-editor.org/info/rfc6689>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 3945，DOI 10.17487/RFC3945，2004年10月<http://www.rfc-editor.org/info/rfc3945>.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，DOI 10.17487/RFC4203，2005年10月<http://www.rfc-editor.org/info/rfc4203>.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, DOI 10.17487/RFC4426, March 2006, <http://www.rfc-editor.org/info/rfc4426>.
[RFC4426]Lang，J.，Ed.，Rajagopalan，B.，Ed.，和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）恢复功能规范”，RFC 4426，DOI 10.17487/RFC4426，2006年3月<http://www.rfc-editor.org/info/rfc4426>.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <http://www.rfc-editor.org/info/rfc4427>.
[RFC4427]Mannie，E.，Ed.，和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，DOI 10.17487/RFC4427，2006年3月<http://www.rfc-editor.org/info/rfc4427>.
Acknowledgements
致谢
The authors would like to thank:
作者要感谢：
- George Swallow for the discussions on the GMPLS restoration.
- 乔治·斯沃恩（George Swallow）参加了GMPLS修复的讨论。
- Lou Berger for the guidance on this work.
- Lou Berger为这项工作提供指导。
- Lou Berger, Vishnu Pavan Beeram, and Christian Hopps for reviewing this document and providing valuable comments.
- 感谢Lou Berger、Vishnu Pavan Beeram和Christian Hopps审阅本文件并提供宝贵意见。
A special thanks to Dale Worley for his thorough review of this document.
特别感谢Dale Worley对本文件的全面审查。
Contributors
贡献者
Gabriele Maria Galimberti Cisco Systems, Inc.
Gabriele Maria Galimberti思科系统公司。
Email: ggalimbe@cisco.com
Email: ggalimbe@cisco.com
Authors' Addresses
作者地址
Xian Zhang Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China
中国深圳市龙岗区华为基地坂田贤章华为技术F3-1-B研发中心邮编：518129
Email: zhang.xian@huawei.com
Email: zhang.xian@huawei.com
Haomian Zheng (editor) Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China
郑浩棉（编辑）华为技术F3-1-B研发中心，华为总部，深圳市龙岗区坂田518129
Email: zhenghaomian@huawei.com
Email: zhenghaomian@huawei.com
Rakesh Gandhi (editor) Cisco Systems, Inc.
拉凯什·甘地（编辑）思科系统公司。
Email: rgandhi@cisco.com
Email: rgandhi@cisco.com
Zafar Ali Cisco Systems, Inc.
扎法尔·阿里思科系统公司。
Email: zali@cisco.com
Email: zali@cisco.com
Pawel Brzozowski ADVA Optical
波厄尔·布佐夫斯基光学公司
Email: PBrzozowski@advaoptical.com
Email: PBrzozowski@advaoptical.com