[要約] RFC 8537は、共同経路を持つ関連双方向ラベルスイッチドパス（LSP）の高速再ルーティング手順の更新を提供します。目的は、LSPの高速再ルーティングを改善し、ネットワークの信頼性とパフォーマンスを向上させることです。
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）アソシエーションシグナリングを使用して、2つの単方向ラベルスイッチドパス（LSP）を関連付けられた双方向LSPにバインドできます。関連する双方向LSPが共同ルーティングされる場合、リバースLSPはフォワードLSPと同じパスをたどります。このドキュメントは、RFC 4090で定義されている高速リルート手順を更新して、片側と両側のプロビジョニングされた関連する双方向LSPをサポートします。また、このドキュメントでは、RFC 7551で定義されている2つのリバースLSPを関連付けて、共同ルーティングされた双方向LSPをサポートする手順を更新しています。高速再ルーティング手順により、共ルーティングされたLSPの場合、障害イベントの後、トラフィックが共ルーティングパスを順方向および逆方向に流れるようになります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）（拡張）ASSOCIATIONオブジェクトは[RFC6780]で指定されており、マルチプロトコルラベルスイッチング（MPLS）と汎用MPLS（GMPLS）トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を関連付けるために一般的に使用できます。 [RFC7551]は、2つのポイントツーポイント（P2P）単方向LSP [RFC3209]を関連する双方向LSPにバインドするメカニズムを定義しています。関連する双方向LSPをプロビジョニングするために[RFC7551]で説明されている2つのモデルがあります：片面と両面です。どちらのモデルでも、双方向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アソシエーションシグナリングを使用すると、既存のネットワークにGMPLS拡張を展開する必要なく、コルーテッド双方向LSPを有効にできます。また、アソシエーションシグナリングにより、ネットワーク内の既存の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]は、LSPの順方向および逆方向でのバイパストンネル割り当ての調整など、GMPLS信号の双方向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]で定義されている2つのリバース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に使用される高速リルートバイパストンネルも、共同ルーティングに関連付けられた双方向であると想定しています。
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 このドキュメントで定義されているバイパストンネル割り当てを調整するための高速リルート手順は、同じルートではないが、フォワードのダウンストリームのローカル修復ポイント（PLR）とマージポイント（MP）のペアが必要な保護された関連双方向LSPに使用できます。 LSPは、リバース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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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.
2つの逆方向単方向P2P LSPが、送信元ノードと宛先ノードのペア間で反対方向に設定され、関連付けられた双方向LSPを形成します。片側がプロビジョニングされたLSPの場合、REVERSE_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.
2つの逆方向単方向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の1つのエンドポイントノードでのみ構成されます。このトンネルのLSPは、アソシエーションタイプが「片面の関連付けられた双方向LSP」に設定された（拡張）ASSOCIATIONオブジェクトと、RSVPパスメッセージに挿入されたREVERSE_LSPオブジェクトを持つ発信側エンドポイントによって開始されます。次に、リモートエンドポイントは、対応するリバースTEトンネルを作成し、受信したRSVPパスメッセージに存在するREVERSE_LSPオブジェクトおよびその他のオブジェクトからの情報を使用して、応答としてリバースLSPに信号を送ります。 [RFC7551]で指定されているように、両面プロビジョニングの場合、RSVP-TEトンネルは双方向LSPの両方のエンドポイントノードで構成されます。順方向と逆方向の両方のLSPは、関連付けタイプを含む（拡張）ASSOCIATIONオブジェクトが「両面関連付けられた双方向LSP」に設定された2つのエンドポイントによって独立して開始されます。片側と両側の両方でプロビジョニングされた双方向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 -->
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に示すように、使用可能なバイパストンネルは2つあります。バイパストンネル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 -->
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に示すように、リンクBC障害の後、ダウンストリームPLRノードBは、バイパストンネルSを介して（パスBFGDで）保護されたフォワードLSP1トラフィックを再ルーティングし、ダウンストリームMPノードDに到達します。一方、アップストリームPLRノードCは、保護されたリバースLSP2を再ルーティングします。 （パスCIHA上の）バイパストンネルNを介したトラフィックは、アップストリーム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が、同一の（拡張）ASSOCIATIONオブジェクトを持つミッドポイントノードに存在する可能性があります。これにより、中間ノードに曖昧さが生じ、高速リルートバイパス割り当てに関連する正しい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
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に属し、同一の（拡張）ASSOCIATIONオブジェクトを伝送します。この例では、一致する（拡張された）ASSOCIATIONオブジェクトが原因で、ミッドポイントノードDがLSP1を逆LSP2ではなく逆LSP4に誤って関連付けることがあります。これにより、関連する双方向LSPが、高速の再ルーティング後に、同じルートでルーティングされなくなる可能性があります。バイパス割り当ては、順方向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 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.
o [RFC8271]で定義されているBYPASS_ASSIGNMENT IPv4サブオブジェクト（値38）およびIPv6サブオブジェクト（値39）は、順方向と逆方向の両方でPLRノード間のバイパストンネル割り当てを調整するために使用されます（図1を参照）。 BYPASS_ASSIGNMENTおよびNode-IDアドレス[RFC4561]サブオブジェクトは、[RFC8271]で定義された手順を使用してローカルバイパストンネル割り当てを示すために、フォワードLSPのRSVPパスメッセージのRECORD_ROUTEオブジェクト（RRO）のダウンストリームPLRノードによって追加されなければなりません（MUST）。 。アップストリームノードは、保護されたフォワードLSPの受信したRSVPパスメッセージ内のバイパス割り当て情報（つまり、バイパストンネルの送信元アドレス、宛先アドレス、およびトンネルID）を使用して、関連するバイパストンネルを逆方向に見つけます。アップストリームPLRノードは、逆LSPのRSVPパスメッセージのRROにBYPASS_ASSIGNMENTサブオブジェクトを追加してはなりません（MUST NOT）。
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ノードは、バイパストンネル割り当てを開始してはなりません（MUST NOT）。
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は、エラーコード "FRR Bypass Assignment Error"（値44）およびサブコード "Bypass Tunnel Not Found"を含む通知メッセージ[RFC3473]を送信する必要があります（SHOULD）。 （値1）ダウンストリームPLRへの[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は、エラーコード「FRR Bypass Assignment Error」（値44）とサブコード「Bypass Assignment」を含む通知メッセージ[RFC3473]を送信する必要があります（SHOULD）。ダウンストリームPLRに「使用できません」（値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 リンクまたはノードの障害後、[RFC4090]で定義された手順を使用して、順方向と逆方向の両方のPLRノードが高速再ルーティングを個別にトリガーし、バイパストンネルを介して、フォワードおよび保護されたリバース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 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.
図2に示すように、保護された同じルートのLSPでノード保護バイパストンネルを使用すると、リンク障害の後で、パスの非対称が順方向と逆方向に発生する可能性があります[RFC8271]。コルーティングを復元するには、ダウンストリームMPノードD（アップストリームPLRとして機能）がプロシージャをトリガーして、コルーティングを復元し、保護されたリバースLSP2 RSVPパスメッセージとバイパストンネルS（パスDGFB）上のトラフィックを再ルーティングする必要があります。ノードBから保護された転送LSP変更RSVPパスメッセージとバイパストンネルS（パスDGFB上）上のトラフィックを受信すると、上流MPノードBに送信されます。上流PLRノードCは、逆方向LSP2のRSVPパスメッセージとトラフィックの受信を停止します。ノードD（RSVPソフトステートタイムアウトが発生）になり、バイパストンネルNを介して（パスCIHA経由で）リバースLSP2のRSVPパスメッセージをノードAに送信しなくなります。
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が同じルートでなくなります。ただし、アップストリームおよびダウンストリーム方向で単方向リンク障害が発生しても、アップストリームおよびダウンストリームPLRが個別に高速リルートをトリガーするため、関連する双方向LSPでRSVPソフト状態タイムアウトが発生しません。ダウンストリーム方向の単方向リンク障害によるフォワードおよびリバースLSPパスの非対称性は、セクション4.1.1で指定されたコルーティングを復元する手順を使用して修正できます。
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が存在する場合）も、復元されたリンクを介してRSVPパスメッセージと保護されたリバースLSPのトラフィックフローの送信を開始し、バイパストンネルを介した送信を停止します[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は、変更されていないRSVPパスメッセージを受信すると、元のリンク（CD）を介してリバースLSPのRSVPパスメッセージとトラフィックの送信を開始する必要があります（SHOULD）。それを介して保護された転送LSPのトラフィック。バイパストンネルS（パスDGFB）を介した送信を停止します。
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 LSPs that initiate the bypass tunnel assignments. For single-sided associated bypass tunnels, these nodes are the originating endpoints of their signaling.
高速リルート双方向バイパストンネルは、片側または両側の関連トンネルにすることができます。片側および両側の関連するバイパストンネルの場合、バイパストンネルの割り当てを開始する保護されたLSPのダウンストリームPLRノードで高速リルート割り当てポリシーを構成する必要があります。片側に関連付けられたバイパストンネルの場合、これらのノードはシグナリングの発信エンドポイントです。
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で説明されている1対1バックアップの両方に使用できます。 [RFC8271]のセクション4.5.2で説明されているように、1対1のバックアップ方法では、関連付けられた双方向バイパストンネルが上流のPLRですでに使用されている場合、エラーコード「Notify message [RFC3473] FRRバイパス割り当てエラー（値44）およびサブコード「ダウンストリームPLRへの1対1バイパスは既に使用されています」（値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を参照）、エンドポイントノードは拡張ASSOCIATIONオブジェクトに信号を送信し、双方向LSPを形成する関連付けられたフォワードおよびリバースLSPペアごとに一意の拡張アソシエーションIDを追加する必要があります。エンドポイントノードは、拡張アソシエーションIDを、付録Aに示す構造に従ってフォーマットされた値に設定してもよい（MAY）。
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で拡張ASSOCIATIONオブジェクトに信号を送ります。リモートエンドポイントは、受信した拡張ASSOCIATIONオブジェクトの内容を、リバースLSPの拡張ASSOCIATIONオブジェクトのRSVPパスメッセージの拡張アソシエーション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]の場合、両方のエンドポイントは、双方向LSPが信号を送る適切な一意の拡張アソシエーションIDを選択することにより、順方向および逆方向の各LSPペアに対して一意の拡張ASSOCIATIONオブジェクトを持っていることを確認する必要があります。コントローラを使用して、両方のエンドポイントで一意の拡張アソシエーション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 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.
このドキュメントは、[RFC4090]で定義されている関連する双方向LSPの高速リルートの手順と、[RFC7551]で定義されている双方向のLSPを関連付ける手順を更新します。手順は、[RFC8271]で定義されているシグナリングメッセージを使用します。このドキュメントでは、新しいシグナリングメッセージは定義されていません。この手順により、同じルートのLSPの場合、トラフィックは、高速ルート変更後、同じ方向のパスを順方向と逆方向に流れます。この関数を使用したいオペレーターは、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、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、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。、編、Swallow、G。、編、A。Atlas、編、「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 ASSOCIATION Object Extensions」、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.、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>。
[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：Extensions for RSVP for LSP Tunnels」、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。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、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] Fang、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 Transport Profile（MPLS-TP）Identifiers」、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。、and E. Gray、Ed。、 "MPLS Transport Profile（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.、and P. Brzozowski、 "RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource共有」、RFC 8131、DOI 10.17487 / RFC8131、2017年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.
拡張ASSOCIATIONオブジェクト[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 :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC3209]のIPv4送信元アドレス。
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 :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Extended Association ID Format Example
図5：IPv6拡張アソシエーションID形式の例
LSP Source Address
LSP送信元アドレス
IPv6 source address of the forward LSP [RFC3209].
転送LSP [RFC3209]のIPv6送信元アドレス。
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
Rakesh Gandhi（編集者）Cisco Systems、Inc.カナダ
Email: rgandhi@cisco.com
Himanshu Shah Ciena
ひまんしゅ しゃｈ しえな
Email: hshah@ciena.com
Jeremy Whittaker Verizon
ジェレミー・ウィテカー・ベライゾン
Email: jeremy.whittaker@verizon.com