[要約] RFC 5187は、OSPFv3 Graceful Restartの仕様を定義しており、ネットワークの再起動時にルーティング情報の損失を最小限に抑えるためのメカニズムを提供します。目的は、ネットワークの可用性を向上させ、ユーザーにサービスの中断を最小限に抑えることです。
Network Working Group P. Pillay-Esnault
Request for Comments: 5187 Cisco Systems
Category: Standards Track A. Lindem
Redback Networks
June 2008
OSPFv3 Graceful Restart
ospfv3優雅な再起動
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations.
このドキュメントでは、OSPFV3の優雅な再起動について説明します。OSPFV3 Graceful RestArtは、このドキュメントで説明されている違いを除いて、OSPFV2と同じです。これらの違いには、Grace Link State Advertisements（LSA）の形式とその他の考慮事項が含まれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Grace Link State Advertisement . . . . . . . . . . . . . . . . 2
2.1. Grace LSA - LS Type . . . . . . . . . . . . . . . . . . . . 2
2.2. Grace LSA Format . . . . . . . . . . . . . . . . . . . . . 3
3. Additional Considerations for OSPFv3 Graceful Restart . . . . . 4
3.1. Preservation of LSA ID to Prefix Correspondence . . . . . . 4
3.2. Preservation of Interface IDs for Link-LSAs,
Network-LSAs, and Router-LSAs . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Graceful OSPF restart [GRACE] describes a mechanism to restart the control plane of an OSPFv2 [OSPFv2] router that still has its forwarding plane intact with a minimum of disruption to the network.
Graceful OSPF Restart [Grace]は、ネットワークへの最小限の破壊を伴う転送面がまだそのままであるOSPFv2 [OSPFV2]ルーターの制御面を再起動するメカニズムを説明しています。
In general, the methods described in [GRACE] work for OSPFv3 [OSPFv3] as well. However, OSPFv3 will use a grace-LSA with a different format to signal that a router is initiating (or is about to initiate) a graceful restart. This document describes other OSPFv3 differences as well.
一般に、[Grace]で説明されている方法は、OSPFV3 [OSPFV3]の作品でもあります。ただし、OSPFV3は異なる形式のGrace-LSAを使用して、ルーターが優雅な再起動を開始（または開始しようとしている）ことを示すことを示します。このドキュメントでは、他のOSPFV3の違いについても説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
An OSPFv3 router initiating a graceful restart of its OSPFv3 software originates grace-LSAs. A grace-LSA requests that the router's neighbors aid in its graceful restart by continuing to advertise the router as fully adjacent during the specified grace period. The grace-LSA contains the restarting router grace-period and the reason code indicating the reason for the graceful restart.
OSPFV3ソフトウェアの優雅な再起動を開始するOSPFV3ルーターは、GRACE-LSAを発生します。Grace-LSAは、ルーターの隣人が、指定されたグレース期間中に完全に隣接するルーターを宣伝し続けることにより、その優雅な再起動を支援することを要求します。Grace-LSAには、再起動ルーターのグレース期間と、優雅な再起動の理由を示す理由コードが含まれています。
In OSPFv3 (refer to section 2.11 of [OSPFv3]), neighboring routers on any link are always identified by their router IDs. This contrasts with the OSPFv2 behavior where neighbors on point-to-point networks and virtual links are identified by their Router IDs, while neighbors on broadcast, Non-Broadcast Multi-Access (NBMA), and point-to-multipoint links are identified by their IPv4 interface addresses. Consequently, there is no requirement for the router-address TLV [GRACE] for OSPFv3 graceful restart.
OSPFV3（[OSPFV3]のセクション2.11を参照）では、任意のリンク上の隣接するルーターは常にルーターIDによって識別されます。これは、ポイントツーポイントネットワークと仮想リンクの近隣がルーターIDによって識別されるOSPFV2の動作とは対照的ですが、ブロードキャスト、非放送マルチアクセス（NBMA）、およびポイントツーマルチポイントリンクの隣人は、IPv4インターフェイスアドレス。その結果、OSPFV3 Graceful RestartのルーターアドレスTLV [Grace]の要件はありません。
The TLV formats of the grace-LSA described in [GRACE] remain unchanged.
[Grace]に記載されているGrace-LSAのTLV形式は、変更されていません。
A grace-LSA is defined as an LSA with the LS type equal to 0x000b.
GRACE-LSAは、LSタイプが0x000Bに等しいLSAとして定義されます。
LSA function code LS Type Description
------------------------------------------
11 0x000b GRACE-LSA
Grace-LSA Type and Function Code
Grace-LSAタイプと機能コード
The S2-bit and S1-bit are set to 0 to indicate link-local flooding scope. The U-bit is set to 0 since it isn't applicable to LSAs with link-local flooding scope.
S2ビットとS1ビットは0に設定されており、リンクローカルフラッディング範囲を示しています。Uビットは、Link-Local Flooding Scopeを持つLSAに適用できないため、0に設定されています。
The format of a grace LSA is:
Grace LSAの形式は次のとおりです。
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 |0|0|0| 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Grace-LSA Format
Grace-LSA形式
The Link State ID of a grace-LSA in OSPFv3 is the Interface ID of the interface originating the LSA.
OSPFV3のGRACE-LSAのリンク状態IDは、LSAを発信するインターフェイスのインターフェイスIDです。
The format of each TLV is:
各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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
TLV形式
Grace-LSA TLVs are formatted according to section 2.3.2 of [OSPF-TE].
GRACE-LSA TLVは、[OSPF-TE]のセクション2.3.2に従ってフォーマットされています。
The following is the list of TLVs that can appear in the body of a grace-LSA.
以下は、Grace-LSAの本体に現れることができるTLVのリストです。
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. This TLV MUST always appear in a grace-LSA.
恵み期間（タイプ= 1、長さ= 4）。ルーターの隣人がルーターとその近隣の間のデータベース同期の状態に関係なく、ルーターを完全に隣接するものとして宣伝し続けるべき秒数。このTLVは常にGrace-LSAに表示されなければなりません。
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.
優雅な再起動理由（タイプ= 2、長さ= 1）。次のいずれかのいずれかとして、ルーターの再起動の理由をエンコードします：0（不明）、1（ソフトウェア再起動）、2（ソフトウェアリロード/アップグレード）、または3（冗長制御プロセッサに切り替えます）。このTLVは常にGrace-LSAに表示されなければなりません。
This section describes OSPFv3 unique considerations in addition to those described in [GRACE].
このセクションでは、[Grace]に記載されているものに加えて、OSPFV3の独自の考慮事項について説明します。
In OSPFv2, there is a direct correspondence between summary and external LSA IDs and the prefixes being advertised. However, in OSPFv3, the LSA ID for inter-area prefix LSAs and external LSAs is simply an unsigned 32-bit integer. Hence, to avoid network churn during graceful restart, the restarting router MUST preserve the LSA ID to prefix correspondence across graceful restarts.
OSPFv2では、要約と外部LSA IDと宣伝されているプレフィックスの間には直接的な対応があります。ただし、OSPFV3では、エリア間プレフィックスLSAおよび外部LSAのLSA IDは、単に署名されていない32ビット整数です。したがって、優雅な再起動中のネットワークチャーンを回避するために、再起動ルーターは、優雅な再起動全体で対応をプレフィックスするためにLSA IDを保存する必要があります。
In OSPFv3, the LSA ID for Link-LSAs and Network-LSAs and link descriptions in Router-LSAs map to their corresponding Interface ID. Changes in the Interface ID during graceful restart will result in a mismatch between the restarting router's pre-restart LSAs and its neighbor adjacency state. These disparities will cause the graceful restart to terminate prematurely.
OSPFV3では、ROUTER-LSASのリンクLSAおよびネットワークLSASおよびリンク説明のLSA IDは、対応するインターフェイスIDにマップされています。優雅な再起動中のインターフェイスIDの変更により、ルーターの再起動前LSAとその隣接隣接状態の再起動との間に不一致が発生します。これらの格差は、優雅な再起動が時期尚早に終了するようになります。
Synchronizing Interface ID changes between neighbors is possible. However, placing the burden on the restarting router to preserve Interface IDs across restarts provides for a more robust, more deterministic, and simpler mechanism. Therefore, the OSPFv3 Interface ID, as described in section 3.1.2 of [OSPFv3], MUST be preserved by the restarting router across restarts.
近隣間のインターフェイスIDの変化を同期することが可能です。ただし、再起動ルーターに負担をかけると、再起動全体にインターフェイスIDを保持することで、より堅牢で、より決定的で、よりシンプルなメカニズムが得られます。したがって、[OSPFV3]のセクション3.1.2で説明されているように、OSPFV3インターフェイスIDは、再起動するルーターを再起動することで保存する必要があります。
Many implementations currently use the interface's MIB-II IfIndex [MIB-INTF] for Interface ID. The persistence of Interface ID across reboots is described in section 3.1.5 of [MIB-PERS].
現在、多くの実装は、インターフェイスIDにインターフェイスのMIB-II IFINDEX [MIB-INTF]を使用しています。再起動全体のインターフェイスIDの持続性は、[MIB-PERS]のセクション3.1.5で説明されています。
[OSPFv3-AUTH] relies on manual key distribution which precludes the use of replay protection that utilizes sequence numbers. The replay of an OSPF Link-Update containing a grace-LSA would allow an attacker to deceive neighboring routers into believing that a router that has been taken out of service (either intentionally or via a malicious action by the same attacker) is still active and is in the process of graceful restart. However, this attack is much more difficult than the obvious replay of standard OSPFv3 hello packets to accomplish the same thing by keeping the adjacency up. Since hello packets are sent more predictably and knowledge of the key is not required, the risk added by OSPFv3 graceful restart is insignificant. Hence, this document does not raise any new security concerns other than those covered in [OSPFv3], [OSPFv3-AUTH], and [GRACE].
[OSPFV3-Auth]は、シーケンス番号を使用するリプレイ保護の使用を妨げる手動キーの分布に依存しています。GRACE-LSAを含むOSPFリンクアップデートのリプレイにより、攻撃者は隣接するルーターを欺き、使用不能になったルーター（意図的に、または同じ攻撃者による悪意のあるアクションを介して）を依然としてアクティブであると信じるようになり、優雅な再起動の過程にあります。ただし、この攻撃は、標準のOSPFV3ハローパケットの明らかなリプレイよりもはるかに困難です。Hello Packetsはより予測可能に送信され、キーに関する知識は不要であるため、OSPFV3のGraceful Restartによって追加されるリスクは重要ではありません。したがって、この文書は、[OSPFV3]、[OSPFV3-Auth]、および[Grace]でカバーされている文書以外の新しいセキュリティ上の懸念を提起しません。
A new LSA function code has been assigned for the OSPFv3 grace-LSA. The assignment of 0x000b has been made in the "OSPFv3 LSA Function Codes" sub-registry of the "Open Shortest Path First v3 (OSPFv3) Parameters" registry. OSPFv3 grace-LSA TLVs and sub-TLVs use the "OSPFv2 Grace LSA Top Level TLV" IANA sub-registry of the "Open Shortest Path First v2 (OSPFv2) Parameters" registry.
OSPFV3 Grace-LSAに新しいLSA関数コードが割り当てられています。0x000Bの割り当ては、「OSPFV3 LSA関数コード」で行われました。OSPFV3 GRACE-LSA TLVとサブTLVは、「OSPFV2 GRACE LSAトップレベルTLV」を使用します。
Many thanks to Kireeti Kompella, Les Ginsberg, and David Ward with whom much of this was discussed. The authors also wish to thank Kunihiro Ishiguro and Vivek Dubey for their comments.
Kireeti Kompella、Les Ginsberg、およびDavid Wardに感謝します。著者はまた、コメントをしてくれたKunihiro IshiguroとVivek Dubeyに感謝します。
This document was produced using Marshall Rose's xml2rfc tool.
このドキュメントは、Marshall RoseのXML2RFCツールを使用して作成されました。
[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[Grace] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful OSPF Restart」、RFC 3623、2003年11月。
[OSPF-TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering Extensions to OSPF", RFC 3630, September 2003.
[OSPF-TE] Katz、D.、Yeung、D.、およびK. Kompella、「Traffic Engineering Extensions to OSPF」、RFC 3630、2003年9月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2] Moy、J。、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPFv3] Moy, J., Ferguson, D., and R. Coltun, "OSPF for IPv6", RFC 2740, March 1997.
[OSPFV3] Moy、J.、Ferguson、D。、およびR. Coltun、「OSPF for IPv6」、RFC 2740、1997年3月。
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MIB-INTF] McCloghrie, K. and M. Rose, "Management Information Base for network management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[MIB-INTF] McCloghrie、K。およびM. Rose、「TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II」、STD 17、RFC 1213、1991年3月。
[MIB-PERS] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[Mib-Pers] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[OSPFv3-AUTH] Gupta, M. and N. Melam, "Authentication/ Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3-Auth] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
Authors' Addresses
著者のアドレス
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134 USA
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose、CA 95134 USA
EMail: ppe@cisco.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
ACEE LINDEM REDBACK NETWORKS 102 CARRIC BEND COURT CARY、NC 27519 USA
EMail: acee@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。