Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Request for Comments: 8537 Cisco Systems, Inc.
Updates: 4090, 7551 H. Shah
Category: Standards Track Ciena
ISSN: 2070-1721 J. Whittaker
Verizon
February 2019
Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Request for Comments: 8537 Cisco Systems, Inc.
Updates: 4090, 7551 H. Shah
Category: Standards Track Ciena
ISSN: 2070-1721 J. Whittaker
Verizon
February 2019
Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs)
更新共路由关联双向标签交换路径（LSP）的快速重路由过程
Abstract
摘要
Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document updates the fast reroute procedures defined in RFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event.
资源预留协议（RSVP）关联信令可用于将两个单向标签交换路径（LSP）绑定到关联的双向LSP中。当相关联的双向LSP被共同路由时，反向LSP遵循与其正向LSP相同的路径。本文档更新了RFC 4090中定义的快速重路由过程，以支持单边和双边配置的关联双向LSP。本文档还更新了将RFC 7551中定义的两个反向LSP关联起来以支持共路由双向LSP的过程。快速重路由程序可以确保，对于共路由LSP，在故障事件发生后，共路由路径上的流量在正向和反向上流动。
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/rfc8537.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8537.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 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 ....................................................3
1.1. Assumptions and Considerations .............................4
2. Conventions Used in This Document ...............................4
2.1. Key Word Definitions .......................................4
2.2. Terminology ................................................4
2.2.1. Forward Unidirectional LSPs .........................5
2.2.2. Reverse Co-routed Unidirectional LSPs ...............5
3. Problem Statement ...............................................5
3.1. Fast Reroute Bypass Tunnel Assignment ......................6
3.2. Node Protection Bypass Tunnels .............................6
3.3. Bidirectional LSP Association at Midpoints .................7
4. Signaling Procedure .............................................8
4.1. Associated Bidirectional LSP Fast Reroute ..................8
4.1.1. Restoring Co-routing with Node Protection
Bypass Tunnels ......................................9
4.1.2. Unidirectional Link Failures .......................10
4.1.3. Revertive Behavior after Fast Reroute ..............10
4.1.4. Bypass Tunnel Provisioning .........................10
4.1.5. One-to-One Bypass Tunnel ...........................11
4.2. Bidirectional LSP Association at Midpoints ................11
5. Compatibility ..................................................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
Appendix A. Extended Association ID ..............................14
Acknowledgments ...................................................16
Authors' Addresses ................................................16
1. Introduction ....................................................3
1.1. Assumptions and Considerations .............................4
2. Conventions Used in This Document ...............................4
2.1. Key Word Definitions .......................................4
2.2. Terminology ................................................4
2.2.1. Forward Unidirectional LSPs .........................5
2.2.2. Reverse Co-routed Unidirectional LSPs ...............5
3. Problem Statement ...............................................5
3.1. Fast Reroute Bypass Tunnel Assignment ......................6
3.2. Node Protection Bypass Tunnels .............................6
3.3. Bidirectional LSP Association at Midpoints .................7
4. Signaling Procedure .............................................8
4.1. Associated Bidirectional LSP Fast Reroute ..................8
4.1.1. Restoring Co-routing with Node Protection
Bypass Tunnels ......................................9
4.1.2. Unidirectional Link Failures .......................10
4.1.3. Revertive Behavior after Fast Reroute ..............10
4.1.4. Bypass Tunnel Provisioning .........................10
4.1.5. One-to-One Bypass Tunnel ...........................11
4.2. Bidirectional LSP Association at Midpoints ................11
5. Compatibility ..................................................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
Appendix A. Extended Association ID ..............................14
Acknowledgments ...................................................16
Authors' Addresses ................................................16
The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION Object is specified in [RFC6780] and can be used generically to associate Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for binding two point-to-point (P2P) unidirectional LSPs [RFC3209] into an associated bidirectional LSP. There are two models described in [RFC7551] for provisioning an associated bidirectional LSP: single-sided and double-sided. In both models, the reverse LSP of the bidirectional LSP may or may not be co-routed and follow the same path as its forward LSP.
资源预留协议（RSVP）（扩展）关联对象在[RFC6780]中指定，可一般用于关联多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程（TE）标签交换路径（LSP）。[RFC7551]定义了将两个点对点（P2P）单向LSP[RFC3209]绑定到相关双向LSP的机制。[RFC7551]中描述了两种用于提供相关双向LSP的模型：单边和双边。在这两种模型中，双向LSP的反向LSP可以或不可以被共路由，并且遵循与其前向LSP相同的路径。
In some packet transport networks, there are requirements where the reverse LSP of a bidirectional LSP needs to follow the same path as its forward LSP [RFC6373]. The MPLS Transport Profile (MPLS-TP) [RFC6370] architecture facilitates the co-routed bidirectional LSP by using GMPLS extensions [RFC3473] to achieve congruent paths. However, RSVP association signaling allows enabling co-routed bidirectional LSPs without having to deploy GMPLS extensions in the existing networks. The association signaling also allows taking advantage of the existing TE and fast reroute mechanisms in the network.
在一些分组传输网络中，存在双向LSP的反向LSP需要遵循与其正向LSP相同的路径的要求[RFC6373]。MPLS传输配置文件（MPLS-TP）[RFC6370]体系结构通过使用GMPLS扩展[RFC3473]来实现一致路径，从而促进共路由双向LSP。然而，RSVP关联信令允许启用共路由双向LSP，而无需在现有网络中部署GMPLS扩展。关联信令还允许利用网络中现有的TE和快速重路由机制。
[RFC4090] defines fast reroute extensions for RSVP-TE LSPs, which are also applicable to the associated bidirectional LSPs. [RFC8271] defines fast reroute procedures for GMPLS signaled bidirectional LSPs such as coordinating bypass tunnel assignments in the forward and reverse directions of the LSP. The mechanisms defined in [RFC8271] are also useful for the fast reroute of associated bidirectional LSPs.
[RFC4090]定义了RSVP-TE LSP的快速重路由扩展，该扩展也适用于相关的双向LSP。[RFC8271]定义了GMPLS信号双向LSP的快速重路由程序，如协调LSP正向和反向的旁路隧道分配。[RFC8271]中定义的机制也可用于相关双向LSP的快速重新路由。
This document updates the fast reroute procedures defined in [RFC4090] to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in [RFC7551] to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after fast reroute.
本文档更新了[RFC4090]中定义的快速重路由过程，以支持单边和双边配置的相关双向LSP。本文档还更新了将[RFC7551]中定义的两个反向LSP关联起来以支持共路由双向LSP的过程。快速重路由程序可确保对于共路由LSP，在快速重路由后，共路由路径上的业务流在正向和反向上流动。
The following assumptions and considerations apply to this document:
以下假设和注意事项适用于本文件：
o The fast reroute procedure for the unidirectional LSPs is defined in [RFC4090] and is not modified by this document.
o 单向LSP的快速重路由程序在[RFC4090]中定义，本文件未对其进行修改。
o The fast reroute procedure when using unidirectional bypass tunnels is defined in [RFC4090] and is not modified by this document.
o [RFC4090]中定义了使用单向旁通隧道时的快速重路由程序，本文件未对其进行修改。
o This document assumes that the fast reroute bypass tunnels used for protected associated bidirectional LSPs are also associated bidirectional.
o 本文档假设用于受保护的关联双向LSP的快速重路由旁路隧道也是关联双向的。
o This document assumes that the fast reroute bypass tunnels used for protected co-routed associated bidirectional LSPs are also co-routed associated bidirectional.
o 本文档假设用于受保护的同路由关联双向LSP的快速重路由旁路隧道也是同路由关联双向LSP。
o The fast reroute procedure to coordinate the bypass tunnel assignment defined in this document may be used for protected associated bidirectional LSPs that are not co-routed but requires that the downstream Point of Local Repair (PLR) and Merge Point (MP) pair of the forward LSP matches the upstream MP and PLR pair of the reverse LSP.
o 本文件中定义的用于协调旁通隧道分配的快速重路由程序可用于受保护的相关双向LSP，该双向LSP不是共路由的，但要求正向LSP的下游本地修复点（PLR）和合并点（MP）对与反向LSP的上游MP和PLR对相匹配。
o Unless otherwise specified in this document, the fast reroute procedures defined in [RFC4090] are used for associated bidirectional LSPs.
o 除非本文件另有规定，否则[RFC4090]中定义的快速重路由程序用于相关的双向LSP。
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 defined in [RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271].
假定读者熟悉[RFC2205]、[RFC3209]、[RFC4090]、[RFC7551]和[RFC8271]中定义的术语。
Two reverse unidirectional P2P LSPs are set up in opposite directions between a pair of source and destination nodes to form an associated bidirectional LSP. In the case of single-sided provisioned LSP, the originating LSP with a REVERSE_LSP Object [RFC7551] is identified as a forward unidirectional LSP. In the case of double-sided provisioned LSP, the LSP originating from the higher node address (as source) and terminating on the lower node address (as destination) is identified as a forward unidirectional LSP.
在一对源节点和目的节点之间的相反方向上设置两个反向单向P2P LSP，以形成相关联的双向LSP。在单边供应LSP的情况下，具有反向LSP对象[RFC7551]的发起LSP被标识为前向单向LSP。在双面供应LSP的情况下，从较高节点地址（作为源）发起并终止于较低节点地址（作为目的地）的LSP被标识为前向单向LSP。
Two reverse unidirectional P2P LSPs are set up in opposite directions between a pair of source and destination nodes to form an associated bidirectional LSP. A reverse unidirectional LSP originates on the same node where the forward unidirectional LSP terminates, and it terminates on the same node where the forward unidirectional LSP originates. A reverse co-routed unidirectional LSP traverses along the same path as the forward-direction unidirectional LSP in the opposite direction.
在一对源节点和目的节点之间的相反方向上设置两个反向单向P2P LSP，以形成相关联的双向LSP。反向单向LSP在前向单向LSP终止的同一节点上发起，并在前向单向LSP发起的同一节点上终止。反向共路由单向LSP沿着与正向单向LSP相反的路径进行遍历。
As specified in [RFC7551], in the single-sided provisioning case, the RSVP-TE tunnel is configured only on one endpoint node of the bidirectional LSP. An LSP for this tunnel is initiated by the originating endpoint with the (Extended) ASSOCIATION Object containing Association Type set to "Single-Sided Associated Bidirectional LSP" and the REVERSE_LSP Object inserted in the RSVP Path message. The remote endpoint then creates the corresponding reverse TE tunnel and signals the reverse LSP in response using the information from the REVERSE_LSP Object and other objects present in the received RSVP Path message. As specified in [RFC7551], in the double-sided provisioning case, the RSVP-TE tunnel is configured on both endpoint nodes of the bidirectional LSP. Both forward and reverse LSPs are initiated independently by the two endpoints with the (Extended) ASSOCIATION Object containing Association Type set to "Double-Sided Associated Bidirectional LSP". With both single-sided and double-sided provisioned bidirectional LSPs, the reverse LSP may or may not be congruent (i.e., co-routed) and follow the same path as its forward LSP.
如[RFC7551]所述，在单边供应情况下，RSVP-TE隧道仅在双向LSP的一个端点节点上配置。此隧道的LSP由原始端点启动，其中包含关联类型的（扩展）关联对象设置为“单边关联双向LSP”，反向\u LSP对象插入RSVP路径消息中。然后，远程端点创建相应的反向TE隧道，并使用来自反向LSP对象和接收到的RSVP Path消息中存在的其他对象的信息向反向LSP发送响应信号。如[RFC7551]中所述，在双面供应情况下，在双向LSP的两个端点节点上配置RSVP-TE隧道。正向和反向LSP均由两个端点独立启动，其中包含关联类型的（扩展）关联对象设置为“双边关联双向LSP”。对于单边和双边供应的双向LSP两者，反向LSP可以是一致的（即，共路由），也可以不是一致的，并且遵循与其前向LSP相同的路径。
Both single-sided and double-sided associated bidirectional LSPs require solutions to the following issues for fast reroute to ensure co-routing after a failure event.
单边和双边相关双向LSP都需要解决以下问题，以便快速重新路由，以确保故障事件后的共同路由。
In order to ensure that the traffic flows on a co-routed path after a link or node failure on the protected co-routed LSP path, the midpoint PLR nodes need to assign matching bidirectional bypass tunnels for fast reroute. Such bypass assignment requires coordination between the PLR nodes in both the forward and reverse directions when more than one bypass tunnel is present on a PLR node.
为了确保在受保护的共同路由LSP路径上的链路或节点故障后，流量在共同路由路径上流动，中点PLR节点需要为快速重新路由分配匹配的双向旁路隧道。当PLR节点上存在多个旁路隧道时，这种旁路分配要求PLR节点在正向和反向上进行协调。
<-- Bypass N -->
+-----+ +-----+
| H +---------+ I |
+--+--+ +--+--+
| |
| |
LSP1 --> | LSP1 --> | LSP1 --> LSP1 -->
+-----+ +--+--+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
| |
| |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- Bypass S -->
<-- Bypass N -->
+-----+ +-----+
| H +---------+ I |
+--+--+ +--+--+
| |
| |
LSP1 --> | LSP1 --> | LSP1 --> LSP1 -->
+-----+ +--+--+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
| |
| |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- Bypass S -->
Figure 1: Multiple Bidirectional Bypass Tunnels
图1：多条双向旁路隧道
As shown in Figure 1, there are two bypass tunnels available: bypass tunnel N (on path B-H-I-C) and bypass tunnel S (on path B-F-G-C). The midpoint PLR nodes B and C need to coordinate bypass tunnel assignment to ensure that traffic in both directions flows through either bypass tunnel N or bypass tunnel S after the link B-C failure.
如图1所示，有两条旁通隧道可用：旁通隧道N（路径B-H-I-C）和旁通隧道S（路径B-F-G-C）。中点PLR节点B和C需要协调旁路隧道分配，以确保在链路B-C故障后，两个方向上的流量流过旁路隧道N或旁路隧道S。
When using a node protection bypass tunnel with a protected associated bidirectional LSP, after a link failure, the forward and reverse LSP traffic can flow on different node protection bypass tunnels in the upstream and downstream directions.
当使用具有受保护的关联双向LSP的节点保护旁路隧道时，在链路故障后，正向和反向LSP流量可以在上游和下游方向的不同节点保护旁路隧道上流动。
<-- Bypass N -->
+-----+ +-----+
| H +------------------------+ I |
+--+--+ +--+--+
| <-- Rerouted-LSP2 |
| |
| |
| LSP1 --> LSP1 --> | LSP1 --> LSP1 -->
+--+--+ +-----+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +-----+ +--+--+ +-----+
<-- LSP2 | <-- LSP2 <-- LSP2 | <-- LSP2
| |
| |
| Rerouted-LSP1 --> |
+--+--+ +--+--+
| F +------------------------+ G |
+-----+ +-----+
<-- Bypass S -->
<-- Bypass N -->
+-----+ +-----+
| H +------------------------+ I |
+--+--+ +--+--+
| <-- Rerouted-LSP2 |
| |
| |
| LSP1 --> LSP1 --> | LSP1 --> LSP1 -->
+--+--+ +-----+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +-----+ +--+--+ +-----+
<-- LSP2 | <-- LSP2 <-- LSP2 | <-- LSP2
| |
| |
| Rerouted-LSP1 --> |
+--+--+ +--+--+
| F +------------------------+ G |
+-----+ +-----+
<-- Bypass S -->
Figure 2: Node Protection Bypass Tunnels
图2：节点保护旁路隧道
As shown in Figure 2, after the link B-C failure, the downstream PLR node B reroutes the protected forward LSP1 traffic over bypass tunnel S (on path B-F-G-D) to reach downstream MP node D, whereas the upstream PLR node C reroutes the protected reverse LSP2 traffic over bypass tunnel N (on path C-I-H-A) to reach the upstream MP node A. As a result, the traffic in the forward and reverse directions flows on different bypass tunnels, which can cause the co-routed associated bidirectional LSP to be no longer co-routed. However, unlike GMPLS LSPs, the asymmetry of paths in the forward and reverse directions does not result in RSVP soft-state timeout with the associated bidirectional LSPs.
如图2所示，在链路B-C故障后，下游PLR节点B通过旁路隧道S（路径B-F-G-D）重新路由受保护的前向LSP1流量，以到达下游MP节点D，而上游PLR节点C通过旁路隧道N（路径C-I-H-A）重新路由受保护的反向LSP2流量，以到达上游MP节点A。因此，正向和反向的流量在不同的旁通隧道上流动，这可能导致共同路由的相关双向LSP不再共同路由。然而，与GMPLS LSP不同，正向和反向路径的不对称不会导致相关双向LSP的RSVP软状态超时。
In packet transport networks, a restoration LSP is signaled after a link failure on the protected LSP path, and the protected LSP may or may not be torn down [RFC8131]. In this case, multiple forward and reverse LSPs of a co-routed associated bidirectional LSP may be present at midpoint nodes with identical (Extended) ASSOCIATION Objects. This creates an ambiguity at midpoint nodes to identify the correct associated LSP pair for fast reroute bypass assignment (e.g., during the recovery phase of the RSVP graceful restart procedure).
在分组传输网络中，在受保护的LSP路径上发生链路故障后，会发出恢复LSP的信号，受保护的LSP可能会被拆除，也可能不会被拆除[RFC8131]。在这种情况下，具有相同（扩展）关联对象的中点节点处可能存在共同路由的关联双向LSP的多个正向和反向LSP。这会在中点节点处产生歧义，以识别用于快速重路由旁路分配的正确关联LSP对（例如，在RSVP优雅重启过程的恢复阶段）。
LSP3 --> LSP3 --> LSP3 -->
LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
<-- LSP4 | | <-- LSP4 <-- LSP4
| |
| LSP3 --> |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- Bypass S -->
<-- LSP4
LSP3 --> LSP3 --> LSP3 -->
LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
<-- LSP4 | | <-- LSP4 <-- LSP4
| |
| LSP3 --> |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- Bypass S -->
<-- LSP4
Figure 3: Restoration LSP Setup after Link Failure
图3：链路故障后恢复LSP设置
As shown in Figure 3, the protected LSPs (LSP1 and LSP2) are an associated LSP pair; similarly, the restoration LSPs (LSP3 and LSP4) are an associated LSP pair. Both pairs belong to the same associated bidirectional LSP and carry identical (Extended) ASSOCIATION Objects. In this example, the midpoint node D may mistakenly associate LSP1 with the reverse LSP4 instead of the reverse LSP2 due to the matching (Extended) ASSOCIATION Objects. This may cause the co-routed associated bidirectional LSP to be no longer co-routed after fast reroute. Since the bypass assignment needs to be coordinated between the forward and reverse LSPs, this can also lead to undesired bypass tunnel assignments.
如图3所示，受保护的LSP（LSP1和LSP2）是相关联的LSP对；类似地，恢复LSP（LSP3和LSP4）是相关联的LSP对。这两对都属于相同的关联双向LSP，并且携带相同的（扩展的）关联对象。在该示例中，由于匹配（扩展）关联对象，中点节点D可能错误地将LSP1与反向LSP4而不是反向LSP2关联。这可能导致在快速重新路由后，共同路由的相关双向LSP不再共同路由。由于旁路分配需要在正向和反向LSP之间进行协调，这也可能导致不需要的旁路隧道分配。
For both single-sided and double-sided associated bidirectional LSPs, the fast reroute procedure specified in [RFC4090] is used. In addition, the mechanisms defined in [RFC8271] are used as follows:
对于单边和双边相关双向LSP，使用[RFC4090]中规定的快速重路由程序。此外，使用[RFC8271]中定义的机制如下：
o The BYPASS_ASSIGNMENT IPv4 subobject (value 38) and IPv6 subobject (value 39) defined in [RFC8271] are used to coordinate bypass tunnel assignment between the PLR nodes in both the forward and reverse directions (see Figure 1). The BYPASS_ASSIGNMENT and Node-ID address [RFC4561] subobjects MUST be added by the downstream PLR node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of the forward LSP to indicate the local bypass tunnel assignment using the procedure defined in [RFC8271]. The upstream node uses the bypass assignment information (namely, bypass tunnel source address, destination address, and Tunnel ID) in the received RSVP Path message of the protected forward LSP to
o [RFC8271]中定义的旁路分配IPv4子对象（值38）和IPv6子对象（值39）用于协调PLR节点之间正向和反向的旁路隧道分配（见图1）。旁路分配和节点ID地址[RFC4561]子对象必须由下游PLR节点添加到前向LSP的RSVP Path消息的记录路由对象（RRO）中，以使用[RFC8271]中定义的过程指示本地旁路隧道分配。上游节点使用所接收的受保护转发LSP的RSVP路径消息中的旁路分配信息（即，旁路隧道源地址、目的地地址和隧道ID）来发送
find the associated bypass tunnel in the reverse direction. The upstream PLR node MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the RSVP Path message of the reverse LSP.
按相反方向查找相关的旁通隧道。上游PLR节点不得在反向LSP的RSVP Path消息的RRO中添加旁路分配子对象。
o The downstream PLR node initiates the bypass tunnel assignment for the forward LSP. The upstream PLR (forward-direction LSP MP) node reflects the associated bypass tunnel assignment for the reverse-direction LSP. The upstream PLR node MUST NOT initiate the bypass tunnel assignment.
o 下游PLR节点为前向LSP发起旁路隧道分配。上游PLR（正向LSP MP）节点反映反向LSP的相关旁通隧道分配。上游PLR节点不得启动旁路隧道分配。
o If the indicated forward bypass tunnel or the associated reverse 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) [RFC8271] to the downstream PLR.
o 如果未找到指示的正向旁通隧道或相关的反向旁通隧道，上游PLR应向下游PLR发送一条通知消息[RFC3473]，错误代码为“FRR旁通分配错误”（值44），子代码为“未找到旁通隧道”（值1）[RFC8271]。
o If the bypass tunnel cannot be used as described in Section 4.5.3 of [RFC8271], 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) [RFC8271] to the downstream PLR.
o 如果旁通隧道无法按照[RFC8271]第4.5.3节所述使用，则上游PLR应向下游PLR发送一条通知消息[RFC3473]，错误代码为“FRR旁通分配错误”（值44），子代码为“无法使用旁通分配”（值0）[RFC8271]。
o After a link or node failure, the PLR nodes in both forward and reverse directions trigger fast reroute independently using the procedures defined in [RFC4090] and send the forward and protected reverse LSP modified RSVP Path messages and traffic over the bypass tunnel. The RSVP Resv signaling of the protected forward and reverse LSPs follows the same procedure as defined in [RFC4090] and is not modified by this document.
o 链路或节点故障后，正向和反向PLR节点使用[RFC4090]中定义的程序独立触发快速重路由，并通过旁路隧道发送正向和受保护的反向LSP修改RSVP路径消息和流量。受保护的前向和反向LSP的RSVP Resv信令遵循[RFC4090]中定义的相同程序，本文件未对其进行修改。
After fast reroute, the downstream MP node assumes the role of upstream PLR and reroutes the reverse LSP RSVP Path messages and traffic over the bypass tunnel on which the forward LSP RSVP Path messages and traffic are received. This procedure is defined as "restoring co-routing" in [RFC8271]. This procedure is used to ensure that both forward and reverse LSP signaling and traffic flow on the same bidirectional bypass tunnel after fast reroute.
在快速重路由之后，下游MP节点承担上游PLR的角色，并通过旁路隧道重路由反向LSP RSVP路径消息和流量，在旁路隧道上接收正向LSP RSVP路径消息和流量。此过程在[RFC8271]中定义为“恢复共同路由”。此程序用于确保在快速重新路由后，前向和反向LSP信令和业务流在同一双向旁路隧道上。
As shown in Figure 2, when using a node protection bypass tunnel with protected co-routed LSPs, asymmetry of paths can occur in the forward and reverse directions after a link failure [RFC8271]. In order to restore co-routing, the downstream MP node D (acting as an upstream PLR) MUST trigger the procedure to restore co-routing and reroute the protected reverse LSP2 RSVP Path messages and traffic over the bypass tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving the protected forward LSP modified RSVP Path messages and traffic
如图2所示，当使用具有受保护的共路由LSP的节点保护旁路隧道时，链路故障后，路径的不对称性可能会在正向和反向发生[RFC8271]。为了恢复共同路由，下游MP节点D（作为上游PLR）必须触发恢复共同路由的过程，并通过旁路隧道S（路径D-G-F-B）重新路由受保护的反向LSP2 RSVP路径消息和流量在接收到受保护的前向LSP修改的RSVP路径消息和流量时发送到上游MP节点B
over the bypass tunnel S (on path D-G-F-B) from node B. The upstream PLR node C stops receiving the RSVP Path messages and traffic for the reverse LSP2 from node D (resulting in RSVP soft-state timeout), and it stops sending the RSVP Path messages for the reverse LSP2 over the bypass tunnel N (on path C-I-H-A) to node A.
上游PLR节点C停止从节点D接收反向LSP2的RSVP路径消息和通信量（导致RSVP软状态超时），并停止通过旁路隧道N（路径C-I-H-A）向节点A发送反向LSP2的RSVP路径消息。
The unidirectional link failures can cause co-routed associated bidirectional LSPs to be no longer co-routed after fast reroute with both link protection and node protection bypass tunnels. However, the unidirectional link failures in the upstream and/or downstream directions do not result in RSVP soft-state timeout with the associated bidirectional LSPs as upstream and downstream PLRs trigger fast reroute independently. The asymmetry of forward and reverse LSP paths due to the unidirectional link failure in the downstream direction can be corrected by using the procedure to restore co-routing specified in Section 4.1.1.
单向链路故障可导致在使用链路保护和节点保护旁路隧道快速重新路由后，共同路由的相关双向LSP不再共同路由。然而，上游和/或下游方向上的单向链路故障不会导致相关双向LSP的RSVP软状态超时，因为上游和下游PLR独立触发快速重路由。通过使用第4.1.1节中规定的恢复共路由的程序，可以纠正由于下游方向的单向链路故障导致的正向和反向LSP路径的不对称性。
When the revertive behavior is desired for a protected LSP after the link is restored, the procedure defined in Section 6.5.2 of [RFC4090] is followed.
当链路恢复后，受保护LSP需要恢复行为时，遵循[RFC4090]第6.5.2节中定义的程序。
o The downstream PLR node starts sending the RSVP Path messages and traffic flow of the protected forward LSP over the restored link and stops sending them over the bypass tunnel [RFC4090].
o 下游PLR节点开始通过恢复的链路发送受保护的前向LSP的RSVP路径消息和业务流，并停止通过旁路隧道发送它们[RFC4090]。
o The upstream PLR node (when the protected LSP is present) also starts sending the RSVP Path messages and traffic flow of the protected reverse LSPs over the restored link and stops sending them over the bypass tunnel [RFC4090].
o 上游PLR节点（当受保护LSP存在时）也开始通过恢复的链路发送受保护反向LSP的RSVP路径消息和业务流，并停止通过旁路隧道发送它们[RFC4090]。
o For node protection bypass tunnels (see Figure 2), after restoring co-routing, the upstream PLR node D SHOULD start sending RSVP Path messages and traffic for the reverse LSP over the original link (C-D) when it receives the unmodified RSVP Path messages and traffic for the protected forward LSP over it and stops sending them over the bypass tunnel S (on path D-G-F-B).
o 对于节点保护旁路隧道（见图2），在恢复共同路由后，上游PLR节点D应开始通过原始链路（C-D）发送反向LSP的RSVP路径消息和通信量当它通过它接收到未修改的RSVP路径消息和受保护转发LSP的通信量，并停止通过旁路隧道S（路径D-G-F-B）发送它们时。
Fast reroute bidirectional bypass tunnels can be single-sided or double-sided associated tunnels. For both single-sided and double-sided associated bypass tunnels, the fast reroute assignment policies need to be configured on the downstream PLR nodes of the protected
快速重路由双向旁路隧道可以是单边或双边关联隧道。对于单边和双边关联旁路隧道，需要在受保护隧道的下游PLR节点上配置快速重路由分配策略
LSPs that initiate the bypass tunnel assignments. For single-sided associated bypass tunnels, these nodes are the originating endpoints of their signaling.
启动旁路通道分配的LSP。对于单边关联旁路隧道，这些节点是其信令的起始端点。
The fast reroute signaling procedure defined in this document can be used for both facility backup described in Section 3.2 of [RFC4090] and one-to-one backup described in Section 3.1 of [RFC4090]. As described in Section 4.5.2 of [RFC8271], in the one-to-one backup method, if the associated bidirectional 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.
本文件中定义的快速重路由信令程序可用于[RFC4090]第3.2节所述的设施备份和[RFC4090]第3.1节所述的一对一备份。如[RFC8271]第4.5.2节所述，在一对一备份方法中，如果相关双向旁路隧道已在上游PLR处使用，则其应向下游PLR发送一条通知消息[RFC3473]，错误代码为“FRR旁路分配错误”（值44），子代码为“一对一旁路已在使用”（值2）。
In order to associate the LSPs unambiguously at a midpoint node (see Figure 3), the endpoint node MUST signal the Extended ASSOCIATION Object and add a unique Extended Association ID for each associated forward and reverse LSP pair forming the bidirectional LSP. An endpoint node MAY set the Extended Association ID to the value formatted according to the structure shown in Appendix A.
为了在中点节点处明确地关联LSP（参见图3），端点节点必须向扩展关联对象发送信号，并为形成双向LSP的每个关联的正向和反向LSP对添加唯一的扩展关联ID。端点节点可将扩展关联ID设置为根据附录A所示结构格式化的值。
o For single-sided provisioned bidirectional LSPs [RFC7551], the originating endpoint signals the Extended ASSOCIATION Object with a unique Extended Association ID. The remote endpoint copies the contents of the received Extended ASSOCIATION Object including the Extended Association ID in the RSVP Path message of the reverse LSP's Extended ASSOCIATION Object.
o 对于单边配置的双向LSP[RFC7551]，发起端点用唯一的扩展关联ID向扩展关联对象发送信号。远程端点复制接收到的扩展关联对象的内容，包括反向LSP的扩展关联对象的RSVP Path消息中的扩展关联ID。
o For double-sided provisioned bidirectional LSPs [RFC7551], both endpoints need to ensure that the bidirectional LSP has a unique Extended ASSOCIATION Object for each forward and reverse LSP pair by selecting appropriate unique Extended Association IDs signaled by them. A controller can be used to provision a unique Extended Association ID on both endpoints. The procedure for selecting unique Extended Association IDs is outside the scope of this document.
o 对于双面配置的双向LSP[RFC7551]，两个端点都需要通过选择由它们发出信号的适当的唯一扩展关联ID来确保双向LSP对于每个正向和反向LSP对具有唯一的扩展关联对象。控制器可用于在两个端点上提供唯一的扩展关联ID。选择唯一扩展关联ID的过程不在本文档的范围内。
This document updates the procedures for fast reroute for associated bidirectional LSPs defined in [RFC4090] and the procedures for associating bidirectional LSPs defined in [RFC7551]. The procedures use the signaling messages defined in [RFC8271]; no new signaling messages are defined in this document. The procedures ensure that for the co-routed LSPs, traffic flows on co-routed paths in the
本文件更新了[RFC4090]中定义的关联双向LSP的快速重路由程序和[RFC7551]中定义的关联双向LSP的程序。程序使用[RFC8271]中定义的信令消息；本文档中未定义新的信令消息。这些程序确保对于共路由LSP，在
forward and reverse directions after fast reroute. Operators wishing to use this function SHOULD ensure that it is supported on all the nodes on the LSP path. The nodes not supporting this function can cause the traffic to flow on asymmetric paths in the forward and reverse directions of the associated bidirectional LSPs after fast reroute.
快速重路由后的正向和反向方向。希望使用此功能的操作员应确保LSP路径上的所有节点都支持此功能。不支持此功能的节点可导致在快速重新路由后，流量在相关双向LSP的正向和反向上的不对称路径上流动。
This document updates the signaling mechanisms defined in [RFC4090] and [RFC7551]. It does not introduce any additional security considerations other than those already covered in [RFC4090], [RFC7551], [RFC8271], and the MPLS/GMPLS security framework [RFC5920].
本文件更新了[RFC4090]和[RFC7551]中定义的信号机制。除了[RFC4090]、[RFC7551]、[RFC8271]和MPLS/GMPLS安全框架[RFC5920]中已经介绍的安全注意事项外，它没有引入任何其他安全注意事项。
This document has no IANA actions.
本文档没有IANA操作。
[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>.
[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>.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, October 2012, <https://www.rfc-editor.org/info/rfc6780>.
[RFC6780]Berger，L.，Le Faucheur，F.，和A.Narayanan，“RSVP关联对象扩展”，RFC 6780，DOI 10.17487/RFC6780，2012年10月<https://www.rfc-editor.org/info/rfc6780>.
[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>.
[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>.
[RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and M. Bhatia, "Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)", RFC 8271, DOI 10.17487/RFC8271, October 2017, <https://www.rfc-editor.org/info/rfc8271>.
[RFC8271]Taillon，M.，Saad，T.，Ed.，Gandhi，R.，Ed.，Ali，Z.，和M.Bhatia，“交通工程GMPLS标签交换路径（LSP）快速重路由的资源预留协议更新”，RFC 8271，DOI 10.17487/RFC8271，2017年10月<https://www.rfc-editor.org/info/rfc8271>.
[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>.
[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>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <https://www.rfc-editor.org/info/rfc6370>.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 6370，DOI 10.17487/RFC6370，2011年9月<https://www.rfc-editor.org/info/rfc6370>.
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar, N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, DOI 10.17487/RFC6373, September 2011, <https://www.rfc-editor.org/info/rfc6373>.
[RFC6373]Andersson，L.，Ed.，Berger，L.，Ed.，Fang，L.，Ed.，Bitar，N.，Ed.，和E.Gray，Ed.，“MPLS传输配置文件（MPLS-TP）控制平面框架”，RFC 6373，DOI 10.17487/RFC6373，2011年9月<https://www.rfc-editor.org/info/rfc6373>.
[RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing", RFC 8131, DOI 10.17487/RFC8131, March 2017, <https://www.rfc-editor.org/info/rfc8131>.
[RFC8131]Zhang，X.，Zheng，H.，Ed.，Gandhi，R.，Ed.，Ali，Z.，和P.Brzowski，“端到端GMPLS恢复和资源共享的RSVP-TE信号程序”，RFC 8131，DOI 10.17487/RFC81312017年3月<https://www.rfc-editor.org/info/rfc8131>.
The Extended Association ID in the Extended ASSOCIATION Object [RFC6780] can be set to the value formatted according to the structure shown in the following example to uniquely identify associated forward and reverse LSP pairs of an associated bidirectional LSP.
扩展关联对象[RFC6780]中的扩展关联ID可以设置为根据以下示例中所示的结构格式化的值，以唯一标识关联双向LSP的关联正向和反向LSP对。
An example of the IPv4 Extended Association ID format is shown below:
IPv4扩展关联ID格式的示例如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 LSP Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 LSP Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Extended Association ID Format Example
图4:IPv4扩展关联ID格式示例
IPv4 LSP Source Address
IPv4 LSP源地址
IPv4 source address of the forward LSP [RFC3209].
转发LSP的IPv4源地址[RFC3209]。
LSP ID
LSP ID
16-bit LSP ID of the forward LSP [RFC3209].
前向LSP[RFC3209]的16位LSP ID。
Variable Length ID
可变长度ID
Variable length Extended Association ID [RFC6780] inserted by the endpoint node of the associated bidirectional LSP [RFC7551].
由关联双向LSP[RFC7551]的端点节点插入的可变长度扩展关联ID[RFC6780]。
An example of the IPv6 Extended Association ID format is shown below:
IPv6扩展关联ID格式的示例如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 LSP Source Address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 LSP Source Address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Extended Association ID Format Example
图5:IPv6扩展关联ID格式示例
LSP Source Address
LSP源地址
IPv6 source address of the forward LSP [RFC3209].
转发LSP的IPv6源地址[RFC3209]。
LSP ID
LSP ID
16-bit LSP ID of the forward LSP [RFC3209].
前向LSP[RFC3209]的16位LSP ID。
Variable Length ID
可变长度ID
Variable length Extended Association ID [RFC6780] inserted by the endpoint node of the associated bidirectional LSP [RFC7551].
由关联双向LSP[RFC7551]的端点节点插入的可变长度扩展关联ID[RFC6780]。
In both IPv4 and IPv6 examples, the Reserved flags MUST be set to 0 on transmission.
在IPv4和IPv6示例中，传输时保留标志必须设置为0。
Acknowledgments
致谢
A special thanks to the authors of [RFC8271]; this document uses the signaling mechanisms defined in that document. The authors would also like to thank Vishnu Pavan Beeram, Daniele Ceccarelli, Deborah Brungard, Adam Roach, and Benjamin Kaduk for reviewing this document and providing valuable comments.
特别感谢[RFC8271]的作者；本文件使用该文件中定义的信号机制。作者还要感谢Vishnu Pavan Beeram、Daniele Ceccarelli、Deborah Brungard、Adam Roach和Benjamin Kaduk审阅本文件并提供了宝贵的意见。
Authors' Addresses
作者地址
Rakesh Gandhi (editor) Cisco Systems, Inc. Canada
拉凯什·甘地（编辑）加拿大思科系统公司
Email: rgandhi@cisco.com
Email: rgandhi@cisco.com
Himanshu Shah Ciena
希曼舒沙希纳
Email: hshah@ciena.com
Email: hshah@ciena.com
Jeremy Whittaker Verizon
杰里米·惠塔克威瑞森
Email: jeremy.whittaker@verizon.com
Email: jeremy.whittaker@verizon.com