[要約] RFC 5243は、OSPFデータベース交換の要約リストの最適化に関するものであり、要約の効果的な使用方法と目的を提案しています。このRFCの目的は、ネットワークのリソース使用を最小限に抑えながら、OSPFデータベースの交換を効率化することです。
Network Working Group R. Ogier
Request for Comments: 5243 SRI International
Category: Informational May 2008
OSPF Database Exchange Summary List Optimization
OSPFデータベース交換概要リスト最適化
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets.
このドキュメントでは、OSPFV2およびOSPFV3のデータベース交換プロセスの後方互換の最適化について説明します。この最適化では、ルーターは、LSAの同じまたは最近のインスタンスが隣のデータベースの説明パケットにリストされている場合、隣人に送信された場合、データベースの説明パケットにリンク状態広告（LSA）をリストしません。この最適化により、データベースの説明が大規模なネットワークで約50％削減されます。この最適化は、データベースの説明パケットから不要な情報のみを省略するため、同期に影響しません。
In OSPFv2 [RFC2328] and OSPFv3 [RFC2740], when two neighboring routers become adjacent, they synchronize their link-state databases via the Database Exchange process. Each router sends the other router a set of Database Description (DD) packets that describes the router's link-state database. This is done by listing each LSA (i.e., including the header of each LSA) in one of the sent DD packets. This procedure allows each router to determine whether the other router has newer LSA instances that should be requested via Link State Request packets.
OSPFV2 [RFC2328]およびOSPFV3 [RFC2740]では、2つの隣接するルーターが隣接すると、データベース交換プロセスを介してリンク状態のデータベースを同期します。各ルーターは、他のルーターに、ルーターのリンク状態データベースを記述するデータベース説明（DD）パケットのセットを送信します。これは、送信されたDDパケットの1つに各LSA（つまり、各LSAのヘッダーを含む）をリストすることによって行われます。この手順により、各ルーターは、他のルーターに、リンク状態リクエストパケットを介して要求する必要がある新しいLSAインスタンスを持っているかどうかを判断できます。
The optimization simply observes that it is not necessary for a router (master or slave) to list an LSA in a DD packet if it knows the neighbor already has an instance of the LSA that is the same or more recent (and therefore will not request the LSA). To avoid listing such LSAs in DD packets, when an LSA is listed in a DD packet received from the neighbor, and the Database summary list for the neighbor has an instance of the LSA that is the same as or less recent than the one received, the LSA is removed from the summary list.
最適化は、隣人がすでに同じまたはより最近のLSAのインスタンスを持っていることを知っている場合、ルーター（マスターまたはスレーブ）がDDパケットにLSAをリストする必要がないことを単純に観察します（したがって要求しませんLSA）。このようなLSAのリストをDDパケットにリストするのを避けるために、LSAが近隣から受信したDDパケットにリストされている場合、近隣のデータベースサマリーリストには、受信したものと同じまたは少ないLSAのインスタンスがあります。LSAは要約リストから削除されます。
The optimization, called the Database Exchange summary list optimization, does not affect synchronization, since the LSAs that are omitted from DD packets are unnecessary. The optimization is fully backward compatible with OSPF. The optimization reduces Database Description overhead by about 50% in large networks in which routers are usually already nearly synchronized when they become adjacent, since it reduces the total number of LSA headers exchanged by about one-half in such networks. The optimization is especially beneficial in large networks with limited bandwidth, such as large mobile ad hoc networks.
DDパケットから省略されているLSAは不要なため、データベース交換概要リストの最適化と呼ばれる最適化は同期に影響しません。最適化は、OSPFと完全に逆方向に互換性があります。最適化により、データベースの説明は、大規模なネットワークでオーバーヘッドを約50％減らします。このネットワークでは、ルーターが通常隣接するとすでにほぼ同期されています。最適化は、大規模なモバイルアドホックネットワークなど、帯域幅が限られている大規模なネットワークで特に有益です。
The Database Exchange summary list optimization is defined by modifying Section 10.6 "Receiving Database Description Packets" of RFC 2328 as follows. The second-to-last paragraph of Section 10.6 is replaced with the following augmented paragraph:
データベース交換の概要リストの最適化は、RFC 2328のセクション10.6「データベースの説明パケットの受信」を次のように変更することによって定義されます。セクション10.6の2番目の段落は、次の拡張段落に置き換えられます。
When the router accepts a received Database Description Packet as the next in sequence, the packet contents are processed as follows. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS-external-LSA (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. Otherwise, the router looks up the LSA in its database to see whether it also has an instance of the LSA. If it does not, or if the database copy is less recent, the LSA is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets. In addition, if the Database summary list contains an instance of the LSA that is the same as or less recent than the listed LSA, the LSA is removed from the Database summary list.
ルーターが次の順番に受信したデータベースの説明パケットを受け入れると、パケットのコンテンツは次のように処理されます。リストされている各LSAについて、LSAのLSタイプの有効性がチェックされます。LSタイプが不明の場合（例えば、この仕様で定義されたLSタイプの1-5のいずれでもない場合）、またはこれがAs-ExternalLSA（LS Type = 5）であり、隣接がスタブ領域に関連付けられている場合、近隣イベントを生成し、パケットの処理を停止します。それ以外の場合、ルーターはデータベースのLSAを調べて、LSAのインスタンスもあるかどうかを確認します。そうでない場合、またはデータベースのコピーが最近ではない場合、LSAはリンク状態リクエストリストに掲載されているため、リンク状態リクエストパケットで（すぐにまたは後で）要求できます。さらに、データベースの概要リストに、リストされているLSAと同じまたは最新のLSAのインスタンスが含まれている場合、LSAはデータベースの概要リストから削除されます。
The above additional step (which updates the Database summary list) may be performed either before or after the router looks up the listed LSA in its database and possibly adds the LSA to the Link state request list. However, to implement the optimization, the additional step must be performed for each LSA listed in the received DD packet (to fully update the Database summary list) before the next DD packet is sent in response.
上記の追加ステップ（データベースの要約リストを更新）は、ルーターがデータベースでリストされているLSAを検索する前または後に実行され、LSAをリンク状態要求リストに追加することができます。ただし、最適化を実装するには、次のDDパケットが応答して送信される前に、受信したDDパケットにリストされている各LSAに対して追加のステップを実行する必要があります（データベースの要約リストを完全に更新する）。
Although the optimization does not require that LSAs be listed in DD packets in any particular order, faster lookup of LSAs in the Database summary list may be possible if LSAs are listed in the same order by all routers. If such an ordering is used, then to encourage different implementations to use the same ordering, this document recommends that LSAs be listed in lexicographically increasing order of (LS type, Link State ID, Advertising Router) for OSPFv2 and (LS type, Advertising Router, Link State ID) for OSPFv3.
最適化では、LSAを特定の順序でDDパケットにリストする必要はありませんが、LSAがすべてのルーターによって同じ順序でリストされている場合、データベースサマリーリストのLSAをより高速に検索することは可能になる場合があります。そのような注文が使用されている場合、同じ順序を使用するように異なる実装を奨励するために、このドキュメントは、LSAを辞書型の順序でリストすることを推奨しています（LSタイプ、リンク状態ID、広告ルーター）のOSPFv2および（LSタイプ、広告ルーターの順序、リンク状態id）for ospfv3。
This section describes an example to illustrate the Database Exchange summary list optimization. Assume that routers RT1 and RT2 already have identical databases when they start Database Exchange. Also assume that the list of LSA headers for the database fits into two DD packets. Then, the standard Database Exchange is as follows when RT1 is the first to change the neighbor state to ExStart. Note that each router sends two full DD packets.
このセクションでは、データベース交換の概要リストの最適化を説明する例について説明します。ルーターRT1とRT2がデータベース交換を開始したときに既に同一のデータベースを持っていると仮定します。また、データベースのLSAヘッダーのリストが2つのDDパケットに収まると仮定します。次に、RT1が近隣状態を最初に変更して最初に変更する場合、標準のデータベース交換は次のとおりです。各ルーターは2つのフルDDパケットを送信することに注意してください。
RT1 (slave) RT2 (master)
RT1（スレーブ）RT2（マスター）
ExStart Empty DD (Seq=x,I,M,Master)
------------------------------>
Empty DD (Seq=y,I,M,Master) ExStart
<------------------------------
Exchange Full DD (Seq=y,M,Slave)
------------------------------>
Full DD (Seq=y+1,M,Master) Exchange
<------------------------------
Full DD (Seq=y+1,Slave)
------------------------------>
Full DD (Seq=y+2, Master)
<------------------------------
Full Empty DD (Seq=y+2, Slave)
------------------------------>
Full
If the optimization is used, when RT2 receives the first full DD packet from RT1, it removes from its summary list all LSAs that are listed in the DD packet. Then RT2 sends a DD packet that lists the remaining LSAs (since all of the LSA headers fit into two DD packets). When RT1 receives this DD packet, it removes these remaining LSAs from its summary list (causing it to be empty) and sends an empty DD packet to RT2.
最適化が使用される場合、RT2がRT1から最初のフルDDパケットを受信すると、DDパケットにリストされているすべてのLSAを要約リストから削除します。次に、RT2は残りのLSAをリストするDDパケットを送信します（すべてのLSAヘッダーが2つのDDパケットに収まるため）。RT1がこのDDパケットを受信すると、これらの残りのLSAが要約リストから削除され（空になります）、空のDDパケットをRT2に送信します。
With the optimization, each router sends only one full DD packet instead of two, as shown below.
最適化により、各ルーターは、以下に示すように、2つではなく1つのフルDDパケットのみを送信します。
RT1 (slave) RT2 (master)
RT1（スレーブ）RT2（マスター）
ExStart Empty DD (Seq=x,I,M,Master)
------------------------------>
Empty DD (Seq=y,I,M,Master) ExStart
<------------------------------
Exchange Full DD (Seq=y,M,Slave)
------------------------------>
Full DD (Seq=y+1,Master) Exchange
<------------------------------
Full Empty DD (Seq=y+1, Slave)
------------------------------>
Full
This document does not raise any new security concerns.
このドキュメントでは、新しいセキュリティ上の懸念を提起しません。
This document specifies a simple backward-compatible optimization for OSPFv2 and OSPFv3 that does not require any new number assignment.
このドキュメントは、新しい番号割り当てを必要としないOSPFV2とOSPFV3の簡単な後方互換的な最適化を指定します。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
The recommendation to list LSAs in lexicographical order was suggested by Acee Lindem.
LSAを辞書的順序でリストするという推奨事項は、ACEE Lindemによって提案されました。
Author's Address
著者の連絡先
Richard G. Ogier EMail: rich.ogier@earthlink.net
Richard G. Ogierメール：rich.ogier@earthlink.net
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への情報をお問い合わせください。