[要約] RFC 8706は、IS-ISプロトコルの再起動シグナリングに関する仕様であり、IS-ISネットワークの再起動時にネットワークの状態を維持するためのメカニズムを提供します。目的は、ネットワークの再起動時にデータの損失を最小限に抑え、ネットワークの安定性と信頼性を向上させることです。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 8706 P. Wells
Obsoletes: 5306 Cisco Systems, Inc.
Category: Standards Track February 2020
ISSN: 2070-1721
Restart Signaling for IS-IS
IS-ISのシグナリングを再起動します
Abstract
概要
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.
このドキュメントでは、再起動中のルータが再起動中であることをネイバーに通知し、データベースの同期を正しく開始しながら、DOWN状態を循環せずに隣接関係を再確立できるようにするメカニズムについて説明します。
This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.
このドキュメントでは、フォワーディングプレーンの状態を維持しながら、再起動を開始する準備をしていることをルータにネイバーに通知するメカニズムについても説明します。これにより、ネイバーはルータが再起動するまで隣接関係を維持できますが、他のトポロジが変更された場合に隣接関係をダウンさせることもできます。
This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.
このドキュメントでは、再起動するルーターが近隣とのリンク状態プロトコルデータユニット（LSP）データベースの同期をいつ達成したかを判断するメカニズムと、ルーターの起動時に一時的なルーティングの中断を最小限に抑えながらLSPデータベースの同期を最適化するメカニズムについても説明します。
This document obsoletes RFC 5306.
このドキュメントはRFC 5306を廃止します。
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/rfc8706.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8706で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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. Overview 2. Conventions Used in This Document 2.1. Requirements Language 3. Approach 3.1. Timers 3.2. Restart TLV 3.2.1. Use of RR and RA Bits 3.2.2. Use of the SA Bit 3.2.3. Use of PR and PA Bits 3.3. Adjacency (Re)Acquisition 3.3.1. Adjacency Reacquisition during Restart 3.3.2. Adjacency Acquisition during Start 3.3.3. Multiple Levels 3.4. Database Synchronization 3.4.1. LSP Generation and Flooding and SPF Computation 4. State Tables 4.1. Running Router 4.2. Restarting Router 4.3. Starting Router 5. IANA Considerations 6. Security Considerations 7. Manageability Considerations 8. Normative References Appendix A. Summary of Changes from RFC 5306 Acknowledgements Authors' Addresses
1. 概要2.このドキュメントで使用される規則2.1。要件言語3.アプローチ3.1。タイマー3.2。 TLV 3.2.1を再起動します。 RRおよびRAビットの使用3.2.2。 SAビットの使用3.2.3。 PRおよびPAビットの使用3.3。隣接（再）取得3.3.1。再起動中の隣接の再取得3.3.2。開始時の隣接取得3.3.3。複数のレベル3.4。データベースの同期3.4.1。 LSP生成とフラッディングおよびSPF計算4.状態テーブル4.1。ルーター4.2の実行。ルーター4.3の再起動。ルーターの開始5. IANAの考慮事項6.セキュリティの考慮事項7.管理性の考慮事項8.規範的な参考資料付録A. RFC 5306からの変更点の概要作成者のアドレス
The Intermediate System to Intermediate System (IS-IS) routing protocol [RFC1195] [ISO10589] is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router.
Intermediate System to Intermediate System（IS-IS）ルーティングプロトコル[RFC1195] [ISO10589]は、リンク状態のドメイン内ルーティングプロトコルです。通常、IS-ISルーターが再起動されると、再起動ルーターと再起動ルーターのネイバーの両方でのイベントにより、ルーティングが一時的に中断されます。
The router that has been restarted computes its own routes before achieving database synchronization with its neighbors. The results of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain.
再起動されたルーターは、ネイバーとのデータベースの同期を達成する前に独自のルートを計算します。この計算の結果は、エリア/ドメイン内の他のルーターによって計算されたルートと収束しない可能性があります。
Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the DOWN state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes a temporary disruption of routes passing through the restarting router.
再起動ルータのネイバーは再起動イベントを検出し、DOWN状態を通じて再起動ルータとの隣接関係を循環させます。隣接状態の循環により、ネイバーは関係する隣接を記述するLSPを再生成します。これにより、再起動ルーターを通過するルートが一時的に中断されます。
In certain scenarios, the temporary disruption of the routes is highly undesirable. This document describes mechanisms to avoid or minimize the disruption due to both of these causes.
特定のシナリオでは、ルートの一時的な中断は非常に望ましくありません。このドキュメントでは、これらの両方の原因による中断を回避または最小限に抑えるメカニズムについて説明します。
When an adjacency is reinitialized as a result of a neighbor restarting, a router does three things:
ネイバーの再起動の結果として隣接関係が再初期化されると、ルーターは次の3つのことを行います。
1. It causes its own LSP(s) to be regenerated, thus triggering Shortest Path First (SPF) runs throughout the area (or in the case of Level 2, throughout the domain).
1. これにより、独自のLSPが再生成され、エリア全体（またはレベル2の場合はドメイン全体）の最短パス優先（SPF）実行がトリガーされます。
2. It sets SRMflags on its own LSP database on the adjacency concerned.
2. 関連する隣接の独自のLSPデータベースにSRMフラグを設定します。
3. In the case of a Point-to-Point link, it transmits a complete set of Complete Sequence Number PDUs (CSNPs), over the adjacency.
3. ポイントツーポイントリンクの場合は、隣接を介して完全なシーケンス番号PDU（CSNP）の完全なセットを送信します。
In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database.
ルータプロセスを再起動する場合、最初のプロセスは非常に望ましくありませんが、LSPデータベースの同期を確実にするために2番目のプロセスは不可欠です。
The third action above minimizes the number of LSPs that must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether or not the router is being restarted (so that the overload bit can be cleared in the router's own LSP, for example).
上記の3番目のアクションは、交換する必要のあるLSPの数を最小限に抑え、信頼できる場合は、隣接するルーターのLSPデータベースがいつ同期されたかを判断する手段を提供します。これは、ルータが再起動されているかどうかに関係なく望ましいです（たとえば、ルータ自体のLSPで過負荷ビットをクリアできるようにするため）。
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting. The mechanism further allows the neighbors to reestablish their adjacencies with the restarting router without cycling through the DOWN state while still correctly initiating database synchronization.
このドキュメントでは、再起動中のルーターが再起動中であることをルーターに通知するメカニズムについて説明します。このメカニズムにより、ネイバーは、データベースの同期を正しく開始しながら、DOWN状態を循環することなく、再起動するルーターとの隣接関係を再確立できます。
This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts.
このドキュメントでは、再起動するルーターが近隣とのLSPデータベース同期をいつ達成したかを判断するメカニズムと、LSPデータベース同期を最適化し、ルーターの起動時に一時的なルーティングの中断を最小限に抑えるメカニズムについても説明します。
It is assumed that the three-way handshake [RFC5303] is being used on Point-to-Point circuits.
3ウェイハンドシェイク[RFC5303]がポイントツーポイント回線で使用されていると想定しています。
If the control and forwarding functions in a router can be maintained independently, it is possible for the forwarding function state to be maintained across a resumption of control function operations. This functionality is assumed when the terms "restart/restarting" are used in this document.
ルーターの制御機能と転送機能を個別に維持できる場合、制御機能の操作を再開しても転送機能の状態を維持できます。このドキュメントで「再起動/再起動」という用語が使用されている場合、この機能が想定されます。
The terms "start/starting" are used to refer to a router in which the control function has either commenced operations for the first time or has resumed operations, but the forwarding functions have not been maintained in a prior state.
「開始/開始」という用語は、制御機能が最初に操作を開始したか、操作を再開したが、転送機能が以前の状態に維持されていないルーターを指すために使用されます。
The terms "(re)start/(re)starting" are used when the text is applicable to both a "starting" and a "restarting" router.
「（再）開始/（再）開始」という用語は、テキストが「開始」ルーターと「再開始」ルーターの両方に適用できる場合に使用されます。
The terms "normal IIH" or "IIH normal" refer to IS-IS Hellos (IIHs) in which the Restart TLV (defined later in this document) has no flags set.
「通常のIIH」または「IIH通常」という用語は、Restart TLV（このドキュメントの後半で定義）にフラグが設定されていないIS-IS Hello（IIH）を指します。
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]で説明されているように解釈されます。
Three additional timers (T1, T2, and T3) are required to support the mechanisms defined in this document. Timers T1 and T2 are used both by a restarting router and a starting router. Timer T3 is used only by a restarting router.
このドキュメントで定義されているメカニズムをサポートするには、3つの追加タイマー（T1、T2、およびT3）が必要です。タイマーT1とT2は、再起動ルーターと起動ルーターの両方で使用されます。タイマーT3は、再起動ルーターでのみ使用されます。
NOTE: These timers are NOT applicable to a router that is preparing to do a planned restart.
注：これらのタイマーは、計画的な再起動を実行する準備をしているルーターには適用されません。
An instance of the timer T1 is maintained per interface and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value is 3 seconds.
タイマーT1のインスタンスはインターフェイスごとに維持され、確認されていない（再）開始試行が繰り返されるまでの時間を示します。一般的な値は3秒です。
An instance of the timer T2 is maintained for each LSP database (LSPDB) present in the system. For example, for a Level 1/2 system, there will be an instance of the timer T2 for Level 1 and an instance for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value is 60 seconds.
タイマーT2のインスタンスは、システムに存在する各LSPデータベース（LSPDB）に対して維持されます。たとえば、レベル1/2システムの場合、レベル1のタイマーT2のインスタンスとレベル2のインスタンスがあります。これは、システムがLSPDB同期を待機する最大時間です。典型的な値は60秒です。
A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds but is set to the minimum of the remaining times of received IIHs containing a Restart TLV with the Restart Acknowledgement (RA) set and an indication that the neighbor has an adjacency in the UP state to the restarting router. (See item a in Section 3.2.1.)
タイマーT3の単一インスタンスは、システム全体で維持されます。これは、ルータがデータベースの同期を達成できなかったと宣言するまでの時間を示します（独自のLSPで過負荷ビットを設定することにより）。これは65535秒に初期化されますが、Restart Acknowledgment（RA）が設定されたRestart TLVを含む受信IIHの残り時間の最小値に設定され、ネイバーが再起動ルーターへのUP状態の隣接関係を持っていることを示します。 （セクション3.2.1の項目aを参照してください。）
A new TLV is defined to be included in IIH PDUs. The TLV includes flags that are used to convey information during a (re)start. The absence of this TLV indicates that the sender supports none of the functionality defined in this document. Therefore, if a router supports any of the functionality defined in this document it MUST include this TLV in all transmitted IIHs.
IIH PDUに含まれる新しいTLVが定義されています。 TLVには、（再）起動中に情報を伝達するために使用されるフラグが含まれています。このTLVがないことは、送信者がこのドキュメントで定義されている機能をサポートしていないことを示しています。したがって、ルーターがこのドキュメントで定義されている機能のいずれかをサポートしている場合、送信されるすべてのIIHにこのTLVを含める必要があります。
Type: 211
タイプ：211
Length: Number of octets in the Value field (1 to (3 + ID Length))
長さ：[値]フィールドのオクテット数（1〜（3 + IDの長さ））
Value:
No. of octets
+-----------------------+
| Flags | 1
+-----------------------+
| Remaining Time | 2
+-----------------------+
| Restarting Neighbor ID| ID Length
+-----------------------+
Flags (1 octet)
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|Reserved|PA|PR|SA|RA|RR|
+--+--+--+--+--+--+--+--+
RR - Restart Request RA - Restart Acknowledgement SA - Suppress adjacency advertisement PR - Restart is planned PA - Planned restart acknowledgement
RR-再起動要求RA-再起動確認SA-隣接広告の抑制PR-再起動が計画されているPA-計画された再起動の確認
Remaining Time (2 octets) Remaining Holding Time (in seconds).
残り時間（2オクテット）残り保持時間（秒単位）。
Required when the RA, PR, or PA bit is set. Otherwise, this field SHOULD be omitted when sent and MUST be ignored when received.
RA、PR、またはPAビットが設定されている場合に必要です。それ以外の場合、このフィールドは送信時に省略し、受信時に無視する必要があります（SHOULD）。
Restarting Neighbor System ID (ID Length octets) The System ID of the neighbor to which an RA/PA refers.
再起動ネイバーシステムID（ID長オクテット）RA / PAが参照するネイバーのシステムID。
Required when the RA or PA bit is set. Otherwise, this field SHOULD be omitted when sent and MUST be ignored when received.
RAまたはPAビットが設定されている場合に必要です。それ以外の場合、このフィールドは送信時に省略し、受信時に無視する必要があります（SHOULD）。
Note: Very early draft versions of the restart functionality did not include the Restarting Neighbor System ID in the TLV. RFC 5306 allowed for the possibility of interoperating with legacy implementations by stating that a router that is expecting an RA on a LAN circuit should assume that the acknowledgement is directed at the local system if the TLV is received with RA set and Restarting Neighbor System ID is not present. It is an implementation choice whether to continue to accept (on a LAN) a TLV with RA set and Restarting Neighbor System ID absent. Note that the omission of the Restarting Neighbor System ID only introduces ambiguity in the case where there are multiple systems on a LAN simultaneously performing restart.
注：再起動機能の非常に初期のドラフトバージョンでは、TLVに再起動ネイバーシステムIDが含まれていませんでした。 RFC 5306では、LAN回線でRAを期待しているルーターは、RAが設定されたTLVを受信し、Restarting Neighbor System IDが受信された場合、ローカルシステムで確認応答が送信されると想定する必要があると述べ、レガシー実装と相互運用する可能性を許容現在ではない。これは、RAが設定され、Restarting Neighbor System IDが存在しないTLVを（LAN上で）引き続き受け入れるかどうかの実装上の選択です。再起動を行う隣接システムIDを省略しても、LAN上に複数のシステムが同時に再起動を実行している場合にのみ曖昧さが生じることに注意してください。
The RR and SA flags may both be set in the TLV under the conditions described in Section 3.3.2. All other combinations where multiple flags are set are invalid and MUST NOT be transmitted. Received TLVs that have invalid flag combinations set MUST be ignored.
RRフラグとSAフラグは、セクション3.3.2で説明されている条件下でTLVに設定できます。複数のフラグが設定されている他のすべての組み合わせは無効であり、送信してはなりません。無効なフラグの組み合わせが設定されている受信TLVは無視する必要があります。
The RR bit is used by a (re)starting router to signal to its neighbors that a (re)start is in progress, that an existing adjacency SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of the SRMflags.
RRビットは、（再）開始ルータが（再）開始が進行中であることを隣接ノードに通知するために使用されます。隣接状態マシンの通常の操作で隣接が必要な状況下でも、既存の隣接を維持する必要があります（SHOULD）。再初期化され、一連のCSNPを要求し、SRMフラグの設定を要求します。
The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a Restart TLV with the RR bit set.
RAビットは、RRビットが設定された再起動TLVの受信を確認するために、（再）起動ルータのネイバーによって送信されます。
When the neighbor of a (re)starting router receives an IIH with the Restart TLV having the RR bit set, if there exists on this interface an adjacency in the UP state with the same System ID and, in the case of a LAN circuit, with the same source LAN address, then irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits) or the "Point-to-Point Three-Way Adjacency" option (Point-to-Point circuits):
（再）開始ルータのネイバーが、RRビットが設定されたRestart TLVを使用してIIHを受信したときに、このインターフェイス上に同じシステムIDを持つUP状態の隣接が存在する場合、LAN回線の場合は、同じ送信元LANアドレスの場合、「中間システムネイバー」オプション（LAN回線）または「ポイントツーポイント3方向隣接」オプション（ポイントツーポイント回線）の他の内容に関係なく、次のようになります。
a. the state of the adjacency is not changed. If this is the first IIH with the RR bit set that this system has received associated with this adjacency, then the adjacency is marked as being in "Restart mode" and the adjacency Holding Time is refreshed -- otherwise, the Holding Time is not refreshed. The Remaining Time transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of an IIH with the RR bit reset will clear the "Restart mode" state. This procedure allows the restarting router to cause the neighbor to maintain the adjacency long enough for restart to successfully complete while also preventing repetitive restarts from maintaining an adjacency indefinitely. Whether or not an adjacency is marked as being in "Restart mode" has no effect on adjacency state transitions.
a. 隣接の状態は変更されません。これがこの隣接に関連してこのシステムが受信したRRビットが設定された最初のIIHである場合、隣接は「再起動モード」にあるとマークされ、隣接の保持時間が更新されます。それ以外の場合、保持時間は更新されません。 。以下の（b）に従って送信された残り時間は、隣接が期限切れになる実際の時間を反映する必要があります。 RRビットをリセットしてIIHを受信すると、「再起動モード」状態がクリアされます。この手順により、再起動ルータは、再起動が正常に完了するまでネイバーが隣接関係を維持できるようにし、繰り返し再起動が隣接関係を無期限に維持するのを防ぎます。隣接関係が「再起動モード」にあるとマークされているかどうかは、隣接関係の状態遷移には影響しません。
b. immediately (i.e., without waiting for any currently running timer interval to expire but with a small random delay of a few tens of milliseconds on LANs to avoid "storms") transmit over the corresponding interface an IIH including the Restart TLV with the RR bit clear and the RA bit set, in the case of Point-to-Point adjacencies having updated the "Point-to-Point Three-Way Adjacency" option to reflect any new values received from the (re)starting router. (This allows a restarting router to quickly acquire the correct information to place in its hellos.) The Remaining Time MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of the router from which the IIH with the RR bit set was received. This is required to correctly associate the acknowledgement and Holding Time in the case where multiple systems on a LAN restart at approximately the same time. This IIH SHOULD be transmitted before any LSPs or SNPs are transmitted as a result of the receipt of the original IIH.
b. 即時に（つまり、現在実行中のタイマー間隔が期限切れになるのを待たずに、「ストーム」を回避するためにLANで数十ミリ秒の小さなランダム遅延が発生する）RRビットがクリアされた再起動TLVを含むIIHを対応するインターフェイス経由で送信するポイントツーポイント隣接が「（ポイント）ポイントスリーウェイ隣接」オプションを更新して、（再）開始ルータから受信した新しい値を反映するように設定されている場合は、RAビットセット。 （これにより、再起動ルーターはhelloに配置する正しい情報をすばやく取得できます。）この隣接の保持タイマーが期限切れになる前に、残り時間を現在の時間（秒単位）に設定する必要があります。対応するインターフェイスがLANインターフェイスである場合、Restarting Neighbor System IDは、RRビットが設定されたIIHを受信したルーターのシステムIDに設定する必要があります（SHOULD）。これは、LAN上の複数のシステムがほぼ同時に再起動する場合に、確認応答と保持時間を正しく関連付けるために必要です。このIIHは、元のIIHの受信の結果としてLSPまたはSNPが送信される前に送信する必要があります（SHOULD）。
c. if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with the highest source Media Access Control (MAC) address breaking ties) among those routers to which the receiving router has an adjacency in the UP state on this interface whose IIHs contain the Restart TLV, excluding adjacencies to all routers that are considered in "Restart mode" (note the actual Designated Intermediate System (DIS) is NOT changed by this process), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database.
c. 対応するインターフェースがポイントツーポイントインターフェースである場合、または受信ルーターがLnRouterPriorityを持っている場合（送信元メディアアクセス制御（MAC）のアドレスの関連付けが最も高い）、受信ルーターが隣接しているルーターの中でIIHに再起動TLVが含まれるこのインターフェイスのUP状態。「再起動モード」と見なされるすべてのルーターへの隣接を除く（実際の指定中間システム（DIS）はこのプロセスによって変更されないことに注意）。対応するインターフェイスを介して送信を開始します。 CSNPの完全なセット、およびローカルLSPデータベース内のすべてのLSPの対応するインターフェイスにSRMflagsを設定します。
Otherwise (i.e., if there was no adjacency in the UP state to the System ID in question), process the IIH as normal by reinitializing the adjacency and setting the RA bit in the returned IIH.
それ以外の場合（つまり、問題のシステムIDに対するUP状態で隣接関係がなかった場合）、隣接関係を再初期化し、返されたIIHにRAビットを設定することにより、IIHを通常どおり処理します。
The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs.
SAビットは、開始ルーターがその隣接ルーターに、隣接ルーターのLSP内の開始ルーターへの隣接関係のアドバタイズメントを抑制するよう要求するために使用されます。
A router that is starting has no maintained forwarding function state. This may or may not be the first time the router has started. If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network. These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router. This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers. The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations.
起動中のルーターには、転送機能の状態が維持されていません。これは、ルーターが初めて起動した場合とそうでない場合があります。ルーターが初めて起動されたのではない場合、このルーターによって以前の具体化で生成されたLSPのコピーが、ネットワーク内の他のルーターのLSPデータベースに存在する可能性があります。これらのコピーは、開始ルーターによるLSPフラグメントシーケンス番号の再初期化により、開始ルーターによって最初に生成されたLSPよりも「新しい」ように見える可能性があります。これにより、更新プロセスの通常の操作によって開始ルーターがシーケンス番号の大きい独自のLSPのコピーを再生成してフラッディングするまで、一時的なブラックホールが発生する可能性があります。開始ルータが以前のインカネーションによって生成されたLSPの新しいバージョンを伝播できるまで、開始ルータのネイバーが開始ルータへの隣接のアドバタイズを抑制する場合、一時的なブラックホールを回避できます。
When a router receives an IIH with the Restart TLV having the SA bit set, if there exists on this interface an adjacency in the UP state with the same System ID and, in the case of a LAN circuit, with the same source LAN address, then the router MUST suppress advertisement of the adjacency to the neighbor in its own LSPs. Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed. If the adjacency transitions to the UP state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received.
SAビットが設定された再起動TLVを使用してルータがIIHを受信したときに、このインターフェイスにUP状態の隣接が存在し、同じシステムIDがあり、LAN回線の場合は、同じ送信元LANアドレスがある場合、次に、ルータは自身のLSP内のネイバーへの隣接のアドバタイズを抑制しなければなりません（MUST）。 SAビットがクリアされたIIHが受信されるまで、ネイバーアドバタイズメントは抑制され続ける必要があります。隣接関係がUP状態に移行する場合、SAビットがクリアされたIIHを受信するまで、新しい隣接関係をアドバタイズしてはなりません（MUST NOT）。
Note that a router that suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation. In particular, if an implementation follows the example guidelines presented in [ISO10589], Annex C.2.5, Step 0:b) "pre-load TENT with the local adjacency database", the suppressed adjacency MUST NOT be loaded into TENT.
隣接のアドバタイズを抑制するルータは、SPF計算を実行するときにこの隣接を使用してはならないことに注意してください。特に、実装が[ISO10589]、付録C.2.5、ステップ0：b）「ローカル隣接データベースを使用してTENTを事前ロードする」に示されているガイドラインの例に従っている場合、抑制された隣接をTENTにロードしてはなりません。
The PR bit is used by a router that is planning to initiate a restart to signal to its neighbors that it will be restarting. The router sending an IIH with PR bit set SHOULD set the Remaining Time to a value greater than the expected control-plane restart time. The PR bit SHOULD remain set in IIHs until the restart is initiated.
PRビットは、再起動を開始することを計画しているルーターが、再起動することを近隣に通知するために使用します。 PRビットが設定されたIIHを送信するルーターは、残り時間を予想されるコントロールプレーン再起動時間よりも大きい値に設定する必要があります（SHOULD）。再起動が開始されるまで、PRビットはIIHに設定されたままである必要があります（SHOULD）。
The PA bit is sent by the neighbor of a router planning to restart to acknowledge receipt of a Restart TLV with the PR bit set.
PAビットは、PRビットが設定された再起動TLVの受信を確認するために再起動を計画しているルータのネイバーによって送信されます。
When the neighbor of a router planning a restart receives an IIH with the Restart TLV having the PR bit set, if there exists on this interface an adjacency in the UP state with the same System ID and, in the case of a LAN circuit, with the same source LAN address, then:
再起動を計画しているルータのネイバーが、PRビットが設定された再起動TLVを使用してIIHを受信したときに、このインターフェイス上に同じシステムIDを持つUP状態の隣接が存在し、LAN回線の場合は、同じ送信元LANアドレス、次に：
a. if this is the first IIH with the PR bit set that this system has received associated with this adjacency, then the adjacency is marked as being in Planned Restart State and the adjacency Holding Time is refreshed -- otherwise, the Holding Time is not refreshed. The Holding Time SHOULD be set to the Remaining Time specified in the received IIH with PR set. The Remaining Time transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of an IIH with the PR bit reset will clear the Planned Restart State and cause the receiving router to set the adjacency Holding Time to the locally configured value. This procedure allows the router planning a restart to cause the neighbor to maintain the adjacency long enough for restart to successfully complete. Whether or not an adjacency is marked as being in Planned Restart State has no effect on adjacency state transitions.
a. これがこの隣接に関連してこのシステムが受信したPRビットが設定された最初のIIHである場合、隣接は計画再起動状態にあるとマークされ、隣接の保持時間が更新されます。それ以外の場合、保持時間は更新されません。保持時間は、PRが設定された受信IIHで指定された残り時間に設定する必要があります（SHOULD）。以下の（b）に従って送信される残り時間は、隣接関係が期限切れになる実際の時間を反映する必要があります。 PRビットをリセットしてIIHを受信すると、計画された再起動状態がクリアされ、受信側ルーターが隣接保持時間をローカルに構成された値に設定します。この手順により、ルータは再起動を計画して、再起動が正常に完了するのに十分な時間、隣接ルータに隣接関係を維持させることができます。隣接が計画再起動状態にあるとマークされているかどうかは、隣接状態の遷移には影響しません。
b. immediately (i.e., without waiting for any currently running timer interval to expire, but with a small random delay of a few tens of milliseconds on LANs to avoid "storms") transmit over the corresponding interface an IIH including the Restart TLV with the PR bit clear and the PA bit set. The Remaining Time MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of the router from which the IIH with the PR bit set was received. This is required to correctly associate the acknowledgement and Holding Time in the case where multiple systems on a LAN are planning a restart at approximately the same time.
b. 即座に（つまり、現在実行中のタイマー間隔が切れるのを待たずに、ただし「ストーム」を回避するためにLANで数十ミリ秒の小さなランダム遅延を使用して）、PRビット付きの再起動TLVを含むIIHを対応するインターフェイス経由で送信するクリアしてPAビットをセットします。残り時間は、この隣接の保持タイマーが期限切れになる前の現在の時間（秒単位）に設定する必要があります。対応するインターフェイスがLANインターフェイスである場合、Restarting Neighbor System IDは、PRビットが設定されたIIHを受信したルーターのシステムIDに設定する必要があります（SHOULD）。これは、LAN上の複数のシステムがほぼ同時に再起動を計画している場合に、確認応答と保持時間を正しく関連付けるために必要です。
NOTE: Receipt of an IIH with PA bit set indicates to the router planning a restart that the neighbor is aware of the planned restart and -- in the absence of topology changes as described below -- will maintain the adjacency for the Remaining Time included in the IIH with PA set.
注：PAビットが設定されたIIHを受信すると、再起動を計画しているルーターに、ネイバーが計画された再起動を認識していることを示し、以下に説明するトポロジ変更がない場合は、含まれる残り時間の隣接を維持しますPAが設定されたIIH。
By definition, a restarting router maintains forwarding state across the control-plane restart (see Section 2). But while a control-plane restart is in progress, it is expected that the restarting router will be unable to respond to topology changes. It is therefore useful to signal a planned restart so that the neighbors of the restarting router can determine whether it is safe to maintain the adjacency if other topology changes occur prior to the completion of the restart. Signaling a planned restart in the absence of maintained forwarding-plane state is likely to lead to significant traffic loss and MUST NOT be done.
定義上、再起動するルーターは、コントロールプレーンの再起動中も転送状態を維持します（セクション2を参照）。ただし、コントロールプレーンの再起動中は、再起動中のルーターがトポロジの変更に応答できないことが予想されます。したがって、再起動が完了する前に他のトポロジの変更が発生した場合に、再起動ルータのネイバーが隣接関係を維持しても安全かどうかを判断できるように、計画的な再起動を通知することは有用です。フォワーディングプレーンの状態が維持されていない場合に計画的な再起動を通知すると、トラフィックが大幅に失われる可能性があり、実行してはなりません。
Neighbors of the router that have signaled planned restart SHOULD maintain the adjacency in a Planned Restart State until it receives an IIH with the RR bit set, it receives an IIH with both PR and RR bits clear, or the adjacency Holding Time expires -- whichever occurs first. Neighbors that choose not to follow the recommended behavior need to consider the impact on traffic delivery of not using the restarting router for forwarding traffic during the restart period.
計画された再起動を通知したルータのネイバーは、RRビットが設定されたIIHを受信するか、PRビットとRRビットの両方がクリアされたIIHを受信するか、隣接関係の保持時間が期限切れになるまで、隣接関係を計画された再起動状態に維持する必要があります（SHOULD）。最初に発生します。推奨される動作を行わないことを選択したネイバーは、再起動期間中にトラフィックの転送に再起動ルーターを使用しないことによるトラフィック配信への影響を考慮する必要があります。
While the adjacency is in Planned Restart State, some or all of the following actions MAY be taken:
隣接関係が計画された再起動状態にある間、以下のアクションの一部またはすべてが実行される場合があります。
a. If additional topology changes occur, the adjacency that is in Planned Restart State MAY be brought down even though the Holding Time has not yet expired. Given that the neighbor that has signaled a planned restart is not expected to update its forwarding plane in response to signaling of the topology changes (since it is restarting) traffic that transits that node is at risk of being improperly forwarded. On a LAN circuit, if the router in Planned Restart State is the DIS at any supported level, the adjacency or adjacencies SHOULD be brought down whenever any LSP update is either generated or received so as to trigger a new DIS election. Failure to do so will compromise the reliability of the update process on that circuit. What other criteria are used to determine what topology changes will trigger bringing the adjacency down is a local implementation decision.
a. 追加のトポロジ変更が発生した場合、保持時間がまだ経過していない場合でも、計画再起動状態にある隣接がダウンする場合があります。計画された再起動を通知したネイバーは、トポロジー変更の通知に応じて転送プレーンを更新することが期待されていないため（再起動のため）、そのノードを通過するトラフィックは不適切に転送されるリスクがあります。 LAN回線では、Planned Restart StateのルーターがサポートされているいずれかのレベルのDISである場合、新しいDIS選出をトリガーするためにLSP更新が生成または受信されるたびに、隣接関係を停止する必要があります。そうしないと、その回路の更新プロセスの信頼性が低下します。トポロジの変更によって隣接関係がダウンする原因となる他の基準を決定するのは、ローカル実装の決定です。
b. If a Bidirectional Forwarding Detection (BFD) [RFC5880] Session to the neighbor that signals a planned restart is in the UP state and subsequently goes down, the event MAY be ignored since it is possible this is an expected side effect of the restart. Use of the Control-Plane Independent state as signaled in BFD control packets SHOULD be considered in the decision to ignore a BFD Session DOWN event.
b. Bidirectional Forwarding Detection（BFD）[RFC5880]計画された再起動を通知するネイバーへのセッションがUP状態であり、その後ダウンした場合、これは再起動の予期される副作用である可能性があるため、イベントは無視される可能性があります。 BFDコントロールパケットで通知されたコントロールプレーン非依存状態の使用は、BFDセッションダウンイベントを無視する決定で考慮されるべきです。
c. On a Point-to-Point circuit, transmission of LSPs, CSNPs, and Partial Sequence Number PDU (PSNPs) MAY be suppressed. It is expected that the PDUs will not be received.
c. ポイントツーポイント回線では、LSP、CSNP、および部分シーケンス番号PDU（PSNP）の送信が抑制される場合があります。 PDUが受信されないことが予想されます。
Use of the PR bit provides a means to safely support restart periods that are significantly longer than standard Holding Times.
PRビットを使用すると、標準の保持時間より大幅に長い再起動期間を安全にサポートする手段が提供されます。
Adjacency (re)acquisition is the first step in (re)initialization. Restarting and starting routers will make use of the RR bit in the Restart TLV, though each will use it at different stages of the (re)start procedure.
隣接（再）獲得は、（再）初期化の最初のステップです。ルーターの再起動と起動は、再起動TLVのRRビットを使用しますが、それぞれが（再）起動手順のさまざまな段階で使用します。
The restarting router explicitly notifies its neighbor that the adjacency is being reacquired and, hence, that it SHOULD NOT reinitialize the adjacency. This is achieved by setting the RR bit in the Restart TLV. When the neighbor of a restarting router receives an IIH with the Restart TLV having the RR bit set, if there exists on this interface an adjacency in the UP state with the same System ID and, in the case of a LAN circuit, with the same source LAN address, then the procedures described in Section 3.2.1 are followed.
再起動ルータは、隣接関係が再取得されていること、したがって隣接関係を再初期化してはならないことをネイバーに明示的に通知します。これは、再起動TLVのRRビットを設定することで実現されます。再起動ルータのネイバーが、RRビットが設定された再起動TLVを使用してIIHを受信したときに、このインターフェイス上に同じシステムIDを持つUP状態の隣接が存在する場合、LAN回線の場合、同じ送信元LANアドレスの場合、セクション3.2.1で説明されている手順に従います。
A router that does not support the restart capability will ignore the Restart TLV and reinitialize the adjacency as normal, returning an IIH without the Restart TLV.
再起動機能をサポートしないルーターは、再起動TLVを無視し、通常どおり隣接関係を再初期化して、再起動TLVなしでIIHを返します。
On restarting, a router initializes the timer T3, starts the timer T2 for each LSPDB, and for each interface (and in the case of a LAN circuit, for each level) starts the timer T1 and transmits an IIH containing the Restart TLV with the RR bit set.
再起動時に、ルータはタイマーT3を初期化し、各LSPDBのタイマーT2を開始し、各インターフェイス（およびLAN回線の場合は各レベル）がタイマーT1を開始し、再起動TLVを含むIIHを送信します。 RRビットセット。
On a Point-to-Point circuit, the restarting router SHOULD set the "Adjacency Three-Way State" to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter the UP state immediately.
ポイントツーポイント回線では、再起動ルーターは、「隣接スリーウェイステート」を「初期化」に設定する必要があります。これは、確認応答IIH（RAセット付き）を受信すると、隣接がすぐにUP状態になる必要があるためです。
On a LAN circuit, the LAN-ID assigned to the circuit SHOULD be the same as that used prior to the restart. In particular, for any circuits for which the restarting router was previously DIS, the use of a different LAN-ID would necessitate the generation of a new set of pseudonode LSPs and corresponding changes in all the LSPs referencing them from other routers on the LAN. By preserving the LAN-ID across the restart, this churn can be prevented. To enable a restarting router to learn the LAN-ID used prior to restart, the LAN-ID specified in an IIH with RR set MUST be ignored.
LAN回線では、回線に割り当てられたLAN-IDは、再起動前に使用されたものと同じである必要があります（SHOULD）。特に、以前はDISを再起動していた回線の場合、別のLAN-IDを使用すると、新しい擬似ノードLSPのセットを生成し、LAN上の他のルーターからそれらを参照するすべてのLSPに対応する変更を加える必要があります。再起動後もLAN-IDを保持することにより、このチャーンを防ぐことができます。再起動ルーターが再起動前に使用されたLAN-IDを学習できるようにするには、RRが設定されたIIHで指定されたLAN-IDを無視する必要があります。
Transmission of "normal IIHs" is inhibited until the conditions described below are met (in order to avoid causing an unnecessary adjacency initialization). Upon expiry of the timer T1, it is restarted and the IIH is retransmitted as above.
「通常のIIH」の送信は、以下に説明する条件が満たされるまで禁止されます（不必要な隣接関係の初期化を引き起こさないようにするため）。タイマーT1が満了すると、タイマーが再起動され、IIHが上記のように再送信されます。
When a restarting router receives an IIH a local adjacency is established as usual, and if the IIH contains a Restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID that matches that of the local system), the receipt of the acknowledgement over that interface is noted. When the RA bit is set and the state of the remote adjacency is UP, then the timer T3 is set to the minimum of its current value and the value of the Remaining Time field in the received IIH.
再起動ルーターがIIHを受信すると、通常どおりローカル隣接関係が確立され、IIHにRAビットが設定された再起動TLV（およびローカルシステムの再起動隣接システムIDと一致する再起動隣接システムIDを持つLAN回路）が含まれている場合、受信そのインターフェース上での確認応答が記録されます。 RAビットが設定され、リモート隣接の状態がUPの場合、タイマーT3は、現在の値と受信したIIHの残り時間フィールドの値の最小値に設定されます。
On a Point-to-Point link, receipt of an IIH not containing the Restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is canceled immediately without waiting for a complete set of CSNPs. Synchronization may therefore be deemed complete even though there are some LSPs that are held (only) by this neighbor (see Section 3.4). In this case, we also want to be certain that the neighbor will reinitialize the adjacency in order to guarantee that the SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. This is guaranteed to happen except in the case where the Adjacency Three-Way State in the received IIH is UP and the Neighbor Extended Local Circuit ID matches the Extended Local Circuit ID assigned by the restarting router. In this case, the restarting router MUST force the adjacency to reinitialize by setting the local Adjacency Three-Way State to DOWN and sending a normal IIH.
ポイントツーポイントリンクでは、Restart TLVを含まないIIHの受信も、ネイバーが再起動可能ではないことを示すため、確認応答として扱われます。ただし、このインターフェイスでCSNPを受信することが保証されていないため、タイマーT1は、CSNPの完全なセットを待たずにすぐにキャンセルされます。したがって、このネイバーによって保持されている（のみ）LSPがいくつかある場合でも、同期は完了したと見なされる場合があります（セクション3.4を参照）。この場合、SRMフラグがデータベースに設定されていることを保証するために、ネイバーが隣接関係を再初期化して、最終的なLSPDB同期を確実にすることも確認します。これは、受信したIIHの隣接スリーウェイステートがUPで、ネイバー拡張ローカルサーキットIDが、再起動ルータによって割り当てられた拡張ローカルサーキットIDと一致する場合を除いて、必ず発生します。この場合、再起動ルーターは、ローカルの隣接3状態をDOWNに設定して通常のIIHを送信することにより、隣接を強制的に再初期化する必要があります。
In the case of a LAN interface, receipt of an IIH not containing the Restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore, T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries.
LANインターフェイスの場合、再起動TLVを含まないIIHの受信は、LAN上の少なくとも1つの非再起動隣接ルーターが再起動をサポートしている限り、同期が発生する可能性があるため、顕著ではありません。したがって、この場合、T1は引き続き実行されます。 LAN上のどのネイバーも再起動に対応していない場合、T1はローカルで定義された回数の再試行後に最終的に期限切れになります。
In the case of a Point-to-Point circuit, the LocalCircuitID and Extended Local Circuit ID information contained in the IIH can be used immediately to generate an IIH containing the correct three-way handshake information. The presence of Neighbor Extended Local Circuit ID information that does not match the value currently in use by the local system is ignored (since the IIH may have been transmitted before the neighbor had received the new value from the restarting router), but the adjacency remains in the initializing state until the correct information is received.
ポイントツーポイント回線の場合、IIHに含まれるLocalCircuitIDおよび拡張ローカル回線ID情報をすぐに使用して、正しい3ウェイハンドシェイク情報を含むIIHを生成できます。ローカルシステムで現在使用されている値と一致しないネイバー拡張ローカルサーキットID情報の存在は無視されます（ネイバーが再起動ルーターから新しい値を受信する前にIIHが送信された可能性があるため）が、隣接関係は残っています正しい情報が受信されるまで、初期化状態のままです。
In the case of a LAN circuit, the source neighbor information (e.g., SNPAAddress) is recorded and used for adjacency establishment and maintenance as normal.
LAN回線の場合、送信元ネイバー情報（SNPAAddressなど）が記録され、通常どおり隣接関係の確立とメンテナンスに使用されます。
When BOTH a complete set of CSNPs (for each active level, in the case of a Point-to-Point circuit) and an acknowledgement have been received over the interface, the timer T1 is canceled.
CSNPの完全なセット（ポイントツーポイント回線の場合は、アクティブレベルごと）と確認応答の両方がインターフェイスを介して受信されると、タイマーT1がキャンセルされます。
Once the timer T1 has been canceled, subsequent IIHs are transmitted according to the normal algorithms but including the Restart TLV with both RR and RA clear.
タイマーT1がキャンセルされると、後続のIIHは通常のアルゴリズムに従って送信されますが、RRとRAの両方がクリアされた再起動TLVが含まれます。
If a LAN contains a mixture of systems, only some of which support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have reinitialized their adjacencies.
LANにシステムの混合が含まれていて、その一部だけが新しいアルゴリズムをサポートしている場合でも、データベースの同期は保証されますが、「古い」システムは隣接関係を再初期化します。
If an interface is active but does not have any neighboring router reachable over that interface, the timer T1 would never be canceled, and according to Section 3.4.1.1, the SPF would never be run. Therefore, timer T1 is canceled after some predetermined number of expirations (which MAY be 1).
インターフェースがアクティブであるが、そのインターフェースを介して到達可能な隣接ルーターがない場合、タイマーT1は決してキャンセルされず、セクション3.4.1.1によると、SPFは実行されません。したがって、タイマーT1は、所定の数の満了（1の場合があります）後にキャンセルされます。
The starting router wants to ensure that in the event that a neighboring router has an adjacency to the starting router in the UP state (from a previous incarnation of the starting router), this adjacency is reinitialized. The starting router also wants neighboring routers to suppress advertisement of an adjacency to the starting router until LSP database synchronization is achieved. This is achieved by sending IIHs with the RR bit clear and the SA bit set in the Restart TLV. The RR bit remains clear and the SA bit remains set in subsequent transmissions of IIHs until the adjacency has reached the UP state and the initial T1 timer interval (see below) has expired.
開始ルーターは、隣接ルーターがUP状態の開始ルーターとの隣接関係を持っている場合（以前の開始ルーターの具体化から）、この隣接関係が再初期化されるようにします。また、開始ルータは、LSPデータベースの同期が達成されるまで、隣接ルータが開始ルータへの隣接関係のアドバタイズを抑制することを望んでいます。これは、RRビットをクリアし、SAビットを再起動TLVに設定してIIHを送信することで実現されます。隣接がUP状態に達し、初期T1タイマー間隔（下記を参照）が経過するまで、RRビットはクリアされたままで、SAビットはIIHの後続の送信で設定されたままになります。
Receipt of an IIH with the RR bit clear will result in the neighboring router utilizing normal operation of the adjacency state machine. This will ensure that any old adjacency on the neighboring router will be reinitialized.
RRビットがクリアされたIIHを受信すると、隣接ルータは隣接状態マシンの通常の動作を利用します。これにより、隣接ルーターの古い隣接関係が再初期化されます。
Upon receipt of an IIH with the SA bit set, the behavior described in Section 3.2.2 is followed.
SAビットがセットされたIIHを受信すると、セクション3.2.2で説明されている動作に従います。
Upon starting, a router starts timer T2 for each LSPDB.
開始すると、ルータは各LSPDBのタイマーT2を開始します。
For each interface (and in the case of a LAN circuit, for each level), when an adjacency reaches the UP state, the starting router starts a timer T1 and transmits an IIH containing the restart TLV with the RR bit clear and SA bit set. Upon expiry of the timer T1, it is restarted and the IIH is retransmitted with both RR and SA bits set (only the RR bit has changed state from earlier IIHs).
各インターフェイス（およびLAN回線の場合は、各レベル）で、隣接関係がUP状態に達すると、開始ルーターはタイマーT1を開始し、RRビットがクリアでSAビットが設定された再起動TLVを含むIIHを送信します。 。タイマーT1が満了すると、タイマーが再起動され、IIHはRRビットとSAビットの両方が設定された状態で再送信されます（以前のIIHから状態が変わったのはRRビットのみです）。
Upon receipt of an IIH with the RR bit set (regardless of whether or not the SA bit is set), the behavior described in Section 3.2.1 is followed.
（SAビットが設定されているかどうかに関係なく）RRビットが設定されたIIHを受信すると、セクション3.2.1で説明されている動作に従います。
When an IIH is received by the starting router and the IIH contains a Restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID that matches that of the local system), the receipt of the acknowledgement over that interface is noted.
開始ルーターがIIHを受信し、IIHにRAビットが設定された再起動TLVが含まれている場合（およびローカルシステムの再起動隣接システムIDと一致する再起動隣接システムIDを持つLAN回路上）、そのインターフェイスを介した確認の受信は了解しました。
On a Point-to-Point link, receipt of an IIH not containing the Restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. Since the neighbor will have reinitialized the adjacency, this guarantees that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is canceled immediately without waiting for a complete set of CSNPs. Synchronization may therefore be deemed complete even though there are some LSPs that are held (only) by this neighbor (see Section 3.4).
ポイントツーポイントリンクでは、Restart TLVを含まないIIHの受信も、ネイバーが再起動可能ではないことを示すため、確認応答として扱われます。ネイバーが隣接関係を再初期化するため、これによりSRMフラグがデータベースに設定されていることが保証され、最終的なLSPDB同期が保証されます。ただし、このインターフェイスでCSNPを受信することが保証されていないため、タイマーT1は、CSNPの完全なセットを待たずにすぐにキャンセルされます。したがって、このネイバーによって保持されている（のみ）LSPがいくつかある場合でも、同期は完了したと見なされる場合があります（セクション3.4を参照）。
In the case of a LAN interface, receipt of an IIH not containing the Restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore, T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. The usual operation of the update process will ensure that synchronization is eventually achieved.
LANインターフェイスの場合、再起動TLVを含まないIIHの受信は、LAN上の少なくとも1つの非再起動隣接ルーターが再起動をサポートしている限り、同期が発生する可能性があるため、顕著ではありません。したがって、この場合、T1は引き続き実行されます。 LAN上のどのネイバーも再起動に対応していない場合、T1はローカルで定義された回数の再試行後に最終的に期限切れになります。更新プロセスの通常の操作により、最終的に同期が確実に行われます。
When BOTH a complete set of CSNPs (for each active level, in the case of a Point-to-Point circuit) and an acknowledgement have been received over the interface, the timer T1 is canceled. Subsequent IIHs sent by the starting router have the RR and RA bits clear and the SA bit set in the Restart TLV.
CSNPの完全なセット（ポイントツーポイント回線の場合は、アクティブレベルごと）と確認応答の両方がインターフェイスを介して受信されると、タイマーT1がキャンセルされます。開始ルータによって送信された後続のIIHは、RRおよびRAビットがクリアされ、SAビットが再起動TLVに設定されています。
Timer T1 is canceled after some predetermined number of expirations (which MAY be 1).
タイマーT1は、あらかじめ決められた数の期限切れ（1の場合があります）の後にキャンセルされます。
When the T2 timer(s) are canceled or expire, transmission of "normal IIHs" will begin.
T2タイマーがキャンセルまたは期限切れになると、「通常のIIH」の送信が開始されます。
A router that is operating as both a Level 1 and a Level 2 router on a particular interface MUST perform the above operations for each level.
特定のインターフェイスでレベル1とレベル2の両方のルーターとして動作しているルーターは、各レベルで上記の操作を実行する必要があります。
On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs and perform the CSNP synchronizations independently for each level.
LANインターフェイスでは、レベル1とレベル2の両方のIIHを送受信し、レベルごとに独立してCSNP同期を実行する必要があります。
On a Point-to-Point interface, only a single IIH (indicating support for both levels) is required, but it MUST perform the CSNP synchronizations independently for each level.
ポイントツーポイントインターフェイスでは、単一のIIH（両方のレベルのサポートを示す）のみが必要ですが、各レベルで独立してCSNP同期を実行する必要があります。
When a router is started or restarted, it can expect to receive a complete set of CSNPs over each interface. The arrival of the CSNP(s) is now guaranteed, since an IIH with the RR bit set will be retransmitted until the CSNP(s) are correctly received.
ルーターを起動または再起動すると、各インターフェースでCSNPの完全なセットを受信することが期待できます。 CSNPが正しく受信されるまで、RRビットが設定されたIIHが再送信されるため、CSNPの到着が保証されます。
The CSNPs describe the set of LSPs that are currently held by each neighbor. Synchronization will be complete when all these LSPs have been received.
CSNPは、各ネイバーが現在保持しているLSPのセットを記述します。これらのLSPをすべて受信すると、同期が完了します。
When (re)starting, a router starts an instance of timer T2 for each LSPDB, as described in Section 3.3.1 or Section 3.3.2. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNPs received over each interface is recorded, together with their remaining lifetime. In the case of a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbors that are not restarting. If there are multiple interfaces on the (re)starting router, the recorded set of LSPIDs is the union of those received over each interface. LSPs with a remaining lifetime of zero are NOT so recorded.
セクション3.3.1またはセクション3.3.2で説明されているように、ルータは（再）起動時に各LSPDBのタイマーT2のインスタンスを起動します。 CSNPの通常の処理に加えて、各インターフェイスを介して受信されたCSNPの最初の完全なセットに含まれるLSPIDのセットが、残りのライフタイムとともに記録されます。 LANインターフェイスの場合、CSNPの完全なセットは、再起動していないネイバーから受信したCSNPで構成する必要があります。 （再）起動ルータに複数のインターフェイスがある場合、記録されたLSPIDのセットは、各インターフェイスで受信されたものの和集合です。残りのライフタイムがゼロのLSPは記録されません。
As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if an LSP arrives before the CSNP containing the reference). When an LSPID has been held in the list for its indicated remaining lifetime, it is removed from the list. When the list of LSPIDs is empty and the timer T1 has been canceled for all the interfaces that have an adjacency at this level, the timer T2 is canceled.
LSPが（更新プロセスの通常の操作によって）任意のインターフェイスで受信されると、対応するLSPIDエントリが削除されます（参照を含むCSNPの前にLSPが到着した場合も削除されます）。 LSPIDが指定された残りのライフタイムの間リストに保持されると、リストから削除されます。 LSPIDのリストが空で、このレベルで隣接関係があるすべてのインターフェイスのタイマーT1がキャンセルされた場合、タイマーT2がキャンセルされます。
At this point, the local database is guaranteed to contain all the LSP(s) (either the same sequence number or a more recent sequence number) that were present in the neighbors' databases at the time of (re)starting. LSPs that arrived in a neighbor's database after the time of (re)starting may or may not be present, but the normal operation of the update process will guarantee that they will eventually be received. At this point, the local database is deemed to be "synchronized".
この時点で、ローカルデータベースには、（再）起動時に近隣のデータベースに存在していたすべてのLSP（同じシーケンス番号またはより新しいシーケンス番号）が含まれていることが保証されています。 （再）起動後にネイバーのデータベースに到着したLSPは、存在する場合と存在しない場合がありますが、更新プロセスの通常の動作により、最終的に受信されることが保証されます。この時点で、ローカルデータベースは「同期」されていると見なされます。
Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded and those with a short remaining lifetime are deleted from the list when the lifetime expires, cancellation of the timer T2 will not be prevented by waiting for an LSP that will never arrive.
残りのライフタイムがゼロのCSNPに記載されているLSPは記録されず、ライフタイムの期限が切れると、残りのライフタイムが短いものはリストから削除されるため、タイマーT2のキャンセルは、到着しない。
The operation of a router starting, as opposed to restarting, is somewhat different. These two cases are dealt with separately below.
再起動とは対照的に、ルーターの起動操作は多少異なります。これら2つのケースは、以下で個別に処理されます。
In order to avoid causing unnecessary routing churn in other routers, it is highly desirable that the router's own LSPs generated by the restarting system are the same as those previously present in the network (assuming no other changes have taken place). It is important therefore not to regenerate and flood the LSPs until all the adjacencies have been reestablished and any information required for propagation into the local LSPs is fully available. Ideally, the information is loaded into the LSPs in a deterministic way, such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions may not even cause SPF to be run in other systems. However, provided the same information is included in the set of LSPs (albeit in a different order, and possibly different LSPs), the result of running the SPF will be the same and will not cause churn to the forwarding tables.
他のルーターで不要なルーティングチャーンが発生しないようにするには、再起動システムによって生成されたルーター自体のLSPが、以前にネットワークに存在していたものと同じであることが望ましいです（他の変更が行われていないと仮定）。したがって、すべての隣接関係が再確立され、ローカルLSPへの伝播に必要な情報が完全に利用可能になるまで、LSPを再生成してフラッディングしないことが重要です。理想的には、情報は決定論的な方法でLSPにロードされ、同じ情報が同じLSPの同じ場所で発生します（したがって、LSPは以前のバージョンと同一です）。これが達成できる場合、新しいバージョンでは、SPFが他のシステムで実行されることすらありません。ただし、LSPのセットに同じ情報が含まれている場合（順序は異なりますが、LSPが異なる可能性があります）、SPFの実行結果は同じであり、転送テーブルへのチャーンは発生しません。
In the case of a restarting router, none of the router's own LSPs are transmitted, nor are the router's own forwarding tables updated while the timer T3 is running.
再起動するルーターの場合、ルーター自体のLSPは送信されず、タイマーT3の実行中にルーター自体の転送テーブルも更新されません。
Redistribution of inter-level information MUST be regenerated before this router's LSP is flooded to other nodes. Therefore, the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has been run. This ensures that any inter-level information that is to be propagated can be included in the Level-n LSP(s).
このルーターのLSPが他のノードにフラッディングされる前に、レベル間情報の再配布を再生成する必要があります。したがって、レベルnの非疑似ノードLSPは、他のレベルのT2タイマーが期限切れになり、そのSPFが実行されるまで、フラッディングしてはいけません（MUST NOT）。これにより、伝達されるすべてのレベル間情報をLevel-n LSPに含めることができます。
During this period, if one of the router's own (including pseudonodes) LSPs is received, which the local router does not currently have in its own database, it is NOT purged. Under normal operation, such an LSP would be purged, since the LSP clearly should not be present in the global LSP database. However, in the present circumstances, this would be highly undesirable, because it could cause premature removal of a router's own LSP -- and hence churn in remote routers. Even if the local system has one or more of the router's own LSPs (which it has generated but not yet transmitted), it is still not valid to compare the received LSP against this set, since it may be that as a result of propagation between Level 1 and Level 2 (or vice versa), a further router's own LSP will need to be generated when the LSP databases have synchronized.
この期間中に、ローカルルータが自身のデータベースに現在持っていない、ルータ自身の（疑似ノードを含む）LSPの1つを受信した場合、それは削除されません。 LSPがグローバルLSPデータベースに存在しないことは明らかであるため、通常の操作では、このようなLSPは削除されます。ただし、現状では、ルーター自体のLSPが早期に削除され、リモートルーターでチャーンされる可能性があるため、これは非常に望ましくありません。ローカルシステムに1つ以上のルーター独自のLSP（生成されているがまだ送信されていない）がある場合でも、受信したLSPをこのセットと比較することはできません。レベル1とレベル2（またはその逆）、LSPデータベースが同期している場合は、さらにルーター独自のLSPを生成する必要があります。
During this period, a restarting router SHOULD send CSNPs as it normally would. Information about the router's own LSPs MAY be included, but if it is included, it MUST be based on LSPs that have been received, not on versions that have been generated (but not yet transmitted). This restriction is necessary to prevent premature removal of an LSP from the global LSP database.
この期間中、再起動ルーターは、通常どおりにCSNPを送信する必要があります（SHOULD）。ルーター自身のLSPに関する情報が含まれる場合がありますが、含まれている場合は、生成された（まだ送信されていない）バージョンではなく、受信したLSPに基づく必要があります。この制限は、グローバルLSPデータベースからのLSPの早期削除を防ぐために必要です。
When the timer T2 expires or is canceled, indicating that synchronization for that level is complete, the SPF for that level is run in order to derive any information that is required to be propagated to another level, but the forwarding tables are not yet updated.
タイマーT2が期限切れになるかキャンセルされ、そのレベルの同期が完了したことを示すと、そのレベルのSPFが実行されて、別のレベルに伝達する必要がある情報が取得されますが、転送テーブルはまだ更新されていません。
Once the other level's SPF has run and any inter-level propagation has been resolved, the router's own LSPs can be generated and flooded. Any own LSPs that were previously ignored, but that are not part of the current set of own LSPs (including pseudonodes), MUST then be purged. Note that it is possible that a Designated Router change may have taken place and, consequently, the router SHOULD purge those pseudonode LSPs that it previously owned but that are now no longer part of its set of pseudonode LSPs.
他のレベルのSPFが実行され、レベル間の伝播が解決されると、ルーター自体のLSPが生成され、フラッディングされます。以前は無視されていたが、現在の独自のLSP（疑似ノードを含む）のセットの一部ではない独自のLSPは、次に削除する必要があります。指定ルーターの変更が行われた可能性があることに注意してください。その結果、ルーターは以前に所有していたが現在はその疑似ノードLSPセットの一部ではない疑似ノードLSPを削除する必要があります（SHOULD）。
When all the T2 timers have expired or been canceled, the timer T3 is canceled, and the local forwarding tables are updated.
すべてのT2タイマーが期限切れになるか取り消されると、タイマーT3が取り消され、ローカル転送テーブルが更新されます。
If the timer T3 expires before all the T2 timers have expired or been canceled, this indicates that the synchronization process is taking longer than the minimum Holding Time of the neighbors. The router's own LSP(s) for levels that have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and therefore other routers MUST NOT compute routes through this router). Normal operation of the update process resumes, and the local forwarding tables are updated. In order to prevent the neighbor's adjacencies from expiring, IIHs with the normal interface value for the Holding Time are transmitted over all interfaces with neither RR nor RA set in the Restart TLV. This will cause the neighbors to refresh their adjacencies. The router's own LSP(s) will continue to have the overload bit set until timer T2 has expired or been canceled.
すべてのT2タイマーが期限切れになるかキャンセルされる前にタイマーT3が期限切れになる場合、これは、同期プロセスがネイバーの最小保持時間よりも長くかかっていることを示しています。最初のSPF計算をまだ完了していないレベルのルーター自体のLSPは、ルーターのLSPDBがまだ同期されていないことを示すために過負荷ビットセットでフラッディングされます（したがって、他のルーターはこのルーターを介してルートを計算してはなりません）。更新プロセスの通常の操作が再開され、ローカル転送テーブルが更新されます。ネイバーの隣接関係が期限切れにならないようにするために、保持時間の通常のインターフェイス値を持つIIHは、再起動TLVでRRもRAも設定されていないすべてのインターフェイスを介して送信されます。これにより、ネイバーは隣接関係を更新します。ルーターの独自のLSPは、タイマーT2が期限切れになるかキャンセルされるまで、過負荷ビットを設定し続けます。
In the case of a starting router, as soon as each adjacency is established, and before any CSNP exchanges, the router's own zeroth LSP is transmitted with the overload bit set. This prevents other routers from computing routes through the router until it has reliably acquired the complete set of LSPs. The overload bit remains set in subsequent transmissions of the zeroth LSP (such as will occur if a previous copy of the router's own zeroth LSP is still present in the network) while any timer T2 is running.
開始ルータの場合、各隣接関係が確立されるとすぐに、CSNPが交換する前に、ルータ自体のゼロ番目のLSPが過負荷ビットが設定された状態で送信されます。これにより、他のルーターがLSPの完全なセットを確実に取得するまで、ルーターを介したルートを計算できなくなります。過負荷ビットは、タイマーT2が実行されている間、0番目のLSPの後続の送信で設定されたままになります（ルーター自体の0番目のLSPの以前のコピーがまだネットワークに存在する場合など）。
When all the T2 timers have been canceled, the router's own LSP(s) MAY be regenerated with the overload bit clear (assuming the router is not in fact overloaded, and there is no other reason, such as incomplete BGP convergence, to keep the overload bit set) and flooded as normal.
すべてのT2タイマーがキャンセルされると、ルーター自体のLSPが過負荷ビットをクリアして再生成される場合があります（ルーターが実際には過負荷ではなく、不完全なBGPコンバージェンスなどの他の理由がないため、オーバーロードビットセット）、通常どおりフラッディングされます。
Other LSPs owned by this router (including pseudonodes) are generated and flooded as normal, irrespective of the timer T2. The SPF is also run as normal and the Routing Information Base (RIB) and Forwarding Information Base (FIB) updated as routes become available.
このルーター（疑似ノードを含む）が所有する他のLSPは、タイマーT2に関係なく、通常どおり生成およびフラッディングされます。 SPFも通常どおり実行され、ルーティング情報ベース（RIB）および転送情報ベース（FIB）は、ルートが利用可能になると更新されます。
To avoid the possible formation of temporary blackholes, the starting router sets the SA bit in the Restart TLV (as described in Section 3.3.2) in all IIHs that it sends.
一時的なブラックホールの形成を回避するために、開始ルーターは、送信するすべてのIIHの再起動TLV（セクション3.3.2で説明）にSAビットを設定します。
When all T2 timers have been canceled, the starting router MUST transmit IIHs with the SA bit clear.
すべてのT2タイマーがキャンセルされた場合、開始ルーターはSAビットをクリアしてIIHを送信する必要があります。
This section presents state tables that summarize the behaviors described in this document. Other behaviors, in particular adjacency state transitions and LSP database update operations, are NOT included in the state tables except where this document modifies the behaviors described in [ISO10589] and [RFC5303].
このセクションでは、このドキュメントで説明されている動作を要約した状態テーブルを示します。他の動作、特に隣接状態の遷移とLSPデータベースの更新操作は、このドキュメントが[ISO10589]と[RFC5303]で説明されている動作を変更する場合を除いて、状態テーブルに含まれていません。
The states named in the columns of the tables below are a mixture of states that are specific to a single adjacency (ADJ suppressed, ADJ Seen RA, ADJ Seen CSNP) and states that are indicative of the state of the protocol instance (Running, Restarting, Starting, SPF Wait).
以下の表の列に示されている状態は、単一の隣接に固有の状態（ADJ抑制、ADJ Seen RA、ADJ Seen CSNP）とプロトコルインスタンスの状態を示す状態（実行中、再起動中）の混合です。 、開始、SPF待機）。
Three state tables are presented from the point of view of a running router, a restarting router, and a starting router.
実行中のルーター、再起動中のルーター、および起動中のルーターの観点から、3つの状態テーブルが提示されます。
+--------+-------------------------------------------+--------------+
| Event | Running | ADJ |
| | | suppressed |
+========+===========================================+==============+
| RX PR | Set Planned Restart State | |
| | Update Holding Time | |
| | Send PA | |
+--------+-------------------------------------------+--------------+
| RX PR | Clear Planned Restart State | |
| clr | Restore Holding Time to local value | |
| and RR | | |
| clr | | |
+--------+-------------------------------------------+--------------+
| RX RR | Maintain ADJ State | |
| | Send RA | |
| | Set SRM, send CSNP (Note 1) | |
| | Update Holding Time, | |
| | set Restart Mode (Note 2) | |
+--------+-------------------------------------------+--------------+
| RX RR | Clr Restart mode | |
| clr | | |
+--------+-------------------------------------------+--------------+
| RX SA | Suppress IS neighbor TLV in LSP(s) | |
| | Goto ADJ Suppressed | |
+--------+-------------------------------------------+--------------+
| RX SA | | Unsuppress |
| clr | | IS neighbor |
| | | TLV in |
| | | LSP(s) |
| | | Goto Running |
+--------+-------------------------------------------+--------------+
Table 1: Running Router
表1：実行中のルーター
Note 1: CSNPs are sent by routers in accordance with item c in Section 3.2.1
注1：CSNPは、セクション3.2.1の項目cに従ってルーターから送信されます。
Note 2: If Restart Mode clear
注2：再起動モードがクリアされている場合
+----------+-----------------+---------+---------+------------------+
| Event | Restarting | ADJ | ADJ | SPF Wait |
| | | Seen RA | Seen | |
| | | | CSNP | |
+==========+=================+=========+=========+==================+
| Restart | Send PR | | | |
| planned | | | | |
+----------+-----------------+---------+---------+------------------+
| Planned | Send PR clr | | | |
| restart | | | | |
| canceled | | | | |
+----------+-----------------+---------+---------+------------------+
| RX PA | Proceed with | | | |
| | planned restart | | | |
+----------+-----------------+---------+---------+------------------+
| Router | Send IIH/RR | | | |
| restarts | ADJ Init | | | |
| | Start T1, T2, | | | |
| | T3 | | | |
+----------+-----------------+---------+---------+------------------+
| RX RR | Send RA | | | |
+----------+-----------------+---------+---------+------------------+
| RX RA | Adjust T3 | | Cancel | |
| | Goto ADJ Seen | | T1 | |
| | RA | | Adjust | |
| | | | T3 | |
+----------+-----------------+---------+---------+------------------+
| RX CSNP | Goto ADJ Seen | Cancel | | |
| set | CSNP | T1 | | |
+----------+-----------------+---------+---------+------------------+
| RX IIH | Cancel T1 | | | |
| w/o | (Point-to-point | | | |
| Restart | only) | | | |
| TLV | | | | |
+----------+-----------------+---------+---------+------------------+
| T1 | Send IIH/RR | Send | Send | |
| expires | Restart T1 | IIH/RR | IIH/RR | |
| | | Restart | Restart | |
| | | T1 | T1 | |
+----------+-----------------+---------+---------+------------------+
| T1 | Send IIH/normal | Send | Send | |
| expires | | IIH/ | IIH/ | |
| nth time | | normal | normal | |
+----------+-----------------+---------+---------+------------------+
| T2 | Trigger SPF | | | |
| expires | Goto SPF Wait | | | |
+----------+-----------------+---------+---------+------------------+
| T3 | Set overload | | | |
| expires | bit | | | |
| | Flood local | | | |
| | LSPs | | | |
| | Update fwd | | | |
| | plane | | | |
+----------+-----------------+---------+---------+------------------+
| LSP DB | Cancel T2 and | | | |
| Sync | T3 | | | |
| | Trigger SPF | | | |
| | Goto SPF wait | | | |
+----------+-----------------+---------+---------+------------------+
| All SPF | | | | Clear overload |
| done | | | | bit |
| | | | | Update fwd |
| | | | | plane |
| | | | | Flood local |
| | | | | LSPs |
| | | | | Goto Running |
+----------+-----------------+---------+---------+------------------+
Table 2: Restarting Router
表2：ルーターの再起動
+-------------+---------------------------+------------+------------+
| Event | Starting | ADJ Seen | ADJ Seen |
| | | RA | CSNP |
+=============+===========================+============+============+
| Router | Send IIH/SA | | |
| starts | Start T1 and T2 | | |
+-------------+---------------------------+------------+------------+
| RX RR | Send RA | | |
+-------------+---------------------------+------------+------------+
| RX RA | Goto ADJ Seen RA | | Cancel T1 |
+-------------+---------------------------+------------+------------+
| RX CSNP Set | Goto ADJ Seen CSNP | Cancel T1 | |
+-------------+---------------------------+------------+------------+
| RX IIH w no | Cancel T1 (Point-to- | | |
| Restart TLV | Point only) | | |
+-------------+---------------------------+------------+------------+
| ADJ UP | Start T1 | | |
| | Send local LSPs with | | |
| | overload bit set | | |
+-------------+---------------------------+------------+------------+
| T1 expires | Send IIH/RR and SA | Send IIH/ | Send IIH/ |
| | Restart T1 | RR and SA | RR and SA |
| | | Restart T1 | Restart T1 |
+-------------+---------------------------+------------+------------+
| T1 expires | Send IIH/SA | Send IIH/ | Send IIH/ |
| nth time | | SA | SA |
+-------------+---------------------------+------------+------------+
| T2 expires | Clear overload bit | | |
| | Send IIH normal | | |
| | Goto Running | | |
+-------------+---------------------------+------------+------------+
| LSP DB Sync | Cancel T2 | | |
| | Clear overload bit | | |
| | Send IIH normal | | |
+-------------+---------------------------+------------+------------+
Table 3: Starting Router
表3：ルーターの起動
This document defines the following IS-IS TLV that is listed in the "IS-IS TLV Codepoints" registry.
このドキュメントでは、「IS-IS TLVコードポイント」レジストリにリストされている次のIS-IS TLVを定義しています。
+------+-------------+-----+-----+-----+-------+
| Type | Description | IIH | LSP | SNP | Purge |
+======+=============+=====+=====+=====+=======+
| 211 | Restart TLV | y | n | n | n |
+------+-------------+-----+-----+-----+-------+
Table 4
表4
IANA has updated the entry in registry to point to this document.
IANAは、このドキュメントを指すようにレジストリのエントリを更新しました。
Any new security issues raised by the procedures in this document depend upon the ability of an attacker to inject a false but apparently valid IIH, the ease/difficulty of which has not been altered.
このドキュメントの手順で提起された新しいセキュリティ問題は、攻撃者が偽りではあるが明らかに有効なIIHを挿入できるかどうかに依存しますが、IIHの難易度は変更されていません。
If the RR bit is set in a false IIH, neighbors who receive such an IIH will continue to maintain an existing adjacency in the UP state and may (re)send a complete set of CSNPs. While the latter action is wasteful, neither action causes any disruption in correct protocol operation.
RRビットが偽のIIHに設定されている場合、そのようなIIHを受信したネイバーは引き続き既存の隣接関係をUP状態に維持し、CSNPの完全なセットを（再）送信できます。後者のアクションは無駄ですが、どちらのアクションも正しいプロトコル操作を中断させません。
If the RA bit is set in a false IIH, a (re)starting router that receives such an IIH may falsely believe that there is a neighbor on the corresponding interface that supports the procedures described in this document. In the absence of receipt of a complete set of CSNPs on that interface, this could delay the completion of (re)start procedures by requiring the timer T1 to time out the locally defined maximum number of retries. This behavior is the same as would occur on a LAN where none of the (re)starting router's neighbors support the procedures in this document and is covered in Sections 3.3.1 and 3.3.2.
RAビットが誤ったIIHに設定されている場合、そのようなIIHを受信する（再）開始ルーターは、このドキュメントで説明されている手順をサポートする対応するインターフェイスにネイバーがあると誤って信じる可能性があります。そのインターフェイスでCSNPの完全なセットを受信しないと、ローカルで定義された再試行の最大数をタイムアウトするようにタイマーT1に要求することにより、（再）開始手順の完了が遅れる可能性があります。この動作は、LANで発生するのと同じであり、（再）起動するルーターのネイバーがこのドキュメントの手順をサポートしておらず、セクション3.3.1および3.3.2で説明されています。
If the SA bit is set in a false IIH, this could cause suppression of the advertisement of an IS neighbor, which could either continue for an indefinite period or occur intermittently with the result being a possible loss of reachability to some destinations in the network and/or increased frequency of LSP flooding and SPF calculation.
SAビットが誤ったIIHに設定されている場合、これによりISネイバーのアドバタイズメントが抑制される可能性があります。これは、無期限に継続するか断続的に発生し、その結果、ネットワーク内の一部の宛先への到達可能性が失われる可能性があります。 LSPフラッディングおよびSPF計算の頻度の増加。
If the PR bit is set in a false IIH, neighbors who receive such an IIH could modify the Holding Time of an existing adjacency inappropriately. In the event of topology changes, the neighbor might also choose to not flood the topology updates and/or bring the adjacency down in the false belief that the forwarding plane of the router identified as the source of the false IIH is not currently processing announced topology changes. This would result in unnecessary forwarding disruption.
PRビットが偽のIIHに設定されている場合、そのようなIIHを受信するネイバーは、既存の隣接の保持時間を不適切に変更する可能性があります。トポロジーが変更された場合、ネイバーは、トポロジーの更新をあふれさせないこと、および/または偽のIIHのソースとして識別されたルーターの転送プレーンが現在アナウンスされたトポロジーを処理していないという誤った信念で隣接関係を低下させないことを選択することもあります変更。これにより、不要な転送の中断が発生します。
If the PA bit is set in a false IIH, a router that receives such an IIH may falsely believe that the neighbor on the corresponding interface supports the planned restart procedures defined in this document. If such a router is planning to restart, it might then proceed to initiate a restart in the false expectation that the neighbor has updated its Holding Time as requested. This may result in the neighbor bringing down the adjacency while the receiving router is restarting, causing unnecessary disruption to forwarding.
PAビットが偽のIIHで設定されている場合、そのようなIIHを受信するルータは、対応するインターフェイスのネイバーがこのドキュメントで定義されている計画された再起動手順をサポートしていると誤って信じる可能性があります。このようなルーターが再起動を計画している場合は、ネイバーが要求に応じて保持時間を更新したという誤った期待で再起動を開始する可能性があります。これにより、受信ルータの再起動中にネイバーが隣接関係を停止させ、転送に不要な中断を引き起こす可能性があります。
The possibility of IS-IS PDU spoofing can be reduced by the use of authentication, as described in [RFC1195] and [ISO10589], and especially by the use of cryptographic authentication, as described in [RFC5304] and [RFC5310].
IS-IS PDUスプーフィングの可能性は、[RFC1195]と[ISO10589]で説明されているように認証を使用することによって、特に[RFC5304]と[RFC5310]で説明されているように暗号化認証を使用することによって減らすことができます。
These extensions that have been designed, developed, and deployed for many years do not have any new impact on management and operation of the IS-IS protocol via this standardization process.
長年にわたって設計、開発、および展開されてきたこれらの拡張機能は、この標準化プロセスによるIS-ISプロトコルの管理と運用に新しい影響を与えることはありません。
[ISO10589] International Organization for Standardization, "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)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化機構、「情報技術-システム間の通信と情報交換-コネクションレスモードのネットワークサービス（ISOを提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル8473） "、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<https://www.rfc-editor.org/ info / rfc1195>。
[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>。
[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, DOI 10.17487/RFC5303, October 2008, <https://www.rfc-editor.org/info/rfc5303>.
[RFC5303] Katz、D.、Saluja、R。、およびD. Eastlake 3番目、「IS-ISポイントツーポイント隣接のための3ウェイハンドシェイク」、RFC 5303、DOI 10.17487 / RFC5303、2008年10月、<https： //www.rfc-editor.org/info/rfc5303>。
[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>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<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>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<https://www.rfc-editor.org/info/rfc5310>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>。
[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>。
This document extends RFC 5306 by introducing support for signaling the neighbors of a restarting router that a planned restart is about to occur. This allows the neighbors to be aware of the state of the restarting router so that appropriate action may be taken if other topology changes occur while the planned restart is in progress. Since the forwarding plane of the restarting router is maintained based upon the pre-restart state of the network, additional topology changes introduce the possibility that traffic may be lost if paths via the restarting router continue to be used while the restart is in progress.
このドキュメントは、計画的な再起動が発生しようとしていることを再起動ルータのネイバーに通知するためのサポートを導入することにより、RFC 5306を拡張します。これにより、ネイバーは再起動中のルーターの状態を認識できるため、計画的な再起動の進行中に他のトポロジーの変更が発生した場合に適切なアクションを実行できます。再起動ルーターの転送プレーンはネットワークの再起動前の状態に基づいて維持されるため、追加のトポロジ変更により、再起動の進行中に再起動ルーター経由のパスが引き続き使用されるとトラフィックが失われる可能性があります。
In support of this new functionality, two new flags have been introduced:
この新しい機能をサポートするために、2つの新しいフラグが導入されました。
PR - Restart is planned
PR-再開予定
PA - Planned restart acknowledgement
PA-計画された再起動の確認
No changes to the post-restart exchange between the restarting router and its neighbors have been introduced.
再起動ルータとそのネイバー間の再起動後の交換に対する変更は導入されていません。
Acknowledgements
謝辞
For RFC 5306, the authors acknowledged contributions made by Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang.
RFC 5306について、著者はJeff Parker、Radia Perlman、Mark Schaefer、Naiming Shen、Nischal Sheth、Russ White、およびRena Yangによる貢献を認めました。
The authors of this updated document acknowledge the contribution of Mike Shand, coauthor of RFC 5306.
この更新されたドキュメントの作成者は、RFC 5306の共著者であるMike Shandの貢献を認めています。
Authors' Addresses
著者のアドレス
Les Ginsberg Cisco Systems, Inc.
Les Ginsberg Cisco Systems、Inc.
Email: ginsberg@cisco.com
Paul Wells Cisco Systems, Inc.
Paul Wells Cisco Systems、Inc.
Email: pauwells@cisco.com