[要約] RFC 8271は、トラフィックエンジニアリングGMPLSラベルスイッチドパス（LSP）の高速再ルーティングのためのリソース予約プロトコルの更新を提供しています。このRFCの目的は、LSPの高速再ルーティングをサポートするためのプロトコルの改善と拡張です。
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で定義されているResource Reservation Protocol-Traffic Engineering（RSVP-TE）Fast Reroute（FRR）手順を更新して、Packet Switch Capable（PSC）Generalized Multiprotocol Label Switching（GMPLS）Label Switched Paths（LSPs）をサポートします。これらのアップデートにより、双方向ルーティングLSPの順方向と逆方向の両方で共通のファシリティを保護する双方向バイパストンネル割り当ての調整が可能になります。さらに、これらの更新により、双方向トラフィックをバイパストンネルにリダイレクトして、FRR後のデータパスの順方向と逆方向のコルーティングを確実にし、コントロールプレーンでのRSVPソフト状態タイムアウトを回避できます。
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/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.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 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.
パケット交換対応（PSC）トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）は、[RFC3473]で指定されている一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング手順を使用して、単方向トンネルと双方向トンネルの両方に対して設定できます。 GMPLSシグナリングを使用すると、RSVPメッセージをデータトラフィックとインバンドで送受信したり、別の制御チャネルを介してアウトオブバンドで送受信したりできます。 Fast Reroute（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に障害が発生した場合に、トラフィックとシグナリングをバイパストンネルに再ルーティングするためのPoint of Local Repair（PLR）の動作を記述しています。これらの手順は、RSVP-TE [RFC3209]またはGMPLS手順[RFC3473]のいずれかを使用してシグナリングされる単方向保護LSPに適用できます。 [RFC4090]で定義されているFRR手順を双方向のGMPLS LSPと共に使用する場合、各方向で同じPLRとマージポイント（MP）のペアを選択し、PLRとMPの両方が同じ双方向バイパストンネルを割り当てることが望まれます。このドキュメントは、[RFC4090]で定義されたFRR手順を更新して、双方向バイパストンネルの割り当てを調整し、保護された同一ルートの双方向LSPのアップストリームPLRとダウンストリーム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]を使用して2つの単方向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.
キーワード「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 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：ダウンストリームマージポイント1つ以上のバックアップトンネルがトラフィックフローのダウンストリーム方向で保護されたLSPのパスに再結合するLSR。同じ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：アップストリームマージポイント1つ以上のバックアップトンネルがトラフィックフローのアップストリーム方向で保護されたLSPのパスに再結合するLSR。同じ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.
Point of Remote Repair（PRR）保護されたLSPの再ルーティングされたパスメッセージを受信するとアップストリームPLRの役割を引き受け、このドキュメントで説明されている手順を使用してトラフィックフローのアップストリーム方向のトラフィックとシグナリングの再ルーティングをトリガーするダウンストリームMP。
GMPLS: Generalized Multiprotocol Label Switching
GMPLS：汎用マルチプロトコルラベルスイッチング
LSP: Label Switched Path
LSP：ラベルスイッチドパス
LSR: Label Switching Router
LSR：ラベルスイッチングルーター
MP: Merge Point
MP：マージポイント
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
PLR: Point of Local Repair
PLR：ローカル修理のポイント
PSC: Packet Switch Capable
PSC：パケットスイッチ対応
RSVP: Resource Reservation Protocol
RSVP：リソース予約プロトコル
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]を使用する場合、リンク障害イベントの後、RSVPメッセージは、ダウンストリームPLRによってバイパストンネルを介して再ルーティングされず、代わりに制御チャネルを介してダウンストリーム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で始まり、対応するダウンストリームMPで終了します。発信元のダウンストリームPLRには、ローカルにプロビジョニングされたバイパストンネルに関するポリシー情報があるため、常にバイパストンネルの割り当てが開始されます。アップストリームPLRから始まり、対応するアップストリームMPで終端する双方向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ラベルを事前に知っている必要があります。これにより、順方向および逆方向のデータをバイパストンネル経由でリダイレクトできます。それぞれFRRの後。
[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で受信したRSVP ResvメッセージのRECORD_ROUTEオブジェクト（RRO）の記録済みラベルから、保護されたLSPのダウンストリームMPラベルを取得するためのダウンストリームPLRの手順を定義します。
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]で指定された手順を使用して、保護されたLSPのRSVPパスメッセージのRROにアップストリームMPラベルを記録します。アップストリームPLRは、受信したRSVPパスメッセージの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で受信されたRSVP ResvメッセージのRROに記録されたノードIDから保護されたLSPのダウンストリームMPアドレスを取得するためのダウンストリームPLRの手順を定義します。
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パスメッセージのRROにアップストリームMPノードIDを記録します。アップストリームPLRは、受信したRSVPパスメッセージの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.
RRO IPv4 / IPv6サブオブジェクトフラグは[RFC4090]のセクション4.4で定義されており、保護された双方向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.
[RFC4090]で定義されている手順は、ダウンストリームPLRによって、保護されたLSPのRSVP ResvメッセージのRROでアップストリームのIPv4 / IPv6サブオブジェクトフラグを通知するために使用されます。同様に、これらの手順はダウンストリームPLRによって使用され、保護されたLSPのRSVPパスメッセージの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.
このドキュメントでは、ダウンストリームPLRとアップストリームPLR間の双方向バイパストンネル割り当ての調整に使用されるRSVP RECORD_ROUTEオブジェクト（RRO）のシグナリング手順と新しいBYPASS_ASSIGNMENTサブオブジェクトを定義します。
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.
再ルーティングされたトラフィックがFRR後に共ルーティングパス上を流れるように、ダウンストリームおよびアップストリームPLRで選択された双方向バイパストンネルを調整することが望ましいです。これを実現するために、双方向のLSPを保護するためにダウンストリームPLRで割り当てられる双方向のバイパストンネルを識別する新しいRSVPサブオブジェクトがRROに対して定義されます。
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 update the data plane until it receives Resv messages containing the MP labels.
このドキュメントで定義された手順が使用されている場合、BYPASS_ASSIGNMENTサブオブジェクトは、ダウンストリームの双方向バイパストンネル割り当てを記録するために、GMPLSシグナリングの双方向保護LSPのRSVPパスRROメッセージの各ダウンストリームPLRによって追加される必要があります。このサブオブジェクトは、ダウンストリームPLRがバイパストンネル割り当てを割り当てるか更新するたびに、RSVPパスRROメッセージで送信されます。ダウンストリームPLRは、ダウンストリームMPのトポロジービューと明示的ルートオブジェクト（ERO）の通過パス情報がある限り、保護されたLSPの最初のパスメッセージを処理するときにバイパストンネルを割り当てることができます。最初のパスメッセージからダウンストリームMPを特定できない保護されたLSPの場合（たとえば、EROでルーズホップを使用する場合）、ダウンストリームPLRは、バイパストンネルを割り当てるために、RROを含むResvメッセージを待つ必要があります。ただし、どちらの場合も、ダウンストリームPLRは、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にBYPASS_ASSIGNMENTサブオブジェクトがないことは、関連するノードまたはインターフェースが双方向バイパストンネルによって保護されていないことを意味します。
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:
BYPASS_ASSIGNMENTサブオブジェクトがパス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 Node-IDアドレスを含むIPv4またはIPv6サブオブジェクトも追加する必要があります[RFC4561]。ノードIDアドレスは、この保護されたLSPに対して選択されたバイパストンネルのソースアドレスと一致する必要があります。
o The BYPASS_ASSIGNMENT subobject MUST be added immediately after the Node-ID address.
o BYPASS_ASSIGNMENTサブオブジェクトは、ノード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のすべてのBYPASS_ASSIGNMENTサブオブジェクトをチェックして、BYPASS_ASSIGNMENTの宛先アドレスがアップストリームPLRのアドレスと一致するかどうかを確認する必要があります（SHOULD）。一致するBYPASS_ASSIGNMENTサブオブジェクトごとに、上流PLRは、BYPASS_ASSIGNMENTで指定されたNode-IDアドレスと同じトンネルIDで示されるように、BYPASS_ASSIGNMENTを挿入した下流PLRと一致するソースアドレスを持つトンネルを探します。 RROには、ノードを識別するための複数のアドレスを含めることができます。ただし、アップストリームPLRは、バイパストンネルを識別するために、BYPASS_ASSIGNMENTサブオブジェクトの前のノードIDアドレスに依存しています。バイパストンネルが見つからない場合、アップストリームPLRは、エラーコード "FRR Bypass Assignment Error"（値44）およびサブコード "Bypass Tunnel Not Found"（値1）を含む通知メッセージ[RFC3473]をダウンストリームPLRに送信する必要があります（SHOULD）。 。このエラーを受信すると、ダウンストリームPLRはバイパストンネルの割り当てを削除し、代替のバイパストンネルが利用可能な場合はそれを選択する必要があります（SHOULD）。 BYPASS_ASSIGNMENTサブオブジェクトを含むRROは、RSVPパスメッセージでダウンストリームに転送されます。
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のBYPASS_ASSIGNMENTサブオブジェクトをそれぞれ追加、削除、または変更できます。この場合、ダウンストリームPLRは、変更されたパスメッセージを生成してダウンストリームに転送する必要があります（SHOULD）。ダウンストリームMPは、受信したPathメッセージのRROをチェックして、それに応じて逆方向のバイパストンネル割り当てを更新する必要があります（SHOULD）。
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で説明されている1対1のバックアップの両方に使用できます。 [RFC4090]のセクション4.2で指定されているように、DETOURオブジェクトを1対1のバックアップ方法で使用して、迂回LSPを識別できます。 1対1のバックアップ方法では、バイパストンネルがアップストリームPLRですでに使用されている場合、エラーコード「FRR Bypass Assignment Error」（値44）とサブコード「Notifyメッセージ[RFC3473]を送信する必要があります（SHOULD）」ダウンストリームPLRへの1対1のバイパスが既に使用されています（値2）。このエラーを受信すると、ダウンストリームPLRはバイパストンネルの割り当てを削除し、代替のバイパストンネルが使用可能な場合はそれを選択する必要があります（SHOULD）。
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は、保護されたLSPの複数のバイパストンネル割り当てをさまざまなダウンストリームPLRから受信する可能性があり、次の2つの例に示すように、非対称バイパストンネル割り当てが発生します。
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は複数のバイパストンネル割り当てを受信します。1つはノード保護用のダウンストリームPLR R4から、もう1つはリンク保護用のダウンストリームPLR R5からです。例1では、R6はダウンストリームPLR R5からのリンク保護バイパストンネルを優先しますが、例2では、R6はダウンストリームPLR R4からのノード保護バイパストンネルを優先します。
+------->>-------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
PATH -> \ /
\ /
+-<<--+
Example 1: Link Protection Is Preferred on Downstream MP
例1：ダウンストリームMPではリンク保護が優先されます
+------->>--------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
\ 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で定義されているSESSION_ATTRIBUTEオブジェクトのフラグを使用することで、バイパストンネル割り当ての非対称性を回避できます。特に、「ノード保護希望」フラグは、ノード保護バイパストンネルを要求するためにヘッドエンドノードによって通知されます。このフラグが設定されると、例2に示すように、ダウンストリームPLRノードとアップストリームPLRノードの両方がノード保護バイパストンネルを割り当てます。「ノード保護希望」フラグが設定されていない場合、ダウンストリーム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は、通知コード[RFC3473]をエラーコード「FRR Bypass Assignment Error」（値44）およびサブコード「Bypass Assignment Not Used」（値0）とともにダウンストリームに送信する必要があります（SHOULD）。逆方向のバイパストンネル割り当てを使用できないことを示すPLR。このエラーを受信すると、ダウンストリームPLRはバイパストンネルの割り当てを削除して、代替のバイパストンネルが使用可能な場合はそれを選択できます（MAY）。
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パスメッセージを受信すると、保護された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 アップストリームPLRは、双方向バイパストンネルを介して変更されたRSVPパスメッセージを受信した後、保護された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
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は、RSVPパスメッセージをバイパストンネルT3経由で受信すると、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
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手順を呼び出すための2つのフェーズが導入されています。最初のフェーズは、データトラフィックを順方向および逆方向のバイパストンネルに高速で再ルーティングするFRR手順で構成されます。 2番目のフェーズでは、最初のフェーズの後に、順方向と逆方向のシグナリングとデータトラフィックのコルーティングを復元します。
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を介してPathメッセージを受信しないため、逆バイパストンネル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パスメッセージを受信するダウンストリーム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のSENDER_TEMPLATEオブジェクトの「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 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.
o逆バイパストンネルが見つかり、検出されたバイパストンネルT2を介して保護されたLSPトラフィックがまだ再ルーティングされていない場合、PRR R5はFRR再ルーティング手順をアクティブにして、見つかったバイパストンネルT2を介してトラフィックを逆方向に転送します。さらに、PRR R5は、バイパストンネルT2を介してRSVP Resvを逆方向に再ルーティングします。これは、ダウンストリームPLRがバイパストンネル割り当てを変更したが、リンク障害が発生したときに、アップストリーム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 -> \ /
\ /
+<<------->>+
Bypass Tunnel T2
バイパストンネルT2
traffic + signaling
トラフィック+シグナリング
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パス（保護された双方向LSPに最も近い）に沿って最も遠いダウンストリームPLRで終了するバイパストンネルを識別する必要があります（SHOULD）。ヘッドエンド）、上記の再ルーティング手順をアクティブにします。
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パケットを識別するには、バイパストンネルのPenultimate Hop Popping（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が存在する場合）は、保護リンクLSPのトラフィックフローを復元されたリンクを介してダウンストリームPLR R3に送信し始め、パスメッセージを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は、変更されたRSVPパスメッセージをバイパストンネルT2経由で受信した後、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 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).
単方向リンクの障害により、トラフィックが順方向と逆方向の非対称パスを流れる可能性があります。さらに、単方向リンク障害が原因で、コントロールプレーンでRSVPソフト状態タイムアウトが発生する場合があります。例として、単方向リンク障害がアップストリーム方向（図1および2のR4からR3へ）である場合、ダウンストリームPLR（ノードR3）は、アップストリームPLR（ノードR4から保護されたLSPのResvメッセージの受信を停止できます図1および2）では、ダウンストリーム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).
ダウンストリーム方向（図1および2のR3からR4へ）での単方向リンク障害は、このドキュメントで定義されているFRR手順を使用する場合、アップストリームPLR（図1のノードR4およびノード図2のR5）は、ダウンストリームPLR（図1および2のノードR3）からバイパストンネルを介して保護LSPのRSVPパスメッセージを受信した後、コルーティング（セクション5.2.2で定義）を復元する手順をトリガーします。
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]を使用する場合、リンク障害イベントの後、RSVPメッセージはダウンストリームおよびアップストリームPLRによって双方向バイパストンネルを介して再ルーティングされず、代わりに制御チャネルを介してダウンストリームおよびアップストリームに再ルーティングされます。それぞれMP。
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.
BYPASS_ASSIGNMENTサブオブジェクトは、PLRによって割り当てられているバイパストンネルをダウンストリームMPに通知するために使用されます。これを使用して、障害の発生前または発生後に、ダウンストリームおよびアップストリーム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に挿入する必要があります（SHOULD）。ダウンストリームPLRではないノードによってRROに挿入されるべきではない（SHOULD NOT）。ダウンストリームLSRによって変更されてはならず、Resv RROに追加されてはなりません。
The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format:
RROのBYPASS_ASSIGNMENT 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject
図4：BYPASS ASSIGNMENT IPv4 RROサブオブジェクト
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.
Lengthには、TypeおよびLengthフィールドを含む、サブオブジェクトの全長がバイト単位で含まれます。長さは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のBYPASS_ASSIGNMENT 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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject
図5：BYPASS_ASSIGNMENT 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.
Lengthには、TypeおよびLengthフィールドを含む、サブオブジェクトの全長がバイト単位で含まれます。長さは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 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.
このドキュメントのERROR_SPECオブジェクト（Cタイプ6）[RFC2205]には、新しいエラーコード「FRRバイパス割り当てエラー」（値44）とそのサブコードが定義されています。これは、で定義されている通知メッセージ（タイプ21）によって伝送されます。 [RFC3473]セクション4.3。このエラーメッセージは、アップストリームPLRからダウンストリームPLRに送信され、バイパス割り当てエラーを通知します。通知メッセージでは、IP宛先アドレスは、バイパス割り当てを開始したダウンストリームPLRのノードアドレスに設定されています。 ERROR_SPECオブジェクトでは、IPアドレスは、バイパス割り当てエラーを検出したアップストリーム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サブオブジェクトBYPASS_ASSIGNMENTは、このドキュメントのRECORD_ROUTEオブジェクトに対して定義され、RSVPパスメッセージで伝達されます。 [RFC3209]に従い、このサブオブジェクトをサポートしないノードはサブオブジェクトを無視しますが、変更せずに転送します。セクション7で説明したように、このサブオブジェクトはRSVP Resvメッセージでは伝達されず、このドキュメントで定義されている「FRRバイパス割り当てエラー」（サブコード「バイパス割り当ては使用できません」）の通知メッセージを送信すると無視されます。このドキュメントで定義されている通知メッセージをサポートしないノードは、それを無視しますが、変更せずに転送します。
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シグナリングメッセージで伝送されるRECORD_ROUTEオブジェクトの新しいBYPASS_ASSIGNMENTサブオブジェクトを紹介します。したがって、シグナリングメッセージが傍受された場合、LSPの高速リルート保護に関する情報が、以前よりも多く推測される可能性があります。この情報はすでに他の手段で利用可能であるため、これは非常に小さなセキュリティリスクであると判断されます。 MPは、特定の送信元アドレスと宛先アドレスを持つ一致するバイパストンネルをローカルで見つけられない場合、BYPASS_ASSIGNMENTサブオブジェクトを無視します。このため、このサブオブジェクトにランダムなアドレスを挿入することで生じるセキュリティリスクは最小限です。このドキュメントで定義されている「FRR Bypass Assignment Error」の通知メッセージは、保護された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.
RSVP-TEおよびGMPLSシグナリング拡張のセキュリティに関する考慮事項は、[RFC3209]および[RFC3473]で説明されています。さらに、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は、「クラスタイプ21 ROUTE_RECORD-タイプ1ルートレコード」レジストリの新しいBYPASS_ASSIGNMENTサブオブジェクトに値を割り当てました。
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 | | | |
+------+----------------------+------------+------------+-----------+
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：使用中の1対1バイパス
[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>。
[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>。
[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>。
[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。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、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.、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>。
[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>。
[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] Weingarten、Y。、編、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、編、「MPLS Transport Profile（MPLS-TP）Linear Protection」、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.、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>。
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に感謝します。また、このドキュメントをレビューして貴重なコメントを提供してくださったNoki Akiya、Loa Andersson、Matt Hartley、Himanshu Shah、Gregory Mirsky、Mach Chen、Alia Atlasにも感謝します。このドキュメントを徹底的にレビューしてくれたAdrian Farrelに特に感謝します。
Contributors
貢献者
Frederic Jounay Orange Switzerland
フレデリックジュネオレンジスイス
Email: frederic.jounay@salt.ch
Lizhong Jin Shanghai China
l私は一種のジン上海中国
Email: lizho.jin@gmail.com
Authors' Addresses
著者のアドレス
Mike Taillon Cisco Systems, Inc.
Mike Taillon Cisco Systems、Inc.
Email: mtaillon@cisco.com
Tarek Saad (editor) Cisco Systems, Inc.
Tarek Saad（編集者）Cisco Systems、ed。
Email: tsaad@cisco.com
Rakesh Gandhi (editor) Cisco Systems, Inc.
Rakesh Gandhi（編集者）Cisco Systems、Inc.
Email: rgandhi@cisco.com
Zafar Ali Cisco Systems, Inc.
Zafar Ali Cisco Systems、Inc.
Email: zali@cisco.com
Manav Bhatia Nokia Bangalore, India
Manav Bhatia Nokia Bangalore、インド
Email: manav.bhatia@nokia.com