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
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.
著作権（C）インターネット協会（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ルーティングプロトコルへの拡張機能について説明します。これは、「グレースフルリスタート」または「ノンストップフォワーディング」と呼ばれています。再起動ルータがタイムリーに、ネットワークトポロジの変更にその転送を調整することができないかもしれません。可能な結果のルーティングループを避けるために、このメモの手順は自動的に、このようなトポロジの変更が検出されたときに、通常のOSPFの再起動に戻り、時や再起動ルータの隣人の1つ以上がこのメモでの機能強化をサポートしていません。グレースフルリスタート時の適切なネットワーク操作は、再起動ルータの動作環境に仮定を行います。これらの仮定にも記載されています。
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".
- グレースフルリスタートを試みるルータは、指定された時間の量または「猶予期間」内グレースフルリスタートを実行する意向を発表し、ここグレース-のLSAと呼ばれる、リンクローカル不透明LSAを発信します。
- 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).
- 猶予期間中は、その隣人は、それは（すなわち、OSPFネイバー状態のフル）完全に隣接していたかのように彼らのLSAに再起動ルータを発表していきますが、ネットワークトポロジは、静的なまま場合にのみ（すなわち、中LSAの内容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処理を変更する必要があります。この期間は、再起動/リロードと隣接の再確立の間、「グレースフルリスタート」と呼ばれています。グレースフルリスタート時：
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を発信しません。代わりに、再起動ルータは、それが前の再スタートに始まったLSAを使用してルートを計算するためにOSPFドメイン内の他のルータを望んでいます。この間、再起動ルータは、変更または受信自己発信LSAをフラッシュしない（のセクション13.4を参照してください[1]）。代わりに、彼らは有効なものとして受け入れられています。具体的には、再起動ルータが再起動する前に発祥猶予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）、再度指定ルータとして自分自身を選出します。再起動ルータは、関連付けられたインターフェイスが待機状態にあるときに、Helloパケットが指定ルータとしてルータをリストネイバーから受信され、場合には、指定ルータをしたことを知っています。
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プロトコルを使用してネイバーを発見指定してバックアップ指定ルータを選出、最初は隣国とのリンクステートデータベースを同期させるためにデータベース交換の手順を実行し、洪水によって、この同期を維持します。
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].
ルータは（ルータ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.)
（私たちは、ルータXは、継続的なサービスに残っているかのように行動する他のOSPFルータをしたいので、一般的な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）ルータは、不揮発性記憶装置内の各インターフェイスで使用される暗号化シーケンス番号を保存する必要があるかもしれません。代替的には、暗号化シーケンス番号生成するためのルータのクロックを使用してクロックを再起動して（同じまたは冗長ルートプロセッサ上で）保存されることを保証することです。これらのいずれも保証することができた場合は、隣接関係を再確立することができます前に、それは再起動後RouterDeadInterval秒かかることがあり、これを大幅に長くするための猶予期間を強制します。
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は、恵み-LSAを発信します。これらは、リンクローカル不透明-のLSA（付録Aを参照してください）です。彼らのLS時代分野は0に設定され、かつ（秒）要求された猶予期間を猶予LSAの体内に挿入されます。猶予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).
猶予LSAはルータのOSPFインターフェイスごとに発信されます。ルータXは、その隣人が猶予-LSAを受けていることを確認したい場合は、それらが確認されるまで、それは（すなわち、猶予LSAの標準OSPF信頼性の氾濫を行う）恵み-LSAを再送する必要があります。一つ以上の完全に隣接している隣人が猶予-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).
猶予のLSAが送信された後、ルータは、不揮発性ストレージに要求された猶予期間の長さとともにグレースフルリスタートを実行していることを記憶すべきです。 （実装者への注意：これは単に、猶予期間の終了の絶対時刻を格納するのが最も簡単であってもよいです）。 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」と呼ばれる）を調べることによってこれを決定、そして、ルータが指定ルータ、事前に再起動ネットワーク - であるそれらのセグメントにすることができますLSAを。これらの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）ルータXは、再起動前のルータLSAと矛盾しているLSAを受信します。例えば、Xは、Xの起動前ルータLSAが、これはどちらかのa）のYは、グレースフルリスタートをサポートしていないことを示しているYにリンクが含まれていなかったにも関わらず、Xへのリンクが含まれていないルータYによって発信ルータLSAを受信します、b）のYは恵み-LSAを受けたことがない、またはc）Yは、何らかの理由（3.2節）のためにそのヘルパーモードを終了しました。ルータXは、ルータYとの隣接関係を確立し、それ自身の再起動前ルータLSAのインスタンスを受信しない場合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:
「グレースフルリスタート」を出ると、再起動ルータは、ルータの現在の状態に基づいてLSAをreoriginatingとリンクステートデータベースの現在の内容に基づいて転送テーブル（単数または複数）を更新し、バック完全に正常OSPF動作に戻ります。 、正常終了または失敗し、グレースフルリスタートを終了するとき、特に、次のアクションを実行する必要があります。
1) The router should reoriginate its router-LSAs for all attached areas in order to make sure they have the correct contents.
1）ルータは、彼らが正しい内容を持っていることを確認しにするために取り付けられているすべての領域について、そのルータLSAをreoriginate必要があります。
2) The router should reoriginate network-LSAs on all segments where it is the Designated Router.
2）ルータは、代表ルータであるすべてのセグメント上のネットワークLSAをreoriginateべきです。
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]）、このシステムフォワーディングテーブルに結果をインストールする時、及び発信要約LSA、タイプ7のLSAとASの外部のLSAを、必要に応じてのセクション16を再実行します。
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は関係なく、隣接の現在の同期状態の、ネットワークセグメントSを介してXに隣接関係を一覧表示し続けることを意味します。このロジックは、（12.4.1.5スルーセクション12.4.1.1とセクションの12.4.2を参照[1]）ルータのLSAとネットワークLSAの両方の内容に影響を与え、また、ネットワークセグメントSの種類に依存します。仮想リンクを経由手助けすると、ヘルパーはまた、ルータLSA仮想リンクの通過エリアについて（[1]のセクション12.4.1）でビット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は助けの関係が始まったネットワークセグメントS上の指定ルーターであれば手助け関係が終了するまで、また、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から猶予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と隣接関係が猶予LSA（付録A参照）の本体にIPインターフェイスアドレスによって識別されます。他のすべてのセグメントタイプでは、Xは、猶予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.
- ルータ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.
- その内容が変更されている（[7]の3.3節を参照）、リスト上のLSAの代わりに存在する場合、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）猶予期間が満了していません。これは恵み-LSAのLS時代が猶予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は、A）、B）猶予期間が時間T、C）のみソフトウェアをリロード/アップグレードに助けを超えることはありません、ヘルパーとして働きませんかもしれません設定されたポリシーのX.例のヘルパーとして動作させることができますまたはd）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を支援していた場合、新しい猶予LSAは受け入れられるべきであると猶予期間はそれに応じて更新する必要があります。
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は、それが役立っていないセグメント（2.2節を参照）に隣接関係を宣伝していきません。しかし、そのような状況はおそらく、Xのグレースフル・リスタートの早期終結につながります。
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.
交互に、猶予LSAを受信したとき、ルータYはヘルパーモードに入ることを選択してもよいし、上記のチェックは、ヘルパーモードに対する隣接関係を集約のこの実装の選択肢は、それぞれ独立して隣接関係を考慮した実装と互換性のあるルータ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によって発信猶予LSAがフラッシュされます。これは、グレースフル・リスタートの正常終了を示します。
2) The grace-LSA's grace period expires.
2）猶予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）リンクステートデータベースの内容の変化は、グレースフルリスタートの終了を強制的ネットワークトポロジの変更を示しています。具体的には、ルータYはLSタイプ1-5,7と、次の2つのプロパティを持つことは、それはLSAの二つの性質があるX.を支援中止すべきとのデータベースに新しいLSAをインストールする場合：
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）LSAは、Xに殺到されていたであろう、Y及びXは完全に隣接していました。 Yが変更ASの外部のLSAをインストールした場合、その隣人は、任意の場合のように、外部LSAを参照しないように、第2のプロパティの例として、それは、スタブ領域に属する隣人と支援の関係を終了しないでください。実装では、グレースフルリスタートを終了からリンクステートデータベースオプションを無効にする設定オプションを提供してもよいです。そのようなオプションは、しかしながら、過渡ルーティングループとブラックホールのリスクを増加させるであろう。
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
Yは、セグメントのルータを指定された場合C）、それはセグメントのネットワーク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.
（セクション3.1で説明したように）ヘルパーモードに入るとき、ルータYルータXとの隣接関係を集約した場合の終了イベントのいずれかがルータ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人のまたは複数の隣人が修正されていない、または、彼らは恵み-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は通常OSPF動作に戻る、いずれの場合も、LSAの矛盾としてトポロジ変化として、およびXによりヘルパー隣人によって解釈されるであろう。
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節で説明した計画の再起動/再ロードするための手順とは対照的に、計画外の停止後にグレースフルリスタートを試みるルータは、*後*その制御ソフトウェアが動作を再開猶予LSAを発信する必要があります。次のポイントは、この猶予-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を猶予LSAは生成する必要がありますし、再起動ルータは任意のOSPF helloパケットを送信します*前*送られます。再起動ルータがその前のDRの状態を認識していないため、ブロードキャストネットワークでは、このLSAはAllSPFRoutersマルチキャストアドレス（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猶予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猶予の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猶予の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]モイ、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オペークLSAオプション"、RFC 2370、1998年7月。
[3] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[3]マーフィー、S.、アナグマ、M.およびB.ウェリントン、 "デジタル署名とOSPF"、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]カッツ、D.、Kompella、K.、およびD.ヨン、 "OSPFバージョン2へのトラフィックエンジニアリング（TE）拡張機能"、RFC 3630、2003年9月。
[5] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[5]マーフィー、P.、 "OSPFない準スタブエリア（NSSA）オプション"、RFC 3101、2003年1月。
[6] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[6] Kompella、K.、ら。、 "一般化MPLSのサポートにルーティング拡張"、ProgressのWork。
[7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[7]モイ、J.、RFC 1793、1995年4月 "オンデマンド・サーキットをサポートするためのOSPFの拡張"。
[8] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[8]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.とA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
A. Grace-LSA Format
A.グレース - 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.
猶予LSAは、リンクローカル不透明LSA [2]、そのOSPFソフトウェアのグレースフルリスタートを実行したいルータによって発信された3のOPAQUE型および0.1グレース - のLSAに等しい不透明IDを有するスコープ。猶予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.
各猶予LSAには、LSAが最初に発信されたときに0に設定LS時代分野を持っています。 LS時代の現在の値は、再起動ルータは、その要求を行ったどのくらい前に示します。 LSAの本体は、TLV符号化されます。 TLV符号化された情報は、猶予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:
猶予LSAの本体内のTLVのフォーマットは、OSPFにトラフィックエンジニアリングの拡張で使用される形式と同じである[4]。 LSAペイロードは、一つ以上のネストされたタイプ/長さ/値（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オクテット整列に埋め込まれます。パディングは、長さフィールド（SO 3つのオクテットの値が3の長さを有するであろうが、TLVの合計サイズは8つのオクテットであろう）には含まれません。ネストされたのTLVはまた、32ビット整列されています。例えば、1つのバイトの値が1に設定され、長さフィールドを持っているでしょう、そして3バイトのパディングは、TLVの値部分の末尾に追加されるであろう。認識できないタイプは無視されます。
The following is the list of TLVs that can appear in the body of a grace-LSA:
猶予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）。ルータの隣人に関係なく、ルータとその近隣諸国との間のデータベースの同期の状態の、完全に隣接するようルータを宣伝し続けなければならない秒数。猶予LSAのLS時代が0に等しかった場合は、この期間が始まって以来のいずれかの場合、猶予期間が終了します。
a) the LS age of the grace-LSA exceeds the value of a Grace Period or
a）の猶予LSAのLS時代は、猶予期間の値を超えましたか
b) the grace-LSA is flushed. See Section 3.2 for other conditions that terminate graceful restart.
b）の猶予LSAがフラッシュされます。グレースフルリスタートを終了し、他の条件については、セクション3.2を参照してください。
This TLV must always appear in a grace-LSA.
このTLVは常に猶予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は常に猶予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インタフェースアドレス（タイプ= 3、長さ= 4）。猶予LSAに関連付けられているサブネット上のルータのIPインターフェイスアドレス。ヘルパーは、再起動するルータを識別するためのIPインタフェースアドレスを使用して放送、NBMAとポイントツーマルチセグメントに必要な（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.
DoNotAgeは猶予LSAは、デマンド回線上でフラッディングされている場合でも、猶予LSAに設定されることはありません[7]。猶予LSAのLS時代分野は、猶予期間の長さを計算するのに使用されているためです。
Grace-LSAs have link-local scope because they only need to be seen by the router's direct neighbors.
彼らは唯一のルータの直接の隣人によって見する必要があるためグレース-LSAは、リンクローカルスコープを持っています。
Additional Grace-LSA TLVs must be described in an Internet Draft and will be subject to the expert review of the OSPF Working Group.
追加のグレース-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は、実装がサポートすることを選択するかもしれないいくつかの追加の設定パラメータを含んでいます。
B.1. Global Parameters (Minimum subset)
B.1。グローバルパラメータ（最小サブセット）
RestartSupport
RestartSupport
The router's level of support for OSPF graceful restart. Allowable values are none, planned restart only, and planned/unplanned.
OSPFのグレースフル・リスタートのサポートのルータのレベル。許容値は、どれだけの再起動を計画していない、および/計画外に計画されています。
RestartInterval
RestartInterval
The graceful restart interval in seconds. The range is from 1 to 1800 seconds, with a suggested default of 120 seconds.
秒でグレースフルリスタートの間隔。範囲は120秒の提案されたデフォルトで、1から1800秒です。
B.2. Global Parameters (Optional)
B.2。グローバルパラメータ（オプション）
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.
再起動するルータにフラッディングされるだろうか、再起動ルータの再送リストに変更されたLSAがある場合には、グレースフルリスタートが開始されたときにLSAに変更がある場合OSPFの再起動のヘルパーはグレースフルリスタートを終了すべきかどうかを示します。推奨のデフォルトが有効になっています。
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などのリンクステートプロトコルを攻撃する方法の一つは、に偽のLSA、またはで破損し、既存の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]再起動ルータ上で使用される場合、不揮発性記憶装置で受信されたシーケンス番号の保存は必須ではありません。再生Helloパケットを作成する故人隣人のために隣人状態を引き起こす可能性があるというリスクがあります。しかし、リスクは、通常動作時よりも大きくありません。
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.
作者は彼らの役に立つコメントをジョン・ドレイク、Vishwas Manral、ケント・ウォン、そしてドン・グッドスピードに感謝したいです。我々はまた、彼らの徹底的なレビューのためにアレックスジニンとビルフェナーに感謝したいです。
Authors' Addresses
著者のアドレス
J. Moy Sycamore Networks, Inc. 150 Apollo Drive Chelmsford, MA 01824
J.モイシカモアネットワークス株式会社150アポロドライブチェルムズフォード、MA 01824
Phone: (978) 367-2505 Fax: (978) 256-4203 EMail: jmoy@sycamorenet.com
電話：（978）367-2505ファックス：（978）256-4203 Eメール：jmoy@sycamorenet.com
Padma Pillay-Esnault Juniper Networks 1194 N, Mathilda Avenue Sunnyvale, CA 94089-1206
パドマPillay-Esnaultジュニパーネットワークスの1194 N、マチルダアベニューサニーベール、CA 94089から1206
EMail: padma@juniper.net
メールアドレス：padma@juniper.net
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519
ACEE Lindemレッドバック・ネットワーク102 Carricベンド裁判所カリー、NC 27519
EMail: acee@redback.com
メールアドレス：acee@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。