Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 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 再開に戻す。段階的再起動の間の適切なネットワークの動作は 再開するルータの運用環境についてある仮定をするが、これらの仮定についても 述べる。 Moy, et al. Standards Track [Page 1]  RFC 3623 Graceful OSPF Restart November 2003 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 1. Overview 概観 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 Moy, et al. Standards Track [Page 2]  RFC 3623 Graceful OSPF Restart November 2003 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（ここでは Grace-LSA と呼ぶ）を生成し、特定の時間（grace period）内に段階的再起動を 実行しようとすることを広告する。 - 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). grace period の間、隣接ルータはネットワークトポロジーが安定である限りにおいて 再開ルータに対して、それが完全な隣接である（例: OSPF 隣接状態が Full）かのように LSA を広告し続ける。（例: LS タイプ 1-5,7 を持つ LSDB の LSA の内容の変更なしに 定期的リフレッシュを行う） 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 で述べられる。 もうひとつはその隣接ルータであり、これらは再開が段階的であるために協調しなければ ならない。段階的再起動の間、これらの隣接ルータは「ヘルパーモード」にある、という。 セクション 3 ではヘルパーモードの開始・終了方法を含め、これらヘルパーモードの ルータの責務を記す。 2. Operation of Restarting Router 再開するルータの動作 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 を生成しない。 その代わり、OSPF ドメイン内の他のルータは再開するルータが 再開を始める前に生成した LSA を使って経路を計算する。この間 再開するルータは自身で生成し受信した LSA が有効として受け取られる 代わりに修正も破棄もしない（[1] のセクション 13.4 を見よ）。 特に再開前にルータが生成した grace-LSA は適切に残される。 自身で生成し受信した LSA はそのルータが段階的再起動が終了した あとに処理される（セクション 2.3 を見よ）。 Moy, et al. Standards Track [Page 3]  RFC 3623 Graceful OSPF Restart November 2003 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) もし再開するルータが再開前にそのセグメントの DR であった場合は 再開後自分自身をふたたび DR として選ぶ。再開するルータは 関連するインタフェイスが Waiting 状態の間に、その隣接ルータから 自分を DR としてリストしている Hello パケットを受信することにより 自分が DR であったことを知る。 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 プロトコルを用いて隣接ルータを見つけ、DR と BDR を選び、 隣接ルータとリンクステート DB を初期同期させるためにデータベース交換 手順を実行し、フラッディングによってこの同期を維持する。 The processes of entering graceful restart, and of exiting graceful restart (either successfully or not) are covered in the following sections. 段階的再起動を開始し、また終了する手順については次章で述べる。 2.1. Entering Graceful Restart 段階的再起動を開始する 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 とする）は、ネットワーク運用者によって適切なコマンドが 発行された場合、段階的再起動を行う意思を知らされる。grace period は ネットワーク運用者が指定するか、またはルータの OSPF ソフトウェアにより 必要な grace period が計算される。再開するルータの LSA の有効期限が 過ぎてしまうのを避けるため、grace period は LSRefreshTime（1800 秒）を 超えてはならない。 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 停止手順は実行されないことに注意。これは、他の OSPF ルータには、ルータ X がサービスを続けているように動作させたい ためである。例えばルータ X は自分が生成した LSA を破棄しない。 なぜかというと、再開する間、それらの LSA が他のルータの LSDB に 残っていて欲しいからである。 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 は自分の転送テーブルが最新であり、再開する間にわたって 保持されることを確実にしなければならない。 Moy, et al. Standards Track [Page 4]  RFC 3623 Graceful OSPF Restart November 2003 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 を長くする。 これにより、grace period が十分に延ばされることになる。 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 period（秒単位）が挿入される。 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). grace-LSA はインタフェース毎に生成される。もしルータ X が、隣接ルータが grace-LSA を受信することを確実にしたいのなら、受信確認されるまで再送する （例：通常の OSPF の reliable flooding を実行する）。もし一つ以上の 完全な隣接ルータが 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 period の間、段階的再起動を行っていることを記憶しておくべきである。 （実装者への注：最も簡単な実装の方法は、単純に grace period の終了する 絶対時間を記憶しておくことである。）それから OSPF ソフトウェアは再開／ 再起動されるべきである。再開されたソフトウェアが段階的再起動を実行し 始めたら、セクション 2 に述べたプロトコルの修正が続く。（再開の前には ルータはその隣接ルータが「ヘルパー」として協調するかどうかはわからない。 単に grace-LSA を受信しただけではヘルパー機能を果たすことにはならない。 このメモでは、いずれにせよルータは（段階的でないにせよ）再開をするつもり であるとみなす。） 2.2. When to Exit Graceful Restart いつ段階的再起動を終了するか 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 Moy, et al. Standards Track [Page 5]  RFC 3623 Graceful OSPF Restart November 2003 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」とよばれる）、 およびそのルータが DR であるセグメントにおける再開前ネットワーク LSA を検査することにより決定することが出来る。 これらの LSA はヘルパー隣接ルータから受信することができるであろう。 またこれらの LSA は再開の期間にわたって不揮発性記憶に保存しておく 必要はない。全ての事前の隣接がタイプ 1、またタイプ 2 リンクとして ルータ LSA 中に、またネットワーク 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 の再開前ルータ LSA が ルータ Y へのリンクを含んでいる にもかかわらず、ルータ Y によって生成され X が受信した ルータ LSA に X へのリンクが含まれていない場合である。これは、 次のうちいずれかの場合である。 a) Y が段階的再起動をサポートしていない。 b) Y が grace-LSA を一度も受信していない。 c) Y が何らかの理由によってヘルパーモードを中断した（セクション3.2） LSA 矛盾の特別な場合は、ルータ X が Y と隣接関係を確立した時に 自分自身の再開前 LSA の内容を受信しない場合である。 3) The grace period expires. 3) grace period が経過した場合。 2.3. Actions on Exiting Graceful Restart 段階的再起動を終了する動作 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 を再生成し、 現時点のリンクステート DB の内容にもとづいて転送テーブルを更新する。 特に、段階的再起動を終了する場合、それが成功であってもなくても、以下の アクションが実行されなければならない。 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) ルータは自身が DR である全てのセグメントについてネットワーク 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、Type-7 LSA、AS-external-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) ルータが生成した grace-LSA は除かれなければならない。 Moy, et al. Standards Track [Page 6]  RFC 3623 Graceful OSPF Restart November 2003 3. Operation of Helper Neighbor ヘルパー隣接ルータの動作 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]). ヘルパーの関係はネットワークセグメント毎に存在する。セグメント S における 再開ルータ X の「ヘルパー隣接ルータ」として、ルータ Y はいくつか 実行すべきことがある。Y はネットワークのトポロジー変更をモニタし、 変更がない限り、自身の LSA をあたかも X が継続して OSPF の動作を 行っているかのように広告する。これはつまり Y の LSA は隣接との同期状態に かかわらず、セグメント S において X との隣接関係をリストし続けることである。 このロジックはルータ LSA とネットワーク LSA の両方に影響し、また ネットワークセグメント S のタイプに依存する（[1] のセクション 12.4.1.1 から 12.4.1.5 及び 12.4.2 を見よ）。仮想リンク上でヘルパーとして動作する 場合には、ヘルパーは仮想リンクを通過するエリアに対して、ルータ 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 がネットワークセグメント S の DR であったならば、ヘルパーの関係が終了するまで Y は X を DR として維持する。 3.1. Entering Helper Mode ヘルパーモードの開始 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 を受信したら、Y は以下のチェック事項を 全てパスする限り、関係するセグメントで 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 と完全な 隣接関係（隣接状態 = Full）を持っている。ブロードキャスト、NBMA、 及び P2MP セグメントでは X との隣接関係は grace-LSA 中の IP アドレスによって識別される（補遺 A を見よ）。その他の全ての セグメントタイプでは、grace-LSA の Advertising Router フィールド によって X が識別される。 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 が再開してから LSDB の内容（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. - 内容に変更のあった LSA があれば（[7] のセクション 3.3 を見よ） Y はヘルパーモードの開始を拒否しなければならない。 Router Y may optionally disallow graceful restart with Router X on other network segments. Determining whether Moy, et al. Standards Track [Page 7]  RFC 3623 Graceful OSPF Restart November 2003 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 period が経過していない。これはつまり grace-LSA の LS age が grace-LSA 本文中で指定された grace period より小さいということである。 （補遺 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) ローカルポリシーが X のために Y がヘルパーモードとしてふるまうのを 許可している。設定されるポリシーの例としては a) ヘルパーとして動作することを許可しない b) grace period がある時間 T を越えることを許可しない c) ソフトウェア再開／アップグレードのみヘルパーになる 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. 上記の要求事項に対し、ひとつ例外がある。もし Y が関連するセグメントで X のヘルパーになっているならば、新しい grace-LSA は受信されるべきで あり、grace period は適宜更新されるべきである。 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 のヘルパーであり、他の セグメントではそうではないかもしれない事に注意されたい。しかしながら、 そのような状況はおそらく X の段階的再起動の不完全な終了につながり、 その結果 Y はヘルパーをしていないセグメントで隣接関係を広告し続けられなく なるだろう（セクション 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. 一台のルータは再起動している複数のルータに対して同時にヘルパーになる ことができる。 3.2. Exiting Helper Mode ヘルパーモードの終了 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 の grace period が経過する。 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 Moy, et al. Standards Track [Page 8]  RFC 3623 Graceful OSPF Restart November 2003 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) LSDB の内容の変更がネットワークトポロジーの変更を示し、それが 段階的再起動を強制的に終了させる。特に、ルータ Y が LS タイプ 1-5,7 の新たな 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 の内容が変わった; これは以前の LSDB インスタンスの LSA は含まず、DB から除かれた 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 をインストール したら、スタブエリアに属する隣接ルータとのヘルパー関係を 終了してはならない。というのはその隣接はどのみち AS 外部 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 のヘルパーをやめたとき、その時点での セグメント上の隣接状態に基づいて LSA を再生成する。くわしくは、Y は 以下の動作を行う: a) Y recalculates the Designated Router for the segment, a) Y はそのセグメントの DR を再計算し、 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 がそのセグメントの DR なら、そのセグメントのネットワーク LSA を再生成し、 d) if the segment was a virtual link, Y reoriginates its router- LSA for the virtual link's transit area. d) もしセグメントがバーチャルリンクであったなら、バーチャルリンクが 通過するエリアのルータ 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 との全ての隣接においてヘルパーモードを終了しなければならない。 4. Backward Compatibility 下位互換性 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 ルータとの下位互換性は、上に述べた機能の自動的な 結果である。段階的再起動を要求するルータのひとつ以上の隣接ルータが 未修正のものであるなら、もしくはそれらが grace-LSA を受信しないなら、 段階的再起動は通常の OSPF の再開に切り戻される。 Moy, et al. Standards Track [Page 9]  RFC 3623 Graceful OSPF Restart November 2003 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 動作へと切り戻される。 5. Unplanned Outages 計画外停止 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 を見よ）。特に、計画外停止の 前後において、ルータは転送テーブルの正常性を保障できそうにないように 考えられる。どのようなイベントにおいても、実装者が計画外停止から 段階的に復旧するかどうかのオプションを提供することは、ネットワーク 運用者がそれらのオプションを off にすることを可能にする。 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-LSA を生成しなければならない。 grace-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 Hello パケットを送る前に 生成・送信されなければならない。ブロードキャストネットワーク上では この LSA は AllSPFRouters マルチキャストアドレス（224.0.0.5）宛に 送られなければならない。なぜなら、再開するルータは以前の DR の 状態がわからないからである。 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 は再開したルータが全く隣接関係を持っていなくても、また 以前の隣接関係を全く知らなくても、 Link State Update パケット中に カプセル化して全てのインタフェースから送出される。 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 が配信される確率を上げるため、grace-LSA を複数回送信する 実装がされるかもしれない（[8] の Robustness Variable の例を見よ）。 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（冗長制御プロセッサへの 切り替わり）としなければならない。これにより、隣接ルータが計画外 再起動のヘルパーになるかどうかを決めることができる。 Moy, et al. Standards Track [Page 10]  RFC 3623 Graceful OSPF Restart November 2003 6. Interaction with Traffic Engineering トラフィックエンジニアリングとの相互動作 The operation of the Traffic Engineering Extensions to OSPF [4] during OSPF Graceful Restart is specified in [6]. OSPF の段階的再起動の間のトラフィックエンジニアリング拡張の動作は [6] に記されている。 7. Possible Future Work 将来の（あるかもしれない）拡張 Devise a less conservative algorithm for graceful restart helper termination that provides a comparable level of black hole and routing loop avoidance. ブラックホールやルーティングループ回避の比較できるレベルを提供する ため、ヘルパーモード終了の際のより保守的なアルゴリズムを考案する。 8. Intellectual Property Rights Notice 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. 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. 9. References 9.1. Normative References [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. 9.2. Informative References [3] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [4] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. Moy, et al. Standards Track [Page 11]  RFC 3623 Graceful OSPF Restart November 2003 [5] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003. [6] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress. [7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [8] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. Moy, et al. Standards Track [Page 12]  RFC 3623 Graceful OSPF Restart November 2003 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 を持ち、オペイク ID は 0 とされる。grace-LSA は OSPF ソフト ウェアの段階的再起動を実行しようとするルータによって生成される。 grace-LSA はその隣接ルータに対して、指定された grace period のあいだ、 そのルータが完全な隣接であるかのように広告をし続けることにより、 段階的再起動を援助するよう要請するものである。 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 は最初に生成されたとき、LS age フィールドは 0 にセット される。LS age の現在値は、ルータがどれくらい前に再開の要求をしたかを 示す。LSA の本体は TLV 形式で符号化される。TLV で符号化された情報には grace period の長さ、段階的再起動の理由、いつ grace-LSA がブロードキャスト、 NBMA、または P2MP ネットワークセグメントに関連付けされたか、再開している ルータのインターフェイスアドレスが含まれる。 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 のペイロードは一つ以上の ネストされたタイプ・長さ・値の三組の値からなる。各々の 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Moy, et al. Standards Track [Page 13]  RFC 3623 Graceful OSPF Restart November 2003 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 は、ここは 0 になる）。TLV は 4 オクテットの倍数になる ようにパディングされる。パディングは長さフィールドに数えられない。 なので、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: 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 Grace Period (タイプ 1、長さ 4)。そのルータの隣接ルータが、データベース 同期の状態に関わらず、完全な隣接関係が続いているかの如く広告を 続けるべき秒数。この時間は grace-LSA の LS age フィールドが 0 の ときに開始されるので、以下のいずれかの条件の場合に grace period が 終了する: a) the LS age of the grace-LSA exceeds the value of a Grace Period or a) grace-LSA の LS age フィールドが Grace Period を超える、または 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 インタフェイスアドレス（タイプ 3、長さ 4）。grace-LSA と 関連付けられたサブネットの IP アドレス。ブロードキャスト、NBMA、 P2MP セグメントにおいて、ヘルパールータが再開しているルータを 見分けるのに必要（セクション 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 がデマンド回線で流される場合でも、grace-LSA 中の DoNotAge はセットされてはならない [7]。なぜなら grace-LSA の LS age フィールドが grace period の長さの計算に使われるからである。 Grace-LSAs have link-local scope because they only need to be seen by the router's direct neighbors. grace-LSA はリンクローカルのスコープを持つ。なぜなら、これらは再開する ルータの直接の隣接ルータにのみ必要だからである。 Moy, et al. Standards Track [Page 14]  RFC 3623 Graceful OSPF Restart November 2003 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 には実装によってサポートする・しないを選択するかもしれない追加の 設定パラメータを含む。 B.1. Global Parameters (Minimum subset) グローバルパラメータ（最低限のサブセット） RestartSupport The router's level of support for OSPF graceful restart. Allowable values are none, planned restart only, and planned/unplanned. そのルータが OSPF 段階的再起動をサポートするかどうか。 許容値は、「なし」、「計画的再起動のみ」、「計画的・計画外とも」 である。 RestartInterval The graceful restart interval in seconds. The range is from 1 to 1800 seconds, with a suggested default of 120 seconds. 段階的再起動のインターバル。範囲は 1 から 1800 秒。提案された デフォルト値は 120 秒。 B.2. Global Parameters (Optional) グローバルパラメータ（選択可能） RestartHelperSupport The router's support for acting as an OSPF restart helper. Allowable values are none, planned restart only, and planned/unplanned. そのルータが OSPF 段階的再起動のヘルパーモードをサポートするかどうか。 許容値は、「なし」、「計画的再起動のみ」、「計画的・計画外とも」 である。 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 が存在した場合に、ヘルパーのルータが段階的 再起動（のヘルパーモード）を中止するかどうかを示す。提案された デフォルト値は、これをサポートする。 Moy, et al. Standards Track [Page 15]  RFC 3623 Graceful OSPF Restart November 2003 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 のようなリンクステートプロトコルを攻撃する一つの方法は LSDB へ間違ったLSA を送り込んだり、LSDB 中に存在している LSA を壊す ことである。攻撃者は偽の grace-LSA を送り込むことによってルータを だまし、実質的にサービスさせなくすることができる。このような LSDB の 破壊を予防する標準的な方法は、[1] に述べられた暗号化認証を用いて OSPF のプロトコルのやりとりを安全にする方法である。LSDB の内容を 安全にするより強力な方法が [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. Moy, et al. Standards Track [Page 16]  RFC 3623 Graceful OSPF Restart November 2003 Authors' Addresses J. Moy Sycamore Networks, Inc. 150 Apollo Drive Chelmsford, MA 01824 Phone: (978) 367-2505 Fax: (978) 256-4203 EMail: jmoy@sycamorenet.com 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 EMail: acee@redback.com Moy, et al. Standards Track [Page 17]  RFC 3623 Graceful OSPF Restart November 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. 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. Moy, et al. Standards Track [Page 18]