[要約] RFC 3847は、IS-ISプロトコルにおける再起動シグナリングに関する仕様です。その目的は、ネットワークの再起動時にIS-ISルーター間での通信を効果的に制御し、ネットワークの安定性と収束時間を向上させることです。

Network Working Group                                           M. Shand
Request for Comments: 3847                                   L. Ginsberg
Category: Informational                                    Cisco Systems
                                                               July 2004
        

Restart Signaling for Intermediate System to Intermediate System (IS-IS)

中間システムの中間システム(IS-IS)のシグナリングを再起動する

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004). All Rights Reserved.

著作権(c)The Internet Society(2004)。無断転載を禁じます。

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.

このドキュメントでは、再起動するルーターが再起動していることを信号するメカニズムについて説明し、データベースの同期を正しく開始しながら、ダウン状態をサイクリングせずに隣接を再確立できるようにします。

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, while minimizing transient routing disruption when a router starts.

このドキュメントでは、再起動ルーターのメカニズムが、近隣とのLSPデータベースの同期をいつ達成したかを判断し、LSPデータベースの同期を最適化するメカニズムを説明し、ルーターが開始されたときの過渡的なルーティングの混乱を最小限に抑えることを説明しています。

Table of Contents

目次

   1.  Conventions used in this Document. . . . . . . . . . . . . . .  2
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.  Timers . . . . . . . . . . . . . . . . . . . . . . . . .  4
       3.2.  Restart TLV. . . . . . . . . . . . . . . . . . . . . . .  5
             3.2.1.  Use of RR and RA Bits. . . . . . . . . . . . . .  6
             3.2.2.  Use of SA Bit. . . . . . . . . . . . . . . . . .  7
       3.3.  Adjacency (re)Acquisition. . . . . . . . . . . . . . . .  8
             3.3.1.  Adjacency Reacquisition During Restart . . . . .  8
             3.3.2.  Adjacency Acquisition During Start . . . . . . . 10
             3.3.3.  Multiple Levels. . . . . . . . . . . . . . . . . 12
       3.4.  Database Synchronization . . . . . . . . . . . . . . . . 12
             3.4.1.  LSP Generation and Flooding and SPF Computation. 13
                     3.4.1.1. Restarting. . . . . . . . . . . . . . . 13
                     3.4.1.2. Starting. . . . . . . . . . . . . . . . 15
   4.  State Tables . . . . . . . . . . . . . . . . . . . . . . . . . 15
       4.1.  Running Router . . . . . . . . . . . . . . . . . . . . . 16
       4.2.  Restarting Router. . . . . . . . . . . . . . . . . . . . 17
       4.3.  Starting Router. . . . . . . . . . . . . . . . . . . . . 18
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 19
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21
        
1. Conventions used in this Document
1. このドキュメントで使用されている規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC-2119 [3].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC-2119 [3]に記載されているように解釈される。

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.

「(re)start/(re)start」という用語は、テキストが「開始」と「再起動」ルーターの両方に適用できる場合に使用されます。

2. Overview
2. 概要

The Intermediate System to Intermediate System (IS-IS) routing protocol [RFC 1195, ISO/IEC 10589] 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.

中間システムから中間システム(IS-IS)ルーティングプロトコル[RFC 1195、ISO/IEC 10589]は、リンク状態内部領域内ルーティングプロトコルです。通常、IS-ISルーターが再起動されると、再起動ルーターと再起動ルーターのネイバーの両方のイベントにより、ルーティングの一時的な混乱が発生します。

The router which 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.

再起動ルーターの隣人は、再起動イベントを検出し、ダウン状態を介して再起動ルーターで隣接を循環させます。隣接状態のサイクリングにより、隣人は関係する隣接を説明する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 SPF runs throughout the area (or in the case of Level 2, throughout the domain).

1. 独自のLSPが再生されるため、エリア全体(またはレベル2の場合、ドメイン全体)をトリガーします。

2. It sets SRMflags on its own LSP database on the adjacency concerned.

2. 関係する隣接において、独自のLSPデータベースにSRMFLAGSを設定します。

3. In the case of a Point-to-Point link, it transmits a (set of) CSNP(s) over the adjacency.

3. ポイントツーポイントリンクの場合、隣接する(S)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 which 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 the router is being restarted or not (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 that it is restarting to its neighbors, and allow them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.

このドキュメントでは、ルーターを再起動するメカニズムが近隣に再起動していることを示し、データベースの同期を正しく開始しながら、ダウン状態をサイクリングせずに隣接を再確立できるようにします。

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 [4] is being used on Point-to-Point circuits.

3方向の握手[4]は、ポイントツーポイント回路で使用されていると想定されています。

3. Approach
3. アプローチ
3.1. Timers
3.1. タイマー

Three additional timers, T1, T2, and T3 are required to support the functionality defined in this document.

このドキュメントで定義されている機能をサポートするには、3つの追加のタイマー、T1、T2、およびT3が必要です。

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 might be 3 seconds.

タイマーT1のインスタンスはインターフェイスごとに維持され、その後の時間を示していないことを示します。典型的な値は3秒かもしれません。

An instance of the timer T2 is maintained for each LSP database present in the system, i.e., for a Level1/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 might be 60 seconds.

タイマーT2のインスタンスは、システムに存在する各LSPデータベース、つまりレベル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 RA set and an indication that the neighbor has an adjacency in the "UP" state to the restarting router.

タイマーT3の単一インスタンスは、システム全体に対して維持されます。これは、ルーターがデータベースの同期を達成できなかったことを宣言する時間を示します(独自のLSPで過負荷ビットを設定することにより)。これは65535秒に初期化されますが、RAセットを備えた再起動TLVを含む受信IIHの残りの時間の最小値と、隣人が再起動ルーターに「UP」状態に隣接があることを示すことを示しています。

NOTE: The timer T3 is only used by a restarting router.

注:タイマーT3は、再起動ルーターによってのみ使用されます。

3.2. Restart TLV
3.2. TLVを再起動します

A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined in this document and it carries flags that are used to convey information during a (re)start. All IIHs transmitted by a router that supports this capability MUST include this TLV.

新しいTLVは、IIH PDUに含まれるように定義されています。このTLVの存在は、送信者がこのドキュメントで定義されている機能をサポートし、(再)開始中に情報を伝えるために使用されるフラグを運ぶことを示しています。この機能をサポートするルーターによって送信されるすべてのIIHSは、このTLVを含める必要があります。

Type 211 Length # of octets in the value field (1 to (3 + ID Length)) Value

タイプ211値フィールドのオクテットの長さ#(1〜(3ID長))値

                                    No. of octets
     +-----------------------+
     |   Flags               |     1
     +-----------------------+
     | Remaining Time        |     2
     +-----------------------+
     | Restarting Neighbor ID|     ID Length
     +-----------------------+
        

Flags (1 octet)

フラグ(1オクテット)

      0  1  2  3  4  5  6  7
     +--+--+--+--+--+--+--+--+
     |  Reserved    |SA|RA|RR|
     +--+--+--+--+--+--+--+--+
        

RR - Restart Request RA - Restart Acknowledgement SA - Suppress adjacency advertisement

RR -Reptart RequestRA-再起動謝辞SA-隣接する広告を抑制します

(Note: Remaining fields are required when the RA bit is set)

(注:RAビットが設定されている場合、残りのフィールドが必要です)

Remaining Time (2 octets)

残り時間(2オクテット)

Remaining holding time (in seconds)

残りの保持時間(秒単位)

Restarting Neighbor System ID (ID Length octets)

ネイバーシステムIDの再起動(ID長さのオクテット)

The system ID of the neighbor to which an RA refers. Note: Implementations based on earlier versions of this document may not include this field in the TLV when the RA is set. In this case, a router which is expecting an RA on a LAN circuit SHOULD assume that the acknowledgement is directed at the local system.

RAが参照する隣人のシステムID。注:このドキュメントの以前のバージョンに基づく実装では、RAが設定されたときにTLVにこのフィールドを含めない場合があります。この場合、LAN回路のRAを期待しているルーターは、承認がローカルシステムに向けられていると想定する必要があります。

3.2.1. Use of RR and RA Bits
3.2.1. RRおよびRAビットの使用

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ビットは、(RE)起動ルーターによって使用され、近隣に(再)開始が進行中であることを信号します。隣接する状態マシンの通常の動作に隣接能力が必要な場合でも、既存の隣接は維持されるべきであることを確認します。再活性化され、CSNPのセットを要求し、SRMFLAGSの設定を要求します。

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 state "UP" 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ビットセットを備えた再起動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 a normal 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 an adjacency is marked as being in "Restart mode" or not 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 10s 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 whom 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) すぐに(つまり、現在実行中のタイマー間隔が期限切れになるのを待つことなく、「嵐」を避けるためにLANSで数ミリ秒の数ミリ秒のわずかな遅延があります)RRビットを含む再起動TLVを含むIIHを対応するインターフェイスを送信しますClear and RA Bit Setは、(再)開始ルーターから受信した新しい値を反映する「ポイントツーポイント3ウェイ隣接」オプションを更新したポイントツーポイント隣接の場合に設定されています。(これにより、再起動するルーターは、Hellosに配置する正しい情報をすばやく取得できます。)「残り時間」は、この隣接の保持タイマーが期限切れになる前に、現在の時間(秒)に設定する必要があります。対応するインターフェイスがLANインターフェイスである場合、RRビットセットを備えたIIHが受信されたルーターのシステムIDを再起動する隣接システムIDを設定する必要があります。これは、LANの複数のシステムがほぼ同時に再起動する場合に、承認と保持時間を正しく関連付けるために必要です。このIIHは、元のIIHの受領の結果としてLSPまたはSNPが送信される前に送信する必要があります。

c) if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with highest source MAC address breaking ties) among those routers to which the receiving router has an adjacency in state "UP" on this interface whose IIHs contain the restart TLV, excluding adjacencies to all routers which are considered in "Restart mode" (note the actual 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) 対応するインターフェイスがポイントツーポイントインターフェイスである場合、または受信ルーターがこのインターフェイスの隣接を「上」にしているルーターの中で、受信ルーターが最も高いソースMACアドレス速報タイを持つ)を持っている場合IIHには、「再起動モード」で検討されているすべてのルーターへの隣接を除くRestArt TLVが含まれています(このプロセスによって実際のDISは変更されないことに注意してください)、CSNPの完全なセットの対応するインターフェイス上の伝送を開始し、SRMFLAGSをセットしますローカルLSPデータベースのすべてのLSPの対応するインターフェイス。

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の「上」状態に隣接がない場合)、隣接を再活性化し、返されたIIHにRAビットを設定することにより、通常どおりにIIHを処理します。

3.2.2. Use of the SA Bit
3.2.2. SAビットの使用

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 which 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 state "UP" 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を受信した場合、このインターフェイスに同じシステムIDを持つ状態の隣接性が「アップ」、LAN回路の場合、同じソースLANアドレスを持つLAN回路の場合に存在する場合、次に、ルーターは、隣人への隣人のLSPの広告を抑制する必要があります。SAビットがクリアされたIIHが受信されるまで、近隣の広告は引き続き抑制されなければなりません。隣接する隣接が「上」状態に移行した場合、SAビットがクリアされたIIHが受信されるまで、新しい隣接を宣伝してはなりません。

Note that a router which 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 [2] 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計算を実行するときにこの隣接を使用してはならないことに注意してください。特に、実装が[2] Annex c.2.5ステップ0に示されている例のガイドラインに従っている場合、b)「ローカル隣接データベースでテントを事前にロードする」、抑制された隣接をテントにロードしてはなりません。

3.3. Adjacency (Re)Acquisition
3.3. 隣接(再)買収

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ビットを使用しますが、それぞれが(再)開始手順の異なる段階で使用します。

3.3.1. Adjacency Reacquisition During Restart
3.3.1. 再起動中の隣接する再取得

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 state "UP" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the procedures described in 3.2.1 are followed.

再起動するルーターは、隣接が隣接性が再取得されていることを明示的に通知し、したがって隣接を再現するべきではないことを明示的に通知します。これは、再起動TLVにRRビットを設定することで実現されます。再起動ルーターの隣人がRRビットセットを備えた再起動ルーターの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を開始し、再起動する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.

ポイントツーポイントサーキットでは、再起動ルーターが「隣接する3者状態」を「init」に設定する必要があります。。

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は、再起動前に使用されたLANと同じでなければなりません。特に、再起動するルーターが以前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.

「通常の」IIHSの伝達は、以下の条件が満たされるまで阻害されます(不必要な隣接の初期化を引き起こすことを避けるため)。タイマー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 which 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を備えたLANサーキットに)、領収書は領収書をそのインターフェイスをめぐる承認のことが記載されています。RAビットが設定され、リモート隣接の状態が「上」になると、タイマー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 cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which 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.

ポイントツーポイントリンクでは、再起動TLVを含んでいないIIHの受領も確認として扱われます。これは、隣人が再起動能力がないことを示すためです。ただし、このインターフェイスでCSNPが受信されることは保証されていないため、CSNPの完全なセットを待つことなく、タイマーT1はすぐにキャンセルされます。したがって、同期は、この隣人によって(のみ)保持されているLSPがあるにもかかわらず、完全であると見なされる場合があります(セクション3.4を参照)。この場合、SRMFLAGがデータベースに設定されていることを保証するために、隣人が隣接を再現していることを確認したいと考えています。これは、受信されたIIHの隣接する3方向の状態が「上」であり、隣接するローカル回路IDが再起動ルーターによって割り当てられた拡張ローカル回路IDと一致する場合を除き、発生することが保証されます。この場合、再起動ルーターは、ローカル隣接の3方向の状態を「ダウン」し、通常の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の受領は、同期が再開されていないRESTARTをサポートする非再起動隣接ルーターの少なくとも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 3-way handshake information. The presence of "Neighbor Extended Local Circuit ID" information which 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 CSNP(s) (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 cancelled.

CSNPの完全なセット(各アクティブレベル、ポイントツーポイント回路の場合)とインターフェイスを介して確認が受信された場合、タイマーT1がキャンセルされます。

Once the timer T1 has been cancelled, 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 cancelled, and according to clause 3.4.1.1, the SPF would never be run. Therefore timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1).

インターフェイスがアクティブであるが、そのインターフェイス上で隣接するルーターが到達できない場合、タイマーT1は決してキャンセルされず、3.4.1.1項に従って、SPFは実行されません。したがって、タイマーT1は、いくつかの事前に決定された数の有効期限(1)の後にキャンセルされます。

3.3.2. Adjacency Acquisition During Start
3.3.2. 開始中の隣接獲得

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.

開始ルーターは、隣接するルーターが「上」状態の開始ルーター(開始ルーターの以前の化身から)に隣接している場合、この隣接性が再活性化されることを保証したいと考えています。また、開始ルーターは、LSPデータベースの同期が達成されるまで、隣接するルーターが開始ルーターへの隣接の広告を抑制することを望んでいます。これは、RRビットクリアでIIHSを送信し、SAビットを再起動TLVでセットすることで達成されます。RRビットは明確なままであり、SAビットは隣接が「UP」状態に達し、初期のT1タイマー間隔(以下を参照)が期限切れになるまでIIHSのその後の送信に設定されたままです。

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 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ビットクリアで再起動TLVを含むIIHを送信し、SAを送信します。ビットセット。タイマーT1の有効期限が切れると、再起動され、IIHはRRビットセットとSAビットセットの両方で再送信されます(RRビットのみが以前のIIHSから状態を変更しました)。

Upon receipt of an IIH with the RR bit set (regardless of whether the SA is set or not), the behavior described in 3.2.1 is followed.

RRビットセットを備えたIIHを受信すると(SAが設定されているかどうかに関係なく)、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 which matches that of the local system), the receipt of the acknowledgement over that interface is noted.

IIHが開始ルーターによって受信され、IIHがRAビットセットを備えた再起動TLVを含む場合(およびローカルシステムのそれと一致する再起動隣接システム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 cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 3.4).

ポイントツーポイントリンクでは、再起動TLVを含んでいないIIHの受領も確認として扱われます。これは、隣人が再起動能力がないことを示すためです。隣人は隣接を再活性化したため、これによりSRMFLAGがデータベースに設定されていることが保証されているため、最終的なLSPDB同期が確保されます。ただし、このインターフェイスでCSNPが受信されることは保証されていないため、CSNPの完全なセットを待つことなく、タイマーT1はすぐにキャンセルされます。したがって、同期は、この隣人によって(のみ)保持されている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の受領は、同期が再開されていないRESTARTをサポートする非再起動隣接ルーターの少なくとも1つが再開されるため、同期は依然として発生する可能性があるため、目立たないものです。したがって、この場合、T1は引き続き実行されます。LANの隣人のいずれも再起動可能な場合、T1はローカルで定義された回収数の後に最終的に期限切れになります。更新プロセスの通常の操作により、同期が最終的に達成されることが保証されます。

When BOTH a complete set of CSNP(s) (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 cancelled. 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 cancelled after some pre-determined number of expirations (which MAY be 1).

タイマーT1は、いくつかの事前に決定された有効期限(1)の後にキャンセルされます。

When the T2 timer(s) are cancelled or expire, transmission of "normal" IIHs (with RR, RA, and SA bits clear) will begin.

T2タイマーがキャンセルまたは期限切れになると、「通常の」IIH(RR、RA、およびSAビットがクリア)の送信が開始されます。

3.3.3. Multiple Levels
3.3.3. 複数のレベル

A router which 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の両方のIIHSを送信および受信し、各レベルで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同期を個別に実行する必要があります。

3.4. Database Synchronization
3.4. データベースの同期

When a router is started or restarted it can expect to receive a (set of) CSNP(s) 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.

ルーターが起動または再起動されると、各インターフェイスで(s)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 3.3.1 or 3.3.2. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNP(s) 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 neighbor(s) which 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で構成されている必要があります。(再)開始ルーターに複数のインターフェイスがある場合、lspidsの記録されたセットは、各インターフェイスで受信したものの結合です。ゼロの残りの残りの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 cancelled for all the interfaces that have an adjacency at this level, the timer T2 is cancelled.

任意のインターフェイスで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のキャンセルは、LSPを待つことによって防止されません。到着することはありません。

3.4.1. LSP Generation and Flooding and SPF Computation
3.4.1. LSP生成と洪水およびSPF計算

The operation of a router starting, as opposed to restarting, is somewhat different. These two cases are dealt with separately below.

再起動とは対照的に、ルーターの操作は多少異なります。これらの2つのケースは、以下で別々に扱われます。

3.4.1.1. Restarting
3.4.1.1. 再起動

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 re-established 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 which is to be propagated can be included in the Level-n LSP(s).

このルーターのLSPが他のノードに浸水する前に、レベル間情報の再分布を再生する必要があります。したがって、レベル-Nの非義理のLSP(s)を浸水させてはならず、他のレベルのT2タイマーが失効し、そのSPFが実行されるまで浸水してはなりません。これにより、伝播すべきレベル間情報をレベル-N LSP(s)に含めることができます。

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.

この期間中、ルーター自身の1つ(擬似ノードを含む)LSPが受信された場合、ローカルルーターが現在独自のデータベースに持っていない場合、それはパージされていません。通常の操作では、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 which have been received, not on versions which have been generated (but not yet transmitted). This restriction is necessary to prevent premature removal of an LSP from the global LSP database.

この期間中、再起動ルーターは通常のようにCSNPを送信する必要があります。ルーター自身のLSPに関する情報は含まれている場合がありますが、それが含まれている場合は、生成されたバージョンではなく、受信されたLSPに基づいている必要があります(まだ送信されていません)。この制限は、グローバルLSPデータベースからLSPの早期除去を防ぐために必要です。

When the timer T2 expires or is cancelled indicating that synchronization for that level is complete, the SPF for that level is run in order to derive any information which 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 which were previously ignored, but which 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 which it previously owned, but which are now no longer part of its set of pseudonode LSPs.

他のレベルのSPFが実行され、レベル間の伝播が解決されると、ルーター自身のLSPを生成して浸水させることができます。以前に無視されていたが、現在の独自のLSP(偽節を含む)の一部ではない独自のLSPをパージする必要があります。指定されたルーターの変更が行われた可能性があることに注意してください。その結果、ルーターは以前に所有していたが、現在では一連の擬似ノードLSPの一部ではなくなった擬似型LSPをパージする必要があることに注意してください。

When all the T2 timers have expired or been cancelled, the timer T3 is cancelled and the local forwarding tables are updated.

すべてのT2タイマーが期限切れまたはキャンセルされた場合、タイマーT3がキャンセルされ、ローカル転送テーブルが更新されます。

If the timer T3 expires before all the T2 timers have expired or been cancelled, 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 which 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 cancelled.

すべてのT2タイマーが失効またはキャンセルされる前にタイマーT3が期限切れになった場合、これは、同期プロセスが近隣の最小保持時間よりも長くかかっていることを示しています。最初のSPF計算をまだ完了していないレベルのルーター自身のLSPは、ルーターのLSPDBがまだ同期していないことを示すために、過負荷ビットであふれています(したがって、他のルーターはこのルーターを介してルーターを計算してはなりません)。更新プロセスの通常の操作履歴書とローカル転送テーブルが更新されます。隣人の隣接が期限切れになるのを防ぐために、保持時間の通常のインターフェイス値を持つIIHSは、再起動TLVにRRもRAも設定されていないすべてのインターフェイスで送信されます。これにより、隣人は隣接をリフレッシュします。ルーター自身のLSP(S)は、タイマーT2が期限切れまたはキャンセルされるまで、オーバーロードビットを引き続き設定します。

3.4.1.2. Starting
3.4.1.2. 起動

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が実行されている間に、ゼロスLSPのその後の送信(ルーター自身のゼロスLSPの以前のコピーがまだネットワークに存在する場合に発生するなど)に設定されたままです。

When all the T2 timers have been cancelled, 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 RIB and 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 3.3.2) in all IIHs that it sends.

一時的なブラックホールの形成の可能性を回避するために、開始ルーターは、送信するすべてのIIHの再起動TLV(3.3.2に記載)にSAビットを設定します。

When all T2 timers have been cancelled, the starting router MUST transmit IIHs with the SA bit clear.

すべてのT2タイマーがキャンセルされた場合、開始ルーターはSAビットクリアでIIHを送信する必要があります。

4. State Tables
4. 状態表

This section presents state tables which summarize the behaviors described in this document. Other behaviors, in particular adjacency state transitions and LSP database update operation, are NOT included in the state tables except where this document modifies the behaviors described in [2] and [4].

このセクションでは、このドキュメントに記載されている動作を要約する状態表を示します。その他の動作、特に隣接する状態遷移およびLSPデータベース更新操作は、このドキュメントが[2]および[4]で説明されている動作を変更する場合を除き、状態表には含まれていません。

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 which are indicative of the state of the protocol instance (Running, Restarting, Starting, SPF Wait).

以下の表の列に命名された状態は、単一の隣接性(adj抑制、adjが見たra、csnpが見た)に固有の状態と、プロトコルインスタンスの状態(実行、再起動の状態を示す状態の混合物です。、開始、SPF待機)。

Three state tables are presented from the point of view of a running router, a restarting router, and a starting router.

実行中のルーター、再起動ルーター、および開始ルーターの観点から3つの状態テーブルが表示されます。

4.1. Running Router
4.1. ランニングルーター
 Event       | Running              | ADJ suppressed
==============================================================
 RX RR       | Maintain ADJ State   |
             | Send RA              |
             | Set SRM,send CSNP    |
             |  (Note 1)            |
             | Update Hold Time,    |
             |  set Restart Mode    |
             |  (Note 2)            |
-------------+----------------------+-------------------------
 RX RR clr   | Clr Restart mode     |
-------------+----------------------+-------------------------
 RX SA       | Suppress IS neighbor |
             |   TLV in LSP(s)      |
             | Goto ADJ Suppressed  |
-------------+----------------------+-------------------------
 RX SA clr   |                      |Unsuppress IS neighbor
             |                      |   TLV in LSP(s)
             |                      |Goto Running
==============================================================
        

Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c Note 2: If Restart Mode clear

注1:CSNPはセクション3.2.1cに従ってルーターによって送信されます注2:再起動モードがクリアされている場合

4.2. Restarting Router
4.2. ルーターの再起動
 Event      | Restarting         | ADJ Seen  | ADJ Seen  | SPF Wait
            |                    |    RA     |   CSNP    |
===================================================================
 Router     | Send IIH/RR        |           |           |
  restarts  | ADJ Init           |           |           |
            | Start T1,T2,T3     |           |           |
------------+--------------------+-----------+-----------+------------
 RX RR      | Send RA            |           |           |
------------+--------------------+-----------+-----------+------------
 RX RA      | Adjust T3          |           | Cancel T1 |
            | Goto ADJ Seen RA   |           | Adjust T3 |
----------- +--------------------+-----------+-----------+------------
 RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 |           |
------------+--------------------+-----------+-----------+------------
 RX IIH w/o | Cancel T1 (Point-  |           |           |
 Restart TLV|  to-point only)    |           |           |
------------+--------------------+-----------+-----------+------------
 T1 Expires | Send IIH/RR        |Send IIH/RR|Send IIH/RR|
            | Restart T1         | Restart T1| Restart T1|
------------+--------------------+-----------+-----------+------------
 T1 Expires | Send IIH/          | Send IIH/ | Send IIH/ |
  nth time  |   normal           |   normal  |   normal  |
------------+--------------------+-----------+-----------+------------
 T2 expires | Trigger SPF        |           |           |
            | Goto SPF Wait      |           |           |
------------+--------------------+-----------+-----------+------------
 T3 expires | Set OL             |           |           |
            | Flood local LSPs   |           |           |
            | Update fwd plane   |           |           |
------------+--------------------+-----------+-----------+------------
 LSP DB Sync| Cancel T2, and T3  |           |           |
            | Trigger SPF        |           |           |
            | Goto SPF wait      |           |           |
------------+--------------------+-----------+-----------+------------
All SPF     |                    |           |           | Clear OL
  done      |                    |           |           | Update fwd
            |                    |           |           |  plane
            |                    |           |           | Flood local
            |                    |           |           |   LSPs
            |                    |           |           | Goto Running
======================================================================
4.3.  Starting Router
        
 Event       | Starting          | ADJ Seen RA| ADJ Seen CSNP
=============================================================
Router       | Send IIH/SA       |            |
  starts     | Start T1,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     | Cancel T1         |            |
  no Restart | (Point-to-Point   |            |
  TLV        |   only)           |            |
-------------+-------------------+------------+---------------
ADJ UP       | Start T1          |            |
             | Send local LSPs   |            |
             |  w OL             |            |
-------------+-------------------+------------+---------------
T1 Expires   | Send IIH/RR       |Send IIH/RR | Send IIH/RR
             |   and SA          |   and SA   |   and SA
             | Restart T1        |Restart T1  | Restart T1
-------------+-------------------+------------+---------------
T1 Expires   | Send IIH/SA       |Send IIH/SA | Send IIH/SA
 nth time    |                   |            |
-------------+-------------------+------------+---------------
T2 expires   | Clear OL          |            |
             | Send IIH normal   |            |
             | Goto Running      |            |
-------------+-------------------+------------+---------------
LSP DB Sync  | Cancel T2         |            |
             | Clear OL          |            |
             | Send IIH normal   |            |
==============================================================
        
5. Security Considerations
5. セキュリティに関する考慮事項

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を注入する能力に依存します。その容易さ/難易度は変更されていません。

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を受け取った隣人は、「上」状態で既存の隣接を維持し続け、CSNPの完全なセットを(再)送信することができます。後者のアクションは無駄ですが、どちらのアクションも正しいプロトコル操作の混乱を引き起こしません。

If the RA bit is set in a false IIH, a (re)starting router which receives such an IIH may falsely believe that there is a neighbor on the corresponding interface which 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ビットがfalse iihに設定されている場合、そのようなiihを受信する(再)起動ルーターは、このドキュメントで説明されている手順をサポートする対応するインターフェイスに隣人がいると誤って信じるかもしれません。そのインターフェイスでCSNPの完全なセットを受信していない場合、これにより、タイマーT1がローカルで定義された最大回収数をタイムアウトする必要があることにより、(再)開始手順の完了を遅らせる可能性があります。この動作は、LANで発生するのと同じです。LANでは、このドキュメントの手順をサポートし、セクション3.3.1および3.3.2でカバーされている(再)開始ルーターの隣人がいない場合と同じです。

If an 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に設定されている場合、これにより、ANの広告の抑制を引き起こす可能性があります。/またはLSP洪水とSPF計算の頻度の増加。

The possibility of IS-IS PDU spoofing can be reduced by the use of authentication as described in [1] and [2], and especially the use of cryptographic authentication as described in [5].

IS-I-IS PDUスプーフィングの可能性は、[1]および[2]に記載されている認証の使用、特に[5]で説明されている暗号化認証の使用によって減少する可能性があります。

6. IANA Considerations
6. IANAの考慮事項

This document defines the following IS-IS TLV that is listed in the IS-IS TLV code-point registry:

このドキュメントでは、IS-IS TLVコードポイントレジストリにリストされている次のIS-IS TLVを定義します。

   Type        Description                            IIH   LSP   SNP
   ----        -----------------------------------    ---   ---   ---
   211         Restart TLV                              y     n     n
        
7. Normative References
7. 引用文献

[1] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.

[1] Callon、R。、「OSIはIPおよびデュアル環境のIS-IS」、RFC 1195、1990年12月。

[2] ISO, "Intermediate system to Intermediate system 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.

[2] ISO、「Connectionless-Mode Network Service(ISO 8473)を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをルーティングする中間システム(ISO 8473)」、ISO/IEC 10589:2002、第2版。

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[4] Katz, D. and R. Saluja, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 3373, September 2002.

[4] Katz、D。およびR. Saluja、「IS-ISポイントツーポイント隣接の3方向の握手」、RFC 3373、2002年9月。

[5] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.

[5] Li、T。およびR. Atkinson、「中間システムから中間システム(IS-IS)暗号化認証」、RFC 3567、2003年7月。

8. Acknowledgements
8. 謝辞

The authors would like to acknowledge contributions made by Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang.

著者は、ジェフ・パーカー、ラディア・パールマン、マーク・シェーファー、ナイミング・シェン、ニシュカル・シェス、ラス・ホワイト、レナ・ヤンによる貢献を認めたいと思います。

9. Authors' Addresses
9. 著者のアドレス

Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK Phone: +44 208 824 8690

Mike Shand Cisco Systems 250 Longwater Avenue、Reading、Berkshire、RG2 6GB UK電話:44 208 824 8690

   EMail: mshand@cisco.com
        

Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USA

Les Ginsberg Cisco Systems 510 McCarthy Blvd.ミルピタス、カリフォルニア州95035 USA

   EMail: ginsberg@cisco.com
        
10. 完全な著作権声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

著作権(c)The Internet Society(2004)。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。