Internet Engineering Task Force (IETF) C. Ramachandran
Request for Comments: 9705 Juniper Networks, Inc.
Updates: 4090 T. Saad
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 D. Pacella
Verizon, Inc.
March 2025
The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090 define two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnels. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from a scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout, hence, making facility backup method refresh-interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent, and hence, compatible with the Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RFC 8370. Hence, this document updates RFC 4090 in order to support the RI-RSVP capability specified in RFC 8370.
RFC 4090で指定されたRSVP-TE Fast Reroute（FRR）拡張機能は、事前に確立されたバックアップトンネル上のラベルスイッチドパス（LSP）トラフィックを再ルーティングする2つのローカル修理手法を定義します。施設のバックアップ方法により、接続されたリンクまたはノードを通過する1つ以上のLSPがバイパストンネルを使用して保護されます。ローカル修理技術の多面的な性質は、スケーラビリティの観点から魅力的です。このドキュメントは、RFC 4090の施設のバックアップ手順を列挙しており、更新時タイムアウトに依存しているため、施設のバックアップ方法を更新することができます。このドキュメントで定義されているRSVP-TE拡張機能は、対応する手順をリフレッシュすることにより、施設のバックアップ保護メカニズムを強化します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9705.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9705で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。この資料の一部の著作権を管理する人は、IETFの信頼にIETF標準プロセス以外のそのような資料の変更を許可する権利を認めていない可能性があります。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、RFCとして公開したり、英語以外の言語に翻訳する場合を除き、IETF標準プロセスの外で作成されない場合があります。
1. Introduction
1.1. Motivation
2. Abbreviations and Terminology
2.1. Abbreviations
2.2. Terminology
3. Problem Description
4. Solution Aspects
4.1. Requirement for RFC 4090 Capable Nodes to Advertise the
RI-RSVP Capability
4.2. Signaling Handshake Between PLR and MP
4.2.1. PLR Behavior
4.2.2. Remote Signaling Adjacency
4.2.3. MP Behavior
4.2.4. "Remote" State on MP
4.3. Impact of Failures on LSP State
4.3.1. Non-MP Behavior
4.3.2. LP-MP Behavior
4.3.3. NP-MP Behavior
4.3.4. Behavior of a Router That Is Both the LP-MP and NP-MP
4.4. Conditional PathTear
4.4.1. Sending the Conditional PathTear
4.4.2. Processing the Conditional PathTear
4.4.3. CONDITIONS Object
4.5. Remote State Teardown
4.5.1. PLR Behavior on Local Repair Failure
4.5.2. PLR Behavior on Resv RRO Change
4.5.3. LSP Preemption During Local Repair
4.5.3.1. Preemption on LP-MP After PHOP Link Failure
4.5.3.2. Preemption on NP-MP After PHOP Link Failure
4.6. Backward Compatibility Procedures
4.6.1. Detecting Support for Refresh-Interval Independent RSVP
FRR
4.6.2. Procedures for Backward Compatibility
4.6.2.1. Lack of Support on Downstream Nodes
4.6.2.2. Lack of Support on Upstream Nodes
4.6.2.3. Incremental Deployment
4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR
5. Security Considerations
6. IANA Considerations
6.1. CONDITIONS Object
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
RSVP-TE relies on a periodic refresh of RSVP messages to synchronize and maintain the states related to the Label Switched Path (LSP) along the reserved path. In the absence of refresh messages, the LSP-related states are automatically deleted. Reliance on periodic refreshes and refresh timeouts are problematic from the scalability point of view. The number of RSVP-TE LSPs that a router needs to maintain has been growing in service provider networks, and the implementations should be capable of handling increases in LSP scale.
RSVP-TEは、RSVPメッセージの定期的な更新に依存して、予約パスに沿ってラベルスイッチドパス（LSP）に関連する状態を同期および維持します。更新メッセージがない場合、LSP関連状態は自動的に削除されます。定期的な更新と更新のタイムアウトへの依存は、スケーラビリティの観点から問題があります。ルーターが維持する必要があるRSVP-TE LSPの数は、サービスプロバイダーネットワークで増加しており、実装はLSPスケールの増加を処理できる必要があります。
[RFC2961] specifies mechanisms to eliminate the reliance on periodic refreshes and refresh timeouts of RSVP messages and enables a router to increase the message refresh interval to values much longer than the default 30 seconds defined in [RFC2205]. However, the protocol extensions defined in [RFC4090] for supporting Fast Reroute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to clean up stale states.
[RFC2961]は、RSVPメッセージの定期的な更新と更新のタイムアウトへの依存を排除するメカニズムを指定し、[RFC2205]で定義されたデフォルトの30秒よりもはるかに長い値にメッセージを更新することができるようにします。ただし、バイパストンネルを使用した高速リルート（FRR）をサポートするために[RFC4090]で定義されたプロトコル拡張機能は、短い更新タイムアウトに暗黙的に依存して古い状態をクリーンアップします。
In order to eliminate the reliance on refresh timeouts, the routers should unambiguously determine when a particular LSP state should be deleted. In scenarios involving FRR using bypass tunnels [RFC4090], additional explicit teardown messages are necessary. The Refresh-Interval Independent RSVP-TE FRR (RI-RSVP-FRR) extensions specified in this document consist of procedures to enable LSP state cleanup that are essential in supporting the RI-RSVP capability for FRR using bypass tunnels from [RFC4090].
更新タイムアウトへの依存を排除するために、ルーターは特定のLSP状態をいつ削除するかを明確に決定する必要があります。バイパストンネル[RFC4090]を使用したFRRを含むシナリオでは、追加の明示的な分解メッセージが必要です。このドキュメントで指定されたREFRESHERTERVAL独立RSVP-TE FRR（RI-RSVP-FRR）拡張機能は、[RFC4090]からのバイパストンネルを使用してFRRのRI-RSVP機能をサポートするのに不可欠なLSP状態クリーンアップを可能にする手順で構成されています。
Base RSVP [RFC2205] maintains state via the generation of RSVP Path and Resv refresh messages. Refresh messages are used to both synchronize state between RSVP neighbors and to recover from lost RSVP messages. The use of Refresh messages to cover many possible failures has resulted in a number of operational problems.
ベースRSVP [RFC2205]は、RSVPパスとRESVの更新メッセージの生成を介して状態を維持します。更新メッセージは、RSVP近隣の間の状態を同期させ、失われたRSVPメッセージから回復するために使用されます。多くの可能な障害をカバーするために更新メッセージを使用すると、多くの運用上の問題が発生しました。
* One problem relates to RSVP control plane scaling due to periodic refreshes of Path and Resv messages.
* 1つの問題は、PATHおよびRESVメッセージの定期的な更新によるRSVPコントロールプレーンスケーリングに関連しています。
* Another problem relates to the reliability and latency of RSVP signaling.
* 別の問題は、RSVPシグナル伝達の信頼性と潜伏期に関連しています。
* An additional problem is the time to clean up the stale state after a tear message is lost. For more on these problems, see Section 1 of [RFC2961].
* 追加の問題は、涙メッセージが失われた後、古い状態をクリーンアップする時です。これらの問題の詳細については、[RFC2961]のセクション1を参照してください。
The problems listed above adversely affect RSVP control plane scalability, and RSVP-TE [RFC3209] inherited these problems from standard RSVP. Procedures specified in [RFC2961] address the above-mentioned problems by eliminating dependency on refreshes for state synchronization and for recovering from lost RSVP messages, and also by eliminating dependency on refresh timeout for stale state cleanup. Implementing these procedures allows implementations to improve RSVP-TE control plane scalability. For more details on eliminating dependency on refresh timeouts for stale state cleanup, refer to Section 3 of [RFC8370].
上記の問題はRSVPコントロールプレーンのスケーラビリティに悪影響を及ぼし、RSVP-TE [RFC3209]はこれらの問題を標準RSVPから受け継ぎました。[RFC2961]で指定された手順は、状態同期のリフレッシングへの依存関係を排除し、失われたRSVPメッセージから回復し、古い状態のクリーンアップのリフレッシュタイムアウトへの依存関係を排除することにより、上記の問題に対処します。これらの手順を実装することで、実装がRSVP-TEコントロールプレーンのスケーラビリティを改善することができます。古い状態のクリーンアップのリフレッシュタイムアウトへの依存関係の排除の詳細については、[RFC8370]のセクション3を参照してください。
However, the facility backup protection procedures specified in [RFC4090] do not fully address stale state cleanup as the procedures depend on refresh timeouts for stale state cleanup. The updated facility backup protection procedures specified in this document, in combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this dependency on refresh timeouts for stale state cleanup.
ただし、[RFC4090]で指定された施設のバックアップ保護手順は、古い状態のクリーンアップのための更新タイムアウトに依存するため、古い状態のクリーンアップに完全に対処しません。このドキュメントで指定された更新された施設のバックアップ保護手順は、RSVP-TEスケーリング手法[RFC8370]と組み合わせて、古い状態のクリーンアップの更新タイムアウトへのこの依存関係を排除します。
The procedures specified in this document assume reliable delivery of RSVP messages, as specified in [RFC2961]. Therefore, [RFC2961] is a prerequisite for this document.
このドキュメントで指定された手順では、[RFC2961]で指定されているように、RSVPメッセージの信頼できる配信を想定しています。したがって、[RFC2961]はこのドキュメントの前提条件です。
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] で説明されているように解釈されます。
In addition, the reader is expected to be familiar with the terminology in [RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370], and [RFC8796].
さらに、読者は[RFC2205]、[RFC3209]、[RFC4090]、[RFC4558]、[RFC8370]、および[RFC8796]の用語に精通していると予想されます。
PHOP:
PHOP：
Previous-Hop (can refer to a router or node along the LSP)
前ホップ（LSPに沿ったルーターまたはノードを参照できます）
PPHOP:
PPHOP：
Previous-Previous-Hop (can refer to a router or node along the LSP)
以前の困難なホップ（LSPに沿ったルーターまたはノードを参照できます）
NHOP:
NHOP：
Next-Hop (can refer to a router or node along the LSP)
Next-Hop（LSPに沿ったルーターまたはノードを参照できます）
NNHOP:
nnhop：
Next-Next-Hop (can refer to a router or node along the LSP)
Next-Next-Hop（LSPに沿ったルーターまたはノードを参照できます）
PLR:
PLR:
Point of Local Repair (can refer to a router as defined in [RFC4090])
ローカル修理のポイント（[RFC4090]で定義されているルーターを参照できます）
MP:
MP:
Merge Point (can refer to a router as defined in [RFC4090])
マージポイント（[RFC4090]で定義されているルーターを参照できます）
LP-MP:
LP-MP：
Link-Protecting Merge Point (can refer to a router or node at the tail of a Link-Protecting bypass tunnel
リンク保護マージポイント（リンク保護バイパストンネルのテールのルーターまたはノードを参照できます
NP-MP:
NP-MP：
Node-Protecting Merge Point (can refer to a router or node at the tail of a Node-Protecting bypass tunnel
ノード保護マージポイント（ノード保護バイパストンネルのテールのルーターまたはノードを参照できます
PSB:
PSB:
Path State Block
パス状態ブロック
RSB:
RSB:
Reservation State Block
予約状態ブロック
RRO:
RRO:
Record Route Object (as defined in [RFC3209])
Record Routeオブジェクト（[RFC3209]で定義されています）
TED:
TED:
Traffic Engineering Database
トラフィックエンジニアリングデータベース
RI-RSVP:
RI-RSVP：
Refresh-Interval Independent RSVP (the set of procedures defined in Section 3 of [RFC8370] to eliminate RSVP's reliance on periodic message refreshes)
リフレッシュインターバル独立RSVP（[RFC8370]のセクション3で定義されている手順のセットで、RSVPの定期的なメッセージのリフレッシュへの依存を排除します）
RI-RSVP-FRR:
RI-RSVP-FRR：
Refresh-Interval Independent RSVP-TE FRR (the set of procedures defined in this document to eliminate RSVP's reliance on periodic message refreshes when supporting facility backup protection [RFC4090])
更新型独立したRSVP-TE FRR（施設のバックアップ保護をサポートする際のRSVPの定期的なメッセージへの依存を排除するためにこのドキュメントで定義されている一連の手順[RFC4090]））
B-SFRR-Ready:
B-SFRR対応：
Bypass Summary FRR Ready Extended ASSOCIATION object as defined in [RFC8796] and added by the PLR for each protected LSP
[RFC8796]で定義され、保護された各LSPのPLRによって追加されたように、バイパスサマリFRR拡張アソシエーションオブジェクト
Conditional PathTear:
条件付きPATHTEAR：
A PathTear message containing a suggestion to a receiving downstream router to retain the path state if the receiving router is an NP-MP
受信ルーターがNP-MPである場合、パス状態を保持するために受信下流のルーターへの提案を含むPATHTEARメッセージ
Remote PathTear:
Remote Pathtear：
A PathTear message sent from a PLR to the MP to delete the LSP state on the MP if the PLR had not previously sent the backup path state reliably
PLRがMPにMPに送信されたPATHTEARメッセージは、PLRが以前にバックアップパス状態を確実に送信していなかった場合にMPのLSP状態を削除します
LSP state
LSP状態
The combination of "path state" maintained as a PSB and "reservation state" maintained as an RSB forms an individual LSP state on an RSVP-TE speaker
RSBとして維持されているPSBと「予約状態」として維持された「パス状態」の組み合わせは、RSVP-TEスピーカーに個々のLSP状態を形成します
E
/ \
/ \
/ \
/ \
/ \
/ \
A ----- B ----- C ----- D
\ /
\ /
\ /
\ /
\ /
\ /
F
Figure 1: Example Topology
図1：トポロジの例
In the topology in Figure 1, consider a large number of LSPs from A to D transiting B and C. Assume that refresh interval has been configured to be as long as the order of minutes and that refresh reduction extensions are enabled on all routers.
図1のトポロジでは、AからDトランジットBおよびCまでの多数のLSPを検討してください。Minutesの順序が長く、すべてのルーターで更新削減延長が有効になっている限り、更新間隔が構成されていると仮定します。
In addition, assume that node protection has been configured for the LSPs and the LSPs are protected by each router in the following way:
さらに、LSPに対してノード保護が構成されており、LSPが次の方法で各ルーターによって保護されていると仮定します。
* A has made node protection available using bypass LSP A -> E -> C; A is the PLR and C is the NP-MP.
* Aは、バイパスLSP a-> e-> cを使用してノード保護を利用可能にしました。AはPLR、CはNP-MPです。
* B has made node protection available using bypass LSP B -> F -> D; B is the PLR and D is the NP-MP.
* Bは、バイパスLSP b-> f-> dを使用してノード保護を利用可能にしました。BはPLR、DはNP-MPです。
* C has made link protection available using bypass LSP C -> B -> F -> D; C is the PLR and D is the LP-MP.
* Cは、バイパスLSP C-> b-> f-> dを使用して、リンク保護を利用可能にしました。CはPLR、DはLP-MPです。
In the above condition, assume that the B-C link fails. The following is the sequence of events that is expected to occur for all protected LSPs under normal conditions.
上記の状態では、B-Cリンクが失敗すると仮定します。以下は、通常の条件下ですべての保護されたLSPで発生すると予想される一連のイベントです。
Step 1. B performs a local repair and redirects LSP traffic over the bypass LSP B -> F -> D.
ステップ1。B局所修理を実行し、バイパスLSP B-> f-> DでLSPトラフィックをリダイレクトします。
Step 2. B also creates a backup state for the LSP and triggers the sending of a backup LSP state to D over the bypass LSP B -> F -> D.
ステップ2。Bは、LSPのバックアップ状態も作成し、バイパスLSP B-> F-> Dを介してバックアップLSP状態をDに送信することをトリガーします。
Step 3. D receives the backup LSP states and merges the backups with the protected LSPs.
ステップ3。DバックアップLSP状態を受信し、保護されたLSPとバックアップをマージします。
Step 4. As the link on C, over which the LSP states are refreshed, has failed, C will no longer receive state refreshes. Consequently, the protected LSP states on C will time out and C will send the teardown messages for all LSPs. As each router should consider itself as an MP, C will time out the state only after waiting for an additional duration equal to the refresh timeout.
ステップ4。LSP状態が更新されているCのリンクが失敗したため、Cは州の更新を受け取りません。その結果、Cの保護されたLSP状態はタイムアウトし、CはすべてのLSPの分解メッセージを送信します。各ルーターは自分自身をMPと見なす必要があるため、Cは更新時刻と等しい追加期間を待ってからのみ状態をタイムアウトします。
While the above sequence of events has been described in [RFC4090], there are a few problems for which no mechanism has been specified explicitly:
上記の一連のイベントは[RFC4090]で説明されていますが、明示的に指定されているメカニズムがないいくつかの問題があります。
* If the protected LSP on C times out before D receives signaling for the backup LSP, then D would receive a PathTear from C prior to receiving signaling for the backup LSP, thus resulting in deleting the LSP state. This would be possible at scale even with the default refresh time.
* DがバックアップLSPのシグナリングを受信する前にCの保護されたLSPが時間をかけた場合、DはバックアップLSPのシグナルを受信する前にCからパステアを受信し、LSP状態を削除します。これは、デフォルトの更新時間があっても大規模に可能です。
* If C is to keep state until its timeout upon the link failure, then with a long refresh interval, this may result in a large amount of stale state on C. Alternatively, if C is to delete the state and send a PathTear to D upon the link failure, then this would result in deleting the state on D, thus deleting the LSP. D needs a reliable mechanism to determine whether or not it is an MP to overcome this problem.
* Cがリンク障害時のタイムアウトまで状態を維持する場合、リフレッシュ間隔が長い場合、CがCで大量に古くなった状態になる場合があります。代わりに、Cが状態を削除し、リンク障害時にPathTearをDに送信する場合、Dで状態を削除し、LSPを削除する可能性があります。Dは、この問題を克服するためのMPであるかどうかを判断するための信頼できるメカニズムが必要です。
* If head-end A attempts to tear down the LSP after Step 1 but before Step 2 of the above sequence, then B may receive the teardown message before Step 2 and delete the LSP state from its state database. If B deletes its state without informing D, with a long refresh interval, this could cause a (large) buildup of stale state on D.
* ヘッドエンドAがステップ1の後にLSPを破壊しようとする場合、上記のシーケンスのステップ2の前に、Bがステップ2の前に分解メッセージを受信し、状態データベースからLSP状態を削除することができます。bがDを通知せずに状態を削除すると、長いリフレッシュ間隔でその状態を削除すると、これにより、Dの古い状態の（大きな）蓄積が発生する可能性があります。
* If B fails to perform a local repair in Step 1, then B will delete the LSP state from its state database without informing D. As B deletes its state without informing D, with a long refresh interval, this could cause a (large) buildup of stale state on D.
* Bがステップ1でローカル修理を実行できない場合、BはDを通知せずに状態データベースからLSP状態を削除します。BはDを通知せずに状態を削除します。
The purpose of this document is to provide solutions to the above problems, which will then make it practical to scale up to a large number of protected LSPs in the network.
このドキュメントの目的は、上記の問題に対する解決策を提供することです。これにより、ネットワーク内の多数の保護されたLSPに拡大することが実用的になります。
The solution consists of five parts:
ソリューションは5つの部分で構成されています。
1. Utilize the MP determination mechanism specified in RSVP-TE Summary FRR [RFC8796] that enables the PLR to signal the availability of local protection to the MP. In addition, introduce PLR and MP procedures to establish a Node-ID-based Hello session between the PLR and the MP to detect router failures and to determine capability. See Section 4.2 of this document for more details. This part of the solution reuses some of the extensions defined in [RFC8796] and [RFC8370], and the subsequent subsections will list the extensions in these documents that are utilized in this document.
1. RSVP-TEサマリーFRR [RFC8796]で指定されたMP決定メカニズムを利用して、PLRがMPへのローカル保護の可用性を信号することができます。さらに、PLRおよびMP手順を導入して、PLRとMPの間にノードIDベースのハローセッションを確立して、ルーターの障害を検出し、機能を決定します。詳細については、このドキュメントのセクション4.2を参照してください。ソリューションのこの部分は、[RFC8796]および[RFC8370]で定義されている拡張機能の一部を再利用し、その後のサブセクションには、このドキュメントで利用されているこれらのドキュメントの拡張機能がリストされます。
2. Handle upstream link or node failures by cleaning up LSP states if the node has not found itself as an MP through the MP determination mechanism. See Section 4.3 of this document for more details.
2. ノードがMP決定メカニズムを介してMPとして認定されていない場合、LSP状態をクリーンアップして、上流のリンクまたはノードの障害を処理します。詳細については、このドキュメントのセクション4.3を参照してください。
3. Introduce extensions to enable a router to send a teardown message to the downstream router that enables the receiving router to conditionally delete its local LSP state. See Section 4.4 of this document for more details.
3. 拡張機能を導入して、ルーターが下流のルーターに断downメッセージを送信できるようにし、受信ルーターがローカルLSP状態を条件付きで削除できるようにします。詳細については、このドキュメントのセクション4.4を参照してください。
4. Enhance facility backup protection by allowing a PLR to directly send a teardown message to the MP without requiring the PLR to either have a working bypass LSP or have already signaled the backup LSP state. See Section 4.5 of this document for more details.
4. PLRが作業バイパスLSPを持つか、すでにバックアップLSP状態を既に合図していることを要求せずに、PLRがMPに直接MPに直接送信できるようにすることにより、施設のバックアップ保護を強化します。詳細については、このドキュメントのセクション4.5を参照してください。
5. Introduce extensions to enable the above procedures to be backward compatible with routers along the LSP running implementations that do not support these procedures. See Section 4.6 of this document for more details.
5. 拡張機能を紹介して、上記の手順を、これらの手順をサポートしていないLSPランニング実装に沿ってルーターと後方互換性を持つことができます。詳細については、このドキュメントのセクション4.6を参照してください。
A node supporting facility backup protection [RFC4090] MUST NOT set the RI-RSVP flag (I-bit) that is defined in Section 3.1 of [RFC8370] unless it supports all the extensions specified in the rest of this document. Hence, this document updates [RFC4090] by defining extensions and additional procedures over facility backup protection [RFC4090] in order to advertise the RI-RSVP capability [RFC8370]. However, if a node supporting facility backup protection [RFC4090] does set the RI-RSVP capability (I-bit) but does not support all the extensions specified in the rest of this document, then it may result in lingering stale states due to the long refresh intervals recommended by [RFC8370]. This can also disrupt normal Fast Reroute (FRR) operations. Section 4.7 of this document delves into this in detail.
施設をサポートするバックアップ保護[RFC4090]は、このドキュメントの残りの部分で指定されたすべての拡張機能をサポートしない限り、[RFC8370]のセクション3.1で定義されているRI-RSVPフラグ（Iビット）を設定してはなりません。したがって、このドキュメントは、RI-RSVP機能[RFC8370]を宣伝するために、施設のバックアップ保護[RFC4090]を介した拡張機能と追加手順を定義することにより、[RFC4090]を更新します。ただし、ノードサポート機能のバックアップ保護[RFC4090]がRI-RSVP機能（I-BIT）を設定しているが、このドキュメントの残りの部分で指定されたすべての拡張機能をサポートしていない場合、[RFC8370]が推奨する長い更新間隔のために古い状態が長引く可能性があります。これは、通常の高速Reroute（FRR）操作を混乱させる可能性もあります。このドキュメントのセクション4.7は、これを詳細に掘り下げています。
As per the facility backup procedures [RFC4090], when an LSP becomes operational on a node and the "local protection desired" flag has been set in the SESSION_ATTRIBUTE object carried in the Path message corresponding to the LSP, then the node attempts to make local protection available for the LSP.
施設のバックアップ手順[RFC4090]によると、LSPがノードで動作可能になり、「ローカル保護」フラグがLSPに対応するパスメッセージに携帯されているsession_attributeオブジェクトに設定された場合、ノードはLSPでローカル保護を利用できるようにします。
* If the "node protection desired" flag is set, then the node tries to become a PLR by attempting to create an NP-bypass LSP to the NNHOP node avoiding the NHOP node on a protected LSP. In case node protection could not be made available, the node attempts to create an LP-bypass LSP to the NHOP node avoiding only the link that the protected LSP takes to reach the NHOP.
* 「ノード保護が望ましい」フラグが設定されている場合、ノードは、保護されたLSPでNHOPノードを回避するNNHOPノードにNP-ByPass LSPを作成しようとすることによりPLRになろうとします。ノード保護が利用できなかった場合、ノードは、保護されたLSPがNHOPに到達するために取るリンクのみを回避するNHOPノードにLP-Bypass LSPを作成しようとします。
* If the "node protection desired" flag is not set, then the PLR attempts to create an LP-bypass LSP to the NHOP node avoiding the link that the protected LSP takes to reach the NHOP.
* 「ノード保護が望ましい」フラグが設定されていない場合、PLRは、保護されたLSPがNHOPに到達するために取るリンクを回避するNHOPノードにLP-ByPass LSPを作成しようとします。
With regard to the PLR procedures described above and specified in [RFC4090], this document specifies the following additional procedures to support RI-RSVP [RFC8370].
上記と[RFC4090]で指定されたPLR手順に関して、このドキュメントは、RI-RSVP [RFC8370]をサポートするための以下の追加手順を指定しています。
* While selecting the destination address of the bypass LSP, the PLR MUST select the router ID of the NNHOP or NHOP node from the Node-ID sub-object included in the RRO that is carried in the most recent Resv message corresponding to the LSP. If the MP has not included a Node-ID sub-object in the Resv RRO and if the PLR and the MP are in the same area, then the PLR may utilize the TED to determine the router ID corresponding to the interface address that is included by the MP in the RRO. If the NP-MP in a different IGP area has not included a Node-ID sub-object in the RRO, then the PLR MUST execute backward compatibility procedures as if the downstream nodes along the LSP do not support the extensions defined in the document (see Section 4.6.2.1).
* バイパスLSPの宛先アドレスを選択しているときに、PLRは、LSPに対応する最新のRESVメッセージに運ばれるNODE-IDサブオブジェクトからNNHOPまたはNHOPノードのルーターIDを選択する必要があります。MPにRESV RROにノードIDサブオブジェクトが含まれておらず、PLRとMPが同じ領域にある場合、PLRはTEDを利用して、RROのMPに含まれるインターフェイスアドレスに対応するRouter IDを決定することができます。別のIGP領域のNP-MPにRROにノードIDサブオブジェクトが含まれていない場合、PLRはLSPに沿った下流ノードがドキュメントで定義されている拡張をサポートしていないかのように逆方向の互換性手順を実行する必要があります（セクション4.6.2.1を参照）。
* The PLR MUST also include its router ID in a Node-ID sub-object in the RRO that is carried in any subsequent Path message corresponding to the LSP. While doing so, the PLR MUST include the Node-ID sub-object after including its IPv4/IPv6 address or unnumbered interface ID sub-object.
* また、PLRは、LSPに対応する後続のパスメッセージで運ばれるRROのノードIDサブオブジェクトにルーターIDを含める必要があります。そうする際、PLRは、IPv4/IPv6アドレスまたは非数のインターフェイスIDサブオブジェクトを含めた後、ノードIDサブオブジェクトを含める必要があります。
* In parallel to the attempt made to create an NP-bypass or an LP-bypass, the PLR MUST initiate a Node-ID-based Hello session to the NNHOP or NHOP node respectively along the LSP to establish the RSVP-TE signaling adjacency. This Hello session is used to detect MP node failure as well as to determine the capability of the MP node. The PLR MUST conclude that the MP supports the refresh-interval independent FRR procedures defined in this document if the MP has set the I-bit in the CAPABILITY object [RFC8370] carried in the Hello message corresponding to the Node-ID-based Hello session. If the MP has not sent Node-ID-based Hello messages or has not set the I-bit in the CAPABILITY object [RFC8370], then the PLR MUST execute backward compatibility procedures defined in Section 4.6.2.1 of this document.
* NP-ByPassまたはLP-Bypassを作成するための試みと並行して、PLRはLSPに沿ってそれぞれNNHOPまたはNHOPノードにノードIDベースのハローセッションを開始して、RSVP-TEシグナル伝達隣接を確立する必要があります。このハローセッションは、MPノード障害を検出し、MPノードの機能を決定するために使用されます。PLRは、MPがNode-IDベースのハローセッションに対応するHello Messageに搭載されている機能オブジェクト[RFC8370]にMPが設定されている場合、このドキュメントで定義されている更新される独立したFRR手順をサポートすると結論付けなければなりません。MPがNode-IDベースのHelloメッセージを送信していないか、機能オブジェクト[RFC8370]にIビットを設定していない場合、PLRはこのドキュメントのセクション4.6.2.1で定義されている後方互換性手順を実行する必要があります。
* When the PLR associates a bypass to a protected LSP, it MUST include a B-SFRR-Ready Extended ASSOCIATION object [RFC8796] and trigger a Path message to be sent for the LSP. If a B-SFRR-Ready Extended ASSOCIATION object is included in the Path message corresponding to the LSP, the encoding and object ordering rules specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In addition to those rules, the PLR MUST set the Association Source in the object to its Node-ID address.
* PLRがバイパスを保護されたLSPに関連付ける場合、B-SFRR対応拡張アソシエーションオブジェクト[RFC8796]を含め、LSPに送信されるパスメッセージをトリガーする必要があります。LSPに対応するパスメッセージにB-SFRR対応の拡張アソシエーションオブジェクトが含まれている場合、RSVP-TEサマリFRR [RFC8796]で指定されたエンコーディングおよびオブジェクト順序付けルールに従う必要があります。これらのルールに加えて、PLRはオブジェクトのアソシエーションソースをノードIDアドレスに設定する必要があります。
A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is used in the source and the destination address fields of RSVP Hello messages [RFC4558]. This document extends Node-ID-based RSVP Hello sessions to track the state of any RSVP-TE neighbor that is not directly connected by at least one interface. In order to apply Node-ID-based RSVP-TE Hello sessions between any two routers that are not immediate neighbors, the router that supports the extensions defined in the document MUST set the TTL to 255 in all outgoing Node-ID-based Hello messages exchanged between the PLR and the MP. The default hello interval for this Node-ID Hello session MUST be set to the default specified in RSVP-TE Scaling Techniques [RFC8370].
ノードIDベースのRSVP-TE Helloセッションは、RSVP Helloメッセージ[RFC4558]のソースおよび宛先アドレスフィールドでノードIDが使用されるものです。このドキュメントは、ノードIDベースのRSVPハローセッションを拡張して、少なくとも1つのインターフェイスで直接接続されていないRSVP-TE隣人の状態を追跡します。Node-IDベースのRSVP-TEハローセッションを任意の2つのルーターではない2つのルーター間で適用するには、ドキュメントで定義されている拡張機能をサポートするルーターは、PLRとMPの間で交換されるすべての発信ノードIDベースのハローメッセージでTTLを255に設定する必要があります。このNode-ID Helloセッションのデフォルトのハロー間隔は、RSVP-TEスケーリング手法[RFC8370]で指定されたデフォルトに設定する必要があります。
In the rest of the document, the terms "signaling adjacency" and "remote signaling adjacency" refer specifically to the RSVP-TE signaling adjacency.
文書の残りの部分では、「シグナリング隣接」および「リモートシグナル伝達隣接」という用語は、RSVP-TEシグナリングの隣接を特に指します。
With regard to the MP procedures that are defined in [RFC4090], this document specifies the following additional procedures to support RI-RSVP as defined in [RFC8370].
[RFC4090]で定義されているMP手順に関して、このドキュメントは、[RFC8370]で定義されているRI-RSVPをサポートする次の追加手順を指定します。
Each node along an LSP supporting the extensions defined in this document MUST also include its router ID in the Node-ID sub-object of the RRO that is carried in the Resv message of the corresponding LSP. If the PLR has not included a Node-ID sub-object in the RRO that is carried in the Path message and if the PLR is in a different IGP area, then the router MUST NOT execute the MP procedures specified in this document for those LSPs. Instead, the node MUST execute backward compatibility procedures defined in Section 4.6.2.2 of this document as if the upstream nodes along the LSP do not support the extensions defined in this document.
このドキュメントで定義されている拡張機能をサポートするLSPに沿った各ノードには、対応するLSPのRESVメッセージに掲載されるRROのノードIDサブオブジェクトにルーターIDを含める必要があります。PLRにパスメッセージに携帯されるRROにノードIDサブオブジェクトが含まれていない場合、PLRが別のIGP領域にある場合、ルーターはこれらのLSPについてこのドキュメントで指定されたMP手順を実行してはなりません。代わりに、ノードは、このドキュメントのセクション4.6.2.2で定義されている後方互換性の手順を実行する必要があり、LSPに沿った上流ノードがこのドキュメントで定義されている拡張機能をサポートしていないかのようにします。
A node receiving a Path message should determine:
パスメッセージを受信するノードが決定する必要があります。
* whether the message contains a B-SFRR-Ready Extended ASSOCIATION object with its own address as the bypass destination address and
* メッセージに、バイパス宛先アドレスとして独自のアドレスを持つB-SFRR対応の拡張アソシエーションオブジェクトが含まれているかどうか
* whether it has an operational Node-ID signaling adjacency with the Association Source.
* Association Sourceとの隣接する操作可能なNode-IDシグナル伝達があるかどうか。
The node MUST execute the backward compatibility procedures defined in Section 4.6.2.2 of this document if:
ノードは、次の場合、このドキュメントのセクション4.6.2.2で定義されている後方互換性の手順を実行する必要があります。
* the PLR has not included the B-SFRR-Ready Extended ASSOCIATION object,
* PLRには、B-SFRR対応の拡張アソシエーションオブジェクトが含まれていません。
* there is no operational Node-ID signaling adjacency with the PLR identified by the Association Source address, or
* Association Sourceアドレスによって識別されたPLRには、運用上のノードIDシグナル伝達隣接がありません。
* the PLR has not advertised the RI-RSVP capability in its Node-ID-based Hello messages.
* PLRは、Node-IDベースのHelloメッセージにRI-RSVP機能を宣伝していません。
If a matching B-SFRR-Ready Extended ASSOCIATION object is found in the Path message and if there is an operational remote Node-ID signaling adjacency with the PLR (identified by the Association Source) that has advertised the RI-RSVP capability (I-bit) [RFC8370], then the node MUST consider itself as the MP for the PLR. The matching and ordering rules for Bypass Summary FRR Extended Association specified in RSVP-TE Summary FRR [RFC8796] MUST be followed by the implementations supporting this document.
一致するB-SFRR対応の拡張アソシエンスオブジェクトがパスメッセージにあり、RI-RSVP機能（I-BIT）[RFC8370]を宣伝したPLR（Association Sourceによって識別）と動作するリモートノードIDシグナリング隣接がある場合、ノードはPLRのMPと考えなければなりません。RSVP-TEサマリーFRR [RFC8796]で指定されたバイパスサマリーFRR拡張アソシエーションのマッチングおよび順序付けルールの後に、このドキュメントをサポートする実装が続く必要があります。
* If a matching Bypass Summary FRR Extended Association object is included by the PPHOP node of an LSP and if a corresponding Node-ID signaling adjacency exists with the PPHOP node, then the router MUST conclude it is the NP-MP.
* 一致するバイパスサマリーFRR拡張アソシエーションオブジェクトがLSPのPPHOPノードに含まれ、対応するノードIDシグナル伝達隣接がPPHOPノードに存在する場合、ルーターはNP-MPであると結論付ける必要があります。
* If a matching Bypass Summary FRR Extended Association object is included by the PHOP node of an LSP and if a corresponding Node-ID signaling adjacency exists with the PHOP node, then the router MUST conclude it is the LP-MP.
* 一致するバイパスサマリーFRR拡張アソシエーションオブジェクトがLSPのPHOPノードに含まれ、対応するノードIDシグナル伝達隣接がPHOPノードに存在する場合、ルーターはLP-MPであると結論付ける必要があります。
Once a router concludes it is the MP for a PLR running refresh-interval independent FRR procedures as described in the preceding section, it MUST create a remote path state for the LSP. The only difference between the "remote" path state and the LSP state is the RSVP_HOP object. The RSVP_HOP object in a "remote" path state contains the address that the PLR uses to send Node-ID Hello messages to the MP.
ルーターが前述のセクションで説明されているように、REFREST-INTERVAL Independent FRR手順を実行するPLRのMPであると結論付けたら、LSPのリモートパス状態を作成する必要があります。「リモート」パス状態とLSP状態の唯一の違いは、RSVP_HOPオブジェクトです。「リモート」パス状態のRSVP_HOPオブジェクトには、PLRがNode-ID HelloメッセージをMPに送信するために使用するアドレスが含まれています。
The MP MUST consider the "remote" path state corresponding to the LSP automatically deleted if:
MPは、次の場合、LSPに対応する「リモート」パス状態を自動的に削除することを考慮する必要があります。
* the MP later receives a Path message for the LSP with no matching B-SFRR-Ready Extended ASSOCIATION object corresponding to the PLR's IP address contained in the Path RRO,
* MPは後に、パスRROに含まれるPLRのIPアドレスに対応するB-SFRR対応拡張アソシエーションオブジェクトと一致することのないLSPのパスメッセージを受信します。
* the Node-ID signaling adjacency with the PLR goes down,
* PLRを伴うNode-IDの信号隣接はダウンします、
* the MP receives backup LSP signaling for the LSP from the PLR,
* MPは、PLRからLSPのバックアップLSPシグナリングを受け取ります。
* the MP receives a PathTear for the LSP, or
* MPは、LSPのPATHTEARを受け取ります
* the MP deletes the LSP state on a local policy or an exception event.
* MPは、ローカルポリシーまたは例外イベントでLSP状態を削除します。
The purpose of "remote" path state is to enable the PLR to explicitly tear down the path and reservation states corresponding to the LSP by sending a tear message for the "remote" path state. Such a message tearing down the "remote" path state is called "Remote" PathTear.
「リモート」パス状態の目的は、PLRが「リモート」パス状態の涙メッセージを送信することにより、LSPに対応するパスと予約状態を明示的に取り壊すことを可能にすることです。このようなメッセージは、「リモート」パス状態を引き裂くメッセージは、「リモート」PathTearと呼ばれます。
The scenarios in which a "Remote" PathTear is applied are described in Section 4.5 of this document.
「リモート」PATHTEARが適用されるシナリオは、このドキュメントのセクション4.5で説明されています。
This section describes the procedures that must be executed upon different kinds of failures by nodes along the path of the LSP. The procedures that must be executed upon detecting RSVP signaling adjacency failures do not impact the RSVP-TE graceful restart mechanisms [RFC3473] [RFC5063]. If a node executing these procedures acts as a helper for a neighboring router, then the signaling adjacency with the neighbor will be declared as having failed only after taking into account the grace period extended for the neighbor by this node acting as a helper.
このセクションでは、LSPの経路に沿ったノードによって異なる種類の障害時に実行されなければならない手順について説明します。RSVPシグナル伝達の隣接障害を検出したときに実行する必要がある手順は、RSVP-TEの優雅な再起動メカニズムに影響しません[RFC3473] [RFC5063]。これらの手順を実行するノードが隣接するルーターのヘルパーとして機能する場合、隣人との信号隣接性は、このノードがヘルパーとして機能する隣人が拡張したGRACE期間を考慮した後にのみ失敗したと宣言されます。
Node failures are detected from the state of Node-ID Hello sessions established with immediate neighbors. RSVP-TE Scaling Techniques [RFC8370] recommends that each node establish Node-ID Hello sessions with all its immediate neighbors. A non-immediate PLR or MP failure is detected from the state of remote signaling adjacency established according to Section 4.2.2 of this document.
ノードの障害は、近隣の隣人が確立されたNode-IDハローセッションの状態から検出されます。RSVP-TEスケーリング手法[RFC8370]は、各ノードがすべてのすぐ近くのすべての人とノードIDハローセッションを確立することを推奨しています。このドキュメントのセクション4.2.2に従って確立されたリモートシグナル伝達隣接の状態から、非誤ったPLRまたはMP障害が検出されます。
When a router detects the PHOP link or the PHOP node failure for an LSP and the router is not an MP for the LSP, then it MUST send a Conditional PathTear (refer to Section 4.4 of this document) and delete the PSB and RSB states corresponding to the LSP.
ルーターがLSPのPHOPリンクまたはPHOPノード障害を検出し、ルーターがLSPのMPではない場合、条件付きパステア（このドキュメントのセクション4.4を参照）を送信し、LSPに対応するPSBおよびRSB状態を削除する必要があります。
When the PHOP link for an LSP fails on a router that is an LP-MP for the LSP, the LP-MP MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:
LSPのLSPのPHOPリンクがLSPのLP-MPであるルーターで失敗する場合、LP-MPは、次のイベントのいずれかが発生するまでLSPに対応するPSBおよびRSB状態を保持する必要があります。
* the Node-ID signaling adjacency with the PHOP PLR goes down,
* PHOPPLRを伴うノードIDシグナル伝達隣接はダウンします、
* the MP receives a normal or "Remote" PathTear for its PSB, or
* MPは、PSBに対して通常または「リモート」パストーテアを受け取ります。
* the MP receives a ResvTear for its RSB.
* MPは、RSBに対してresvtearを受け取ります。
When a router that is an LP-MP for an LSP detects PHOP node failure from the Node-ID signaling adjacency state, the LP-MP MUST send a normal PathTear and delete the PSB and RSB states corresponding to the LSP.
LSPのLP-MPであるルーターが、ノードIDシグナリング隣接状態からPHOPノード障害を検出する場合、LP-MPは通常のパステアを送信し、LSPに対応するPSBおよびRSB状態を削除する必要があります。
When a router that is an NP-MP for an LSP detects PHOP link failure or PHOP node failure from the Node-ID signaling adjacency, the router MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:
LSPのNP-MPであるルーターが、Node-IDシグナル伝達隣接からPHOPリンク障害またはPHOPノード障害を検出する場合、ルーターは、次のイベントの発生までLSPに対応するPSBおよびRSB状態を保持する必要があります。
* the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
* PPHOP PLRを使用したリモートノードIDシグナル伝達隣接はダウンします。
* the MP receives a normal or "Remote" PathTear for its PSB, or
* MPは、PSBに対して通常または「リモート」パストーテアを受け取ります。
* the MP receives a ResvTear for its RSB.
* MPは、RSBに対してresvtearを受け取ります。
When a router that is an NP-MP for an LSP does not detect the PHOP link or the PHOP node failure but receives a Conditional PathTear from the PHOP node, then the router MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:
LSPのNP-MPであるルーターがPHOPリンクまたはPHOPノード障害を検出せず、PHOPノードから条件付きパステアを受信する場合、ルーターは次のイベントの発生までLSPに対応するPSBおよびRSB状態を保持する必要があります。
* the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
* PPHOP PLRを使用したリモートノードIDシグナル伝達隣接はダウンします。
* the MP receives a normal or "Remote" PathTear for its PSB, or
* MPは、PSBに対して通常または「リモート」パストーテアを受け取ります。
* the MP receives a ResvTear for its RSB.
* MPは、RSBに対してresvtearを受け取ります。
Receiving a Conditional PathTear from the PHOP node will not impact the "remote" state from the PPHOP PLR. Note that the PHOP node must have sent the Conditional PathTear as it was not an MP for the LSP (see Section 4.3.1 of this document).
PHOPノードから条件付きPATHTEARを受信しても、PPHOP PLRから「リモート」状態に影響しません。PHOPノードは、LSPのMPではなかったため、条件付きパステアを送信している必要があることに注意してください（このドキュメントのセクション4.3.1を参照）。
In the example topology in Figure 1, we assume C and D are the NP-MPs for the PLRs A and B, respectively. Now, when the A-B link fails, B will delete the LSP state, because B is not an MP and its PHOP link has failed (this behavior is required for unprotected LSPs; refer to Section 4.3.1 of this document). In the data plane, that would require B to delete the label forwarding entry corresponding to the LSP. Thus, if B's downstream nodes C and D continue to retain state, it would not be correct for D to continue to assume itself as the NP-MP for the PLR B.
図1のトポロジの例では、CとDがそれぞれPLRS AおよびBのNP-MPSであると仮定します。A-Bリンクが失敗すると、BはMPではなく、PHOPリンクが故障しているため、BはLSP状態を削除します（この動作は保護されていないLSPに必要です。このドキュメントのセクション4.3.1を参照）。データプレーンでは、LSPに対応するラベル転送エントリを削除するにはBが必要です。したがって、Bの下流ノードCとDが状態を保持し続ける場合、DがPLR BのNP-MPとして自らを引き続き想定し続けることは正しくありません。
The mechanism that enables D to stop considering itself as the NP-MP for B and delete the corresponding "remote" path state is given below.
DがBのNP-MPとして自分自身を考慮し、対応する「リモート」パス状態を削除することを停止できるメカニズムを以下に示します。
1. When C receives a Conditional PathTear from B, it decides to retain the LSP state as it is the NP-MP of the PLR A. It also checks whether PHOP B had previously signaled availability of node protection. As B had previously signaled NP availability by including the B-SFRR-Ready Extended ASSOCIATION object, C removes the B-SFRR-Ready Extended ASSOCIATION object containing the Association Source set to B from the Path message and triggers a Path to D.
1. cがBから条件付きパストゥールを受信すると、PLR AのNP-MPであるため、LSP状態を保持することを決定します。また、PHOP Bが以前にノード保護の可用性を示していたかどうかをチェックします。Bは以前にB-SFRR対応拡張アソシエーションオブジェクトを含めることでNPの可用性をシグナル付けしていたため、CはパスメッセージからBに設定されたアソシエーションソースセットを含むB-SFRR対応拡張アソシエーションオブジェクトを削除し、Dへのパスをトリガーします。
2. When D receives the Path message, it realizes that it is no longer the NP-MP for B and so it deletes the corresponding "remote" path state. D does not propagate the Path further down because the only change is that the B-SFRR-Ready Extended ASSOCIATION object corresponding to Association Source B is no longer present in the Path message.
2. dがパスメッセージを受信すると、それがBのNP-MPではなくなったことに気付くため、対応する「リモート」パス状態を削除します。Dは、パスメッセージに対応するB-SFRR対応の拡張アソシエーションオブジェクトがパスメッセージに存在しなくなったことであるため、Dはさらに下にパスを伝播しません。
A router may simultaneously be the LP-MP and the NP-MP for the PHOP and PPHOP nodes of an LSP, respectively. If the PHOP link fails on such a node, the node MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:
ルーターは、それぞれLSPのPHOPノードとPPHOPノードのLP-MPとNP-MPである場合があります。このようなノードでPHOPリンクが失敗した場合、ノードは次のイベントの発生までLSPに対応するPSBおよびRSB状態を保持する必要があります。
* both Node-ID signaling adjacencies with PHOP and PPHOP nodes go down,
* PHOPノードとPPHOPノードを使用したnode-idシグナリングの両方の隣接が下がります。
* the MP receives a normal or "Remote" PathTear for its PSB, or
* MPは、PSBに対して通常または「リモート」パストーテアを受け取ります。
* the MP receives a ResvTear for its RSB.
* MPは、RSBに対してresvtearを受け取ります。
If a router that is both an LP-MP and an NP-MP detects PHOP node failure, then the node MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:
LP-MPとNP-MPの両方であるルーターがPHOPノードの障害を検出する場合、ノードは次のイベントの発生までLSPに対応するPSBおよびRSB状態を保持する必要があります。
* the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
* PPHOP PLRを使用したリモートノードIDシグナル伝達隣接はダウンします。
* the MP receives a normal or "Remote" PathTear for its PSB, or
* MPは、PSBに対して通常または「リモート」パストーテアを受け取ります。
* the MP receives a ResvTear for its RSB.
* MPは、RSBに対してresvtearを受け取ります。
In the example provided in Section 4.3.3 of this document, B deletes the PSB and RSB states corresponding to the LSP once B detects its PHOP link has gone down as B is not an MP. If B were to send a PathTear normally, then C would delete the LSP state immediately. In order to avoid this, there should be some mechanism by which B can indicate to C that B does not require the receiving node to unconditionally delete the LSP state immediately. For this, B MUST add a new optional CONDITIONS object in the PathTear. The CONDITIONS object is defined in Section 4.4.3 of this document. If node C also understands the new object, then C MUST NOT delete the LSP state if it is an NP-MP.
このドキュメントのセクション4.3.3で提供されている例では、BはBがMPではないため、PHOPリンクが下がった場合、LSPに対応するPSBおよびRSB状態を削除します。bが正常にPathtearを送信する場合、CはLSP状態をすぐに削除します。これを回避するために、Bがbが無条件にLSP状態をすぐに削除するために受信ノードを必要としないことをcに示すことができるいくつかのメカニズムがあるはずです。このために、BはPathTearに新しいオプションの条件オブジェクトを追加する必要があります。条件オブジェクトは、このドキュメントのセクション4.4.3で定義されています。Node Cも新しいオブジェクトを理解している場合、CがNP-MPである場合、LSP状態を削除してはなりません。
A router that is not an MP for an LSP MUST delete the PSB and RSB states corresponding to the LSP if the PHOP link or the PHOP Node-ID signaling adjacency goes down (see Section 4.3.1 of this document). The router MUST send a Conditional PathTear if the following are also true:
LSPのMPではないルーターは、PHOPリンクまたはPHOPノードIDシグナル伝達隣接が低下した場合、LSPに対応するPSBおよびRSB状態を削除する必要があります（このドキュメントのセクション4.3.1を参照）。ルーターは、次の場合も条件付きPATHTEARを送信する必要があります。
* the ingress has requested node protection for the LSP and
* 侵入はLSPのノード保護を要求し、
* no PathTear is received from the upstream node.
* 上流ノードからPATHTEARは受信されません。
When a router that is not an NP-MP receives a Conditional PathTear, the node MUST delete the PSB and RSB states corresponding to the LSP and process the Conditional PathTear by considering it as a normal PathTear. Specifically, the node MUST NOT propagate the Conditional PathTear downstream but remove the optional object and send a normal PathTear downstream.
NP-MPではないルーターが条件付きPATHTEARを受信する場合、ノードはLSPに対応するPSBおよびRSB状態を削除し、通常のパステアと見なすことにより条件付きパステアを処理する必要があります。具体的には、ノードは条件付きパスの下流を伝播しないでください。オプションのオブジェクトを削除して、下流の通常のパステアを送信する必要があります。
When a node that is an NP-MP receives a Conditional PathTear, it MUST NOT delete the LSP state. The node MUST check whether the PHOP node had previously included the B-SFRR-Ready Extended ASSOCIATION object in the Path. If the object had been included previously by the PHOP, then the node processing the Conditional PathTear from the PHOP MUST remove the corresponding object and trigger a Path downstream.
NP-MPであるノードが条件付きPATHTEARを受信した場合、LSP状態を削除してはなりません。ノードは、PHOPノードに以前にパスにB-SFRR対応拡張アソシエーションオブジェクトを含めていたかどうかを確認する必要があります。オブジェクトが以前にPHOPに含まれていた場合、PHOPから条件付きパステアを処理するノードは、対応するオブジェクトを削除し、下流のパスをトリガーする必要があります。
If a Conditional PathTear is received from a neighbor that has not advertised support (refer to Section 4.6 of this document) for the new procedures defined in this document, then the node MUST consider the message as a normal PathTear. The node MUST propagate the normal PathTear downstream and delete the LSP state.
このドキュメントで定義されている新しい手順について、サポートを宣伝していない隣人（このドキュメントのセクション4.6を参照）から条件付きPathtearが受信された場合、ノードはメッセージを通常のPathtearと見なす必要があります。ノードは、通常のPathtearの下流を伝播し、LSP状態を削除する必要があります。
Any implementation that does not support a Conditional PathTear needs to ignore the new object but process the message as a normal PathTear without generating any error. For this reason, the Class-Num of the new object follows the pattern 10bbbbbb, where "b" represents a bit. (The behavior for objects of this type is specified in Section 3.10 of [RFC2205].)
条件付きPATHTEARをサポートしていない実装は、新しいオブジェクトを無視する必要がありますが、エラーを生成せずにメッセージを通常のPATHTEARとして処理する必要があります。このため、新しいオブジェクトのクラスナムは、パターン10bbbbbbbに従います。ここで、「b」は少し表します。（このタイプのオブジェクトの動作は、[RFC2205]のセクション3.10で指定されています。）
The new object is called the "CONDITIONS" object and will specify the conditions under which default processing rules of the RSVP-TE message MUST be invoked.
新しいオブジェクトは「条件」オブジェクトと呼ばれ、RSVP-TEメッセージのデフォルト処理ルールを呼び出す必要がある条件を指定します。
The object has the following format:
オブジェクトには次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class | C-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags (Reserved) |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CONDITIONS Object
図2：条件オブジェクト
Class:
クラス：
135
135
C-type:
Cタイプ：
1
1
Flags:
フラグ：
32 bit field
32ビットフィールド
M:
M:
Bit 31 is the Merge-point condition (M) bit. If the M bit is set to 1, then the PathTear message MUST be processed according to the receiver router role, i.e., if the receiving router is an MP or not for the LSP. If it is not set, then the PathTear message MUST be processed as a normal PathTear message for the LSP.
ビット31は、マージポイント条件（m）ビットです。Mビットが1に設定されている場合、PATHTEARメッセージはレシーバールーターの役割に応じて処理する必要があります。つまり、受信ルーターがLSPのMPであるかどうかの場合。設定されていない場合は、PATHTEARメッセージをLSPの通常のPATHTEARメッセージとして処理する必要があります。
Bits 0-30 are reserved; they MUST be set to zero on transmission and MUST be ignored on receipt.
ビット0〜30は予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
If the ingress wants to tear down the LSP because of a management event while the LSP is being locally repaired at a transit PLR, it would not be desirable to wait until the completion of backup LSP signaling to perform state cleanup. In this case, the PLR MUST send a "Remote" PathTear message instructing the MP to delete the PSB and RSB states corresponding to the LSP. The TTL in the "Remote" PathTear message MUST be set to 255. Doing this enables LSP state cleanup when the LSP is being locally repaired.
LSPがトランジットPLRでローカルに修復されている間に管理イベントのためにIngressがLSPを取り壊したい場合、バックアップLSPシグナリングが完了するまで状態クリーンアップを実行するまで待つことは望ましくありません。この場合、PLRは、LSPに対応するPSBおよびRSB状態を削除するようにMPを指示する「リモート」PATHTEARメッセージを送信する必要があります。「リモート」PATHTEARメッセージのTTLは255に設定する必要があります。これを実行すると、LSPがローカルで修理されている場合にLSP状態のクリーンアップが可能になります。
Consider that node C in the example topology (Figure 1) has gone down and node B locally repairs the LSP:
例のトポロジ（図1）のノードCが下がっており、ノードBがLSPをローカルに修理していることを考えてください。
1. Ingress A receives a management event to tear down the LSP.
1. イングレスAは、LSPを取り壊すために管理イベントを受け取ります。
2. A sends a normal PathTear for the LSP to B.
2. a lspの通常のパスタートをBに送信します。
3. Assume B has not initiated the backup signaling for the LSP during local repair. To enable LSP state cleanup, B sends a "Remote" PathTear with the destination IP address set to that of the node D used in the Node-ID signaling adjacency with D and the RSVP_HOP object containing the local address used in the Node-ID signaling adjacency.
3. Bがローカル修理中にLSPのバックアップシグナリングを開始していないと仮定します。LSP状態のクリーンアップを有効にするために、Bは、DとノードIDのシグナリング隣接順序で使用されているノードDと、ノードIDシグナリング隣接に使用されるローカルアドレスを含むRSVP_HOPオブジェクトを使用して、宛先IPアドレスを設定した「リモート」パステアを送信します。
4. B then deletes the PSB and RSB states corresponding to the LSP.
4. 次に、BはLSPに対応するPSBとRSB状態を削除します。
5. On D, there would be a remote signaling adjacency with B, and so D accepts the "Remote" PathTear and deletes the PSB and RSB states corresponding to the LSP.
5. Dでは、Bにはリモートシグナル伝達隣接があり、Dは「リモート」パステアを受け入れ、LSPに対応するPSBおよびRSB状態を削除します。
If local repair fails on the PLR after a failure, the PLR MUST send a "Remote" PathTear to the MP. The purpose of this is to clean up LSP state from the PLR to the egress. Upon receiving the PathTear, the MP MUST delete the states corresponding to the LSP and also propagate the PathTear downstream, thereby achieving state cleanup from all downstream nodes up to the LSP egress. Note that in the case of link protection, the PathTear MUST be directed to the LP-MP's Node-ID IP address rather than the NHOP interface address.
障害後にPLRでローカル修理が故障した場合、PLRはMPに「リモート」パステアを送信する必要があります。これの目的は、LSP状態をPLRから出口にクリーンアップすることです。PATHTEARを受信すると、MPはLSPに対応する状態を削除し、下流のPathtearを伝播する必要があります。リンク保護の場合、PATHTEARは、NHOPインターフェイスアドレスではなく、LP-MPのノードID IPアドレスに向けられる必要があることに注意してください。
When a PLR router that has already made NP available for an LSP detects a change in the RRO carried in the Resv message that indicates that the router's former NP-MP is no longer present on the path of the LSP, then the router MUST send a "Remote" PathTear directly to its former NP-MP.
既にLSPでNPを利用可能にしているPLRルーターが、ルーターの以前のNP-MPがLSPの経路に存在しなくなったことを示すRRROメッセージの変更を検出する場合、ルーターは「リモート」パスを前のNP-MPに直接送信する必要があります。
In the example topology in Figure 1, assume node A has made node protection available for an LSP and C has concluded it is the NP-MP for PLR A. When the B-C link fails, then C, implementing the procedure specified in Section 4.3.4 of this document, will retain the states corresponding to the LSP until one of the following occurs:
図1のトポロジの例では、ノードAがLSPでノード保護を利用可能にし、CがPLR AのNP-MPであると結論付けたと仮定します。B-Cリンクが失敗した場合、Cはこのドキュメントのセクション4.3.4で指定された手順を実装し、次のうちの1つが発生するまでLSPに対応する状態を保持します。
* the remote Node-ID signaling adjacency with A goes down or
* リモートノードIDの信号隣接がダウンします
* a PathTear or a ResvTear is received for its PSB or RSB, respectively.
* PATHTEARまたはRESVTEARは、それぞれPSBまたはRSBに対して受信されます。
If B also has made node protection available, B will eventually complete backup LSP signaling with its NP-MP D and trigger a Resv to A with RRO changed. The new RRO of the LSP carried in the Resv will not contain C. When A processes the Resv message with a new RRO not containing C, its former NP-MP, A, sends a "Remote" PathTear to C. When C receives the "Remote" PathTear for its PSB state, C will send a normal PathTear downstream to D and delete both the PSB and RSB states corresponding to the LSP. As D has already received backup LSP signaling from B, D will retain the control plane and forwarding states corresponding to the LSP.
Bがノード保護を利用可能にした場合、Bは最終的にNP-MP Dを使用してBackup LSPシグナリングを完了し、RROを変更してAをAにトリガーします。RESVで運ばれるLSPの新しいRROにはCが含まれません。CがCを含む新しいRROを使用してRESVメッセージをプロセスすると、以前のNP-MP A aがCに「リモート」パスを送信します。DがすでにBからバックアップLSPシグナル伝達を受けているため、DはLSPに対応するコントロールプレーンと転送状態を保持します。
If an LSP is preempted on an LP-MP after its PHOP link has already failed but the backup LSP has not been signaled yet as part of the local repair procedure, then the node MUST send a normal PathTear and delete both the PSB and RSB states corresponding to the LSP. As the LP-MP has retained the LSP state expecting the PLR to initiate backup LSP signaling, preemption would bring down the LSP and the node would not be LP-MP anymore, requiring the node to clean up the LSP state.
PHOPリンクがすでに失敗した後、LSPがLP-MPで先取りされているが、バックアップLSPはローカル修理手順の一部としてまだ信号を送られていない場合、ノードは通常のPATHTEARを送信し、LSPに対応するPSBとRSBの両方の状態を削除する必要があります。LP-MPは、PLRがバックアップLSPシグナリングを開始することを期待してLSP状態を保持しているため、PreemptionはLSPを削減し、ノードはLP-MPになり、LSP状態をクリーンアップするためのノードが必要になります。
If an LSP is preempted on an NP-MP after its PHOP link has already failed but the backup LSP has not been signaled yet, then the node MUST send a normal PathTear and delete the PSB and RSB states corresponding to the LSP. As the NP-MP has retained the LSP state expecting the PLR to initiate backup LSP signaling, preemption would bring down the LSP and the node would not be NP-MP anymore, requiring the node to clean up LSP state.
PHOPリンクが既に故障した後、LSPがNP-MPで先制されているが、バックアップLSPがまだシグナルを行っていない場合、ノードは通常のPATHTEARを送信し、LSPに対応するPSBおよびRSB状態を削除する必要があります。NP-MPは、PLRがバックアップLSPシグナリングを開始することを期待してLSP状態を保持しているため、PreemptionはLSPを削減し、ノードはNP-MPになり、LSP状態をクリーンアップするためにノードを要求します。
Consider that the B-C link goes down on the same example topology (Figure 1). As C is the NP-MP for the PLR A, C will retain the LSP state.
B-Cリンクは、同じ例トポロジーで下落することを考えてください（図1）。CはPLR AのNP-MPであるため、CはLSP状態を保持します。
1. The LSP is preempted on C.
1. LSPはCで先取りされています
2. C will delete the RSB state corresponding to the LSP. However, C cannot send a PathErr or a ResvTear to the PLR A because the backup LSP has not been signaled yet.
2. Cは、LSPに対応するRSB状態を削除します。ただし、バックアップLSPがまだ通知されていないため、cはpatherrまたはresvtearをPLR Aに送信することはできません。
3. As the only reason for C having retained state after PHOP node failure was that it was an NP-MP, C sends a normal PathTear to D and also deletes its PSB state. D would also delete the PSB and RSB states on receiving a PathTear from C.
3. PHOPノード障害後にCが状態を保持した唯一の理由は、それがNP-MPであるということであるため、Cは通常のパステアをDに送信し、PSB状態も削除します。Dは、CからPATHTEARを受信する際にPSBおよびRSB状態を削除します。
4. B starts backup LSP signaling to D. However, as D does not have the LSP state, it will reject the backup LSP Path message and send a PathErr to B.
4. BはDへのバックアップLSPシグナリングを開始します。ただし、DにはLSP状態がないため、バックアップLSPパスメッセージを拒否し、PatherrをBに送信します。
5. B will delete its reservation and send a ResvTear to A.
5. Bは予約を削除し、Aにresvtearを送信します
"Refresh-Interval Independent RSVP FRR" and "RI-RSVP-FRR" refer to the set of procedures defined in this document to eliminate the reliance on periodic refreshes. The extensions proposed in RSVP-TE Summary FRR [RFC8796] may apply to implementations that do not support RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state cleanup, namely Conditional and "Remote" PathTears, require support from one-hop and two-hop neighboring nodes along the LSP. Thus, procedures that fall under the LSP state cleanup category MUST NOT be turned on if any of the nodes involved in the node protection FRR (i.e., the PLR, the MP, and the intermediate node in the case of NP) do not support RI-RSVP-FRR extensions. Note that for LSPs requesting link protection, only the PLR and the LP-MP MUST support the extensions.
「リフレッシュインターヴァル独立RSVP FRR」および「RI-RSVP-FRR」は、定期的なリフレッシュへの依存を排除するために、このドキュメントで定義されている一連の手順を指します。RSVP-TEサマリFRR [RFC8796]で提案されている拡張機能は、RI-RSVP-FRRをサポートしていない実装に適用できます。一方、LSP状態のクリーンアップに関連するRI-RSVP-FRR拡張、つまり、条件付きおよび「リモート」パステアは、LSPに沿った1ホップおよび2ホップの隣接ノードからのサポートが必要です。したがって、LSP状態クリーンアップカテゴリに該当する手順は、ノード保護FRR（つまり、PLR、MP、およびNPの場合の中間ノード）に関与するノードのいずれかがRI-RSVP-FRR拡張ソをサポートしていない場合、オンにする必要はありません。LSPがリンク保護を要求する場合、PLRとLP-MPのみが拡張機能をサポートする必要があることに注意してください。
An implementation supporting RI-RSVP-FRR extensions MUST set the RI-RSVP Capable flag in the CAPABILITY object carried in Hello messages as specified in RSVP-TE Scaling Techniques [RFC8370]. If an implementation does not set the flag even if it supports RI-RSVP-FRR extensions, then its neighbors will view the node as any node that does not support the extensions.
RI-RSVP-FRR拡張機能をサポートする実装では、RSVP-TEスケーリング技術[RFC8370]で指定されているように、Helloメッセージに掲載された機能オブジェクトにRI-RSVP対応フラグを設定する必要があります。RI-RSVP-FRR拡張機能をサポートしていても、実装がフラグを設定しない場合、その近隣はノードを拡張機能をサポートしないノードと見なします。
* As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID-based signaling adjacency with all immediate neighbors, such a node on the path of a protected LSP can determine whether its PHOP and NHOP neighbors support RI-RSVP-FRR enhancements.
* RI-RSVP-FRR拡張機能をサポートするノードは、すべての直接傍とノードIDベースのシグナル伝達隣接を開始するため、保護されたLSPのパス上のノードは、PHOPおよびNHOPの近隣がRI-RSVP-FRR強化をサポートするかどうかを判断できます。
* As nodes supporting the RI-RSVP-FRR extensions also initiate Node-ID-based signaling adjacency with the NNHOP along the path of the LSP requesting node protection (see Section 4.2.1 of this document), each node along the LSP can determine whether its NNHOP node supports RI-RSVP-FRR enhancements. If the NNHOP (a) does not reply to remote Node-ID Hello messages or (b) does not set the RI-RSVP flag in the CAPABILITY object carried in its Node-ID Hello messages, then the node acting as the PLR can conclude that NNHOP does not support RI-RSVP-FRR extensions.
* RI-RSVP-FRR拡張機能をサポートするノードは、LSPのパスに沿ったNNHOPとのノードIDベースのシグナル伝達を開始するため、LSPに沿った各ノードがNNHOPノードがRI-RSVP-FRR強化をサポートするかどうかを判断できます。NNHOP（a）がリモートノードIDハローメッセージに返信しない場合、または（b）がノードIDハローメッセージに掲載された機能オブジェクトにRI-RSVPフラグを設定しない場合、PLRとして作用するノードは、NNHOPがRI-RSVP-FRR拡張機能をサポートしていないと結論付けることができます。
* If node protection is requested for an LSP and if (a) the PPHOP node has not included a matching B-SFRR-Ready Extended ASSOCIATION object in its Path messages, (b) the PPHOP node has not initiated remote Node-ID Hello messages, or (c) the PPHOP node does not set the RI-RSVP flag in the CAPABILITY object carried in its Node-ID Hello messages, then the node MUST conclude that the PLR does not support RI-RSVP-FRR extensions.
* LSPに対してノード保護が要求され、（a）PPHOPノードにそのパスメッセージに一致するB-SFRR対応拡張アソシエーションオブジェクトが含まれていない場合、（b）PPHOPノードがリモートノードIDハローメッセージを開始していない場合、または（c）PPHOPノードは、Node hillo Carriedのcapablabilityオブジェクトにri-rsvpフラグを設定していない場合、pphopノードはri-rsvpフラグを設定していません。RI-RSVP-FRR拡張機能。
Every node that supports RI-RSVP-FRR MUST support the procedures defined in this section in order to support backward compatibility for those subsets of LSPs that also traverse nodes that do not support RI-RSVP-FRR.
RI-RSVP-FRRをサポートするすべてのノードは、RI-RSVP-FRRをサポートしていないLSPのサブセットの後方互換性をサポートするために、このセクションで定義されている手順をサポートする必要があります。
The procedures on the downstream direction are as follows:
下流の方向の手順は次のとおりです。
* If a node finds that the NHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval.
* ノードがLSPに沿ったNHOPノードがRI-RSVP-FRR拡張機能をサポートしていないことを発見した場合、ノードはパスメッセージに配信されたtime_valuesオブジェクトの「更新期間」をデフォルトの短い更新インターバルに減らす必要があります。
* If node protection is requested for the LSP and the NNHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval.
* LSPにノード保護が要求され、LSPに沿ったNNHOPノードがRI-RSVP-FRR拡張機能をサポートしていない場合、ノードはパスメッセージに配信されたtime_valuesオブジェクトの「更新期間」をデフォルトの短い更新間隔まで減らす必要があります。
If a node reduces the refresh time using the above procedures, it MUST NOT send any "Remote" PathTear or Conditional PathTear message to the downstream node.
上記の手順を使用してノードが更新時間を短縮した場合、「リモート」パステアまたは条件付きPathTearメッセージをダウンストリームノードに送信してはなりません。
Consider the example topology in Figure 1. If C does not support the RI-RSVP-FRR extensions, then:
図1のトポロジの例を考えてみましょう。CがRI-RSVP-FRR拡張機能をサポートしていない場合、次のとおりです。
* A and B reduce the refresh time to the default short refresh interval of 30 seconds and trigger a Path message.
* AとBは、更新時間を30秒のデフォルトの短い更新間隔まで短縮し、パスメッセージをトリガーします。
* If B is not an MP and if the PHOP link of B fails, B cannot send a Conditional PathTear to C but times out the PSB state from A normally. Note that B can only normally time out the PSB state A if A did not set the long refresh in the TIME_VALUES object carried in the Path messages sent earlier.
* BがMPではない場合、BのPHOPリンクが失敗した場合、Bは条件付きパステアをCに送信できませんが、通常からPSB状態を除外します。bは、以前に送信されたパスメッセージに掲載されたtime_valuesオブジェクトに長い更新を設定しなかった場合にのみ、PSB状態Aをタイムアウトできることに注意してください。
The procedures on the upstream direction are as follows:
上流の方向の手順は次のとおりです。
* If a node finds that the PHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Resv messages to the default short refresh interval.
* ノードがLSPに沿ったPHOPノードがRI-RSVP-FRR拡張機能をサポートしていないことを発見した場合、ノードは、RESVメッセージに掲載されたTIME_VALUESオブジェクトの「更新期間」をデフォルトの短い更新インターバルに減らす必要があります。
* If node protection is requested for the LSP and the PHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval (thus, the NHOP can use compatible values when sending a Resv).
* LSPにノード保護が要求され、LSPに沿ったPHOPノードがRI-RSVP-FRR拡張機能をサポートしていない場合、ノードはパスメッセージに掲載されたTIME_VALUESオブジェクトの「更新期間」をデフォルトの短い更新間隔に減らす必要があります（したがって、NHOPはRESVを送信するときに互換値を使用できます）。
* If node protection is requested for the LSP and the PPHOP node does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Resv messages to the default short refresh interval.
* LSPに対してノード保護が要求され、PPHOPノードがRI-RSVP-FRR拡張機能をサポートしていない場合、ノードは、RESVメッセージに掲載されたTIME_VALUESオブジェクトの「更新期間」をデフォルトの短い更新間隔に減らす必要があります。
* If the node reduces the refresh time using the above procedures, it MUST NOT execute MP procedures specified in Section 4.3 of this document.
* 上記の手順を使用してノードが更新時間を短縮する場合、このドキュメントのセクション4.3で指定されたMP手順を実行してはなりません。
The backward compatibility procedures described in the previous subsections imply that a router supporting the RI-RSVP-FRR extensions specified in this document can apply the procedures specified in this document either in the downstream or upstream direction of an LSP, depending on the capability of the routers downstream or upstream in the LSP.
以前のサブセクションで説明されている後方互換性の手順は、このドキュメントで指定されたRI-RSVP-FRR拡張機能をサポートするルーターが、LSPの下流または上流のルーターの機能に応じて、LSPの下流または上流の方向で指定された手順を適用できることを意味します。
* RI-RSVP-FRR extensions and procedures are enabled for downstream Path, PathTear, and ResvErr messages corresponding to an LSP if link protection is requested for the LSP and the NHOP node supports the extensions.
* LSPにリンク保護が要求され、NHOPノードが拡張機能をサポートする場合、RI-RSVP-FRR拡張機能と手順は、LSPに対応する下流パス、PATHTEAR、およびRESVERRメッセージに対して有効になります。
* RI-RSVP-FRR extensions and procedures are enabled for downstream Path, PathTear, and ResvErr messages corresponding to an LSP if node protection is requested for the LSP and both NHOP and NNHOP nodes support the extensions.
* LSPにノード保護が要求され、NHOPとNNHOPノードの両方が拡張機能をサポートする場合、RI-RSVP-FRR拡張および手順は、LSPに対応する下流パス、PATHTEAR、およびRESVERRメッセージに対して有効になります。
* RI-RSVP-FRR extensions and procedures are enabled for upstream PathErr, Resv, and ResvTear messages corresponding to an LSP if link protection is requested for the LSP and the PHOP node supports the extensions.
* RI-RSVP-FRR拡張機能と手順は、LSPにリンク保護が要求され、PHOPノードが拡張をサポートする場合、LSPに対応する上流のPatherr、RESV、およびRESVTEARメッセージに対して有効になります。
* RI-RSVP-FRR extensions and procedures are enabled for upstream PathErr, Resv, and ResvTear messages corresponding to an LSP if node protection is requested for the LSP and both PHOP and PPHOP nodes support the extensions.
* RI-RSVP-FRR拡張機能と手順は、LSPにノード保護が要求され、PHOPノードとPPHOPノードの両方が拡張をサポートする場合、LSPに対応する上流のPatherr、RESV、およびRESVTEARメッセージに対して有効になります。
For example, if an implementation supporting the RI-RSVP-FRR extensions specified in this document is deployed on all routers in a particular region of the network and if all the LSPs in the network request node protection, then the FRR extensions will only be applied for the LSP segments that traverse the particular region. This will aid incremental deployment of these extensions and also allow reaping the benefits of the extensions in portions of the network where it is supported.
たとえば、このドキュメントで指定されているRI-RSVP-FRR拡張機能をサポートする実装がネットワークの特定の領域のすべてのルーターに展開され、ネットワークリクエストノード保護のすべてのLSPが特定の領域を追跡するLSPセクションにのみ適用されます。これにより、これらの拡張機能の増分展開が役立ち、サポートされているネットワークの一部の拡張機能の利点を享受できます。
If a node supporting facility backup protection [RFC4090] sets the RI-RSVP capability (I-bit) but does not support the RI-RSVP-FRR extensions, due to an implementation bug or configuration error, then it leaves room for the stale state to linger around for an inordinate period of time or for disruption of normal FRR operations (see Section 3 of this document). Consider the example topology (Figure 1) provided in this document.
ノードサポート施設のバックアップ保護[RFC4090]がRI-RSVP機能（I-BIT）を設定するが、実装バグまたは構成エラーのためにRI-RSVP-FRR拡張をサポートしていない場合、古代状態が存在する期間のために長期にわたって存在する余地を残します。このドキュメントで提供されているトポロジの例（図1）を考えてください。
* Assume node B does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. When B detects the failure of its PHOP link along an LSP, it will not send a Conditional PathTear to C as required by the RI-RSVP-FRR procedures. If B simply leaves the LSP state without deleting, then B may end up holding on to the stale state until the (long) refresh timeout.
* Node BがRI-RSVP-FRR拡張機能をサポートしていない場合でも、ノードIDベースのハローメッセージにRI-RSVP機能を設定すると仮定します。BがLSPに沿ったPHOPリンクの障害を検出すると、RI-RSVP-FRR手順で義務付けられているように条件付きPathTearをCに送信しません。Bが単に削除せずにLSP状態を離れるだけで、Bは（長い）更新タイムアウトまで古い状態を保持することになります。
* Instead of node B, assume node C does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. When B details the failure of its PHOP link along an LSP, it will send a Conditional PathTear to C as required by the RI-RSVP-FRR procedures. However, C would not recognize the condition encoded in the PathTear and end up tearing down the LSP.
* ノードBの代わりに、Node CがRI-RSVP-FRR拡張機能をサポートしていない場合でも、ノードIDベースのハローメッセージにRI-RSVP機能を設定すると仮定します。bがLSPに沿ったPHOPリンクの障害を詳述すると、RI-RSVP-FRR手順で要求されているように条件付きPathTearがCに送信されます。ただし、CはPathTearでエンコードされた条件を認識しず、LSPを引き裂くことになります。
* Assume node B does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. In addition, assume local repair is about to commence on node B for an LSP that has only requested link protection, that is, B has not initiated the backup LSP signaling for the LSP. If node B receives a normal PathTear at this time from ingress A because of a management event initiated on A, then B simply deletes the LSP state without sending a Remote PathTear to the LP-MP C, so C may end up holding on to the stale state until the (long) refresh timeout.
* Node BがRI-RSVP-FRR拡張機能をサポートしていない場合でも、ノードIDベースのハローメッセージにRI-RSVP機能を設定すると仮定します。さらに、リンク保護のみを要求したLSPのノードBでローカル修理が開始されていると仮定します。つまり、BはLSPのバックアップLSPシグナリングを開始していません。Node BがAで開始された管理イベントのためにIngress Aからこの時点で通常のPathTearを受信した場合、BはLP-MP Cにリモートパスのtearを送信せずにLSP状態を削除するだけで、Cは（長い）更新タイムアウトまで古い状態を保持することになります。
The security considerations pertaining to the original RSVP protocol ([RFC2205], [RFC3209], and [RFC5920]) remain relevant. When using RSVP cryptographic authentication [RFC2747], more robust algorithms such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104] [FIPS-180-4] SHOULD be used when computing the keyed message digest where possible.
元のRSVPプロトコル（[RFC2205]、[RFC3209]、および[RFC5920]）に関連するセキュリティ上の考慮事項は、引き続き関連しています。RSVP暗号化認証[RFC2747]を使用する場合、Keyedメッセージが可能な場合に発見されたキー付きメッセージを計算するときに、HMAC-Sha256、HMAC-Sha384、またはHMAC-Sha512 [RFC2104] [FIPS-180-4]などのより堅牢なアルゴリズムを使用する場合。
This document extends the applicability of Node-ID-based Hello sessions between immediate neighbors. The Node-ID-based Hello session between the PLR and the NP-MP may require the two routers to exchange Hello messages with a non-immediate neighbor. Therefore, the implementations SHOULD provide the option to configure either a specific neighbor or global Node-ID authentication key to authentication messages received from Node-ID neighbors. The network administrator SHOULD utilize this option to enable RSVP-TE routers to authenticate Node-ID Hello messages received with a TTL greater than 1. Implementations SHOULD also provide the option to specify a limit on the number of Node-ID-based Hello sessions that can be established on a router supporting the extensions defined in this document.
このドキュメントは、Node-IDベースのハローセッションの即時隣人間の適用性を拡張します。PLRとNP-MPの間のノードIDベースのハローセッションでは、2つのルーターが非Immediateネイバーとハローメッセージを交換する必要があります。したがって、実装は、Node-ID Neighborsから受信した認証メッセージに対して、特定のネイバーまたはグローバルNode-ID認証キーを構成するオプションを提供する必要があります。ネットワーク管理者は、このオプションを利用して、RSVP-TEルーターに1を超えるTTLで受信したノードIDハローメッセージを認証できるようにする必要があります。実装は、このドキュメントで定義されているエクステンションをサポートするルーターで確立できるノードIDベースのハローセッションの数の制限を指定するオプションも提供する必要があります。
IANA maintains the "Class Names, Class Numbers, and Class Types" registry in the "RSVP Parameters" registry group (see <http://www.iana.org/assignments/rsvp-parameters/>). IANA has extended these registries by adding a new Class Number (in the 10bbbbbb range) and assigning a new C-Type under this Class Number, as described below (see Section 4.4.3). New Class Type values for Class Name "CONDITIONS" can be added via "IETF Review" [RFC8126].
IANAは、「クラス名、クラス番号、クラスタイプ」レジストリ「RSVPパラメーター」レジストリグループのレジストリを維持しています（<http://www.iana.org/assignments/rsvp-parameters/>を参照）。IANAは、以下に説明するように（セクション4.4.3を参照）、新しいクラス番号（10BBBBB範囲）を追加し、このクラス番号の下に新しいCタイプを割り当てることにより、これらのレジストリを拡張しました。クラス名「条件」の新しいクラスタイプの値は、「IETFレビュー」[RFC8126]を介して追加できます。
+==============+============+===========+
| Class Number | Class Name | Reference |
+==============+============+===========+
| 135 | CONDITIONS | RFC 9705 |
+--------------+------------+-----------+
Table 1: Class Names, Class Numbers, and Class Types
表1：クラス名、クラス番号、クラスの種類
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 1 | CONDITIONS | RFC 9705 |
+-------+-------------+-----------+
Table 2: Class Types or C-Types - 135 CONDITIONS
表2：クラスの種類またはCタイプ-135条件
IANA has added a subregistry called "CONDITIONS Object Flags" as shown below. New registrations can be added via "IETF Review" [RFC8126].
IANAは、以下に示すように、「条件オブジェクトフラグ」と呼ばれるサブレジストリを追加しました。新しい登録は、「IETFレビュー」[RFC8126]を介して追加できます。
+============+==============+=============+===========+
| Bit Number | 32-Bit Value | Name | Reference |
+============+==============+=============+===========+
| 0-30 | | Unassigned | |
+------------+--------------+-------------+-----------+
| 31 | 0x0001 | Merge-point | RFC 9705 |
+------------+--------------+-------------+-----------+
Table 3: CONDITIONS Object Flags
表3：オブジェクトフラグの条件
[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>.
[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>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <https://www.rfc-editor.org/info/rfc2747>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<https://www.rfc-editor.org/info/rfc2961>.
[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>.
[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>.
[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>.
[RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou,
"Node-ID Based Resource Reservation Protocol (RSVP) Hello:
A Clarification Statement", RFC 4558,
DOI 10.17487/RFC4558, June 2006,
<https://www.rfc-editor.org/info/rfc4558>.
[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
GMPLS Resource Reservation Protocol (RSVP) Graceful
Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
<https://www.rfc-editor.org/info/rfc5063>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
T. Saad, "Techniques to Improve the Scalability of RSVP-TE
Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,
<https://www.rfc-editor.org/info/rfc8370>.
[RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A.,
Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute
Extensions for Label Switched Path (LSP) Tunnels",
RFC 8796, DOI 10.17487/RFC8796, July 2020,
<https://www.rfc-editor.org/info/rfc8796>.
[FIPS-180-4]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[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>.
We are very grateful to Yakov Rekhter for his contributions to the development of the idea and thorough review of the content of the document. We are thankful to Raveendra Torvi and Yimin Shen for their comments and inputs on early versions of the document. We also thank Alexander Okonnikov for his review and comments on the document.
Yakov Rekhterが、アイデアの開発への貢献と、文書の内容の徹底的なレビューに非常に感謝しています。ドキュメントの初期バージョンに関するコメントとインプットについて、Raveendra TorviとYimin Shenに感謝しています。また、Alexander Okonnikovのレビューと文書に関するコメントに感謝します。
Ina Minei
Google, Inc.
Email: inaminei@google.com
Markus Jork
Juniper Networks, Inc.
Email: mjork@juniper.net
Harish Sitaraman
Individual Contributor
Email: harish.ietf@gmail.com
Vishnu Pavan Beeram
Juniper Networks, Inc.
Email: vbeeram@juniper.net
Ebben Aries
Juniper Networks, Inc.
Email: exa@juniper.com
Mike Taillon
Cisco Systems, Inc.
Email: mtaillon@cisco.com
Chandra Ramachandran
Juniper Networks, Inc.
Email: csekar@juniper.net
Tarek Saad
Cisco Systems, Inc.
Email: tsaad@cisco.com
Dante Pacella
Verizon, Inc.
Email: dante.j.pacella@verizon.com