[要約] 要約：RFC 8370は、RSVP-TE（Resource Reservation Protocol - Traffic Engineering）展開の拡張性を向上させるための技術について説明しています。 目的：このRFCの目的は、RSVP-TEの展開におけるスケーラビリティの問題を解決するための具体的な手法を提供することです。
Internet Engineering Task Force (IETF) V. Beeram, Ed.
Request for Comments: 8370 Juniper Networks
Category: Standards Track I. Minei
ISSN: 2070-1721 R. Shakir
Google, Inc
D. Pacella
Verizon
T. Saad
Cisco Systems
May 2018
Techniques to Improve the Scalability of RSVP-TE Deployments
RSVP-TE展開のスケーラビリティを改善する手法
Abstract
概要
Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.
RSVP-TE LSPを利用するネットワークは、展開されたLSPの数の増加をサポートする能力が制限された実装に遭遇しています。
This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.
このドキュメントでは、Refresh-Interval Independent RSVP（RI-RSVP）とPer-Peer Flow Controlの2つの手法を定義し、ラベルスイッチングルーター（LSR）でRSVP-TE LSP状態を維持するために必要な処理サイクル数を減らし、実装を可能にします。大規模な展開をサポートします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8370.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8370で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Required Support for RFC 2961 . . . . . . . . . . . . . . . . 4
2.1. Required Functionality from RFC 2961 . . . . . . . . . . 4
2.2. Making Acknowledgements Mandatory . . . . . . . . . . . . 4
3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5
3.1. Capability Advertisement . . . . . . . . . . . . . . . . 6
3.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 6
4. Per-Peer Flow Control . . . . . . . . . . . . . . . . . . . . 6
4.1. Capability Advertisement . . . . . . . . . . . . . . . . 7
4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Capability Object Values . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Networks that utilize RSVP-TE [RFC3209] LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.
RSVP-TE [RFC3209] LSPを利用するネットワークは、展開されているLSPの数の増加をサポートする機能が制限されている実装に遭遇しています。
The set of RSVP Refresh Overhead Reduction procedures [RFC2961] serves as a powerful toolkit for RSVP-TE implementations to help cover a majority of the concerns about soft-state scaling. However, even with these tools in the toolkit, analysis of existing implementations [RFC5439] indicates that the processing required beyond a certain scale may still cause significant disruption to a Label Switching Router (LSR).
RSVPリフレッシュオーバーヘッド削減手順のセット[RFC2961]は、RSVP-TE実装の強力なツールキットとして機能し、ソフト状態のスケーリングに関する懸念の大部分をカバーします。ただし、これらのツールがツールキットに含まれている場合でも、既存の実装の分析[RFC5439]は、特定の規模を超えて必要な処理が、ラベルスイッチングルーター（LSR）に重大な混乱を引き起こす可能性があることを示しています。
This document builds on existing scaling work and analysis and defines protocol extensions to help RSVP-TE deployments push the envelope further on scaling by increasing the threshold above which an LSR struggles to achieve sufficient processing to maintain LSP state.
このドキュメントは、既存のスケーリング作業と分析に基づいてプロトコル拡張を定義し、LSP状態を維持するのに十分な処理を実現するためにLSRが苦労するしきい値を増やすことにより、RSVP-TE展開がスケーリングの限界を押し上げるのを支援します。
This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that cut down the number of processing cycles required to maintain LSP state. RI-RSVP helps completely eliminate RSVP's reliance on refreshes and refresh timeouts, while Per-Peer Flow Control enables a busy RSVP speaker to apply back pressure to its peer(s). This document defines a unique RSVP Capability [RFC5063] for each technique (support for the CAPABILITY object is a prerequisite for implementing these techniques). Note that the Per-Peer Flow-Control technique requires the RI-RSVP technique as a prerequisite. In order to reap maximum scaling benefits, it is strongly recommended that implementations support both techniques and have them enabled by default. Both techniques are fully backward compatible and can be deployed incrementally.
このドキュメントでは、LSP状態を維持するために必要な処理サイクル数を削減する、リフレッシュ間隔に依存しないRSVP（RI-RSVP）とピアごとのフロー制御の2つの手法を定義します。ピアごとのフロー制御により、ビジーなRSVPスピーカーがピアにバックプレッシャーをかけることができる一方で、RI-RSVPは、リフレッシュとリフレッシュタイムアウトへのRSVPの依存を完全に排除するのに役立ちます。このドキュメントでは、各手法に固有のRSVP機能[RFC5063]を定義しています（CAPABILITYオブジェクトのサポートは、これらの手法を実装するための前提条件です）。ピアごとのフロー制御手法では、前提条件としてRI-RSVP手法が必要です。スケーリングのメリットを最大限に引き出すには、実装で両方の手法をサポートし、デフォルトで有効にすることを強くお勧めします。どちらの手法にも完全な下位互換性があり、段階的に導入できます。
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 techniques defined in Sections 3 and 4 are based on proposals made in [RFC2961]. Implementations of these techniques need to support the RSVP messages and procedures defined in [RFC2961] with some minor modifications and alterations to recommended time intervals and iteration counts (see Appendix A for the set of recommended defaults).
セクション3と4で定義された技術は、[RFC2961]で行われた提案に基づいています。これらの手法の実装は、[RFC2961]で定義されているRSVPメッセージと手順をサポートする必要があり、推奨される時間間隔と反復回数に若干の変更と変更を加えます（推奨されるデフォルトのセットについては、付録Aを参照してください）。
An implementation that supports the techniques discussed in Sections 3 and 4 must support the functionality described in [RFC2961] as follows:
セクション3と4で説明されている手法をサポートする実装は、[RFC2961]で説明されている機能を次のようにサポートする必要があります。
o It MUST indicate support for RSVP Refresh Overhead Reduction extensions (as specified in Section 2 of [RFC2961]).
o （[RFC2961]のセクション2で指定されている）RSVPリフレッシュオーバーヘッド削減拡張機能のサポートを示す必要があります。
o It MUST support receipt of any RSVP Refresh Overhead Reduction message as defined in [RFC2961].
o [RFC2961]で定義されているRSVPリフレッシュオーバーヘッド削減メッセージの受信をサポートする必要があります。
o It MUST initiate all RSVP Refresh Overhead Reduction mechanisms as defined in [RFC2961] (including the SRefresh message) with the default behavior being to initiate the mechanisms; however, a configuration override should be offered.
o [RFC2961]で定義されているすべてのRSVPリフレッシュオーバーヘッド削減メカニズム（SRefreshメッセージを含む）を開始する必要があります。デフォルトの動作はメカニズムを開始することです。ただし、構成のオーバーライドを提供する必要があります。
o It MUST support reliable delivery of Path/Resv and the corresponding Tear/Err messages (as specified in Section 4 of [RFC2961]).
o Path / Resvおよび対応するTear / Errメッセージの信頼できる配信をサポートする必要があります（[RFC2961]のセクション4で指定）。
o It MUST support retransmission of all unacknowledged RSVP-TE messages using exponential backoff (as specified in Section 6 of [RFC2961]).
o 指数バックオフを使用して、すべての未確認のRSVP-TEメッセージの再送信をサポートする必要があります（[RFC2961]のセクション6で指定）。
The reliable message delivery mechanism specified in [RFC2961] states that "Nodes receiving a non-out of order [sic] message containing a MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with a MESSAGE_ID_ACK object."
[RFC2961]で指定されている信頼性の高いメッセージ配信メカニズムでは、「ACK_Desiredフラグが設定されたMESSAGE_IDオブジェクトを含む非順序[sic]メッセージを受信するノードは、MESSAGE_ID_ACKオブジェクトで応答する必要があります。」
In an implementation that supports the techniques discussed in Sections 3 and 4, nodes receiving a non-out-of-order message containing a MESSAGE_ID object with the ACK_Desired flag set MUST respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can be packed with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects and sent in an Ack message (or piggybacked in any other RSVP message).
セクション3と4で説明した手法をサポートする実装では、ACK_Desiredフラグが設定されたMESSAGE_IDオブジェクトを含む非順序メッセージを受信するノードは、MESSAGE_ID_ACKオブジェクトで応答する必要があります。このMESSAGE_ID_ACKオブジェクトは、他のMESSAGE_ID_ACKまたはMESSAGE_ID_NACKオブジェクトとパックして、Ackメッセージで送信できます（または他のRSVPメッセージで便乗できます）。
This improvement to the predictability of the system in terms of reliable message delivery is key for being able to take any action based on a non-receipt of an ACK.
信頼性の高いメッセージ配信に関するシステムの予測可能性に対するこの改善は、ACKの非受信に基づいてアクションを実行できるようにするための鍵です。
The RSVP protocol relies on periodic refreshes for state synchronization between RSVP neighbors and recovery from lost RSVP messages. It relies on a refresh timeout for stale-state cleanup. The primary motivation behind introducing the notion of Refresh-Interval Independent RSVP (RI-RSVP) is to completely eliminate RSVP's reliance on refreshes and refresh timeouts. This is done by simply increasing the refresh interval to a fairly large value. [RFC2961] and [RFC5439] talk about increasing the value of the refresh interval to provide linear improvement of transmission overhead, but they also point out the degree of functionality that is lost by doing so. This section revisits this notion, but also sets out additional requirements to make sure that there is no loss of functionality incurred by increasing the value of the refresh interval.
RSVPプロトコルは、RSVPネイバー間の状態同期と失われたRSVPメッセージからの回復のために定期的なリフレッシュに依存しています。古い状態のクリーンアップは、更新タイムアウトに依存します。リフレッシュ間隔非依存RSVP（RI-RSVP）の概念を導入する主な動機は、RSVPのリフレッシュおよびリフレッシュタイムアウトへの依存を完全に排除することです。これは、リフレッシュ間隔をかなり大きな値に増やすだけで実行されます。 [RFC2961]と[RFC5439]は、送信オーバーヘッドの線形改善を提供するためにリフレッシュ間隔の値を増やすことについて話していますが、そうすることによって失われる機能の程度も指摘しています。このセクションでは、この概念を再検討しますが、更新間隔の値を増やしても機能が失われないようにするための追加要件を示します。
An implementation that supports RI-RSVP:
RI-RSVPをサポートする実装：
o MUST support all of the requirements specified in Section 2.
o セクション2で指定されたすべての要件をサポートする必要があります。
o MUST make the default value of the configurable refresh interval (R) be a large value (tens of minutes). A default value of 20 minutes is RECOMMENDED by this document.
o 構成可能なリフレッシュ間隔（R）のデフォルト値を大きな値（数十分）にする必要があります。このドキュメントでは、デフォルト値の20分が推奨されています。
o MUST use a separate shorter refresh interval for refreshing state associated with unacknowledged Path/Resv (uR) messages. A default value of 30 seconds is RECOMMENDED by this document.
o 確認応答されていないPath / Resv（uR）メッセージに関連付けられた状態の更新には、別の短い更新間隔を使用する必要があります。このドキュメントでは、デフォルト値の30秒が推奨されています。
o MUST implement coupling the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. When an RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the speaker MUST act as if all the Path and Resv states learned via the failed signaling adjacency have timed out.
o 個々のLSPの状態と、対応するRSVP-TEシグナリング隣接の状態との結合を実装する必要があります。 RSVP-TEスピーカーがRSVP-TEシグナリング隣接の失敗を検出すると、スピーカーは、失敗したシグナリング隣接を介して学習されたすべてのPathおよびResv状態がタイムアウトしたかのように動作する必要があります。
o MUST make use of the Hello session based on the Node-ID ([RFC3209] [RFC4558]) for detection of RSVP-TE signaling adjacency failures. A default value of 9 seconds is RECOMMENDED by this document for the configurable node hello interval (as opposed to the default value of 5 milliseconds proposed in Section 5.3 of [RFC3209]).
o RSVP-TEシグナリング隣接障害の検出には、Node-ID（[RFC3209] [RFC4558]）に基づくHelloセッションを使用する必要があります。このドキュメントでは、構成可能なノードのhello間隔について、デフォルト値の9秒が推奨されています（[RFC3209]のセクション5.3で提案されているデフォルト値の5ミリ秒とは異なります）。
o MUST indicate support for RI-RSVP via the CAPABILITY object [RFC5063] in Hello messages.
o HelloメッセージのCAPABILITYオブジェクト[RFC5063]を介してRI-RSVPのサポートを示す必要があります。
An implementation supporting the RI-RSVP technique MUST set a new flag, RI-RSVP Capable, in the CAPABILITY object signaled in Hello messages. The following bit indicates that the sender supports RI-RSVP:
RI-RSVP技術をサポートする実装は、Helloメッセージで通知されるCAPABILITYオブジェクトに新しいフラグRI-RSVP Capableを設定しなければなりません（MUST）。次のビットは、送信者がRI-RSVPをサポートしていることを示しています。
Bit Number 28 (0x0008) - RI-RSVP Capable (I-bit)
ビット番号28（0x0008）-RI-RSVP対応（Iビット）
Any node that sets the new I-bit in its CAPABILITY object MUST also set the Refresh-Reduction-Capable bit [RFC2961] in the common header of all RSVP-TE messages. If a peer sets the I-bit in the CAPABILITY object but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP functionality MUST NOT be activated for that peer.
CAPABILITYオブジェクトで新しいIビットを設定するノードは、すべてのRSVP-TEメッセージの共通ヘッダーでRefresh-Reduction-Capableビット[RFC2961]も設定する必要があります。ピアがCAPABILITYオブジェクトにIビットを設定しているが、Refresh-Reduction-Capableビットを設定していない場合、そのピアに対してRI-RSVP機能をアクティブにしてはなりません（MUST NOT）。
The RI-RSVP functionality MUST NOT be activated with a peer that does not indicate support for this functionality. Inactivation of the RI-RSVP functionality MUST result in the use of the traditional smaller refresh interval [RFC2205].
RI-RSVP機能は、この機能のサポートを示さないピアでアクティブにしてはなりません（MUST NOT）。 RI-RSVP機能の非アクティブ化は、従来のより小さいリフレッシュ間隔[RFC2205]の使用をもたらす必要があります。
The functionality discussed in this section provides an RSVP speaker with the ability to apply back pressure to its peer(s) to reduce/ eliminate a significant portion of the RSVP-TE control message load.
このセクションで説明する機能は、RSVPスピーカーにピアにバックプレッシャーを適用して、RSVP-TE制御メッセージの負荷のかなりの部分を削減/排除する機能を提供します。
An implementation that supports Per-Peer Flow Control:
ピアごとのフロー制御をサポートする実装：
o MUST support all of the requirements specified in Section 2.
o セクション2で指定されたすべての要件をサポートする必要があります。
o MUST support RI-RSVP (Section 3).
o RI-RSVPをサポートする必要があります（セクション3）。
o MUST treat lack of ACKs from a peer as an indication of a peer's RSVP-TE control-plane congestion. If congestion is detected, the local system MUST throttle RSVP-TE messages to the affected peer. This MUST be done on a per-peer basis. (Per-peer throttling MAY be implemented by a traffic-shaping mechanism that proportionally reduces the RSVP-signaling packet rate as the number of outstanding ACKs increases. When the number of outstanding ACKs decreases, the send rate would be adjusted up again.)
o ピアからのACKの欠如を、ピアのRSVP-TEコントロールプレーンの輻輳の指標として扱う必要があります。輻輳が検出された場合、ローカルシステムは、影響を受けるピアへのRSVP-TEメッセージをスロットルする必要があります。これはピアごとに行う必要があります。 （ピアごとのスロットリングは、未処理のACKの数が増えると、それに比例してRSVPシグナリングパケットレートを下げるトラフィックシェーピングメカニズムによって実装される場合があります。未処理のACKの数が減ると、送信レートが再び調整されます。）
o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of [RFC2961] suggests using 3).
o 7の再試行制限（Rl）値を使用する必要があります（[RFC2961]のセクション6.2は3の使用を推奨しています）。
o SHOULD prioritize Hello messages and messages carrying Acknowledgements over other RSVP messages.
o Helloメッセージと確認応答を運ぶメッセージを他のRSVPメッセージよりも優先する必要があります。
o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that bring up new LSP state) sent to a peer when the local system detects RSVP-TE control-plane congestion in the peer.
o ローカルシステムがピアでRSVP-TEコントロールプレーンの輻輳を検出したときに、ピアに送信されるトリガーパス/ Resv（新しいLSP状態を引き起こすメッセージ）よりもティア/エラーを優先する必要があります（SHOULD）。
o MUST indicate support for this technique via the CAPABILITY object [RFC5063] in Hello messages.
o HelloメッセージのCAPABILITYオブジェクト[RFC5063]を介して、この手法のサポートを示す必要があります。
An implementation supporting the Per-Peer Flow-Control technique MUST set a new flag, Per-Peer Flow-Control Capable, in the CAPABILITY object signaled in Hello messages. The following bit indicates that the sender supports Per-Peer Flow Control:
ピアごとのフロー制御技術をサポートする実装は、Helloメッセージで通知されるCAPABILITYオブジェクトに新しいフラグであるピアごとのフロー制御機能を設定する必要があります。次のビットは、送信側がピアごとのフロー制御をサポートしていることを示しています。
Bit Number 27 (0x0010) - Per-Peer Flow-Control Capable (F-bit)
ビット番号27（0x0010）-ピアごとのフロー制御が可能（Fビット）
Any node that sets the new F-bit in its CAPABILITY object MUST also set the Refresh-Reduction-Capable bit in the common header of all RSVP-TE messages. If a peer sets the F-bit in the CAPABILITY object but does not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow-Control functionality MUST NOT be activated for that peer.
CAPABILITYオブジェクトで新しいFビットを設定するノードは、すべてのRSVP-TEメッセージの共通ヘッダーでRefresh-Reduction-Capableビットも設定する必要があります。ピアがCAPABILITYオブジェクトにFビットを設定しているが、Refresh-Reduction-Capableビットを設定していない場合、ピアごとのフロー制御機能をそのピアに対してアクティブにしてはなりません（MUST NOT）。
The Per-Peer Flow-Control functionality MUST NOT be activated with a peer that does not indicate support for this functionality. If a peer hasn't indicated that it is capable of participating in Per-Peer Flow Control, then it SHOULD NOT be assumed that the peer would always acknowledge a non-out-of-order message containing a MESSAGE_ID object with the ACK_Desired flag set.
ピアごとのフロー制御機能は、この機能のサポートを示さないピアでアクティブにしてはなりません。ピアがピアごとのフロー制御に参加できることをピアが示していない場合は、ピアが常に、ACK_Desiredフラグが設定されたMESSAGE_IDオブジェクトを含む順不同メッセージを確認すると想定してはなりません（SHOULD NOT） 。
IANA maintains the "Capability Object values" subregistry [RFC5063] within the "Resource Reservation Protocol (RSVP) Parameters" registry <http://www.iana.org/assignments/rsvp-parameters>. IANA has assigned two new Capability Object Value bit flags as follows:
IANAは、「Resource Reservation Protocol（RSVP）Parameters」レジストリ<http://www.iana.org/assignments/rsvp-parameters>内に「Capability Object values」サブレジストリ[RFC5063]を保持しています。 IANAは、次のように2つの新しい機能オブジェクト値ビットフラグを割り当てました。
Bit Hex Name Reference
Number Value
------------------------------------------------------------------
28 0x0008 RI-RSVP Capable (I) Section 3
27 0x0010 Per-Peer Flow-Control Capable (F) Section 4
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC2205] and RSVP-TE [RFC3209], and those that are described in [RFC5920], remain relevant.
このドキュメントでは、新しいセキュリティの問題は紹介していません。元のRSVPプロトコル[RFC2205]とRSVP-TE [RFC3209]に関連するセキュリティの考慮事項、および[RFC5920]で説明されている考慮事項は引き続き関連します。
[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>。
[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>.
[RFC2961] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVPリフレッシュオーバーヘッド削減拡張機能」、RFC 2961、DOI 10.17487 / RFC2961、4月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>.
[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>。
[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>.
[RFC4558] Ali、Z.、Rahman、R.、Prairie、D。、およびD. Papadimitriou、「Node-ID Based Resource Reservation Protocol（RSVP）Hello：A Clarification Statement」、RFC 4558、DOI 10.17487 / RFC4558、6月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>.
[RFC5063] Satyanarayana、A.、Ed。およびR.ラーマン編、「Extensions to GMPLS Resource Reservation Protocol（RSVP）Graceful Restart」、RFC 5063、DOI 10.17487 / RFC5063、2007年10月、<https://www.rfc-editor.org/info/rfc5063> 。
[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>。
[RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of Scaling Issues in MPLS-TE Core Networks", RFC 5439, DOI 10.17487/RFC5439, February 2009, <https://www.rfc-editor.org/info/rfc5439>.
[RFC5439]安川S.、Farrel、A。、およびO. Komolafe、「MPLS-TEコアネットワークにおけるスケーリング問題の分析」、RFC 5439、DOI 10.17487 / RFC5439、2009年2月、<https：// www。 rfc-editor.org/info/rfc5439>。
[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>。
a. Refresh Interval (R) - 20 minutes (Section 3): Given that an implementation supporting RI-RSVP doesn't rely on refreshes for state sync between peers, the function of the RSVP refresh interval is analogous to that of IGP refresh interval (the default of which is typically in the order of tens of minutes). Choosing a default of 20 minutes allows the refresh timer to be randomly set to a value in the range [10 minutes (0.5R), 30 minutes (1.5R)].
a. 更新間隔（R）-20分（セクション3）：RI-RSVPをサポートする実装がピア間の状態同期の更新に依存していない場合、RSVP更新間隔の機能はIGP更新間隔（そのデフォルトは通常、数十分程度です。デフォルトの20分を選択すると、更新タイマーを[10分（0.5R）、30分（1.5R）]の範囲の値にランダムに設定できます。
b. Node Hello Interval - 9 seconds (Section 3):
b. ノードのHello間隔-9秒（セクション3）：
[RFC3209] defines the hello timeout as 3.5 times the hello interval. Choosing 9 seconds for the node hello interval gives a hello timeout of 3.5 * 9 = 31.5 seconds. This puts the hello timeout value in the vicinity of the IGP hello timeout value.
[RFC3209]は、helloタイムアウトをhelloインターバルの3.5倍として定義しています。ノードのhello間隔に9秒を選択すると、3.5 * 9 = 31.5秒のhelloタイムアウトになります。これにより、helloタイムアウト値がIGP helloタイムアウト値の近くに配置されます。
c. Retry-Limit (Rl) - 7 (Section 4): Choosing 7 as the retry-limit results in an overall rapid retransmit phase of 31.5 seconds. This matches up with the hello timeout of 31.5 seconds.
c. 再試行制限（Rl）-7（セクション4）：再試行制限として7を選択すると、全体で31.5秒の高速再送信フェーズになります。これは、31.5秒のhelloタイムアウトと一致します。
d. Refresh Interval for refreshing state associated with unacknowledged Path/Resv messages (uR) - 30 seconds (Section 3): The recommended refresh interval (R) value of 20 minutes (for an implementation supporting RI-RSVP) cannot be used for refreshing state associated with unacknowledged Path/Resv messages. This document recommends the use of the traditional default refresh interval value of 30 seconds for uR.
d. 未確認のPath / Resvメッセージ（uR）に関連付けられた状態を更新するための更新間隔-30秒（セクション3）：推奨される更新間隔（R）の値20（RI-RSVPをサポートする実装の場合）は、関連付けられた状態の更新に使用できません未確認のPath / Resvメッセージ。このドキュメントでは、uRに従来のデフォルトの更新間隔値である30秒を使用することを推奨しています。
Acknowledgements
謝辞
The authors would like to thank Yakov Rekhter for initiating this work and providing valuable input. They would like to thank Raveendra Torvi and Chandra Ramachandran for participating in the many discussions that led to the techniques discussed in this document. They would also like to thank Adrian Farrel, Lou Berger, and Elwyn Davies for providing detailed review comments and text suggestions.
著者は、この作業を開始して貴重な情報を提供してくれたYakov Rekhterに感謝します。このドキュメントで説明されている手法につながった多くの議論に参加してくれたRaveendra TorviとChandra Ramachandranに感謝します。また、詳細なレビューコメントとテキストの提案を提供してくれたAdrian Farrel、Lou Berger、およびElwyn Daviesにも感謝します。
Contributors
貢献者
Markus Jork Juniper Networks Email: mjork@juniper.net
Markus Jork Juniper Networksメール：mjork@juniper.net
Ebben Aries Juniper Networks Email: exa@juniper.net
このAriesジュニパーネットワークスのメール：exa@juniper.net
Authors' Addresses
著者のアドレス
Vishnu Pavan Beeram (editor) Juniper Networks
Vishnu Pawan Biran（編集者）Juniper Networks
Email: vbeeram@juniper.net
Ina Minei Google, Inc
いな みねい ごおｇぇ、 いんｃ
Email: inaminei@google.com
Rob Shakir Google, Inc
Rob Shakir Google、Inc
Email: rjs@rob.sh
Dante Pacella Verizon
ダンテパチェッラベライゾン
Email: dante.j.pacella@verizon.com
Tarek Saad Cisco Systems
Saad Cisco Systemsの追跡
Email: tsaad@cisco.com