Internet Engineering Task Force (IETF) M. Taillon
Request for Comments: 8271 T. Saad, Ed.
Updates: 4090 R. Gandhi, Ed.
Category: Standards Track Z. Ali
ISSN: 2070-1721 Cisco Systems, Inc.
M. Bhatia
Nokia
October 2017
Internet Engineering Task Force (IETF) M. Taillon
Request for Comments: 8271 T. Saad, Ed.
Updates: 4090 R. Gandhi, Ed.
Category: Standards Track Z. Ali
ISSN: 2070-1721 Cisco Systems, Inc.
M. Bhatia
Nokia
October 2017
Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)
更新流量工程GMPLS标签交换路径（LSP）快速重路由的资源预留协议
Abstract
摘要
This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane.
本文档更新了RFC 4090中定义的资源预留协议-流量工程（RSVP-TE）快速重路由（FRR）程序，以支持支持支持分组交换（PSC）的通用多协议标签交换（GMPLS）标签交换路径（LSP）。这些更新允许协调双向旁路隧道分配，以在共同路由的双向LSP的正向和反向上保护公共设施。此外，这些更新允许将双向流量重定向到旁路隧道，以确保FRR后正向和反向数据路径的共同路由，并避免控制平面中的RSVP软状态超时。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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 https://www.rfc-editor.org/info/rfc8271.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8271.
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 (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Fast Reroute for Unidirectional GMPLS LSPs . . . . . . . . . 6
4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 7
4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7
4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . 7
4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7
4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8
4.5. Bidirectional Bypass Tunnel Assignment Coordination . . . 8
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling
Procedure . . . . . . . . . . . . . . . . . . . . . . 8
4.5.2. One-to-One Bidirectional Bypass Tunnel Assignment . . 10
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . 10
5. Fast Reroute for Bidirectional GMPLS LSPs with In-Band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . 12
5.1.1. Behavior after Link Failure . . . . . . . . . . . . . 13
5.1.2. Revertive Behavior after Fast Reroute . . . . . . . . 13
5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . 13
5.2.1. Behavior after Link Failure . . . . . . . . . . . . . 14
5.2.2. Behavior after Link Failure to Restore Co-routing . . 14
5.2.3. Revertive Behavior after Fast Reroute . . . . . . . . 16
5.2.4. Behavior after Node Failure . . . . . . . . . . . . . 16
5.3. Unidirectional Link Failures . . . . . . . . . . . . . . 16
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Message and Object Definitions . . . . . . . . . . . . . . . 17
7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17
7.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 21
10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Fast Reroute for Unidirectional GMPLS LSPs . . . . . . . . . 6
4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 7
4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7
4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . 7
4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7
4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8
4.5. Bidirectional Bypass Tunnel Assignment Coordination . . . 8
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling
Procedure . . . . . . . . . . . . . . . . . . . . . . 8
4.5.2. One-to-One Bidirectional Bypass Tunnel Assignment . . 10
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . 10
5. Fast Reroute for Bidirectional GMPLS LSPs with In-Band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . 12
5.1.1. Behavior after Link Failure . . . . . . . . . . . . . 13
5.1.2. Revertive Behavior after Fast Reroute . . . . . . . . 13
5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . 13
5.2.1. Behavior after Link Failure . . . . . . . . . . . . . 14
5.2.2. Behavior after Link Failure to Restore Co-routing . . 14
5.2.3. Revertive Behavior after Fast Reroute . . . . . . . . 16
5.2.4. Behavior after Node Failure . . . . . . . . . . . . . 16
5.3. Unidirectional Link Failures . . . . . . . . . . . . . . 16
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Message and Object Definitions . . . . . . . . . . . . . . . 17
7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17
7.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 21
10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Packet Switch Capable (PSC) Traffic Engineering (TE) Label Switched Paths (LSPs) can be set up using Generalized Multiprotocol Label Switching (GMPLS) signaling procedures specified in [RFC3473] for both unidirectional and bidirectional tunnels. The GMPLS signaling allows sending and receiving the RSVP messages in-band with the data traffic or out-of-band over a separate control channel. Fast Reroute (FRR) [RFC4090] has been widely deployed in the packet TE networks today and is desirable for TE GMPLS LSPs. Using FRR methods also allows the leveraging of existing mechanisms for failure detection and restoration in deployed networks.
对于单向和双向隧道，可使用[RFC3473]中规定的通用多协议标签交换（GMPLS）信令程序建立支持分组交换（PSC）的流量工程（TE）标签交换路径（LSP）。GMPLS信令允许在带内或带外通过单独的控制信道发送和接收RSVP消息。快速重路由（FRR）[RFC4090]如今已广泛部署在分组TE网络中，并且对于TE GMPLS LSP是可取的。使用FRR方法还允许利用现有机制在已部署的网络中进行故障检测和恢复。
The FRR procedures defined in [RFC4090] describe the behavior of the Point of Local Repair (PLR) to reroute traffic and signaling onto the bypass tunnel in the event of a failure for protected LSPs. Those procedures are applicable to the unidirectional protected LSPs signaled using either RSVP-TE [RFC3209] or GMPLS procedures [RFC3473]. When using the FRR procedures defined in [RFC4090] with co-routed bidirectional GMPLS LSPs, it is desired that same PLR and Merge Point (MP) pairs are selected in each direction and that both PLR and MP assign the same bidirectional bypass tunnel. This document updates the FRR procedures defined in [RFC4090] to coordinate the bidirectional bypass tunnel assignment and to exchange MP labels between upstream and downstream PLRs of the protected co-routed bidirectional LSP.
[RFC4090]中定义的FRR程序描述了当受保护LSP发生故障时，本地维修点（PLR）将流量和信号重新路由到旁路隧道的行为。这些程序适用于使用RSVP-TE[RFC3209]或GMPLS程序[RFC3473]发出信号的单向保护LSP。当使用[RFC4090]中定义的FRR程序和共路由双向GMPLS LSP时，希望在每个方向上选择相同的PLR和合并点（MP）对，并且PLR和MP分配相同的双向旁路隧道。本文件更新了[RFC4090]中定义的FRR程序，以协调双向旁路隧道分配，并在受保护的共路由双向LSP的上游和下游PLR之间交换MP标签。
When using FRR procedures with co-routed bidirectional GMPLS LSPs, it is possible in some cases for the RSVP signaling refreshes to stop reaching certain nodes along the protected LSP path after the PLRs finish rerouting of the signaling messages. This can occur after a failure event when using node protection bypass tunnels. As shown in Figure 2, this is possible even with selecting the same bidirectional bypass tunnels in both directions and the same PLR and MP pairs. This is caused by the asymmetry of paths that may be taken by the bidirectional LSP's signaling in the forward and reverse directions due to upstream and downstream PLRs independently triggering FRR. In such cases, after FRR, the RSVP soft-state timeout causes the protected bidirectional LSP to be torn down, with subsequent traffic loss.
当对共路由双向GMPLS LSP使用FRR过程时，在某些情况下，在PLR完成信令消息的重新路由后，RSVP信令刷新可能停止到达受保护LSP路径上的某些节点。当使用节点保护旁路隧道时，这可能发生在故障事件之后。如图2所示，即使在两个方向上选择相同的双向旁路隧道以及相同的PLR和MP对，这也是可能的。这是由由于上游和下游plr独立触发FRR而导致的双向LSP的信令在正向和反向上可能采取的路径不对称引起的。在这种情况下，在FRR之后，RSVP软状态超时会导致受保护的双向LSP被拆除，并导致随后的通信量丢失。
Protection State Coordination Protocol [RFC6378] is applicable to FRR [RFC4090] for local protection of co-routed bidirectional LSPs in order to minimize traffic disruptions in both directions. However, this does not address the above-mentioned problem of RSVP soft-state timeout that can occur in the control plane.
保护状态协调协议[RFC6378]适用于FRR[RFC4090]，用于对共路由双向LSP进行本地保护，以最大限度地减少双向通信中断。但是，这并不能解决上述控制平面中可能出现的RSVP软状态超时问题。
This document defines a solution to the RSVP soft-state timeout issue by providing mechanisms in the control plane to complement the FRR procedures of [RFC4090]. This solution allows the RSVP soft state for co-routed, protected bidirectional GMPLS LSPs to be maintained in the control plane and enables co-routing of the traffic paths in the forward and reverse directions after FRR.
本文件通过在控制平面中提供机制来补充[RFC4090]的FRR程序，定义了RSVP软状态超时问题的解决方案。该解决方案允许在控制平面中维持共路由、受保护的双向GMPLS LSP的RSVP软状态，并在FRR后在正向和反向上实现业务路径的共路由。
The procedures defined in this document apply to PSC TE co-routed, protected bidirectional LSPs and co-routed bidirectional FRR bypass tunnels both signaled by GMPLS. Unless otherwise specified in this document, the FRR procedures defined in [RFC4090] are not modified by this document. The FRR mechanism for associated bidirectional GMPLS LSPs where two unidirectional GMPLS LSPs are bound together by using association signaling [RFC7551] is outside the scope of this document.
本文件中定义的程序适用于由GMPLS发出信号的PSC TE共路由、受保护的双向LSP和共路由的双向FRR旁路隧道。除非本文件另有规定，否则本文件不修改[RFC4090]中定义的FRR程序。通过使用关联信令[RFC7551]将两个单向GMPLS LSP绑定在一起的关联双向GMPLS LSP的FRR机制不在本文档范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The reader is assumed to be familiar with the terminology in [RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090].
假定读者熟悉[RFC2205]、[RFC3209]、[RFC3471]、[RFC3473]和[RFC4090]中的术语。
Downstream PLR: Downstream Point of Local Repair The PLR that locally detects a failure in the downstream direction of the traffic flow and reroutes traffic in the same direction of the protected bidirectional LSP RSVP Path signaling. A downstream PLR has a corresponding downstream MP.
下游PLR：本地修复的下游点——本地检测业务流下游方向故障并在受保护的双向LSP RSVP路径信令的同一方向上重新路由业务的PLR。下游PLR具有相应的下游MP。
Downstream MP: Downstream Merge Point The LSR where one or more backup tunnels rejoin the path of the protected LSP in the downstream direction of the traffic flow. The same LSR can be both a downstream MP and an upstream PLR simultaneously.
下游MP：下游合并点——LSR，其中一条或多条备用隧道在交通流的下游方向重新连接受保护LSP的路径。同一LSR可以同时是下游MP和上游PLR。
Upstream PLR: Upstream Point of Local Repair The PLR that locally detects a failure in the upstream direction of the traffic flow and reroutes traffic in the opposite direction of the protected bidirectional LSP RSVP Path signaling. An upstream PLR has a corresponding upstream MP.
上游PLR：本地修复的上游点本地检测业务流上游方向的故障并在受保护的双向LSP RSVP路径信令的相反方向重新路由业务的PLR。上游PLR具有相应的上游MP。
Upstream MP: Upstream Merge Point The LSR where one or more backup tunnels rejoin the path of the protected LSP in the upstream direction of the traffic flow. The same LSR can be both an upstream MP and a downstream PLR simultaneously.
上游MP：上游合并点——LSR，其中一条或多条备用隧道在交通流的上游方向重新加入受保护LSP的路径。同一LSR可以同时是上游MP和下游PLR。
Point of Remote Repair (PRR) A downstream MP that assumes the role of upstream PLR upon receiving the protected LSP's rerouted Path message and triggers reroute of traffic and signaling in the upstream direction of the traffic flow using the procedures described in this document.
远程修复点（PRR）：一种下游MP，在接收到受保护LSP的重路由路径消息时，承担上游PLR的角色，并使用本文件中描述的程序触发交通流上游方向的交通和信令重路由。
GMPLS: Generalized Multiprotocol Label Switching
广义多协议标签交换
LSP: Label Switched Path
标签交换路径
LSR: Label Switching Router
标签交换路由器
MP: Merge Point
MP：合并点
MPLS: Multiprotocol Label Switching
多协议标签交换
PLR: Point of Local Repair
PLR：局部维修点
PSC: Packet Switch Capable
PSC：支持分组交换
RSVP: Resource Reservation Protocol
资源预留协议
TE: Traffic Engineering
交通工程
The FRR procedures defined in [RFC4090] for RSVP-TE signaling [RFC3209] are equally applicable to the unidirectional protected LSPs signaled using GMPLS [RFC3473] and are not modified by the updates defined in this document except for the following:
[RFC4090]中定义的RSVP-TE信号[RFC3209]的FRR程序同样适用于使用GMPLS[RFC3473]发出信号的单向保护LSP，本文件中定义的更新不会对其进行修改，但以下情况除外：
When using the GMPLS out-of-band signaling [RFC3473], after a link failure event, the RSVP messages are not rerouted over the bypass tunnel by the downstream PLR but instead are rerouted over a control channel to the downstream MP.
当使用GMPLS带外信令[RFC3473]时，链路故障事件发生后，下游PLR不会通过旁路隧道重新路由RSVP消息，而是通过控制信道重新路由到下游MP。
This section describes signaling procedures for FRR bidirectional bypass tunnel assignment for GMPLS signaled PSC co-routed bidirectional TE LSPs for both in-band and out-of-band signaling.
本节描述了用于带内和带外信令的GMPLS信令PSC共路由双向TE LSP的FRR双向旁路隧道分配的信令程序。
This document defines procedures where bidirectional GMPLS bypass tunnels are signaled in the same direction as the protected GMPLS LSPs. In other words, the bidirectional GMPLS bypass tunnels originate on the downstream PLRs and terminate on the corresponding downstream MPs. As the originating downstream PLR has the policy information about the locally provisioned bypass tunnels, it always initiates the bypass tunnel assignment. The bidirectional GMPLS bypass tunnels originating from the upstream PLRs and terminating on the corresponding upstream MPs are outside the scope of this document.
本文件规定了双向GMPLS旁通隧道与受保护的GMPLS LSP在同一方向发出信号的程序。换句话说，双向GMPLS旁路隧道起始于下游PLR，终止于相应的下游MPs。由于发起的下游PLR具有关于本地供应的旁路隧道的策略信息，因此它总是发起旁路隧道分配。源自上游PLR并终止于相应上游MPs的双向GMPLS旁通隧道不在本文件范围内。
To correctly reroute data traffic over a node protection bypass tunnel, the downstream and upstream PLRs have to know, in advance, the downstream and upstream MP labels of the protected LSP so that data in the forward and reverse directions can be redirected through the bypass tunnel after FRR, respectively.
为了在节点保护旁路隧道上正确地重新路由数据通信量，下游和上游plr必须事先知道受保护LSP的下游和上游MP标签，以便在fr之后可以分别通过旁路隧道重定向正向和反向的数据。
[RFC4090] defines procedures for the downstream PLR to obtain the protected LSP's downstream MP label from recorded labels in the RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the downstream PLR.
[RFC4090]定义了下游PLR从下游PLR接收的RSVP Resv消息的记录路由对象（RRO）中记录的标签获取受保护LSP下游MP标签的程序。
To obtain the upstream MP label, the procedures specified in [RFC4090] are used to record the upstream MP label in the RRO of the RSVP Path message of the protected LSP. The upstream PLR obtains the upstream MP label from the recorded labels in the RRO of the received RSVP Path message.
为了获得上游MP标签，使用[RFC4090]中规定的程序将上游MP标签记录在受保护LSP的RSVP Path消息的RRO中。上游PLR从接收到的RSVP Path消息的RRO中记录的标签获取上游MP标签。
To correctly assign a bidirectional bypass tunnel, the downstream and upstream PLRs have to know, in advance, the downstream and upstream MP addresses.
为了正确分配双向旁路隧道，下游和上游PLR必须提前知道下游和上游MP地址。
[RFC4561] defines procedures for the downstream PLR to obtain the protected LSP's downstream MP address from the recorded Node-IDs in the RRO of the RSVP Resv message received at the downstream PLR.
[RFC4561]定义了下游PLR从下游PLR接收的RSVP Resv消息的RRO中记录的节点ID获取受保护LSP的下游MP地址的过程。
To obtain the upstream MP address, the procedures specified in [RFC4561] are used to record upstream MP Node-ID in the RRO of the RSVP Path message of the protected LSP. The upstream PLR obtains the upstream MP address from the recorded Node-IDs in the RRO of the received RSVP Path message.
为了获得上游MP地址，使用[RFC4561]中指定的程序在受保护LSP的RSVP Path消息的RRO中记录上游MP节点ID。上游PLR从接收到的RSVP Path消息的RRO中记录的节点ID获得上游MP地址。
RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 and are equally applicable to the FRR procedure for the protected bidirectional GMPLS LSPs.
[RFC4090]第4.4节定义了RRO IPv4/IPv6子对象标志，该标志同样适用于受保护的双向GMPLS LSP的FRR程序。
The procedures defined in [RFC4090] are used by the downstream PLR to signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP Resv message of the protected LSP. Similarly, those procedures are used by the downstream PLR to signal the IPv4/IPv6 subobject flags downstream in the RRO of the RSVP Path message of the protected LSP.
下游PLR使用[RFC4090]中定义的过程向受保护LSP的RSVP Resv消息的RRO中上游的IPv4/IPv6子对象标志发送信号。类似地，下游PLR使用这些过程向下游受保护LSP的RSVP Path消息的RRO中的IPv4/IPv6子对象标志发送信号。
This document defines signaling procedures and a new BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO) used to coordinate the bidirectional bypass tunnel assignment between the downstream and upstream PLRs.
本文件在RSVP记录路由对象（RRO）中定义了信令程序和新的旁路分配子对象，用于协调下游和上游PLR之间的双向旁路隧道分配。
It is desirable to coordinate the bidirectional bypass tunnel selected at the downstream and upstream PLRs so that the rerouted traffic flows on co-routed paths after FRR. To achieve this, a new RSVP subobject is defined for RRO that identifies a bidirectional bypass tunnel that is assigned at a downstream PLR to protect a bidirectional LSP.
希望协调在下游和上游PLR处选择的双向旁路隧道，以便在FRR之后重新路由的交通流在共同路由路径上流动。为了实现这一点，为RRO定义了一个新的RSVP子对象，该子对象标识在下游PLR处分配的双向旁路隧道，以保护双向LSP。
When the procedures defined in this document are in use, the BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in the RSVP Path RRO message of the GMPLS signaled bidirectional protected LSP to record the downstream bidirectional bypass tunnel assignment. This subobject is sent in the RSVP Path RRO message every time the downstream PLR assigns or updates the bypass tunnel assignment. The downstream PLR can assign a bypass tunnel when processing the first Path message of the protected LSP as long as it has a topological view of the downstream MP and the traversed path information in the Explicit Route Object (ERO). For the protected LSP where the downstream MP cannot be determined from the first Path message (e.g., when using loose hops in the ERO), the downstream PLR needs to wait for the Resv message with RRO in order to assign a bypass tunnel. However, in both cases, the downstream PLR cannot
当使用本文件中定义的程序时，每个下游PLR必须在GMPLS信号双向保护LSP的RSVP Path RRO消息中添加旁路分配子对象，以记录下游双向旁路隧道分配。每当下游PLR分配或更新旁通隧道分配时，该子对象在RSVP Path RRO消息中发送。当处理受保护LSP的第一路径消息时，下游PLR可以分配旁路隧道，只要它在显式路由对象（ERO）中具有下游MP的拓扑视图和经过的路径信息。对于无法从第一条路径消息确定下游MP的受保护LSP（例如，在ERO中使用松散跃点时），下游PLR需要等待带有RRO的Resv消息，以便分配旁通隧道。然而，在这两种情况下，下游PLR不能
update the data plane until it receives Resv messages containing the MP labels.
更新数据平面，直到它接收到包含MP标签的Resv消息。
The upstream PLR (downstream MP) simply reflects the bypass tunnel assignment in the reverse direction. The absence of the BYPASS_ASSIGNMENT subobject in Path RRO means that the relevant node or interface is not protected by a bidirectional bypass tunnel.
上游PLR（下游MP）仅反映反向的旁通隧道分配。路径RRO中缺少旁路分配子对象意味着相关节点或接口不受双向旁路隧道的保护。
Hence, the upstream PLR need not assign a bypass tunnel in the reverse direction.
因此，上游PLR不需要在相反方向上分配旁通隧道。
When the BYPASS_ASSIGNMENT subobject is added in the Path RRO:
在路径RRO中添加旁路分配子对象时：
o The IPv4 or IPv6 subobject containing the Node-ID address MUST also be added [RFC4561]. The Node-ID address MUST match the source address of the bypass tunnel selected for this protected LSP.
o 还必须添加包含节点ID地址的IPv4或IPv6子对象[RFC4561]。节点ID地址必须与为此受保护LSP选择的旁路隧道的源地址匹配。
o The BYPASS_ASSIGNMENT subobject MUST be added immediately after the Node-ID address.
o 旁路分配子对象必须立即添加到节点ID地址之后。
o The Label subobject MUST also be added [RFC3209].
o 还必须添加标签子对象[RFC3209]。
The rules for adding an IPv4 or IPv6 Interface address subobject and Unnumbered Interface ID subobject as specified in [RFC3209] and [RFC4090] are not modified by the above procedure. The options specified in Section 6.1.3 in [RFC4990] are also applicable as long as the above-mentioned rules are followed when using the FRR procedures defined in this document.
[RFC3209]和[RFC4090]中指定的用于添加IPv4或IPv6接口地址子对象和未编号接口ID子对象的规则不受上述过程的修改。[RFC4990]第6.1.3节中规定的选项也适用，只要在使用本文件中定义的FRR程序时遵守上述规则。
An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT subobjects in the Path RRO to see if the destination address in the BYPASS_ASSIGNMENT matches the address of the upstream PLR. For each BYPASS_ASSIGNMENT subobject that matches, the upstream PLR looks for a tunnel that has a source address matching the downstream PLR that inserted the BYPASS_ASSIGNMENT, as indicated by the Node-ID address and the same Tunnel ID as indicated in the BYPASS_ASSIGNMENT. The RRO can contain multiple addresses to identify a node. However, the upstream PLR relies on the Node-ID address preceding the BYPASS_ASSIGNMENT subobject for identifying the bypass tunnel. If the bypass tunnel is not found, the upstream PLR SHOULD send a Notify message [RFC3473] with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code "Bypass Tunnel Not Found" (value 1) to the downstream PLR. Upon receiving this error, the downstream PLR SHOULD remove the bypass tunnel assignment and select an alternate bypass tunnel if one available. The RRO containing BYPASS_ASSIGNMENT subobject(s) is then simply forwarded downstream in the RSVP Path message.
上游PLR（下游MP）应检查路径RRO中的所有旁路分配子对象，以查看旁路分配中的目标地址是否与上游PLR的地址匹配。对于匹配的每个旁路分配子对象，上游PLR查找一个隧道，该隧道的源地址与插入旁路分配的下游PLR相匹配，如节点ID地址和旁路分配中所示的相同隧道ID所示。RRO可以包含多个地址来标识节点。然而，上游PLR依赖于旁路分配子对象之前的节点ID地址来识别旁路隧道。如果未找到旁通隧道，上游PLR应向下游PLR发送一条带有错误代码“FRR旁通分配错误”（值44）和子代码“未找到旁通隧道”（值1）的通知消息[RFC3473]。收到此错误后，下游PLR应删除旁通隧道分配，并选择备用旁通隧道（如果可用）。然后，包含旁路分配子对象的RRO在RSVP Path消息中直接转发到下游。
A downstream PLR may add, remove, or change the bypass tunnel assignment for a protected LSP resulting in the addition, removal, or modification of the BYPASS_ASSIGNMENT subobject in the Path RRO, respectively. In this case, the downstream PLR SHOULD generate a modified Path message and forward it downstream. The downstream MP SHOULD check the RRO in the received Path message and update the bypass tunnel assignment in the reverse direction accordingly.
下游PLR可添加、移除或更改受保护LSP的旁路隧道分配，从而分别添加、移除或修改路径RRO中的旁路分配子对象。在这种情况下，下游PLR应生成修改后的路径消息并将其转发到下游。下游MP应检查接收到的路径消息中的RRO，并相应地以相反方向更新旁通隧道分配。
The bidirectional bypass tunnel assignment coordination procedure defined in this document can be used for both the facility backup described in Section 3.2 of [RFC4090] and the one-to-one backup described in Section 3.1 of [RFC4090]. As specified in Section 4.2 of [RFC4090], the DETOUR object can be used in the one-to-one backup method to identify the detour LSPs. In the one-to-one backup method, if the bypass tunnel is already in use at the upstream PLR, it SHOULD send a Notify message [RFC3473] with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code "One-to-One Bypass Already in Use" (value 2) to the downstream PLR. Upon receiving this error, the downstream PLR SHOULD remove the bypass tunnel assignment and select an alternate bypass tunnel if one is available.
本文件中定义的双向旁路隧道分配协调程序可用于[RFC4090]第3.2节所述的设施备份和[RFC4090]第3.1节所述的一对一备份。如[RFC4090]第4.2节所述，可在一对一备份方法中使用迂回对象来识别迂回LSP。在一对一备份方法中，如果旁路隧道已在上游PLR处使用，则应向下游PLR发送一条带有错误代码“FRR旁路分配错误”（值44）和子代码“一对一旁路已在使用”（值2）的通知消息[RFC3473]。收到此错误后，下游PLR应删除旁通隧道分配，并选择备用旁通隧道（如果可用）。
The upstream PLR may receive multiple bypass tunnel assignments for a protected LSP from different downstream PLRs, leading to an asymmetric bypass tunnel assignment as shown in the following two examples.
上游PLR可以从不同的下游PLR接收用于受保护LSP的多个旁路隧道分配，从而导致如以下两个示例中所示的不对称旁路隧道分配。
As shown in Examples 1 and 2, for the protected bidirectional GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass tunnel assignments, one from downstream PLR R4 for node protection and one from downstream PLR R5 for link protection. In Example 1, R6 prefers the link protection bypass tunnel from downstream PLR R5, whereas, in Example 2, R6 prefers the node protection bypass tunnel from downstream PLR R4.
如示例1和2中所示，对于受保护的双向GMPLS LSP R4-R5-R6，上游PLR R6接收多个旁路隧道分配，一个来自下游PLR R4用于节点保护，另一个来自下游PLR R5用于链路保护。在实例1中，R6优选来自下游PLR R5的链路保护旁路隧道，而在实例2中，R6优选来自下游PLR R4的节点保护旁路隧道。
+------->>-------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
PATH -> \ /
\ /
+-<<--+
+------->>-------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
PATH -> \ /
\ /
+-<<--+
Example 1: Link Protection Is Preferred on Downstream MP
示例1：链路保护优先于下游MP
+------->>--------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
+------->>--------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
\ PATH -> /
\ /
\ /
+-------<<--------+
\ PATH -> /
\ /
\ /
+-------<<--------+
Example 2: Node Protection Is Preferred on Downstream MP
示例2：下游MP上首选节点保护
The asymmetry of bypass tunnel assignments can be avoided by using the flags in the SESSION_ATTRIBUTE object defined in Section 4.3 of [RFC4090]. In particular, the "node protection desired" flag is signaled by the head-end node to request node protection bypass tunnels. When this flag is set, both downstream PLR and upstream PLR nodes assign node protection bypass tunnels as shown in Example 2. When the "node protection desired" flag is not set, the downstream PLR nodes may only signal the link protection bypass tunnels avoiding the asymmetry of bypass tunnel assignments shown in Example 1.
旁路通道分配的不对称性可以通过使用[RFC4090]第4.3节中定义的会话_属性对象中的标志来避免。特别地，“所需节点保护”标志由前端节点发出信号以请求节点保护旁路隧道。当设置该标志时，下游PLR和上游PLR节点都分配节点保护旁路隧道，如示例2所示。当未设置“所需节点保护”标志时，下游PLR节点可仅向链路保护旁路隧道发送信号，以避免示例1中所示的旁路隧道分配的不对称性。
When multiple bypass tunnel assignments are received, the upstream PLR SHOULD send a Notify message [RFC3473] with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code "Bypass Assignment Cannot Be Used" (value 0) to the downstream PLR to indicate that it cannot use the bypass tunnel assignment in the reverse direction. Upon receiving this error, the downstream PLR MAY remove the bypass tunnel assignment and select an alternate bypass tunnel if one is available.
当接收到多个旁通隧道分配时，上游PLR应向下游PLR发送一条带有错误代码“FRR旁通分配错误”（值44）和子代码“无法使用旁通分配”（值0）的通知消息[RFC3473]，以指示其无法反向使用旁通隧道分配。收到此错误后，下游PLR可移除旁通隧道分配，并选择备用旁通隧道（如果可用）。
If multiple bypass tunnel assignments are present on the upstream PLR R6 at the time of a failure, any resulted asymmetry gets corrected using the procedure for restoring co-routing after FRR as specified in Section 5.2.2.
如果在发生故障时上游PLR R6上存在多个旁通隧道分配，则使用第5.2.2节中规定的FRR后恢复共路由的程序纠正任何产生的不对称。
When a bidirectional bypass tunnel is used after a link failure, the following procedure is followed when using the in-band signaling:
当链路故障后使用双向旁路隧道时，使用带内信令时遵循以下程序：
o The downstream PLR reroutes protected LSP traffic and RSVP Path signaling over the bidirectional bypass tunnel using the procedures defined in [RFC4090]. The RSVP Path messages are modified as described in Section 6.4.3 of [RFC4090].
o 下游PLR使用[RFC4090]中定义的程序，通过双向旁路隧道重新路由受保护的LSP流量和RSVP路径信令。按照[RFC4090]第6.4.3节所述修改RSVP路径消息。
o The upstream PLR reroutes protected LSP traffic upon detecting the link failure or upon receiving an RSVP Path message over the bidirectional bypass tunnel.
o 上游PLR在检测到链路故障或通过双向旁路隧道接收到RSVP Path消息时重新路由受保护的LSP通信量。
o The upstream PLR also reroutes protected LSP RSVP Resv signaling after receiving the modified RSVP Path message over the bidirectional bypass tunnel. The upstream PLR uses the procedure defined in Section 7 of [RFC4090] to detect that RSVP Path messages have been rerouted over the bypass tunnel by the downstream PLR. The upstream PLR does not modify the RSVP Resv message before sending it over the bypass tunnel.
o 在通过双向旁路隧道接收到修改的RSVP Path消息之后，上游PLR还重新路由受保护的LSP RSVP Resv信令。上游PLR使用[RFC4090]第7节中定义的程序检测RSVP路径消息是否已被下游PLR通过旁通隧道重新路由。上游PLR在通过旁通隧道发送RSVP Resv消息之前不会修改该消息。
The above procedure allows both traffic and RSVP signaling to flow on symmetric paths in the forward and reverse directions of a protected bidirectional GMPLS LSP. The following sections describe the handling for link protection and node protection bypass tunnels.
上述过程允许业务和RSVP信令在受保护的双向GMPLS LSP的正向和反向对称路径上流动。以下章节描述了链路保护和节点保护旁路隧道的处理。
<- RESV
[R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<----->>+
T3
PATH ->
<- RESV
<- RESV
[R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<----->>+
T3
PATH ->
<- RESV
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T3: {R3-R4}
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T3: {R3-R4}
Figure 1: Flow of RSVP Signaling after Link Failure and FRR
图1：链路故障和FRR后的RSVP信令流
Consider the TE network shown in Figure 1. Assume that every link in the network is protected with a link protection bypass tunnel (e.g., bypass tunnel T3). For the protected co-routed bidirectional LSP whose head-end is on node R1 and tail-end is on node R6, each traversed node (a potential PLR) assigns a link protection co-routed bidirectional bypass tunnel.
考虑图1所示的TE网络。假设网络中的每个链路都受到链路保护旁路隧道（例如，旁路隧道T3）的保护。对于头端在节点R1上、尾端在节点R6上的受保护共路由双向LSP，每个被穿越节点（潜在PLR）分配链路保护共路由双向旁路隧道。
Consider the link R3-R4 on the protected LSP path failing. The downstream PLR R3 and upstream PLR R4 independently trigger fast reroute to redirect traffic onto bypass tunnel T3 in the forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path messages onto the bypass tunnel T3 using the procedures described in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the reverse bypass tunnel T3 upon receiving an RSVP Path message over bypass tunnel T3.
考虑在受保护LSP路径上失败的链路R3-R4。下游PLR R3和上游PLR R4独立触发快速重路由，以在正向和反向方向上将流量重定向到旁通隧道T3上。下游PLR R3还使用[RFC4090]中描述的程序将RSVP路径消息重新路由到旁路隧道T3上。上游PLR R4在通过旁路隧道T3接收到RSVP Path消息时，将RSVP Resv消息重新路由到反向旁路隧道T3。
The revertive behavior defined in [RFC4090], Section 6.5.2, is applicable to the link protection of bidirectional GMPLS LSPs. When using the local revertive mode, after the link R3-R4 (in Figure 1) is restored, following node behaviors apply:
[RFC4090]第6.5.2节中定义的回复行为适用于双向GMPLS LSP的链路保护。使用本地恢复模式时，在链接R3-R4（图1中）恢复后，将应用以下节点行为：
o The downstream PLR R3 starts sending the Path messages and traffic flow of the protected LSP over the restored link and stops sending them over the bypass tunnel.
o 下游PLR R3开始通过恢复的链路发送受保护LSP的路径消息和业务流，并停止通过旁路隧道发送它们。
o The upstream PLR R4 starts sending the traffic flow of the protected LSP over the restored link and stops sending it over the bypass tunnel.
o 上游PLR R4开始通过恢复的链路发送受保护LSP的业务流，并停止通过旁通隧道发送。
o When upstream PLR R4 receives the protected LSP Path messages over the restored link, if not already done, it starts sending Resv messages and traffic flow of the protected LSP over the restored link and stops sending them over the bypass tunnel.
o 当上游PLR R4通过恢复的链路接收到受保护的LSP路径消息时，如果尚未接收到，则它开始通过恢复的链路发送Resv消息和受保护的LSP的业务流，并停止通过旁路隧道发送它们。
T1
+<<------->>+
/ \
/ \ <- RESV
[R1]----[R2]----[R3]--x--[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<------->>+
T2
T1
+<<------->>+
/ \
/ \ <- RESV
[R1]----[R2]----[R3]--x--[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<------->>+
T2
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5}
R4's Bypass T1: {R4-R2}
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5}
R4's Bypass T1: {R4-R2}
Figure 2: Flow of RSVP Signaling after Link Failure and FRR
图2：链路故障和FRR后的RSVP信令流
Consider the TE network shown in Figure 2. Assume that every link in the network is protected with a node protection bypass tunnel. For the protected co-routed bidirectional LSP whose head-end is on node R1 and tail-end is on node R6, each traversed node (a potential PLR) assigns a node protection co-routed bidirectional bypass tunnel.
考虑图2所示的TE网络。假设网络中的每个链路都受到节点保护旁路隧道的保护。对于头端在节点R1上、尾端在节点R6上的受保护共路由双向LSP，每个被穿越节点（潜在PLR）分配一个节点保护共路由双向旁路隧道。
The solution introduces two phases for invoking FRR procedures by the PLR after the link failure. The first phase comprises of FRR procedures to fast reroute data traffic onto bypass tunnels in the forward and reverse directions. The second phase restores the co-routing of signaling and data traffic in the forward and reverse directions after the first phase.
该解决方案引入了两个阶段，用于在链路故障后由PLR调用FRR过程。第一阶段包括FRR程序，以在正向和反向快速将数据流量重新路由到旁通隧道。第二阶段在第一阶段之后恢复正向和反向信令和数据业务的共同路由。
Consider a link R3-R4 (in Figure 2) on the protected LSP path failing. The downstream PLR R3 and upstream PLR R4 independently trigger fast reroute procedures to redirect the protected LSP traffic onto respective bypass tunnels T2 and T1 in the forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path messages over the bypass tunnel T2 using the procedures described in [RFC4090]. Note, at this point, that node R4 stops receiving RSVP Path refreshes for the protected bidirectional LSP while protected traffic continues to flow over bypass tunnels. As node R4 does not receive Path messages over bypass tunnel T1, it does not reroute RSVP Resv messages over the reverse bypass tunnel T1.
考虑受保护LSP路径失败的链接R3-R4（见图2）。下游PLR R3和上游PLR R4独立地触发快速重路由程序，以将受保护的LSP业务重定向到正向和反向的各自旁通隧道T2和T1上。下游PLR R3还使用[RFC4090]中描述的程序在旁路隧道T2上重新路由RSVP路径消息。注意，此时，节点R4停止接收受保护双向LSP的RSVP路径刷新，而受保护的流量继续流过旁路隧道。由于节点R4不通过旁路隧道T1接收路径消息，因此它不通过反向旁路隧道T1重新路由RSVP Resv消息。
The downstream MP R5 that receives the rerouted protected LSP RSVP Path message through the bypass tunnel, in addition to the regular MP processing defined in [RFC4090], gets promoted to a Point of Remote Repair (PRR) role and performs the following actions to restore co-routing signaling and data traffic over the same path in the reverse direction:
除了[RFC4090]中定义的常规MP处理外，通过旁路隧道接收重新路由的受保护LSP RSVP Path消息的下游MP R5将升级到远程修复点（PRR）角色，并执行以下操作以恢复反向同一路径上的共同路由信令和数据流量：
o Finds the bypass tunnel in the reverse direction that terminates on the downstream PLR R3. Note: the downstream PLR R3's address can be extracted from the "IPV4 tunnel sender address" in the SENDER_TEMPLATE Object of the protected LSP (see [RFC4090], Section 6.1.1).
o 在终止于下游PLR R3的相反方向上查找旁通隧道。注：下游PLR R3的地址可以从受保护LSP的发送方模板对象中的“IPV4隧道发送方地址”中提取（请参见[RFC4090]，第6.1.1节）。
o If the reverse bypass tunnel is found and the protected LSP traffic is not already rerouted over the found bypass tunnel T2, the PRR R5 activates FRR reroute procedures to direct traffic over the found bypass tunnel T2 in the reverse direction. In addition, the PRR R5 also reroutes RSVP Resv over the bypass tunnel T2 in the reverse direction. This can happen when the downstream PLR
o 如果发现反向旁通隧道，且受保护的LSP流量尚未在发现的旁通隧道T2上重新路由，则PRR R5激活FRR重新路由程序，以在发现的旁通隧道T2上反向引导流量。此外，PRR R5还以相反方向在旁通隧道T2上重新路由RSVP Resv。当下游PLR
has changed the bypass tunnel assignment but the upstream PLR has not yet processed the updated Path RRO and programmed the data plane when link failure occurs.
已更改旁通隧道分配，但上游PLR尚未处理更新的路径RRO，并在发生链路故障时对数据平面进行编程。
o If the reverse bypass tunnel is not found, the PRR R5 immediately tears down the protected LSP.
o 如果未找到反向旁通通道，PRR R5会立即拆除受保护的LSP。
<- RESV
[R1]----[R2]----[R3]--X--[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<------->>+
<- RESV
[R1]----[R2]----[R3]--X--[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<------->>+
Bypass Tunnel T2
绕行隧道T2
traffic + signaling
交通+信号
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5}
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5}
Figure 3: Flow of RSVP Signaling after FRR and Restoring Co-routing
图3:FRR和恢复共同路由后的RSVP信令流
Figure 3 describes the path taken by the traffic and signaling after restoring co-routing of data and signaling in the forward and reverse paths described above. Node R4 will stop receiving the Path and Resv messages and it will timeout the RSVP soft state. However, this will not cause the LSP to be torn down. RSVP signaling at node R2 is not affected by the FRR and restoring co-routing.
图3描述了在上述正向和反向路径中恢复数据和信令的共同路由后，业务和信令所采用的路径。节点R4将停止接收Path和Resv消息，并使RSVP软状态超时。但是，这不会导致LSP被拆除。节点R2处的RSVP信令不受FRR和恢复共同路由的影响。
If downstream MP R5 receives multiple RSVP Path messages through multiple bypass tunnels (e.g., as a result of multiple failures), the PRR SHOULD identify a bypass tunnel that terminates on the farthest downstream PLR along the protected LSP path (closest to the protected bidirectional LSP head-end) and activate the reroute procedures mentioned above.
如果下游MP R5通过多个旁路隧道接收到多个RSVP路径消息（例如，由于多个故障），则PRR应识别一个旁路隧道，该旁路隧道终止于沿受保护LSP路径的最远下游PLR（最接近受保护的双向LSP头端）并启动上述重新路由程序。
The downstream MP (upstream PLR) MAY optionally support restoring co-routing in the data plane as follows. If the downstream MP has assigned a bidirectional bypass tunnel, as soon as the downstream MP receives the protected LSP packets on the bypass tunnel, it MAY switch the upstream traffic on to the bypass tunnel. In order to identify the protected LSP packets through the bypass tunnel, Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled. The downstream MP checks whether the protected LSP signaling is rerouted over the found bypass tunnel, and if not, it performs the signaling procedure described in Section 5.2.2.
下游MP（上游PLR）可以可选地支持恢复数据平面中的共路由，如下所示。如果下游MP已经分配了双向旁路隧道，则一旦下游MP在旁路隧道上接收到受保护的LSP分组，它就可以将上游业务切换到旁路隧道。为了通过旁路隧道识别受保护的LSP数据包，必须禁用旁路隧道的倒数第二跳弹出（PHP）。下游MP检查受保护的LSP信令是否在找到的旁路隧道上重新路由，如果没有，则执行第5.2.2节所述的信令程序。
The revertive behavior defined in [RFC4090], Section 6.5.2, is applicable to the node protection of bidirectional GMPLS LSPs. When using the local revertive mode, after the link R3-R4 (in Figures 2 and 3) is restored, the following node behaviors apply:
[RFC4090]第6.5.2节中定义的回复行为适用于双向GMPLS LSP的节点保护。当使用本地恢复模式时，链路R3-R4（图2和图3中）恢复后，以下节点行为适用：
o The downstream PLR R3 starts sending the Path messages and traffic flow of the protected LSP over the restored link and stops sending them over the bypass tunnel.
o 下游PLR R3开始通过恢复的链路发送受保护LSP的路径消息和业务流，并停止通过旁路隧道发送它们。
o The upstream PLR R4 (when the protected LSP is present) starts sending the traffic flow of the protected LSP over the restored link towards downstream PLR R3 and forwarding the Path messages towards PRR R5 and stops sending the traffic over the bypass tunnel.
o 上游PLR R4（当受保护LSP存在时）开始通过恢复的链路向下游PLR R3发送受保护LSP的业务流，并向PRR R5转发路径消息，并停止通过旁路隧道发送业务。
o When upstream PLR R4 receives the protected LSP Path messages over the restored link, if not already done, the node R4 (when the protected LSP is present) starts sending Resv messages and traffic flow over the restored link towards downstream PLR R3 and forwarding the Path messages towards PRR R5 and stops sending them over the bypass tunnel.
o 当上游PLR R4通过恢复的链路接收到受保护的LSP路径消息时，如果尚未完成，则节点R4（当受保护的LSP存在时）开始通过恢复的链路向下游PLR R3发送Resv消息和业务流，并向PRR R5转发路径消息，并停止通过旁路隧道发送它们。
o When PRR R5 receives the protected LSP Path messages over the restored path, it starts sending Resv messages and traffic flow over the restored path and stops sending them over the bypass tunnel.
o 当PRR R5通过恢复的路径接收到受保护的LSP路径消息时，它开始通过恢复的路径发送Resv消息和流量，并停止通过旁路隧道发送它们。
Consider the node R4 (in Figure 3) on the protected LSP path failing. The downstream PLR R3 and upstream PLR R5 independently trigger fast reroute procedures to redirect the protected LSP traffic onto bypass tunnel T2 in forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path messages over the bypass tunnel T2 using the procedures described in [RFC4090]. The upstream PLR R5 reroutes RSVP Resv signaling after receiving the modified RSVP Path message over the bypass tunnel T2.
考虑受保护LSP路径失败的节点R4（见图3）。下游PLR R3和上游PLR R5独立地触发快速重路由程序，以将受保护的LSP业务在正向和反向方向上重定向到旁通隧道T2上。下游PLR R3还使用[RFC4090]中描述的程序在旁路隧道T2上重新路由RSVP路径消息。上游PLR R5在通过旁路隧道T2接收到修改的RSVP Path消息之后重新路由RSVP Resv信令。
Unidirectional link failures can result in the traffic flowing on asymmetric paths in the forward and reverse directions. In addition, unidirectional link failures can cause RSVP soft-state timeout in the control plane in some cases. As an example, if the unidirectional link failure is in the upstream direction (from R4 to R3 in Figures 1 and 2), the downstream PLR (node R3) can stop receiving the Resv
单向链路故障可能导致流量在正向和反向的不对称路径上流动。此外，在某些情况下，单向链路故障会导致控制平面中的RSVP软状态超时。例如，如果单向链路故障在上游方向（图1和2中从R4到R3），则下游PLR（节点R3）可以停止接收Resv
messages of the protected LSP from the upstream PLR (node R4 in Figures 1 and 2) and this can cause RSVP soft-state timeout to occur on the downstream PLR (node R3).
来自上游PLR（图1和图2中的节点R4）的受保护LSP的消息，这可能导致下游PLR（节点R3）上发生RSVP软状态超时。
A unidirectional link failure in the downstream direction (from R3 to R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when using the FRR procedures defined in this document, since the upstream PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the procedure to restore co-routing (defined in Section 5.2.2) after receiving RSVP Path messages of the protected LSP over the bypass tunnel from the downstream PLR (node R3 in Figures 1 and 2).
当使用本文件中定义的FRR程序时，下游方向（图1和图2中从R3到R4）的单向链路故障不会导致RSVP软状态超时，因为上游PLR（图1中的节点R4和图2中的节点R5）触发恢复共同路由的程序（在第5.2.2节中定义）从下游PLR（图1和图2中的节点R3）通过旁路隧道接收受保护LSP的RSVP路径消息后。
When using the GMPLS out-of-band signaling [RFC3473], after a link failure event, the RSVP messages are not rerouted over the bidirectional bypass tunnel by the downstream and upstream PLRs but are instead rerouted over the control channels to the downstream and upstream MPs, respectively.
当使用GMPLS带外信令[RFC3473]时，在发生链路故障事件后，下游和上游PLR不会通过双向旁路隧道重新路由RSVP消息，而是通过控制信道分别重新路由到下游和上游MPs。
The RSVP soft-state timeout after FRR as described in Section 5.2 is equally applicable to the GMPLS out-of-band signaling as the RSVP signaling refreshes can stop reaching certain nodes along the protected LSP path after the downstream and upstream PLRs finish rerouting of the signaling messages. However, unlike with the in-band signaling, unidirectional link failures as described in Section 5.3 do not result in soft-state timeout with GMPLS out-of-band signaling. Apart from this, the FRR procedure described in Section 5 is equally applicable to the GMPLS out-of-band signaling.
第5.2节所述FRR后的RSVP软状态超时同样适用于GMPLS带外信令，因为在下游和上游PLR完成信令消息的重新路由后，RSVP信令刷新可以停止到达受保护LSP路径上的某些节点。然而，与带内信令不同，第5.3节中描述的单向链路故障不会导致GMPLS带外信令的软状态超时。除此之外，第5节中描述的FRR程序同样适用于GMPLS带外信令。
The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP of the bypass tunnel being assigned by the PLR. This can be used to coordinate the bypass tunnel assignment for the protected LSP by the downstream and upstream PLRs in the forward and reverse directions respectively prior or after the failure occurrence.
旁路分配子对象用于通知下游MP PLR分配的旁路隧道。这可用于在故障发生之前或之后，分别在正向和反向上协调下游和上游PLR对受保护LSP的旁通隧道分配。
This subobject SHOULD be inserted into the Path RRO by the downstream PLR. It SHOULD NOT be inserted into an RRO by a node that is not a downstream PLR. It MUST NOT be changed by downstream LSRs and MUST NOT be added to a Resv RRO.
该子对象应由下游PLR插入到路径RRO中。它不应由不是下游PLR的节点插入到RRO中。下游LSR不得对其进行更改，也不得将其添加到Resv RRO中。
The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format:
RRO中的IPv4子对象具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: 38 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Bypass Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: 38 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Bypass Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject
图4：旁路分配IPv4错误子对象
Type
类型
Downstream Bypass Assignment. Value is 38.
下游旁路分配。值为38。
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The length is 8 bytes.
长度包含子对象的总长度（字节），包括类型和长度字段。长度为8字节。
Bypass Tunnel ID
旁通隧道ID
The bypass tunnel identifier (16 bits).
旁路通道标识符（16位）。
Bypass Destination Address
绕过目标地址
The bypass tunnel IPv4 destination address.
旁路隧道IPv4目标地址。
The BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format:
RRO中的旁路分配IPv6子对象具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: 39 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Bypass Destination Address |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: 39 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Bypass Destination Address |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject
图5：旁路分配IPv6 RRO子对象
Type
类型
Downstream Bypass Assignment. Value is 39.
下游旁路分配。值为39。
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The length is 20 bytes.
长度包含子对象的总长度（字节），包括类型和长度字段。长度为20字节。
Bypass Tunnel ID
旁通隧道ID
The bypass tunnel identifier (16 bits).
旁路通道标识符（16位）。
Bypass Destination Address
绕过目标地址
The bypass tunnel IPv6 destination address.
旁路隧道IPv6目标地址。
New Error Code "FRR Bypass Assignment Error" (value 44) and its sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] in this document, that is carried by the Notify message (Type 21) defined in [RFC3473] Section 4.3. This Error message is sent by the upstream PLR to the downstream PLR to notify a bypass assignment error. In the Notify message, the IP destination address is set to the node address of the downstream PLR that had initiated the bypass assignment. In the ERROR_SPEC Object, the IP address is set to the
本文件中为[RFC3473]第4.3节中定义的通知消息（类型21）携带的错误规范对象（C-Type 6）[RFC2205]定义了新的错误代码“FRR旁路分配错误”（值44）及其子代码。该错误消息由上游PLR发送至下游PLR，以通知旁路分配错误。在Notify消息中，IP目的地地址设置为启动旁路分配的下游PLR的节点地址。在ERROR_SPEC对象中，IP地址设置为
node address of the upstream PLR that detected the bypass assignment error. This Error MUST NOT be sent in a Path Error message. This Error does not cause the protected LSP to be torn down.
检测到旁路分配错误的上游PLR的节点地址。此错误不能在路径错误消息中发送。此错误不会导致受保护的LSP被拆除。
New RSVP subobject BYPASS_ASSIGNMENT is defined for the RECORD_ROUTE Object in this document that is carried in the RSVP Path message. Per [RFC3209], nodes not supporting this subobject will ignore the subobject but forward it without modification. As described in Section 7, this subobject is not carried in the RSVP Resv message and is ignored by sending the Notify message for "FRR Bypass Assignment Error" (with Sub-code "Bypass Assignment Cannot Be Used") defined in this document. Nodes not supporting the Notify message defined in this document will ignore it but forward it without modification.
为RSVP Path消息中携带的本文档中的记录路由对象定义了新的RSVP子对象旁路分配。根据[RFC3209]，不支持此子对象的节点将忽略该子对象，但会转发它而不进行修改。如第7节所述，RSVP Resv消息中不包含该子对象，通过发送本文档中定义的“FRR旁路分配错误”（子代码为“无法使用旁路分配”）的通知消息，该子对象将被忽略。不支持此文档中定义的Notify消息的节点将忽略该消息，但会在不进行修改的情况下转发该消息。
This document introduces a new BYPASS_ASSIGNMENT subobject for the RECORD_ROUTE Object that is carried in an RSVP signaling message. Thus, in the event of the interception of a signaling message, more information about the LSP's fast reroute protection can be deduced than was previously the case. This is judged to be a very minor security risk as this information is already available by other means. If an MP does not find a matching bypass tunnel with given source and destination addresses locally, it ignores the BYPASS_ASSIGNMENT subobject. Due to this, security risks introduced by inserting a random address in this subobject is minimal. The Notify message for the "FRR Bypass Assignment Error" defined in this document does not result in tear-down of the protected LSP and does not affect service.
本文档为RSVP信令消息中携带的记录路由对象引入了一个新的旁路分配子对象。因此，在信令消息被截获的情况下，可以推断出比以前更多关于LSP的快速重路由保护的信息。这被认为是一个非常小的安全风险，因为此信息已经通过其他方式提供。如果MP在本地找不到具有给定源地址和目标地址的匹配旁路隧道，它将忽略旁路分配子对象。因此，在此子对象中插入随机地址所带来的安全风险最小。本文档中定义的“FRR旁路分配错误”的通知消息不会导致受保护LSP的中断，也不会影响服务。
Security considerations for RSVP-TE and GMPLS signaling extensions are covered in [RFC3209] and [RFC3473]. Further, general considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in [RFC5920]. This document updates the mechanisms defined in [RFC4090], which also discusses related security measures that are also applicable to this document. As specified in [RFC4090], a PLR and its selected merge point trust RSVP messages received from each other. The security considerations pertaining to the original RSVP protocol [RFC2205] also remain relevant to the updates in this document.
[RFC3209]和[RFC3473]中介绍了RSVP-TE和GMPLS信令扩展的安全注意事项。此外，在MPLS-TE和GMPLS网络中保护RSVP-TE的一般注意事项见[RFC5920]。本文件更新了[RFC4090]中定义的机制，其中还讨论了同样适用于本文件的相关安全措施。如[RFC4090]所述，PLR及其所选合并点信任RSVP消息相互接收。与原始RSVP协议[RFC2205]相关的安全注意事项也与本文档中的更新相关。
IANA manages the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). IANA has assigned a value for the new BYPASS_ASSIGNMENT subobject in the "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.
IANA管理“资源预留协议（RSVP）参数”注册表（请参阅<http://www.iana.org/assignments/rsvp-parameters>). IANA已在“Class Type 21 ROUTE_RECORD-Type 1 ROUTE RECORD”注册表中为新的旁路_分配子对象分配了一个值。
This document introduces a new subobject for the RECORD_ROUTE Object:
本文档为RECORD_ROUTE对象引入了一个新的子对象：
+------+----------------------+------------+------------+-----------+
| Type | Description | Carried in | Carried in | Reference |
| | | Path | Resv | |
+------+----------------------+------------+------------+-----------+
| 38 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| | IPv4 subobject | | | |
| | | | | |
| 39 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| | IPv6 subobject | | | |
+------+----------------------+------------+------------+-----------+
+------+----------------------+------------+------------+-----------+
| Type | Description | Carried in | Carried in | Reference |
| | | Path | Resv | |
+------+----------------------+------------+------------+-----------+
| 38 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| | IPv4 subobject | | | |
| | | | | |
| 39 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| | IPv6 subobject | | | |
+------+----------------------+------------+------------+-----------+
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). The "Error Codes and Globally-Defined Error Value Sub-Codes" subregistry is included in this registry.
IANA维护“资源预留协议（RSVP）参数”注册表（请参阅<http://www.iana.org/assignments/rsvp-parameters>). “错误代码和全局定义的错误值子代码”子区域包含在此注册表中。
This registry has been extended for the new Error Code and Sub-codes defined in this document as follows:
此注册表已针对本文档中定义的新错误代码和子代码进行了扩展，如下所示：
o Error Code 44: FRR Bypass Assignment Error
o 错误代码44:FRR旁路分配错误
o Sub-code 0: Bypass Assignment Cannot Be Used
o 子代码0:无法使用旁路分配
o Sub-code 1: Bypass Tunnel Not Found
o 子代码1：未找到旁通隧道
o Sub-code 2: One-to-One Bypass Already in Use
o 子代码2：一对一旁路已在使用
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<https://www.rfc-editor.org/info/rfc2205>.
[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, <https://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月<https://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, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<https://www.rfc-editor.org/info/rfc3473>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 4090，DOI 10.17487/RFC4090，2005年5月<https://www.rfc-editor.org/info/rfc4090>.
[RFC4561] Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition of a Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, DOI 10.17487/RFC4561, June 2006, <https://www.rfc-editor.org/info/rfc4561>.
[RFC4561]Vasseur，J.，Ed.，Ali，Z.，和S.Sivabalan，“记录路由对象（RRO）节点Id子对象的定义”，RFC 4561，DOI 10.17487/RFC4561，2006年6月<https://www.rfc-editor.org/info/rfc4561>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，DOI 10.17487/RFC3471，2003年1月<https://www.rfc-editor.org/info/rfc3471>.
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990, September 2007, <https://www.rfc-editor.org/info/rfc4990>.
[RFC4990]Shiomoto，K.，Papneya，R.和R.Rabbat，“通用多协议标签交换（GMPLS）网络中地址的使用”，RFC 4990，DOI 10.17487/RFC4990，2007年9月<https://www.rfc-editor.org/info/rfc4990>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <https://www.rfc-editor.org/info/rfc6378>.
[RFC6378]Y.Weingarten，Ed.，Bryant，S.，Osborne，E.，Sprecher，N.，和A.Fulignoli，Ed.，“MPLS传输模式（MPLS-TP）线性保护”，RFC 6378，DOI 10.17487/RFC6378，2011年10月<https://www.rfc-editor.org/info/rfc6378>.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.
[RFC7551]Zhang，F.，Ed.，Jing，R.，和R.Gandhi，Ed.，“相关双向标签交换路径（LSP）的RSVP-TE扩展”，RFC 7551，DOI 10.17487/RFC7551，2015年5月<https://www.rfc-editor.org/info/rfc7551>.
Acknowledgements
致谢
The authors would like to thank George Swallow for many useful comments and suggestions. The authors would like to thank Lou Berger for the guidance on this work and for providing review comments. The authors would also like to thank Nobo Akiya, Loa Andersson, Matt Hartley, Himanshu Shah, Gregory Mirsky, Mach Chen, Vishnu Pavan Beeram, and Alia Atlas for reviewing this document and providing valuable comments. A special thanks to Adrian Farrel for his thorough review of this document.
作者要感谢George Swallow提出的许多有用的意见和建议。作者要感谢Lou Berger对这项工作的指导和提供的审查意见。作者还要感谢Nobo Akiya、Loa Andersson、Matt Hartley、Himanshu Shah、Gregory Mirsky、Mach Chen、Vishnu Pavan Beeram和Alia Atlas审查本文件并提供宝贵意见。特别感谢阿德里安·法雷尔对本文件的全面审查。
Contributors
贡献者
Frederic Jounay Orange Switzerland
Frederic Jounay橙色瑞士
Email: frederic.jounay@salt.ch
Email: frederic.jounay@salt.ch
Lizhong Jin Shanghai China
中国上海理中金
Email: lizho.jin@gmail.com
Email: lizho.jin@gmail.com
Authors' Addresses
作者地址
Mike Taillon Cisco Systems, Inc.
迈克·泰隆思科系统公司。
Email: mtaillon@cisco.com
Email: mtaillon@cisco.com
Tarek Saad (editor) Cisco Systems, Inc.
塔瑞克·萨阿德（编辑）思科系统公司。
Email: tsaad@cisco.com
Email: tsaad@cisco.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
Manav Bhatia Nokia Bangalore, India
Manav Bhatia诺基亚班加罗尔，印度
Email: manav.bhatia@nokia.com
Email: manav.bhatia@nokia.com