RFC3623 日本語訳
3623 Graceful OSPF Restart. J. Moy, P. Pillay-Esnault, A. Lindem. November 2003. (Format: TXT=38757 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Moyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3623年のアメリカスズカケノキはカテゴリをネットワークでつなぎます: 標準化過程P.Pillay-Esnault杜松は2003年11月にA.Lindem20ドル紙幣ネットワークをネットワークでつなぎます。
Graceful OSPF Restart
優雅なOSPF再開
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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
Moy、他 OSPF再開2003年11月に優雅な標準化過程[1ページ]RFC3623
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. 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 再開ルータ. . . . . . . . . . . . . . . . 3 2.1の操作。 優雅な状態で入って、再開してください。 . . . . . . . . . . . . . . . 4 2.2. いつ優雅な再開を出ますか? . . . . . . . . . . . . . 5 2.3. 優雅な状態で出ることへの動作は再開します。 . . . . . . . . . . 6 3. アシスタントの隣人. . . . . . . . . . . . . . . . . 7 3.1の操作。 アシスタントモード. . . . . . . . . . . . . . . . . . 7 3.2を入れます。 アシスタントモードを出ます。 . . . . . . . . . . . . . . . . . . 8 4. 後方の互換性. . . . . . . . . . . . . . . . . . . . 9 5。 無計画な供給停止。 . . . . . . . . . . . . . . . . . . . . . . 10 6. 交通工学. . . . . . . . . . . . . 11 7との相互作用。 可能な今後の活動. . . . . . . . . . . . . . . . . . . . . 11 8。 知的所有権に気付きます。 . . . . . . . . . . . . . 11 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1。 引用規格. . . . . . . . . . . . . . . . . . 11 9.2。 有益な参照. . . . . . . . . . . . . . . . . 11A.優雅-LSAは.13のB.の構成可能なパラメタをフォーマットします。 . . . . . . . . . . . . . . . . . . . 15 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . . . 16の承認. . . . . . . . . . . . . . . . . . . . . . . . . 16の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 17の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 18
1. Overview
1. 概観
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は、データベース同期の不足によって引き起こされたルーティング輪、そして/または、ブラックホールの可能性を最小にするために再開ルータを避けます。 再開ルータへのリンクを省略して、ルータの隣人に彼らのLSAsを再発行させることによって、回避は実行されます。
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
しかしながら、(a) ネットワーク形態が安定した状態を保って、再開ルータが再開の向こう側にテーブルを進めさせ(b) 続けることができるなら、推進経路に再開ルータを保つのは安全でしょう。 このメモはそのような優雅な再開を可能にして、自動的に戻って戻るOSPFに増進を記録します。
Moy, et al. Standards Track [Page 2] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[2ページ]RFC3623
to a standard OSPF restart for safety when network topology changes are detected.
標準の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".
- グレース-LSAsは、ここに優雅な再開を試みるルータがリンク地方のOpaque-LSAsを溯源すると呼びました、指定された時間か「据置期間」以内に優雅な再開を実行するという意志を発表して。
- 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).
- 据置期間の間、ネットワーク形態が静的に残る場合にだけ(すなわち、7歳のLSタイプ1-5を変わりがなくて、周期的に残らせるのがリフレッシュするリンク州のデータベースのLSAsの内容は許容されています)、隣人は、まるでそれに完全に隣接しているかのように(すなわち、OSPF隣人州のFull)彼らのLSAsで再開ルータを発表し続けています。
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はアシスタントモードに入って、出るのを含んでいて、ルータがアシスタントモードへ駆け込む責任をカバーします。
2. Operation of Restarting Router
2. 再開ルータの操作
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) 再開ルータは7歳のLSタイプ1- 5と共にLSAsを溯源しません。 代わりに、再開ルータは、それが再開の前に溯源したLSAsを使用することでルートを計算するためにOSPFドメインで他のルータを必要とします。 これが調節されるのを再開ルータが変更しないか、または水洗は、受けました。自己の溯源されたLSAs([1])のセクション13.4を見てください。 代わりに、それらは有効であるとして認められます。 特に適所にある再開の前に溯源された再開ルータがある優雅-LSAsの左。 ルータが優雅な再開を出る(セクション2.3を見てください)時を容認された自己によって溯源されたLSAsまで取扱うでしょう。
Moy, et al. Standards Track [Page 3] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[3ページ]RFC3623
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) 再開ルータが、それが再開の前の与えられたセグメントのDesignated Routerであったことを決定するなら、それは再びDesignated Routerとしてそれ自体を選出します。 関連インタフェースがWaiting状態にある間、ルータについてDesignated Routerに記載する隣人からHelloパケットを受け取るなら、再開ルータは、それがDesignated Routerであったのを知っています。
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プロトコルを使用することで隣人を発見して、DesignatedとBackup Designated Routersを選出して、初めはリンク州のデータベースを隣人と同期させるようにDatabase Exchange手順を実行して、氾濫によるこの同期を維持します。
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
2.1. 入ることの優雅な再開
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 Xと呼ぶ)は優雅な再開に関する願望において知識があります。 また、ネットワーク・オペレータが据置期間の長さを指定するかもしれませんか、または必要な据置期間はルータのOSPFソフトウェアによって計算されるかもしれません。 外で年をとるので再開ルータのLSAsを避けるために、据置期間はLSRefreshTime(1800年の秒)[1]を超えるべきではありません。
In preparation for the graceful restart, Router X must perform the following actions before its software is restarted/reloaded:
優雅な再開に備えて、ソフトウェアが再開されるか、または再ロードされる前にRouter 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停止手順が*でないのが実行した*であることに注意してください、まるでRouter Xが永年勤続に残っているかのように私たちが、他のOSPFルータが行動して欲しいと思うので。 例えば、Router Xは局所的に溯源されたLSAsを洗い流しません、私たちが、彼らに再開の期間の間中他のルータのリンク州のデータベースに残って欲しいと思うので。)
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
Moy、他 OSPF再開2003年11月に優雅な標準化過程[4ページ]RFC3623
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は、LSAsに名誉を与えるのを溯源します。 これらはリンク地方のOpaque-LSAs(Appendix Aを見る)です。 それらのLS Age分野は0に設定されます、そして、要求された据置期間(秒の)は優雅-LSAのボディーに挿入されます。 優雅-LSAの正確なコンテンツはAppendix 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インタフェースに溯源されます。 Router Xが、隣人が端麗LSAsを受け取るのを保証したいなら、彼らが承認されるまで(すなわち、優雅-LSAsの標準のOSPF信頼できる氾濫を実行してください)、それは、LSAsに名誉を与えるのを再送するべきです。 1人以上の完全に隣接している隣人が優雅-LSAsを受け取らないと、彼らはおそらく優雅な再開手順の未完熟終了を引き起こすより受け取るでしょう(セクション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).
優雅-LSAsを送った後に、ルータは非揮発性記憶装置による要求された据置期間の長さに伴う優雅な再開を実行しているという事実を格納するべきです。 (作成者への注意: 単に据置期間の終わりの絶対時間を格納するのは最も簡単であるかもしれません)。 そして、OSPFソフトウェアは、再開されるべきであるか、または再ロードされるべきです。 再び積まれたソフトウェアが優雅な再開を実行し始めるとき、セクション2におけるプロトコル変更は続かれています。 (再開の前にルータが、隣人が「アシスタント」として協力するかどうかを知らないことに注意してください。 優雅-LSAsの単なるレセプションはアシスタント責任の承認を含意しません。 このメモは、ルータがとにかく再開したがっていると仮定します、再開が優雅にならないでも).
2.2. When to Exit Graceful Restart
2.2. いつ優雅な再開を出ますか。
A Router X exits graceful restart when any of the following occurs:
以下のどれかが起こると、Router 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
1) ルータXはすべての隣接番組を回復させました。 ルータXは、そして、ルータがDesignated Router(プレ再開ネットワーク-LSAs)であるところでそれらのセグメントでそれが再開(「あらかじめ再開しているルータLSA」と呼ばれる)の前に最後に溯源したルータ-LSAsを調べることによって、これを決定できます。 これらのLSAsは助けている隣人から受け取られてしまうだろうといって、非揮発性記憶装置に横切って格納される必要はありませんでした。
Moy, et al. Standards Track [Page 5] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[5ページ]RFC3623
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.
再開してください。 前のすべての隣接番組がルータ-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がThisが示そんなにのどちらかY.へのリンクを含みましたが、Xへのリンクを含まないルータYによって溯源されたルータ-LSA a)を受けます。 Yは優雅な再開、b)を支持しません。 Yは優雅-LSAかc)を決して受けませんでした。 Yはある理由で(セクション3.2)アシスタントモードを終えました。 LSA矛盾の特別なケースはRouter XがルータYで隣接番組を確立して、それ自身のプレ再開ルータLSAの例を受けない時です。
3) The grace period expires.
3) 据置期間は期限が切れます。
2.3. Actions on Exiting Graceful Restart
2.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操作に戻って戻ります、reoriginating LSAsがルータの現状のときに基づいていて、リンク州のデータベースの現在のコンテンツに基づく推進テーブルをアップデートして。 首尾よいか不成功に優雅な再開を出るとき、特に、以下の動作は実行されるべきです:
1) The router should reoriginate its router-LSAs for all attached
areas in order to make sure they have the correct contents.
1) ルータは、それらには正しいコンテンツがあるのを確実にするためにすべての付属領域にルータ-LSAsを再由来するべきです。
2) The router should reoriginate network-LSAs on all segments
where it is the Designated Router.
2) ルータはすべてのセグメントのそれがDesignated Routerであるreoriginateネットワーク-LSAsがそうするべきです。
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、システム推進テーブルに結果をインストールして、概要-LSAsを溯源する今回、Type-7 LSAs、およびASの外部のLSAs。
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) どんなもう有効でない自己によって溯源された容認されたLSAsも洗い流されるべきです。
6) Any grace-LSAs that the router originated should be flushed.
6) ルータが溯源したどんな優雅-LSAsも洗い流されるべきです。
Moy, et al. Standards Track [Page 6] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[6ページ]RFC3623
3. Operation of Helper Neighbor
3. アシスタントの隣人の操作
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操作に残ったかのようにLSAsの広告を出し続けています。 これは、YのLSAsが、ネットワークセグメントSの上に隣接番組をXに記載し続けていることを意味します、隣接番組の現在の同期状態にかかわらず。 この論理は、ルータ-LSAsとネットワーク-LSAsの両方についてコンテンツに影響して、また、ネットワークセグメントSのタイプに頼っています。([1])についてセクション12.4.1の.1〜12.4の.1の.5とセクション12.4.2を見てください。 また、仮想のリンクの上に助けるとき、アシスタントは、仮想のリンクのトランジット領域のためにルータ-LSAにビットVをはめ込み続けなければなりません。([1])について12.4に.1を区分してください。
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がDesignated Routerとして関係が始めた一杯、YがXを維持するネットワークセグメントSのDesignated Routerであったなら、関係も終えられます。
3.1. Entering Helper Mode
3.1. アシスタントモードを入れます。
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(隣人州のFull)がある状態で、完全な隣接番組があります。 放送、NBMA、およびPointからMultiPointへのセグメントでは、Xとの隣人関係は優雅-LSA(Appendix Aを見る)のボディーのIPインターフェース・アドレスによって特定されます。 他のすべてのセグメントタイプの上では、Xは優雅-LSA Advertising Router分野によって特定されます。
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.
- 何か7歳のLSタイプ1-5があるLSAsがリストにあれば、彼らは皆、周期的であるに違いありません。リフレッシュします。
- 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.
- 代わりにLSAsがリストにあれば、だれのコンテンツを変えたか。([7])のセクション3.3、Yが、アシスタントモードを入れるのを拒否しなければならないのを確実にしてください。
Router Y may optionally disallow graceful restart with
Router X on other network segments. Determining whether
ルータYは他のネットワークセグメントのRouter Xと共に優雅な再開を任意に禁じるかもしれません。 決定
Moy, et al. Standards Track [Page 7] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[7ページ]RFC3623
changed LSAs have been successfully flooded to router Y on
other network segments is feasible but beyond the scope of
this document.
首尾よくルータへあふれて、他のネットワークセグメントのYが可能であるということですが、変えられたLSAsはこのドキュメントの範囲を超えてそうしました。
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) ローカルの方針で、据置期間がアシスタント、b)でどんなTime T、c) ソフトウェア再ロード/アップグレードの助けだけも、またはd) 決して特定のルータ(OSPF Router IDによって指定される)のためのアシスタントとしての行為も決して超えないことができないとき、Yはa)が決して行為でなかったかもしれないなら構成された方針のX.Examplesのアシスタントとして務めます。
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).
Router 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.
交互に、Router Yは、優雅LSAが受け取られているとき、アシスタントモードを入れるのを選ぶかもしれません、そして、上のチェックはRouter X.があるすべての隣接番組に適用します。独自に各隣接番組を考える場合、アシスタントモードに関して隣接番組に集めるThis実現代替手段は実現と互換性があります。
A single router is allowed to simultaneously serve as a helper for multiple restarting neighbors.
ただ一つのルータは同時に、複数の再開している隣人のためのアシスタントとして勤めることができます。
3.2. Exiting Helper Mode
3.2. アシスタントモードを出ます。
Router Y ceases to perform the helper function for its neighbor Router X on a given segment when one of the following events occurs:
以下の出来事の1つが起こると、ルータYは、隣人Router Xのために与えられたセグメントにヘルパー機能を実行するのをやめます:
1) The grace-LSA originated by X on the segment is flushed. This
indicates the successful termination of graceful restart.
1) LSAにセグメントのXによって溯源される名誉を与えるのは紅潮しています。 これは優雅な再開のうまくいっている終了を示します。
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
3) リンク州のデータベースコンテンツにおける変化はネットワーク形態変化を示します。(それは、優雅な再開の終了を強制します)。 ルータYが明確に新しいLSAを中にインストールする、それ
Moy, et al. Standards Track [Page 8] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[8ページ]RFC3623
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:
LSとのデータベースは1-5、7をタイプします、そして、以下の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の内容は変化しました。 そしてこれが前のリンク州のデータベース例のないLSAsとデータベースからのLSAsを洗い流すことを含んでいますが、周期的な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外部の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:
Routerであるときに、YはXのために与えられたネットワークセグメントでアシスタントモードを出て、それはLSAsが隣接番組の現状のときにセグメントの上でRouter Xに基礎づけたreoriginatesです。 詳細に、Yは以下の行動を取ります:
a) Y recalculates the Designated Router for the segment,
a) セグメントのためのY recalculates Designated Router
b) Y reoriginates its router-LSA for the segment's OSPF area,
b) Y reoriginatesセグメントのOSPFのためのルータ-LSA領域
c) if Y is Designated Router for the segment, it reoriginates the
network-LSA for the segment and
そしてYであるならc)がセグメントのためのDesignated Routerである、セグメントのためにLSAをネットワークでつなぐのを再由来する。
d) if the segment was a virtual link, Y reoriginates its router-
LSA for the virtual link's transit area.
セグメントであるなら、d)は仮想のリンクであり、Y reoriginatesは仮想のリンクのトランジット領域へのそのルータ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で説明されるように)、Router YがRouter Xと共に隣接番組に集めたなら、出口出来事のどれかが隣接番組のためにRouter Xと共に起こると、それはすべての隣接番組のためにRouter Xと共にアシスタントモードを出なければなりません。
4. Backward Compatibility
4. 後方の互換性
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ルータとの後方の互換性は上に記録された機能性の自動結果です。 彼らが、LSAに名誉を与えるのを受けないなら優雅な再開を要求するルータの1人以上の隣人が変更されていないなら、優雅な再開は通常のOSPF再開に戻ります。
Moy, et al. Standards Track [Page 9] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[9ページ]RFC3623
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に省略されている状態でそれらのLSAsを再発行することによって初期のデータベース同期を実行しながら、変更されていないルータは再開しているルータXの周りで掘り始めるでしょう。 これらのLSAsはトポロジー変化としてのアシスタントの隣人、およびLSA矛盾としてのXによって解釈されるでしょう、どちらかの場合で、通常のOSPF操作に戻って。
5. Unplanned Outages
5. 無計画な供給停止
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で説明された計画された再開/再ロードのための手順と対照して、**制御ソフトウェアが操作を再開した後に無計画な供給停止の後に優雅な再開を試みるルータは優雅-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 **再開しているルータがどんなOSPF Hello Packetsも送る前に、溯源して、LSAsを名誉を与えさせなければなりません。 放送網では、AllSPFRoutersマルチキャストアドレスへこのLSAをあふれさせなければならない、(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 優雅-LSAsをLink州Update Packetsで要約して、すべてのインタフェースに出します、再開しているルータには、前の隣接番組に関する隣接番組がなくて知識が全くありませんが。
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 優雅-LSAsを届けるという確率を改良するために、実現は複数の回を彼らに送るかもしれません。([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 優雅-LSAsの再開理由は、0(未知の)へのセットか3であるに違いありません(余分な制御プロセッサに切り替わってください)。 これは、隣人が、彼らが無計画な再開でルータを助けたがっているかどうか決めるのを可能にします。
Moy, et al. Standards Track [Page 10] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[10ページ]RFC3623
6. Interaction with Traffic Engineering
6. 交通工学との相互作用
The operation of the Traffic Engineering Extensions to OSPF [4] during OSPF Graceful Restart is specified in [6].
OSPF Graceful Restartの間のOSPF[4]へのTraffic Engineering Extensionsの操作は[6]で指定されます。
7. Possible Future Work
7. 可能な今後の活動
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
8. 知的所有権通知
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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[1]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[2]Coltun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2370。
9.2. Informative References
9.2. 有益な参照
[3] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997.
[3] マーフィーとS.とムジナとM.とB.ウェリントン、「デジタル署名があるOSPF」、RFC2154、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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
Moy, et al. Standards Track [Page 11] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[11ページ]RFC3623
[5] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC
3101, January 2003.
[5] マーフィー、P.、「OSPFしたがって、短く太くない領域(NSSA)オプション」、RFC3101、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]Moy、J.、「要求サーキットを支えるためにOSPFを広げています」、RFC1793、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] カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月」。
Moy, et al. Standards Track [Page 12] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[12ページ]RFC3623
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に名誉を与えるのは、リンク地方の見られたOpaque-LSA[2]です、3のOpaque Typeと0と等しいOpaque IDを持っていて。 優雅-LSAsはそれがOSPFソフトウェアの優雅な再開を実行したがっているルータによって溯源されます。 優雅-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はLS時代分野を0に設定させます。 そして、LS時代の現行価値は、再開ルータがどれくらい昔に要求をしたかを示します。 LSAのボディーはTLVによってコード化されています。 TLVによってコード化された情報は据置期間の長さ、優雅な再開の理由、およびLSAに名誉を与えるのがPointから放送、NBMAまたはMultiPointへのネットワークセグメントに関連しているときの再開ルータの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 -+
| ... |
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時代| オプション| 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 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のボディーの中のTLVsの形式はTraffic Engineering ExtensionsによってOSPF[4]に使用された形式と同じです。 LSAペイロードは1つ以上の入れ子にされたType/長さ/値(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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Moy, et al. Standards Track [Page 13] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[13ページ]RFC3623
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.
Length分野は八重奏における、値の部分の長さを定義します(その結果、値の部分のないTLVには、ゼロの長さがあるでしょう)。 TLVは4八重奏の整列に水増しされます。 詰め物は長さの分野に含まれていません(3八重奏価値には、したがって、3の長さがあるでしょうが、TLVの総サイズは8つの八重奏でしょう)。 また、並べられた状態で、入れ子にされたTLVsは32ビットです。 例えば、長さの分野が値で設定する1バイトから1、および3バイトの詰め物はTLVの値の一部の端に加えられるでしょう。 認識されていないタイプは無視されます。
The following is the list of TLVs that can appear in the body of a grace-LSA:
↓これは優雅-LSAのボディーに現れることができるTLVsのリストです:
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 優雅Period(=1、長さ=4をタイプします)。 ルータの隣人が、ルータのルータとその隣人の間のデータベース同期の状態にかかわらず同じくらい完全に隣接していた状態で広告を出し続けるべきである秒の数。 優雅-LSAのLS年令が0と等しかったときに、この期間が始まったので、どちらかであるときに、据置期間は終わります:
a) the LS age of the grace-LSA exceeds the value of a Grace Period
or
またはa) 優雅-LSAのLS時代がaグレースPeriodの値を超えている。
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をタイプします)。 ルータの理由が以下の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をタイプします)。 サブネットに関するルータのIPインターフェース・アドレスは優雅-LSAと交際しました。 放送、NBMA、およびPointからMultiPointへのセグメントで必要であることで、アシスタントが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.
LSAに名誉を与えるのが要求サーキット[7]の上に水につかっても、DoNotAgeは優雅-LSAで決して用意ができていません。 これは優雅-LSA LS時代分野が据置期間の持続時間について計算するのに使用されるからです。
Grace-LSAs have link-local scope because they only need to be seen by the router's direct neighbors.
彼らが、ルータのダイレクト隣人によって見られる必要があるだけであるので、優雅-LSAsには、リンク地方の範囲があります。
Moy, et al. Standards Track [Page 14] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[14ページ]RFC3623
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 TLVsはインターネットDraftで説明しなければならなくて、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再開アシスタントが優雅な再開を終えるべきであるか否かに関係なく、示します。 提案されたデフォルトは可能にされます。
Moy, et al. Standards Track [Page 15] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[15ページ]RFC3623
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つは、リンク州のデータベースで偽のLSAsを注入するか、または既存のLSAsを崩壊させることです。 偽の優雅-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、ケントウォン、およびドン・グッドスピードに感謝したがっています。 また、彼らの徹底的なレビューについてアレックス・ジニンとビル・フェナーに感謝申し上げます。
Moy, et al. Standards Track [Page 16] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[16ページ]RFC3623
Authors' Addresses
作者のアドレス
J. Moy Sycamore Networks, Inc. 150 Apollo Drive Chelmsford, MA 01824
J.MoyアメリカスズカケノキはInc.150アポロDriveチェルムズフォード、MA 01824をネットワークでつなぎます。
Phone: (978) 367-2505 Fax: (978) 256-4203 EMail: jmoy@sycamorenet.com
以下に電話をしてください。 (978) 367-2505 Fax: (978) 256-4203 メールしてください: jmoy@sycamorenet.com
Padma Pillay-Esnault Juniper Networks 1194 N, Mathilda Avenue Sunnyvale, CA 94089-1206
Padma Pillay-Esnault杜松は1194年のN、マチルダ・Avenueサニーベル、カリフォルニア94089-1206をネットワークでつなぎます。
EMail: padma@juniper.net
メール: padma@juniper.net
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519
NC Acee Lindem20ドル紙幣ネットワーク102こづなつなぎ法廷のケーリー、27519
EMail: acee@redback.com
メール: acee@redback.com
Moy, et al. Standards Track [Page 17] RFC 3623 Graceful OSPF Restart November 2003
Moy、他 OSPF再開2003年11月に優雅な標準化過程[17ページ]RFC3623
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Moy, et al. Standards Track [Page 18]
Moy、他 標準化過程[18ページ]
一覧
スポンサーリンク
