Internet Engineering Task Force (IETF) B. Decraene
Request for Comments: 9681 Orange
Category: Experimental L. Ginsberg
ISSN: 2070-1721 Cisco Systems
T. Li
Juniper Networks, Inc.
G. Solignac
M. Karasek
Cisco Systems
G. Van de Velde
Nokia
T. Przygienda
Juniper
November 2024
Current Link State PDU flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding.
現在のリンク状態PDU洪水率は、最新のネットワークがサポートできるものよりもはるかに遅いです。IS-ISを大規模に使用するには、希望する収束目標を達成するために、より速い洪水率が必要です。このドキュメントでは、より速い洪水の必要性、より速い洪水に関する問題、およびより速い洪水を達成するためのいくつかの例のアプローチについて説明します。また、より速い洪水に関連するプロトコル拡張も定義します。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9681.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9681で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Historical Behavior
4. Flooding Parameters TLV
4.1. LSP Burst Size Sub-TLV
4.2. LSP Transmission Interval Sub-TLV
4.3. LSPs per PSNP Sub-TLV
4.4. Flags Sub-TLV
4.5. PSNP Interval Sub-TLV
4.6. Receive Window Sub-TLV
4.7. Operation on a LAN Interface
5. Performance Improvement on the Receiver
5.1. Rate of LSP Acknowledgments
5.2. Packet Prioritization on Receive
6. Congestion and Flow Control
6.1. Overview
6.2. Congestion and Flow Control Algorithm
6.3. Transmitter-Based Congestion Control Approach
7. IANA Considerations
7.1. Flooding Parameters TLV
7.2. Registry: IS-IS Sub-TLV for Flooding Parameters TLV
7.3. Registry: IS-IS Bit Values for Flooding Parameters Flags
Sub-TLV
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Link state IGPs such as Intermediate System to Intermediate System (IS-IS) depend upon having consistent Link State Databases (LSDBs) on all Intermediate Systems (ISs) in the network in order to provide correct forwarding of data packets. When topology changes occur, new/updated Link State PDUs (LSPs) are propagated network-wide. The speed of propagation is a key contributor to convergence time.
中間システムなどのリンク状態IGPは、データパケットの正しい転送を提供するために、ネットワーク内のすべての中間システム（ISS）に一貫したリンク状態データベース（LSDB）を持つことに依存します。トポロジの変更が発生すると、新規/更新されたリンク状態PDU（LSP）がネットワーク全体に伝播されます。伝播の速度は、収束時間の重要な貢献者です。
IS-IS base specification [ISO10589] does not use flow or congestion control but static flooding rates. Historically, flooding rates have been conservative -- on the order of tens of LSPs per second. This is the result of guidance in the base specification and early deployments when the CPU and interface speeds were much slower and the area scale was much smaller than they are today.
IS-ISベース仕様[ISO10589]は、フローまたは輻輳制御ではなく、静的洪水速度を使用します。歴史的に、洪水率は保守的であり、1秒あたりの数十のLSPの順序で。これは、CPUとインターフェイスの速度がはるかに遅く、エリアスケールが現在よりもはるかに小さかったベース仕様と早期展開のガイダンスの結果です。
As IS-IS is deployed in greater scale both in the number of nodes in an area and in the number of neighbors per node, the impact of the historic flooding rates becomes more significant. Consider the bring-up or failure of a node with 1000 neighbors. This will result in a minimum of 1000 LSP updates. At typical LSP flooding rates used today (33 LSPs per second), it would take more than 30 seconds simply to send the updated LSPs to a given neighbor. Depending on the diameter of the network, achieving a consistent LSDB on all nodes in the network could easily take a minute or more.
IS-ISは、エリアのノード数とノードあたりの近隣数の両方でより大きなスケールで展開されているため、歴史的な洪水率の影響がより重要になります。1000人の隣人を持つノードの供給または障害を考慮してください。これにより、最低1000のLSP更新が行われます。今日使用されている典型的なLSP洪水率（1秒あたり33 LSP）では、更新されたLSPを特定の隣人に送信するだけで30秒以上かかります。ネットワークの直径に応じて、ネットワーク内のすべてのノードで一貫したLSDBを達成するには、簡単に1分以上かかる場合があります。
Therefore, increasing the LSP flooding rate becomes an essential element of supporting greater network scale.
したがって、LSP洪水率を上げることは、より大きなネットワークスケールをサポートする重要な要素になります。
Improving the LSP flooding rate is complementary to protocol extensions that reduce LSP flooding traffic by reducing the flooding topology such as Mesh Groups [RFC2973] or Dynamic Flooding [RFC9667]. Reduction of the flooding topology does not alter the number of LSPs required to be exchanged between two nodes, so increasing the overall flooding speed is still beneficial when such extensions are in use. It is also possible that the flooding topology can be reduced in ways that prefer the use of neighbors that support improved flooding performance.
LSP洪水率の改善は、メッシュグループ[RFC2973]や動的洪水[RFC9667]などの洪水トポロジを減らすことにより、LSPの洪水トラフィックを減らすプロトコル拡張を補完します。洪水トポロジの削減は、2つのノード間で交換するために必要なLSPの数を変更しないため、そのような拡張機能が使用されている場合、全体的な洪水速度を上げることは依然として有益です。また、洪水性パフォーマンスの改善をサポートする隣人の使用を好む方法で、洪水トポロジを減らすことができます。
With the goal of supporting faster flooding, this document introduces the signaling of additional flooding related parameters (Section 4), specifies some performance improvements on the receiver (Section 5) and introduces the use of flow and/or congestion control (Section 6).
より速い洪水をサポートすることを目的として、このドキュメントでは、追加の洪水関連パラメーターのシグナル伝達（セクション4）を導入し、受信機のパフォーマンスの改善（セクション5）を指定し、フローおよび/または輻輳制御の使用（セクション6）を導入します。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The base specification for IS-IS [ISO10589] was first published in 1992 and updated in 2002. The update made no changes in regards to suggested timer values. Convergence targets at the time were on the order of seconds, and the specified timer values reflect that. Here are some examples:
IS-IS [ISO10589]の基本仕様は1992年に最初に公開され、2002年に更新されました。この更新により、推奨されるタイマー値に関して変更はありませんでした。当時の収束ターゲットは秒程度であり、指定されたタイマー値はそれを反映しています。ここにいくつかの例があります：
minimumLSPGenerationInterval
minimumlspgenerationInterval
- This is the minimum time interval between generation of Link State PDUs. A source Intermediate system shall wait at least this long before regenerating one of its own Link State PDUs. [...]
- これは、リンク状態PDUの生成間の最小時間間隔です。ソース中間システムは、少なくともこれほどずっとずっと待ってから、独自のリンク状態PDUの1つを再生します。[...]
A reasonable value is 30 s.
合理的な値は30秒です。
minimumLSPTransmissionInterval
minimumlsptransmissionInterval
- This is the amount of time an Intermediate system shall wait before further propagating another Link State PDU from the same source system. [...]
- これは、同じソースシステムから別のリンク状態PDUをさらに伝播する前に、中間システムが待つ時間です。[...]
A reasonable value is 5 s.
合理的な値は5秒です。
partialSNPInterval
partialsnpinterval
- This is the amount of time between periodic action for transmission of Partial Sequence Number PDUs. It shall be less than minimumLSPTransmissionInterval. [...]
- これは、部分シーケンス数PDUの伝達のための周期的アクション間の時間です。それは、最小限のlspTransmissionInterval未満でなければなりません。[...]
A reasonable value is 2 s.
合理的な値は2秒です。
Most relevant to a discussion of the LSP flooding rate is the recommended interval between the transmission of two different LSPs on a given interface.
LSP洪水率の議論に最も関連することは、特定のインターフェイス上の2つの異なるLSPの伝送間の推奨区間です。
For broadcast interfaces, [ISO10589] states:
ブロードキャストインターフェイスの場合、[ISO10589]は次のように述べています。
minimumBroadcastLSPTransmissionInterval indicates the minimum interval between PDU arrivals which can be processed by the slowest Intermediate System on the LAN.
MinimumbroadCastlSpTransmissInterIntervalは、LANで最も遅い中間システムによって処理できるPDU到着間の最小間隔を示します。
The default value was defined as 33 milliseconds. It is permitted to send multiple LSPs back to back as a burst, but this was limited to 10 LSPs in a one-second period.
デフォルト値は、33ミリ秒として定義されました。バーストとして複数のLSPを背中合わせに送信することは許可されていますが、これは1秒の期間で10 LSPに制限されていました。
Although this value was specific to LAN interfaces, this has commonly been applied by implementations to all interfaces though that was not the original intent of the base specification. In fact, Section 12.1.2.4.3 of [ISO10589] states:
この値はLANインターフェイスに固有でしたが、これは一般にすべてのインターフェイスへの実装によって適用されていますが、ベース仕様の元の意図ではありませんでした。実際、[ISO10589]のセクション12.1.2.4.3は次のとおりです。
On point-to-point links the peak rate of arrival is limited only by the speed of the data link and the other traffic flowing on that link.
ポイントツーポイントリンクでは、ピーク到着率は、データリンクの速度とそのリンクに流れる他のトラフィックによってのみ制限されます。
Although modern implementations have not strictly adhered to the 33-millisecond interval, it is commonplace for implementations to limit the flooding rate to the same order of magnitude: tens of milliseconds, and not the single digits or fractions of milliseconds that are needed today.
最新の実装は33ミリ秒間隔に厳密に順守されていませんが、実装が洪水率を同じ規模に制限することは一般的です。数十ミリ秒、そして今日必要とされる1桁または分数の分数ではありません。
In the past 20 years, significant work on achieving faster convergence, more specifically sub-second convergence, has resulted in implementations modifying a number of the above timers in order to support faster signaling of topology changes. For example, minimumLSPGenerationInterval has been modified to support millisecond intervals, often with a backoff algorithm applied to prevent LSP generation storms in the event of rapid successive oscillations.
過去20年間で、より速い収束、より具体的にはサブセカンドの収束を達成するための重要な作業により、トポロジの変化のより速いシグナル伝達をサポートするために、上記のタイマーの多くを変更することができました。たとえば、MinimulLSPGenerationIntervalは、急速に連続した振動が発生した場合にLSP生成の嵐を防ぐためにバックオフアルゴリズムが適用されることが多いミリ秒間隔をサポートするように変更されています。
However, the flooding rate has not been fundamentally altered.
ただし、洪水率は根本的に変更されていません。
This document defines a new Type-Length-Value (TLV) tuple called the "Flooding Parameters TLV" that may be included in IS-IS Hellos (IIHs) or Partial Sequence Number PDUs (PSNPs). It allows IS-IS implementations to advertise flooding-related parameters and capabilities that may be used by the peer to support faster flooding.
このドキュメントでは、IS-IS Hellos（IIHS）または部分シーケンス番号PDU（PSNP）に含まれる「フラッディングパラメーターTLV」と呼ばれる新しいタイプ長値（TLV）タプルを定義します。これにより、IS-ISの実装は、より速い洪水をサポートするためにピアが使用する可能性のある洪水関連のパラメーターと機能を宣伝することができます。
Type:
タイプ：
21
21
Length:
長さ：
variable; the size in octets of the Value field
変数;値フィールドのオクテットのサイズ
Value:
値：
one or more sub-TLVs
1つ以上のサブTLV
Several sub-TLVs are defined in this document. The support of any sub-TLV is OPTIONAL.
このドキュメントでは、いくつかのサブTLVが定義されています。Sub-TLVのサポートはオプションです。
For a given IS-IS adjacency, the Flooding Parameters TLV does not need to be advertised in each IIH or PSNP. An IS uses the latest received value for each parameter until a new value is advertised by the peer. However, as IIHs and PSNPs are not reliably exchanged and may never be received, parameters SHOULD be sent even if there is no change in value since the last transmission. For a parameter that has never been advertised, an IS uses its local default value. That value SHOULD be configurable on a per-node basis and MAY be configurable on a per-interface basis.
特定のIS-IS隣接については、洪水パラメーターTLVを各IIHまたはPSNPで宣伝する必要はありません。ANは、ピアによって新しい値が宣伝されるまで、各パラメーターの最新の受信値を使用します。ただし、IIHSとPSNPは確実に交換されず、受信されない可能性があるため、最後の伝送以来価値に変化がない場合でも、パラメーターを送信する必要があります。宣伝されていないパラメーターの場合、Aはローカルデフォルト値を使用します。その値は、ノードごとに構成可能であり、インターフェイスごとに構成可能である場合があります。
The LSP Burst Size sub-TLV advertises the maximum number of LSPs that the node can receive without an intervening delay between LSP transmissions.
LSPバーストサイズのSub-TLVは、LSP送信の間に介在する遅延なしにノードが受信できるLSPの最大数を宣伝します。
Type:
タイプ：
1
1
Length:
長さ：
4 octets
4オクテット
Value:
値：
number of LSPs that can be received back to back
背中合わせに受信できるLSPの数
The LSP Transmission Interval sub-TLV advertises the minimum interval, in microseconds, between LSPs arrivals that can be sustained on this receiving interface.
LSP伝送間隔Sub-TLVは、この受信インターフェイスで維持できるLSPの到着の間に、マイクロ秒単位で最小間隔を宣伝します。
Type:
タイプ：
2
2
Length:
長さ：
4 octets
4オクテット
Value:
値：
minimum interval, in microseconds, between two consecutive LSPs received after LSP Burst Size LSPs have been received
LSPバーストサイズのLSPを受信した後に受け取った2つの連続したLSPの間のマイクロ秒の最小間隔
The LSP Transmission Interval is an advertisement of the receiver's sustainable LSP reception rate. This rate may be safely used by a sender that does not support the flow control or congestion algorithm. It may also be used as the minimal safe rate by flow control or congestion algorithms in unexpected cases, e.g., when the receiver is not acknowledging LSPs anymore.
LSP送信間隔は、受信者の持続可能なLSP受信率の広告です。このレートは、フロー制御または輻輳アルゴリズムをサポートしていない送信者が安全に使用できます。また、予期しない場合のフロー制御または輻輳アルゴリズムによって最小限の安全レートとして使用される場合があります。たとえば、レシーバーがLSPをもう確認していない場合。
The LSP per PSNP (LPP) sub-TLV advertises the number of received LSPs that triggers the immediate sending of a PSNP to acknowledge them.
PSNPあたりのLSP（LPP）Sub-TLVは、PSNPの即時送信をトリガーしてそれらを認めることをトリガーする受信したLSPの数を宣伝します。
Type:
タイプ：
3
3
Length:
長さ：
2 octets
2オクテット
Value:
値：
number of LSPs acknowledged per PSNP
PSNPごとに認められているLSPの数
A node advertising this sub-TLV with a value for LPP MUST send a PSNP once LPP LSPs have been received and need to be acknowledged.
LPPの値を持つこのサブTLVを宣伝するノードは、LPP LSPが受信され、認められる必要がある後にPSNPを送信する必要があります。
The sub-TLV Flags advertises a set of flags.
Sub-TLVフラグは、一連のフラグを宣伝しています。
Type:
タイプ：
4
4
Length:
長さ：
Indicates the length in octets (1-8) of the Value field. The length SHOULD be the minimum required to send all bits that are set.
値フィールドのオクテット（1-8）の長さを示します。長さは、設定されたすべてのビットを送信するために必要な最小でなければなりません。
Value:
値：
list of flags
フラグのリスト
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
|O| ...
+-+-+-+-+-+-+-+-+...
An LSP receiver sets the O-flag (Ordered acknowledgment) to indicate to the LSP sender that it will acknowledge the LSPs in the order as received. A PSNP acknowledging N LSPs is acknowledging the N oldest LSPs received. The order inside the PSNP is meaningless. If the sender keeps track of the order of LSPs sent, this indication allows for fast detection of the loss of an LSP. This MUST NOT be used to alter the retransmission timer for any LSP. This MAY be used to trigger a congestion signal.
LSPレシーバーは、O-Flag（注文承認）を設定して、LSP送信者に、受信した順序でLSPを承認することを示します。N LSPを認めるPSNPは、受け取った最古のLSPを認めています。PSNP内の順序は無意味です。送信者が送信されたLSPの順序を追跡している場合、この表示により、LSPの喪失を迅速に検出できます。これは、LSPの再送信タイマーを変更するために使用しないでください。これは、輻輳信号をトリガーするために使用できます。
The PSNP Interval sub-TLV advertises the amount of time in milliseconds between periodic action for transmission of PSNPs. This time will trigger the sending of a PSNP even if the number of unacknowledged LSPs received on a given interface does not exceed LPP (Section 4.3). The time is measured from the reception of the first unacknowledged LSP.
PSNP間隔Sub-TLVは、PSNPの伝送のための周期的アクション間のミリ秒単位で時間を宣伝します。今回は、特定のインターフェイスで受信された未承認のLSPの数がLPPを超えない場合でも、PSNPの送信をトリガーします（セクション4.3）。時間は、最初の承認されていないLSPの受信から測定されます。
Type:
タイプ：
5
5
Length:
長さ：
2 octets
2オクテット
Value:
値：
partialSNPInterval in milliseconds
millisecondsのpartialsnpinterval
A node advertising this sub-TLV SHOULD send a PSNP at least once per PSNP Interval if one or more unacknowledged LSPs have been received on a given interface.
このSub-TLVを宣伝するノードは、特定のインターフェイスで1つ以上の承認されていないLSPが受信されている場合、PSNP間隔ごとに少なくとも1回PSNPを送信する必要があります。
The Receive Window (RWIN) sub-TLV advertises the maximum number of unacknowledged LSPs that the node can receive for a given adjacency.
受信ウィンドウ（RWIN）Sub-TLVは、ノードが特定の隣接に対して受信できる最大数の未装填LSPを宣伝します。
Type:
タイプ：
6
6
Length:
長さ：
2 octets
2オクテット
Value:
値：
maximum number of unacknowledged LSPs
未吸収のLSPの最大数
On a LAN interface, all LSPs are link-level multicasts. Each LSP sent will be received by all ISs on the LAN, and each IS will receive LSPs from all transmitters. In this section, we clarify how the flooding parameters should be interpreted in the context of a LAN.
LANインターフェイスでは、すべてのLSPがリンクレベルのマルチキャストです。送信される各LSPは、LAN上のすべてのISSによって受信され、それぞれがすべての送信機からLSPを受け取ります。このセクションでは、LANのコンテキストで洪水パラメーターをどのように解釈すべきかを明確にします。
An LSP receiver on a LAN will communicate its desired flooding parameters using a single Flooding Parameters TLV, which will be received by all LSP transmitters. The flooding parameters sent by the LSP receiver MUST be understood as instructions from the LSP receiver to each LSP transmitter about the desired maximum transmit characteristics of each transmitter. The receiver is aware that there are multiple transmitters that can send LSPs to the receiver LAN interface. The receiver might want to take that into account by advertising more conservative values, e.g., a higher LSP Transmission Interval. When the transmitters receive the LSP Transmission Interval value advertised by an LSP receiver, the transmitters should rate-limit LSPs according to the advertised flooding parameters. They should not apply any further interpretation to the flooding parameters advertised by the receiver.
LAN上のLSPレシーバーは、すべてのLSP送信機が受信する単一の洪水パラメーターTLVを使用して、目的の洪水パラメーターを通知します。LSPレシーバーによって送信された洪水パラメーターは、各トランスミッターの目的の最大送信特性について、LSPレシーバーから各LSP送信機への指示として理解する必要があります。受信者は、レシーバーLANインターフェイスにLSPを送信できる複数の送信機があることを認識しています。受信者は、より保守的な価値、たとえばより高いLSP伝送間隔を宣伝することにより、それを考慮に入れたいかもしれません。トランスミッターがLSPレシーバーによって宣伝されているLSP伝送間隔値を受信すると、送信機は広告された洪水パラメーターに従ってLSPを速度制限する必要があります。レシーバーが宣伝した洪水パラメーターにさらなる解釈を適用すべきではありません。
A given LSP transmitter will receive multiple flooding parameter advertisements from different receivers that may include different flooding parameter values. A given transmitter SHOULD use the most conservative value on a per-parameter basis. For example, if the transmitter receives multiple LSP Burst Size values, it should use the smallest value.
特定のLSP送信機は、異なる洪水パラメーター値を含む可能性のあるさまざまなレシーバーから複数のフラッディングパラメーター広告を受け取ります。特定の送信機は、パラメーターごとに最も保守的な価値を使用する必要があります。たとえば、送信機が複数のLSPバーストサイズ値を受信した場合、最小値を使用する必要があります。
The Designated Intermediate System (DIS) plays a special role in the operation of flooding on the LAN as it is responsible for responding to PSNPs sent on the LAN circuit that are used to request LSPs that the sender of the PSNP does not have. If the DIS does not support faster flooding, this will impact the maximum flooding speed that could occur on a LAN. Use of LAN priority to prefer a node that supports faster flooding in the DIS election may be useful.
指定された中間システム（DIS）は、PSNPの送信者が持っていないLSPSを要求するために使用されるLAN回路で送信されたPSNPに応答する責任があるため、LANでの洪水の動作に特別な役割を果たします。DISがより速い洪水をサポートしない場合、これはLANで発生する可能性のある最大洪水速度に影響を与えます。LANの優先順位を使用して、DIS選挙でより速い洪水をサポートするノードを好むことが有用かもしれません。
Note: The focus of work used to develop the example algorithms discussed later in this document focused on operation over point-to-point interfaces. A full discussion of how best to do faster flooding on a LAN interface is therefore out of scope for this document.
注：このドキュメントで後で説明したアルゴリズムの例を開発するために使用される作業の焦点は、ポイントツーポイントインターフェイス上の動作に焦点を当てていました。したがって、LANインターフェイスでより速い洪水を行うのが最善の方法についての完全な議論は、このドキュメントの範囲外です。
This section defines two behaviors that SHOULD be implemented on the receiver.
このセクションでは、受信機に実装する必要がある2つの動作を定義します。
On point-to-point networks, PSNPs provide acknowledgments for received LSPs. [ISO10589] suggests using some delay when sending PSNPs. This provides some optimization as multiple LSPs can be acknowledged by a single PSNP.
ポイントツーポイントネットワークでは、PSNPは受信したLSPの謝辞を提供します。[ISO10589]は、PSNPを送信する際にある程度の遅延を使用することをお勧めします。複数のLSPは単一のPSNPによって認識できるため、これは最適化を提供します。
Faster LSP flooding benefits from a faster feedback loop. This requires a reduction in the delay in sending PSNPs.
より速いLSP洪水は、より速いフィードバックループからのメリットがあります。これには、PSNPの送信の遅延を減らす必要があります。
For the generation of PSNPs, the receiver SHOULD use a partialSNPInterval smaller than the one defined in [ISO10589]. The choice of this lower value is a local choice. It may depend on the available processing power of the node, the number of adjacencies, and the requirement to synchronize the LSDB more quickly. 200 ms seems to be a reasonable value.
PSNPの生成の場合、受信機は[ISO10589]で定義されているものよりも小さい部分的な部分を使用する必要があります。この低い値の選択はローカルな選択です。ノードの利用可能な処理能力、隣接の数、およびLSDBをより迅速に同期するための要件に依存する場合があります。200ミリ秒は合理的な価値のようです。
In addition to the timer-based partialSNPInterval, the receiver SHOULD keep track of the number of unacknowledged LSPs per circuit and level. When this number exceeds a preset threshold of LSPs per PSNP (LPP), the receiver SHOULD immediately send a PSNP without waiting for the PSNP timer to expire. In the case of a burst of LSPs, this allows more frequent PSNPs, giving faster feedback to the sender. Outside of the burst case, the usual timer-based PSNP approach comes into effect.
タイマーベースのPartialSnpintervalに加えて、受信機は回路とレベルごとの未吸合のLSPの数を追跡する必要があります。この数値がPSNP（LPP）あたりのLSPのプリセットしきい値を超える場合、受信者はPSNPタイマーが期限切れになるのを待たずにすぐにPSNPを送信する必要があります。LSPのバーストの場合、これによりPSNPが頻繁になり、送信者へのフィードバックが高速になります。バーストケース以外では、通常のタイマーベースのPSNPアプローチが有効になります。
The smaller the LPP is, the faster the feedback to the sender and possibly the higher the rate if the rate is limited by the end-to-end RTT (link RTT + time to acknowledge). This may result in an increase in the number of PSNPs sent, which may increase CPU and IO load on both the sender and receiver. The LPP should be less than or equal to 90 as this is the maximum number of LSPs that can be acknowledged in a PSNP at common MTU sizes; hence, waiting longer would not reduce the number of PSNPs sent but would delay the acknowledgments. LPP should not be chosen too high as the congestion control starts with a congestion window of LPP + 1. Based on experimental evidence, 15 unacknowledged LSPs is a good value, assuming that the Receive Window is at least 30. More frequent PSNPs give the transmitter more feedback on receiver progress, allowing the transmitter to continue transmitting while not burdening the receiver with undue overhead.
LPPが小さいほど、送信者へのフィードバックが速くなり、レートがエンドツーエンドのRTTによって制限されている場合、レートが高くなります（承認するためのRTT +時間をリンク）。これにより、送信されるPSNPの数が増加する可能性があり、これにより、送信者と受信機の両方のCPUとIOの負荷が増加する可能性があります。これは、一般的なMTUサイズのPSNPで認識できるLSPの最大数であるため、LPPは90以下である必要があります。したがって、長く待つことは、送信されるPSNPの数を減らすことはありませんが、謝辞を遅らせるでしょう。混雑制御がLPP + 1の輻輳ウィンドウから始まるため、LPPを高く選択すべきではありません。実験的証拠に基づいて、15の未委託LSPは、受信ウィンドウが少なくとも30であると仮定して良い値です。受信機の進行に関するより多くのフィードバックにより、トランスミッターは、気が過度のオーバーヘッドで負担をかけずに送信を続けることができます。
By deploying both the timer-based and the threshold-based PSNP approaches, the receiver can be adaptive to both LSP bursts and infrequent LSP updates.
タイマーベースとしきい値ベースのPSNPアプローチの両方を展開することにより、レシーバーはLSPバーストと頻繁なLSPアップデートの両方に適応できます。
As PSNPs also consume link bandwidth, packet-queue space, and protocol-processing time on receipt, the increased sending of PSNPs should be taken into account when considering the rate at which LSPs can be sent on an interface.
PSNPは、領収書のリンク帯域幅、パケットキュースペース、およびプロトコル処理時間も消費するため、LSPをインターフェイスで送信できるレートを考慮すると、PSNPの送信の増加を考慮する必要があります。
There are three classes of PDUs sent by IS-IS:
is-isによって送信されるpdusには3つのクラスがあります。
* Hellos
* ハロス
* LSPs
* LSP
* SNPs (Complete Sequence Number PDUs (CSNPs) and PSNPs)
* SNPS（完全なシーケンス番号PDU（CSNP）およびPSNP）
Implementations today may prioritize the reception of Hellos over LSPs and Sequence Number PDUs (SNPs) in order to prevent a burst of LSP updates from triggering an adjacency timeout, which in turn would require additional LSPs to be updated.
今日の実装では、LSPの更新が隣接するタイムアウトをトリガーするのを防ぐために、LSPおよびシーケンス番号PDU（SNP）に対するHellosの受信を優先する場合があります。これにより、追加のLSPを更新する必要があります。
CSNPs and PSNPs serve to trigger or acknowledge the transmission of specified LSPs. On a point-to-point link, PSNPs acknowledge the receipt of one or more LSPs. For this reason, [ISO10589] specifies a delay (partialSNPInterval) before sending a PSNP so that the number of PSNPs required to be sent is reduced. On receipt of a PSNP, the set of LSPs acknowledged by that PSNP can be marked so that they do not need to be retransmitted.
CSNPとPSNPは、指定されたLSPの送信をトリガーまたは確認するのに役立ちます。ポイントツーポイントリンクで、PSNPは1つ以上のLSPの受領を確認します。このため、[ISO10589]は、送信する必要があるPSNPの数が削減されるように、PSNPを送信する前に遅延（partialsnpinterval）を指定します。PSNPを受け取ったとき、そのPSNPによって認められたLSPのセットは、再送信する必要がないようにマークすることができます。
If a PSNP is dropped on reception, the set of LSPs advertised in the PSNP cannot be marked as acknowledged, and this results in needless retransmissions that further delay transmission of other LSPs that are yet to be transmitted. It may also make it more likely that a receiver becomes overwhelmed by LSP transmissions.
受信時にPSNPがドロップされた場合、PSNPで宣伝されているLSPのセットは認められたとおりにマークすることはできません。これにより、まだ送信されていない他のLSPの伝達をさらに遅らせる不必要な再送信が得られます。また、レシーバーがLSPトランスミッションに圧倒される可能性が高くなる可能性があります。
Therefore, implementations SHOULD prioritize IS-IS PDUs on the way from the incoming interface to the IS-IS process. The relative priority of packets in decreasing order SHOULD be: Hellos, SNPs, and LSPs. Implementations MAY also prioritize IS-IS packets over other protocols, which are less critical for the router or network, less sensitive to delay, or more bursty (e.g., BGP).
したがって、実装は、着信インターフェイスからIS-ISプロセスに至るまで、IS-IS PDUを優先する必要があります。順序の減少におけるパケットの相対的な優先度は、Hellos、SNP、およびLSPである必要があります。また、実装は、ルーターやネットワークにとってそれほど重要ではなく、遅延に敏感ではない、またはよりバースト（例：BGP）では、IS-ISパケットに優先順位を付ける場合があります。
Ensuring the goodput between two entities is a Layer 4 responsibility as per the OSI model. A typical example is the TCP protocol defined in [RFC9293] that provides flow control, congestion control, and reliability.
2つのエンティティ間のGoodputを保証することは、OSIモデルに従ってレイヤー4の責任です。典型的な例は、フロー制御、混雑制御、および信頼性を提供する[RFC9293]で定義されたTCPプロトコルです。
Flow control creates a control loop between a transmitter and a receiver so that the transmitter does not overwhelm the receiver. TCP provides a means for the receiver to govern the amount of data sent by the sender through the use of a sliding window.
フロー制御は、送信機と受信機が受信機を圧倒しないように、送信機と受信機の間に制御ループを作成します。TCPは、レシーバーがスライドウィンドウを使用して送信者から送信されたデータの量を管理する手段を提供します。
Congestion control prevents the set of transmitters from overwhelming the path of the packets between two IS-IS implementations. This path typically includes a point-to-point link between two IS-IS neighbors, which is usually oversized compared to the capability of the IS-IS speakers, but potentially also includes some internal elements inside each neighbor such as switching fabric, line card CPU, and forwarding plane buffers that may experience congestion. These resources may be shared across multiple IS-IS adjacencies for the system, and it is the responsibility of congestion control to ensure that these are shared reasonably.
混雑制御により、一連の送信機が2つのIS-I-IS実装の間にパケットのパスを圧倒することを防ぎます。このパスには通常、2つのIS近隣の間のポイントツーポイントリンクが含まれます。これは通常、ISスピーカーの機能と比較して大きくなりますが、潜在的には、スイッチングファブリック、ラインカードなど、各近隣内にいくつかの内部要素も含まれます。CPU、および混雑を経験する可能性のある転送面バッファー。これらのリソースは、システムの複数のIS隣接にわたって共有される場合があり、これらが合理的に共有されることを保証することは渋滞制御の責任です。
Reliability provides loss detection and recovery. IS-IS already has mechanisms to ensure the reliable transmission of LSPs. This is not changed by this document.
信頼性は、損失の検出と回復を提供します。IS-ISには、LSPの信頼できる送信を確保するためのメカニズムがすでにあります。これは、このドキュメントによって変更されません。
Sections 6.2 and 6.3 provide two flow and/or congestion control algorithms that may be implemented by taking advantage of the extensions defined in this document. The signal that these IS-IS extensions (defined in Sections 4 and 5) provide is generic and is designed to support different sender-side algorithms. A sender can unilaterally choose a different algorithm to use.
セクション6.2および6.3は、このドキュメントで定義されている拡張機能を活用することで実装できる2つのフローおよび/または混雑制御アルゴリズムを提供します。これらのIS拡張機能（セクション4および5で定義されている）が提供する信号は汎用であり、さまざまな送信者側のアルゴリズムをサポートするように設計されています。送信者は、使用する別のアルゴリズムを一方的に選択できます。
A flow control mechanism creates a control loop between a single transmitter and a single receiver. This section uses a mechanism similar to the TCP receive window to allow the receiver to govern the amount of data sent by the sender. This receive window (RWIN) indicates an allowed number of LSPs that the sender may transmit before waiting for an acknowledgment. The size of the receive window, in units of LSPs, is initialized with the value advertised by the receiver in the Receive Window sub-TLV. If no value is advertised, the transmitter should initialize RWIN with its locally configured value for this receiver.
フロー制御メカニズムは、単一の送信機と単一の受信機の間に制御ループを作成します。このセクションでは、TCP受信ウィンドウと同様のメカニズムを使用して、受信者が送信者から送信されたデータの量を管理できるようにします。この受信ウィンドウ（RWIN）は、送信者が承認を待つ前に送信することができるLSPの許可数を示します。LSPのユニットの受信ウィンドウのサイズは、受信ウィンドウSub-TLVの受信機によって宣伝されている値で初期化されます。値が宣伝されていない場合、送信機はこのレシーバーのローカルで構成された値でRWINを初期化する必要があります。
When the transmitter sends a set of LSPs to the receiver, it subtracts the number of LSPs sent from RWIN. If the transmitter receives a PSNP, then RWIN is incremented for each acknowledged LSP. The transmitter must ensure that the value of RWIN never goes negative.
送信機がレシーバーにLSPのセットを送信すると、RWINから送信されたLSPの数を差し引きます。トランスミッターがPSNPを受信した場合、RWINは認められているLSPごとに増加します。トランスミッターは、RWINの値が負のものにならないようにする必要があります。
The RWIN value is of importance when the RTT is the limiting factor for the throughput. In this case, the optimal size is the desired LSP rate multiplied by the RTT. The RTT is the addition of the link RTT plus the time taken by the receiver to acknowledge the first received LSP in its PSNP. The values 50 or 100 may be reasonable default numbers for RWIN. As an example, an RWIN of 100 requires a control plane input buffer of 150 kbytes per neighbor (assuming an IS-IS MTU of 1500 octets) and limits the throughput to 10000 LSPs per second and per neighbor for a link RTT of 10 ms. With the same RWIN, the throughput limitation is 2000 LSPs per second when the RTT is 50 ms. That's the maximum throughput assuming no other limitations such as CPU limitations.
RTTがスループットの制限要因である場合、RWIN値は重要です。この場合、最適なサイズは、希望のLSPレートにRTTを掛けたものです。RTTは、リンクRTTの追加であり、PSNPで最初に受け取ったLSPを確認するために受信機が取った時間です。値50または100は、RWINの妥当なデフォルト番号になる場合があります。たとえば、100のRWINには、隣人あたり150 kバイトのコントロールプレーン入力バッファーが必要（1500オクテットのIS-IS MTUを想定）。同じRWINでは、RTTが50ミリ秒の場合、スループット制限は2000 LSP /秒になります。これは、CPUの制限などの他の制限がないと仮定して、最大スループットです。
Equally, RTT is of importance for the performance. That is why the performance improvements on the receiver specified in Section 5 are important to achieve good throughput. If the receiver does not support those performance improvements, in the worst case (small RWIN and high RTT) the throughput will be limited by the LSP Transmission Interval as defined in Section 4.2.
同様に、RTTはパフォーマンスにとって重要です。そのため、セクション5で指定された受信機のパフォーマンスの改善が、優れたスループットを実現するために重要です。受信機がこれらのパフォーマンスの改善をサポートしていない場合、最悪の場合（小RWINおよび高RTT）、セクション4.2で定義されているように、スループットはLSP伝送間隔によって制限されます。
By sending the Receive Window sub-TLV, a node advertises to its neighbor its ability to receive that many unacknowledged LSPs from the neighbor. This is akin to a receive window or sliding window in flow control. In some implementations, this value should reflect the IS-IS socket buffer size. Special care must be taken to leave space for CSNPs, PSNPs, and IIHs if they share the same input queue. In this case, this document suggests advertising an LSP Receive Window corresponding to half the size of the IS-IS input queue.
受信ウィンドウSub-TLVを送信することにより、ノードは近隣に隣人から多くの未解決のLSPを受け取る能力を隣接します。これは、フロー制御の受信ウィンドウまたはスライドウィンドウに似ています。いくつかの実装では、この値はIS-ISソケットバッファサイズを反映する必要があります。同じ入力キューを共有する場合、CSNP、PSNP、およびIIHSのスペースを離れるために特別な注意を払う必要があります。この場合、このドキュメントは、IS-IS入力キューの半分のサイズに対応するLSP受信ウィンドウを広告することを提案しています。
By advertising an LSP Transmission Interval sub-TLV, a node advertises its ability to receive LSPs separated by at least the advertised value, outside of LSP bursts.
LSP送信間隔Sub-TLVを宣伝することにより、ノードは、LSPバーストの外で、少なくとも広告値によって区切られたLSPを受信する機能を宣伝します。
By advertising an LSP Burst Size sub-TLV, a node advertises its ability to receive that number of LSPs back to back.
LSPバーストサイズのサブTLVを宣伝することにより、ノードはその数のLSPを連続して受信する機能を宣伝します。
The LSP transmitter MUST NOT exceed these parameters. After having sent a full burst of LSPs, it MUST send the subsequent LSPs with a minimum of LSP Transmission Interval between LSP transmissions. For CPU scheduling reasons, this rate MAY be averaged over a small period, e.g., 10-30 ms.
LSP送信機はこれらのパラメーターを超えてはなりません。LSPの完全なバーストを送信した後、LSPトランスミッション間に最小LSP透過間隔で後続のLSPを送信する必要があります。CPUのスケジューリング上の理由では、このレートは、たとえば10〜30ミリ秒、小さな期間にわたって平均化される場合があります。
If either the LSP transmitter or receiver does not adhere to these parameters, for example, because of transient conditions, this doesn't result in a fatal condition for IS-IS operation. In the worst case, an LSP is lost at the receiver, and this situation is already remedied by mechanisms in [ISO10589]. After a few seconds, neighbors will exchange PSNPs (for point-to-point interfaces) or CSNPs (for broadcast interfaces) and recover from the lost LSPs. This worst case should be avoided as those additional seconds impact convergence time since the LSDB is not fully synchronized. Hence, it is better to err on the conservative side and to under-run the receiver rather than over-run it.
たとえば、LSP送信機または受信機がこれらのパラメーターを順守していない場合、一時的な状態のため、IS-IS操作の致命的な条件にはなりません。最悪の場合、レシーバーでLSPが失われ、この状況は[ISO10589]のメカニズムによってすでに改善されています。数秒後、隣人はPSNP（ポイントツーポイントインターフェイスの場合）またはCSNP（ブロードキャストインターフェイス用）を交換し、失われたLSPから回復します。LSDBが完全に同期していないため、これらの追加の秒に影響を与えるため、この最悪のケースは避けるべきです。したがって、保守的な側で誤りを犯し、それを過剰に追い払うよりも、受信機を過小評価する方が良いです。
Flow and congestion control on a LAN interface is out of scope for this document.
LANインターフェイスのフローと輻輳制御は、このドキュメントの範囲外です。
Whereas flow control prevents the sender from overwhelming the receiver, congestion control prevents senders from overwhelming the network. For an IS-IS adjacency, the network between two IS-IS neighbors is relatively limited in scope and includes a single link that is typically oversized compared to the capability of the IS-IS speakers. In situations where the probability of LSP drop is low, flow control (Section 6.2.1) is expected to give good results, without the need to implement congestion control. Otherwise, adding congestion control will help handling congestion of LSPs in the receiver.
フロー制御により、送信者が受信機を圧倒するのを防ぎますが、混雑制御により、送信者がネットワークを圧倒することを防ぎます。IS-ISの隣接性の場合、2人のIS近隣のネットワークは範囲が比較的限られており、IS-ISスピーカーの機能と比較して一般的に大きい単一のリンクが含まれています。LSPドロップの確率が低い状況では、フロー制御（セクション6.2.1）は、混雑制御を実装する必要なく、良い結果をもたらすと予想されます。それ以外の場合は、うっ血制御を追加すると、レシーバーのLSPの混雑の処理に役立ちます。
This section describes one sender-side congestion control algorithm largely inspired by the TCP congestion control algorithm [RFC5681].
このセクションでは、主にTCP輻輳制御アルゴリズム[RFC5681]に触発された1つの送信者側の混雑制御アルゴリズムについて説明します。
The proposed algorithm uses a variable congestion window 'cwin'. It plays a role similar to the receive window described above. The main difference is that cwin is adjusted dynamically according to various events described below.
提案されているアルゴリズムは、変数輻輳ウィンドウ「CWIN」を使用します。上記の受信ウィンドウと同様の役割を果たします。主な違いは、以下で説明するさまざまなイベントに従ってCWINが動的に調整されることです。
In its simplest form, the congestion control algorithm looks like the following:
最も単純な形式では、混雑制御アルゴリズムは次のようになります。
+---------------+
| |
| v
| +----------------------+
| | Congestion avoidance |
| + ---------------------+
| |
| | Congestion signal
----------------+
Figure 1
The algorithm starts with cwin = cwin0 = LPP + 1. In the congestion avoidance phase, cwin increases as LSPs are acked: for every acked LSP, cwin += 1 / cwin without exceeding RWIN. When LSPs are exchanged, cwin LSPs will be acknowledged in 1 RTT, meaning cwin(t) = t/RTT + cwin0. Since the RTT is low in many IS-IS deployments, the sending rate can reach fast rates in short periods of time.
アルゴリズムはcwin = cwin0 = lpp + 1で始まります。うっ血回避段階では、lspがackedになるとCWINが増加します。LSPが交換されると、CWIN LSPは1 RTTで認められます。RTTは多くのIS展開で低いため、送信率は短期間で速いレートに達する可能性があります。
When updating cwin, it must not become higher than the number of LSPs waiting to be sent, otherwise the sending will not be paced by the receiving of acks. Said differently, transmission pressure is needed to maintain and increase cwin.
CWINを更新する場合、送信を待っているLSPの数よりも高くならないようにする必要があります。そうしないと、ACKの受信によって送信がペースになりません。別の言い方をすれば、cwinを維持および増加させるために伝送圧力が必要です。
When the congestion signal is triggered, cwin is set back to its initial value, and the congestion avoidance phase starts again.
輻輳信号がトリガーされると、CWINは初期値に戻り、混雑回避段階が再び開始されます。
The congestion signal can take various forms. The more reactive the congestion signals, the fewer LSPs will be lost due to congestion. However, overly aggressive congestion signals will cause a sender to keep a very low sending rate even without actual congestion on the path.
混雑信号はさまざまな形をとることができます。渋滞信号が反応性が高いほど、輻輳のためにLSPが失われることが少なくなります。ただし、過度に攻撃的な輻輳シグナルは、パス上の実際の輻輳がなくても、送信者が非常に低い送信率を維持することになります。
Two practical signals are given below.
2つの実用的な信号を以下に示します。
1. Delay: When receiving acknowledgments, a sender estimates the acknowledgment time of the receiver. Based on this estimation, it can infer that a packet was lost and that the path is congested.
1. 遅延：謝辞を受け取るとき、送信者は受信者の承認時間を推定します。この推定に基づいて、パケットが失われ、パスが混雑していると推測できます。
There can be a timer per LSP, but this can become costly for implementations. It is possible to use only a single timer t1 for all LSPs: during t1, sent LSPs are recorded in a list list_1. Once the RTT is over, list_1 is kept and another list, list_2, is used to store the next LSPs. LSPs are removed from the lists when acked. At the end of the second t1 period, every LSP in list_1 should have been acked, so list_1 is checked to be empty. list_1 can then be reused for the next RTT.
LSPごとにタイマーがある場合がありますが、これは実装に費用がかかる場合があります。すべてのLSPに対して単一のタイマーT1のみを使用することができます。T1の間に、送信されたLSPはリストlist_1に記録されます。RTTが終了すると、List_1が保持され、別のList、List_2が次のLSPを保存するために使用されます。LSPは、Ackedの場合、リストから削除されます。2番目のT1期間の終わりに、List_1のすべてのLSPがAckedされている必要があるため、List_1が空になるようにチェックされます。その後、List_1は次のRTTのために再利用できます。
There are multiple strategies to set the timeout value t1. It should be based on measurements of the maximum acknowledgment time (MAT) of each PSNP. Using three times the RTT is the simplest strategy; alternatively, an exponential moving average of the MATs, as described in [RFC6298], can be used. A more elaborate one is to take a running maximum of the MATs over a period of a few seconds. This value should include a margin of error to avoid false positives (e.g., estimated MAT measure variance), which would have a significant impact on performance.
タイムアウト値T1を設定するための複数の戦略があります。各PSNPの最大承認時間（MAT）の測定に基づいている必要があります。RTTの3倍を使用することが最も簡単な戦略です。あるいは、[RFC6298]に記載されているように、マットの指数移動平均を使用できます。より精巧なものは、数秒間にわたってマットの最大マットを実行することです。この値には、誤検知（例えば、推定されたMAT測定の分散など）を避けるためのエラーのマージンを含める必要があります。これは、パフォーマンスに大きな影響を与えます。
2. Loss: if the receiver has signaled the O-flag (see Section 4.4), a sender MAY record its sending order and check that acknowledgments arrive in the same order. If not, some LSPs are missing, and this MAY be used to trigger a congestion signal.
2. 損失：受信者がO-Flagに合図した場合（セクション4.4を参照）、送信者は送信順序を記録し、謝辞が同じ順序で到着することを確認できます。そうでない場合、一部のLSPが欠落しており、これを使用してうっ血信号をトリガーする場合があります。
With the algorithm presented above, if congestion is detected, cwin goes back to its initial value and does not use the information gathered in previous congestion avoidance phases.
上記のアルゴリズムを提示した場合、混雑が検出された場合、CWINは初期値に戻り、以前の混雑回避段階で収集された情報を使用しません。
It is possible to use a fast recovery phase once congestion is detected and to avoid going through this linear rate of growth from scratch. When congestion is detected, a fast recovery threshold frthresh is set to frthresh = cwin / 2. In this fast recovery phase, for every acked LSP, cwin += 1. Once cwin reaches frthresh, the algorithm goes back to the congestion avoidance phase.
混雑が検出されたら、高速回復段階を使用し、この線形成長速度をゼロから通過することを避けることができます。輻輳が検出されると、高速回復のしきい値frthreshがfrthresh = cwin / 2に設定されます。この高速回復段階では、Acked LSPごとにcwin += 1について。
+---------------+
| |
| v
| +----------------------+
| | Congestion avoidance |
| + ---------------------+
| |
| | Congestion signal
| |
| +----------------------+
| | Fast recovery |
| +----------------------+
| |
| | frthresh reached
----------------+
Figure 2
This algorithm's performance is dependent on the LPP value. Indeed, the smaller the LPP is, the more information is available for the congestion control algorithm to perform well. However, it also increases the resources spent on sending PSNPs, so a trade-off must be made. This document recommends using an LPP of 15 or less. If a Receive Window is advertised, LPP SHOULD be lower, and the best performance is achieved when LPP is an integer fraction of the Receive Window.
このアルゴリズムのパフォーマンスは、LPP値に依存します。実際、LPPが小さいほど、混雑制御アルゴリズムがうまく機能する情報が増えます。ただし、PSNPの送信に費やされるリソースも増加するため、トレードオフを行う必要があります。このドキュメントでは、15以下のLPPを使用することをお勧めします。受信ウィンドウが宣伝されている場合、LPPは低くなり、LPPが受信ウィンドウの整数分数である場合に最適なパフォーマンスが達成されます。
Note that this congestion control algorithm benefits from the extensions proposed in this document. The advertisement of a receive window from the receiver (Section 6.2.1) avoids the use of an arbitrary maximum value by the sender. The faster acknowledgment of LSPs (Section 5.1) allows for a faster control loop and hence a faster increase of the congestion window in the absence of congestion.
この混雑制御アルゴリズムは、このドキュメントで提案されている拡張機能の恩恵を受けることに注意してください。受信ウィンドウの広告（セクション6.2.1）は、送信者による任意の最大値の使用を回避します。LSP（セクション5.1）をより高速に認識すると、制御ループがより速くなり、混雑がない場合に輻輳ウィンドウがより速く増加することができます。
As discussed in [RFC9002], Section 7.7, a sender SHOULD pace sending of all in-flight LSPs based on input from the congestion controller.
[RFC9002]、セクション7.7で説明したように、送信者は、混雑コントローラーからの入力に基づいて、すべての飛行中のLSPをペースで送信する必要があります。
Sending multiple packets without any delay between them creates a packet burst that might cause short-term congestion and losses. Senders MUST either use pacing or limit such bursts. Senders SHOULD limit bursts to LSP Burst Size.
それらの間に遅延することなく複数のパケットを送信すると、短期の混雑と損失を引き起こす可能性のあるパケットバーストが作成されます。送信者は、ペーシングを使用するか、そのようなバーストを制限する必要があります。送信者は、バーストをLSPバーストサイズに制限する必要があります。
Senders can implement pacing as they choose. A perfectly paced sender spreads packets evenly over time. For a window-based congestion controller, such as the one in this section, that rate can be computed by averaging the congestion window over the RTT. Expressed as an inter-packet interval in units of time:
送信者は、選択したときにペーシングを実装できます。完全にペースの送信者は、時間の経過とともにパケットを均等に広げます。このセクションのようなウィンドウベースの混雑コントローラーの場合、そのレートは、RTT上の輻輳ウィンドウを平均することで計算できます。時間単位でパケット間間隔として表現されています：
interval = (SRTT / cwin) / N
interval =（srtt / cwin） / n
SRTT is the Smoothed Round-Trip Time [RFC6298].
SRTTは、滑らかな往復時間です[RFC6298]。
Using a value for N that is small, but at least 1 (for example, 1.25), ensures that variations in RTT do not result in underutilization of the congestion window.
小さいnの値を使用しますが、少なくとも1（たとえば、1.25）は、RTTの変動が輻輳ウィンドウの十分な活用をもたらさないことを保証します。
Practical considerations, such as scheduling delays and computational efficiency, can cause a sender to deviate from this rate over time periods that are much shorter than an RTT.
スケジューリングの遅延や計算効率などの実際的な考慮事項により、送信者はRTTよりもはるかに短い期間にわたってこのレートから逸脱する可能性があります。
One possible implementation strategy for pacing uses a leaky bucket algorithm, where the capacity of the "bucket" is limited to the maximum burst size, and the rate that the "bucket" fills is determined by the above function.
ペーシングの可能な実装戦略の1つは、「バケツ」の容量が最大バーストサイズに制限され、「バケット」が埋める速度が上記の関数によって決定される漏れやすいバケットアルゴリズムを使用します。
The values that a receiver advertises do not need to be perfect. If the values are too low, then the transmitter will not use the full bandwidth or available CPU resources. If the values are too high, then the receiver may drop some LSPs during the first RTT, and this loss will reduce the usable receive window, and the protocol mechanisms will allow the adjacency to recover. Flooding slower than both nodes can support will hurt performance as will consistently overloading the receiver.
受信者が宣伝する価値は、完璧である必要はありません。値が低すぎる場合、送信機は完全な帯域幅または利用可能なCPUリソースを使用しません。値が高すぎる場合、受信者は最初のRTT中にいくつかのLSPを落とす可能性があり、この損失は使用可能な受信ウィンドウを減らし、プロトコルメカニズムにより隣接性が回復することができます。両方のノードがサポートできるよりも遅い洪水は、レシーバーを一貫して過負荷にするため、パフォーマンスを損なうでしょう。
The values advertised need not be dynamic, as feedback is provided by the acknowledgment of LSPs in SNP messages. Acknowledgments provide a feedback loop on how fast the LSPs are processed by the receiver. They also signal that the LSPs can be removed from the receive window, explicitly signaling to the sender that more LSPs may be sent. By advertising relatively static parameters, we expect to produce overall flooding behavior similar to what might be achieved by manually configuring per-interface LSP rate-limiting on all interfaces in the network. The advertised values could be based, for example, on offline tests of the overall LSP-processing speed for a particular set of hardware and the number of interfaces configured for IS-IS. With such a formula, the values advertised in the Flooding Parameters TLV would only change when additional IS-IS interfaces are configured.
宣伝されている値は、SNPメッセージのLSPの承認によってフィードバックが提供されるため、動的ではありません。謝辞は、レシーバーによってLSPがどれだけ速く処理されるかについてのフィードバックループを提供します。また、LSPを受信ウィンドウから削除できることを示しており、より多くのLSPが送信される可能性があることを送信者に明示的に信号します。比較的静的なパラメーターを広告することにより、ネットワーク内のすべてのインターフェイスでインターフェイスごとのLSPレート制限を手動で構成することで達成できるものと同様の全体的な洪水挙動を生成することが期待されます。広告された値は、たとえば、特定のハードウェアセットのLSP処理速度全体のオフラインテストと、IS-ISに対して構成されたインターフェイスの数に基づいている可能性があります。このような式では、フラッディングパラメーターTLVで宣伝されている値は、追加のISインターフェイスが構成されている場合にのみ変更されます。
Static values are dependent on the CPU generation, class of router, and network scaling, typically the number of adjacent neighbors. Examples at the time of publication are provided below. The LSP Burst Size could be in the range 5 to 20. From a router perspective, this value typically depends on the queue(s) size(s) on the I/O path from the packet forwarding engine to the control plane, which is very platform-dependent. It also depends upon how many IS-IS neighbors share this I/O path, as typically all neighbors will send the same LSPs at the same time. It may also depend on other incoming control plane traffic that is sharing that I/O path, how bursty they are, and how many incoming IS-IS packets are prioritized over other incoming control plane traffic. As indicated in Section 3, the historical behavior from [ISO10589] allows a value of 10; hence, 10 seems conservative. From a network operation perspective, it would be beneficial for the burst size to be equal to or higher than the number of LSPs that may be originated by a single failure. For a node failure, this is equal to the number of IS-IS neighbors of the failed node. The LSP Transmission Interval could be in the range of 1 ms to 33 ms. As indicated in Section 3, the historical behavior from [ISO10589] is 33 ms; hence, 33 ms is conservative. The LSP Transmission Interval is an advertisement of the receiver's sustainable LSP reception rate taking into account all aspects and particularly the control plane CPU and the I/O bandwidth. It's expected to improve (hence, decrease) as hardware and software naturally improve over time. It should be chosen conservatively, as this rate may be used by the sender in all conditions -- including the worst conditions. It's also not a bottleneck as the flow control algorithm may use a higher rate in good conditions, particularly when the receiver acknowledges quickly, and the receive window is large enough compared to the RTT. LPP could be in the range of 5 to 90 with a proposed 15. A smaller value provides faster feedback at the cost of the small overhead of more PSNP messages. PartialSNPInterval could be in the range 50 to 500 ms with a proposed value of 200 ms. One may distinguish the value used locally from the value signaled to the sender. The value used locally benefits from being small but is not expected to be the main parameter to improve performance. It depends on how fast the IS-IS flooding process may be scheduled by the CPU. Even when the receiver CPU is busy, it's safe because it will naturally delay its acknowledgments, which provides a negative feedback loop. The value advertised to the sender should be conservative (high enough) as this value could be used by the sender to send some LSPs rather than keep waiting for acknowledgments. Receive Window could be in the range of 30 to 200 with a proposed value of 60. In general, the larger the better the performance on links with high RTT. The higher that number and the higher the number of IS-IS neighbors, the higher the use of control plane memory, so it's mostly dependent on the amount of memory, which may be dedicated to IS-IS flooding and the number of IS-IS neighbors. From a memory usage perspective (a priori), one could use the same value as the TCP receive window, but the value advertised should not be higher than the buffer of the "socket" used.
静的値は、CPUの生成、ルーターのクラス、およびネットワークスケーリング、通常は隣接する隣人の数に依存します。出版時の例を以下に示します。LSPバーストサイズは5〜20の範囲にある可能性があります。ルーターの観点から、この値は通常、パケット転送エンジンからコントロールプレーンまでのI/Oパス上のキューのサイズに依存します。非常にプラットフォームに依存します。また、通常、すべての隣人が同じLSPを同時に送信するため、このI/Oパスを共有するISの隣人の数にも依存します。また、I/Oパス、それらがどれほど破裂しているか、そして他の着信プレーントラフィックよりも優先順位付けされるIS-ISパケットの数を共有している他の着信プレーントラフィックに依存する場合があります。セクション3に示されているように、[ISO10589]の歴史的行動は10の値を許可します。したがって、10は保守的なようです。ネットワーク操作の観点からは、バーストサイズが単一の障害によって発信される可能性のあるLSPの数以上が等しくなることが有益です。ノードの障害の場合、これは失敗したノードのIS-IS近隣の数に等しくなります。LSP伝送間隔は、1ミリ秒から33ミリ秒の範囲である可能性があります。セクション3に示されているように、[ISO10589]の歴史的行動は33ミリ秒です。したがって、33ミリ秒は保守的です。LSP送信間隔は、すべての側面、特にコントロールプレーンCPUおよびI/O帯域幅を考慮した、受信者の持続可能なLSP受信率の広告です。ハードウェアとソフトウェアが時間の経過とともに自然に改善するため、改善することが期待されています（したがって、減少します）。このレートは、最悪の条件を含むすべての条件で送信者が使用する可能性があるため、保守的に選択する必要があります。また、フロー制御アルゴリズムは良好な条件でより高いレートを使用する可能性があるため、特に受信者が迅速に認識し、受信ウィンドウがRTTと比較して十分に大きいため、ボトルネックでもありません。LPPは、提案された15で5〜90の範囲である可能性があります。値が少ないと、より多くのPSNPメッセージの小さなオーバーヘッドを犠牲にしてフィードバックが高速になります。PartialSnpintervalは、200ミリ秒の提案された値で50〜500ミリ秒の範囲にある可能性があります。局所的に使用される値を、送信者に通知された値と区別することができます。使用される値は、局所的に小さいことから利益を得ていますが、パフォーマンスを改善するための主要なパラメーターになるとは期待されていません。IS-ISの洪水プロセスがCPUによってどれだけ速くスケジュールされるかに依存します。受信機CPUが忙しい場合でも、否定的なフィードバックループを提供することを自然に遅延させるため、安全です。送信者に宣伝されている値は、この値を承認を待ち続けるのではなく、いくつかのLSPを送信するためにこの値を使用できるため、保守的（十分に高い）でなければなりません。受信ウィンドウの範囲は30〜200から200の範囲で、提案された値は60です。一般に、高RTTとのリンクのパフォーマンスが大きくなります。その数とISの隣接の数が多いほど、コントロールプレーンメモリの使用が高くなるため、IS-ISの洪水とIS-ISの数に専念するメモリの量にほとんど依存します。隣人。メモリ使用の観点（先験的）から、TCP受信ウィンドウと同じ値を使用できますが、宣伝されている値は、使用される「ソケット」のバッファよりも高くはありません。
To reflect the relative change of load on the receiver, the values may be updated dynamically by improving the values when the receiver load is getting lower and by degrading the values when the receiver load is getting higher. For example, if LSPs are regularly dropped, or if the queue regularly comes close to being filled, then the values may be too high. On the other hand, if the queue is barely used (by IS-IS), then the values may be too low.
受信機の負荷の相対的な変化を反映するために、受信機の負荷が低くなったときに値を改善し、受信機負荷が高くなっているときに値を分解することにより、値を動的に更新できます。たとえば、LSPが定期的にドロップされている場合、またはキューが定期的に満たされている場合、値が高すぎる可能性があります。一方、キューがほとんど使用されない場合（IS-IS）、値が低すぎる場合があります。
Alternatively, the values may be computed to reflect the relevant average hardware resources, e.g., the amount of buffer space used by incoming LSPs. In this case, care must be taken when choosing the parameters influencing the values in order to avoid undesirable or unstable feedback loops. For example, it would be undesirable to use a formula that depends on an active measurement of the instantaneous CPU load to modify the values advertised in the Flooding Parameters TLV. This could introduce feedback into the IGP flooding process that could produce unexpected behavior.
あるいは、値を計算して、関連する平均ハードウェアリソース、たとえば、着信LSPで使用するバッファスペースの量を反映することができます。この場合、望ましくないまたは不安定なフィードバックループを避けるために、値に影響を与えるパラメーターを選択するときは注意が必要です。たとえば、瞬間的なCPU負荷のアクティブな測定に依存する式を使用して、洪水パラメーターTLVで宣伝されている値を変更することは望ましくありません。これにより、予期しない動作を生成する可能性のあるIGP洪水プロセスへのフィードバックが導入される可能性があります。
As discussed in Section 4.7, the solution is more effective on point-to-point adjacencies. Hence, a broadcast interface (e.g., Ethernet) only shared by two IS-IS neighbors should be configured as point-to-point in order to have more effective flooding.
セクション4.7で説明したように、ソリューションはポイントツーポイントの隣接により効果的です。したがって、より効果的な洪水を発揮するために、2人のIS-IS近隣によってのみ共有される放送インターフェイス（イーサネットなど）は、ポイントツーポイントとして構成する必要があります。
This section describes an approach to the congestion control algorithm based on performance measured by the transmitter without dependence on signaling from the receiver.
このセクションでは、受信機からの信号に依存せずに送信機によって測定されたパフォーマンスに基づいた輻輳制御アルゴリズムへのアプローチについて説明します。
Note that the following description is an abstraction; implementation details vary.
次の説明は抽象化であることに注意してください。実装の詳細はさまざまです。
Existing router architectures may utilize multiple input queues. On a given line card, IS-IS PDUs from multiple interfaces may be placed in a rate-limited input queue. This queue may be dedicated to IS-IS PDUs or may be shared with other routing related packets.
既存のルーターアーキテクチャは、複数の入力キューを利用する場合があります。特定のラインカードでは、複数のインターフェイスからのIS PDUをレート制限入力キューに配置できます。このキューは、IS-IS PDUに専念するか、他のルーティング関連パケットと共有される場合があります。
The input queue may then pass IS-IS PDUs to a "punt queue", which is used to pass PDUs from the data plane to the control plane. The punt queue typically also has controls on its size and the rate at which packets will be punted.
入力キューは、IS-IS PDUを「パントキュー」に渡すことができます。これは、データプレーンからコントロールプレーンにPDUを渡すために使用されます。パントキューには通常、そのサイズとパケットがパントされる速度に関するコントロールもあります。
An input queue in the control plane may then be used to assemble PDUs from multiple line cards, separate the IS-IS PDUs from other types of packets, and place the IS-IS PDUs in an input queue dedicated to the IS-IS protocol.
次に、コントロールプレーンの入力キューを使用して、複数のラインカードからPDUを組み立て、IS-IS PDUを他のタイプのパケットから分離し、IS-IS PDUをIS-ISプロトコル専用の入力キューに配置できます。
The IS-IS input queue then separates the IS-IS PDUs and directs them to an instance-specific processing queue. The instance-specific processing queue may then further separate the IS-IS PDUs by type (IIHs, SNPs, and LSPs) so that separate processing threads with varying priorities may be employed to process the incoming PDUs.
IS-IS入力キューは、IS-IS PDUを分離し、それらをインスタンス固有の処理キューに向けます。インスタンス固有の処理キューは、IS-IS PDUをタイプ（IIH、SNP、およびLSP）ごとにさらに分離し、さまざまな優先順位を持つ個別の処理スレッドを使用して、着信PDUを処理できるようにすることができます。
In such an architecture, it may be difficult for IS-IS in the control plane to determine what value should be advertised as a receive window.
このようなアーキテクチャでは、コントロールプレーンのIS-ISが受信ウィンドウとしてどの値を宣伝すべきかを決定することは困難かもしれません。
The following section describes an approach to congestion control based on performance measured by the transmitter without dependence on signaling from the receiver.
次のセクションでは、受信機からの信号に依存せずに送信機によって測定されたパフォーマンスに基づいた混雑制御へのアプローチについて説明します。
The approach described in this section does not depend upon direct signaling from the receiver. Instead, it adapts the transmission rate based on measurement of the actual rate of acknowledgments received.
このセクションで説明するアプローチは、受信機からの直接シグナル伝達に依存しません。代わりに、受け取った実際の謝辞率の測定に基づいて伝送速度を適応させます。
Flow control is not used by this approach. When congestion control is necessary, it can be implemented based on knowledge of the current flooding rate and the current acknowledgment rate. The algorithm used is a local matter. There is no requirement to standardize it, but there are a number of aspects that serve as guidelines that can be described. Algorithms based on this approach should follow the recommendations described below.
このアプローチでは、フロー制御は使用されません。輻輳制御が必要な場合、現在の洪水率と現在の確認率の知識に基づいて実装できます。使用されるアルゴリズムはローカルな問題です。それを標準化するための要件はありませんが、説明できるガイドラインとして機能する多くの側面があります。このアプローチに基づくアルゴリズムは、以下に説明する推奨事項に従う必要があります。
A maximum LSP transmission rate (LSPTxMax) should be configurable. This represents the fastest LSP transmission rate that will be attempted. This value should be applicable to all interfaces and should be consistent network wide.
最大LSP透過率（LSPTXMAX）は構成可能である必要があります。これは、試行される最速のLSP透過率を表します。この値はすべてのインターフェイスに適用できる必要があり、一貫したネットワークワイドである必要があります。
When the current rate of LSP transmission (LSPTxRate) exceeds the capabilities of the receiver, the congestion control algorithm needs to quickly and aggressively reduce the LSPTxRate. Slower responsiveness is likely to result in a larger number of retransmissions, which can introduce much longer delays in convergence.
LSP透過率（LSPTXRATE）の現在のレートが受信機の機能を超えると、混雑制御アルゴリズムはLSPTXRATEを迅速かつ積極的に削減する必要があります。応答性が遅くなると、より多くの再送信が発生する可能性が高く、収束にはるかに長い遅延が発生する可能性があります。
Dynamic increase of the rate of LSP transmission (LSPTxRate), i.e., making the rate faster, should be done less aggressively and only be done when the neighbor has demonstrated its ability to sustain the current LSPTxRate.
LSP透過率（LSPTXRATE）の速度の動的増加、つまり、速度をより速くする必要があり、積極的に行われ、隣人が現在のLSPTXRATEを維持する能力を実証した場合にのみ行われる必要があります。
The congestion control algorithm should not assume that the receive performance of a neighbor is static, i.e., it should handle transient conditions that result in a slower or faster receive rate on the part of a neighbor.
渋滞制御アルゴリズムは、隣人の受信パフォーマンスが静的であると仮定すべきではありません。つまり、隣人の側での受信率が遅くなるか、より速い速度をもたらす一時的な条件を処理する必要があります。
The congestion control algorithm should consider the expected delay time in receiving an acknowledgment. Therefore, it incorporates the neighbor partialSNPInterval (Section 4.5) to help determine whether acknowledgments are keeping pace with the rate of LSPs transmitted. In the absence of an advertisement of partialSNPInterval, a locally configured value can be used.
輻輳制御アルゴリズムは、謝辞を受信する際の予想される遅延時間を考慮する必要があります。したがって、近隣のpartialsnpinterval（セクション4.5）が組み込まれ、謝辞が送信されたLSPのレートに対応しているかどうかを判断するのに役立ちます。PartialSnpintervalの広告がない場合、ローカルで構成された値を使用できます。
IANA has made the following allocation in the "IS-IS Top-Level TLV Codepoints" registry.
IANAは、「IS-ISトップレベルのTLVコードポイント」レジストリで次の割り当てを行いました。
+=======+=========================+=====+=====+=====+=======+
| Value | Name | IIH | LSP | SNP | Purge |
+=======+=========================+=====+=====+=====+=======+
| 21 | Flooding Parameters TLV | y | n | y | n |
+-------+-------------------------+-----+-----+-----+-------+
Table 1
IANA has created the following sub-TLV registry in the "IS-IS TLV Codepoints" registry group.
IANAは、「IS-IS TLV CodePoints」レジストリグループに次のSUB-TLVレジストリを作成しました。
Name:
名前：
IS-IS Sub-TLVs for Flooding Parameters TLV
洪水パラメーターTLVのIS-ISサブTLV
Registration Procedure(s):
登録手続き：
Expert Review
専門家のレビュー
Description:
説明：
This registry defines sub-TLVs for the Flooding Parameters TLV (21).
このレジストリは、洪水パラメーターTLVのサブTLVを定義します（21）。
Reference:
参照：
RFC 9681
RFC 9681
+=======+===========================+
| Type | Description |
+=======+===========================+
| 0 | Reserved |
+-------+---------------------------+
| 1 | LSP Burst Size |
+-------+---------------------------+
| 2 | LSP Transmission Interval |
+-------+---------------------------+
| 3 | LSPs per PSNP |
+-------+---------------------------+
| 4 | Flags |
+-------+---------------------------+
| 5 | PSNP Interval |
+-------+---------------------------+
| 6 | Receive Window |
+-------+---------------------------+
| 7-255 | Unassigned |
+-------+---------------------------+
Table 2: Initial Sub-TLV Allocations for Flooding Parameters TLV
表2：洪水パラメーターTLVの初期サブTLV割り当て
IANA has created a new registry, in the "IS-IS TLV Codepoints" registry group, for assigning Flag bits advertised in the Flags sub-TLV.
IANAは、Flags sub-tlvに宣伝されているフラグビットを割り当てるために、「IS-IS TLV CODEPOINTS」レジストリグループに新しいレジストリを作成しました。
Name:
名前：
IS-IS Bit Values for Flooding Parameters Flags Sub-TLV
フラッディングパラメータフラグサブTLVのIS-ISビット値
Registration Procedure:
登録手順：
Expert Review
専門家のレビュー
Description:
説明：
This registry defines bit values for the Flags sub-TLV (4) advertised in the Flooding Parameters TLV (21).
このレジストリは、洪水パラメータTLV（21）で宣伝されているフラグサブTLV（4）のビット値を定義します。
Note:
注記：
In order to minimize encoding space, a new allocation should pick the smallest available value.
エンコーディングスペースを最小限に抑えるために、新しい割り当ては利用可能な最小値を選択する必要があります。
Reference:
参照：
RFC 9681
RFC 9681
+=======+=================================+
| Bit # | Description |
+=======+=================================+
| 0 | Ordered acknowledgment (O-flag) |
+-------+---------------------------------+
| 1-63 | Unassigned |
+-------+---------------------------------+
Table 3: Initial Bit Allocations for Flags Sub-TLV
表3：フラグサブTLVの初期ビット割り当て
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310]. These documents describe mechanisms that provide for the authentication and integrity of IS-IS PDUs, including SNPs and IIHs. These authentication mechanisms are not altered by this document.
IS-ISのセキュリティ上の懸念は、[ISO10589]、[RFC5304]、および[RFC5310]で対処されています。これらのドキュメントは、SNPおよびIIHを含むIS-IS PDUの認証と整合性を提供するメカニズムについて説明します。これらの認証メカニズムは、このドキュメントによって変更されません。
With the cryptographic mechanisms described in [RFC5304] and [RFC5310], an attacker wanting to advertise an incorrect Flooding Parameters TLV would have to first defeat these mechanisms.
[RFC5304]および[RFC5310]に記載されている暗号化メカニズムでは、誤った洪水パラメーターを宣伝したい攻撃者が最初にこれらのメカニズムを打ち負かす必要があります。
In the absence of cryptographic authentication, as IS-IS does not run over IP but directly over the link layer, it's considered difficult to inject a false SNP or IIH without having access to the link layer.
暗号化認証がない場合、IS-ISはIPではなくリンクレイヤーを直接実行するため、リンクレイヤーにアクセスせずに誤ったSNPまたはIIHを注入することは困難であると考えられています。
If a false SNP or IIH is sent with a Flooding Parameters TLV set to conservative values, the attacker can reduce the flooding speed between the two adjacent neighbors, which can result in LSDB inconsistencies and transient forwarding loops. However, it is not significantly different than filtering or altering LSPs, which would also be possible with access to the link layer. In addition, if the downstream flooding neighbor has multiple IGP neighbors (which is typically the case for reliability or topological reasons), it would receive LSPs at a regular speed from its other neighbors and hence would maintain LSDB consistency.
誤ったSNPまたはIIHが保守的な値に設定された洪水パラメーターTLVで送信されると、攻撃者は2人の隣接する隣人間の洪水速度を低下させることができ、LSDBの不一致と一時的な転送ループをもたらす可能性があります。ただし、LSPのフィルタリングまたは変更とは有意な差はありません。これは、リンクレイヤーへのアクセスでも可能です。さらに、下流の洪水の隣人が複数のIGP近傍を持っている場合（通常、信頼性またはトポロジカルな理由の場合は当てはまります）、他の隣人から通常の速度でLSPを受け取り、したがってLSDBの一貫性を維持します。
If a false SNP or IIH is sent with a Flooding Parameters TLV set to aggressive values, the attacker can increase the flooding speed, which can either overload a node or more likely cause loss of LSPs. However, it is not significantly different than sending many LSPs, which would also be possible with access to the link layer, even with cryptographic authentication enabled. In addition, IS-IS has procedures to detect the loss of LSPs and recover.
False SNPまたはIIHが攻撃的な値に設定された洪水パラメーターTLVで送信されると、攻撃者は洪水速度を上げることができます。ただし、暗号化認証が有効になっていても、リンクレイヤーへのアクセスを使用すると、多くのLSPを送信することと有意な差はありません。さらに、IS-ISには、LSPの損失を検出して回復する手順があります。
This TLV advertisement is not flooded across the network but only sent between adjacent IS-IS neighbors. This would limit the consequences in case of forged messages and also limit the dissemination of such information.
このTLV広告は、ネットワーク全体に浸水するのではなく、隣接するIS-IS近隣の間にのみ送信されます。これにより、鍛造メッセージの場合の結果が制限され、そのような情報の普及も制限されます。
[ISO10589] ISO/IEC, "Information technology - Telecommunications and
information exchange between systems - Intermediate system
to Intermediate system intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", Second Edition, ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
[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>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.
[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>.
[RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups",
RFC 2973, DOI 10.17487/RFC2973, October 2000,
<https://www.rfc-editor.org/info/rfc2973>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9667] Li, T., Ed., Psenak, P., Ed., Chen, H., Jalil, L., and S.
Dontula, "Dynamic Flooding on Dense Graphs", RFC 9667,
DOI 10.17487/RFC9667, October 2024,
<https://www.rfc-editor.org/info/rfc9667>.
The authors would like to thank Henk Smit, Sarah Chen, Xuesong Geng, Pierre Francois, Hannes Gredler, Acee Lindem, Mirja Kühlewind, Zaheduzzaman Sarker, and John Scudder for their reviews, comments, and suggestions.
著者は、ヘンクスミット、サラチェン、シュエンゴンゲ、ピエールフランソワ、ハンヌグレドラー、エーシーリンデム、ミルジャキュルウィンド、ザヘダッツザマンサルカー、ジョンスカダーにレビュー、コメント、提案に感謝します。
The authors would like to thank David Jacquet, Sarah Chen, and Qiangzhou Gao for the tests performed on commercial implementations and for their identification of some limiting factors.
著者は、商業実装で実行されたテストといくつかの制限要因の特定について、David Jacquet、Sarah Chen、およびQiangzhou Gaoに感謝したいと思います。
The following people gave substantial contributions to the content of this document and should be considered as coauthors:
次の人々は、この文書の内容に大きな貢献をし、共著者と見なされるべきです。
Jayesh J
Ciena
Email: jayesh.ietf@gmail.com
Chris Bowers
Juniper Networks
Email: cbowers@juniper.net
Peter Psenak
Cisco Systems
Email: ppsenak@cisco.com
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: ginsberg@cisco.com
Tony Li
Juniper Networks, Inc.
Email: tony.li@tony.li
Guillaume Solignac
Email: gsoligna@protonmail.com
Marek Karasek
Cisco Systems
Pujmanove 1753/10a, Prague 4 - Nusle
10 14000 Prague
Czech Republic
Email: mkarasek@cisco.com
Gunter Van de Velde
Nokia
Copernicuslaan 50
2018 Antwerp
Belgium
Email: gunter.van_de_velde@nokia.com
Tony Przygienda
Juniper
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: prz@juniper.net