RFC4811 日本語訳
4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization. L.Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT=18976 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Nguyen Request for Comments: 4811 A. Roy Category: Informational Cisco Systems A. Zinin Alcatel-Lucent March 2007
Nguyenがコメントのために要求するワーキンググループL.をネットワークでつないでください: 4811年のA.ロイカテゴリ: 2007年3月にアルカテル透明な情報のシスコシステムズのA.ジニン
OSPF Out-of-Band Link State Database (LSDB) Resynchronization
バンドで出ているOSPFは州のデータベース(LSDB)Resynchronizationをリンクします。
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.
OSPFはIPネットワークに使用されるリンク州のイントラドメインルーティング・プロトコルです。 OSPFでのリンク州Database(LSDB)同期は2つの方法で達成されます--OSPFルータがちょうどネットワークに関連づけられたところなときの初期のLSDB同期と初期プロシージャが完成した後にトポロジー変化があるとき連続したLSDB同期を確実にする非同期な氾濫。 それはいつか、必要であるかもしれません。OSPFルータがそれらのLSDBsを再連動させるには、必要であってください。 しかしながら、OSPF規格で、実際にネットワークのトポロジー眺望を変えないで、ルータはそうしません。
This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard.
このメモは、バンドの外のそのようなフォームLSDB同期を実行するために業者特有のメカニズムについて説明します。 RFC3623で説明されるGraceful OSPF Restartが生まれる前に本書では説明されたメカニズムは提案されました。 それは、少なくとも1つの一流の業者によって実行されるか、または支持されて、現在、その分野で配備されます。 このドキュメントの目的は公共の使用のためにこのメカニズムの細部を得ることです。 このメカニズムはIETF規格ではありません。
Nguyen, et al. Informational [Page 1] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[1ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
Table of Contents
目次
1. Introduction ....................................................2 2. Proposed Solution ...............................................2 2.1. The LR-Bit .................................................3 2.2. OSPF Neighbor Data Structure ...............................3 2.3. Hello Packets ..............................................4 2.4. DBD Packets ................................................4 2.5. Neighbor State Treatment ...................................7 2.6. Initiating OOB LSDB Resynchronization ......................7 3. Backward Compatibility ..........................................7 4. Security Considerations .........................................7 5. IANA Considerations .............................................7 6. References ......................................................8 6.1. Normative References .......................................8 6.2. Informative References .....................................8 Appendix A. Acknowledgements ......................................9
1. 序論…2 2. ソリューションを提案します…2 2.1. LR-ビット…3 2.2. OSPF隣人データ構造…3 2.3. こんにちは、パケット…4 2.4. DBDパケット…4 2.5. 隣人は処理を述べます…7 2.6. OOB LSDB Resynchronizationを開始します…7 3. 後方の互換性…7 4. セキュリティ問題…7 5. IANA問題…7 6. 参照…8 6.1. 標準の参照…8 6.2. 有益な参照…8 付録A.承認…9
1. Introduction
1. 序論
According to the OSPF standard [RFC2328], after two OSPF routers have established an adjacency (the neighbor Finite State Machines (FSMs) have reached Full state), routers announce the adjacency states in their router-Link State Advertisements (LSAs). Asynchronous flooding algorithm ensures that routers' LSDBs stay in sync in the presence of topology changes. However, if routers need (for some reason) to resynchronize their LSDBs, they cannot do that without actually putting the neighbor FSMs into the ExStart state. This effectively causes the adjacencies to be removed from the router-LSAs, which may not be acceptable if the desire is to prevent routing table flaps during database resynchronization. In this document, we provide the means for so-called out-of-band (OOB) LSDB resynchronization.
OSPF規格[RFC2328]によると、2つのOSPFルータが隣接番組を確立した(隣人Finite州Machines(FSMs)はFull状態に達しました)後にルータはそれらのルータリンク州Advertisements(LSAs)で隣接番組州を発表します。 非同期な氾濫アルゴリズムは、トポロジー変化があるときルータのLSDBsが同時性で滞在するのを確実にします。 しかしながら、ルータが、それらのLSDBsを再連動させる必要があるなら(ある理由で)、実際にExStart状態に隣人FSMsを入れないで、彼らはそれができません。 これで、事実上、ルータ-LSAs再同期から隣接番組を取り除きます。(LSAsは願望がデータベースの間、経路指定テーブルフラップを防ぐことであるなら許容できないかもしれません)。 本書では、私たちはいわゆるバンドで出ている(OOB)LSDB resynchronizationに手段を供給します。
The described mechanism can be used in a number of situations including those where the routers are picking up the adjacencies after a reload. The process of adjacency preemption is outside the scope of this document. Only the details related to LSDB resynchronization are mentioned herein.
ルータが再ロードの後に隣接番組を拾っているところのものを含む多くの状況で説明されたメカニズムを使用できます。 このドキュメントの範囲の外に隣接番組先取りの過程があります。 LSDB resynchronizationに関連する詳細だけがここに言及されます。
2. Proposed Solution
2. 提案されたソリューション
With this Out-of-Band Resynchronization Solution, the format of the OSPF Database Description (DBD) packet is changed to include a new R-bit indicating OOB LSDB resynchronization. All DBD packets sent during the OOB resynchronization procedure are sent with the R-bit set.
このバンドのOut Resynchronizationソリューションで、OOB LSDB resynchronizationを示しながら新しいR-ビットを含むようにOSPF Database記述(DBD)パケットの形式を変えます。 R-ビットセットでOOB resynchronization手順の間に送られたすべてのDBDパケットを送ります。
Nguyen, et al. Informational [Page 2] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[2ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
Also, two new fields are added to the neighbor data structure. The first field indicates a neighbor's OOB resynchronization capability. The second indicates that OOB LSDB resynchronization is in process. The latter field allows OSPF implementations to utilize the existing neighbor FSM code.
また、2つの新しい分野が隣人データ構造に追加されます。 最初の分野は隣人のOOB resynchronization能力を示します。 2番目は、OOB LSDB resynchronizationが過程にあるのを示します。 後者の分野で、OSPF実現は既存の隣人FSMコードを利用できます。
A bit is occupied in the Extended Options (EO) TLV (see [RFC4813]). Routers set this bit to indicate their capability to support the described technique.
Extended Options(EO)TLV([RFC4813]を見る)で少し占領されます。 ルータは、このビットに説明されたテクニックをサポートする彼らの能力を示すように設定します。
2.1. The LR-Bit
2.1. LR-ビット
A new bit, called LR (LR stands for LSDB Resynchronization), is introduced to the LLS Extended Options TLV (see [RFC4813]). The value of the bit is 0x00000001; see Figure 1. See the "IANA Considerations" section of [RFC4813] for more information on the Extended Options bit definitions. Routers set the LR-bit to announce OOB LSDB resynchronization capability.
LR(LRはLSDB Resynchronizationを表す)と呼ばれる新しいビットはLLS Extended Options TLVに紹介されます([RFC4813]を見てください)。 ビットの価値は0×00000001です。 図1を見てください。 Extended Optionsに関する詳しい情報のための[RFC4813]の「IANA問題」セクションが定義に噛み付いたのを確実にしてください。 ルータは、LR-ビットにOOB LSDB resynchronization能力を発表するように設定します。
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ | * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | LR| +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ | * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | LR| +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
Figure 1. The Options Field
図1。 オプション分野
Routers supporting the OOB LSDB resynchronization technique set the LR-bit in the EO-TLV in the LLS block attached to both Hello and DBD packets. Note that no bit is set in the standard OSPF Options field, neither in OSPF packets nor in LSAs.
OOB LSDB resynchronizationのテクニックをサポートするルータがHelloとDBDパケットの両方に添付されたLLSブロックでLR-ビットをEO-TLVにはめ込みます。 ビットが全く標準のOSPF Options分野、どちらもOSPFパケットかLSAsに設定されないことに注意してください。
2.2. OSPF Neighbor Data Structure
2.2. OSPF隣人データ構造
A field is introduced into OSPF neighbor data structure, as described below. The name of the field is OOBResync, and it is a flag indicating that the router is currently performing OOB LSDB resynchronization with the neighbor.
野原は以下で説明されるようにOSPF隣人データ構造に取り入れられます。 分野の名前はOOBResyncです、そして、それはルータが現在隣人と共にOOB LSDB resynchronizationを実行しているのを示す旗です。
The OOBResync flag is set when the router is initiating OOB LSDB resynchronization (see Section 2.6 for more details).
ルータがOOB LSDB resynchronizationを開始しているとき(その他の詳細に関してセクション2.6を見てください)、OOBResync旗は設定されます。
Routers clear the OOBResync flag on the following conditions:
ルータは以下の条件でOOBResync旗をきれいにします:
o The neighbor data structure is first created.
o 隣人データ構造は最初に、作成されます。
o The neighbor FSM transitions to any state lower than ExStart.
o 隣人FSMはExStartより低どんな状態にも移行します。
o The neighbor FSM transitions to the ExStart state because a DBD packet with the R-bit clear has been received.
o 隣人FSMは、R-ビットが明確のDBDパケットを受け取ったので、ExStart状態に移行します。
Nguyen, et al. Informational [Page 3] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[3ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
o The neighbor FSM reaches the state Full.
o 隣人FSMは州のFullに達します。
Note that the OOBResync flag may have a TRUE value only if the neighbor FSM is in states ExStart, Exchange, or Loading. As indicated above, if the FSM transitions to any other state, the OOBResync flag should be cleared.
隣人FSMが州のExStart、Exchange、またはLoadingにある場合にだけOOBResync旗にはTRUE値があるかもしれないことに注意してください。 上で示されるように、FSMがいかなる他の状態にも移行するなら、OOBResync旗はきれいにされるべきです。
It is important to mention that operation of the OSPF neighbor FSM is not changed by this document. However, depending on the state of the OOBResync flag, the router sends either normal DBD packets or DBD packets with the R-bit set.
OSPF隣人FSMの操作がこのドキュメントによって変えられないと言及するのは重要です。 しかしながら、OOBResync旗の状態によって、ルータはR-ビットセットがある正常なDBDパケットかDBDパケットを送ります。
2.3. Hello Packets
2.3. こんにちは、パケット
Routers capable of performing OOB LSDB resynchronization should always set the LR-bit in their Hello packets.
OOB LSDB resynchronizationを実行できるルータはいつもそれらのHelloパケットにLR-ビットをはめ込むべきです。
2.4. DBD Packets
2.4. DBDパケット
Routers supporting the described technique should always set the LR- bit in the DBD packets. Since the Options field of the initial DBD packet is stored in corresponding neighbor data structure, the LR-bit may be used later to check if a neighbor is capable of performing OOB LSDB resynchronization.
説明されたテクニックをサポートするルータはいつもDBDパケットにLRビットをはめ込むべきです。 初期のDBDパケットのOptions野原が対応する隣人データ構造に格納されるので、LR-ビットは後で隣人がOOB LSDB resynchronizationを実行できるかどうかチェックするのに使用されるかもしれません。
The format of type 2 (DBD) OSPF packets is changed to include a flag indicating the OOB LSDB resynchronization procedure. Figure 2 illustrates the new packet format.
OOB LSDB resynchronization手順を示す旗を含むようにタイプ2(DBD)OSPFパケットの形式を変えます。 図2は新しいパケット・フォーマットを例証します。
Nguyen, et al. Informational [Page 4] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[4ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 2 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface MTU | Options |0|0|0|0|R|I|M|MS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- An LSA Header -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 2 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| AuType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースMTU| オプション|0|0|0|0|R|I|M|+++++++++++++++++++++++++++++++++さん| DD一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | + LSAヘッダー-+| | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Figure 2. Modified DBD Packet
図2。 変更されたDBDパケット
The R-bit in OSPF type 2 packets is set when the OOBResync flag for the specific neighbor is set to TRUE. If a DBD packets with the R- bit clear is received for a neighbor with active OOBResync flag, the OOB LSDB resynchronization process is canceled and normal LSDB synchronization procedure is initiated.
特定の隣人のためのOOBResync旗がTRUEに設定されるとき、R-ビットはOSPFタイプ2パケットに設定されます。 RビットがあるDBDパケットであるなら明確であるのが、隣人のためにアクティブなOOBResyncと共に受け取って、旗、OOB LSDB resynchronizationの過程が取り消されるということであり、正常なLSDB同期手順は着手されます。
When a DBD packet is received with the R-bit set and the sender is known to be OOB-incapable, the packet should be dropped and a SeqNumber-Mismatch event should be generated for the neighbor.
R-ビットセットでDBDパケットを受け取って、OOB不可能であることを送付者を知っているとき、パケットを落とすべきです、そして、隣人のためにSeqNumber-ミスマッチ出来事を発生させるべきです。
Nguyen, et al. Informational [Page 5] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[5ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
Processing of DBD packets is modified as follows:
DBDパケットの処理は以下の通り変更されます:
1. If the OOBResync flag for the neighbor is set (the LSDB resynchronization process has been started) and the received DBD packet does not have the R-bit set, ignore the packet and generate a SeqNumberMismatch event for the neighbor FSM.
1. 隣人のためのOOBResync旗が設定されて(LSDB resynchronizationの過程は始められました)、容認されたDBDパケットでR-ビットを設定しないなら、パケットを無視してください、そして、隣人FSMのためにSeqNumberMismatch出来事を発生させてください。
2. Otherwise, if the OOBResync flag for the neighbor is clear and the received DBD packet has the R-bit set, perform the following steps:
2. さもなければ、隣人のためのOOBResync旗が明確であり、容認されたDBDパケットでR-ビットを設定するなら、以下のステップを実行してください:
* If the neighbor FSM is in state Full and bits I, M, and MS are set in the DBD packet, set the OOBResync flag for the neighbor, put the FSM in ExStart state, and continue processing the DBD packet as described in [RFC2328].
* 隣人FSMが州のFullとビットにあるなら、私、M、およびMSは、DBDパケットに設定されて、OOBResync旗を隣人に設定して、ExStart状態にFSMを置いて、[RFC2328]で説明されるようにDBDパケットを処理し続けています。
* Otherwise, ignore received DBD packet (no OOB DBD packets are allowed with OOBResync flag clear and FSM in state other than Full). Also, if the state of the FSM is Exchange or higher, generate a SeqNumberMismatch event for the neighbor FSM.
* さもなければ、容認されたDBDパケットを無視してください(OOB DBDパケットは全く明確なOOBResync旗とFull以外の状態のFSMと共に許容されていません)。 また、FSMの州がExchangeか、より高いなら、隣人FSMのためにSeqNumberMismatch出来事を発生させてください。
3. Otherwise, process the DBD packet as described in [RFC2328].
3. さもなければ、[RFC2328]で説明されるようにDBDパケットを処理してください。
During normal processing of the initial OOB DBD packet (with bits R, I, M, and MS set), if the receiving router is selected to be the Master, it may speed up the resynchronization process by immediately replying to the received packet.
初期のOOB DBDパケット(R、私、M、およびMSが設定するビットがある)の正常処理の間、受信ルータがMasterであることが選択されるなら、それは、すぐにまでに容認されたパケットに答えながら、再同期の過程を早くするかもしれません。
It is also necessary to limit the time an adjacency can spend in ExStart, Exchange, and Loading states with OOBResync flag set to a finite period of time (e.g., by limiting the number of times DBD and link state request packets can be retransmitted). If the adjacency does not proceed to Full state before the timeout, it is indicative that the neighboring router cannot resynchronize its LSDB with the local router. The requesting router may decide to stop trying to resynchronize the LSDB over this adjacency (if, for example, it can be resynchronized via another neighbor on the same segment) or to resynchronize using the legacy method by clearing the OOBResync flag and leaving the FSM in ExStart state. The neighboring router may decide to cancel the OOB procedure for the neighbor.
また、隣接番組が有限期間までExStart、Exchange、およびLoading州でOOBResync旗のセットと過ごすことができる時間を制限するのも必要です(例えば、回数を制限することによって、DBDとリンク州のリクエスト・パケットを再送できます)。 隣接番組がタイムアウトの前にFull状態に進まないなら、隣接しているルータがローカルルータでLSDBを再連動させることができないのは、暗示しています。 要求ルータは、この隣接番組(例えば、それが同じセグメントの別の隣人を通して再連動できるなら)の上でLSDBを再連動させようとするのを止めるか、またはOOBResync旗をきれいにすることによって遺産方法を使用して、ExStartのFSMを状態に発って、再連動すると決めるかもしれません。 隣接しているルータは、隣人のためにOOB手順を取り消すと決めるかもしれません。
Nguyen, et al. Informational [Page 6] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[6ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
2.5. Neighbor State Treatment
2.5. 隣人州の処理
An OSPF implementation supporting the described technique should modify the logic consulting the state of a neighbor FSM as described below.
説明されたテクニックをサポートするOSPF実現は以下で説明されるように隣人FSMの州に相談する論理を変更するべきです。
o FSM state transitioning from and to the Full state with the OOBResync flag set should not cause origination of a new version of router-LSA or network-LSA.
o OOBResync旗のセットに従って状態とFull状態に移行するFSM州はルータ-LSAかネットワーク-LSAの新しいバージョンの創作を引き起こすべきではありません。
o Any explicit checks for the Full state of a neighbor FSM for the purposes other than LSDB synchronization and flooding should treat states ExStart, Exchange, and Loading as state Full, provided that OOBResync flag is set for the neighbor. (Flooding and MaxAge-LSA-specific procedures should not check the state of the OOBResync flag, but should continue consulting only the FSM state.)
o LSDB同期と氾濫以外の目的のための隣人FSMのFull州へのどんな明白なチェックも州のFullとして州のExStart、Exchange、およびLoadingを扱うべきです、OOBResync旗が隣人に設定されれば。 (氾濫とMaxAge-LSA特有の手順は、OOBResync旗の状態をチェックするべきではありませんが、FSM状態だけに相談し続けるべきです。)
2.6. Initiating OOB LSDB Resynchronization
2.6. OOB LSDB Resynchronizationを開始します。
To initiate out-of-band LSDB resynchronization, the router must first make sure that the corresponding neighbor supports this technology (by checking the LR-bit in the Options field of the neighbor data structure). If the neighboring router is capable, the OOBResync flag for the neighbor should be set to TRUE and the FSM state should be forced to ExStart.
バンドの外でLSDB resynchronizationを開始するために、ルータは、最初に、対応する隣人がこの技術(隣人データ構造のOptions分野でLR-ビットをチェックするのによる)を支持するのを確実にしなければなりません。 隣接しているルータができるなら、隣人のためのOOBResync旗はTRUEに設定されるべきです、そして、FSM状態はExStartに強制されるべきです。
3. Backward Compatibility
3. 後方の互換性
Because OOB-capable routers explicitly indicate their capability by setting the corresponding bit in the Options field, no DBD packets with the R-bit set are sent to OOB-incapable routers.
OOBできるルータがOptions分野に対応するビットをはめ込むことによって明らかに彼らの能力を示すので、R-ビットセットがあるDBDパケットを全くOOB不可能なルータに送りません。
The LR-bit itself is transparent for OSPF implementations and does not affect communication between routers.
LR-ビット自体は、OSPF実現に透明であり、ルータの間でコミュニケーションに影響しません。
4. Security Considerations
4. セキュリティ問題
The described technique does not introduce any new security issues into the OSPF protocol.
説明されたテクニックはどんな新しい安全保障問題もOSPFプロトコルに取り入れません。
5. IANA Considerations
5. IANA問題
Please refer to the "IANA Considerations" section of [RFC4813] for more information on the Extended Options bit definitions.
Extended Optionsビット定義に関する詳しい情報について[RFC4813]の「IANA問題」セクションを参照してください。
Nguyen, et al. Informational [Page 7] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[7ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623] MoyとJ.とPillay-Esnault、P.とA.Lindem、「優雅なOSPFは再開する」RFC3623、2003年11月。
6.2. Informative References
6.2. 有益な参照
[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
[RFC4813] フリードマン、B.、Nguyen、L.、ロイ、A.、Yeung、D.、およびA.ジニン、「OSPFのリンク地方のシグナリング」、RFC4813、2007年3月。
Nguyen, et al. Informational [Page 8] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[8ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
Appendix A. Acknowledgments
付録A.承認
The authors would like to thank Acee Lindem, Russ White, Don Slice, and Alvaro Retana for their valuable comments.
作者は彼らの貴重なコメントについてAcee Lindem、ラス・ホワイト、ドンSlice、およびアルバロ・レタナに感謝したがっています。
Authors' Addresses
作者のアドレス
Liem Nguyen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: lhnguyen@cisco.com
西タスマン・DriveリームNguyenシスコシステムズ225カリフォルニア95134サンノゼ(米国)はメールされます: lhnguyen@cisco.com
Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: akr@cisco.com
西タスマン・Drive Abhayロイシスコシステムズ225カリフォルニア95134サンノゼ(米国)はメールされます: akr@cisco.com
Alex Zinin Alcatel-Lucent Mountain View, CA USA EMail: alex.zinin@alcatel-lucent.com
アレックスジニン・アルカテル透明なカリフォルニアマウンテンビュー(米国)EMail: alex.zinin@alcatel-lucent.com
Nguyen, et al. Informational [Page 9] RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
Nguyen、他 情報[9ページ]のRFC4811のOSPFのバンドで出ているLSDB Resynchronization行進2007
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Nguyen, et al. Informational [Page 10]
Nguyen、他 情報[10ページ]
一覧
スポンサーリンク