Network Working Group R. Ogier
Request for Comments: 5243 SRI International
Category: Informational May 2008
OSPF Database Exchange Summary List Optimization
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]では、二つの隣接ルータが隣接なったとき、彼らは、データベース交換プロセスを経て、そのリンクステートデータベースを同期させます。各ルータは他のルータにルータのリンクステートデータベースを記述するデータベース記述（DD）パケットのセットを送信します。これは、送信されたDDパケットのいずれかで（すなわち、各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パケットにリストアップされている場合、DDパケットに、このようなLSAをリストアップ回避するために近隣から受信した、と隣人のためのDatabase概要リストには、受信した1つ以上の最近のと同じかそれ以下である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との完全な下位互換性があります。そのようなネットワークにおいて約半分で交換LSAヘッダの総数を減少させるための最適化は、ルータは通常、それらが隣接してなると既にほぼ同期された大規模なネットワークでは約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の外部のLSA（LSタイプ= 5）であり、隣人が、スタブ領域に関連付けられている場合隣人イベントSeqNumberMismatchを生成し、パケットの処理を停止。そうしないと、ルータはまた、LSAのインスタンスを持っているかどうかを確認するために、そのデータベースにLSAを検索します。そうでない場合、またはデータベースのコピーが少なく、最近であれば、それはリンク状態要求パケットで（すぐにまたはいくつかの後に）要求することができるように、LSAはリンクステート要求リストの上に置かれています。 Database概要リストがリストされたLSAよりも最近のと同じかそれ以下であるLSAのインスタンスを含んでいる場合も、LSAは、Database概要リストから削除されます。
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.
（Database概要リストを更新する）上記の追加のステップが前またはルータがそのデータベースにリストされているLSAを検索し、おそらくLink州の要求リストにLSAを追加した後のいずれかを行ってもよいです。ただし、最適化を実装するために、追加のステップが応答して送信される次のDDパケットの前に受信DDパケット（完全Database概要リストを更新する）に記載されている各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のは、すべてのルータによって同じ順序でリストされている場合は、Database概要リスト内のLSAの速い検索が可能です。そのような順序が使用されている場合は、同じ順序付けを使用するように異なる実装を奨励するために、このドキュメントでは、LSAのが辞書のOSPFv2および（LSタイプ、広告ルータ用（LSタイプ、リンクステートID、広告ルータ）の昇順でリストされることをお勧めしますOSPFv3のため、リンクステートID）。
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はのExStartに隣人の状態を変更することが第一であるとき、次のようです。各ルータは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ヘッダのすべてが、2つのDDパケットに収まるので）、残りのLSAを一覧表示DDパケットを送信します。 RT1このDDパケットを受信すると、それは（それが空であることが原因）、その要約リストから、これらの残りのLSAを除去し、RT2に空DDパケットを送信します。
With the optimization, each router sends only one full DD packet instead of two, as shown below.
以下に示すように、最適化では、各ルータは、代わりに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,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]モイ、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.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、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
リチャード・G・オジェEメール：rich.ogier@earthlink.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。