[要約] RFC 3623は、OSPFの優雅な再起動に関する要件と手順を定義しています。その目的は、ネットワークの再起動中にパケットの喪失やルーティングの不安定性を最小限に抑えることです。
Network Working Group J. Moy
Request for Comments: 3623 Sycamore Networks
Category: Standards Track P. Pillay-Esnault
Juniper Networks
A. Lindem
Redback Networks
November 2003
Graceful OSPF Restart
優雅なOSPFの再起動
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "graceful restart" or "non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.
このメモは、OSPFルーティングプロトコルの強化を文書化します。これにより、OSPFソフトウェアが再起動されている場合でも、OSPFルーターは転送パスにとどまることができます。これは、「Graceful Restart」または「ノンストップ転送」と呼ばれます。再起動ルーターは、ネットワークトポロジが変更されたときにタイムリーに転送を調整することができない場合があります。結果として生じる可能性のあるルーティングループを回避するために、このメモの手順は、そのようなトポロジの変更が検出されたとき、または1つまたは複数の再起動ルーターのネイバーがこのメモの強化をサポートしていないときに、通常のOSPF再起動に自動的に戻ります。優雅な再起動中の適切なネットワーク操作は、再起動ルーターの動作環境を仮定します。これらの仮定も文書化されています。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Operation of Restarting Router . . . . . . . . . . . . . . . . 3
2.1. Entering Graceful Restart. . . . . . . . . . . . . . . . 4
2.2. When to Exit Graceful Restart. . . . . . . . . . . . . . 5
2.3. Actions on Exiting Graceful Restart. . . . . . . . . . . 6
3. Operation of Helper Neighbor . . . . . . . . . . . . . . . . . 7
3.1. Entering Helper Mode . . . . . . . . . . . . . . . . . . 7
3.2. Exiting Helper Mode. . . . . . . . . . . . . . . . . . . 8
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9
5. Unplanned Outages. . . . . . . . . . . . . . . . . . . . . . . 10
6. Interaction with Traffic Engineering . . . . . . . . . . . . . 11
7. Possible Future Work . . . . . . . . . . . . . . . . . . . . . 11
8. Intellectual Property Rights Notice. . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
A. Grace-LSA Format . . . . . . . . . . . . . . . . . . . . . . . 13
B. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 15
Security Considerations. . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 18
Today many Internet routers implement a separation of control and forwarding functions. Certain processors are dedicated to control and management tasks such as OSPF routing, while other processors perform the data forwarding tasks. This separation creates the possibility of maintaining a router's data forwarding capability while the router's control software is restarted/reloaded. We call such a possibility "graceful restart" or "non-stop forwarding".
今日、多くのインターネットルーターが制御機能と転送機能の分離を実装しています。特定のプロセッサは、OSPFルーティングなどの制御および管理タスクに専念していますが、他のプロセッサはデータ転送タスクを実行します。この分離は、ルーターの制御ソフトウェアが再起動/リロードされている間に、ルーターのデータ転送機能を維持する可能性を作成します。このような可能性を「優雅な再起動」または「ノンストップ転送」と呼びます。
The OSPF protocol presents a problem to graceful restart whereby, under normal operation, OSPF intentionally routes around a restarting router while it rebuilds its link-state database. OSPF avoids the restarting router to minimize the possibility of routing loops and/or black holes caused by lack of database synchronization. Avoidance is accomplished by having the router's neighbors reissue their LSAs, omitting links to the restarting router.
OSPFプロトコルは、優雅な再起動の問題を提示し、通常の操作の下で、OSPFがリンク状態のデータベースを再構築しながら意図的に再起動するルーターの周りにルーティングします。OSPFは、データベースの同期の欠如によって引き起こされるルーティングループやブラックホールの可能性を最小限に抑えるために、ルーターの再起動を回避します。回避は、ルーターの隣人にLSAを再発行させ、再起動ルーターへのリンクを省略することで達成されます。
However, if (a) the network topology remains stable and (b) the restarting router is able to keep its forwarding table(s) across the restart, it would be safe to keep the restarting router on the forwarding path. This memo documents an enhancement to OSPF that makes such graceful restart possible, and automatically reverts back to a standard OSPF restart for safety when network topology changes are detected.
ただし、（a）ネットワークトポロジが安定したままで、（b）再起動ルーターが再起動全体に転送テーブルを維持できる場合、再起動ルーターを転送パスに維持することは安全です。このメモは、このような優雅な再起動を可能にするOSPFの拡張を文書化し、ネットワークトポロジの変更が検出されたときに安全のために標準のOSPF再起動に自動的に戻ってきます。
In a nutshell, the OSPF enhancements for graceful restart are as follows:
一言で言えば、優雅な再起動のためのOSPFの強化は次のとおりです。
- The router attempting a graceful restart originates link-local Opaque-LSAs, herein called Grace-LSAs, announcing its intention to perform a graceful restart within a specified amount of time or "grace period".
- 優雅な再起動を試みるルーターは、ここではGrace-LSAと呼ばれるLink-Local Opaque-LSAを発信し、指定された時間または「Grace期間」内で優雅な再起動を実行する意図を発表します。
- During the grace period, its neighbors continue to announce the restarting router in their LSAs as if it were fully adjacent (i.e., OSPF neighbor state Full), but only if the network topology remains static (i.e., the contents of the LSAs in the link-state database having LS types 1-5,7 remain unchanged and periodic refreshes are allowed).
- 恵み期間中、その隣人は、LSAのルーターの再起動を完全に隣接しているかのように発表し続けます（つまり、OSPF隣人状態が完全）。-LSタイプ1-5,7を持つステートデータベースは変更されておらず、定期的なリフレッシュが許可されています）。
There are two roles being played by OSPF routers during graceful restart. First there is the router that is being restarted. The operation of this router during graceful restart, including how the router enters and exits graceful restart, is the subject of Section 2. Then there are the router's neighbors, which must cooperate in order for the restart to be graceful. During graceful restart, we say that the neighbors are running in "helper mode". Section 3 covers the responsibilities of a router running in helper mode, including entering and exiting helper mode.
優雅な再起動中にOSPFルーターが演奏する2つのロールがあります。最初に再起動しているルーターがあります。ルーターが優雅な再起動に入って出る方法など、優雅な再起動中のこのルーターの操作はセクション2の主題です。次に、ルーターの隣人があります。これは、再起動が優雅になるためには協力しなければなりません。優雅な再起動中、隣人は「ヘルパーモード」で走っていると言います。セクション3では、ヘルパーモードの入りおよび終了など、ヘルパーモードで実行されるルーターの責任について説明します。
After the router restarts/reloads, it must change its OSPF processing somewhat until it re-establishes full adjacencies with all its former fully-adjacent neighbors. This time period, between the restart/reload and the reestablishment of adjacencies, is called "graceful restart". During graceful restart:
ルーターが再起動/リロードされた後、以前のすべての完全に隣接する隣人との完全な隣接を再確立するまで、OSPF処理を多少変更する必要があります。この期間は、再起動/リロードと隣接の再確立の間で、「Graceful Restart」と呼ばれます。優雅な再起動中：
1) The restarting router does not originate LSAs with LS types 1- 5,7. Instead, the restarting router wants the other routers in the OSPF domain to calculate routes using the LSAs that it originated prior to its restart. During this time, the restarting router does not modify or flush received self-originated LSAs, (see Section 13.4 of [1]). Instead they are accepted as valid. In particular, the grace-LSAs that the restarting router originated before the restart are left in place. Received self-originated LSAs will be dealt with when the router exits graceful restart (see Section 2.3).
1) 再起動ルーターは、LSタイプ1〜5,7のLSAを発生しません。代わりに、再起動ルーターは、OSPFドメイン内の他のルーターが、再起動前に発生したLSAを使用してルートを計算することを望んでいます。この期間中、再起動ルーターは、受信された自己序ッドLSAを変更またはフラッシュしません（[1]のセクション13.4を参照）。代わりに、それらは有効であると受け入れられます。特に、再起動するルーターが再起動する前に起源があるGrace-LSAは、所定の位置に残されています。受信した自己由来のLSAは、ルーターが優雅な再起動を終了すると対処されます（セクション2.3を参照）。
2) The restarting router runs its OSPF routing calculations, as specified in Section 16 of [1]. This is necessary to return any OSPF virtual links to operation. However, the restarting router does *not* install OSPF routes into the system's forwarding table(s) and relies on the forwarding entries that it installed prior to the restart.
2) [1]のセクション16で指定されているように、再起動ルーターはOSPFルーティング計算を実行します。これは、OSPF仮想リンクを操作に返すために必要です。ただし、再起動するルーターは、OSPFルートをシステムの転送テーブルにインストールし、再起動前にインストールした転送エントリに依存しています。
3) If the restarting router determines that it was the Designated Router on a given segment prior to the restart, it elects itself as the Designated Router again. The restarting router knows that it was the Designated Router if, while the associated interface is in Waiting state, a Hello packet is received from a neighbor listing the router as the Designated Router.
3) 再起動ルーターが、再起動前に特定のセグメントの指定されたルーターであると判断した場合、指定されたルーターとして再び選択します。再起動ルーターは、関連するインターフェイスが待機状態にある場合、指定されたルーターであることを知っています。
Otherwise, the restarting router operates the same as any other OSPF router. It discovers neighbors using OSPF's Hello protocol, elects Designated and Backup Designated Routers, performs the Database Exchange procedure to initially synchronize link-state databases with its neighbors, and maintains this synchronization through flooding.
それ以外の場合、再起動ルーターは他のOSPFルーターと同じように動作します。OSPFのHelloプロトコルを使用して近隣を発見し、指定されたバックアップ指定ルーターを選択し、データベース交換手順を実行して、最初にリンク状態データベースをNeighborsと同期し、洪水を通じてこの同期を維持します。
The processes of entering graceful restart, and of exiting graceful restart (either successfully or not) are covered in the following sections.
優雅な再起動を入力し、優雅な再起動を終了するプロセス（正常かどうか）を次のセクションで説明します。
The router (call it Router X) is informed of the desire for its graceful restart when an appropriate command is issued by the network operator. The network operator may also specify the length of the grace period, or the necessary grace period may be calculated by the router's OSPF software. In order to avoid the restarting router's LSAs from aging out, the grace period should not exceed LSRefreshTime (1800 second) [1].
Router（Router Xと呼ばれる）は、ネットワークオペレーターによって適切なコマンドが発行されたときに、その優雅な再起動の欲求を知らされます。ネットワークオペレーターは、グレース期間の長さを指定するか、必要な猶予期間をルーターのOSPFソフトウェアによって計算することもできます。ルーターのLSAの再起動が老化しないように回避するために、猶予期間はLSREFRESHTIME（1800秒）を超えてはなりません[1]。
In preparation for the graceful restart, Router X must perform the following actions before its software is restarted/reloaded:
優雅な再起動に備えて、ルーターXは、ソフトウェアが再起動/リロードされる前に、次のアクションを実行する必要があります。
(Note that common OSPF shutdown procedures are *not* performed, since we want the other OSPF routers to act as if Router X remains in continuous service. For example, Router X does not flush its locally originated LSAs, since we want them to remain in other routers' link-state databases throughout the restart period.)
（他のOSPFルーターにルーターXが継続的なサービスを維持しているかのように動作するように動作するため、一般的なOSPFシャットダウン手順は実行されないことに注意してください。たとえば、ルーターXは、そのままにしたいので、ローカルに由来するLSAをフラッシュしません。再起動期間中、他のルーターのリンク状態データベースで。）
1) Router X must ensure that its forwarding table(s) is/are up-to-date and will remain in place across the restart.
1) ルーターXは、転送テーブルが最新であることを確認する必要があります。
2) The router may need to preserve the cryptographic sequence numbers being used on each interface in non-volatile storage. An alternative is to use the router's clock for cryptographic sequence number generation and ensure that the clock is preserved across restarts (either on the same or redundant route processors). If neither of these can be guaranteed, it can take up to RouterDeadInterval seconds after the restart before adjacencies can be reestablished and this would force the grace period to be lengthened greatly.
2) ルーターは、不揮発性ストレージの各インターフェイスで使用されている暗号化シーケンス番号を保存する必要がある場合があります。別の方法は、暗号化シーケンス番号の生成にルーターのクロックを使用し、再起動全体（同じまたは冗長ルートプロセッサ）全体にクロックが保存されていることを確認することです。これらのいずれも保証できない場合、隣接する前に再起動後にルーターディーデッドインターバルまでかかることがあり、これにより恵み期間が大幅に延長されるようになります。
Router X then originates the grace-LSAs. These are link-local Opaque-LSAs (see Appendix A). Their LS Age field is set to 0, and the requested grace period (in seconds) is inserted into the body of the grace-LSA. The precise contents of the grace-LSA are described in Appendix A.
次に、ルーターXがGrace-LSAを発信します。これらはリンクローカルの不透明LSAです（付録Aを参照）。それらのLS Ageフィールドは0に設定されており、要求された恵み期間（秒単位）がGrace-LSAの本体に挿入されます。Grace-LSAの正確な内容は、付録Aで説明されています。
A grace-LSA is originated for each of the router's OSPF interfaces. If Router X wants to ensure that its neighbors receive the grace-LSAs, it should retransmit the grace-LSAs until they are acknowledged (i.e., perform standard OSPF reliable flooding of the grace-LSAs). If one or more fully adjacent neighbors do not receive grace-LSAs, they will more than likely cause premature termination of the graceful restart procedure (see Section 4).
RouterのOSPFインターフェイスごとにGrace-LSAが発信されます。Router Xが隣人がGrace-LSAを受け取るようにしたい場合、Grace-LSAが認められるまでGrace-LSAを再送信する必要があります（つまり、Grace-LSAの標準的なOSPF信頼できる洪水を実行します）。1つまたは複数の完全に隣接する隣人がGrace-LSAを受け取らない場合、優雅な再起動手順の早期終了を引き起こす可能性が高くなります（セクション4を参照）。
After the grace-LSAs have been sent, the router should store the fact that it is performing graceful restart along with the length of the requested grace period in non-volatile storage. (Note to implementors: It may be easiest to simply store the absolute time of the end of the grace period). The OSPF software should then be restarted/reloaded. When the reloaded software starts executing the graceful restart, the protocol modifications in Section 2 are followed. (Note that prior to the restart, the router does not know whether its neighbors are going to cooperate as "helpers"; the mere reception of grace-LSAs does not imply acceptance of helper responsibilities. This memo assumes that the router would want to restart anyway, even if the restart is not going to be graceful).
Grace-LSAが送信された後、ルーターは、不揮発性ストレージで要求されたGrace期間の長さとともに優雅な再起動を実行しているという事実を保存する必要があります。（実装者への注意：猶予期間の終わりの絶対時間を単純に保存するのが最も簡単かもしれません）。その後、OSPFソフトウェアを再起動/リロードする必要があります。リロードされたソフトウェアが優雅な再起動の実行を開始すると、セクション2のプロトコルの変更が続きます。（再起動の前に、ルーターはその隣人が「ヘルパー」として協力するかどうかを知らないことに注意してください。グレースLSAの単なる受信はヘルパーの責任の受け入れを意味しません。このメモは、ルーターが再起動したいと思っていることを想定していますとにかく、たとえ再起動が優雅にならないとしても）。
A Router X exits graceful restart when any of the following occurs:
ルーターXは、次のいずれかが発生したときに優雅な再起動を終了します。
1) Router X has reestablished all its adjacencies. Router X can determine this by examining the router-LSAs that it last originated before the restart (called the "pre-restart router-LSA"), and, on those segments where the router is the Designated Router, the pre-restart network-LSAs. These LSAs will have been received from the helping neighbors, and need not have been stored in non-volatile storage across the restart. All previous adjacencies will be listed as type-1 and type-2 links in the router-LSA, and as neighbors in the body of the network-LSA.
1) ルーターXは、そのすべての隣接を再確立しました。ルーターXは、再起動前に最後に発生したルーター-LSA（「プレレスターター-LSA」と呼ばれる）、およびルーターが指定されたルーターであるセグメントであるそれらのセグメントであるリスートネットワークであるセグメントを調べることで、これを決定できます。LSAS。これらのLSAは、支援隣人から受け取られており、再起動全体で不揮発性ストレージに保存される必要はありません。以前のすべての隣接は、ルーターLSAのタイプ1およびタイプ2リンクとして、およびネットワークLSAの本体の近隣としてリストされます。
2) Router X receives an LSA that is inconsistent with its pre-restart router-LSA. For example, X receives a router-LSA originated by router Y that does not contain a link to X, even though X's pre-start router-LSA did contain a link to Y. This indicates that either a) Y does not support graceful restart, b) Y never received the grace-LSA or c) Y has terminated its helper mode for some reason (Section 3.2). A special case of LSA inconsistency is when Router X establishes an adjacency with router Y and doesn't receive an instance of its own pre-restart router LSA.
2) Router Xは、再復活前のルーターLSAと矛盾するLSAを受け取ります。たとえば、Xは、Xの事前開始ルーターLSAがYへのリンクを含んでいたにもかかわらず、Xへのリンクを含まないルーターYから発信されたルーター-LSAを受信します。これは、a）yが優雅な再起動をサポートしていないことを示します、b）yはGrace-LSAを受け取ったことがないか、C）yは何らかの理由でヘルパーモードを終了しました（セクション3.2）。LSAの矛盾の特別なケースは、ルーターXがルーターYの隣接性を確立し、独自のリスターツ前LSAのインスタンスを受け取らない場合です。
3) The grace period expires.
3) 猶予期間は期限切れになります。
Upon exiting "graceful restart", the restarting router reverts back to completely normal OSPF operation, reoriginating LSAs based on the router's current state and updating its forwarding table(s) based on the current contents of the link-state database. In particular, the following actions should be performed when exiting, either successfully or unsuccessfully, graceful restart:
「優雅な再起動」を終了すると、ルーターの再起動は完全に正常なOSPF操作に戻り、ルーターの現在の状態に基づいてLSAを再び再調整し、リンク状態データベースの現在の内容に基づいて転送テーブルを更新します。特に、次のアクションは、成功した、または失敗して、優雅な再起動のいずれかを終了するときに実行する必要があります。
1) The router should reoriginate its router-LSAs for all attached areas in order to make sure they have the correct contents.
1) ルーターは、正しい内容があることを確認するために、すべての接続された領域のルーターLSAを再び再調整する必要があります。
2) The router should reoriginate network-LSAs on all segments where it is the Designated Router.
2) ルーターは、指定されたルーターであるすべてのセグメントのネットワークLSAを再び再調整する必要があります。
3) The router reruns its OSPF routing calculations (Section 16 of [1]), this time installing the results into the system forwarding table, and originating summary-LSAs, Type-7 LSAs and AS-external-LSAs as necessary.
3) ルーターは、OSPFルーティング計算（[1]のセクション16）を再実行し、今回は結果をシステム転送テーブルにインストールし、必要に応じてサマリLSA、タイプ7 LSA、およびASExternal-LSAを発信します。
4) Any remnant entries in the system forwarding table that were installed before the restart, but that are no longer valid, should be removed.
4) 再起動前にインストールされていたが無効になっていないシステム転送テーブルの残りのエントリは削除する必要があります。
5) Any received self-originated LSAs that are no longer valid should be flushed.
5) もはや有効でない自己陽子LSAを受け取ったものは、フラッシュする必要があります。
6) Any grace-LSAs that the router originated should be flushed.
6) ルーターが発生したグレースLSAは、フラッシュする必要があります。
The helper relationship is per network segment. As a "helper neighbor" on a segment S for a restarting router X, router Y has several duties. It monitors the network for topology changes, and as long as there are none, continues to advertise its LSAs as if X had remained in continuous OSPF operation. This means that Y's LSAs continue to list an adjacency to X over network segment S, regardless of the adjacency's current synchronization state. This logic affects the contents of both router-LSAs and network-LSAs, and also depends on the type of network segment S (see Sections 12.4.1.1 through 12.4.1.5 and Section 12.4.2 of [1]). When helping over a virtual link, the helper must also continue to set bit V in its router-LSA for the virtual link's transit area (Section 12.4.1 of [1]).
ヘルパー関係はネットワークセグメントごとです。ルーターXの再起動のセグメントSの「ヘルパー隣人」として、ルーターYにはいくつかの義務があります。トポロジの変更のためのネットワークを監視し、Xが継続的なOSPF操作のままであるかのようにLSAを宣伝し続けています。つまり、YのLSAは、隣接の現在の同期状態に関係なく、ネットワークセグメントを介してXへの隣接をリストし続けています。このロジックは、ルーターLSAとネットワークLSAの両方の内容に影響し、ネットワークセグメントsのタイプにも依存します（[1]のセクション12.4.1.1から12.4.1.5およびセクション12.4.2を参照）。仮想リンクを支援する場合、ヘルパーは、仮想リンクのトランジットエリア（[1]のセクション12.4.1）のルーターLSAにビットVを設定し続ける必要があります。
Also, if X was the Designated Router on network segment S when the helping relationship began, Y maintains X as the Designated Router until the helping relationship is terminated.
また、Xが支援関係が始まったときにネットワークセグメントの指定されたルーターである場合、YはXを支援関係が終了するまで指定されたルーターとして維持します。
When a router Y receives a grace-LSA from router X, it enters helper mode for X on the associated network segment, as long as all the following checks pass:
ルーターYがルーターXからGRACE-LSAを受信すると、次のすべてのチェックが通過する限り、関連するネットワークセグメントでXのヘルパーモードに入ります。
1) Y currently has a full adjacency with X (neighbor state Full) over the associated network segment. On broadcast, NBMA and Point-to-MultiPoint segments, the neighbor relationship with X is identified by the IP interface address in the body of the grace-LSA (see Appendix A). On all other segment types, X is identified by the grace-LSA's Advertising Router field.
1) yは現在、関連するネットワークセグメントにx（近隣状態フル）を備えた完全な隣接を持っています。ブロードキャスト、NBMA、およびポイントツーマルチポイントセグメントでは、Xとの隣接関係は、Grace-LSAの本文のIPインターフェイスアドレスによって識別されます（付録Aを参照）。他のすべてのセグメントタイプで、XはGrace-LSAの広告ルーターフィールドによって識別されます。
2) There have been no changes in content to the link-state database (LS types 1-5,7) since router X restarted. This is determined as follows:
2) ルーターXが再起動して以来、リンク状態データベース（LSタイプ1-5,7）のコンテンツに変更はありませんでした。これは次のように決定されます。
- Router Y examines the link-state retransmission list for X over the associated network segment.
- Router Yは、関連するネットワークセグメントでXのリンク状態の再送信リストを調べます。
- If there are any LSAs with LS types 1-5,7 on the list, then they all must be periodic refreshes.
- リストにLSタイプ1-5,7を持つLSAがある場合、それらはすべて定期的な更新でなければなりません。
- If there are instead LSAs on the list whose contents have changed (see Section 3.3 of [7]), Y must refuse to enter helper mode.
- リストに内容が変更されたLSAがある場合（[7]のセクション3.3を参照）、Yはヘルパーモードに入ることを拒否する必要があります。
Router Y may optionally disallow graceful restart with Router X on other network segments. Determining whether changed LSAs have been successfully flooded to router Y on other network segments is feasible but beyond the scope of this document.
ルーターYは、オプションで、他のネットワークセグメントでルーターXを使用して優雅な再起動を許可する場合があります。変更されたLSAが他のネットワークセグメントでルーターYに正常に浸水したかどうかを判断することは実現可能ですが、このドキュメントの範囲を超えています。
3) The grace period has not yet expired. This means that the LS age of the grace-LSA is less than the grace period specified in the body of the grace-LSA (Appendix A).
3) 恵み期間はまだ期限切れではありません。これは、GRACE-LSAのLS年齢がGrace-LSAの本体で指定された恵み期間よりも小さいことを意味します（付録A）。
4) Local policy allows Y to act as the helper for X. Examples of configured policies might be a) never act as helper, b) never allow the grace period to exceed a Time T, c) only help on software reloads/upgrades, or d) never act as a helper for specific routers (specified by OSPF Router ID).
4) ローカルポリシーにより、YはXのヘルパーとして機能することができます。設定されたポリシーの例は、a）ヘルパーとして機能することはない場合があります。b）猶予期間が時間を超えないようにしないでください。）特定のルーターのヘルパーとして機能しないでください（OSPFルーターIDで指定）。
5) Router Y is not in the process of graceful restart.
5) ルーターYは、優雅な再起動の過程にありません。
There is one exception to the above requirements. If Y was already helping X on the associated network segment, the new grace-LSA should be accepted and the grace period should be updated accordingly.
上記の要件には1つの例外があります。Yがすでに関連するネットワークセグメントでXを支援していた場合、新しいGrace-LSAを受け入れ、それに応じてGRACE期間を更新する必要があります。
Note that Router Y may be helping X on some network segments, and not on others. However, that circumstance will probably lead to the premature termination of X's graceful restart, as Y will not continue to advertise adjacencies on the segments where it is not helping (see Section 2.2).
ルーターYは、他のネットワークセグメントではなく、一部のネットワークセグメントでXを支援している可能性があることに注意してください。ただし、その状況はおそらく、Yが役に立たないセグメントの隣接を宣伝し続けないため、Xの優雅な再開の早期終了につながるでしょう（セクション2.2を参照）。
Alternately, Router Y may choose to enter helper mode when a grace-LSA is received and the above checks pass for all adjacencies with Router X. This implementation alternative of aggregating the adjacencies with respect to helper mode is compatible with implementations considering each adjacency independently.
あるいは、ルーターYは、GRACE-LSAを受信し、上記のチェックがルーターXを使用してすべての隣接を通過するときにヘルパーモードに入ることを選択できます。ヘルパーモードに関する隣接を集約するこの実装の代替手段は、各隣接性を独立して実装と互換性があります。
A single router is allowed to simultaneously serve as a helper for multiple restarting neighbors.
単一のルーターは、複数の再起動隣人のヘルパーとして同時に機能することができます。
Router Y ceases to perform the helper function for its neighbor Router X on a given segment when one of the following events occurs:
ルーターYは、次のイベントのいずれかが発生した場合、特定のセグメントで隣接ルーターXのヘルパー関数を実行しなくなります。
1) The grace-LSA originated by X on the segment is flushed. This indicates the successful termination of graceful restart.
1) セグメント上のXから生まれたGrace-LSAはフラッシュされます。これは、優雅な再起動の終了が成功したことを示しています。
2) The grace-LSA's grace period expires.
2) Grace-LSAの恵み期間は期限切れになります。
3) A change in link-state database contents indicates a network topology change, which forces termination of a graceful restart. Specifically, if router Y installs a new LSA in its database with LS types 1-5,7 and having the following two properties, it should cease helping X. The two properties of the LSA are:
3) リンク状態のデータベースコンテンツの変更は、ネットワークトポロジの変更を示しており、優雅な再起動の終了を強制します。具体的には、Router YがLSタイプ1-5,7のデータベースに新しいLSAをインストールし、次の2つのプロパティを持つ場合、Xを支援する必要があります。LSAの2つのプロパティは次のとおりです。
a) the contents of the LSA have changed; this includes LSAs with no previous link-state database instance and the flushing of LSAs from the database, but excludes periodic LSA refreshes (see Section 3.3 of [7]), and
a) LSAの内容が変更されました。これには、以前のリンク状態データベースインスタンスのないLSAとデータベースからのLSAのフラッシュが含まれますが、定期的なLSAリフレッシュ（[7]のセクション3.3を参照）を除外します。
b) the LSA would have been flooded to X, had Y and X been fully adjacent. As an example of the second property, if Y installs a changed AS-external-LSA, it should not terminate a helping relationship with a neighbor belonging to a stub area, as that neighbor would not see the AS-external-LSA in any case. An implementation MAY provide a configuration option to disable link-state database options from terminating graceful restart. Such an option will, however, increase the risk of transient routing loops and black holes.
b) yとxが完全に隣接していれば、LSAはxに浸水していたでしょう。2番目のプロパティの例として、yが変更されたas-fernal-LSAをインストールする場合、隣人がいずれにせよ、as-erternal-LSAを見ないため、隣の隣人との援助関係を終了するべきではありません。。実装は、リンク状態のデータベースオプションを優雅な再起動の終了から無効にする構成オプションを提供する場合があります。ただし、このようなオプションは、一時的なルーティングループとブラックホールのリスクを高めます。
When Router Y exits helper mode for X on a given network segment, it reoriginates its LSAs based on the current state of its adjacency to Router X over the segment. In detail, Y takes the following actions:
ルーターYが特定のネットワークセグメントでXのヘルパーモードを終了すると、セグメント上のルーターXへの隣接の現在の状態に基づいてLSAを再拡張します。詳細には、yは次のアクションを実行します。
a) Y recalculates the Designated Router for the segment,
a) yセグメントの指定されたルーターを再計算します。
b) Y reoriginates its router-LSA for the segment's OSPF area,
b) yセグメントのOSPF領域のルーター-LSAを再確認します。
c) if Y is Designated Router for the segment, it reoriginates the network-LSA for the segment and
c) yがセグメントのルーターに指定されている場合、セグメントのネットワークLSAを再環境に導き、
d) if the segment was a virtual link, Y reoriginates its router-LSA for the virtual link's transit area.
d) セグメントが仮想リンクである場合、Yは仮想リンクのトランジットエリアのルーターLSAを再び再構成します。
If Router Y aggregated adjacencies with Router X when entering helper mode (as described in section 3.1), it must also exit helper mode for all adjacencies with Router X when any one of the exit events occurs for an adjacency with Router X.
ルーターYがヘルパーモードに入るときにルーターXと隣接して集計された場合（セクション3.1で説明されているように）、ルーターXの隣接する場合に出口イベントのいずれかが発生した場合、ルーターXのすべての隣接するヘルパーモードも終了する必要があります。
Backward-compatibility with unmodified OSPF routers is an automatic consequence of the functionality documented above. If one or more neighbors of a router requesting graceful restart are unmodified, or if they do not receive the grace-LSA, the graceful restart reverts to a normal OSPF restart.
変更されていないOSPFルーターを使用した後方互換性は、上記の機能の自動的な結果です。優雅な再起動を要求するルーターの1つ以上の隣人が修正されていない場合、またはGrace-LSAを受け取っていない場合、優雅な再起動は通常のOSPF再起動に戻ります。
The unmodified routers will start routing around the restarted router X as it performs initial database synchronization by reissuing their LSAs with links to X omitted. These LSAs will be interpreted by helper neighbors as a topology change, and by X as an LSA inconsistency, in either case, reverting to normal OSPF operation.
変更されていないルーターは、Xへのリンクを使用してLSAを再発行することにより、初期データベース同期を実行するため、再起動したルーターXの周りにルーティングを開始します。これらのLSAは、ヘルパーネイバーズによってトポロジーの変化として解釈され、XによってLSAの矛盾として解釈されます。どちらの場合も、通常のOSPF操作に戻ります。
The graceful restart mechanisms in this memo can be used for unplanned outages. (Examples of unplanned outages include the crash of a router's control software, an unexpected switchover to a redundant control processor, etc). However, implementors and network operators should note that attempting graceful restart from an unplanned outage may not be a good idea, owing to the router's inability to properly prepare for the restart (see Section 2.1). In particular, it seems unlikely that a router could guarantee the sanity of its forwarding table(s) across an unplanned restart. In any event, implementors providing the option to recover gracefully from unplanned outages must allow a network operator to turn the option off.
このメモの優雅な再起動メカニズムは、計画外の停止に使用できます。（予定外の停止の例には、ルーターの制御ソフトウェアのクラッシュ、冗長性制御プロセッサへの予期しない切り替えなど）が含まれます。ただし、実装者とネットワークオペレーターは、ルーターが再起動に適切に準備できないため、計画外の停止から優雅な再起動を試みることは良い考えではないかもしれないことに注意する必要があります（セクション2.1を参照）。特に、ルーターが計画外の再開全体で転送テーブルの正気を保証できる可能性は低いようです。いずれにせよ、計画外の停止から優雅に回復するオプションを提供する実装者は、ネットワークオペレーターがオプションをオフにすることを許可する必要があります。
In contrast to the procedure for planned restart/reloads that was described in Section 2.1, a router attempting graceful restart after an unplanned outage must originate grace-LSAs *after* its control software resumes operation. The following points must be observed during this grace-LSA origination.
セクション2.1で説明されている計画された再起動/リロードの手順とは対照的に、計画外の停止後に優雅な再起動を試みるルーターは、その制御ソフトウェアが操作を再開した後、Grace-LSAS *を発信する必要があります。このグレースLSAの起源の間、次の点を観察する必要があります。
o The grace-LSAs must be originated and be sent *before* the restarted router sends any OSPF Hello Packets. On broadcast networks, this LSA must be flooded to the AllSPFRouters multicast address (224.0.0.5) since the restarting router is not aware of its previous DR state.
o Grace-LSAは、再起動したルーターがOSPFのハローパケットを送信する前に、発信して送信する必要があります *。ブロードキャストネットワークでは、再起動ルーターが以前のDR州を認識していないため、このLSAはAllSPFRoutertersマルチキャストアドレス（224.0.0.5）に浸水する必要があります。
o The grace-LSAs are encapsulated in Link State Update Packets and sent out to all interfaces, even though the restarted router has no adjacencies and no knowledge of previous adjacencies.
o 再起動したルーターには隣接や以前の隣接に関する知識がない場合でも、Grace-LSAはリンク状態更新パケットにカプセル化され、すべてのインターフェイスに送信されます。
o To improve the probability that grace-LSAs will be delivered, an implementation may send them multiple times (see for example the Robustness Variable in [8]).
o Grace-LSAが配信される確率を改善するために、実装はそれらを複数回送信する場合があります（たとえば、[8]の堅牢性変数を参照）。
o The restart reason in the grace-LSAs must be set to 0 (unknown) or 3 (switch to redundant control processor). This enables the neighbors to decide whether they want to help the router through an unplanned restart.
o GRACE-LSAの再起動理由は、0（不明）または3（冗長制御プロセッサに切り替える）に設定する必要があります。これにより、隣人は、計画外の再起動を通じてルーターを支援したいかどうかを決定できます。
The operation of the Traffic Engineering Extensions to OSPF [4] during OSPF Graceful Restart is specified in [6].
OSPFの優雅な再起動中のOSPF [4]へのトラフィックエンジニアリング拡張の動作は、[6]で指定されています。
Devise a less conservative algorithm for graceful restart helper termination that provides a comparable level of black hole and routing loop avoidance.
同等のレベルのブラックホールとルーティングループ回避を提供する優雅な再起動ヘルパー終了のために、保守的でないアルゴリズムを考案します。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[1] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[2] Coltun、R。、「OSPF Opaque LSAオプション」、RFC 2370、1998年7月。
[3] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[3] Murphy、S.、Badger、M. and B. Wellington、「Digital Signatures with Digital Signatures」、RFC 2154、1997年6月。
[4] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[4] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）拡張機能への拡張」、RFC 3630、2003年9月。
[5] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[5] Murphy、P。、「OSPF Not-Stubby Area（NSSA）オプション」、RFC 3101、2003年1月。
[6] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[6] Kompella、K.、et al。、「一般化されたMPLSをサポートするルーティング拡張機能」、進行中の作業。
[7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[7] Moy、J。、「需要回路をサポートするためにOSPFを拡張」、RFC 1793、1995年4月。
[8] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[8] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。and A. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
A. Grace-LSA Format
A. Grace-LSA形式
The grace-LSA is a link-local scoped Opaque-LSA [2], having an Opaque Type of 3 and an Opaque ID equal to 0. Grace-LSAs are originated by a router that wishes to execute a graceful restart of its OSPF software. A grace-LSA requests that the router's neighbors aid in its graceful restart by continuing to advertise the router as fully adjacent during a specified grace period.
Grace-LSAは、リンクローカルスコープされた不透明LSA [2]であり、3の不透明なタイプ3と0に等しい不透明なIDを有します。Grace-LSAは、OSPFソフトウェアの優雅な再起動を実行したいルーターによって発信されます。。Grace-LSAは、ルーターの隣人が、指定されたグレース期間中に完全に隣接するルーターを宣伝し続けることにより、その優雅な再起動を支援することを要求します。
Each grace-LSA has an LS age field set to 0 when the LSA is first originated; the current value of the LS age then indicates how long ago the restarting router made its request. The body of the LSA is TLV-encoded. The TLV-encoded information includes the length of the grace period, the reason for the graceful restart and, when the grace-LSA is associated with a broadcast, NBMA or Point-to-MultiPoint network segment, the IP interface address of the restarting router.
各Grace-LSAには、LSAが最初に発生すると、LS Ageフィールドが0に設定されています。LS年齢の現在の値は、再起動ルーターがどのくらい前にその要求を行ったかを示します。LSAの本体はTLVエンコードされています。TLVエンコードされた情報には、グレース期間の長さ、優雅な再起動の理由、およびGrace-LSAが放送、NBMA、またはポイントツーマルチポイントネットワークセグメントに関連付けられている場合、再起動ルーターのIPインターフェイスアドレスが含まれます。。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
The format of the TLVs within the body of a grace-LSA is the same as the format used by the Traffic Engineering Extensions to OSPF [4]. The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of each TLV is:
Grace-LSAの本体内のTLVの形式は、トラフィックエンジニアリング拡張がOSPF [4]で使用される形式と同じです。LSAペイロードは、1つ以上のネストされたタイプ/長さ/値（TLV）トリプレットで構成されています。各TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. For example, a one byte value would have the length field set to 1, and three bytes of padding would be added to the end of the value portion of the TLV. Unrecognized types are ignored.
長さフィールドは、オクテットの値部分の長さを定義します（したがって、値部分のないTLVはゼロの長さになります）。TLVは、4オクテットのアライメントにパッドで埋められています。パディングは長さフィールドには含まれていません（したがって、3オクテットの値は3つの長さですが、TLVの合計サイズは8オクテットになります）。ネストされたTLVも32ビットアライメントされています。たとえば、1バイト値の長さフィールドは1に設定され、TLVの値部分の最後に3バイトのパディングが追加されます。認識されていないタイプは無視されます。
The following is the list of TLVs that can appear in the body of a grace-LSA:
以下は、Grace-LSAの本体に表示されるTLVのリストです。
o Grace Period (Type=1, length=4). The number of seconds that the router's neighbors should continue to advertise the router as fully adjacent, regardless of the state of database synchronization between the router and its neighbors. Since this time period began when grace-LSA's LS age was equal to 0, the grace period terminates when either:
o 恵み期間（タイプ= 1、長さ= 4）。ルーターの隣人がルーターとその近隣の間のデータベース同期の状態に関係なく、ルーターを完全に隣接するものとして宣伝し続けるべき秒数。Grace-LSAのLS年齢が0に等しいこの期間が始まったので、猶予期間は次の場合に終了します。
a) the LS age of the grace-LSA exceeds the value of a Grace Period or
a) Grace-LSAのLS年齢は、恵み期間の価値を超えています。
b) the grace-LSA is flushed. See Section 3.2 for other conditions that terminate graceful restart.
b) Grace-LSAはフラッシュされます。優雅な再起動を終了する他の条件については、セクション3.2を参照してください。
This TLV must always appear in a grace-LSA.
このTLVは常にGrace-LSAに表示されなければなりません。
o Graceful restart reason (Type=2, length=1). Encodes the reason for the router restart as one of the following: 0 (unknown), 1 (software restart), 2 (software reload/upgrade) or 3 (switch to redundant control processor). This TLV must always appear in a grace-LSA.
o 優雅な再起動理由（タイプ= 2、長さ= 1）。ルーターの再起動の理由を次のいずれかのいずれかとしてエンコードします：0（不明）、1（ソフトウェア再起動）、2（ソフトウェアリロード/アップグレード）、または3（冗長制御プロセッサへの切り替え）。このTLVは常にGrace-LSAに表示されなければなりません。
o IP interface address (Type=3, length=4). The router's IP interface address on the subnet associated with the grace-LSA. Required on broadcast, NBMA and Point-to-MultiPoint segments, where the helper uses the IP interface address to identify the restarting router (see Section 3.1).
o IPインターフェイスアドレス（type = 3、length = 4）。GRACE-LSAに関連付けられたサブネット上のルーターのIPインターフェイスアドレス。ブロードキャスト、NBMA、およびポイントツーマルチポイントセグメントで必要です。ヘルパーはIPインターフェイスアドレスを使用して再起動ルーターを識別します（セクション3.1を参照）。
DoNotAge is never set in a grace-LSA, even if the grace-LSA is flooded over a demand circuit [7]. This is because the grace-LSA's LS age field is used to calculate the duration of the grace period.
Grace-LSAが需要回路に浸水していても、装飾は恵みLSAに設定されることはありません[7]。これは、Grace-LSAのLS年齢分野が恵み期間の期間を計算するために使用されるためです。
Grace-LSAs have link-local scope because they only need to be seen by the router's direct neighbors.
Grace-LSAには、ルーターの直接の隣人が見る必要があるため、Link-Local Scopeがあります。
Additional Grace-LSA TLVs must be described in an Internet Draft and will be subject to the expert review of the OSPF Working Group.
追加のGRACE-LSA TLVは、インターネットドラフトで説明する必要があり、OSPFワーキンググループの専門家レビューの対象となります。
B. Configurable Parameters
B.構成可能なパラメーター
OSPF graceful restart parameters are suggested below. Section B.1 contains a minimum subset of parameters that should be supported. B.2 includes some additional configuration parameters that an implementation may choose to support.
OSPF優雅な再起動パラメーターを以下に提案します。セクションB.1には、サポートすべきパラメーターの最小サブセットが含まれています。B.2には、実装がサポートすることを選択できる追加の構成パラメーターが含まれています。
RestartSupport
RestArtSupport
The router's level of support for OSPF graceful restart. Allowable values are none, planned restart only, and planned/unplanned.
OSPFの優雅な再起動に対するルーターのサポートレベル。許容値はなし、計画された再起動のみ、計画/計画外です。
RestartInterval
rettartinterval
The graceful restart interval in seconds. The range is from 1 to 1800 seconds, with a suggested default of 120 seconds.
秒単位の優雅な再起動間隔。範囲は1〜1800秒で、推奨されるデフォルトは120秒です。
RestartHelperSupport
Restarthelpersupport
The router's support for acting as an OSPF restart helper. Allowable values are none, planned restart only, and planned/unplanned.
OSPFの再起動ヘルパーとして行動するためのルーターのサポート。許容値はなし、計画された再起動のみ、計画/計画外です。
RestartHelperStrictLSAChecking
restarthelperstrictlsachecking
Indicates whether or not an OSPF restart helper should terminate graceful restart when there is a change to an LSA that would be flooded to the restarting router or when there is a changed LSA on the restarting router's retransmission list when graceful restart is initiated. The suggested default is enabled.
OSPFの再起動ヘルパーが、再起動ルーターに浸水するLSAに変更がある場合、または優雅な再起動が開始されたときに再起動ルーターの再送信リストにLSAが変更された場合に優雅な再起動を終了するかどうかを示します。推奨されるデフォルトは有効です。
Security Considerations
セキュリティに関する考慮事項
One of the ways to attack a link-state protocol such as OSPF is to inject false LSAs into, or corrupt existing LSAs in, the link-state database. Injecting a false grace-LSA would allow an attacker to spoof a router that, in reality, has been withdrawn from service. The standard way to prevent such corruption of the link-state database is to secure OSPF protocol exchanges using the cryptographic authentication specified in [1]. An even stronger way of securing link-state database contents has been proposed in [3].
OSPFなどのリンク状態プロトコルを攻撃する方法の1つは、既存のLSAをリンク状態データベースに挿入または破損することです。誤ったグレースLSAを注入することで、攻撃者が実際にはサービスから撤回されたルーターを吹き込むことができます。[1]で指定された暗号化認証を使用して、リンク状態データベースのこのような破損を防ぐ標準的な方法は、OSPFプロトコル交換を保護することです。[3]では、リンク状態データベースの内容を確保するためのさらに強力な方法が提案されています。
When cryptographic authentication [1] is used on the restarting router the preservation of received sequence numbers in non-volatile storage is not mandatory. There is a risk that a replayed Hello packet could cause neighbor state for a deceased neighbor to be created. However, the risk is no greater than during normal operation.
再起動ルーターで暗号化認証[1]を使用する場合、不揮発性ストレージで受信したシーケンス番号の保存は必須ではありません。再生されたハローパケットが、亡くなった隣人が作成されるために近隣状態を引き起こす可能性があるというリスクがあります。ただし、リスクは通常の操作中よりも大きくありません。
Acknowledgments
謝辞
The authors wish to thank John Drake, Vishwas Manral, Kent Wong, and Don Goodspeed for their helpful comments. We also wish to thank Alex Zinin and Bill Fenner for their thorough review.
著者は、ジョン・ドレイク、ヴィシュワス・マンラル、ケント・ウォン、ドン・グッドスピードに役立つコメントをしてくれたことに感謝します。また、Alex ZininとBill Fennerの徹底的なレビューに感謝します。
Authors' Addresses
著者のアドレス
J. Moy Sycamore Networks, Inc. 150 Apollo Drive Chelmsford, MA 01824
J. Moy Sycamore Networks、Inc。150 Apollo Drive Chelmsford、MA 01824
Phone: (978) 367-2505 Fax: (978) 256-4203 EMail: jmoy@sycamorenet.com
電話：（978）367-2505ファックス：（978）256-4203メール：jmoy@sycamorenet.com
Padma Pillay-Esnault Juniper Networks 1194 N, Mathilda Avenue Sunnyvale, CA 94089-1206
Padma Pillay-Esnault Juniper Networks 1194 N、Mathilda Avenue Sunnyvale、CA 94089-1206
EMail: padma@juniper.net
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519
ACEE LINDEM REDBACK NETWORKS 102 CARRIC BEND COURT CARY、NC 27519
EMail: acee@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。