RFC5243 日本語訳
5243 OSPF Database Exchange Summary List Optimization. R. Ogier. May 2008. (Format: TXT=11029 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Ogier Request for Comments: 5243 SRI International Category: Informational May 2008
コメントを求めるワーキンググループR.オジェ要求をネットワークでつないでください: 5243年のSRIインターナショナルカテゴリ: 情報の2008年5月
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のDatabase Exchangeの過程とOSPFv3のために後方コンパチブル最適化について説明します。 この最適化では、ルータは隣人に送られたDatabase記述パケットにLink州Advertisement(LSA)を記載しません、同じくらいかLSAの、より最近の例が隣人から既に受け取られたDatabase記述パケットに記載されたなら。 この最適化は大きいネットワークでDatabase記述オーバーヘッドをおよそ50%下げます。 Database記述パケットからの不要な情報を省略するだけであるので、この最適化は同期に影響しません。
1. Introduction
1. 序論
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つの隣接しているルータが隣接するようになると、それらはDatabase Exchangeの過程で自己のリンク州のデータベースを同期させます。 各ルータはルータのリンク州のデータベースについて説明する1セットのDatabase記述(DD)パケットをもう片方のルータに送ります。 送られたDDパケットの1つに各LSAを記載することによって(すなわち、それぞれのLSAのヘッダーを含んでいます)、これをします。 この手順で、各ルータは、もう片方のルータにはLink州Requestパケットを通して要求されているべきであるより新しい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を要求しないでしょう)LSAの例が既にあるのを知っているなら、最適化は、ルータ(マスターか奴隷)がDDパケットにLSAを記載するのが必要でないことを単に観測します。 LSAが隣人から受け取られたDDパケットに記載されていて、同じくらいまたは、同じLSAの例が隣人へのDatabase概要リストでものが受信されたほど最近でなくなるとき、DDパケットにそのようなLSAsを記載するのを避けるために、LSAは概要リストから取り外されます。
Ogier Informational [Page 1] RFC 5243 OSPF Database Summary List Optimization May 2008
[1ページ]RFC5243OSPFデータベース概要リスト最適化2008年5月の情報のオジェ
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.
Database Exchange概要リスト最適化と呼ばれる最適化は同期に影響しません、DDパケットから省略されるLSAsが不要であるので。 最適化はOSPFと互換性があった状態で完全に後方です。 最適化は隣接するようになるとき通常、ルータが既にほとんど同期する大きいネットワークでDatabase記述オーバーヘッドをおよそ50%下げます、およそ半分によってそのようなネットワークで交換されたLSAヘッダーの総数を減少させるので。 最適化は限られた帯域幅に伴う大きい可動の臨時のネットワークなどの大きいネットワークで特に有益です。
2. Specification of Optimization
2. 最適化の仕様
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:
Database Exchange概要リスト最適化は、以下のRFC2328について「データベース記述パケットを受ける」というセクション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.
ルータが次として連続して容認されたDatabase記述Packetを認めるとき、パケット含有量は以下の通り処理されます。 LSAが記載したそれぞれに関しては、LSAのLSタイプは正当性がないかどうかチェックされます。 LSタイプが未知である(例えば、LSのどんなひとりもこの仕様で定義された1-5をタイプしません)、これがASの外部のLSA(LSは=5をタイプする)であり、または隣人がスタッブ領域に関連しているなら、隣人イベントSeqNumberMismatchを発生させてください、そして、パケットを処理するのを止めてください。 さもなければ、ルータは、また、それにはLSAの例があるかどうか確認するためにデータベースでLSAを見上げます。 そうしないか、またはデータベースコピーがそれほど最近でないなら、LSAは、Link州Request Packetsでそれを要求できる(すぐにか何らかの後の時間に)ようにLink州の要求リストに載せられます。 さらに、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.
以前かルータがデータベースで記載されたLSAを見上げて、ことによるとLink州の要求リストにLSAを追加した後に上の追加ステップ(Database概要リストをアップデートする)は実行されるかもしれません。 しかしながら、最適化を実行するために、応答で次のDDパケットを送る前に容認されたDDパケット(Database概要リストを完全にアップデートする)に記載する各LSAのために追加ステップを実行しなければなりません。
Ogier Informational [Page 2] RFC 5243 OSPF Database Summary List Optimization May 2008
[2ページ]RFC5243OSPFデータベース概要リスト最適化2008年5月の情報のオジェ
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.
最適化は、LSAsがどんな特定のオーダーでもDDパケットに記載されているのを必要としませんが、LSAsがすべてのルータによって同次で記載されるなら、Database概要リストのLSAsの、より速いルックアップは可能であるかもしれません。 そして、異なった実現が同じ注文を使用するよう奨励するのにそのような注文を使用するなら、このドキュメントは、LSAsがOSPFv3のためにOSPFv2と(LSタイプ、Advertising Router、Link州ID)に(LSタイプ、Link州ID、Advertising Router)の注文を辞書編集に増加させる際に記載されることを勧めます。
3. Example
3. 例
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.
このセクションは、Database Exchange概要リスト最適化を例証するために例について説明します。 Database Exchangeを始動するときルータのRT1とRT2には同じデータベースが既にあると仮定してください。 また、データベースのためのLSAヘッダーのリストが2つのDDパケットに収まると仮定してください。 その時RT1が隣人状態をExStartに変える1日であるとき、標準のDatabase Exchangeは以下の通りです。 各ルータが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
ExStartの空のDD(Seq=x、I、M、マスター)------------------------------>の空のDD(Seq=y、I、M、マスター)ExStart<。------------------------------ 交換の完全なDD(Seq=y(M)は身を粉にして働きます)------------------------------>の完全なDD(Seq=y+1、M、マスター)交換<。------------------------------ 完全なDD(Seq=y+1、奴隷)------------------------------>の完全なDD(Seq=y+2、マスター)<。------------------------------ 完全な空のDD(Seq=y+2、奴隷)------------------------------>満
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パケットに記載されているすべてのLSAsを取り外します。 そして、RT2は残っているLSAsを記載するDDパケットを送ります(LSAヘッダーが皆、2つのDDパケットに収まるので)。 RT1がこのDDパケットを受けるとき、それは、概要リスト(それが空であることを引き起こす)からLSAsのままで残っているこれらを移して、空のDDパケットをRT2に送ります。
Ogier Informational [Page 3] RFC 5243 OSPF Database Summary List Optimization May 2008
[3ページ]RFC5243OSPFデータベース概要リスト最適化2008年5月の情報のオジェ
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
ExStartの空のDD(Seq=x、I、M、マスター)------------------------------>の空のDD(Seq=y、I、M、マスター)ExStart<。------------------------------ 交換の完全なDD(Seq=y(M)は身を粉にして働きます)------------------------------>の完全なDD(Seq=y+1、マスター)交換<。------------------------------ 完全な空のDD(Seq=y+1、奴隷)------------------------------>満
4. Security Considerations
4. セキュリティ問題
This document does not raise any new security concerns.
このドキュメントはどんな新しい安全上の配慮も上げません。
5. IANA Considerations
5. IANA問題
This document specifies a simple backward-compatible optimization for OSPFv2 and OSPFv3 that does not require any new number assignment.
このドキュメントはOSPFv2とどんな新しい数の課題も必要としないOSPFv3に簡単な後方コンパチブル最適化を指定します。
6. Normative References
6. 引用規格
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[RFC2740] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
7. Acknowledgments
7. 承認
The recommendation to list LSAs in lexicographical order was suggested by Acee Lindem.
辞書編集のオーダーにLSAsを記載するという推薦はAcee Lindemによって勧められました。
Author's Address
作者のアドレス
Richard G. Ogier EMail: rich.ogier@earthlink.net
リチャードG.オジェメール: rich.ogier@earthlink.net
Ogier Informational [Page 4] RFC 5243 OSPF Database Summary List Optimization May 2008
[4ページ]RFC5243OSPFデータベース概要リスト最適化2008年5月の情報のオジェ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Ogier Informational [Page 5]
オジェInformationalです。[5ページ]
一覧
スポンサーリンク
