Network Working Group R. Ogier
Request for Comments: 5614 SRI International
Category: Experimental P. Spagnolo
Boeing
August 2009
Mobile Ad Hoc Network (MANET) Extension of OSPF
Using Connected Dominating Set (CDS) Flooding
Abstract
抽象
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information.
この文書では、モバイル広告のアドホックネットワーク（MANET）をサポートするためのOSPFv3の拡張子を指定します。 OSPF-MDRと呼ばれる拡張機能は、アドホックネットワークにおける用の新しいOSPFインターフェイスタイプとして設計されています。 OSPF-MDRは、MANET指定ルータ（先MDR）とバックアップ先MDRからなる、MANETルータのサブセットの選択に基づいています。 MDRが接続支配セット（CDS）を形成し、各MDRとバックアップ先MDRは一緒に堅牢ため2連結CDSを形成します。このCDSは2つの方法で利用されています。まず、洪水のオーバーヘッドを減らすために、最適化された氾濫手順はのみ（バックアップ）のMDRバック受信インタフェースから新しいリンク状態アドバタイズメント（LSA）をフラッドする使用されています。信頼性の氾濫は、隣接沿っLSAを再送信することによって確保されています。第二に、隣接関係が密なネットワークではるかに優れた拡張が可能になり、唯一の（バックアップ）のMDRと隣人のサブセットとの間に形成されています。 CDSは、ハロープロトコル拡張内に設けられた2ホップネイバー情報を使用して構築されています。こんにちはプロトコルは、さらに、隣接状態の変化のみを報告した差動helloを可能にすることにより、最適化されています。オプションは、オーバーヘッドが少ないトポロジ情報を広告することで減らすことができるように、完全または部分的なトポロジー情報を提供するルータのLSAを発信するために指定されています。
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
2. Overview ........................................................7
2.1. Selection of MDRs, BMDRs, Parents, and Adjacencies .........8
2.2. Flooding Procedure .........................................9
2.3. Link State Acknowledgments ................................10
2.4. Routable Neighbors ........................................10
2.5. Partial and Full Topology LSAs ............................11
2.6. Hello Protocol ............................................12
3. Interface and Neighbor Data Structures .........................12
3.1. Changes to Interface Data Structure .......................12
3.2. New Configurable Interface Parameters .....................13
3.3. Changes to Neighbor Data Structure ........................15
4. Hello Protocol .................................................17
4.1. Sending Hello Packets .....................................17
4.2. Receiving Hello Packets ...................................20
4.3. Neighbor Acceptance Condition .............................24
5. MDR Selection Algorithm ........................................25
5.1. Phase 1: Creating the Neighbor Connectivity Matrix ........27
5.2. Phase 2: MDR Selection ....................................27
5.3. Phase 3: Backup MDR Selection .............................29
5.4. Phase 4: Parent Selection .................................29
5.5. Phase 5: Optional Selection of Non-Flooding MDRs ..........30
6. Interface State Machine ........................................31
6.1. Interface States ..........................................31
6.2. Events that Cause Interface State Changes .................31
6.3. Changes to Interface State Machine ........................32
7. Adjacency Maintenance ..........................................32
7.1. Changes to Neighbor State Machine .........................33
7.2. Whether to Become Adjacent ................................34
7.3. Whether to Eliminate an Adjacency .........................35
7.4. Sending Database Description Packets ......................35
7.5. Receiving Database Description Packets ....................36
8. Flooding Procedure .............................................37
8.1. LSA Forwarding Procedure ..................................38
8.2. Sending Link State Acknowledgments ........................41
8.3. Retransmitting LSAs .......................................42
8.4. Receiving Link State Acknowledgments ......................42
9. Router-LSAs ....................................................43
9.1. Routable Neighbors ........................................44
9.2. Backbone Neighbors ........................................45
9.3. Selected Advertised Neighbors .............................45
9.4. Originating Router-LSAs ...................................46
10. Calculating the Routing Table .................................47
11. Security Considerations .......................................49
12. IANA Considerations ...........................................50
13. Acknowledgments ...............................................51
14. Normative References ..........................................51
15. Informative References ........................................51
Appendix A. Packet Formats .......................................52
A.1. Options Field ............................................52
A.2. Link-Local Signaling .....................................52
A.3. Hello Packet DR and Backup DR Fields .....................57
A.4. LSA Formats and Examples .................................57
Appendix B. Detailed Algorithms for MDR/BMDR Selection ...........62
B.1. Detailed Algorithm for Step 2.4 (MDR Selection) ..........62
B.2. Detailed Algorithm for Step 3.2 (BMDR Selection) .........63
Appendix C. Min-Cost LSA Algorithm ...............................65
Appendix D. Non-Ackable LSAs for Periodic Flooding ...............68
Appendix E. Simulation Results ...................................69
This document specifies an extension of OSPFv3 [RFC5340] to support a new interface type for mobile ad hoc networks (MANETs), i.e., for broadcast-capable, multihop wireless networks in which routers and hosts can be mobile. Note that OSPFv3 is specified by describing the modifications to OSPFv2 [RFC2328]. This MANET extension of OSPFv3 is also applicable to non-mobile mesh networks using layer-3 routing. This extension does not preclude the use of any existing OSPF interface types, and is fully compatible with legacy OSPFv3 implementations.
この文書では、ルータとホストが移動することが可能な放送対応、マルチホップ無線ネットワークのための、すなわちモバイルアドホックネットワーク（MANET）のための新しいインタフェースタイプをサポートするためのOSPFv3 [RFC5340]の拡張を指定します。 OSPFv3はOSPFv2の[RFC2328]への変更を記述することによって指定されていることに注意してください。 OSPFv3のこのMANET延長もレイヤ3ルーティングを使用して非モバイルメッシュネットワークに適用可能です。この拡張は、既存のOSPFインターフェイスタイプの使用を排除し、従来のOSPFv3の実装と完全な互換性がありません。
Existing OSPF interface types do not perform adequately in MANETs, due to scaling issues regarding the flooding protocol operation, inability of the Designated Router election protocol to converge in all scenarios, and large numbers of adjacencies when using a point-to-multipoint interface type.
ポイント・ツー・マルチポイントインターフェイスタイプを使用している場合、既存のOSPFインターフェイスタイプが原因スケーリングフラッディングプロトコルの動作に関する問題、すべてのシナリオで収束するのDesignated Router選挙プロトコルのできないこと、および隣接関係の多数に、アドホックネットワークにおけるでは十分に機能しません。
The approach taken is to generalize the concept of an OSPF Designated Router (DR) and Backup DR to multihop wireless networks, in order to reduce overhead by reducing the number of routers that must flood new LSAs and reducing the number of adjacencies. The generalized (Backup) Designated Routers are called (Backup) MANET Designated Routers (MDRs). The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness (if the network itself is biconnected). By definition, each router in the MANET either belongs to the CDS or is one hop away from it. A distributed algorithm is used to select and dynamically maintain the biconnected CDS. Adjacencies are established only between (Backup) MDRs and a subset of their neighbors, thus resulting in a dramatic reduction in the number of adjacencies in dense networks, compared to the approach of forming adjacencies between all neighbor pairs. The OSPF extension is called OSPF-MDR.
取られたアプローチは、新しいLSAをフラッディングしなければならないルータの数を低減し、隣接の数を減らすことによって、オーバーヘッドを低減するために、無線ネットワークをマルチホップするOSPF指定ルータ（DR）とバックアップDRの概念を一般化することです。一般化（バックアップ）指定ルータは、（バックアップ）MANET指定ルータ（のMDR）と呼ばれています。 MDRが接続支配セット（CDS）を形成し、（ネットワーク自体が2連結されている場合）のMDRとバックアップ先MDRは一緒に堅牢ため2連結CDSを形成します。定義により、MANET内の各ルータは、CDSに属するか、または離れてから1つのホップのいずれか。分散アルゴリズムを選択し、動的に2連結CDSを維持するために使用されます。隣接関係は、このように全ての隣接対の間の隣接関係を形成する手法に比べて、緻密なネットワークにおける隣接の数の劇的な減少をもたらすのみ（バックアップ）のMDRおよびその近傍の部分集合との間で確立されています。 OSPF拡張機能は、OSPF-MDRと呼ばれています。
Hello packets are modified, using OSPF link-local signaling (LLS; see [RFC5613]), for two purposes: to provide neighbors with 2-hop neighbor information that is required by the MDR selection algorithm, and to allow differential Hellos that report only changes in neighbor states. Differential Hellos can be sent more frequently without a significant increase in overhead, in order to respond more quickly to topology changes.
ハローパケットは（LLS; [RFC5613]を参照）OSPFリンクローカルシグナリングを使用して、修飾された2つの目的のために、：MDR選択アルゴリズムによって必要とされる2ホップネイバー情報をネイバーを提供するために、唯一報告差動helloを可能にします隣人状態の変化。差動ハローズは、トポロジの変更に迅速に対応するためには、オーバーヘッドを大幅に増加させることなく、より頻繁に送信することができます。
Each MANET router advertises a subset of its MANET neighbors as point-to-point links in its router-LSA. The choice of which neighbors to advertise is flexible, allowing overhead to be reduced by advertising less topology information. Options are specified for originating router-LSAs that provide full or partial topology information.
各MANETルータは、そのルータLSAでのポイントツーポイントリンクとしてそのMANETネイバーのサブセットをアドバタイズします。隣人が宣伝するかの選択は、オーバーヘッドが少ないトポロジ情報を広告することで減らすことができるように、柔軟です。オプションは、完全または部分的なトポロジー情報を提供するルータのLSAを発信するために指定されています。
This document is organized as follows. Section 2 presents an overview of OSPF-MDR, Section 3 presents the new interface and neighbor data items that are required for the extension, Section 4 describes the Hello protocol, including procedures for maintaining the 2-hop neighbor information, Section 5 describes the MDR selection algorithm, Section 6 describes changes to the Interface state machine, Section 7 describes the procedures for forming adjacencies and deciding which neighbors should become adjacent, Section 8 describes the flooding procedure, Section 9 specifies the requirements and options for the contents of router-LSAs, and Section 10 describes changes in the calculation of the routing table.
次のようにこの文書は、組織化されています。セクション2セクション3セクション5はMDRを説明し、第4章は2ホップネイバー情報を維持するための手順を含む、ハロープロトコルを記述し、拡張するために必要とされる新たなインターフェースと隣接データ項目を提示し、OSPF-MDRの概要を示し選択アルゴリズム、セクション6は、第7部9はルータLSAの内容のための要件とオプションを指定し、第8章は、フラッディング手順を説明し、隣接関係を形成し、隣接なるべきネイバーを決定するための手順を説明し、インタフェース状態マシンへの変更を記述する、およびセクション10は、ルーティングテーブルの計算の変更を記載しています。
The appendices specify packet formats, detailed algorithms for the MDR selection algorithm, an algorithm for the selection of a subset of neighbors to advertise in the router-LSA to provide shortest-path routing, a proposed option that uses non-ackable LSAs to provide periodic flooding without the overhead of Link State Acknowledgments, and simulation results that predict the performance of OSPF-MDR in mobile networks with up to 200 nodes. Additional information and resources for OSPF-MDR can be found at http://www.manet-routing.org.
付録は、パケットフォーマット、MDR選択アルゴリズムの詳細なアルゴリズムを、最短パスルーティング、定期的提供する非ackable LSAを使用して提案のオプションを提供するために、ルータLSAにアドバタイズするネイバーのサブセットを選択するためのアルゴリズムを指定しますリンクステート謝辞のオーバーヘッドなしに氾濫し、最大200のノードとモバイルネットワークにおけるOSPF-MDRの性能を予測するシミュレーション結果。 OSPF-MDRのための追加情報やリソースがhttp://www.manet-routing.orgで見つけることができます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
In addition, this document uses the following terms:
また、この文書は、次の用語を使用します。
MANET Interface A MANET Interface is a new OSPF interface type that supports broadcast-capable, multihop wireless networks. Two neighboring routers on a MANET interface may not be able to communicate directly with each other. A neighboring router on a MANET interface is called a MANET neighbor. MANET neighbors are discovered dynamically using a modification of OSPF's Hello protocol.
MANETインタフェースA MANETインタフェースは、放送可能な、マルチホップ無線ネットワークサポートする新しいOSPFインターフェイスタイプです。 MANETインタフェース上の2つの隣接ルータが互いに直接通信することができないかもしれません。 MANETインターフェイス上の隣接ルータは、MANETの隣人と呼ばれています。 MANETの隣人は、OSPFのHelloプロトコルの変更を使用して動的に発見されています。
MANET Router A MANET Router is an OSPF router that has at least one MANET interface.
MANETルータA MANETルータは、少なくとも一つのMANETインタフェースを有するOSPFルータです。
Differential Hello A Differential Hello is a Hello packet that reduces the overhead of sending full Hellos, by including only the Router IDs of neighbors whose state changed recently.
差動こんにちはA差動こんにちは状態最近変更隣人の唯一のルータIDを含めることにより、フルhelloを送信するのオーバーヘッドを低減Helloパケットです。
2-Hop Neighbor Information This information specifies the bidirectional neighbors of each neighbor. The modified Hello protocol provides each MANET router with 2-hop neighbor information, which is used for selecting MDRs and Backup MDRs.
2ホップネイバー情報この情報は、各隣接の双方向ネイバーを指定します。修飾されたHelloプロトコルは、各MDRとバックアップ先MDRを選択するために使用されている2ホップネイバー情報、各MANETルータを提供します。
MANET Designated Router (MDR) A MANET Designated Router is one of a set of routers responsible for flooding new LSAs, and for determining the set of adjacencies that must be formed. The set of MDRs forms a connected dominating set and is a generalization of the DR found in broadcast networks. Each router runs the MDR selection algorithm for each MANET interface, to decide whether the router is an MDR, Backup MDR, or neither for that interface.
ルータ（MDR）MANET代表ルータを指定MANETは、新しいLSAをフラッディングするため、および形成されなければならない隣接のセットを決定する責任ルータのセットのうちの1つです。 MDRの集合は、接続された支配的なセットを形成し、DRの一般化は、放送ネットワークにおいて見出されます。各ルータは、ルータがMDR、バックアップMDR、またはそのインターフェイスのどちらであるかどうかを判断するために、各MANETインタフェースのためのMDR選択アルゴリズムを実行します。
Backup MANET Designated Router (Backup MDR or BMDR) A Backup MANET Designated Router is one of a set of routers responsible for providing backup flooding when neighboring MDRs fail. The set of MDRs and Backup MDRs forms a biconnected dominating set. The Backup MDR is a generalization of the Backup DR found in broadcast networks.
バックアップMANETは、バックアップMANET指定ルータが隣接のMDRが失敗したときのバックアップフラッディングを提供する責任ルータのセットの1つであるルータ（バックアップMDRまたはBMDR）を指定します。 MDRとバックアップのMDRのセットは、2連結支配集合を形成しています。バックアップMDRは、DRは放送ネットワークで見つかったバックアップの一般化です。
MDR Other A router is an MDR Other for a particular MANET interface if it is neither an MDR nor a Backup MDR for that interface.
それはMDRも、そのインターフェイスのバックアップMDRでもない場合MDR他のルータは、特定のMANETインタフェースのためのMDRその他のです。
Parent Each router selects a Parent for each MANET interface. The Parent of a non-MDR router will be a neighboring MDR if one exists. The Parent of an MDR is always the router itself. Each non-MDR router becomes adjacent with its Parent. The Router ID of the Parent is advertised in the DR field of each Hello sent on the interface.
親は、各ルータは、各MANETインタフェースの親を選択します。が存在する場合、非MDRルータの親は、隣接MDRであろう。 MDRの親は常にルータ自体です。各非MDRルータは、その親と隣接なります。親のルータIDは、各ハローのDRフィールドにアドバタイズされるインターフェイス上で送信されました。
Backup Parent If the option of biconnected adjacencies is chosen, then each MDR Other selects a Backup Parent, which will be a neighboring MDR or BMDR if one exists that is not the Parent. The Backup Parent of a BMDR is always the router itself. Each MDR Other becomes adjacent with its Backup Parent if it exists. The Router ID of the Backup Parent is advertised in the Backup DR field of each Hello sent on the interface.
バックアップ親2連結隣接のオプションを選択する場合、各MDR他の一つは、その親でない存在する場合、隣接MDR又はBMDRされるバックアップ親を選択します。 BMDRのバックアップ親は常にルータ自体です。それが存在する場合、各MDRその他は、その予備親に隣接なります。バックアップ親のルータIDは、各ハローのバックアップDRフィールドにアドバタイズされるインターフェイス上で送信されました。
Bidirectional Neighbor A bidirectional neighbor is a neighboring router whose neighbor state is 2-Way or greater.
双方向ネイバー双方向ネイバーは、そのネイバー状態2ウェイ以上である隣接ルータです。
Routable Neighbor A bidirectional MANET neighbor becomes routable if the SPF calculation has produced a route to the neighbor and the neighbor satisfies a quality condition. Once a neighbor becomes routable, it remains routable as long as it remains bidirectional. Only routable and Full neighbors can be used as next hops in the SPF calculation, and can be included in the router-LSA originated by the router.
SPFの計算は隣人への経路を生成しており、近隣の品質条件を満たしている場合、ルーティング可能な近隣双方向MANETネイバーがルーティング可能となります。ネイバーがルーティング可能になると、それは限り、それは双方向のままでルーティング可能なまま。のみルーティング可能とフル隣人はSPF計算でネクストホップとして使用することができ、およびルータLSAルータによって発信に含めることができます。
Non-Flooding MDR A non-flooding MDR is an MDR that does not automatically flood received LSAs back out the receiving interface, but performs backup flooding like a BMDR. Some MDRs may declare themselves non-flooding in order to reduce flooding overhead.
非フラッディングMDRは非洪水のMDRは自動的に受信インタフェースうち受信したLSAをフラッディングされませんMDRが、BMDRなどのバックアップフラッディングを実行します。いくつかのMDRは、洪水のオーバーヘッドを削減するために、自ら非洪水宣言してもよいです。
This section provides an overview of OSPF-MDR, including motivation and rationale for some of the design choices.
このセクションでは、設計上の選択肢のいくつかの動機や根拠など、OSPF-MDRの概要を説明し、提供します。
OSPF-MDR was motivated by the desire to extend OSPF to support MANETs, while keeping the same design philosophy as OSPF and using techniques that are similar to those of OSPF. For example, OSPF reduces overhead in a broadcast network by electing a Designated Router (DR) and Backup DR, and by having two neighboring routers form an adjacency only if one of them is the DR or Backup DR. This idea can be generalized to a multihop wireless network by forming a spanning tree, with the edges of the tree being the adjacencies and the interior (non-leaf) nodes of the tree being the generalized DRs, called MANET Designated Routers (MDRs).
OSPFと同じ設計思想を維持し、OSPFのものと類似している技術を使用しながら、OSPF-MDRは、アドホックネットワークにおけるをサポートするために、OSPFを拡張する欲求によって動機づけました。例えば、OSPFは、指定ルータ（DR）とバックアップDRを選出することによって、二つの隣接ルータを有することによって、ブロードキャストネットワークにおけるオーバーヘッドを低減するそれらの一つはDRまたはバックアップDRの場合にのみ隣接関係を形成します。このアイデアは、ツリーの縁隣接及び内部（非リーフ）一般DRS、呼び出さMANET指定ルータ（のMDR）にある木のノードであると、スパニングツリーを形成することにより、マルチホップ無線ネットワークに一般化することができます。
To provide better robustness and fast response to topology changes, it was decided that a router should decide whether it is an MDR based only on local information that can be obtained from neighbors' Hellos. The resulting set of adjacencies therefore does not always form a tree globally, but appears to be a tree locally. Similarly, the Backup DR can be generalized to Backup MDRs (BMDRs), to provide robustness through biconnected redundancy. The set of MDRs forms a connected dominating set (CDS), and the set of MDRs and BMDRs forms a biconnected dominating set (if the network itself is biconnected).
優れた堅牢性とトポロジの変化への迅速な応答を提供するためには、ルータは、それが唯一の隣人のハローズから入手することができますローカル情報に基づいてMDRあるかどうかを決める必要があることを決定しました。隣接の結果セットは、したがって、常にグローバルなツリーを形成するが、ローカルで木のように見えるしません。同様に、バックアップDRは2連結冗長性を介して堅牢性を提供するために、バックアップ先MDR（BMDRs）に一般化することができます。 MDRの集合は、接続された支配セット（CDS）とのMDRのセットを形成し、（ネットワーク自体が2連結されている場合）BMDRsは2連結支配集合を形成します。
The following subsections provide an overview of each of the main features of OSPF-MDR, starting with a summary of how MDRs, BMDRs, and adjacencies are selected.
以下のサブセクションでは、各MDR、BMDRs、および隣接が選択されている方法の要約で始まる、OSPF-MDRの主な特徴の各々の概要を提供します。
The MDR selection algorithm is distributed; each router selects itself as an MDR, BMDR, or other router (called an "MDR Other") based on information about its one-hop neighborhood, which is obtained from Hello packets received from neighbors. Routers are ordered lexicographically based on the tuple (RtrPri, MDR Level, RID), where RtrPri is the Router Priority, MDR Level represents the current state of the router (2 for an MDR, 1 for a BMDR, and 0 for an MDR Other), and RID is the Router ID. Routers with lexicographically larger values of (RtrPri, MDR Level, RID) are given preference for becoming MDRs.
MDR選択アルゴリズムは、分散されています。各ルータは、ネイバーから受信したHelloパケットから得られるの1ホップ近隣に関する情報に基づいて（「MDRその他」と呼ばれる）MDR、BMDR、又は他のルータとしてそれ自身を選択します。ルータはRtrPriルータ優先度で、MDRレベルは、MDR 2（ルータの現在の状態を表すBMDR 1、及びMDRその他0タプル（RtrPri、MDRレベル、RID）、に基づいて辞書式に順序付けられます）、およびRIDルータIDです。 （RID RtrPri、MDRレベル）の辞書より大きな値を持つルータは、各MDRになるために優先順位を与えられています。
The MDR selection algorithm can be summarized as follows. If the router itself has a larger value of (RtrPri, MDR Level, RID) than all of its neighbors, it selects itself as an MDR. Otherwise, let Rmax denote the neighbor with the largest value of (RtrPri, MDR Level, RID). The router then selects itself as an MDR unless each neighbor can be reached from Rmax in at most k hops via neighbors that have a larger value of (RtrPri, MDR Level, RID) than the router itself, where k is the parameter MDRConstraint, whose default value is 3.
次のようにMDR選択アルゴリズムをまとめることができます。ルータ自体が、その隣人のすべてより（RtrPri、MDRレベル、RID）の大きい値を持っている場合、それはMDRとしての地位を選択します。それ以外の場合は、Rmaxが（RtrPri、MDRレベル、RID）の最大値と隣人を示してみましょう。各隣接KはパラメータMDRConstraint、あるルータ自体、より（RtrPri、MDRレベル、RID）の大きい方の値を有する近隣を介し最もKホップににさRmaxから到達することができない限り、ルータは、次にMDRとしての地位を選択しますデフォルト値は3です。
This parameter serves to control the density of the MDR set, since the MDR set need not be strictly minimal.
MDRセットは、厳密に最小である必要はないので、このパラメータは、MDRのセットの密度を制御するのに役立ちます。
Similarly, a router that does not select itself as an MDR will select itself as a BMDR unless each neighbor can be reached from Rmax via two node-disjoint paths, using as intermediate hops only neighbors that have a larger value of (RtrPri, MDR Level, RID) than the router itself.
各ネイバーは、2つのノードディスジョイント経路を介してRmaxとから到達することができない限り、同様に、MDRとしてそれ自身を選択しないルータが中間ホップ（RtrPri、MDRレベルの大きい方の値を持っている唯一の近隣として使用して、BMDRとして自身を選択します、ルータ自体より）RID。
When a router selects itself as an MDR, it also decides which MDR neighbors it should become adjacent with, to ensure that the set of MDRs and the adjacencies between them form a connected backbone. Each non-MDR router selects and becomes adjacent with an MDR neighbor called its Parent, thus ensuring that all routers are connected to the MDR backbone.
ルータは、MDRとして自身を選択した場合、それはまた、各MDRの集合とそれらの間の隣接関係は、接続されたバックボーンを形成することを確実にするために、と隣接なるべきMDRネイバー決定します。各非MDRルータが選択され、MDRのネイバーと隣接なったため、すべてのルータがMDRバックボーンに接続されていることを確認して、その親と呼ばれます。
If the option of biconnected adjacencies is chosen (AdjConnectivity = 2), then additional adjacencies are selected to ensure that the set of MDRs and BMDRs, and the adjacencies between them, form a biconnected backbone. In this case, each MDR Other selects and becomes adjacent with an MDR/BMDR neighbor called its Backup Parent, in addition to its Parent.
2連結隣接のオプションが選択された場合（AdjConnectivity = 2）、次いで、追加の隣接関係は、先MDRとBMDRs、およびそれらの間の隣接関係のセットは、2連結主鎖を形成することを確実にするために選択されます。この場合には、MDR / BMDRのネイバーと隣接する各MDR他の選択となり、その親に加えて、そのバックアップ親と呼ばれます。
OSPF-MDR also provides the option of full-topology adjacencies (AdjConnectivity = 0). If this option is selected, then each router forms an adjacency with each bidirectional neighbor. Although BMDR selection is optional if AdjConnectivity is 0 or 1, it is recommended since BMDRs improve robustness by providing backup flooding.
OSPF-MDRは、また、（AdjConnectivity = 0）フルトポロジ隣接のオプションを提供します。このオプションが選択されている場合、各ルータは、それぞれ双方向のネイバーとの隣接関係を形成しています。 AdjConnectivityが0または1である場合BMDRの選択はオプションですがBMDRsがバックアップ洪水を提供することにより、堅牢性を向上させるために、それが推奨されます。
Prioritizing routers according to (RtrPri, MDR Level, RID) allows neighboring routers to agree on which routers should become an MDR, and gives higher priority to existing MDRs, which increases the lifetime of MDRs and the adjacencies between them. In addition, Parents are selected to be existing adjacent neighbors whenever possible, to avoid forming new adjacencies unless necessary. Once a neighbor becomes adjacent, it remains adjacent as long as the neighbor is bidirectional and either the neighbor or the router itself is an MDR or BMDR (similar to OSPF). The above rules reduce the rate at which new adjacencies are formed, which is important since database exchange must be performed whenever a new adjacency is formed.
（RtrPri、MDRレベル、RID）に応じてルータを優先して、隣接ルータがMDRなるべきルータに合意することができ、そして各MDRおよびそれらの間の隣接関係の寿命を増加させる、既存のMDRに高い優先順位を与えます。また、両親が必要な場合を除き、新たな隣接関係を形成することを避けるために、可能な限り隣接している隣人を既存の対象に選択されています。ネイバーが隣接になると、それは限り隣人が双方向であり、隣接またはルータ自体のいずれかがMDR又はBMDR（OSPFと同様）であるように、隣接残ります。上記の規則は、新しい隣接関係が形成されるたびにデータベース交換が行われなければならないので重要である新しい隣接関係が形成される速度を低下させます。
When an MDR receives a new link state advertisement (LSA) on a MANET interface, it floods the LSA back out the receiving interface unless it can be determined that such flooding is unnecessary (as specified in Section 8.1). The router MAY delay the flooding of the LSA by a small random amount of time (e.g., less than 100 ms). The delayed flooding is useful for coalescing multiple LSAs in the same Link State Update packet, and it can reduce the possibility of a collision in case multiple MDRs received the same LSA at the same time. However, such collisions are usually avoided with wireless MAC protocols.
MDRは、MANETインタフェースに新しいリンク状態アドバタイズメント（LSA）を受信すると（セクション8.1で指定されるように）そのようなフラッディングが不要であると判断することができない限り、それはバック受信インターフェースアウトLSAをフラッディング。ルータは、時間（例えば、100ミリ秒未満）の小さなランダム量だけLSAのフラッディングを遅延させることができます。遅れた洪水は、同じリンクステートアップデートパケットで複数のLSAを合体ために有用であり、それは、複数のMDRが同時に同じLSAを受信する場合には、衝突の可能性を低減することができます。しかし、このような衝突は、通常、無線MACプロトコルで回避されています。
When a Backup MDR receives a new LSA on a MANET interface, it waits a short interval (BackupWaitInterval), and then floods the LSA only if it has a neighbor that did not flood or acknowledge the LSA and is not known to be a neighbor of another neighbor (of the Backup MDR) that flooded the LSA.
バックアップMDRは、MANETインターフェイスに新しいLSAを受信すると、それは短い間隔（BackupWaitInterval）を待ち、それがLSAをあふれさせるか、認めなかった隣人を持っているとの隣人であることが知られていない場合にのみ、その後、LSAをフラッディングLSAをあふれ（バックアップMDRの）別の隣人。
MDR Other routers never flood LSAs back out the receiving interface. To exploit the broadcast nature of MANETs, a new LSA is processed (and possibly forwarded) if it is received from any neighbor in state 2-Way or greater. The flooding procedure also avoids redundant forwarding of LSAs when multiple interfaces exist.
MDR他のルータは、バック受信インタフェースアウトLSAをあふれさせることはありません。それは状態2ウェイ以上の任意のネイバーから受信された場合にアドホックネットワークにおけるブロードキャストの性質を利用するために、新しいLSAは、処理された（そしておそらく転送）されます。複数のインターフェースが存在する場合フラッディング手順は、LSAの冗長転送を回避します。
All Link State Acknowledgment packets are multicast. An LSA is acknowledged if it is a new LSA, or if it is a duplicate LSA received as a unicast. (A duplicate LSA received as multicast is not acknowledged.) An LSA that is flooded back out the same interface is treated as an implicit acknowledgment. Link State Acknowledgments may be delayed to allow coalescing multiple acknowledgments in the same packet. The only exception is that (Backup) MDRs send a multicast Link State Acknowledgment immediately when a duplicate LSA is received as a unicast, in order to prevent additional retransmissions. Only Link State Acknowledgments from adjacent neighbors are processed, and retransmitted LSAs are sent (via unicast) only to adjacent neighbors.
すべてのリンクステート確認応答パケットがマルチキャストされています。それは新しいLSAがある場合LSAが認められている、またはそれがある場合、重複するLSAは、ユニキャストとして受信しました。 （マルチキャストが確認されないように重複LSAを受信しました。）同じインターフェイスからバックフラッディングさLSAを暗黙の肯定応答として処理されます。リンクステート謝辞は同じパケット内の複数の承認を合体できるように遅れる場合があります。唯一の例外は、重複するLSAが追加の再送信を防止するために、ユニキャストとして受信したとき（バックアップ）のMDRは、すぐにマルチキャストリンクステート確認応答を送信することです。のみ隣接している隣人からリンクステート謝辞が処理され、再送信されたLSAは隣接している隣人に（ユニキャスト経由で）送信されます。
In OSPF, a neighbor must typically be fully adjacent (in state Full) for it to be used in the SPF calculation. An exception exists for an OSPF broadcast network, to avoid requiring all pairs of routers in such a network to form adjacencies, which would generate a large amount of overhead. In such a network, a router can use a non-adjacent neighbor as a next hop as long as both routers are fully adjacent with the Designated Router. We define this neighbor relationship as a "routable neighbor" and extend its usage to the MANET interface type.
それはSPF計算で使用するためのOSPFでは、ネイバーは、典型的には、（フル状態）に完全に隣接していなければなりません。例外は、オーバーヘッドを大量に生成する隣接関係を形成するために、そのようなネットワーク内のルータのすべてのペアを必要とする避けるために、OSPFブロードキャストネットワークのために存在します。そのようなネットワークでは、ルータがあれば、両方のルータが代表ルータと完全に隣接しているように、次のホップのような非隣接近隣を使用することができます。私たちは、「ルーティング可能な隣人」として、このネイバー関係を定義し、MANETインタフェースタイプにその使用法を拡張します。
A MANET neighbor becomes routable if it is bidirectional and the SPF calculation has produced a route to the neighbor. (A flexible quality condition may also be required.) Only routable and Full neighbors can be used as next hops in the SPF calculation, and can be included in the router-LSA originated by the router. The idea is that if the SPF calculation has produced a route to the neighbor, then it makes sense to take a "shortcut" and forward packets directly to the neighbor.
それは双方向で、SPF計算が隣人へのルートを作成した場合MANETネイバーがルーティング可能になります。 （柔軟な品質条件も必要とされ得る。）のみルーティング可能とフル隣人はSPF計算の次のホップとして使用することができ、ルータによって発信ルータLSAに含めることができます。アイデアは、SPF計算が隣人へのルートを作成した場合、それは「ショートカット」を取ると隣人に直接パケットを転送することは理にかなっていることです。
The routability condition is a generalization of the way that neighbors on broadcast networks are treated in the SPF calculation. The network-LSA of an OSPF broadcast network implies that a router can use a non-adjacent neighbor as a next hop. But a network-LSA cannot describe the general topology of a MANET, making it necessary to explicitly include non-adjacent neighbors in the router-LSA. Allowing only adjacent neighbors in LSAs would either result in suboptimal routes or require a large number of adjacencies.
ルータビリティ条件は、放送ネットワーク上の隣人は、SPF計算で処理されている方法を一般化したものです。 OSPFのブロードキャストネットワークのネットワークLSAは、ルータがネクストホップとして非隣接の隣人を使用することができることを意味します。しかし、ネットワークLSAは、それが必要な明示的ルータLSAで非隣接の隣人が含まれるようになって、MANETの一般的なトポロジーを記述することはできません。 LSAにのみ隣接近隣を可能にする準最適経路をもたらす、または隣接の多数を必要とするいずれか。
OSPF-MDR allows routers to originate both full-topology LSAs, which advertise links to all routable and Full neighbors, and partial-topology LSAs, which advertise only a subset of such links. In a dense network, partial-topology LSAs are typically much smaller than full-topology LSAs, thus achieving better scalability.
OSPF-MDRは、ルータがこのようなリンクのサブセットのみを広告のすべてのルーティング可能とフル隣人、そして部分的トポロジーのLSAへのリンクを宣伝フルトポロジのLSA、両方を発信することができます。密なネットワークでは、パーシャル・トポロジのLSAは、このように優れたスケーラビリティを実現し、一般的にフルトポロジのLSAよりもはるかに小さいです。
Each router advertises a subset of its neighbors as point-to-point links in its router-LSA. The choice of which neighbors to advertise is flexible. As a minimum requirement, each router must advertise a minimum set of "backbone" neighbors in its router-LSA. An LSA that includes only this minimum set of neighbors is called a minimal LSA and corresponds to LSAFullness = 0. This choice results in the minimum amount of LSA flooding overhead, but does not ensure routing along shortest paths. However, it is useful for achieving scalability to networks with a large number of nodes.
各ルータは、そのルータLSAでのポイントツーポイントリンクとして隣国のサブセットをアドバタイズします。隣人が宣伝するかの選択が柔軟です。最小要件として、各ルータは、そのルータLSAの「バックボーン」隣人の最小セットをアドバタイズする必要があります。近隣のみ、この最小セットを含むLSAは、最小LSAと呼ばれ、LSAフラッディングオーバーヘッドの最小量でLSAFullness = 0この選択結果に対応するが、最短経路に沿ってルーティング保証しないれます。しかし、多数のノードを有するネットワークにスケーラビリティを達成するのに有用です。
At the other extreme, if LSAFullness = 4, then the router originates a full-topology LSA, which includes all routable and Full neighbors.
他の極端では、LSAFullness = 4場合、ルータは、すべてのルーティング可能とFull隣人を含んでフルトポロジのLSAを、発信します。
Setting LSAFullness to 1 results in min-cost LSAs, which provide routing along shortest (minimum-cost) paths. Each router decides which neighbors to include in its router-LSA based on 2-hop neighbor information obtained from its neighbors' Hellos. Each router includes in its LSA the minimum set of neighbors necessary to provide a shortest path between each pair of its neighbors.
沿って最短（最小コスト）パスルーティング提供分コストのLSAに1つの結果にLSAFullnessを設定します。各ルータは、その隣人のハローズから入手した2ホップネイバー情報に基づいて、そのルータLSAに含める隣人を決定します。各ルータは、LSAにその隣接の各ペア間の最短経路を提供するのに必要なネイバーの最小セットを含みます。
Setting LSAFullness to 2 also provides shortest-path routing, but allows the router to advertise additional neighbors to provide redundant routes.
2 LSAFullnessを設定すると、最短パスルーティングを提供するが、ルータ冗長経路を提供するために、追加の隣人をアドバタイズすることを可能にします。
Setting LSAFullness to 3 results in MDR full LSAs, causing each MDR to originate a full-topology LSA while other routers originate minimal LSAs. This choice does not provide routing along shortest paths, but simulations have shown that it provides routing along nearly shortest paths with relatively low overhead.
他のルータが最小LSAを発信しながら、各MDRフルトポロジLSAを発信させ、MDR満杯のLSA 3つの結果にLSAFullnessを設定します。この選択は、最短経路に沿ってルーティング提供していないが、シミュレーションは、比較的低いオーバーヘッドでほぼ最短経路に沿ってルーティングを提供することを示しています。
The above LSA options are interoperable with each other, because they all require the router-LSA to include a minimum set of neighbors, and because the construction of the router-LSA (described in Section 9.4) ensures that the router-LSAs originated by different routers are consistent. Routing along shortest paths is provided if and only if every router selects LSAFullness to be 1, 2, or 4.
上記LSAオプションは、それらすべてがネイバーの最小セットを含むようにルータLSAを必要とするため、互いに相互運用可能であり、及び（9.4節を参照）ルータLSAの構成は、ルータのLSAが異なることにより生じたことを確実にするためルータは一致しています。最短経路に沿ってルーティングすることは、すべてのルータは、1,2、又は4であることがLSAFullnessを選択する場合にのみ設けられています。
OSPF-MDR uses the same Hello format as OSPFv3, but appends additional information to Hello packets using link-local signaling (LLS), in order to indicate the set of bidirectional neighbors and other information that is used by the MDR selection algorithm and the min-cost LSA algorithm. In addition to full Hellos, which include the same set of neighbor IDs as OSPFv3 Hellos, OSPF-MDR allows the use of differential Hellos, which include only the IDs of neighbors whose state (or other information) has recently changed (within the last HelloRepeatCount Hellos).
OSPF-MDRはOSPFv3のと同じハロー・フォーマットを使用するが、MDR選択アルゴリズムと分で使用され、双方向の隣人と他の情報のセットを示すために、リンクローカルシグナリング（LLS）を使用して、Helloパケットに付加情報を付加します-COST LSAアルゴリズム。 OSPFv3のハローズとしてネイバーIDの同じセットを含む完全ハローズ、に加えて、OSPF-MDRは、最後HelloRepeatCount内（状態（または他の情報）ネイバーのIDのみを含む差動ハローズの使用が最近変更された可能ハローズ）。
Hellos are sent every HelloInterval seconds. Full Hellos are sent every 2HopRefresh Hellos, and differential Hellos are sent at all other times. For example, if 2HopRefresh is equal to 3, then every third Hello is a full Hello. The default value of 2HopRefresh is 1; i.e., the default is to send only full Hellos. The default value for HelloInterval is 2 seconds. Differential Hellos are used to reduce overhead and to allow Hellos to be sent more frequently, for faster reaction to topology changes.
ハローズはあらゆるHelloIntervalが後援を送信されます。フル・ハローズは、すべての2HopRefresh helloを送信され、差動ハローズは、他のすべての回で送信されます。 2HopRefreshが3に等しい場合、例えば、その後、すべての第三のハローがいっぱいハローあります。 2HopRefreshのデフォルト値は1です。つまり、デフォルトでは唯一のフルhelloを送信することです。 HelloIntervalとのデフォルト値は2秒です。差動ハローズは、オーバーヘッド低減し、ハローズは、トポロジの変更へのより速い反応のために、より頻繁に送信することができるようにするために使用されています。
The following modified or new data items are required for the Interface Data Structure of a MANET interface:
以下の変更または新しいデータ項目は、MANETインタフェースのインタフェースデータ構造のために必要とされています。
Type A router that implements this extension can have one or more interfaces of type MANET, in addition to the OSPF interface types defined in [RFC2328].
[RFC2328]で定義されたOSPFインタフェースタイプに加えて、この拡張は、タイプMANETの1つまたは複数のインターフェースを有することができる実装するルータを入力します。
State The possible states for a MANET interface are the same as for a broadcast interface. However, the DR and Backup states now imply that the router is an MDR or Backup MDR, respectively.
MANETインタフェースのための可能な状態を状態がブロードキャストインターフェイスの場合と同じです。しかし、DRおよびバックアップの状態は今ルータは、それぞれ、MDRまたはバックアップMDRであることを示唆しています。
MDR Level The MDR Level is equal to MDR (value 2) if the router is an MDR, Backup MDR (value 1) if the router is a Backup MDR, and MDR Other (value 0) otherwise. The MDR Level is used by the MDR selection algorithm.
ルータが他のルータはバックアップMDRある場合MDR、バックアップMDR（値1）であり、そしてMDR他（値0）場合MDRレベルザMDRレベルはMDR（値2）に等しいです。 MDRレベルはMDR選択アルゴリズムによって使用されます。
Parent The Parent replaces the Designated Router (DR) data item of OSPF. Each router selects a Parent as described in Section 5.4. The Parent of an MDR is the router itself, and the Parent of a non-MDR router will be a neighboring MDR, if one exists. The Parent is initialized to 0.0.0.0, indicating the lack of a Parent. Each router advertises the Router ID of its Parent in the DR field of each Hello sent on the interface.
親親は、OSPFの代表ルータ（DR）データ項目を置き換えます。 5.4節で説明したように各ルータは、親が選択されます。 MDRの親が存在する場合、隣接MDRなりルータ自体、非MDRルータの親です。親は親の欠如を示し、0.0.0.0に初期化されます。各ルータは、それぞれのHelloのDRフィールドに親のルータIDがインターフェイスで送信されるアドバタイズします。
Backup Parent The Backup Parent replaces the Backup Designated Router data item of OSPF. The Backup Parent of a BMDR is the router itself. If the option of biconnected adjacencies is chosen, then each MDR Other selects a Backup Parent, which will be a neighboring MDR/BMDR if one exists that is not the Parent. The Backup Parent is initialized to 0.0.0.0, indicating the lack of a Backup Parent. Each router advertises the Router ID of its Backup Parent in the Backup DR field of each Hello sent on the interface.
予備親は予備親は、OSPFのバックアップ指定ルータのデータ項目を置き換えます。 BMDRのバックアップ親はルータ自体です。 2連結隣接のオプションを選択する場合、各MDR他の一つは、その親でない存在する場合、隣接MDR / BMDRされるバックアップ親を選択します。予備親は予備親の欠如を示し、0.0.0.0に初期化されます。各ルータは、それぞれのHelloのバックアップDRフィールドにその予備親のルータIDがインターフェイスで送信されるアドバタイズします。
Router Priority An 8-bit unsigned integer. A router with a larger Router Priority is more likely to be selected as an MDR. The Router Priority for a MANET interface can be changed dynamically based on any criteria, including bandwidth capacity, willingness to be a relay (which can depend on battery life, for example), number of neighbors (degree), and neighbor stability. A router that has been a (Backup) MDR for a certain amount of time can reduce its Router Priority so that the burden of being a (Backup) MDR can be shared among all routers. If the Router Priority for a MANET interface is changed, then the interface variable MDRNeighborChange must be set.
ルータの優先順位アン8ビットの符号なし整数。大きなルータの優先順位を持つルータは、MDRとして選択されやすいです。 MANETインターフェイスのルータプライオリティは、帯域幅容量、（例えば電池寿命に依存することができる）リレーである意欲、近隣の数（度）、及び隣接安定性を含む任意の基準に基づいて動的に変更することができます。一定時間（バックアップ）MDRされているルータは、（バックアップ）であることの重荷ように、そのルータの優先順位を下げることができMDRは、すべてのルータ間で共有することができます。 MANETインタフェース用のルータプライオリティが変更された場合、インタフェース変数MDRNeighborChangeを設定する必要があります。
Hello Sequence Number (HSN) The 16-bit sequence number carried by the MDR-Hello TLV. The HSN is incremented by 1 (modulo 2^16) every time a Hello packet is sent on the interface.
ハローシーケンス番号（HSN）MDR-ハローTLVによって運ばれる16ビットのシーケンス番号。 HSNは1（法2 ^ 16）Helloパケットがインターフェイスで送信されるたびにインクリメントされます。
MDRNeighborChange A single-bit variable set to 1 if a neighbor change has occurred that requires the MDR selection algorithm to be executed.
実行されるMDR選択アルゴリズムを必要と隣接変化が発生した場合に1にシングルビットの変数セットをMDRNeighborChange。
The following new configurable interface parameters are required for a MANET interface. The default values for HelloInterval, RouterDeadInterval, and RxmtInterval for a MANET interface are 2, 6, and 7 seconds, respectively.
次の新しい設定可能なインターフェイスパラメータは、MANETインターフェースのために必要とされます。 MANETインターフェイスのHelloIntervalの、RouterDeadInterval、及びRxmtIntervalのデフォルト値は、それぞれ、2、6、7秒です。
The default configuration for OSPF-MDR uses uniconnected adjacencies (AdjConnectivity = 1) and partial-topology LSAs that provide shortest-path routing (LSAFullness = 1). This is the most scalable configuration that provides shortest-path routing. Other configurations may be preferable in special circumstances. For example, setting LSAFullness to 4 provides full-topology LSAs, and setting LSAFullness to 0 provides minimal LSAs that minimize overhead but do not ensure shortest-path routing. Setting AdjConnectivity to 2 may improve robustness by providing a biconnected adjacency subgraph, and setting AdjConnectivity to 0 results in full-topology adjacencies.
OSPF-MDRのデフォルト設定はuniconnected隣接（AdjConnectivity = 1）及び（LSAFullness = 1）をルーティングする最短経路を提供する部分トポロジーLSAを使用します。これは、最短パスルーティングを提供し、最もスケーラブルな構成です。その他の構成は、特殊な状況で好ましいかもしれません。例えば、4にLSAFullnessを設定するフルトポロジLSAを提供し、0にLSAFullnessを設定するオーバーヘッド最小限なく最短パスルーティングを保証しない最小のLSAを提供します。 2 AdjConnectivityを設定すると、2連結隣接サブグラフを提供し、フルトポロジ隣接0結果にAdjConnectivityを設定することによって、堅牢性を改善することができます。
All possible configurations of the new interface parameters are functional, except that if AdjConnectivity is 0 (full-topology adjacencies), then LSAFullness must be 1, 2, or 4 (see Section 9.3).
新しいインタフェースパラメータのすべての可能な構成はAdjConnectivityは0（完全トポロジー隣接）である場合、LSAFullness（セクション9.3を参照）1、2、または4でなければならないことを除いて、機能的です。
Differential Hellos should be used to reduce the size of Hello packets when the average number of neighbors is large (e.g., greater than 50). Differential Hellos are obtained by setting the parameter 2HopRefresh to an integer greater than 1, with the recommended value being 3. Good performance in simulated mobile networks with up to 160 nodes has been obtained using the default configuration with differential Hellos. Good performance in simulated mobile networks with up to 200 nodes has been obtained using the same configuration except with minimal LSAs (LSAFullness = 0). Simulation results are presented in Appendix E.
ネイバーの平均数が大きい（例えば、50より大きい）の場合、差動ハローズは、Helloパケットのサイズを減少させるために使用されるべきです。最大160のノードとシミュレートされたモバイルネットワークにおける3良好な性能である推奨値は、差動ハローズでデフォルト設定を使用して得られたものとの差分ハローズは、1より大きい整数にパラメータ2HopRefreshを設定することによって得られます。最大200ノードとシミュレートされたモバイルネットワークにおける良好な性能は、最小のLSA（= 0 LSAFullness）を除いて同じ構成を使用して得られました。シミュレーション結果は、付録E.に提示されています
Although all routers should preferably choose the same values for the new configurable interface parameters, this is not required. OSPF-MDR was carefully designed so that correct interoperation is achieved even if each router sets these parameters independently of the other routers.
すべてのルータは、好ましくは、新しい設定可能なインターフェイスパラメータに同じ値を選択する必要がありますが、これは必須ではありません。正しい相互運用は各ルータが独立して他のルータのこれらのパラメータを設定しても達成されるように、OSPF-MDRは、慎重に設計されました。
AdjConnectivity If equal to the default value of 1, then the set of adjacencies forms a (uni)connected graph. If equal to the optional value of 2, then the set of adjacencies forms a biconnected graph. If AdjConnectivity is 0, then adjacency reduction is not used; i.e., the router becomes adjacent with all of its neighbors.
AdjConnectivityは、1のデフォルト値に等しい場合には、隣接のセットは、（UNI）接続グラフを形成します。 2の任意の値に等しい場合には、隣接のセットは、2重連結グラフを形成します。 AdjConnectivityが0である場合には、隣接の減少は使用されません。すなわち、ルータはその隣人のすべてと隣接なります。
MDRConstraint A parameter of the MDR selection algorithm, which affects the number of MDRs selected and must be an integer greater than or equal to 2. The default value of 3 results in nearly the minimum number of MDRs. Values larger than 3 result in slightly fewer MDRs, and the value 2 results in a larger number of MDRs.
選択のMDRの数に影響を及ぼし、以上のMDRのほぼ最小数の3つの結果の2デフォルト値に等しい整数でなければならないMDR選択アルゴリズムのパラメータをMDRConstraint。わずかに少ないのMDR 3の結果より大きな値、および値のMDR多数の2つの結果。
BackupWaitInterval The number of seconds that a Backup MDR must wait after receiving a new LSA before it decides whether to flood the LSA. The default value is 0.5 second.
BackupWaitIntervalバックアップMDRは、それがLSAをフラッディングするかどうかを決定する前に新しいLSAを受信した後、待機しなければならない秒数。デフォルト値は0.5秒です。
AckInterval The interval between Link State Acknowledgment packets when only delayed acknowledgments need to be sent. AckInterval MUST be less than RxmtInterval, and SHOULD NOT be larger than 1 second. The default value is 1 second.
リンクステート確認応答パケットの間隔AckIntervalだけ遅れて確認応答を送信する必要がある場合。 AckIntervalはRxmtInterval未満でなければならない、と1秒より大きくするべきではありません。デフォルト値は1秒です。
LSAFullness Determines which neighbors a router should advertise in its router-LSA. The value 0 results in minimal LSAs that include only "backbone" neighbors. The values 1 and 2 result in partial-topology LSAs that provide shortest-path routing, with the value 2 providing redundant routes. The value 3 results in MDRs originating full-topology LSAs and other routers originating minimal LSAs. The value 4 results in all routers originating full-topology LSAs. The default value is 1.
LSAFullnessは、ルータがそのルータLSAで広告を出すべき隣人を決定します。値のみ「バックボーン」隣人を含め、最小限のLSAで0の結果。値2は、冗長経路を提供すると、最短パスルーティングを提供する部分トポロジーのLSAの値1および2の結果。値が最小のLSAを発信フルトポロジのLSAと他のルータの発信先MDR 3つの結果。値フルトポロジのLSAを発信するすべてのルータで4つの結果。デフォルト値は1です。
2HopRefresh One out of every 2HopRefresh Hellos sent on the interface must be a full Hello. All other Hellos are differential. The default value is 1; i.e., the default is to send only full Hellos. If differential Hellos are used, the recommended value of 2HopRefresh is 3.
すべての2HopRefreshハローズのうち2HopRefresh一つはフルこんにちはでなければならないインターフェイスで送信されます。他のすべてのハローズは差動です。デフォルト値は1です。つまり、デフォルトでは唯一のフルhelloを送信することです。差動ハローズが使用されている場合は、2HopRefreshの推奨値は3です。
HelloRepeatCount The number of consecutive Hellos in which a neighbor must be included when its state changes, if differential Hellos are used. This parameter must be set to 3.
その状態が変化する差動ハローズが使用される場合、隣接は、含まれる必要がある連続ハローズの数をHelloRepeatCount。このパラメータは3に設定する必要があります。
The neighbor states are the same as for OSPF. However, the data for a MANET neighbor that has transitioned to the Down state must be maintained for at least HelloInterval * HelloRepeatCount seconds, to allow the state change to be reported in differential Hellos. The following new data items are required for the Neighbor Data Structure of a neighbor on a MANET interface.
隣人の状態はOSPFの場合と同じです。しかし、ダウン状態に移行したMANETの隣人のためのデータは、状態変化が差動ハローズで報告できるようにするために、少なくともHelloIntervalの* HelloRepeatCount秒間維持しなければなりません。次の新しいデータ項目は、MANETインタフェース上のネイバーのネイバーデータ構造のために必要とされます。
Neighbor Hello Sequence Number (NHSN) The Hello sequence number contained in the last Hello received from the neighbor.
近隣こんにちはシーケンス番号（NHSN）最後のHelloに含まれるHelloシーケンス番号は、ネイバーから受信しました。
A-bit The A-bit copied from the MDR-Hello TLV of the last Hello received from the neighbor. This bit is 1 if the neighbor is using full-topology adjacencies, i.e., is not using adjacency reduction.
最後のHelloのMDR-こんにちはTLVからコピーされたビットのAビットがネイバーから受信しました。隣人、すなわち、隣接還元を使用していない、完全なトポロジー隣接を使用している場合、このビットは1です。
FullHelloRcvd A single-bit variable equal to 1 if a full Hello has been received from the neighbor.
完全こんにちは隣人から受信された場合に1に等しい単一ビット変数FullHelloRcvd。
Neighbor's MDR Level The MDR Level of the neighbor, based on the DR and Backup DR fields of the last Hello packet received from the neighbor or from the MDR-DD TLV in a Database Description (DD) packet received from the neighbor.
最後のhelloパケットのDRおよびバックアップDRフィールドに基づいて隣人の隣人のMDRレベルザ・MDRレベルでは、パケットがネイバーから受信（DD）データベース記述に隣人からか、MDR-DD TLVから受け取りました。
Neighbor's Parent The neighbor's choice for Parent, obtained from the DR field of the last Hello packet received from the neighbor or from the MDR-DD TLV in a DD packet received from the neighbor.
最後のHelloパケットのDRフィールドから取得した隣人の親の親のための隣人の選択は、ネイバーから受信DDパケット内のネイバーからか、MDR-DD TLVから受け取りました。
Neighbor's Backup Parent The neighbor's choice for Backup Parent, obtained from the Backup DR field of the last Hello packet received from the neighbor or from the MDR-DD TLV in a DD packet received from the neighbor.
最後のHelloパケットのバックアップDRフィールドから取得したバックアップ親のための隣人のバックアップ親隣人の選択は、ネイバーから受信DDパケットに隣人からか、MDR-DD TLVから受け取りました。
Child A single-bit variable equal to 1 if the neighbor is a child, i.e., if the neighbor has selected the router as a (Backup) Parent.
子ネイバーが（バックアップ）親としてのルータを選択した場合、隣接は、即ち、子供であれば1に等しい単一ビット変数。
Dependent Neighbor A single-bit variable equal to 1 if the neighbor is a Dependent Neighbor, which is decided by the MDR selection algorithm. Each MDR/BMDR router becomes adjacent with its Dependent Neighbors (which are also MDR/BMDR routers) to form a connected backbone. The set of all Dependent Neighbors on a MANET interface is called the Dependent Neighbor Set (DNS) for the interface.
従属ネイバーネイバーがMDR選択アルゴリズムによって決定され依存近隣であれば1に等しい単一ビット変数。各MDR / BMDRルータは、接続されたバックボーンを形成するために（もMDR / BMDRルータである）、その依存ネイバーと隣接なります。 MANETインターフェイス上のすべての依存隣人のセットは、インタフェースのための依存隣接セット（DNS）と呼ばれます。
Dependent Selector A single-bit variable equal to 1 if the neighbor has selected the router to be dependent.
依存セレクタ1に等しい単一ビット変数ネイバーが依存するようにルータを選択した場合。
Selected Advertised Neighbor (SAN) A single-bit variable equal to 1 if the neighbor is a Selected Advertised Neighbor. Selected Advertised Neighbors are neighbors that the router has selected to be included in the router-LSA, along with other neighbors that are required to be included. The set of all Selected Advertised Neighbors on a MANET interface is called the Selected Advertised Neighbor Set (SANS) for the interface.
ネイバーが選択されたアドバタイズ近隣であれば1に等しいアドバタイズネイバー（SAN）は、単一ビットの変数を選択しました。選択されたアドバタイズ隣人は、ルータが含まれるように要求されている他の隣人と一緒に、ルータLSAに含まれるように選択したことを隣接しています。 MANETインターフェイス上のすべての選択されたアドバタイズ隣人のセットは、インタフェースのために選択されたアドバタイズ隣接セット（SANS）と呼ばれています。
Routable A single-bit variable equal to 1 if the neighbor is routable.
ルーティング可能な1に等しい単一ビット変数ネイバーがルーティング可能である場合。
Neighbor's Bidirectional Neighbor Set (BNS) The neighbor's set of bidirectional neighbors, which is updated when a Hello is received from the neighbor.
近隣の双方向の隣接セット（BNS）のHelloがネイバーから受信したときに更新され、双方向の隣人の隣人のセット。
Neighbor's Dependent Neighbor Set (DNS) The neighbor's set of Dependent Neighbors, which is updated when a Hello is received from the neighbor.
近隣の依存隣接セット（DNS）のHelloがネイバーから受信したときに更新される依存隣人の隣人のセット。
Neighbor's Selected Advertised Neighbor Set (SANS) The neighbor's set of Selected Advertised Neighbors, which is updated when a Hello is received from the neighbor.
隣人の選択アドバタイズ隣接セット（SANS）こんにちはがネイバーから受信されたときに更新されて選択されたアドバタイズ隣人の隣人のセット。
Neighbor's Link Metrics The link metric for each of the neighbor's bidirectional neighbors, obtained from the Metric TLV appended to Hello packets.
メトリックTLVから得た隣人の双方向の隣人のそれぞれについて、隣人のリンクメトリックリンクメトリックは、Helloパケットに追加しました。
The MANET interface utilizes Hellos for neighbor discovery and for enabling neighbors to learn 2-hop neighbor information. The protocol is flexible because it allows the use of full or differential Hellos. Full Hellos list all neighbors on the interface that are in state Init or greater, as in OSPFv3, whereas differential Hellos list only neighbors whose status as a bidirectional neighbor, Dependent Neighbor, or Selected Advertised Neighbor has recently changed. Differential Hellos are used to reduce overhead, and they allow Hellos to be sent more frequently (for faster reaction to topology changes). If differential Hellos are used, full Hellos are sent less frequently to ensure that all neighbors have current 2-hop neighbor information.
MANETインタフェースは、近隣探索のためにと2ホップネイバー情報を学ぶために隣人を可能とするためのhelloを利用しています。それは完全または差分ハローズの使用を可能にするためのプロトコルは柔軟です。全ハローズリスト、ステータスが双方向の隣人、従属ネイバー、または選択したアドバタイズ隣人として最近変更された差動ハローズリストのみ隣人に対し、OSPFv3ののように、状態の初期化以上にあるインターフェイス上のすべての隣人。差動ハローズは、オーバーヘッドを減らすために使用されている、と彼らはハローズは、（変更をトポロジに速い反応のために）より頻繁に送信することを可能にします。差動ハローズが使用されている場合は、完全なハローズは、すべてのネイバーは、現在の2ホップネイバー情報を持っていることを保証するために、それほど頻繁に送信されます。
Hello packets are sent according to [RFC5340], Section 4.2.1.1, and [RFC2328], Section 9.5, with the following MANET-specific specifications beginning after paragraph 3 of Section 9.5. The Hello packet format is defined in [RFC5340], Section A.3.2, except for the ordering of the Neighbor IDs and the meaning of the DR and Backup DR fields as described below.
こんにちは、パケットは、9.5節の第3項の後に開始して、次のMANET特有の仕様に、[RFC5340]、セクション4.2.1.1、および[RFC2328]、セクション9.5に応じて送信されます。 HelloパケットフォーマットはセクションA.3.2は近隣IDおよびDRおよびバックアップDRフィールドの意味を以下に説明するように順序を除いて、[RFC5340]で定義されています。
Similar to [RFC2328], the DR and Backup DR fields indicate whether the router is an MDR or Backup MDR. If the router is an MDR, then the DR field is the router's own Router ID, and if the router is a Backup MDR, then the Backup DR field is the router's own Router ID. These fields are also used to advertise the router's Parent and Backup Parent, as specified in Section A.3 and Section 5.4.
[RFC2328]と同様、DRおよびバックアップDRフィールドは、ルータがMDRまたはバックアップMDRであるかどうかを示します。ルータがMDRの場合、DRフィールドには、ルータ自身のルータIDで、ルータはバックアップMDRの場合、[バックアップDRフィールドには、ルータ自身のルータIDです。 A.3節と5.4節に指定されているこれらのフィールドはまた、ルータの親とバックアップ親を宣伝するために使用されています。
Hellos are sent every HelloInterval seconds. Full Hellos are sent every 2HopRefresh Hellos, and differential Hellos are sent at all other times. For example, if 2HopRefresh is equal to 3, then every third Hello is a full Hello. If 2HopRefresh is set to 1, then all Hellos are full (the default).
ハローズはあらゆるHelloIntervalが後援を送信されます。フル・ハローズは、すべての2HopRefresh helloを送信され、差動ハローズは、他のすべての回で送信されます。 2HopRefreshが3に等しい場合、例えば、その後、すべての第三のハローがいっぱいハローあります。 2HopRefreshが1に設定されている場合は、すべてのハローズは（デフォルト）に満ちています。
The neighbor IDs included in the body of each Hello are divided into the following five disjoint lists of neighbors (some of which may be empty), and must appear in the following order:
IDは各こんにちはの本文に含ま隣人が隣人（そのうちのいくつかは空でもよい）の以下の5つの互いに素のリストに分割され、次の順序で表示されている必要があります。
List 1. Neighbors whose state recently changed to Down (included only in differential Hellos).
その状態が最近ダウン（差分のみハローズに含まれる）に変更リスト1.隣人。
List 2. Neighbors in state Init.
リスト状態の初期化2.隣人。
List 3. Dependent Neighbors.
リスト3.依存隣人。
List 4. Selected Advertised Neighbors.
リスト4.選択したアドバタイズ隣人。
List 5. Unselected bidirectional neighbors, defined as bidirectional neighbors that are neither Dependent nor Selected Advertised Neighbors.
どちらも依存も選択されたアドバタイズ隣接している双方向の隣人として定義リスト5.選択されていない双方向の隣人、。
Note that all neighbors in Lists 3 through 5 are bidirectional neighbors. These lists are used to update the neighbor's Bidirectional Neighbor Set (BNS), Dependent Neighbor Set (DNS), and Selected Advertised Neighbor Set (SANS) when a Hello is received.
〜5リスト3のすべてのネイバーが双方向の隣人であることに注意してください。これらのリストには、隣人の双方向隣接セット（BNS）、従属隣接セット（DNS）を更新するために使用され、選択されたアドバタイズ近隣のHelloを受信したセット（SANS）。
Note that the above five lists are disjoint, so each neighbor can appear in at most one list. Also note that some or all of the five lists can be empty.
上記の5つのリストは互いに素であるので、各隣人は最大1つのリストに表示されることに注意してください。また、5つのリストの一部または全部が空であることに注意してください。
Link-local signaling (LLS) is used to append up to two TLVs to each MANET Hello packet. The format for LLS is given in Section A.2. The MDR-Hello TLV is appended to each (full or differential) MANET Hello packet. It indicates whether the Hello is full or differential, and gives the Hello Sequence Number (HSN) and the number of neighbor IDs in each of Lists 1 through 4 defined above. The size of List 5 is then implied by the packet length field of the Hello. The format of the MDR-Hello TLV is given in Section A.2.3.
リンクローカルシグナリング（LLS）は、各MANET Helloパケットには、2つのTLVまで付加するために使用されます。 LLSのフォーマットは、セクションA.2に与えられています。 MDR-ハローTLVはそれぞれ（完全または差分）MANET Helloパケットに付加されています。これはハローが完全または差分であるかを示し、そしてハローシーケンス番号（HSN）および上記で定義された1〜4の各リストにおける隣接IDの数を与えます。リスト5の大きさは、その後のHelloのパケット長フィールドによって暗示されます。 MDR-こんにちはTLVのフォーマットは、セクションA.2.3に与えられています。
In both full and differential Hellos, the appended MDR-Hello TLV is built as follows.
次のようにフルと差分の両方ハローズには、特許MDR-こんにちはTLVが構築されています。
o The Sequence Number field is set to the current HSN for the interface; the HSN is then incremented (modulo 2^16).
Oシーケンス番号フィールドは、インタフェースの現在HSNに設定されています。 HSNは、その後、（モジュロ2 ^ 16）をインクリメントします。
o The D-bit of the MDR-Hello TLV is set to 1 for a differential Hello and 0 for a full Hello.
O MDR-ハローTLVのDビットは、完全ハローする差動ハローを0 1に設定されています。
o The A-bit of the MDR-Hello TLV is set to 1 if AdjConnectivity is 0 (the router is using full-topology adjacencies); otherwise, it is set to 0.
O MDR-ハローTLVのAビットは、（ルータがフルトポロジー隣接を使用している）AdjConnectivityが0である場合は1に設定されています。それ以外の場合は0に設定されています。
o The N1, N2, N3, and N4 fields are set to the number of neighbor IDs in the body of the Hello that are in List 1, List 2, List 3, and List 4, respectively. (N1 is always zero in a full Hello.)
OをN1、N2、N3、及びN4のフィールドはそれぞれ、リスト1、リスト2、リスト3、リスト4にあるハローの本体に隣接IDの数に設定されています。 （N1は常にフルこんにちはではゼロです。）
The MDR-Metric TLV (or Metric TLV) advertises the link cost to each bidirectional neighbor on the interface, to allow the selection of neighbors to include in partial-topology LSAs. If LSAFullness is 1 or 2, a Metric TLV must be appended to each MANET Hello packet unless all link costs are 1. The format of the Metric TLV is given in Section A.2.5. The I bit of the Metric TLV can be set to 0 or 1. If the I bit is set to 0, then the Metric TLV does not contain neighbor IDs, and contains the metric for each bidirectional neighbor listed in the (full or differential) Hello, in the same order. If the I bit is set to 1, then the Metric TLV includes the neighbor ID and metric for each bidirectional neighbor listed in the Hello whose metric is not equal to the Default Metric field of the TLV.
MDR-メトリックTLV（またはメトリックTLV）は部分トポロジーのLSAに含まれるように近隣の選択を可能にするために、インターフェイスの各双方向ネイバーへのリンクコストをアドバタイズ。 LSAFullnessは1または2である場合、すべてのリンクのコストは1メートルTLVのフォーマットは、セクションA.2.5で与えられているのでない限り、メトリックTLVは各MANET Helloパケットに追加する必要があります。 Iビットが次にメトリックTLVが隣接IDを含まず、0に設定され、（完全または差分）にリストされた各双方向ネイバーのメトリックが含まれている場合メトリックTLVのIビットが0または1に設定することができこんにちは、同じためです。 Iビットが1に設定されている場合、メトリックTLVは、ネイバーIDと、そのメトリックTLVのデフォルトのメトリックフィールドに等しくないハローにリストされた各双方向ネイバーのメトリックを含みます。
The I bit should be chosen to minimize the size of the Metric TLV. This can be achieved by choosing the I bit to be 1 if and only if the number of bidirectional neighbors listed in the Hello whose metric differs from the Default Metric field is less than 1/3 of the total number of bidirectional neighbors listed in the Hello.
IビットはメトリックTLVのサイズを最小化するように選択すべきです。これが1になるようにIビットを選択することによって達成することができるならば、そのメトリックは異なり、デフォルトのメトリックフィールドからこんにちはに記載されている双方向の隣人の数はハローに記載されている双方向の隣人の総数の1/3以下である場合にのみ、 。
For example, if all neighbors have the same metric, then the I bit should be set to 1, with the Default Metric equal to this metric, avoiding the need to include neighbor IDs and corresponding metrics in the TLV. At the other extreme, if all neighbors have different metrics, then the I bit should be set to 0 to avoid listing the same neighbor IDs in both the body of the Hello and the Metric TLV.
すべてのネイバーは、同じメトリックを持っている場合たとえば、その後、IビットがTLVで隣人IDと対応する指標を含める必要性を回避、このメトリックに等しいデフォルトのメトリックで、1に設定する必要があります。すべてのネイバーは異なるメトリックを持っている場合は、他の極端では、その後、Iビットがこんにちは、メトリックTLVの本体の両方に同じネイバーIDをリストアップ避けるために、0に設定する必要があります。
In both full and differential Hello packets, the L bit is set in the Hello's option field to indicate LLS.
こんにちはフルと差分の両方のパケットでは、LビットはLLS示すためにこんにちはのオプションフィールドに設定されています。
In a full Hello, the neighbor ID list includes all neighbors on the interface that are in state Init or greater, in the order described above. The MDR-Hello TLV is built as described above. If a Metric TLV is appended, it is built as specified in Section A.2.5.
こんにちはフルでは、ネイバーIDのリストは、上記の順番で、状態の初期化以上にあるインターフェイス上のすべてのネイバーが含まれています。 MDR-こんにちはTLVは、上記のように構築されています。メトリックTLVが追加されている場合は、セクションA.2.5で指定され、それが構築されています。
In a differential Hello, the five neighbor ID lists defined in Section 4.1 are populated as follows:
次のように差動でこんにちは、セクション4.1で定義されている5つの隣接IDリストが読み込まれます。
List 1 includes each neighbor in state Down that has not yet been included in HelloRepeatCount Hellos since transitioning to this state.
リスト1は、まだこの状態に遷移するのでHelloRepeatCountハローズには含まれていない状態下での各隣人が含まれています。
List 2 includes each neighbor in state Init that has not yet been included in HelloRepeatCount Hellos since transitioning to this state.
リスト2は、まだこの状態に遷移するのでHelloRepeatCountハローズには含まれていない状態の初期の各隣人が含まれています。
List 3 includes each Dependent Neighbor that has not yet been included in HelloRepeatCount Hellos since becoming a Dependent Neighbor.
リスト3は、まだ従属ネイバーになってきているのでHelloRepeatCountハローズには含まれていない各従属ネイバーが含まれています。
List 4 includes each Selected Advertised Neighbor that has not yet been included in HelloRepeatCount Hellos since becoming a Selected Advertised Neighbor.
リスト4は、まだ選択されたアドバタイズ隣人になってきているのでHelloRepeatCountハローズには含まれていないそれぞれの選択アドバタイズ隣人が含まれています。
List 5 includes each unselected bidirectional neighbor (defined in Section 4.1) that has not yet been included in HelloRepeatCount Hellos since becoming an unselected bidirectional neighbor.
リスト5は、まだ選択されていない双方向隣接なっているのでHelloRepeatCountハローズに含まれていない（セクション4.1で定義された）各選択されていない双方向ネイバーを含みます。
In addition, a bidirectional neighbor must be included (in the appropriate list) if the neighbor's BNS does not include the router (indicating that the neighbor does not consider the router to be bidirectional).
隣人のBNSは（隣人は、ルータが双方向であることを考慮していないことを示す）は、ルータが含まれていない場合は加えて、双方向の隣人は、（適切なリストに）含まれている必要があります。
If a Metric TLV is appended to the Hello, then a bidirectional neighbor must be included (in the appropriate list) if it has not yet been included in HelloRepeatCount Hellos since its metric last changed.
メトリックTLVをこんにちはに追加されている場合は、そのメトリックが最後に変更したので、それはまだHelloRepeatCountハローズには含まれていない場合は、双方向の隣人は、（適切なリストに）含まれている必要があります。
A Hello packet received on a MANET interface is processed as described in [RFC5340], Section 4.2.2.1, and the first two paragraphs of [RFC2328], Section 10.5, followed by the processing specified below.
以下に特定の処理に続いて、[RFC5340]、セクション4.2.2.1、および[RFC2328]の最初の二つのパラグラフ、セクション10.5に記載のMANETインタフェース上で受信したハローパケットが処理されます。
The source of a received Hello packet is identified by the Router ID found in the Hello's OSPF packet header. If a matching neighbor cannot be found in the interface's data structure, one is created with the Neighbor ID set to the Router ID found in the OSPF packet header, the state initialized to Down, all MANET-specific neighbor variables (specified in Section 3.3) initialized to zero, and the neighbor's DNS, SANS, and BNS initialized to empty sets.
受信したHelloパケットのソースは、ハローのOSPFパケットのヘッダに見られるルータIDによって識別されます。マッチング隣人がインタフェースのデータ構造内に見つからない場合、一方はOSPFパケットヘッダに見られるルータIDに近隣IDのセットを使用して作成され、状態がダウンに初期化（セクション3.3で指定された）全てのMANET固有隣接変数ゼロに初期化し、隣人のDNSは、SANS、およびBNSはセットを空に初期化。
The neighbor structure's Router Priority is set to the value of the corresponding field in the received Hello packet. The Neighbor's Parent is set to the value of the DR field, and the Neighbor's Backup Parent is set to the value of the Backup DR field.
隣人構造のルータの優先順位は、受信されたHelloパケット内の対応するフィールドの値に設定されています。隣人の親は、DRフィールドの値に設定され、近隣の予備親は、Backup DRフィールドの値に設定されています。
Now the rest of the Hello Packet is examined, generating events to be given to the neighbor and interface state machines. These state machines are specified to be either executed or scheduled (see [RFC2328], Section 4.4, "Tasking support"). For example, by specifying below that the neighbor state machine be executed in line, several neighbor state transitions may be affected by a single received Hello.
今のHelloパケットの残りの部分は、隣人とのインターフェイスのステートマシンに与えられるイベントを生成し、検討しています。これらの状態マシンは、いずれかの実行またはスケジュールするように指定されている（「支援をTASKING」、セクション4.4、[RFC2328]を参照）。例えば、ネイバーステートマシンはラインで実行することが下方に指定することによって、いくつかの隣接状態遷移はハローを受信し、単一の影響を受けることができます。
o If the L bit in the options field is not set, then an error has occurred and the Hello is discarded.
オプションフィールド内のLビットが設定されていない場合は、O、エラーが発生したとこんにちはは破棄されます。
o If the LLS contains an MDR-Hello TLV, the neighbor state machine is executed with the event HelloReceived. Otherwise, an error has occurred and the Hello is discarded.
LLSは、MDR-こんにちはTLVが含まれている場合は、O、隣人州のマシンはイベントHelloReceivedで実行されます。そうしないと、エラーが発生しているとこんにちはは破棄されます。
o The Hello Sequence Number and the A-bit in the MDR-Hello TLV are copied to the neighbor's data structure.
Oこんにちはシーケンス番号とMDR-こんにちはTLVにおけるA-ビットは、隣人のデータ構造にコピーされます。
o The DR and Backup DR fields are processed as follows.
次のようにO DRおよびバックアップDRフィールドが処理されます。
(1) If the DR field is equal to the neighbor's Router ID, set the neighbor's MDR Level to MDR.
DRフィールドが隣人のルータIDに等しい場合（1）、MDRに隣人のMDRレベルを設定します。
(2) Else if the Backup DR field is equal to the neighbor's Router ID, set the neighbor's MDR Level to Backup MDR.
（2）バックアップDRフィールドは隣人のルータIDと等しい場合はそうでなければ、バックアップMDRに隣人のMDRレベルを設定します。
(3) Else, set the neighbor's MDR Level to MDR Other and set the neighbor's Dependent Neighbor variable to 0. (Only MDR/BMDR neighbors can be Dependent.)
（3）それ以外の場合、MDR他に隣人のMDRレベルを設定し、0に隣人の従属ネイバー変数を設定する（のみMDR / BMDRネイバーが依存することができます。）
(4) If the DR or Backup DR field is equal to the router's own Router ID, set the neighbor's Child variable to 1; otherwise, set it to 0.
（4）DRまたはバックアップDRフィールドは、ルータ自身のルータIDに等しい場合、1に隣人の子変数を設定します。それ以外の場合は、0に設定します。
The neighbor ID list of the Hello is divided as follows into the five lists defined in Section 4.1, where N1, N2, N3, and N4 are obtained from the corresponding fields of the MDR-Hello TLV. List 1 is defined to be the first N1 neighbor IDs, List 2 is defined to be the next N2 neighbor IDs, List 3 is defined to be the next N3 neighbor IDs, List 4 is defined to be the next N4 neighbor IDs, and List 5 is defined to be the remaining neighbor IDs in the Hello.
N1、N2、N3、およびN4はMDR-こんにちはTLVの対応するフィールドから取得されているセクション4.1で定義されている5つのリストに次のようにこんにちはのネイバーIDのリストが分割されます。リスト1は、第1 N1ネイバーのIDであると定義され、リスト2は、次N2ネイバーのIDであると定義され、リスト3は、次N3ネイバーのIDであると定義され、リスト4は、次N4ネイバーのIDであると定義され、リストされています5は、こんにちは内の残りのネイバーIDのように定義されます。
Further processing of the Hello depends on whether it is full or differential, which is indicated by the value of the D-bit of the MDR-Hello TLV.
ハローのさらなる処理は、MDR-ハローTLVのDビットの値によって示されている、それは完全または差分であるかどうかに依存します。
If the received Hello is full (the D-bit of the MDR-Hello TLV is 0), the following steps are performed:
受信したハローが満杯である場合（MDR-ハローTLVのDビットが0で）、以下のステップが実行されます。
o If the N1 field of the MDR-Hello TLV is not zero, then an error has occurred and the Hello is discarded. Otherwise, set FullHelloRcvd to 1.
MDR-こんにちはTLVのN1フィールドがゼロでない場合は、O、エラーが発生したとこんにちはは破棄されます。それ以外の場合は、1にFullHelloRcvdを設定します。
o In the neighbor structure, modify the neighbor's DNS to equal the set of neighbor IDs in the Hello's List 3, modify the neighbor's SANS to equal the set of neighbor IDs in the Hello's List 4, and modify the neighbor's BNS to equal the set of neighbor IDs in the union of Lists 3, 4, and 5.
O隣人構造では、一連のに等しくなるように隣人のBNSを、こんにちは者リスト3に隣人IDのセットを等しくこんにちは者リスト4に隣人IDのセットに等しくなるように隣人のSANSを修正し、修正するために隣人のDNSを変更リスト3、4、および5の労働組合で近隣のID。
o If the router itself appears in the Hello's neighbor ID list, the neighbor state machine is executed with the event 2-WayReceived after the Hello is processed. Otherwise, the neighbor state machine is executed with the event 1-WayReceived after the Hello is processed.
ルータ自体はこんにちはのネイバーIDのリストに表示されている場合、O、ネイバーステートマシンは、イベントのHelloが処理された後、2 WayReceivedで実行されます。こんにちはが処理された後にそれ以外の場合は、ネイバーステートマシンは、イベント1-WayReceivedで実行されます。
If the received Hello is differential (the D-bit of the MDR-Hello TLV is 1), the following steps are performed:
受信したハローが差動である場合（MDR-ハローTLVのDビットが1であり）、以下のステップが実行されます。
(1) For each neighbor ID in List 1 or List 2 of the Hello:
（1）一覧1又はハローの一覧2における各隣接IDについて：
o Remove the neighbor ID from the neighbor's DNS, SANS, and BNS,
if it belongs to the neighbor set.
(2) For each neighbor ID in List 3 of the Hello:
（2）こんにちは一覧3における各隣接IDの場合：
o Add the neighbor ID to the neighbor's DNS and BNS, if it does
not belong to the neighbor set.
o Remove the neighbor ID from the neighbor's SANS, if it belongs to the neighbor set.
それは隣接セットに属している場合は、O、隣人のSANSから隣のIDを削除します。
(3) For each neighbor ID in List 4 of the Hello:
（3）こんにちは一覧4の各ネイバーIDの場合：
o Add the neighbor ID to the neighbor's SANS and BNS, if it does
not belong to the neighbor set.
o Remove the neighbor ID from the neighbor's DNS, if it belongs to the neighbor set.
それは隣接セットに属している場合は、O、隣人のDNSからネイバーIDを削除します。
(4) For each neighbor ID in List 5 of the Hello:
（4）こんにちは一覧5の各ネイバーIDの場合：
o Add the neighbor ID to the neighbor's BNS, if it does not
belong to the neighbor set.
o Remove the neighbor ID from the neighbor's DNS and SANS, if it belongs to the neighbor set.
それは隣接セットに属している場合は、O、隣人のDNSとSANSからネイバーIDを削除します。
(5) If the router's own RID appears in List 1, execute the neighbor state machine with the event 1-WayReceived after the Hello is processed.
リスト1のルータ自身のRID表示された場合こんにちはが処理された後に（5）、イベント1-WayReceivedで隣人州のマシンを実行します。
(6) If the router's own RID appears in List 2, 3, 4, or 5, execute the neighbor state machine with the event 2-WayReceived after the Hello is processed.
（6）一覧2、3、4、または5で、ルータ自身のRIDが表示されますが、イベントこんにちは処理された後、2 WayReceivedで隣人州のマシンを実行した場合。
(7) If the router's own RID does not appear in the Hello's neighbor ID list, and the neighbor state is 2-Way or greater, and the Hello Sequence Number is less than or equal to the previous sequence number plus HelloRepeatCount, then the neighbor state machine is executed with the event 2-WayReceived after the Hello is processed (the state does not change).
（7）の場合、ルータのRID自身の隣人の状態は2ウェイ以上であり、かつこんにちはシーケンス番号は、前のシーケンス番号に加えてHelloRepeatCount、隣人以下であるのHelloのネイバーIDのリストに表示させず、こんにちはが処理された後、状態マシンは（状態は変化しません）イベント2 - WayReceivedで実行されます。
(8) If 2-WayReceived is not executed, then 1-WayReceived is executed after the Hello is processed.
2- WayReceivedが実行されていない場合はハローが処理された後（8）、次いで1- WayReceivedが実行されます。
The following applies to both full and differential Hellos.
以下は、フルと差分の両方ハローズに適用されます。
If the router itself belongs to the neighbor's DNS, the neighbor's Dependent Selector variable is set to 1; otherwise, it is set to 0.
ルータ自体が隣人のDNSに属している場合は、隣人の従属セレクター変数が1に設定されています。それ以外の場合は0に設定されています。
The receiving interface's MDRNeighborChange variable is set to 1 if any of the following changes occurred as a result of processing the Hello:
次のいずれかの変更は、ハローを処理した結果として発生した場合、受信インタフェースのMDRNeighborChange変数が1に設定されています：
o The neighbor's state changed from less than 2-Way to 2-Way or greater, or vice versa.
O隣人の状態は、2ウェイ以上に以下2-wayから変更、またはその逆。
o The neighbor is bidirectional and any of the following neighbor variables has changed: MDR Level, Router Priority, FullHelloRcvd, and Bidirectional Neighbor Set (BNS).
O隣人は双方向性であり、次の隣接変数のいずれかが変更されました：MDRレベル、ルータプライオリティ、FullHelloRcvd、および双方向隣接セット（BNS）を。
The neighbor state machine is scheduled with the event AdjOK? if any of the following changes occurred as a result of processing the Hello:
隣人州のマシンはイベントに予定されてAdjOK？次のいずれかの変更は、ハローを処理した結果として発生した場合：
o The neighbor's state changed from less than 2-Way to 2-Way or greater.
隣人の状態O 2ウェイ以上に未満2ウェイから変更。
o The neighbor is bidirectional and its MDR Level has changed, or its Child variable or Dependent Selector variable has changed from 0 to 1.
O隣人は双方向であり、そのMDRレベルは変更されている、またはその子変数や従属セレクター変数が0から1に変更されました。
If the LLS contains a Metric TLV, it is processed by updating the neighbor's link metrics according to the format of the Metric TLV specified in Section A.2.5. If the LLS does not contain a Metric TLV and LSAFullness is 1 or 2, the metric for each of the neighbor's links is set to 1.
LLSは、メトリックTLVが含まれている場合は、セクションA.2.5で指定されたメトリックTLVのフォーマットに従って、隣人のリンクメトリックを更新することによって処理されます。 LLSは、メトリックTLVとLSAFullnessは1または2であるが含まれていない場合は、隣人のリンクのそれぞれについて、メトリックは1に設定されています。
In wireless networks, a single Hello can be received from a neighbor with which a poor connection exists, e.g., because the neighbor is almost out of range. To avoid accepting poor-quality neighbors, and to employ hysteresis, a router may require that a stricter condition be satisfied before changing the state of a MANET neighbor from Down to Init or greater. This condition is called the "neighbor acceptance condition", which by default is the reception of a single Hello or DD packet. For example, the neighbor acceptance condition may require that 2 consecutive Hellos be received from a neighbor before changing the neighbor's state from Down to Init. Other possible conditions include the reception of 3 consecutive Hellos, or the reception of 2 of the last 3 Hellos. The neighbor acceptance condition may also impose thresholds on other measurements such as received signal strength.
隣人はほとんど範囲外であるため、無線ネットワークでは、単一のハローは、例えば、接続不良が存在すると、近隣から受信することができます。質の悪い隣人を受け入れないようにするには、ヒステリシスを採用し、ルータは厳しい状態が初期化以上に下からMANETの隣人の状態を変更する前に満たされることを要求することができます。この状態は、デフォルトでは、単一のHelloまたはDDパケットの受信である「隣人の受け入れ条件」、と呼ばれています。例えば、隣人の受け入れ条件は、2つの連続ハローズがダウンからの初期化に隣人の状態を変更する前にネイバーから受信することを要求することができます。他の可能な条件は、3つの連続ハローズの受信、または最後の3つのハローズの2の受信を含みます。隣接受け入れ条件はまた、受信信号強度のような他の測定値にしきい値を課すことができます。
The neighbor state transition for state Down and event HelloReceived is thus modified (see Section 7.1) to depend on the neighbor acceptance condition.
ダウン状態とイベントHelloReceivedための隣接状態の遷移は、このように隣接受付条件に依存する（7.1節を参照）修飾されています。
This section describes the MDR selection algorithm, which is run for each MANET interface to determine whether the router is an MDR, Backup MDR, or MDR Other for that interface. The algorithm also selects the Dependent Neighbors and the (Backup) Parent, which are used to decide which neighbors should become adjacent (see Section 7.2).
ここでは、ルータは、そのインターフェイスのためのMDR、バックアップMDR、またはMDRその他であるかどうかを決定するために各MANETインターフェイスに対して実行されMDR選択アルゴリズムが記載されています。アルゴリズムは、依存隣人と（セクション7.2を参照）隣接するようになりべき隣人を決定するために使用されている（バックアップ）親を選択します。
The MDR selection algorithm must be executed just before sending a Hello if the MDRNeighborChange bit is set for the interface. The algorithm SHOULD also be executed whenever a bidirectional neighbor transitions to less than 2-Way, and MAY be executed at other times when the MDRNeighborChange bit is set. The bit is cleared after the algorithm is executed.
MDR選択アルゴリズムは、ちょうどMDRNeighborChangeビットがインタフェースに設定されている場合こんにちはを送信する前に実行する必要があります。双方向ネイバー未満2ウェイに遷移、及びMDRNeighborChangeビットが設定されているときに、他の時間に実行することができるたびにアルゴリズムも実行する必要があります。アルゴリズムが実行された後、ビットがクリアされます。
To simplify the implementation, the MDR selection algorithm MAY be executed periodically just before sending each Hello, to avoid having to determine when the MDRNeighborChange bit should be set. After running the MDR selection algorithm, the AdjOK? event may be invoked for some or all neighbors as specified in Section 7.
実装を簡素化するために、MDR選択アルゴリズムは、ちょうどMDRNeighborChangeビットが設定されるべき時期を決定することを避けるために、こんにちはそれぞれを送信する前に、定期的に実行することもできます。 MDR選択アルゴリズムを実行した後、AdjOK？第7節で指定されたイベントは、一部またはすべての隣人のために起動することができます。
The purpose of the MDRs is to provide a minimal set of relays for flooding LSAs, and the purpose of the Backup MDRs is to provide backup relays to flood LSAs when flooding by MDRs does not succeed. The set of MDRs forms a CDS, and the set of MDRs and Backup MDRs forms a biconnected CDS (if the network itself is biconnected).
MDRの目的は、洪水のLSAのためのリレーの最小セットを提供することであり、そしてバックアップのMDRの目的はのMDRによって洪水が成功しないときLSAをフラッディングするバックアップリレーを提供することです。 MDRのセットは、CDSを形成し、（ネットワーク自体が2連結されている場合）のMDRとバックアップ先MDRのセットは2連結CDSを形成します。
Each MDR selects and becomes adjacent with a subset of its MDR neighbors, called Dependent Neighbors, forming a connected backbone. Each non-MDR router connects to this backbone by selecting and becoming adjacent with an MDR neighbor called its Parent. Each MDR selects itself as Parent, to inform neighbors that it is an MDR.
各MDRは、選択して、そのMDRネイバーのサブセットと隣接なり、依存隣人と呼ばれる、接続されたバックボーンを形成します。各非MDRルータは、選択とMDRの隣人がその親と呼ばれると、隣接なることで、このバックボーンに接続します。各MDRは、MDRであることを隣人に知らせるために、親としての自分自身を選択します。
If AdjConnectivity = 2, then each (Backup) MDR selects and becomes adjacent with additional (Backup) MDR neighbors to form a biconnected backbone, and each MDR Other selects and becomes adjacent with a second (Backup) MDR neighbor called its Backup Parent, thus becoming connected to the backbone via two adjacencies. Each BMDR selects itself as Backup Parent, to inform neighbors that it is a BMDR.
AdjConnectivity = 2、各（バックアップ）MDRを選択し、2連結主鎖を形成するために、追加の（バックアップ）MDRネイバーと隣接なり、各MDR他は、このように選択して第二の（バックアップ）MDRの隣人がそのバックアップ親と呼ばと隣接なった場合2つの隣接経由でバックボーンに接続さになります。各BMDRは、それがBMDRであることを隣人に知らせるために、バックアップの親として自分自身を選択します。
The MDR selection algorithm is a distributed CDS algorithm that uses 2-hop neighbor information obtained from Hellos. More specifically, it uses as inputs the set of bidirectional neighbors (in state 2-Way or greater), the triplet (Router Priority, MDR Level, Router ID) for each such neighbor and for the router itself, and the neighbor variables Bidirectional Neighbor Set (BNS) and FullHelloRcvd for each such neighbor. The MDR selection algorithm can be implemented in O(d^2) time, where d is the number of neighbors.
MDR選択アルゴリズムはハローズから得られた2ホップネイバー情報を使用して分散CDSアルゴリズムです。具体的には、このような各ネイバーのために、ルータ自体に（状態2ウェイ以上）、トリプレット（ルータプライオリティ、MDRレベル、ルータID）双方向ネイバーのセットを入力として使用し、隣接変数双方向ネイバーそれぞれのそのような隣人のためのセット（BNS）とFullHelloRcvd。 MDR選択アルゴリズムは、dは近隣の数であり、O（D ^ 2）の時間で実施することができます。
The above triplet will be abbreviated as (RtrPri, MDR Level, RID). The triplet (RtrPri, MDR Level, RID) is said to be larger for Router A than for Router B if the triplet for Router A is lexicographically greater than the triplet for Router B. Routers that have larger values of this triplet are preferred for selection as an MDR. The algorithm therefore prefers routers that are already MDRs, resulting in a longer average MDR lifetime.
上記トリプレット（RtrPri、MDRレベル、RID）と略記します。ルータAのトリプレットを選択するのに好ましいこのトリプレットのより大きな値を有するルータB.ルータのトリプレットより辞書大きい場合トリプレット（RtrPri、RID MDRレベル）ルータBよりもルータAの大きくなると言われていますMDRとして。アルゴリズムは、したがって、より長い平均MDR寿命が得られ、既にのMDRであるルータを好みます。
The MDR selection algorithm consists of five phases, the last of which is optional. Phase 1 creates the neighbor connectivity matrix for the interface, which determines which pairs of neighbors are neighbors of each other. Phase 2 decides whether the calculating router is an MDR, and which MDR neighbors are Dependent. Phase 3 decides whether the calculating router is a Backup MDR and, if AdjConnectivity = 2, which additional MDR/BMDR neighbors are Dependent. Phase 4 selects the Parent and Backup Parent.
MDR選択アルゴリズムはオプションで、最後のうち5つのフェーズで構成されています。フェーズ1は、近隣の対は互いに隣接しているかを決定するインターフェイス、のための隣接接続性マトリックスを作成します。フェーズ2は、計算ルータはMDRで、どのMDRの隣人が依存しているかどうかを決定します。フェーズ3は、計算のルータがバックアップMDRあるか否かを判断して、追加のMDR / BMDR隣人が依存しているAdjConnectivity = 2、もし。フェーズ4は、親とバックアップ親を選択します。
The algorithm simplifies considerably if AdjConnectivity is 0 (full-topology adjacencies). In this case, the set of Dependent Neighbors is empty and MDR Other routers need not select Parents. Also, Phase 3 (BMDR selection) is not required if AdjConnectivity is 0 or 1. However, Phase 3 MUST be executed if AdjConnectivity is 2, and SHOULD be executed if AdjConnectivity is 0 or 1, since BMDRs improve robustness by providing backup flooding.
AdjConnectivityは0（完全トポロジー隣接）である場合、アルゴリズムは、かなり簡素化されます。この場合、依存隣人のセットが空で、MDR他のルータは、両親を選択する必要はありません。 AdjConnectivityしかし0または1である場合にも、フェーズ3（BMDR選択）が必要とされないAdjConnectivityが2である場合、フェーズ3が実行されなければならない、とAdjConnectivityは0又は1である場合BMDRsバックアップフラッディングを提供することによって、堅牢性を改善するため、実行されるべき。
A router that has selected itself as an MDR in Phase 2 MAY execute Phase 5 to possibly declare itself a non-flooding MDR. A non-flooding MDR is the same as a flooding MDR except that it does not automatically flood received LSAs back out the receiving interface, because it has determined that neighboring MDRs are sufficient to flood the LSA to all neighbors. Instead, a non-flooding MDR performs backup flooding just like a BMDR. A non-flooding MDR maintains its MDR level (rather than being demoted to a BMDR) in order to maximize the stability of adjacencies. (The decision to form an adjacency does not depend on whether an MDR is non-flooding.) By having MDRs declare themselves to be non-flooding when possible, flooding overhead is reduced. The resulting reduction in flooding overhead can be dramatic for certain regular topologies, but has been found to be less than 15% for random topologies.
フェーズ2におけるMDRとして自身を選択したルータは、おそらくそれ自体が非フラッディングMDRを宣言するフェーズ5を実行してもよいです。非フラッディングMDRは、それが近隣のMDRは、すべてのネイバーにLSAをあふれさせるのに十分であると判断したので、それは自動的に、受信インタフェースから戻って受信したLSAをあふれないことを除いてフラッディングMDRと同じです。代わりに、非洪水MDRはちょうどBMDRのようなバックアップフラッディングを実行します。非フラッディングMDRは、隣接の安定性を最大にするために（かなりBMDRに降格されるよりも）そのMDRレベルを維持します。 （MDR非フラッディングであるかどうかに依存しない隣接関係を形成するための決定。）のMDRを有することによっては、フラッディングオーバーヘッドが低減され、可能な場合、それ自体が非フラッディングであると宣言する。洪水オーバーヘッドの結果の減少は、特定の定期的なトポロジの劇的なことができますが、ランダムなトポロジの15％未満であることが判明しています。
The following subsections describe the MDR selection algorithm, which is applied independently to each MANET interface. For convenience, the term "bi-neighbor" will be used as an abbreviation for "bidirectional neighbor".
以下のサブセクションでは、各MANETインタフェースに独立に適用されるMDR選択アルゴリズムを記述する。便宜上、用語「バイ隣人は」「双方向の隣人」の略称として使用されます。
Phase 1 creates the neighbor connectivity matrix (NCM) for the interface. The NCM is a symmetric matrix that defines a topology graph for the set of bi-neighbors on the interface. The NCM assigns a value of 0 or 1 for each pair of bi-neighbors; a value of 1 indicates that the neighbors are assumed to be bi-neighbors of each other in the MDR selection algorithm. Letting i denote the router itself, NCM(i,j) and NCM(j,i) are set to 1 for each bi-neighbor j. The value of the matrix is set as follows for each pair of bi-neighbors j and k on the interface.
フェーズ1は、インターフェースのための隣接接続マトリクス（NCM）を作成します。 NCMは、インターフェイス上の双方向の隣人のセットのトポロジグラフを定義する対称行列です。 NCMは、双近隣の各ペアのために0または1の値を代入します。 1の値は、隣人がMDR選択アルゴリズムにおいて互いに双方向ネイバーであると仮定されていることを示しています。私はルータ自体を表しせ、NCM（I、J）及びNCM（j、i）に対して、各二隣接jに対して1に設定されています。インタフェース上の双方向ネイバーjとkの各対について、以下のように行列の値が設定されています。
(1.1) If FullHelloRcvd is 1 for both neighbors j and k: NCM(j,k) = NCM(k,j) is 1 only if j belongs to the BNS of neighbor k and k belongs to the BNS of neighbor j.
（1.1）FullHelloRcvdの両方隣人jとkの1である場合：NCM（J、K）はNCM（k、j）はjは隣接kのBNSに属し、kは隣接jのBNSに属している場合にのみ1 =。
(1.2) If FullHelloRcvd is 1 for neighbor j and is 0 for neighbor k: NCM(j,k) = NCM(k,j) is 1 only if k belongs to the BNS of neighbor j.
FullHelloRcvdが隣接jについて1であり、隣接kの0の場合（1.2）：NCM（J、K）= NCM（k、j）は、kは、隣接jのBNSに属する1場合のみです。
(1.3) If FullHelloRcvd is 0 for both neighbors j and k: NCM(j,k) = NCM(k,j) = 0.
（1.3）FullHelloRcvdの両方隣人jとkの0の場合：NCM（J、K）は= NCM（K、J）= 0。
In Step 1.1 above, two neighbors are considered to be bi-neighbors of each other only if they both agree that the other router is a bi-neighbor. This provides faster response to the failure of a link between two neighbors, since it is likely that one router will detect the failure before the other router. In Step 1.2 above, only neighbor j has reported its full BNS, so neighbor j is believed in deciding whether j and k are bi-neighbors of each other. As Step 1.3 indicates, two neighbors are assumed not to be bi-neighbors of each other if neither neighbor has reported its full BNS.
ステップ以上1.1では、2人の隣人は、それらの両方が、他のルータが双方向の隣人であることに同意した場合にのみ、互いの双方向の隣人であると考えられています。 1つのルータが他のルータの前に障害を検出する可能性があるので、これは、2つのネイバー間のリンクの故障に速い応答を提供します。上記のステップ1.2では、唯一の隣人jは、その完全なBNSを報告しているので、隣人jはjおよびkは、それぞれ他の双方向の隣人であるかどうかを決定する際に考えられています。ステップ1.3が示すように、2人の隣人は、どちらも隣人がその全BNSを報告した場合、互いの双方向の隣人ではないと仮定されています。
Phase 2 depends on the parameter MDRConstraint, which affects the number of MDRs selected. The default value of 3 results in nearly the minimum number of MDRs, while the value 2 results in a larger number of MDRs. If AdjConnectivity = 0 (full-topology adjacencies), then the following steps are modified in that Dependent Neighbors are not selected.
フェーズ2は、選択されたのMDRの数に影響を与えるパラメータMDRConstraint、に依存します。先MDRの多数の値2の結果、一方のMDRのほぼ最小数の3つの結果のデフォルト値。 AdjConnectivity = 0（完全トポロジー隣接）は、次の手順は、その依存隣人に修飾されている場合は選択されません。
(2.1) The set of Dependent Neighbors is initialized to be empty.
（2.1）依存隣人のセットが空であるように初期化されます。
(2.2) If the router has a larger value of (RtrPri, MDR Level, RID) than all of its bi-neighbors, the router selects itself as an MDR; selects all of its MDR bi-neighbors as Dependent Neighbors; if AdjConnectivity = 2, selects all of its BMDR bi-neighbors as Dependent Neighbors; then proceeds to Phase 4.
ルータはその双近隣のすべてより（RtrPri、MDRレベル、RID）の大きな値を有する場合（2.2）は、ルータは、MDRとしてそれ自身を選択します。依存隣人としてのMDRの双方向ネイバーのすべてを選択します。 AdjConnectivity = 2の場合、依存隣人としてのBMDR双方向ネイバーの全てを選択します。次いで、4フェーズに移行します。
(2.3) Let Rmax be the bi-neighbor with the largest value of (RtrPri, MDR Level, RID).
（2.3）Rmaxは（RtrPri、MDRレベルは、RID）の最大値との双方向の隣人とします。
(2.4) Using NCM to determine the connectivity of bi-neighbors, compute the minimum number of hops, denoted hops(u), from Rmax to each other bi-neighbor u, using only intermediate nodes that are bi-neighbors with a larger value of (RtrPri, MDR Level, RID) than the router itself. If no such path from Rmax to u exists, then hops(u) equals infinity. (See Appendix B for a detailed algorithm using breadth-first search.)
（2.4）より大きな値を持つ双隣接しているのみ中間ノードを使用して、Rmaxとから互いに双方向ネイバーにUのホップの最小数、示さホップ（U）を、計算し、双方向近隣の接続性を決定するために、NCMを使用し（RtrPri、MDRレベル、RID）のルータ自体よりも。 RmaxとからUへのそのようなパスが存在しない場合は、（U）をホップ無限大に等しいです。 （幅優先探索を用いた詳細なアルゴリズムについては、付録Bを参照してください。）
(2.5) If hops(u) is at most MDRConstraint for each bi-neighbor u, the router selects no Dependent Neighbors, and sets its MDR Level as follows: If the MDR Level is currently MDR, then it is changed to BMDR if Phase 3 will be executed and to MDR Other if Phase 3 will not be executed. Otherwise, the MDR Level is not changed.
（2.5）の場合のホップ（u）はuは、ルータは何の依存隣人を選択していない各双方向の隣人のための最もMDRConstraintであり、かつ、次のようにそのMDRレベルを設定します：MDRレベルが現在MDRであれば、それはフェーズ場合BMDRに変更されますフェーズ3は実行されない場合は3とMDR他に実行されます。それ以外の場合は、MDRレベルは変更されません。
(2.6) Else, the router sets its MDR Level to MDR and selects the following neighbors as Dependent Neighbors: Rmax if it is an MDR or BMDR; each MDR bi-neighbor u such that hops(u) is greater than MDRConstraint; and if AdjConnectivity = 2, each BMDR bi-neighbor u such that hops(u) is greater than MDRConstraint.
（2.6）は、そうでなければ、ルータは、MDRへのMDRレベルを設定し、依存隣人として、次の隣人を選択：それはMDRかBMDRであればRmaxは、ホップ（u）がMDRConstraintより大きいことuは、各MDR双方向隣接。そしてAdjConnectivity = 2、ホップU、各BMDR双隣接場合（u）はMDRConstraintより大きい。
(2.7) If steps 2.1 through 2.6 resulted in the MDR Level changing to BMDR, or to MDR with AdjConnectivity equal to 1 or 2, then execute steps 2.1 through 2.6 again. (This is necessary because the change in MDR Level can cause the set of Dependent Neighbors and the BFS tree to change.) This step is not required if the MDR selection algorithm is executed periodically.
（2.7）2.6を介して2.1 MDRレベルをもたらしステップは1又は2に等しいAdjConnectivityでBMDRに、またはMDRに変化した場合、再度2.6を介してステップ2.1を行います。 （MDRレベルの変化が依存隣人のセットと変更するBFSツリーを引き起こす可能性があるので、これが必要です。）MDR選択アルゴリズムを定期的に実行された場合、この手順は必要ありません。
Step 2.4 can be implemented using a breadth-first search (BFS) algorithm to compute min-hop paths from Rmax to all other bi-neighbors, modified to allow a bi-neighbor to be an intermediate node only if its value of (RtrPri, MDR Level, RID) is larger than that of the router itself. A detailed description of this algorithm, which runs in O(d^2) time, is given in Appendix B.
ステップ2.4双方向ネイバーが中間ノードであることを可能にするように変更されたすべての他の二ネイバーにさRmaxから最小ホップ経路を計算する幅優先探索（BFS）アルゴリズムを使用して実装することができる場合にのみ、その値（RtrPri、 RID MDRレベルは、）ルータ自体のそれよりも大きくなっています。 O（D ^ 2）の時間で実行され、このアルゴリズムの詳細な説明は、付録Bに記載されています
(3.1) If the MDR Level is MDR (after running Phase 2) and AdjConnectivity is not 2, then proceed to Phase 4. (If the MDR Level is MDR and AdjConnectivity = 2, then Phase 3 may select additional Dependent Neighbors to create a biconnected backbone.)
MDRレベルはMDRとAdjConnectivity = 2の場合（3.1）MDRレベルは、（フェーズ2を実行した後）MDRとAdjConnectivityが2でない場合は、4相に進む（次にフェーズ3が作成する追加の依存ネイバーを選択することができます。 2連結バックボーン。）
(3.2) Using NCM to determine the connectivity of bi-neighbors, determine whether or not there exist two node-disjoint paths from Rmax to each other bi-neighbor u, using only intermediate nodes that are bi-neighbors with a larger value of (RtrPri, MDR Level, RID) than the router itself. (See Appendix B for a detailed algorithm.)
（3.2）双方向の隣人の接続性を決定するために、NCMを使用して、uは（より大きな値と双方向ネイバーのみ中間ノードを使用して、Rmaxとから互いに双方向ネイバーへの2つのノードディスジョイント経路が存在するか否かを判定するルータ自体よりRtrPri、MDRレベル、RID）。 （詳細なアルゴリズムについては、付録Bを参照してください。）
(3.3) If there exist two such node-disjoint paths from Rmax to each other bi-neighbor u, then the router selects no additional Dependent Neighbors and sets its MDR Level to MDR Other.
互いに双方向隣接UとRmaxとの二つのそのようなノードディスジョイント経路が存在する場合（3.3）、ルータは追加の従属ネイバーを選択せず、MDRの他に、そのMDRレベルを設定します。
(3.4) Else, the router sets its MDR Level to Backup MDR unless it already selected itself as an MDR in Phase 2, and if AdjConnectivity = 2, adds each of the following neighbors to the set of Dependent Neighbors: Rmax if it is an MDR or BMDR, and each MDR/BMDR bi-neighbor u such that Step 3.2 did not find two node-disjoint paths from Rmax to u.
それはすでにフェーズ2でMDRとしての地位を選ばない限り、（3.4）は、そうでなければ、ルータはバックアップMDRへのMDRレベルを設定し、AdjConnectivity = 2場合、依存隣人のセットに、次の隣人のそれぞれを追加します。それがあればRmaxはMDR又はBMDR、各MDR / BMDR双隣接Uは、そのステップ3.2は、RmaxとからUへの2つのノードディスジョイントパスを見つけられませんでした。
(3.5) If steps 3.1 through 3.4 resulted in the MDR Level changing from MDR Other to BMDR, then run Phases 2 and 3 again. (This is necessary because running Phase 2 again can cause the MDR Level to change to MDR.) This step is not required if the MDR selection algorithm is executed periodically.
（3.5）3.4を通じて3.1 MDRレベルがBMDRにMDRその他の変更が生じた段階で、再度フェーズ2と3を実行した場合。 （再度、フェーズ2を実行すると、MDRレベルはMDRに変更することがありますので、これが必要です。）MDR選択アルゴリズムを定期的に実行された場合、この手順は必要ありません。
Step 3.2 can be implemented in O(d^2) time using the algorithm given in Appendix B. A simplified version of the algorithm is also specified, which results in a larger number of BMDRs.
ステップ3.2 BMDRsのより多くをもたらすも指定されたアルゴリズムの付録B. A簡易版で与えられたアルゴリズムを用いてOに（D ^ 2）の時間を実現することができます。
Each router selects a Parent for each MANET interface. The Parent of a non-MDR router will be a neighboring MDR if one exists. If the option of biconnected adjacencies is chosen, then each MDR Other selects a Backup Parent, which will be a neighboring MDR/BMDR if one exists that is not the Parent. The Parent of an MDR is always the router itself, and the Backup Parent of a BMDR is always the router itself.
各ルータは、各MANETインタフェースの親を選択します。が存在する場合、非MDRルータの親は、隣接MDRであろう。 2連結隣接のオプションを選択する場合、各MDR他の一つは、その親でない存在する場合、隣接MDR / BMDRされるバックアップ親を選択します。 MDRの親は常にルータ自体で、BMDRのバックアップ親は常にルータ自体です。
The (Backup) Parent is advertised in the (Backup) DR field of each Hello sent on the interface. As specified in Section 7.2, each router forms an adjacency with its Parent and Backup Parent if it exists and is a neighboring MDR/BMDR.
（バックアップ）親が各ハローの（バックアップ）DRフィールドにアドバタイズされるインターフェイス上で送信されました。セクション7.2で指定されるように、それが存在し、隣接MDR / BMDRある場合、各ルータは、その親とバックアップ親と隣接関係を形成します。
For a given MANET interface, let Rmax denote the router with the largest value of (RtrPri, MDR Level, RID) among all bidirectional neighbors, if such a neighbor exists that has a larger value of (RtrPri, MDR Level, RID) than the router itself. Otherwise, Rmax is null.
所与MANETインタフェースのため、そのような隣人がそれよりも（RtrPri、MDRレベル、RID）の大きい方の値を持つ存在する場合Rmaxは、すべての双方向の隣人のうち（RtrPri、MDRレベル、RID）の最大値とルータを示すものとルータ自体。それ以外の場合は、Rmaxがnullです。
If the calculating router has selected itself as an MDR, then the Parent is equal to the router itself, and the Backup Parent is Rmax. (The latter design choice was made because it results in slightly better performance than choosing no Backup Parent.) If the router has selected itself as a BMDR, then the Backup Parent is equal to the router itself.
計算ルータがMDRとしてそれ自身を選択した場合、親は、ルータ自体に等しく、バックアップ親はRmaxです。 （それは予備親を選択しないよりもわずかにパフォーマンスが向上しているため、後者の設計上の選択が行われた。）ルータがBMDRとして自分自身を選択した場合は、[バックアップ親はルータ自体に等しいです。
If the calculating router is a BMDR or MDR Other, the Parent is selected to be any adjacent neighbor that is an MDR, if such a neighbor exists. If no adjacent MDR neighbor exists, then the Parent is selected to be Rmax. By giving preference to neighbors that are already adjacent, the formation of a new adjacency is avoided when possible. Note that the Parent can be a non-MDR neighbor temporarily when no MDR neighbor exists. (This design choice was also made for performance reasons.)
計算のルータがBMDRまたはMDR他のであれば、親は、ネイバーが存在する場合、MDRである任意の隣接ネイバーであるように選択されます。隣接するMDRネイバーが存在しない場合は、親がRmaxであるように選択されます。すでに隣接している隣人を優先することで、新しい隣接関係の形成が可能な場合は回避されます。何MDRネイバーが存在しない場合、親が一時的に非MDR隣接することができることに注意してください。 （この設計の選択は、パフォーマンス上の理由のために作られました。）
If AdjConnectivity = 2 and the calculating router is an MDR Other, then the Backup Parent is selected to be any adjacent neighbor that is an MDR or BMDR, other than the Parent selected in the previous paragraph, if such a neighbor exists. If no such adjacent neighbor exists, then the Backup Parent is selected to be the bidirectional neighbor, excluding the selected Parent, with the largest value of (RtrPri, MDR Level, RID), if such a neighbor exists. Otherwise, the Backup Parent is null.
AdjConnectivity = 2と算出ルータがMDRその他の場合は、バックアップ親は、ネイバーが存在する場合、前の段落で選択した親以外のMDR又はBMDR、任意の隣接する近隣であるように選択されます。そのような隣接ネイバーが存在しない場合、そのようなネイバーが存在する場合、バックアップ親は、（RtrPri、MDRレベル、RID）の最大値と、選択した親除く双方向の隣人を、ように選択されます。それ以外の場合は、バックアップの親はnullです。
A router that has selected itself as an MDR MAY execute the following steps to possibly declare itself a non-flooding MDR. An MDR that does not execute the following steps is by default a flooding MDR.
MDRとしての地位を選択しているルータは、おそらくそれ自体が非洪水のMDRを宣言するために、次のステップを実行することができます。次の手順を実行しませんMDRは、デフォルトでは洪水のMDRです。
(5.1) If the router has a larger value of (RtrPri, MDR Level, RID) than all of its bi-neighbors, the router is a flooding MDR. Else, proceed to Step 5.2.
（5.1）ルータは双方向の隣人のすべてより（RtrPri、MDRレベル、RID）の大きい値を持っている場合、ルータはフラッディングMDRあります。そうでなければ、5.2に進みます。
(5.2) Let Rmax be the bi-neighbor that has the largest value of (RtrPri, MDR Level, RID).
（5.2）（RID、RtrPri、MDRレベル）Rmaxが最大の値を持つ双方向の隣人とします。
(5.3) Using NCM to determine the connectivity of bi-neighbors, compute the minimum number of hops, denoted hops(u), from Rmax to each other bi-neighbor u, using only intermediate nodes that are MDR bi-neighbors with a smaller value of (RtrPri, RID) than the router itself. (This can be done using BFS as in Step 2.4).
、示さホップ（U）、Rmaxとから互いに双方向隣接Uまでのホップの最小数を、双方向近隣の接続性を決定する計算するNCMを使用し（5.3）、小さいとMDR双隣接しているのみ中間ノードを使用してルータ自体より（RtrPri、RID）の値。 （これは、ステップ2.4のようにBFSを使用して行うことができます）。
(5.4) If hops(u) is at most MDRConstraint for each bi-neighbor u, then the router is a non-flooding MDR. Else, it is a flooding MDR.
（5.4）は、ホップが（u）は、それぞれ双方向の隣人uのための最もMDRConstraintである場合、ルータは非洪水のMDRです。そうでなければ、それは洪水のMDRです。
No new states are defined for a MANET interface. However, the DR and Backup states now imply that the router is an MDR or Backup MDR, respectively. The following modified definitions apply to MANET interfaces:
新しい状態はMANETインタフェース用に定義されていません。しかし、DRおよびバックアップの状態は今ルータは、それぞれ、MDRまたはバックアップMDRであることを示唆しています。以下の変形の定義は、MANETインターフェイスに適用されます。
Waiting In this state, the router learns neighbor information from the Hello packets it receives, but is not allowed to run the MDR selection algorithm until it transitions out of the Waiting state (when the Wait Timer expires). This prevents unnecessary changes in the MDR selection resulting from incomplete neighbor information. The length of the Wait Timer is 2HopRefresh * HelloInterval seconds (the interval between full Hellos).
この状態で待機中、ルータは、受信したHelloパケットからネイバー情報を学習し、それは待機状態から移行するまで（待ちタイマが満了した場合）MDR選択アルゴリズムを実行することはできません。これは、不完全な隣接情報から得られたMDR選択における不要な変更を防止することができます。待ちタイマの長さは2HopRefresh * HelloIntervalの秒（フルハローズの間隔）です。
DR Other The router has run the MDR selection algorithm and determined that it is not an MDR or a Backup MDR.
DR他のルータはMDR選択アルゴリズムを実行し、MDRまたはバックアップMDRないと判断しました。
Backup The router has selected itself as a Backup MDR.
バックアップルータがバックアップMDRとしての地位を選択しています。
DR The router has selected itself as an MDR.
DRルータは、MDRとしてそれ自身を選択しました。
All interface events defined in [RFC2328], Section 9.2, apply to MANET interfaces, except for BackupSeen and NeighborChange. BackupSeen is never invoked for a MANET interface (since seeing a Backup MDR does not imply that the router itself cannot also be an MDR or Backup MDR).
[RFC2328]、セクション9.2で定義されたすべてのインタフェースイベントは、BackupSeenとNeighborChangeを除いて、MANETインタフェースに適用されます。 BackupSeenはMANETインタフェース（バックアップMDRを見ているので、ルータ自体もMDRまたはバックアップMDRすることができないことを意味するものではない）のために呼び出されることはありません。
The event NeighborChange is replaced with the new interface variable MDRNeighborChange, which indicates that the MDR selection algorithm must be executed due to a change in neighbor information (see Section 4.2.3).
イベントはNeighborChangeはMDR選択アルゴリズムが原因近隣情報の変化を実行しなければならないことを示す新しいインタフェース変数MDRNeighborChange、（セクション4.2.3を参照）で置換されています。
This section describes the changes to the interface state machine for a MANET interface. The two state transitions specified below are for state-event pairs that are described in [RFC2328], but have modified action descriptions because MDRs are selected instead of DRs. The state transition in [RFC2328] for the event NeighborChange is omitted; instead, the new interface variable MDRNeighborChange is used to indicate when the MDR selection algorithm needs to be executed. The state transition for the event BackupSeen does not apply to MANET interfaces, since this event is never invoked for a MANET interface. The interface state transitions for the events Loopback and UnloopInd are unchanged from [RFC2328].
このセクションでは、MANETインターフェイスのインターフェイスステートマシンの変更点について説明します。以下に指定された2つの状態遷移が[RFC2328]に記載されている状態イベントのペアのためのものであるが、先MDRは、のDRの代わりに選択されているため、アクションの記述を変更しました。 NeighborChangeが省略されたイベントのために[RFC2328]の状態遷移。代わりに、新しいインタフェース変数MDRNeighborChangeはMDR選択アルゴリズムを実行する必要があるときを示すために使用されます。このイベントは、MANETのインタフェースのために呼び出されることはないので、イベントBackupSeenの状態遷移は、MANETのインターフェースには適用されません。イベントループバックとUnloopIndためのインタフェース状態遷移が[RFC2328]から変化していません。
State: Down Event: InterfaceUp New state: Depends on action routine.
状態：ダウンイベント：InterfaceUp新しい状態は：アクションルーチンによります。
Action: Start the interval Hello Timer, enabling the periodic sending of Hello packets out the interface. The state transitions to Waiting and the single shot Wait Timer is started.
処置：インタフェースからHelloパケットの送信周期性を有効にする、間隔のHelloタイマーを起動します。待機とシングルショットの状態遷移は、タイマーが開始されるまで待ちます。
State: Waiting Event: WaitTimer New state: Depends on action routine.
状態：待機イベント：WaitTimer新しい状態は：アクションルーチンによります。
Action: Run the MDR selection algorithm, which may result in a change to the router's MDR Level, Dependent Neighbors, and (Backup) Parent. As a result of this calculation, the new interface state will be DR Other, Backup, or DR.
アクション：ルータのMDRレベルへの変化、依存隣人、と（バックアップ）親になることがありMDR選択アルゴリズムを実行します。この計算の結果として、新しい界面状態がDR他、バックアップ、またはDRであろう。
As a result of these changes, the AdjOK? neighbor event
may be invoked for some or all neighbors. (See
Section 7.)
Adjacency forming and eliminating on non-MANET interfaces remain unchanged. Adjacency maintenance on a MANET interface requires changes to transitions in the neighbor state machine ([RFC2328], Section 10.3), to deciding whether to become adjacent ([RFC2328],
成形および非MANETに除去隣接インターフェイスが変わりません。 MANETインタフェースに隣接メンテナンスは、隣接する（[RFC2328]になるためにかどうかを決定するに隣接ステートマシン（[RFC2328]、セクション10.3）での遷移に変更する必要
Section 10.4), sending of DD packets ([RFC2328], Section 10.8), and receiving of DD packets ([RFC2328], Section 10.6). The specification below relates to the MANET interface only.
セクション10.4）、DDパケット（[RFC2328]、セクション10.8）の送信、及びDDパケット（[RFC2328]、セクション10.6）の送受信。以下の仕様は、MANETインタフェースに関する。
If full-topology adjacencies are used (AdjConnectivity = 0), the router forms an adjacency with each bidirectional neighbor. If adjacency reduction is used (AdjConnectivity is 1 or 2), the router forms adjacencies with a subset of its neighbors, according to the rules specified in Section 7.2.
フルトポロジー隣接を（AdjConnectivity = 0）が使用される場合、ルータは各双方向ネイバーとの隣接関係を形成します。隣接還元が使用される場合（AdjConnectivityは1又は2）、ルータ形態は、セクション7.2で指定された規則に従って、その隣接のサブセットとの隣接します。
An adjacency maintenance decision is made when any of the following four events occur between a router and its neighbor. The decision is made by executing the neighbor event AdjOK?.
次の4つのイベントのいずれかが、ルータとその隣人の間で発生したときに隣接メンテナンス決定がなされています。決定は隣人イベントAdjOKを実行することによって作られます？。
(1) The neighbor state changes from Init to 2-Way.
（1）2ウェイの初期からネイバー状態変化。
(2) The MDR Level changes for the neighbor or for the router itself.
（2）MDRレベルは、隣人のためか、ルータ自身のために変更されます。
(3) The neighbor is selected to be the (Backup) Parent.
（3）隣接は（バックアップ）親となるように選択されます。
(4) The neighbor selects the router to be its (Backup) Parent.
（4）隣人がその（バックアップ）親にルータを選択します。
The following specifies new transitions in the neighbor state machine.
以下は、ネイバーステートマシンに新しい遷移を指定します。
State(s): Down Event: HelloReceived New state: Depends on action routine.
状態（S）：ダウンイベント：HelloReceived新しい状態は：アクションルーチンによります。
Action: If the neighbor acceptance condition is satisfied (see Section 4.3), the neighbor state transitions to Init and the Inactivity Timer is started. Otherwise, the neighbor remains in the Down state.
処置：初期化と非アクティブタイマーに隣接受け入れ条件が満たされた場合（4.3節を参照）、ネイバーの状態遷移が開始されます。そうでなければ、隣人はダウン状態のまま。
State(s): Init Event: 2-WayReceived New state: 2-Way
状態（S）：初期化イベント：2-WayReceived新しい状態：2ウェイ
Action: Transition to neighbor state 2-Way.
処置：隣人の状態への移行2ウェイ。
State(s): 2-Way Event: AdjOK? New state: Depends on action routine.
状態（S）：2ウェイイベント：AdjOK？新しい状態は：アクションルーチンによります。
Action: Determine whether an adjacency should be formed with the neighboring router (see Section 7.2). If not, the neighbor state remains at 2-Way and no further action is taken.
処置：隣接は隣接ルータ（セクション7.2を参照）で形成されるべきかどうかを決定します。ない場合は、隣人の状態は2ウェイのままで、それ以上のアクションは取られません。
Otherwise, the neighbor state changes to ExStart, and the
following actions are performed. If the neighbor has a
larger Router ID than the router's own ID, and the
received packet is a DD packet with the initialize (I),
more (M), and master (MS) bits set, then execute the
event NegotiationDone, which causes the state to
transition to Exchange.
Otherwise (negotiation is not complete), the router increments the DD sequence number in the neighbor data structure. If this is the first time that an adjacency has been attempted, the DD sequence number should be assigned a unique value (like the time of day clock). It then declares itself master (sets the master/slave bit to master), and starts sending Database Description packets, with the initialize (I), more (M), and master (MS) bits set, the MDR-DD TLV included in an LLS, and the L bit set. This Database Description packet should be otherwise empty. This Database Description packet should be retransmitted at intervals of RxmtInterval until the next state is entered (see [RFC2328], Section 10.8).
そうでない場合（ネゴシエーションが完了していない）、ルータは隣人データ構造のDDシーケンス番号をインクリメントします。これは隣接関係が試みられたのは今回が初めてである場合は、DDシーケンス番号は、（日・クロックの時間のような）一意の値を割り当てる必要があります。それは、マスタ（マスタマスタ/スレーブビットをセット）自身を宣言し、初期化（I）、複数（M）と、データベース記述パケットの送信を開始し、マスター（MS）ビットはセット、MDR-DD TLVは、中に含まLLS、及びLビットセット。このデータベース説明パケットは、そうでない場合は、空でなければなりません。次の状態が入力されるまで、このデータベース説明パケットに含まれるのは（[RFC2328]、セクション10.8を参照してください）RxmtIntervalの間隔で再送信する必要があります。
State(s): ExStart or greater Event: AdjOK? New state: Depends on action routine.
状態（S）：のExStart以上イベント：AdjOK？新しい状態は：アクションルーチンによります。
Action: Determine whether the neighboring router should still be adjacent (see Section 7.3). If yes, there is no state change and no further action is necessary. Otherwise, the (possibly partially formed) adjacency must be destroyed. The neighbor state transitions to 2-Way. The Link state retransmission list, Database summary list, and Link state request list are cleared of LSAs.
アクション：隣接ルータがまだ隣接すべきかどうかを決定（7.3節を参照してください）。そうならば、そこには状態変化がなく、それ以上のアクションは必要ありません。そうでない場合、（おそらく部分的に形成された）隣接関係が破棄されなければなりません。 2ウェイの隣人状態遷移。リンクステート再送リスト、Database概要リスト、およびLink州の要求リストは、LSAのクリアされます。
The following defines the method to determine if an adjacency should be formed between neighbors in state 2-Way. The following procedure does not depend on whether AdjConnectivity is 1 or 2, but the selection of Dependent Neighbors (by the MDR selection algorithm) depends on AdjConnectivity.
以下に、隣接状態2ウェイに隣人との間に形成されるべきかどうかを決定する方法を定義します。次の手順はAdjConnectivityは1又は2であるが、従属ネイバー（MDR選択アルゴリズムによる）の選択はAdjConnectivityに依存するかどうかには依存しません。
If adjacency reduction is not used (AdjConnectivity = 0), then an adjacency is formed with each neighbor in state 2-Way. Otherwise, an adjacency is formed with a neighbor in state 2-Way if any of the following conditions is true:
隣接還元が使用されていない場合（AdjConnectivity = 0）、次に隣接は状態2ウェイの各隣接して形成されています。次の条件のいずれかに該当する場合それ以外の場合は、隣接関係が状態2ウェイで隣人が形成されています。
(1) The router is a (Backup) MDR and the neighbor is a (Backup) MDR and is either a Dependent Neighbor or a Dependent Selector.
（1）ルータは（バックアップ）MDRと隣人は（バックアップ）MDRで、従属ネイバーまたは依存セレクタのいずれかです。
(2) The neighbor is a (Backup) MDR and is the router's (Backup) Parent.
（2）隣人が（バックアップ）MDRで、ルータの（バックアップ）親です。
(3) The router is a (Backup) MDR and the neighbor is a child.
（3）ルータは（バックアップ）MDRで、隣人が子供です。
(4) The neighbor's A-bit is 1, indicating that the neighbor is using full-topology adjacencies.
（4）隣接のAビットは、隣接フルトポロジー隣接を使用していることを示し、1です。
Otherwise, an adjacency is not established and the neighbor remains in state 2-Way.
それ以外の場合は、隣接関係を確立し、隣人が状態2ウェイに残っていません。
The following defines the method to determine if an existing adjacency should be eliminated. An existing adjacency is maintained if any of the following is true:
以下では、既存の隣接関係が解消されなければならないかどうかを決定する方法を定義します。以下のいずれかに該当する場合、既存の隣接関係が維持されます。
(1) The router is an MDR or Backup MDR.
（1）ルータは、MDRまたはバックアップMDRです。
(2) The neighbor is an MDR or Backup MDR.
（2）隣人がMDRまたはバックアップMDRです。
(3) The neighbor's A-bit is 1, indicating that the neighbor is using full-topology adjacencies.
（3）隣人のAビットは、隣接フルトポロジー隣接を使用していることを示し、1です。
Otherwise, the adjacency MAY be eliminated.
それ以外の場合は、隣接関係を省略してもよいです。
Sending a DD packet on a MANET interface is the same as [RFC5340], Section 4.2.1.2, and [RFC2328], Section 10.8, with the following additions to paragraph 3 of Section 10.8.
MANETインタフェース上DDパケットを送信すると、セクション10.8のパラグラフ3に以下の追加と[RFC5340]、セクション4.2.1.2、および[RFC2328]、セクション10.8、同じです。
If the neighbor state is ExStart, the standard initialization packet is sent with an MDR-DD TLV appended using LLS, and the L bit is set in the DD packet's option field. The format for the MDR-DD TLV is specified in Section A.2.4. The DR and Backup DR fields of the MDR-DD TLV are set exactly the same as the DR and Backup DR fields of a Hello sent on the same interface.
隣人状態がのExStartであれば、標準の初期化パケットは、LLS使用して付加MDR-DD TLVで送信され、LビットがDDパケットのオプションフィールドに設定されています。 MDR-DD TLVのフォーマットは、セクションA.2.4で指定されています。 DR及びハローのバックアップDRフィールドが同じインターフェイス上で送信されたDRとMDR-DD TLVのバックアップDRフィールドは正確に同じに設定されています。
Processing a DD packet received on a MANET interface is the same as [RFC2328], Section 10.6, except for the changes described in this section. The following additional steps are performed before processing the packet based on neighbor state in paragraph 3 of Section 10.6.
MANETインターフェイスで受信DDパケットを処理することは、このセクションで説明する変更点を除いて、[RFC2328]、セクション10.6、同じです。次の追加手順は、10.6節の第3項に隣人状態に基づいてパケットを処理する前に実行されます。
o If the DD packet's L bit is set in the options field and an MDR-DD TLV is appended, then the MDR-DD TLV is processed as follows.
DDパケットのLビットがオプションフィールドに設定されており、MDR-DD TLVが添付されている場合は次のようにO、次いでMDR-DD TLVが処理されます。
(1) If the DR field is equal to the neighbor's Router ID:
（1）DRフィールドが隣人のルータIDに等しい場合。
(a) Set the MDR Level of the neighbor to MDR.
（a）はMDRへの隣人のMDRレベルを設定します。
(b) Set the neighbor's Dependent Selector variable to 1.
（b）は1に隣人の従属セレクター変数を設定します。
(2) Else if the Backup DR field is equal to the neighbor's Router ID:
（2）それ以外のバックアップDRフィールドが隣人のルータIDと等しい場合：
(a) Set the MDR Level of the neighbor to Backup MDR.
（a）はバックアップMDRに隣人のMDRレベルを設定します。
(b) Set the neighbor's Dependent Selector variable to 1.
（b）は1に隣人の従属セレクター変数を設定します。
(3) Else:
（3）他に：
(a) Set the MDR Level of the neighbor to MDR Other.
（a）はMDRその他の近隣のMDRレベルを設定します。
(b) Set the neighbor's Dependent Neighbor variable to 0.
（b）は0に隣人の従属ネイバー変数を設定します。
(4) If the DR or Backup DR field is equal to the router's own Router ID, set the neighbor's Child variable to 1; otherwise, set it to 0.
（4）DRまたはバックアップDRフィールドは、ルータ自身のルータIDに等しい場合、1に隣人の子変数を設定します。それ以外の場合は、0に設定します。
o If the neighbor state is Init, the neighbor event 2-WayReceived is executed.
O隣接状態は、init、2-WayReceivedが実行された隣接イベントである場合。
o If the MDR Level of the neighbor changed, the neighbor state machine is scheduled with the event AdjOK?.
隣人のMDRレベルが変更された場合、O、ネイバーステートマシンは、イベントAdjOKで予定されています？。
o If the neighbor's Child status has changed from 0 to 1, the neighbor state machine is scheduled with the event AdjOK?.
隣人の子供の状態が0から1に変更されている場合は、O、ネイバーステートマシンは、イベントAdjOKで予定されています？。
o If the neighbor's neighbor state changed from less than 2-Way to 2-Way or greater, the neighbor state machine is scheduled with the event AdjOK?.
隣の隣の状態が2ウェイ以上に2ウェイ未満から変更した場合は、O、ネイバーステートマシンは、イベントAdjOKで予定されています？。
In addition, the Database Exchange optimization described in [RFC5243] SHOULD be performed as follows. If the router accepts a received DD packet as the next in sequence, the following additional step should be performed for each LSA listed in the DD packet (whether the router is master or slave). 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. This avoids listing the LSA in a DD packet sent to the neighbor, when the neighbor already has an instance of the LSA that is the same or more recent. This optimization reduces overhead due to DD packets by approximately 50% in large networks.
次のように加えて、[RFC5243]に記載のデータベース交換の最適化を行うべきです。ルータは、シーケンス内の次のような受信されたDDパケットを受け入れた場合、次の追加のステップは、（ルータがマスターかスレーブか）DDパケットにリストされた各LSAのために行われるべきです。 Database概要リストがリストされたLSAよりも最近のと同じかそれ以下であるLSAのインスタンスが含まれている場合は、LSAは、Database概要リストから削除されます。これは、ネイバーがすでに同じか、より最近でLSAのインスタンスを持っている場合、ネイバーに送信DDパケット内のLSAを一覧避けることができます。この最適化は、大規模なネットワークでは約50％DDパケットによるオーバーヘッドを軽減します。
This section specifies the changes to [RFC2328], Section 13, for routers that support OSPF-MDR. The first part of Section 13 (before Section 13.1) is the same except for the following three changes.
このセクションでは、OSPF-MDRをサポートするルータの[RFC2328]、セクション13、への変更を指定します。 （セクション13.1の前に）セクション13の最初の部分は、次の3つの変更点を除いて同じです。
o To exploit the broadcast nature of MANETs, if the Link State Update (LSU) packet was received on a MANET interface, then the packet is dropped without further processing only if the sending neighbor is in a lesser state than 2-Way. Otherwise, the LSU packet is processed as described in this section.
リンク状態更新（LSU）パケットがMANETインタフェース上で受信された場合、アドホックネットワークにおけるブロードキャストの性質を利用するために、Oは、パケットは送信ネイバーが2ウェイよりも少ない状態にある場合にのみ、さらなる処理なしでドロップされます。このセクションで説明するようにそれ以外の場合は、LSUパケットが処理されます。
o If the received LSA is the same instance as the database copy, the following actions are performed in addition to Step 7. For each MANET interface for which a BackupWait Neighbor List exists for the LSA (see Section 8.1):
受信したLSAはデータベースコピーと同じインスタンスである場合、O、以下のアクションがBackupWait隣接リストは、LSA（8.1節を参照）のために存在する各MANETインタフェース7.ステップに加えて実行されます。
(a) Remove the sending neighbor from the BackupWait Neighbor List if it belongs to the list.
それはリストに属している場合（a）はBackupWaitの近隣リストから送付隣人を削除します。
(b) For each neighbor on the receiving interface that belongs to the BNS for the sending neighbor, remove the neighbor from the BackupWait Neighbor List if it belongs to the list.
それはリストに属している場合（b）の送信のために隣接BNSに属する受信インタフェース上の各隣接について、BackupWait隣接リストからネイバーを削除します。
o Step 8, which handles the case in which the database copy of the LSA is more recent than the received LSA, is modified as follows. If the sending neighbor is in a lesser state than Exchange, then the router does not send the LSA back to the sending neighbor.
次のようにLSAのデータベースのコピーを受信LSAより最近である場合を扱うOステップ8は、修飾されています。送付隣人がExchangeよりも低い状態にある場合、ルータは、送信ネイバーにLSAを返送しません。
There are no changes to Sections 13.1, 13.2, or 13.4. The following subsections describe the changes to Sections 13.3 (Next step in the flooding procedure), 13.5 (Sending Link State Acknowledgments), 13.6 (Retransmitting LSAs), and 13.7 (Receiving Link State Acknowledgments) of [RFC2328].
セクション13.1、13.2、13.4に変更はありません。以下のサブセクションは、セクション13.3に変化する（フラッディング手順の次のステップ）、13.5（リンク状態の確認応答を送信する）、13.6（再送のLSA）を記述し、13.7（受信リンク状態謝辞）[RFC2328]。
When a new LSA is received, Steps 1 through 5 of [RFC2328], Section 13.3, are performed without modification for each eligible (outgoing) interface that is not of type MANET. This section specifies the modified steps that must be performed for each eligible MANET interface. The eligible interfaces depend on the LSA's flooding scope as described in [RFC5340], Section 4.5.2. Whenever an LSA is flooded out a MANET interface, it is included in an LSU packet that is sent to the multicast address AllSPFRouters. (Retransmitted LSAs are always unicast, as specified in Section 8.3.)
新しいLSAを受信したとき、5 [RFC2328]、セクション13.3を介して1ステップ、型MANETではない各対象（発信）インターフェイスの変更を加えることなく行われます。このセクションでは、各適格MANETインターフェイスに対して実行されなければならない変更の手順を指定します。 [RFC5340]、セクション4.5.2に記載したように対象のインターフェイスはLSAの氾濫範囲に依存します。 LSAは、MANETインターフェイスをフラッディングされるたびに、それがマルチキャストアドレスAllSPFRoutersに送信されLSUパケットに含まれています。 （セクション8.3で指定されるように再送LSAは、常にユニキャストです。）
Step 1 of [RFC2328], Section 13.3, is performed for each eligible MANET interface with the following modification, so that the new LSA is placed on the Link State retransmission list for each appropriate adjacent neighbor. Step 1c is replaced with the following action, so that the LSA is not placed on the retransmission list for a neighbor that has already acknowledged the LSA.
新しいLSAがそれぞれ適切な隣接ネイバーのリンクステート再送リストに配置されるように[RFC2328]、セクション13.3、工程1は、以下の変更を加えた各対象MANETインターフェースに対して行われます。 LSAはすでにLSAを認めている隣人のために再送信リストの上に置かれないように、ステップ1cは、次のアクションに置き換えられます。
o If the new LSA was received from this neighbor, or a Link State Acknowledgment (LS Ack) for the new LSA has already been received from this neighbor, examine the next neighbor.
O新しいLSAがこのネイバーから受信した、または新しいLSAのためのリンクステート確認応答（LS ACK）は、すでに次の隣人を調べて、このネイバーから受信された場合。
To determine whether an Ack for the new LSA has been received from the neighbor, the router maintains an Acked LSA List for each adjacent neighbor, as described in Section 8.4. When a new LSA is received, the Acked LSA List for each neighbor, on each MANET interface, should be updated by removing any LS Ack that is for an older instance of the LSA than the one received.
セクション8.4で説明したように、新しいLSAに対するACKが隣人から受信されたかどうかを決定するために、ルータは、各隣接ネイバーのためにACKさLSAリストを維持します。各隣人のための新しいLSAが受信され、ACKさLSAのリスト、各MANETインタフェース上で、1は、受信よりもLSAの古いインスタンスの任意のLS ACKを除去することにより、更新する必要があります。
The following description will use the notion of a "covered" neighbor. A neighbor k is defined to be covered if the LSA was sent as a multicast by a MANET neighbor j, and neighbor k belongs to the Bidirectional Neighbor Set (BNS) for neighbor j. A neighbor k is also defined to be covered if the LSA was sent to the multicast address AllSPFRouters by a neighbor j on a broadcast interface on which both j and k are neighbors. (Note that j must be the DR or Backup DR for the broadcast network, since only these routers may send LSAs to AllSPFRouters on a broadcast network.)
以下の説明は、「カバー」隣人の概念を使用します。隣接kは、LSAがMANETネイバーjによってマルチキャストとして送信し、隣接kは隣接jに対して双方向隣接セット（BNS）に属する場合に覆われるように定義されます。隣接kはまた、LSAは、jおよびkの両方が隣人されたブロードキャストインターフェース上の隣接jによってマルチキャストアドレスAllSPFRoutersに送信された場合に覆われるように定義されます。 （のみこれらのルータはブロードキャストネットワーク上のAllSPFRoutersにLSAを送信することがあるため、そのjはDRまたはブロードキャストネットワークのバックアップDRでなければなりません。）
The following steps must be performed for each eligible MANET interface, to determine whether the new LSA should be forwarded on the interface.
次の手順は、新しいLSAがインターフェイスに転送する必要があるかどうかを判断するために、各適格MANETインタフェースのために実行する必要があります。
(2) If every bidirectional neighbor on the interface satisfies at least one of the following three conditions, examine the next interface (the LSA is not flooded out this interface).
インターフェイス満足にすべての双方向隣接以下の3つの条件の少なくとも一方が、次のインタフェースを調べると（2）（LSAは、このインターフェイスをフラッディングされていません）。
(a) The LSA was received from the neighbor.
（A）LSAは、ネイバから受信されました。
(b) The LSA was received on a MANET or broadcast interface and the neighbor is covered (defined above).
（B）LSAは、MANETまたはブロードキャストインターフェース上で受信し、隣人が（上記に定義）覆われています。
(c) An Ack for the LSA has been received from the neighbor.
（C）LSAのためのアンACKがネイバーから受信されています。
Condition (c) MAY be omitted (thus ignoring Acks) in order to
simplify this step. Note that the above conditions do not
assume the outgoing interface is the same as the receiving
interface.
(3) If the LSA was received on this interface, and the router is an MDR Other for this interface, examine the next interface (the LSA is not flooded out this interface).
LSAは、このインターフェイス上で受信し、ルータはこのインターフェイスのためのMDRその他の場合（3）、次のインタフェースを調べる（LSAは、このインターフェイスをフラッディングされていません）。
(4) If the LSA was received on this interface, and the router is a Backup MDR or a non-flooding MDR for this interface, then the router waits BackupWaitInterval before deciding whether to flood the LSA. To accomplish this, the router creates a BackupWait Neighbor List for the LSA, which initially includes every bidirectional neighbor on this interface that does not satisfy any of the conditions in Step 2. A single-shot BackupWait Timer associated with the LSA is started, which is set to expire after BackupWaitInterval seconds plus a small amount of random jitter. (The actions performed when the BackupWait Timer expires are described below in Section 8.1.2.) Examine the next interface (the LSA is not yet flooded out this interface).
LSAは、このインターフェイス上で受信し、ルータがバックアップMDRまたはこのインタフェースの非フラッディングMDR（4）である場合、ルータはLSAをフラッディングするかどうかを決定する前にBackupWaitIntervalを待ちます。これを実現するために、ルータは、最初にLSAに関連したシングルショットBackupWaitタイマーが開始され、ステップ2での条件のいずれかを満たしていない、このインターフェイス上のすべての双方向の隣人を含んLSA、用BackupWaitの近隣リストを作成しますBackupWaitInterval秒プラスランダム・ジッタの少量の後に期限切れになるように設定されています。 （BackupWaitタイマが満了したときに実行されるアクションは、セクション8.1.2で説明されている。）は、次のインターフェースを（LSAはまだ、このインターフェイスをフラッディングされていない）を調べます。
(5) If the router is a flooding MDR for this interface, or if the LSA was originated by the router itself, then the LSA is flooded out the interface (whether or not the LSA was received on this interface) and the next interface is examined.
（5）ルータは、このインターフェイスのフラッディングMDRである、またはLSAは、ルータ自体によって発信された場合、LSAは、インターフェイスをフラッディングされる（LSAは、このインターフェイス上で受信されたか否か）、次のインタフェースがある場合調べました。
(6) If the LSA was received on a MANET or broadcast interface that is different from this (outgoing) interface, then the following two steps SHOULD be performed to avoid redundant flooding.
LSAは、この（発信）インタフェースとは異なるMANETまたはブロードキャストインターフェース上で受信された場合（6）は、次の2つのステップは、冗長なフラッディングを回避するために行われるべきです。
(a) If the router has a larger value of (RtrPri, MDR Level, RID) on the outgoing interface than every covered neighbor (defined above) that is a neighbor on BOTH the receiving and outgoing interfaces (or if no such neighbor exists), then the LSA is flooded out the interface and the next interface is examined.
（a）は、ルータは、受信および発信両方のインターフェイスに隣接している（上記に定義）ごとに覆わ隣接より発信インターフェイス上で（RtrPri、MDRレベル、RID）の大きな値を有する場合（またはそのようなネイバーが存在しない場合） 、次にLSAインターフェイスをフラッディングされ、次のインタフェースが検査されます。
(b) Else, the router waits BackupWaitInterval before deciding whether to flood the LSA on the interface, by performing the actions in Step 4 for a Backup MDR (whether or not the router is a Backup MDR on this interface). A separate BackupWait
（B）そうでなければ、ルータは、（ルータがこのインターフェイス上でバックアップMDRであるか否か）バックアップMDRのためのステップ4の操作を行うことにより、インターフェイス上のLSAをフラッディングするかどうかを決定する前にBackupWaitIntervalを待ちます。別のBackupWait
Neighbor List is created for each MANET interface, but only
one BackupWait Timer is associated with the LSA. Examine the
next interface (the LSA is not yet flooded out this
interface).
(7) If this step is reached, the LSA is flooded out the interface.
このステップに達した場合（7）、LSAインターフェイスをフラッディングされます。
Performing the optional Step 6 can greatly reduce flooding overhead if the LSA was received on a MANET or broadcast interface. For example, assume that the LSA was received from the DR of a broadcast network that includes 100 routers, and 50 of the routers (not including the DR) are also attached to a MANET. Assume that these 50 routers are neighbors of each other in the MANET and that each has a neighbor in the MANET that is not attached to the broadcast network (and is therefore not covered). Then by performing Step 6 of the LSA forwarding procedure, the number of routers that forward the LSA from the broadcast network to the MANET is reduced from 50 to just 1 (assuming that at most 1 of the 50 routers is an MDR).
LSAは、MANETまたはブロードキャストインターフェース上で受信された場合、オプションのステップ6を実行すると、大幅にフラッディングオーバーヘッドを低減することができます。例えば、LSA 100台のルータを含み、そして（DR含まない）ルータ50はまた、MANETに接続されているブロードキャストネットワークのDRから受信されたと仮定する。これらの50台のルータは、MANET内の互いに隣接していると仮定し、それぞれが、ブロードキャストネットワークに接続されていない（したがって、カバーされていない）MANETにおける隣接を持っていること。次いで、LSA転送手順のステップ6を実行することによって、MANETにブロードキャストネットワークからLSAを転送するルータの数はわずか1（50台のルータの多くとも1 MDRであると仮定して）50から低減されます。
If the BackupWait Timer for an LSA expires, then the following steps are performed for each (MANET) interface for which a BackupWait Neighbor List exists for the LSA.
LSA用BackupWaitタイマが満了した場合、次のステップはBackupWait隣接リストは、LSAのために存在する各（MANET）インターフェースに対して行われます。
(1) If the BackupWait Neighbor List for the interface contains at least one router that is currently a bidirectional neighbor, the following actions are performed.
インタフェースのためのBackupWaitの近隣リストは、現在、双方向の隣人である少なくとも一つのルータが含まれている場合（1）、以下のアクションが実行されます。
(a) The LSA is flooded out the interface.
（A）LSAは、インターフェイスをフラッディングされます。
(b) If the LSA is on the Ack List for the interface (i.e., is scheduled to be included in a delayed Link State Acknowledgment packet), then the router SHOULD remove the LSA from the Ack List, since the flooded LSA will be treated as an implicit Ack.
浸水LSAが扱われますので、（b）のLSAがインターフェイスのためのAckリスト上にある場合（すなわち、遅れたリンクステート確認応答パケットに含まれる予定です）、ルータは、AckをリストからLSAを削除する必要があります暗黙のACKと。
(c) If the LSA is on the Link State retransmission list for any neighbor, the retransmission SHOULD be rescheduled to occur after RxmtInterval seconds.
（C）LSAは、すべての隣人のためにリンクステート再送リストに記載されている場合、再送信はRxmtInterval秒後に発生するために再スケジュールされるべきである（SHOULD）。
(2) The BackupWait Neighbor List is then deleted (whether or not the LSA is flooded).
（2）BackupWait隣接リストは、その後、（LSAがフラッディングされたか否か）が削除されています。
This section describes the procedure for sending Link State Acknowledgments (LS Acks) on MANET interfaces. Section 13.5 of [RFC2328] remains unchanged for non-MANET interfaces, but does not apply to MANET interfaces. To minimize overhead due to LS Acks, and to take advantage of the broadcast nature of MANETs, all LS Ack packets sent on a MANET interface are multicast using the IP address AllSPFRouters. In addition, duplicate LSAs received as a multicast are not acknowledged.
このセクションでは、MANETインターフェイスでリンクステート謝辞（LS ACKを）送信するための手順を記載しています。 [RFC2328]のセクション13.5は非MANETインタフェースの変更されないまま、しかしMANETインターフェイスには適用されません。原因LSのAcksをするオーバーヘッドを最小限にするために、そしてアドホックネットワークにおけるのブロードキャスト性を利用するために、すべてのIPアドレスAllSPFRoutersを使用して、マルチキャストMANETインターフェイス上で送信されたACKパケットをされているLS。また、マルチキャストとして受け取っ重複LSAは認められていません。
When a router receives an LSA, it must decide whether to send a delayed Ack, an immediate Ack, or no Ack. The interface parameter AckInterval is the interval between LS Ack packets when only delayed Acks need to be sent. A delayed Ack SHOULD be delayed by at least (RxmtInterval - AckInterval - 0.5) seconds and at most (RxmtInterval - 0.5) seconds after the LSA instance being acknowledged was first received. If AckInterval and RxmtInterval are equal to their default values of 1 and 7 seconds, respectively, this reduces Ack traffic by increasing the chance that a new instance of the LSA will be received before the delayed Ack is sent. An immediate Ack is sent immediately in a multicast LS Ack packet, which may also include delayed Acks that were scheduled to be sent.
ルータがLSAを受信すると、それは遅延ACK、即時ACK、または全くACKを送信するかどうかを決定する必要があります。だけ遅延ACKが送信される必要がある場合インターフェイスパラメータAckIntervalはLS ACKパケット間の間隔です。 LSAインスタンスが確認された後に最初に受信された秒 - 秒と最も（0.5 RxmtInterval）で遅延ACKは、少なくとも（ - - AckInterval 0.5 RxmtInterval）だけ遅延されるべきです。 AckIntervalとRxmtIntervalは1と7秒のデフォルト値に等しい場合、それぞれ、これは遅延ACKが送信される前に、LSAの新しいインスタンスが受信される可能性を高めてACKトラフィックが減少します。即時ACKも送信されるようにスケジュールされた遅延ACKを含むことができるパケットのAckマルチキャストLSにすぐに送信されます。
The decision whether to send a delayed or immediate Ack depends on whether the received LSA is new (i.e., is more recent than the database copy) or a duplicate (the same instance as the database copy), and on whether the LSA was received as a multicast or a unicast (which indicates a retransmitted LSA). The following rules are used to make this decision.
遅延または即時ACKを送信するかどうかの決定は、受信したLSAは、新しい（つまり、データベースのコピーよりも新しい）または複製（データベースのコピーと同じインスタンス）であるかどうかについて、そしてLSAは次のように受け取られたかどうかに依存します（再送LSAを示す）マルチキャストまたはユニキャスト。次の規則は、この決定を行うために使用されています。
(1) If the received LSA is new, a delayed Ack is sent on each MANET interface associated with the area, unless the LSA is flooded out the interface.
受信されたLSAが新しい場合LSAインターフェイスをフラッディングされない限り、（1）、遅延ACKは、領域に関連付けられた各MANETのインターフェイス上で送信されます。
(2) If the LSA is a duplicate and was received as a multicast, the LSA is not acknowledged.
LSAが重複しているとマルチキャストとして受信された場合（2）、LSAは認めていません。
(3) If the LSA is a duplicate and was received as a unicast:
（3）LSAは、重複され、ユニキャストとして受信された場合。
(a) If the router is an MDR, or AdjConnectivity = 2 and the
router is a Backup MDR, or AdjConnectivity = 0, then an
immediate Ack is sent out the receiving interface.
(b) Otherwise, a delayed Ack is sent out the receiving interface.
（B）それ以外の場合は、遅延ACKは、受信インターフェースを送出します。
The reason that (Backup) MDRs send an immediate Ack when a retransmitted LSA is received is to try to prevent other adjacent neighbors from retransmitting the LSA, since (Backup) MDRs usually have a large number of adjacent neighbors. MDR Other routers do not send an immediate Ack (unless AdjConnectivity = 0) because they have fewer adjacent neighbors, and so the potential benefit does not justify the additional overhead resulting from sending immediate Acks.
再送されたLSAを受信したときに（バックアップ）のMDRは、即時ACKを送信する理由は、（バックアップ）のMDRは通常、隣接するネイバーの数が多いことから、LSAを再送から隣接する他の隣人を防ぐためにしようとすることです。 （AdjConnectivity = 0ない限り）彼らは少数の隣接している隣人を持っており、その潜在的な利益が即時ACKを送ることから生じる追加のオーバーヘッドを正当化していないため、MDR他のルータは即時ACKを送信しません。
LSAs are retransmitted according to Section 13.6 of [RFC2328]. Thus, LSAs are retransmitted only to adjacent routers. Therefore, since OSPF-MDR does not allow an adjacency to be formed between two MDR Other routers, an MDR Other never retransmits an LSA to another MDR Other, only to its Parents, which are (Backup) MDRs.
LSAは、[RFC2328]のセクション13.6に応じて再送されています。このように、LSAは唯一の隣接ルータに再送信されます。したがって、OSPF-MDRは、2つの隣接MDR他のルータとの間に形成されることを可能にしないので、MDRその他決してのみ（バックアップ）のMDRであるその親に、別のMDR他のLSAを再送しません。
Retransmitted LSAs are included in LSU packets that are unicast directly to an adjacent neighbor that did not acknowledge the LSA (explicitly or implicitly). The length of time between retransmissions is given by the configurable interface parameter RxmtInterval, whose default is 7 seconds for a MANET interface. To reduce overhead, several retransmitted LSAs should be included in a single LSU packet whenever possible.
再送されたLSAは（明示的または暗黙的に）LSAを認めなかった隣接の隣人に直接ユニキャストですLSUパケットに含まれています。再送信の間の時間の長さは、そのデフォルトMANETインターフェイスの7秒で設定可能なインタフェースパラメータRxmtInterval、によって与えられます。オーバーヘッドを減らすために、いくつかの再送LSAは、単一のLSUパケット可能な限りに含まれるべきです。
A Link State Acknowledgment (LS Ack) packet that is received from an adjacent neighbor (in state Exchange or greater) is processed as described in Section 13.7 of [RFC2328], with the additional steps described in this section. An LS Ack packet that is received from a neighbor in a lesser state than Exchange is discarded.
このセクションで説明する追加の手順を用いて、[RFC2328]のセクション13.7に記載されているように（状態所以上）に隣接する近隣から受信されたリンクステート確認応答（LS ACK）パケットを処理します。取引所よりも少ない状態で、ネイバーから受信されたLS ACKパケットが破棄されます。
Each router maintains an Acked LSA List for each adjacent neighbor, to keep track of any LSA instances the neighbor has acknowledged but that the router itself has NOT yet received. This is necessary because (unlike [RFC2328]) each router acknowledges an LSA only the first time it is received as a multicast.
各ルータは、隣人が認めているが、ルータ自体がまだ受信していないことをすべてのLSAインスタンスを追跡するために、各隣接隣人のためにACKさLSAのリストを維持します。 （とは異なりは[RFC2328]）は、各ルータがLSAそれはマルチキャストとして受信される最初の時間を認めるため、これが必要です。
If the neighbor from which the LS Ack packet was received is in state Exchange or greater, then the following steps are performed for each LS Ack in the received LS Ack packet:
LS Ackパケットが受信されたネイバー状態所以上である場合は、次の手順は、受信されたLS Ackパケットの各LS ACKを実行されます。
(1) If the router does not have a database copy of the LSA being acknowledged, or has a database copy that is less recent than the one being acknowledged, the LS Ack is added to the Acked LSA List for the sending neighbor.
ルータが認知されているLSAのデータベースのコピーを持っている、または認知されている1未満の最近のあるデータベースのコピーを持っていない場合は（1）、LS ACKは送信隣人のためにACKさLSAのリストに追加されます。
(2) If the router has a database copy of the LSA being acknowledged, which is the same as the instance being acknowledged, then the following action is performed. For each MANET interface for which a BackupWait Neighbor List exists for the LSA (see Section 8.1), remove the sending neighbor from the BackupWait Neighbor List if it belongs to the list.
ルータが認識されるインスタンスと同じで承認されてLSAのデータベースのコピーがある場合、（2）、次の動作が行われます。 BackupWait隣接リストは、LSAのために存在する各MANETインタフェースのためにそれがリストに属している場合、BackupWait隣接リストから送信ネイバーを削除する（8.1節参照）。
Unlike the DR of an OSPF broadcast network, an MDR does not originate a network-LSA, since a network-LSA cannot be used to describe the general topology of a MANET. Instead, each router advertises a subset of its MANET neighbors as point-to-point links in its router-LSA. The choice of which MANET neighbors to include in the router-LSA is flexible. Whether or not adjacency reduction is used, the router can originate either partial-topology or full-topology LSAs.
ネットワークLSAは、MANETの一般的なトポロジを記述するために使用することができないので、OSPFブロードキャストネットワークのDRとは異なり、MDRは、ネットワークLSAを発信しません。代わりに、各ルータは、そのルータLSAでのポイントツーポイントリンクとしてそのMANETネイバーのサブセットをアドバタイズします。 MANET隣人がルータ - LSAに含めるの選択が柔軟です。隣接減少が使用されているかどうかにかかわらず、ルータが部分的トポロジーまたはフルトポロジのLSAのいずれかを発信することができます。
If adjacency reduction is used (AdjConnectivity is 1 or 2), then as a minimum requirement each router must advertise a minimum set of "backbone" neighbors in its router-LSA. This minimum choice corresponds to LSAFullness = 0, and results in the minimum amount of LSA flooding overhead, but does not provide routing along shortest paths.
隣接還元が使用される場合（AdjConnectivityは1又は2である）、最小要件として、各ルータは、そのルータLSAの「バックボーン」隣人の最小セットをアドバタイズしなければなりません。この最小値選択はLSAFullness = 0に対応し、LSAフラッディングオーバーヘッドの最小量の結果が、最短経路に沿ってルーティングを提供しません。
Therefore, to allow routers to calculate shortest paths, without requiring every pair of neighboring routers along the shortest paths to be adjacent (which would be inefficient due to requiring a large number of adjacencies), a router-LSA may also advertise non-adjacent neighbors that satisfy a synchronization condition described below.
したがって、ルータは（これは隣接の多数を必要とするには非効率的であると思われる）隣接する最短経路に沿って隣接するルータのすべてのペアを必要とすることなく、最短経路を計算できるように、ルータLSAは、非隣接近隣を広告することができますそれは、以下に記載の同期条件を満たしています。
To motivate this, we note that OSPF already allows a non-adjacent neighbor to be a next hop, if both the router and the neighbor belong to the same broadcast network (and are both adjacent to the DR). A network-LSA for a broadcast network (which includes all routers attached to the network) implies that any router attached to the network can forward packets directly to any other router attached to the network (which is why the distance from the network to all attached routers is zero in the graph representing the link-state database).
これをやる気にさせる、我々は、ルータと隣人の両方が同じブロードキャストネットワークに属している（と両方のDRに隣接している）場合、OSPFはすでに、非隣接隣人がネクストホップにすることができますことに注意してください。ネットワークLSA（ネットワークに接続されているすべてのルータを含む）は、ブロードキャストネットワークのためには、ネットワークに接続されているすべてのルータは、すべてのネットワークからの距離が取り付け理由である（ネットワークに接続されているすべての他のルータにパケットを直接転送することができることを意味しますルータがリンクステートデータベースを示すグラフ）でゼロです。
Since a network-LSA cannot be used to describe the general topology of a MANET, the only way to advertise non-adjacent neighbors that can be used as next hops is to include them in the router-LSA. However, to ensure that such neighbors are sufficiently synchronized, only "routable" neighbors are allowed to be included in LSAs, and to be used as next hops in the SPF calculation.
ネットワークLSAは、MANETの一般的なトポロジを記述するために使用することはできませんので、ネクストホップとして使用できる非隣接している隣人を宣伝する唯一の方法は、ルータLSAでそれらを含めることです。しかし、そのような隣人が十分に同期されていることを確認するために、唯一の「ルーティング可能な」隣人はLSAの中に含まれることが許可されている、とSPF計算でネクストホップとして使用されるように。
If adjacency reduction is used, a bidirectional MANET neighbor becomes routable if the SPF calculation has found a route to the neighbor and the neighbor satisfies the routable neighbor quality condition (defined below). Since only routable and Full neighbors are advertised in router-LSAs, and since adjacencies are selected to form a connected spanning subgraph, this definition implies that there exists, or recently existed, a path of full adjacencies from the router to the routable neighbor. The idea is that, since a routable neighbor can be reached through an acceptable path, it makes sense to take a "shortcut" and forward packets directly to the routable neighbor.
隣接還元が使用される場合SPFの計算は隣人への経路を発見しており、隣人が（以下に定義）ルーティング可能な隣接品質条件を満たしている場合、双方向MANETネイバーがルーティング可能となります。のみルーティング可能とフルネイバーがルータのLSAでアドバタイズされており、隣接するので、接続にまたがる部分グラフを形成するために選択されているので、この定義は、ルーティング可能な隣人へのルータからの完全な隣接関係のパスが、そこに存在する、または最近存在していたことを意味します。アイデアは、ルーティング可能な隣人が許容可能な経路を通って到達することができるので、それは「ショートカット」を取ると、ルーティング可能な隣人に直接パケットを転送することは理にかなって、ということです。
This requirement does not guarantee perfect synchronization, but simulations have shown that it performs well in mobile networks. This requirement avoids, for example, forwarding packets to a new neighbor that is poorly synchronized because it was not reachable before it became a neighbor.
この要件は、完全な同期を保証するものではありませんが、シミュレーションでは、それは、モバイルネットワークでも実行することを示しています。この要件は、それが隣人になった前に、それが到達可能ではなかったので、悪い同期されている新しい隣人にパケットを転送する、例えば、避けることができます。
To avoid selecting poor-quality neighbors as routable neighbors, a neighbor that is selected as a routable neighbor must satisfy the routable neighbor quality condition. By default, this condition is that the neighbor's BNS must include the router itself (indicating that the neighbor agrees the connection is bidirectional). Optionally, a router may impose a stricter condition. For example, a router may require that two Hellos have been received from the neighbor that (explicitly or implicitly) indicate that the neighbor's BNS includes the router itself.
ルーティング可能な隣人としての質の悪い隣人を選択しないようにするには、ルーティング可能な隣人として選択された隣人は、ルーティング可能な隣人品質条件を満たさなければなりません。デフォルトでは、この条件は隣人のBNSは（隣人は接続が双方向で同意していることを示す）ルータ自体を含まなければならないということです。必要に応じて、ルータは、より厳しい条件を課すことができます。たとえば、ルータは2つのハローズが隣人のBNSは、ルータ自体が含まれていることを示している（明示的または暗黙的に）ことをネイバーから受信されていることを必要とするかもしれません。
The single-bit neighbor variable Routable indicates whether the neighbor is routable, and is initially set to 0. If adjacency reduction is used, Routable is updated as follows when the state of the neighbor changes, or the SPF calculation finds a route to the neighbor, or a Hello is received that affects the routable neighbor quality condition.
単一ビットの隣接変数ルーティング可能なネイバーの状態が変化し、またはSPFの計算は隣人へのルートを検出した場合、次のようにルーティング可能な更新され、ネイバーがルーティング可能であり、且つ隣接還元が使用される場合、最初に0に設定されているかどうかを示します、またはこんにちはルーティング可能な隣人品質条件に影響が受信されます。
(1) If Routable is 0 for the neighbor, the state of the neighbor is 2-Way or greater, there exists a route to the neighbor, and the routable neighbor quality condition (defined above) is satisfied, then Routable is set to 1 for the neighbor.
（1）ルーティング可能なネイバーのために0である場合に、ネイバーの状態は2ウェイである以上、近隣への経路が存在すると、（上記で定義した）ルーティング可能な隣接品質条件が満たされ、その後、ルーティング可能な1に設定されています隣人のために。
(2) If Routable is 1 for the neighbor and the state of the neighbor is less than 2-Way, Routable is set to 0 for the neighbor.
ルーティング可能なネイバーのための1であり、隣人の状態が2未満ウェイ（2）である場合、ルーティング可能に隣人のために0に設定されています。
If adjacency reduction is not used (AdjConnectivity = 0), then routable neighbors are not computed and the set of routable neighbors remains empty.
隣接還元が使用されていない場合（AdjConnectivity = 0）、次いで、ルーティング可能な近隣を計算し、ルーティング可能な近隣のセットが空のままされていません。
The flexible choice for the router-LSA is made possible by defining two types of neighbors that are included in the router-LSA: backbone neighbors and Selected Advertised Neighbors.
バックボーン隣人と選択したアドバタイズ隣人：ルータLSAのための柔軟な選択は、ルータLSAに含まれている隣人の2種類を定義することによって可能となります。
If adjacency reduction is used, a bidirectional neighbor is defined to be a backbone neighbor if and only if it satisfies the condition for becoming adjacent (see Section 7.2). If adjacency reduction is not used (AdjConnectivity = 0), a bidirectional neighbor is a backbone neighbor if and only if the neighbor's A-bit is 0 (indicating that the neighbor is using adjacency reduction). This definition allows the interoperation between routers that use adjacency reduction and routers that do not.
隣接還元が使用される場合、双方向ネイバーは、それが隣接なるための条件を満たしている場合にのみ基幹隣人であると定義される（セクション7.2参照）。隣接還元が使用されていない場合（AdjConnectivity = 0）、双方向の隣人は、隣人のAビットが0であれば（隣人が隣接還元を使用していることを示す）場合骨格隣人です。この定義は、隣接の減少とそうでないルータを使用するルータ間の相互運用を可能にします。
If adjacency reduction is used, then a router MUST include in its router-LSA all Full neighbors and all routable backbone neighbors. A minimal LSA, corresponding to LSAFullness = 0, includes only these neighbors. This choice guarantees connectivity, but does not ensure shortest paths. However, this choice is useful in large networks to achieve maximum scalability.
隣接削減が使用されている場合、ルータはそのルータLSA内のすべての完全な隣人や、すべてのルーティング可能なバックボーンネイバーを含まなければなりません。最小のLSAは、LSAFullness = 0に対応し、これらのみネイバーを含みます。この選択は、接続性を保証しますが、最短経路を保証するものではありません。しかし、この選択は最大のスケーラビリティを実現するために大規模なネットワークに有用です。
To allow flexibility while ensuring that router-LSAs are symmetric (i.e., router i advertises a link to router j if and only if router j advertises a link to router i), each router maintains a Selected Advertised Neighbor set (SANS), which consists of MANET neighbors that the router has selected to advertise in its router-LSA, not including backbone neighbors. Since the SANS does not include backbone neighbors (and thus Dependent Neighbors), the SANS and DNS are disjoint. Both of these neighbor sets are advertised in Hellos.
そのルータLSAを確保しながら柔軟性を許可するには（すなわち、ルータiのルータjが私のルータへのリンクをアドバタイズ場合に限り、ルータjへのリンクをアドバタイズ）対称である、各ルータが構成されて選択されたアドバタイズ近隣セット（SANS）を、維持しますMANETネイバーのルータがバックボーン隣人を含まない、そのルータLSAで広告を掲載するために選択したこと。 SANSは、バックボーン・ネイバー（ひいては依存隣人）が含まれていませんので、SANSとDNSは互いに素です。これらのネイバーセットの両方がハローズで宣伝されています。
If LSAFullness is 0 (minimal LSAs), then the SANS is empty. At the other extreme, if LSAFullness is 4 (full-topology LSAs), the SANS includes all bidirectional MANET neighbors except backbone neighbors. In between these two extremes, a router that is using adjacency reduction may select any subset of bidirectional non-backbone neighbors as its SANS. The resulting router-LSA is constructed as specified in Section 9.4.
LSAFullnessは0（最小限のLSA）の場合は、SANSは空です。 LSAFullnessは4（フルトポロジのLSA）であれば、他の極端な、SANSは、バックボーンの隣人を除くすべての双方向MANETネイバーを含んでいます。これらの2つの両極端の間では、隣接削減を使用しているルータは、そのSANSなど双方向の非バックボーン隣人の任意のサブセットを選択することができます。 9.4節で指定されたルータLSAが構築されます。
Since a router that is not using adjacency reduction typically has no backbone neighbors (unless it has neighbors that are using adjacency reduction), to ensure connectivity, such a router must choose its SANS to contain the SANS corresponding to LSAFullness = 1. Thus, if AdjConnectivity is 0 (no adjacency reduction), then LSAFullness must be 1, 2, or 4.
通常、隣接の減少を使用していないルータがあれば、接続性を確保するために、（それは隣接の減少を使用している隣人を持っていない限り）、そのようなルータはこのようにLSAFullness = 1に対応するSANSを含むようにそのSANSを選択しなければならないというバックボーン隣人を持っていないので、 AdjConnectivityは、0（なし隣接減少）で、次いでLSAFullnessは、1,2、または4でなければなりません。
If LSAFullness is 1, the router originates min-cost LSAs, which are partial-topology LSAs that (when flooded) provide each router with sufficient information to calculate a shortest (minimum-cost) path to each destination. Appendix C describes the algorithm for selecting the neighbors to include in the SANS that results in min-cost LSAs. The input to this algorithm includes information obtained from Hellos received from each MANET neighbor, including the neighbor's Bidirectional Neighbor Set (BNS), Dependent Neighbor Set (DNS), Selected Advertised Neighbor Set (SANS), and the Metric TLV. The Metric TLV, specified in Section A.2.5, is appended to each Hello (unless all link costs are 1) to advertise the link cost to each bidirectional neighbor.
LSAFullnessが1である場合、ルータは（フラッディング）部分トポロジーのLSAである最小コストLSAを、発信各宛先への最短（最小コスト）経路を計算するために十分な情報を各ルータを提供します。付録Cは最小コストのLSAになりSANSに含める隣人を選択するためのアルゴリズムを説明します。このアルゴリズムへの入力はハローズから得られた情報は、隣人の双方向隣接セット（BNS）、依存隣接セット（DNS）、選択されたアドバタイズ隣接セット（SANS）、及びメトリックTLVを含む、各MANETネイバーから受信含みます。 （全てのリンクのコストが1でない限り）セクションA.2.5で指定されたメトリックTLVは、それぞれ双方向ネイバーにリンクコストを宣伝するために、各こんにちはに追加されます。
If LSAFullness is 2, the SANS must be selected to be a superset of the SANS corresponding to LSAFullness = 1. This choice provides shortest-path routing while allowing the router to advertise additional neighbors to provide redundant routes.
LSAFullnessが2の場合、SANSは、この選択は、冗長経路を提供するために、追加の隣人をアドバタイズするようにルータを可能にしながら、ルーティング最短パスを提供LSAFullness = 1に対応するSANSのスーパーセットであるように選択されなければなりません。
If LSAFullness is 3, each MDR originates a full-topology LSA (which includes all Full and routable neighbors), while each non-MDR router originates a minimal LSA. If the router has multiple MANET interfaces, the router-LSA includes all Full and routable neighbors on each interface for which it is an MDR, and advertises only Full neighbors and routable backbone neighbors on its other interfaces. This choice provides routing along nearly shortest paths with relatively low overhead.
LSAFullnessが3である場合、各非MDRルータが最小LSAを発信しつつ、各MDRは、（すべてのフルおよびルーティング可能な近隣を含む）フルトポロジLSAを発信します。ルータが複数MANETインタフェースを有する場合、ルータLSAは、MDRされた各インタフェース上のすべての本文とルーティング可能なネイバーを含み、その他のインターフェイスにのみフルネイバーとルーティング可能な骨格ネイバーアドバタイズ。この選択は、比較的低いオーバーヘッドでほぼ最短経路に沿ってルーティングを提供します。
Although this document specifies a few choices of the SANS, which correspond to different values of LSAFullness, it is important to note that other choices are possible. In addition, it is not necessary for different routers to choose the same value of LSAFullness. The different choices are interoperable because they all require the router-LSA to include a minimum set of neighbors, and because the construction of the router-LSA (described below) ensures that the router-LSAs originated by different routers are consistent.
この文書はLSAFullnessの異なる値に対応SANSのいくつかの選択肢を、指定しますが、他の選択肢が可能であることに注意することが重要です。別のルータがLSAFullnessの同じ値を選択するために加えて、それは必要ありません。それらはすべての隣人の最小セットを含むようにルータLSAを必要とするため、異なる選択肢が相互運用可能であり、そしてのでルータLSA（後述）の構成が異なるルータによって発信ルータのLSAが一貫していることを保証します。
When a new router-LSA is originated, it includes a point-to-point (type 1) link for each MANET neighbor that is advertised. The set of neighbors to be advertised is determined as follows. If adjacency reduction is used, the router advertises all Full neighbors, and advertises each routable neighbor j that satisfies any of the following three conditions. If adjacency reduction is not used (AdjConnectivity = 0), the router advertises each Full neighbor j that satisfies any of the following three conditions.
新しいルータLSAが発信されると、アドバタイズされた各MANETネイバーのためのポイント・ツー・ポイント（タイプ1）リンクを含みます。隣人のセットは以下のように決定された広告します。隣接削減が使用されている場合、ルータはすべてのフル隣人をアドバタイズし、次の3つの条件のいずれかを満たす各ルーティング可能な隣人jをアドバタイズします。隣接減少は（AdjConnectivity = 0）で使用されていない場合、ルータは次の3つの条件のいずれかを満たす各完全隣人jをアドバタイズします。
(1) The router's SANS (for any interface) includes j.
（1）（任意のインターフェイス用）ルータのSANSがjを含んでいます。
(2) Neighbor j's SANS includes the router (to ensure symmetry).
（2）近隣JのSANSは、ルータを含み（対称性を確保するため）。
(3) Neighbor j is a backbone neighbor.
（3）隣接jはバックボーン隣人です。
Note that backbone neighbors and neighbors in the SANS need not be routable or Full, but only routable and Full neighbors may be included in the router-LSA. This is done so that the SANS, which is advertised in Hellos, does not depend on routability.
なお、SANSのそのバックボーン隣人や近所のルーティング可能なまたは完全な、しかしのみルーティング可能とフルネイバーがルータ - LSAに含まれることができるである必要はありません。ハローズで宣伝されSANSは、ルーティング性に依存しないようにするためです。
The events that cause a new router-LSA to be originated are the same as in [RFC2328] and [RFC5340] except that a MANET neighbor changing to/from the Full state does not always cause a new router-LSA to be originated. Instead, a new router-LSA is originated whenever a change occurs that causes any of the following three conditions to occur:
新しいルータLSAが発信させるイベントがに/フルの状態から変更MANETの隣人は、常に新しいルータLSAが発信されることはありませんことを除いて、[RFC2328]と[RFC5340]と同じです。代わりに、新しいルータLSAは、変更は次の3つの条件のいずれかが発生する原因となる発生したときに発信されます。
o There exists a MANET neighbor j that satisfies the above conditions for inclusion in the router-LSA, but is not included in the current router-LSA.
Oが存在ルータLSAに含めるため、上記の条件を満たしているMANETの隣人jを存在するが、現在のルータ - LSAには含まれていません。
o The current router-LSA includes a MANET neighbor that is no longer bidirectional.
O現在のルータ - LSAは、もはや双方向であるMANETの隣人を含んでいます。
o The link metric has changed for a MANET neighbor that is included in the current router-LSA.
Oリンクメトリックは、現在のルータ - LSAに含まれているMANETの隣人のために変更されました。
The above conditions may be checked periodically just before sending each Hello, instead of checking them every time one of the neighbor sets changes. The following implementation was found to work well. Just before sending each Hello, and whenever a bidirectional neighbor transitions to less than 2-Way, the router runs the MDR selection algorithm; updates its adjacencies, routable neighbors, and Selected Advertised Neighbors; then checks the above conditions to see if a new router-LSA should be originated. In addition, if a neighbor becomes bidirectional or Full, the router updates its routable neighbors and checks the above conditions.
上記の条件は、単に各こんにちは送るのではなく、それらを隣人のいずれかが変更を設定するたびにチェックする前に定期的にチェックすることができます。次の実装はうまく機能することが分かりました。ただ、2未満ウェイへこんにちはそれぞれを送信すると、いつでも双方向ネイバー移行する前に、ルータは、MDR選択アルゴリズムを実行します。その隣接、ルーティング可能な隣人、そして選択されたアドバタイズ隣人を更新します。その後、新しいルータ - LSAを発信する必要があるかどうかを確認するために、上記の条件をチェックします。ネイバーが双方向またはいっぱいになるとまた、ルータはルーティング可能な隣人を更新し、上記の条件をチェックします。
The routing table calculation is the same as specified in [RFC2328], except for the following changes to Section 16.1 (Calculating the shortest-path tree for an area). If full-topology adjacencies and full-topology LSAs are used (AdjConnectivity = 0 and LSAFullness = 4), there is no change to Section 16.1.
ルーティングテーブルの計算は（地域の最短パス木の計算）セクション16.1に次の変更を除いて、[RFC2328]で指定されたものと同じです。フルトポロジ隣接フルトポロジのLSAが使用される場合（AdjConnectivity = 0とLSAFullness = 4）、16.1項に変化はありません。
If adjacency reduction is used (AdjConnectivity is 1 or 2), then Section 16.1 is modified as follows. Recall from Section 9 that a router can use any routable neighbor as a next hop to a destination, whether or not the neighbor is advertised in the router-LSA. This is accomplished by modifying Step 2 so that the router-LSA associated with the root vertex is replaced with a dummy router-LSA that includes links to all Full neighbors and all routable MANET neighbors. In addition, Step 2b (checking for a link from W back to V) MUST be skipped when V is the root vertex and W is a routable MANET neighbor. However, Step 2b must still be executed when V is not the root vertex, to ensure compatibility with OSPFv3.
隣接還元が使用される場合、次のようにセクション16.1が変更される（AdjConnectivityは1又は2です）。ルータは隣接ルータ-LSAでアドバタイズされているか否かを、宛先へのネクストホップとして任意のルーティング可能な隣人を使用することができ、セクション9からリコール。これは、ルート頂点に関連付けられたルータLSAはすべてのフルネイバーおよびすべてルーティング可能MANETネイバーへのリンクを含むダミールータLSAで置換されているように、ステップ2を変更することによって達成されます。 Vがルート頂点であり、Wは、ルーティング可能なMANETネイバーである場合に加えて、ステップ2b（裏面VにWからのリンクをチェック）をスキップしなければなりません。 Vがルート頂点でない場合しかし、ステップ2bは依然としてのOSPFv3との互換性を確保するために、実行されなければなりません。
If LSAFullness is 0 (minimal LSAs), then the calculated paths need not be shortest paths. In this case, the path actually taken by a packet can be shorter than the calculated path, since intermediate routers may have routable neighbors that are not advertised in any router-LSA.
LSAFullnessは0（最小のLSA）である場合には、計算された経路は最短経路である必要はありません。中間ルータは、任意のルータLSAでアドバタイズされていないルーティング可能な近隣を有していてもよいので、この場合には、実際のパケットによって取られる経路は、計算された経路よりも短くすることができます。
If full-topology adjacencies and partial-topology LSAs are used, then Section 16.1 is modified as follows. Step 2 is modified so that the router-LSA associated with the root vertex is replaced with a dummy router-LSA that includes links to all Full neighbors. In addition, Step 2b MUST be skipped when V is the root vertex and W is a Full MANET neighbor. (This is necessary since the neighbor's router-LSA need not contain a link back to the router.)
フルトポロジ隣接及び部分トポロジーのLSAが使用される場合、次のようにセクション16.1が変更されます。根頂点に関連付けられているルータLSAがすべて完全隣人へのリンクが含まれてダミールータLSAに置き換えられるようにステップ2を変更したものです。また、Vは、ルート頂点である場合、ステップ2bはスキップされなければなりません、そして、Wは完全MANETネイバーです。 （ネイバーのルータLSAが戻ってルータへのリンクが含まれている必要がないので、これが必要です。）
If adjacency reduction is used with partial-topology LSAs, then the set of routable neighbors can change without causing the contents of the router-LSA to change. This could happen, for example, if a routable neighbor that was not included in the router-LSA transitions to the Down or Init state. Therefore, if the set of routable neighbors changes, the shortest-path tree must be recalculated, even if the router-LSA does not change.
隣接の減少は、部分トポロジーのLSAで使用されている場合は、ルーティング可能な隣人のセットは、ルータLSAの内容は変更させることなく、変更することができます。ルータLSAに含まれていませんでしたルーティング可能なネイバーがダウンまたは初期状態に遷移場合、これは、例えば、発生する可能性があります。そのため、ルーティング可能な隣人の変更のセットならば、最短パスツリーは、ルータLSAが変化していない場合でも、再計算されなければなりません。
After the shortest-path tree and routing table are calculated, the set of routable neighbors must be updated, since a route to a non-routable neighbor may have been discovered. If the set of routable neighbors changes, then the shortest-path tree and routing table must be calculated a second time. The second calculation will not change the set of routable neighbors again, so two calculations are sufficient. If the set of routable neighbors is updated periodically every HelloInterval seconds, then it is not necessary to update the set of routable neighbors immediately after the routing table is updated.
最短パスツリーとルーティングテーブルが計算された後、ルーティング不可能な隣人へのルートが発見されている可能性があるため、ルーティング可能な隣人のセットは、更新する必要があります。ルーティング可能な近隣のセットが変更された場合、最短パス木とルーティングテーブルは、第二の時間を計算しなければなりません。第2の算出は再びルーティング可能なネイバーのセットを変更しないので、2回の計算で十分です。ルーティング可能な隣人のセットは、定期的にすべてのHelloIntervalが後援を更新した場合、ルーティングテーブルが更新された直後にルーティング可能なネイバーのセットを更新する必要はありません。
As with OSPFv3 [RFC5340], OSPF-MDR can use the IPv6 Authentication Header (AH) [RFC4302] and/or the IPv6 Encapsulation Security Payload (ESP) [RFC4303] to provide authentication, integrity, and/or confidentiality. The use of AH and ESP for OSPFv3 is described in [RFC4552].
OSPFv3の[RFC5340]と同様に、OSPF-MDRは、認証、整合性、および/または機密性を提供するために、IPv6の認証ヘッダー（AH）[RFC4302]および/またはIPv6カプセル化セキュリティペイロード（ESP）[RFC4303]を使用することができます。 OSPFv3のためのAHとESPの使用は、[RFC4552]に記載されています。
Generic threats to routing protocols are described and categorized in [RFC4593]. The mechanisms described in [RFC4552] provide protection against many of these threats, but not all of them. In particular, as mentioned in [RFC5340], these mechanisms do not provide protection against compromised, malfunctioning, or misconfigured routers (also called Byzantine routers); this is true for both OSPFv3 and OSPF-MDR.
ルーティングプロトコルへの一般的な脅威について説明し、[RFC4593]に分類されます。 [RFC4552]で説明されたメカニズムは、それらのすべてのこれらの脅威の多くではなくに対する保護を提供します。具体的には、[RFC5340]で述べたように、これらの機構が損なわれ、誤動作、または誤って設定ルータ（別名ビザンチンルータ）に対する保護を提供しません。これは、OSPFv3のOSPFと-MDRの両方に当てはまります。
The extension of OSPFv3 to include MANET routers does not introduce any new security threats. However, the use of a wireless medium and lack of infrastructure, inherent with MANET routers, may render some of the attacks described in [RFC4593] easier to mount. Depending on the network context, these increased vulnerabilities may increase the need to provide authentication, integrity, and/or confidentiality, as well as anti-replay service.
MANETルータを含めることのOSPFv3の拡張は、新たなセキュリティの脅威を導入していません。しかし、MANETルータに固有の無線媒体とインフラの欠如の使用は、[RFC4593]マウントする方が簡単に説明された攻撃の一部をレンダリングすることがあります。ネットワークの状況に応じて、これらの増加の脆弱性は、認証、整合性、および/または機密性だけでなく、アンチリプレイサービスを提供する必要性を増大させることができます。
For example, sniffing of routing information and traffic analysis are easier tasks with wireless routers than with wired routers, since the attacker only needs to be within the radio range of a router. The use of confidentiality (encryption) provides protection against sniffing but not traffic analysis.
攻撃者のみルータの無線範囲内にする必要があるため、例えば、有線ルータよりも無線ルータとの簡単なタスクは、情報及びトラフィック分析をルーティングさスニッフィング。機密性（暗号化）を使用すると、トラフィック分析を盗聴ではなくに対する保護を提供します。
Similarly, interference attacks are also easier to mount against MANET routers due to their wireless nature. Such attacks can be mounted even if OSPF packets are protected by authentication and confidentiality, e.g., by transmitting noise or replaying outdated OSPF packets. As discussed below, an anti-replay service (provided by both ESP and AH) can be used to protect against the latter attack.
同様に、干渉攻撃も、ワイヤレス性質に起因MANETルータに対してマウントするのが容易です。このような攻撃は、OSPFパケットがノイズを送信または古いOSPFパケットを再生することによって、例えば、認証および機密性によって保護されていても実装することができます。以下に説明するように、（ESPおよびAHの両方によって提供される）アンチリプレイサービスは、後者の攻撃から保護するために使用することができます。
The following threat actions are also easier with MANET routers: spoofing (assuming the identify of a legitimate router), falsification (sending false routing information), and overloading (sending or triggering an excessive amount of routing updates). These attacks are only possible if authentication is not used, or the attacker takes control of a router or is able to forge legitimacy (e.g., by discovering the cryptographic key).
次の脅威アクションがMANETルータとも容易である：スプーフィング（正当なルータの識別と仮定）、改ざん（偽ルーティング情報を送信すること）、及び（送信またはルーティングアップデートの過剰量をトリガ）過負荷します。認証が使用されていない場合、これらの攻撃は可能であり、または攻撃者は、ルータの制御を取るか（暗号鍵を発見することで、例えば）正当性を偽造することができます。
[RFC4552] mandates the use of manual keying when current IPsec protocols are used with OSPFv3. Routers are required to use manually configured keys with the same security association (SA) parameters for both inbound and outbound traffic. For MANET routers, this implies that all routers attached to the same MANET must use the same key for multicasting packets. This is required in order to achieve scalability and feasibility, as explained in [RFC4552]. Future specifications can explore the use of automated key management protocols that may be suitable for MANETs.
[RFC4552]は、現在のIPsecプロトコルをOSPFv3のと共に使用される手動キーの使用を義務付け。ルータは、インバウンドおよびアウトバウンドトラフィックの両方に対して同じセキュリティアソシエーション（SA）パラメータを使用して手動で設定キーを使用する必要があります。 MANETルータの場合、これは同じMANETに接続されたすべてのルータがマルチキャストパケットの同じキーを使用しなければならないことを意味します。 [RFC4552]で説明したように、これは、拡張性と実現可能性を達成するために必要とされます。将来の仕様は、アドホックネットワークにおけるするのに適して自動化された鍵管理プロトコルの使用を探索することができます。
As discussed in [RFC4552], the use of manual keys can increase vulnerability. For example, manual keys are usually long lived, thus giving an attacker more time to discover the keys. In addition, the use of the same key on all routers attached to the same MANET leaves all routers insecure against impersonation attacks if any one of the routers is compromised.
[RFC4552]で議論するように、手動キーの使用は、脆弱性を増加させることができます。例えば、手動キーは通常長いので、攻撃者に鍵を発見するために多くの時間を与えて、住んでいます。ルータのいずれかが侵害された場合に加えて、同じMANETに接続されているすべてのルータで同じキーを使用すると、なりすまし攻撃に対する安全でないすべてのルータを残します。
Although [RFC4302] and [RFC4303] state that implementations of AH and ESP SHOULD NOT provide anti-replay service in conjunction with SAs that are manually keyed, it is important to note that such service is allowed if the sequence number counter at the sender is correctly maintained across local reboots until the key is replaced. Therefore, it may be possible for MANET routers to make use of the anti-replay service provided by AH and ESP.
AHとESPの実装は手動でキー入力されたSAと一緒にアンチリプレイサービスを提供するべきではないこと[RFC4302]及び[RFC4303]状態が、送信元のシーケンス番号カウンタである場合、そのようなサービスが許可されていることに留意することが重要ですキーが交換されるまで、正しくローカル再起動しても維持。 MANETルータはAHとESPが提供するアンチリプレイサービスを利用するため、それが可能です。
When an OSPF routing domain includes both MANET networks and fixed networks, the frequency of OSPF updates either due to actual topology changes or malfeasance could result in instability in the fixed networks. In situations where this is a concern, it is recommended that the border routers segregate the MANET networks from the fixed networks with either separate OSPF areas or, in cases where legacy routers are very sensitive to OSPF update frequency, separate OSPF instances. With separate OSPF areas, the 5-second MinLSInterval will dampen the frequency of changes originated in the MANET networks. Additionally, OSPF ranges can be configured to aggregate prefixes for the areas supporting MANET networks. With separate OSPF instances, more conservative local policies can be employed to limit the volume of updates emanating from the MANET networks.
OSPFルーティングドメインはMANETネットワーク及び固定ネットワークの両方を含む場合、実際のトポロジーの変更や不正行為に起因するいずれかのOSPF更新の頻度は、固定ネットワークに不安定になる可能性があります。これが懸念される状況では、境界ルータは、レガシールータがOSPFの更新頻度に非常に敏感である場合には別のOSPF領域または、別個のOSPFインスタンスのいずれかを有する固定ネットワークからMANETネットワークを分離することをお勧めします。別OSPFエリアと、5秒MinLSIntervalは、MANETネットワークに起源変化の周波数を減衰させるであろう。また、OSPF範囲は、MANETネットワーク対応領域の集計プレフィックスに構成することができます。別OSPFインスタンスと、より保守的なローカルポリシーは、MANETネットワークから発するアップデートの量を制限するために使用することができます。
This document defines three new LLS TLV types: MDR-Hello TLV (14), MDR-Metric TLV (16), and MDR-DD TLV (15) (see Section A.2).
（セクションA.2を参照）MDR-こんにちはTLV（14）、MDR-メトリックTLV（16）、及びMDR-DD TLV（15）：この文書は、3つの新しいLLS TLVタイプを定義します。
Thanks to Aniket Desai for helpful discussions and comments, including the suggestion that Router Priority should come before MDR Level in the lexicographical comparison of (RtrPri, MDR Level, RID) when selecting MDRs and BMDRs, and that the MDR calculation should be repeated if it causes the MDR Level to change. Thanks also to Tom Henderson, Acee Lindem, and Emmanuel Baccelli for helpful discussions and comments.
ルータの優先順位がの辞書式の比較でMDRレベルの前に来るべきだとの提案を含む、有益な議論とコメントについてAniketデサイのおかげで（RtrPri、MDRレベル、RID）のMDRを選択するときとBMDRs、それならばMDR計算を繰り返さなければならないことMDRレベルを変化させます。有益な議論とコメントについてもトム・ヘンダーソン、ACEE Lindem、およびエマニュエルBaccelliに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]グプタ、M.およびN.メラム、 "OSPFv3のための認証/機密性"、RFC 4552、2006年6月。
[RFC5243] Ogier, R., "OSPF Database Exchange Summary List Optimization", RFC 5243, May 2008.
[RFC5243]オジェ、R.、 "OSPFデータベース交換の概要一覧の最適化"、RFC 5243、2008年5月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC5613]ジニン、A.、ロイ、A.、グエン、L.、フリードマン、B.、およびD.ヨン、 "OSPFリンクローカルシグナリング"、RFC 5613、2009年8月。
[Lawler] Lawler, E., "Combinatorial Optimization: Networks and Matroids", Holt, Rinehart, and Winston, New York, 1976.
[ローラー]ローラー、E.、「組合せ最適化：ネットワークとマトロイド」、ホルト、ラインハート、およびウィンストン、ニューヨーク、1976年。
[Suurballe] Suurballe, J.W. and R.E. Tarjan, "A Quick Method for Finding Shortest Pairs of Disjoint Paths", Networks, Vol. 14, pp. 325-336, 1984.
【Suurballe] Suurballe、J.W.そして、R.E. Tarjan、ネットワーク、巻「ディスジョイント経路の最短ペアを見つけるための迅速な方法」。 14頁。325-336、1984。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 4593、2006年10月。
Appendix A. Packet Formats
付録A.パケット形式
A.1. Options Field
A.1。オプションフィールド
The L bit of the OSPF options field is used for link-local signaling, as described in [RFC5613]. Routers set the L bit in Hello and DD packets to indicate that the packet contains an LLS data block. Routers set the L bit in a self-originated router-LSA to indicate that the LSA is non-ackable.
[RFC5613]に記載されているようにOSPFオプションフィールドのLビットは、リンクローカルシグナリングのために使用されます。ルータは、パケットがLLSデータブロックが含まれていることを示すために、こんにちは、DDパケットのLビットを設定します。ルータは、LSAが非ackableであることを示すために、自己起源ルータLSAでLビットを設定します。
A.2. Link-Local Signaling
A.2。リンクローカルシグナリング
OSPF-MDR uses link-local signaling [RFC5613] to append the MDR-Hello TLV and MDR-Metric TLV to Hello packets, and to append the MDR-DD TLV to Database Description packets. Link-local signaling is an extension of OSPFv2 and OSPFv3 that allows the exchange of arbitrary data using existing OSPF packet types. Here we use LLS for OSPFv3, which is accomplished by adding an LLS data block at the end of the OSPFv3 packet. The OSPF packet length field does not include the length of the LLS data block, but the IPv6 packet length does include this length.
OSPF-MDRは、HelloパケットにMDR-こんにちはTLVとMDR-メトリックTLVを追加すると、データベース説明パケットにMDR-DD TLVを追加するために、リンクローカルシグナリング[RFC5613]を使用しています。リンクローカルシグナリングは、既存のOSPFパケットタイプを使用して、任意のデータの交換を可能にするのOSPFv2とのOSPFv3の拡張です。ここでは、OSPFv3のパケットの最後にLLSデータブロックを追加することによって達成されたOSPFv3、ためにLLSを使用します。 OSPFパケット長フィールドは、LLSデータブロックの長さが含まれていませんが、IPv6パケットの長さは、この長さを含んでいます。
A.2.1. LLS Data Block
A.2.1。 LLSデータブロック
The data block used for link-local signaling is formatted as described below in Figure A.1.
図A.1に、以下に記載されるようにリンクローカルシグナリングのために使用されるデータブロックがフォーマットされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | LLS Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LLS TLVs |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.1: Format of LLS Data Block
図A.1：LLSデータブロックのフォーマット
The Checksum field contains the standard IP checksum of the entire contents of the LLS block.
チェックサムフィールドは、LLSブロックのコンテンツ全体の標準IPチェックサムが含まれています。
The 16-bit LLS Data Length field contains the length (in 32-bit words) of the LLS block including the header and payload. Implementations should not use the Length field in the IPv6 packet header to determine the length of the LLS data block.
16ビットLLSデータ長フィールドは、ヘッダとペイロードを含むLLSブロック（32ビットワードで）長さを含みます。実装はLLSデータブロックの長さを決定するために、IPv6パケットヘッダの長さフィールドを使用してはなりません。
The rest of the block contains a set of Type/Length/Value (TLV) triplets as described in the following section. All TLVs must be 32-bit aligned (with padding if necessary).
次のセクションで説明したように、ブロックの残りの部分は、タイプ/長さ/値（TLV）トリプレットのセットを含みます。すべての（必要に応じてパディングを含む）のTLVは、32ビットに整列されなければなりません。
A.2.2. LLS TLV Format
A.2.2。 LLS TLVのフォーマット
The contents of the LLS data block are constructed using TLVs. See Figure A.2 for the TLV format.
LLSデータブロックの内容は、TLVを使用して構築されています。 TLV形式の図A.2を参照してください。
The Type field contains the TLV ID, which is unique for each type of TLV. The Length field contains the length of the Value field (in bytes) that is variable and contains arbitrary data.
Typeフィールドは、TLVの種類ごとに一意であるTLV IDが含まれています。 Lengthフィールドは、可変であり、任意のデータを含んでいる（バイト）値フィールドの長さを含みます。
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.2: Format of LLS TLVs
図A.2：LLSのTLVのフォーマット
Note that TLVs are always padded to a 32-bit boundary, but padding bytes are not included in the TLV Length field (though they are included in the LLS Data Length field of the LLS block header). All unknown TLVs MUST be silently ignored.
（それらはLLSブロックヘッダのLLSデータ長フィールドに含まれているが）のTLVは、TLVの長さフィールドには常に32ビット境界に埋め込まれているが、パディングバイトが含まれていないことに留意されたいです。すべての未知のTLVは黙って無視しなければなりません。
A.2.3. MDR-Hello TLV
A.2.3。 MDR-こんにちはTLV
The MDR-Hello TLV is appended to each MANET Hello using LLS. It includes the current Hello sequence number (HSN) for the transmitting interface and the number of neighbors of each type that are listed in the body of the Hello (see Section 4.1). It also indicates whether the Hello is differential (via the D-bit), and whether the router is using full-topology adjacencies (via the A-bit).
MDR-こんにちはTLVはLLSを使用して、各MANETのHelloに追加されます。これは、送信インタフェースの現在のHelloシーケンス番号（HSN）およびハローの本体に記載されている各タイプの近隣の数を含む（セクション4.1を参照）。それはまた、ハローが（Dビットを介して）微分であり、ルータは（Aビットを介して）フルトポロジー隣接を使用しているかどうかかどうかを示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Sequence Number | Reserved |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N1 | N2 | N3 | N4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Set to 14.
O型：14に設定します。
o Length: Set to 8.
Oの長さ：8に設定します。
o Hello Sequence Number: A circular two-octet unsigned integer indicating the current HSN for the transmitting interface. The HSN for the interface is incremented by 1 (modulo 2^16) every time a (differential or full) Hello is sent on the interface.
Oハローシーケンス番号：送信インタフェースの現在のHSNを示す円形の2オクテットの符号なし整数。インターフェイスのためのHSNは、毎回（差分または完全）ハローがインターフェイス上で送信される1（モジュロ2 ^ 16）だけインクリメントされます。
o Reserved: Set to 0. Reserved for future use.
O：予約将来使用するために予約を0に設定してください。
o A (1 bit): Set to 1 if AdjConnectivity is 0; otherwise, set to 0.
O（1ビット）：AdjConnectivityが0である場合は1に設定。それ以外の場合は、0に設定します。
o D (1 bit): Set to 1 for a differential Hello and 0 for a full Hello.
O D（1ビット）：フルハローのhello差動ために1に設定され、0。
o N1 (8 bits): The number of neighbors listed in the Hello that are in state Down. N1 is zero if the Hello is not differential.
O N1（8ビット）：ダウン状態にあるハローに列挙されたネイバーの数。こんにちは、差動でない場合、N1はゼロです。
o N2 (8 bits): The number of neighbors listed in the Hello that are in state Init.
N2（8ビット）○：初期状態にあるハローに列挙されたネイバーの数。
o N3 (8 bits): The number of neighbors listed in the Hello that are Dependent.
O N3（8ビット）に依存しているハローに列挙されたネイバーの数。
o N4 (8 bits): The number of neighbors listed in the Hello that are Selected Advertised Neighbors.
O N4（8ビット）：アドバタイズ隣人に選択されるハローに列挙されたネイバーの数。
A.2.4. MDR-DD TLV
A.2.4。 MDR-DD TLV
When a Database Description packet is sent to a neighbor in state ExStart, an MDR-DD TLV is appended to the packet using LLS. It includes the same two Router IDs that are included in the DR and Backup DR fields of a Hello sent by the router, and is used to indicate the router's MDR Level and Parent(s).
データベース説明パケットが状態のExStartでネイバーに送信されると、MDR-DD TLVはLLS使用してパケットに付加されます。これは、DRに含まれている同じ2つのルータIDとルータによって送信されるhelloのバックアップDRフィールドが含まれており、ルータのMDRレベルと親（複数可）を示すために使用されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
| DR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup DR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Set to 15.
O型：15に設定します。
o Length: Set to 8.
Oの長さ：8に設定します。
o DR: The same Router ID that is included in the DR field of a Hello sent by the router (see Section A.3).
O DR：ルータによって送信されたハローのDRフィールドに含まれるのと同じルータID（セクションA.3を参照）。
o Backup DR: The same Router ID that is included in the Backup DR field of a Hello sent by the router (see Section A.3).
OバックアップDR：ルータによって送信されるhelloのバックアップDRフィールドに含まれるのと同じルータID（A.3項を参照してください）。
A.2.5. MDR-Metric TLV
A.2.5。 MDR-メトリックTLV
If LSAFullness is 1 or 2, an MDR-Metric TLV must be appended to each MANET Hello packet using LLS, unless all link metrics are 1. This TLV advertises the link metric for each bidirectional neighbor listed in the body of the Hello. At a minimum, this TLV advertises a single default metric. If the I bit is set, the Router ID and link metric are included for each bidirectional neighbor listed in the body of the Hello whose link metric is not equal to the default metric. This option reduces overhead when all neighbors have the same link metric, or only a few neighbors have a link metric that differs from the default metric. If the I bit is zero, the link metric is included for each bidirectional neighbor that is listed in the body of the Hello and the neighbor RIDs are omitted from the TLV.
LSAFullnessは1または2である場合は、MDR-メトリックTLVはLLSを使用して、各MANET Helloパケットに追加されている必要があり、すべてのリンクメトリックが1でない限り、このTLVハローのボディにリストされた各双方向の隣人のリンクメトリックをアドバタイズします。最低でも、このTLVは、単一のデフォルトメトリックをアドバタイズします。 Iビットがセットされている場合は、ルータIDとリンクメトリックは、リンクメトリックのHelloのボディにリストされた各双方向の隣人のために含まれているは、メトリックのデフォルトと同じではありません。すべてのネイバーは、同じリンクメトリックを持っている、または少数の隣人は、デフォルトのメトリックとは異なり、リンクメトリックを持っている場合、このオプションは、オーバーヘッドを低減します。 Iビットがゼロの場合は、リンクメトリックはTLVから省略されているこんにちは、ネイバーのRIDの本体に表示されているそれぞれの双方向の隣人のために含まれています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default Metric | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (1) | Metric (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Set to 16.
O型：16に設定します。
o Length: Set to 4 + 6*N if the I bit is 1, and to 4 + 2*N if the I bit is 0, where N is the number of neighbors included in the TLV.
O長さ：IビットNが隣人の数はTLVに含まれる0の場合、Iビットが1であり、N * 2 + 4である場合は4 + 6 * Nに設定します。
o Default Metric: If the I bit is 1, this is the link metric that applies to every bidirectional neighbor listed in the body of the Hello whose RID is not listed in the Metric TLV.
Oデフォルトメトリックは：Iビットが1の場合、これはRIDメトリックTLVに記載されていないのHelloの本体に記載されているすべての双方向ネイバーに適用されるリンクメトリックです。
o Neighbor ID: If the I bit is 1, the RID is listed for each bidirectional neighbor (Lists 3 through 5 as defined in Section 4.1) in the body of the Hello whose link metric is not equal to the default metric. Omitted if the I bit is 0.
OネイバーID：Iビットが1である場合、RIDは、リンクメトリックがデフォルトメトリックと等しくないハローの本体にそれぞれ双方向ネイバー（リストセクション4.1で定義されるように3〜5）のために記載されています。 Iビットが0の場合は省略。
o Metric: Link metric for each bidirectional neighbor, listed in the same order as the Neighbor IDs in the TLV if the I bit is 1, and in the same order as the Neighbor IDs of bidirectional neighbors (Lists 3 through 5 as defined in Section 4.1) in the body of the Hello if the I bit is 0.
Oメトリック：Iビットが1である場合、双方向の隣人（リスト3〜5のネイバーのIDと同じ順序で節で定義されるように各双方向ネイバーのリンクメトリックは、TLVにおけるネイバーのIDと同じ順序で列挙されました4.1）こんにちはの体内のIビットが0の場合。
A.3. Hello Packet DR and Backup DR Fields
A.3。 helloパケットDRおよびバックアップDRフィールド
The Designated Router (DR) and Backup DR fields of a Hello packet are set as follows:
次のように指定ルータ（DR）とHelloパケットのバックアップDRフィールドが設定されています。
o DR: This field is the router's Parent, or is 0.0.0.0 if the Parent is null. The Parent of an MDR is always the router's own RID.
O DR：このフィールドは、ルータの親である、または親がnullの場合は0.0.0.0です。 MDRの親は常にルータ自身のRIDです。
o Backup DR: This field is the router's Backup Parent, or is 0.0.0.0 if the Backup Parent is null. The Backup Parent of a BMDR is always the router's own RID.
OバックアップDR：このフィールドには、ルータのバックアップ親である、または予備親がnullの場合は0.0.0.0です。 BMDRのバックアップ親は常にルータ自身のRIDです。
A.4. LSA Formats and Examples
A.4。 LSAのフォーマットと例
LSA formats are specified in [RFC5340], Section 4.4. Figure A.3 below gives an example network map for a MANET in a single area.
LSAのフォーマットは、[RFC5340]、セクション4.4で指定されています。以下図A.3は、単一の領域におけるMANETのための例示的なネットワークマップを与えます。
o Four MANET routers RT1, RT2, RT3, and RT4 are in area 1.
OフォーMANETはRT1、RT2、RT3、RT4及びエリア1にあるルータなどがあります。
o RT1's MANET interface has links to RT2 and RT3's MANET interfaces.
O RT1のMANETインタフェースはRT2とRT3のMANETインタフェースへのリンクがあります。
o RT2's MANET interface has links to RT1 and RT3's MANET interfaces.
O RT2のMANETインタフェースはRT1とRT3のMANETインタフェースへのリンクがあります。
o RT3's MANET interface has links to RT1, RT2, and RT3's MANET interfaces.
O RT3のMANETインタフェースはRT1、RT2、及びRT3のMANETインタフェースへのリンクがあります。
o RT4's MANET interface has a link to RT3's MANET interface.
O RT4のMANETインタフェースはRT3のMANETインタフェースへのリンクを持っています。
o RT1 and RT2 have stub networks attached on broadcast interfaces.
O RT1とRT2は、ブロードキャストインターフェイスに付着スタブネットワークを有しています。
o RT3 has a transit network attached on a broadcast interface.
O RT3は、ブロードキャストインターフェイスに接続トランジットネットワークを持っています。
..........................................
. Area 1.
. + .
. | .
. | 2+---+1 1+---+
. N1 |---|RT1|----+ +---|RT4|----
. | +---+ |\ / +---+
. | | \ / .
. + | \ N3 / .
. | \ / .
. + | \ / .
. | | \ / .
. | 2+---+1 | \ / .
. N2 |---|RT2|----+-------+ .
. | +---+ |1 .
. | +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. +------------+ .
. |1 N4 .
. +---+ .
. |RT5| .
. +---+ .
..........................................
Figure A.3: Area 1 with IP Addresses Shown
図A.3：示されたIPアドレスを持つエリア1
Network IPv6 prefix
-----------------------------------
N1 5f00:0000:c001:0200::/56
N2 5f00:0000:c001:0300::/56
N4 5f00:0000:c001:0400::/56
Table 1: IPv6 link prefixes for sample network
表1：サンプルネットワークのためのIPv6リンクプレフィックス
Router interface Interface ID IPv6 global unicast prefix
-----------------------------------------------------------
RT1 LOOPBACK 0 5f00:0001::/64
to N3 1 n/a
to N1 2 5f00:0000:c001:0200::RT1/56
RT2 LOOPBACK 0 5f00:0002::/64
to N3 1 n/a
to N2 2 5f00:0000:c001:0300::RT2/56
RT3 LOOPBACK 0 5f00:0003::/64
to N3 1 n/a
to N4 2 5f00:0000:c001:0400::RT3/56
RT4 LOOPBACK 0 5f00:0004::/64
to N3 1 n/a
RT5 to N4 1 5f00:0000:c001:0400::RT5/56
Table 2: IPv6 link prefixes for sample network
表2：サンプルネットワークのためのIPv6リンクプレフィックス
Router interface Interface ID link-local address
-------------------------------------------------------
RT1 LOOPBACK 0 n/a
to N1 1 fe80:0001::RT1
to N3 2 fe80:0002::RT1
RT2 LOOPBACK 0 n/a
to N2 1 fe80:0001::RT2
to N3 2 fe80:0002::RT2
RT3 LOOPBACK 0 n/a
to N3 1 fe80:0001::RT3
to N4 2 fe80:0002::RT3
RT4 LOOPBACK 0 n/a
to N3 1 fe80:0001::RT4
RT5 to N4 1 fe80:0002::RT5
Table 3: OSPF interface IDs and link-local addresses
表3：OSPFインタフェースIDとリンクローカルアドレス
A.4.1. Router-LSAs
A.4.1。ルータのLSA
As an example, consider the router-LSA that node RT3 would originate. The node consists of one MANET, one broadcast, and one loopback interface.
一例として、ノードRT3を発信することをルータLSAを考えます。ノードは、1つのMANET、1回の放送、および1つのループバックインタフェースで構成されています。
RT3's router-LSA
RT3のルータLSA
LS age = DoNotAge+0 ;newly originated LS type = 0x2001 ;router-LSA Link State ID = 0 ;first fragment Advertising Router = 192.1.1.3 ;RT3's Router ID bit E = 0 ;not an AS boundary router bit B = 1 ;area border router Options = (V6-bit|E-bit|R-bit) Type = 1 ;p2p link to RT1 Metric = 1 ;cost to RT1 Interface ID = 1 ;Interface ID Neighbor Interface ID = 1 ;Interface ID Neighbor Router ID = 192.1.1.1 ;RT1's Router ID Type = 1 ;p2p link to RT2 Metric = 1 ;cost to RT2 Interface ID = 1 ;Interface ID Neighbor Interface ID = 1 ;Interface ID Neighbor Router ID = 192.1.1.2 ;RT2's Router ID Type = 1 ;p2p link to RT4 Metric = 1 ;cost to RT4 Interface ID = 1 ;Interface ID Neighbor Interface ID = 1 ;Interface ID Neighbor Router ID = 192.1.1.4 ;RT4's Router ID Type = 2 ;connects to N4 Metric = 1 ;cost to N4 Interface ID = 2 ;RT3's Interface ID Neighbor Interface ID = 1 ;RT5's Interface ID (elected DR) Neighbor Router ID = 192.1.1.5 ;RT5's Router ID (elected DR)
LS年齢= DoNotAge + 0;新しく始まっLSタイプ= 0x2001;ルータLSAリンクステートID = 0;最初のフラグメント広告ルータ= 192.1.1.3; RT3のルータIDビットE = 0;ないAS境界ルータビットB = 1;エリアボーダルータオプション=（V6ビット| Eビット| Rビット）TYPE = 1;コストRT1へのインタフェースID = 1;インターフェースIDネイバーインタフェースID = 1; RT1メトリック= 1にP2PリンクインターフェースIDの隣接ルータID = 192.1.1.1; RT1のルータIDタイプ= 1; RT2メトリック= 1へのP2Pリンク、インタフェースIDの隣人インタフェースID = 1;;インタフェースID近隣ルーターID = 192.1.1.2; RT2のルータID RT2インタフェースID = 1のコストタイプ= 1; RT4メトリック= 1にP2Pリンクは、インタフェースIDネイバーインタフェースID = 1;インターフェースID近隣ルータID = 192.1.1.4; RT4のルータIDタイプ= 2; RT4インタフェースID = 1のコスト= N4メトリックに接続します1; N4インタフェースID = 2のコスト; RT3のインターフェースIDネイバーインタフェースID = 1; RT5のインタフェースID（選出DR）近隣ルータID = 192.1.1.5; RT5のルータID（DRを選択）
A.4.2. Link-LSAs
A.4.2。リンクのLSA
Consider the link-LSA that RT3 would originate for its MANET interface.
RT3は、そのMANETインターフェイスに発信うリンクLSAを考えてみましょう。
RT3's link-LSA for its MANET interface
そのMANETインタフェース用RT3のリンクLSA
LS age = DoNotAge+0 ;newly originated LS type = 0x0008 ;Link-LSA Link State ID = 1 ;Interface ID Advertising Router = 192.1.1.3 ;RT3's Router ID RtrPri = 1 ;default priority Options = (V6-bit|E-bit|R-bit) Link-local Interface Address = fe80:0001::RT3 # prefixes = 0 ;no global unicast address
LS年齢= DoNotAge + 0;新しく始まっLSタイプ= 0x0008で、リンクLSAリンクステートID = 1;インタフェースID広告のルータ= 192.1.1.3; RT3のルータID RtrPri = 1;デフォルトの優先オプション=（V6ビット| E-ビット| R-ビット）リンクローカルインタフェースアドレス=のFE80：0001 :: RT3番号プレフィックス= 0;なしグローバルユニキャストアドレス
A.4.3. Intra-Area-Prefix-LSAs
A.4.3。エリア内プレフィクスLSAを
A MANET node originates an intra-area-prefix-LSA to advertise its own prefixes, and those of its attached networks or stub links. As an example, consider the intra-area-prefix-LSA that RT3 will build.
MANETノードは、独自のプレフィックスを通知するために、エリア内プレフィックス-LSAを発信し、その接続されたネットワークまたはスタブリンクのものを。例として、RT3が構築することを、エリア内プレフィックス-LSAを考えます。
RT2's intra-area-prefix-LSA for its own prefixes
独自のプレフィックスのRT2のエリア内プレフィックスLSA-
LS age = DoNotAge+0 ;newly originated LS type = 0x2009 ;intra-area-prefix-LSA Link State ID = 177 ;or something Advertising Router = 192.1.1.3 ;RT3's Router ID # prefixes = 2 Referenced LS type = 0x2001 ;router-LSA reference Referenced Link State ID = 0 ;always 0 for router-LSA reference Referenced Advertising Router = 192.1.1.3 ;RT2's Router ID PrefixLength = 64 ;prefix on RT3's LOOPBACK PrefixOptions = 0 Metric = 0 ;cost of RT3's LOOPBACK Address Prefix = 5f00:0003::/64 PrefixLength = 56 ;prefix on RT3's interface 2 PrefixOptions = 0 Metric = 1 ;cost of RT3's interface 2 Address Prefix = 5f00:0000:c001:0400::RT3/56 ;pad
LS時代= DoNotAge + 0;新しく始まっLSタイプ= 0x2009;エリア内プレフィックス-LSAリンクステートID = 177;か何かの広告ルータ= 192.1.1.3; RT3のルータID番号の接頭辞= 2参考LSタイプ= 0x2001;ルータリンクステートID = 0参考に-lsa参照;常に0 = 192.1.1.3広告ルータ参考ルータLSAの参照用、RT2のルータID PrefixLength = 64;接頭辞RT3のループバックPrefixOptions上= 0メートル= 0; RT3のループバックアドレスのプレフィックスのコスト= 5F00：0003 :: / 64 PrefixLength = 56; RT3のインターフェイス上の接頭辞2 PrefixOptions = 0メトリック= 1; RT3のインターフェース2つのアドレスプレフィックス= 5F00のコスト：0000：C001：0400 :: RT3 / 56;パッド
Appendix B. Detailed Algorithms for MDR/BMDR Selection
MDR / BMDR選択のための付録B.詳細なアルゴリズム
This section provides detailed algorithms for Step 2.4 of Phase 2 (MDR selection) and Step 3.2 of Phase 3 (BMDR selection) of the MDR selection algorithm described in Section 5. Step 2.4 uses a breadth-first search (BFS) algorithm, and Step 3.2 uses an efficient algorithm for finding pairs of node-disjoint paths from Rmax to all other neighbors. Both algorithms run in O(d^2) time, where d is the number of neighbors.
第5ステップ2.4に記載MDR選択アルゴリズムのこのセクションフェーズ2（MDR選択）のステップ2.4の詳細なアルゴリズムを提供し、フェーズ3（BMDR選択）の3.2ステップは、幅優先探索（BFS）アルゴリズムを使用し、ステップ3.2は、他のすべてのネイバーにさRmaxからノードディスジョイントパスのペアを見つけるための効率的なアルゴリズムを使用します。両方のアルゴリズムは、Dは、近隣の数であり、O（D ^ 2）の時間で実行されます。
For convenience, in the following description, the term "bi-neighbor" will be used as an abbreviation for "bidirectional neighbor". Also, node i denotes the router performing the calculation.
便宜上、以下の説明では、用語「バイ隣人は」「双方向の隣人」の略称として使用されます。また、ノードiは計算を実行するルータを示しています。
B.1. Detailed Algorithm for Step 2.4 (MDR Selection)
B.1。ステップ2.4の詳細なアルゴリズム（MDRセレクション）
The following algorithm performs Step 2.4 of the MDR selection algorithm, and assumes that Phase 1 and Steps 2.1 through 2.3 have been performed, so that the neighbor connectivity matrix NCM has been computed and Rmax is the bi-neighbor with the (lexicographically) largest value of (RtrPri, MDR Level, RID). The BFS algorithm uses a FIFO queue so that all nodes 1 hop from node Rmax are processed first, then 2 hops, etc. When the BFS algorithm terminates, hops(u), for each bi-neighbor node u of node i, will be equal to the minimum number of hops from node Rmax to node u, using only intermediate nodes that are bi-neighbors of node i and that have a larger value of (RtrPri, MDR Level, RID) than node i. The algorithm also computes, for each node u, the tree parent p(u) and the second node r(u) on the tree path from Rmax to u, which will be used in Step 3.2.
以下のアルゴリズムは、MDR選択アルゴリズムのステップ2.4を実行し、隣接の接続性マトリックスNCMが計算され、Rmaxが（辞書）の最大値との双方向ネイバーとなるように、フェーズ1および2.3〜ステップ2.1は、実行されていることを前提と（RtrPri、MDRレベル、RID）の。 BFSアルゴリズムはBFSアルゴリズムが終了すると、ノードさRmaxから、全てのノード1つのホップ、2つのホップ、等次いで、最初に処理されるように、FIFOキューを使用（U）をホップ、ノードの各双隣接ノードU iについては、あろう私は、それがノードより（RtrPri、MDRレベル、RID）のより大きな値を持つノードの双近隣のみ中間ノードを使用して、Uのノード間Rmaxとからのホップの最小数に等しいです。アルゴリズムは、ステップ3.2で使用されるRmaxとからUへのツリー経路上の各ノードU、ツリーの親P（U）と第2ノードR（U）のために、計算します。
(a) Compute a matrix of link costs c(u,v) for each pair of bi-neighbors u and v as follows: If node u has a larger value of (RtrPri, MDR Level, RID) than node i, and NCM(u,v) = 1, then set c(u,v) to 1. Otherwise, set c(u,v) to infinity. (Note that the matrix NCM(u,v) is symmetric, but the matrix c(u,v) is not.)
ノードuがより大きな値を有する場合（RtrPri、MDRレベルを、RID）iがノード以外、およびNCM：（A）次のように各二近隣の対uとvのリンクコストC（U、V）のマトリックスを計算します（U、V）= 1の場合、Cを設定する（U、V）1それ以外の場合は、セットCの（u、v）と無限大です。 （マトリックスNCMは、（u、v）が対称であるが、行列Cは、（u、v）をしないことに注意してください。）
(b) Set hops(u) = infinity for all bi-neighbors u other than Rmax, and set hops(Rmax) = 0. Initially, p(u) is undefined for each neighbor u. For each bi-neighbor u such that c(Rmax,u) = 1, set r(u) = u; for all other u, r(u) is initially undefined. Add node Rmax to the FIFO queue.
（B）セットホップ（u）はRmaxのよりuは他のすべての二ネイバーの無限=、および最初のホップさ（Rmax）= 0に設定し、pが（U）各隣接Uは未定義です。各二ネイバのUように、C（Rmaxは、U）= 1をセットR（U）= U。他のすべてのuのために、R（u）は、最初は未定義です。 FIFOキューにノードRmaxを追加します。
(c) While the FIFO queue is nonempty: Remove the node at the head of the queue; call it node u. For each bi-neighbor v of node i such that c(u,v) = 1: If hops(v) > hops(u) + 1, then set hops(v) = hops(u) + 1, set p(v) = u, set r(v) = r(u) if hops(v) > 1, and add node v to the tail of the queue.
（C）FIFOキューが空である間：キューの先頭にあるノードを削除します。 Uをノードと呼んでいます。各双隣接ノードのV Iように、C（U、V）= 1：ホップ（V）>ホップ場合（u）は+ 1、次にホップ（v）がホップ（U）+ 1、セットPは（=設定しましたV）U =、セットR（V）= R（U）場合ホップ（V）> 1、キューの末尾にノードvを追加します。
B.2. Detailed Algorithm for Step 3.2 (BMDR Selection)
B.2。ステップ3.2の詳細なアルゴリズム（BMDRセレクション）
Step 3.2 of the MDR selection algorithm requires the router to determine whether there exist two node-disjoint paths from Rmax to each other bi-neighbor u, via bi-neighbors that have a larger value of (RtrPri, MDR Level, RID) than the router itself. This information is needed to determine whether the router should select itself as a BMDR.
より（RtrPri、MDRレベル、RID）のより大きな値を持つ二ネイバーを介して、互いに双方向隣接UにさRmaxから二ノードディスジョイント経路が存在するかどうかMDR選択アルゴリズムのステップ3.2を決定するためにルータを必要とルータ自体。この情報は、ルータがBMDRとして自分自身を選択する必要があるかどうかを判断するために必要とされます。
It is possible to determine separately for each bi-neighbor u whether there exist two node-disjoint paths from Rmax to u, using the well-known augmenting path algorithm [Lawler] that runs in O(n^2) time, but this must be done for all bi-neighbors u, thus requiring a total run time of O(n^3). The algorithm described below makes the same determination simultaneously for all bi-neighbors u, achieving a much faster total run time of O(n^2). The algorithm is a simplified variation of the Suurballe-Tarjan algorithm [Suurballe] for finding pairs of disjoint paths.
O（N ^ 2）の時間で実行され、周知の増強パスアルゴリズム[ローラー]、このマストを使用して、RmaxとからUへの2つのノードディスジョイント経路が存在するかどうかを各双方向ネイバーのための別々のuを決定することができることです従ってO（N ^ 3）の合計実行時間を必要とする、すべてのBI-ネイバーのためのUを行うこと。以下に説明するアルゴリズムは、Oのはるかに速く総実行時間（N ^ 2）を達成し、全二ネイバーUに対して同時に同じ決意をします。アルゴリズムは互いに素パスのペアを見つけるためSuurballe-Tarjanアルゴリズム[Suurballe]の簡略化された変形例です。
The algorithm described below uses the following output of Phase 2: the tree parent p(u) of each node (which defines the BFS tree computed in Phase 2), and the second node r(u) on the tree path from Rmax to u.
UへRmaxとからツリー経路上の（フェーズ2で計算BFSツリーを定義する）各ノードのツリーの親P（U）、及び第2のノードR（U）：以下に説明するアルゴリズムは、フェーズ2の次の出力を使用します。
The algorithm uses the following concepts. For any node u on the BFS tree other than Rmax, we define g(u) to be the first labeled node on the reverse tree path from u to Rmax, if such a labeled node exists other than Rmax. (The reverse tree path consists of u, p(u), p(p(u)), ..., Rmax.) If no such labeled node exists, then g(u) is defined to be r(u). In particular, if u is labeled then g(u) = u. Note that g(u) either must be labeled or must be a neighbor of Rmax.
このアルゴリズムは、次の概念を使用しています。 Rmaxは以外BFSツリーの任意のノードuのために、我々は、そのような標識されたノードがRmaxで以外存在する場合、RmaxでのUからの逆ツリー経路上の最初の標識されたノードであるG（U）を定義します。 （逆ツリー経路は、Uから成り、P（U）、P（P（U））、...、Rmaxが。）そのような標識されたノードが存在しない場合は、G（U）は、R（U）であると定義されます。特に、Uは、次いで標識されている場合、G（U）= U。そのG（U）のいずれかを標識しなければならない点に注意してくださいまたはRmaxとの隣人でなければなりません。
For any node k that either is labeled or is a neighbor of Rmax, we define the unlabeled subtree rooted at k, denoted S(k), to be the set of nodes u such that g(u) = k. Thus, S(k) includes node k itself and the set of unlabeled nodes downstream of k on the BFS tree that can be reached without going through any labeled nodes. This set can be obtained in linear time using a depth-first search starting at node k, and using labeled nodes to indicate the boundaries of the search. Note that g(u) and S(k) are not maintained as variables in the algorithm given below, but simply refer to the definitions given above.
標識された又はさRmaxの近隣であるいずれかの任意のノードkのために、我々は、Kをルート非標識サブツリーを定義し、Uは、G（U）= Kそのノードのセットであることが、S（k）と表記。従って、S（k）は、ノードk自身と任意の標識されたノードを経由せずに到達することができるBFSツリー上のkの下流の非標識ノードのセットを含みます。このセットは、ノードkから始まる深さ優先探索を使用して線形時間で得られ、そして検索の境界を示すために、標識されたノードを使用することができます。なお、G（U）及びS（k）は以下に示すアルゴリズムにおいて変数として維持し、単に上記の定義を参照していません。
The BMDR algorithm maintains a set B, which is initially empty. A node u is added to B when it is known that two node-disjoint paths exist from Rmax to u via nodes that have a larger value of (RtrPri, MDR Level, RID) than the router itself. When the algorithm terminates, B consists of all nodes that have this property.
BMDRアルゴリズムは最初は空であり、セットBを、維持します。ノードuが、二つのノードディスジョイント経路がルータ自体よりも（RtrPri、MDRレベル、RID）の大きな値を有するノードを介してUにさRmaxから存在することが知られている場合Bに添加します。アルゴリズムが終了すると、Bは、この性質を持っているすべてのノードで構成されています。
The algorithm consists of the following two steps.
このアルゴリズムは、以下の2つのステップから構成されています。
(a) Mark Rmax as labeled. For each pair of nodes u, v on the BFS tree other than Rmax such that r(u) is not equal to r(v) (i.e., u and v have different second nodes), NCM(u,v) = 1, and node u has a greater value of (RtrPri, MDR level, RID) than the router itself, add v to B. (Clearly there are two disjoint paths from Rmax to v.)
（a）はマークさRmaxラベルとして。ノードの各対について、U、R（u）は、R（V）に等しくないようにさRmax以外BFSツリー上のV（すなわち、uおよびvは異なる第二のノードを有する）、NCM（U、V）= 1ノードuは、ルータ自体よりも（RtrPri、MDRレベル、RID）の大きな値を有し、BにVを追加する（明らかにVへRmaxとから2つの互いに素の経路があります。）
(b) While there exists a node in B that is not labeled, do the following. Choose any node k in B that is not labeled, and let j = g(k). Now mark k as labeled. (This creates a new unlabeled subtree S(k), and makes S(j) smaller by removing S(k) from it.) For each pair of nodes u, v such that u is in S(k), v is in S(j), and NCM(u,v) = 1:
標識されていないB内のノードが存在しているが（b）に示すように、次のように行います。標識されていないB内の任意のノードkを選択し、J = G（k）をしましょう。ラベルされたとして、今のkをマーク。 （これは、新しい非標識サブツリーS（k）を作成し、それから、S（k）を除去することにより、S（j）を小さくなる。）Uが、UはS（k）がであることV例えば、Vが入っているノードの各ペアについてS（J）、およびNCM（u、v）は1 =：
o If u has a larger value of (RtrPri, MDR level, RID) than the
router itself, and v is not in B, then add v to B.
o If v has a larger value of (RtrPri, MDR level, RID) than the router itself, and u is not in B, then add u to B.
vがルータ自体よりも（RtrPri、MDRレベル、RID）の大きい方の値を有し、そしてuがBにない場合、O、次いでBにUを加えます
A simplified version of the algorithm MAY be performed by omitting step (b). However, the simplified algorithm will result in more BMDRs, and is not recommended if AdjConnectivity = 2 since it will result in more adjacencies.
アルゴリズムの単純化されたバージョンは、工程（b）を省略することによって行われてもよいです。しかし、簡略化されたアルゴリズムは、よりBMDRsになり、そしてAdjConnectivity = 2場合、それはより多くの隣接関係になりますので、お勧めしません。
The above algorithm can be executed in O(n^2) time, where n is the number of neighbors. Step (a) clearly requires O(n^2) time since it considers all pairs of nodes u and v. Step (b) also requires O(n^2) time because each pair of nodes is considered at most once. This is because labeling nodes divides unlabeled subtrees into smaller unlabeled subtrees, and a given pair u, v is considered only the first time u and v belong to different unlabeled subtrees.
上記のアルゴリズムは、nが隣人の数であり、O（N ^ 2）の時間で実行することができます。ステップ（a）は、明確には、ノードのすべての対がUおよびV考えるので、O（N ^ 2）の時間を必要とする。ノードの各対がせいぜい一度であると考えられるので、ステップ（B）は、（N ^ 2）の時間Oを必要とします。標識ノードは小さな非標識サブツリーに標識されていないサブツリーを分割し、所定の一対のUこれは、vがuとvは異なる非標識サブツリーに属するのみ初めて考えられるれます。
Appendix C. Min-Cost LSA Algorithm
付録C.分コストLSAアルゴリズム
This section describes the algorithm for determining which MANET neighbors to include in the router-LSA when LSAFullness is 1. The min-cost LSA algorithm ensures that the link-state database provides sufficient information to calculate at least one shortest (minimum-cost) path to each destination. The algorithm assumes that a router may have multiple interfaces, at least one of which is a MANET interface. The algorithm becomes significantly simpler if the router has only a single (MANET) interface.
LSAFullnessが最小コストLSAアルゴリズムがリンクステートデータベースは、少なくとも一つの最短（最小コスト）パスを計算するのに十分な情報を提供することを確実に1である場合、このセクションでは、ルータLSAに含めるMANETネイバーを決定するためのアルゴリズムを説明します各宛先へ。アルゴリズムは、ルータがMANETインタフェースである少なくとも一方が複数のインタフェースを有してもよいことを想定しています。このアルゴリズムは、ルータは、単一の（MANET）のインターフェースを持っている場合は非常に簡単になります。
The input to this algorithm includes information obtained from Hellos received from each neighbor on each MANET interface, including the neighbor's Bidirectional Neighbor Set (BNS), Dependent Neighbor Set (DNS), Selected Advertised Neighbor Set (SANS), and link metrics. The input also includes the link-state database if the router has a non-MANET interface.
このアルゴリズムへの入力はハローズから得られた情報をアドバタイズ隣接セット（SANS）、およびリンクメトリックを選択された隣接の双方向隣接セット（BNS）、依存隣接セット（DNS）、を含む、各MANETインタフェース上の各ネイバーから受信含みます。ルータは非MANETインタフェースを持っている場合、入力は、リンクステートデータベースを含みます。
The output of the algorithm is the router's SANS for each MANET interface. The SANS is used to construct the router-LSA as described in Section 9.4. The min-cost LSA algorithm must be run to update the SANS (and possibly originate a new router-LSA) either periodically just before sending each Hello, or whenever any of the following events occurs:
アルゴリズムの出力は、各MANETインタフェースのためのルータのSANSです。 SANSは、9.4節で説明したようにルータLSAを構築するために使用されます。最小コストのLSAアルゴリズムはちょうどこんにちはそれぞれを送信する前に、定期的にどちらかのSANSを更新（そしておそらく新しいルータ - LSAを発信）するために実行しなければならない、またはときは、次のいずれかのイベントが発生します。
o The state or routability of a neighbor changes.
ネイバーの状態が変化するか、ルータビリティO。
o A Hello received from a neighbor indicates a change in its MDR Level, Router Priority, FullHelloRcvd, BNS, DNS, SANS, Parent(s), or link metrics.
こんにちはoをそのMDRレベル、ルータプライオリティ、FullHelloRcvd、BNS、DNS、SANS、親（S）の変化を示す、あるいはリンクメトリックネイバーから受信。
o An LSA originated by a non-MANET neighbor is received.
O非MANETの隣人によって発信LSAが受信されます。
Although the algorithm described below runs in O(d^3) time, where d is the number of neighbors, an incremental version for a single topology change runs in O(d^2) time, as discussed following the algorithm description.
以下に説明するアルゴリズムは、dは近隣の数、単一のトポロジ変更の増分バージョンがO（D ^ 3）時間で実行されているがアルゴリズム記述以下で論じたように、O（D ^ 2）の時間で実行されます。
For convenience, in the following description, the term "bi-neighbor" will be used as an abbreviation for "bidirectional neighbor". Also, router i will denote the router doing the calculation. To perform the min-cost LSA algorithm, the following steps are performed.
便宜上、以下の説明では、用語「バイ隣人は」「双方向の隣人」の略称として使用されます。また、ルータiは計算を行うルータを意味します。最小コストのLSAアルゴリズムを実行するには、以下のステップが実行されます。
(1) Create the neighbor connectivity matrix (NCM) for each MANET interface, as described in Section 5.1. Create the multiple-interface neighbor connectivity matrix MNCM as follows. For each bi-neighbor j, set MNCM(i,j) = MNCM(j,i) = 1. For each pair j, k of MANET bi-neighbors, set MNCM(j,k) = 1 if NCM(j,k) equals 1 for any MANET interface. For each pair j, k of non-MANET bi-neighbors, set MNCM(j,k) = 1 if the link-state database indicates that a direct link exists between j and k. Otherwise, set MNCM(j,k) = 0. (Note that a given router can be a neighbor on both a MANET interface and a non-MANET interface.)
セクション5.1で説明したように（1）、各MANETインターフェイスの隣接接続マトリクス（NCM）を作成します。以下のように、複数のインターフェイスネイバー接続行列MNCMを作成します。各双隣接jに対して、MNCM（I、J）= MNCM（J、I）=各ペアjに対して1、MANETの双近隣のK、設定MNCM（J、K）= 1を設定NCM（J場合、 k）は、任意のMANETインターフェイスの1に等しいです。リンクステートデータベースは、直接リンクは、JおよびKとの間に存在することを示す場合に各ペアjについて、非MANET二近傍のkは、MNCM（J、K）= 1を設定しました。そうでない場合、MNCM（J、K）= 0を設定する（特定のルータがMANETインタフェースと非MANETインタフェースの両方に隣接することができることに留意されたいです。）
(2) Create the inter-neighbor cost matrix (COST) as follows. For each pair j, k of routers such that each of j and k is a bi-neighbor or router i itself:
（2）次のように相互隣接コストマトリックス（COST）を作成します。各ペアjについて、jおよびkのそれぞれは双方向ネイバーまたはルータI自体であるようなルータのK。
(a) If MNCM(j,k) = 1, set COST(j,k) to the metric of the link
from j to k obtained from j's Hellos (for a MANET interface),
or from the link-state database (for a non-MANET interface).
If there are multiple links from j to k (via multiple
interfaces), COST(j,k) is set to the minimum cost of these
links.
(b) Otherwise, set COST(j,k) to LSInfinity.
LSInfinityに（B）それ以外の場合は、設定されたコスト（J、K）。
(3) Create the backbone neighbor matrix (BNM) as follows. BNM indicates which pairs of MANET bi-neighbors are backbone neighbors of each other, as defined in Section 9.2.1. If adjacency reduction is not used (AdjConnectivity = 0), set all entries of BNM to zero and proceed to Step 4.
（3）次のようにバックボーン隣接行列（BNM）を作成します。 BNMはセクション9.2.1で定義されているMANET二近隣の対は、互いの骨格隣接しているかを示します。隣接還元が使用されていない場合（AdjConnectivity = 0）、BNMのすべてのエントリがゼロとステップ4に進むように設定。
In the following, if a link exists from router j to router k on
more than one interface, we consider only interfaces for which
the cost from j to k equals COST(j,k); such interfaces will be
called "candidate" interfaces.
For each pair j, k of MANET bi-neighbors, BNM(j,k) is set to 1 if j and k are backbone neighbors of each other on a candidate MANET interface. That is, BNM(j,k) is set to 1 if, for any candidate MANET interface, NCM(j,k) = 1 and either of the following conditions is satisfied:
jおよびkは、候補MANETインタフェース上の互いの骨格隣接している場合に各ペアjについて、MANET二近隣のKは、BNM（J、K）が1に設定されています。つまり、次のいずれかの条件が満たされた任意の候補MANETインタフェース、NCM（J、K）= 1とするために、場合BNM（J、K）が1に設定されます。
(a) Router k is included in j's DNS or router j is included in k's DNS.
（a）はルータkがJのDNSやルーターJに含まれているKのDNSに含まれています。
(b) Router j is the (Backup) Parent of router k or router k is the (Backup) Parent of router j.
（b）は、ルータjは、ルータKまたはルータkの（バックアップ）親ルータjの（バックアップ）親です。
Otherwise, BNM(j,k) is set to 0.
そうでない場合、BNM（j、k）は0に設定されています。
(4) Create the Selected Advertised Neighbor Matrix (SANM) as follows. For each pair j, k of routers such that each of j and k is a bi-neighbor or router i itself, SANM(j,k) is set to 1 if, for any candidate MANET interface, NCM(j,k) = 1 and k is included in j's SANS. Otherwise, SANM(j,k) is set to 0. Note that SANM(i,k) is set to 1 if k is currently a Selected Advertised Neighbor.
（4）以下のように選択されたアドバタイズ近隣マトリックス（SANM）を作成します。各ペアjに対して、ルータのkはjおよびkのそれぞれは、I自体は、SANM（J、K）が1に設定されている双方向ネイバーまたはルータであるように、任意の候補MANETインタフェース用の、NCM（J、K）=、もし1とkがJのSANSに含まれています。そうでない場合、SANM（j、k）は、kは、現在選択されてアドバタイズ近隣であればSANM（I、K）が1に設定されていることを注意0に設定されています。
(5) Compute the new set of Selected Advertised Neighbors as follows. For each MANET bi-neighbor j, initialize the bit variable new_sel_adv(j) to 0. (This bit will be set to 1 if j is selected.) For each MANET bi-neighbor j:
以下のように（5）選択されたアドバタイズ隣人の新しいセットを計算します。各MANET双隣接jについて、各MANET双隣接jに対して（jが選択されている場合、このビットは1に設定される）0にビット変数new_sel_adv（j）を初期化します。
(a) If j is a bi-neighbor on more than one interface, consider
only candidate interfaces (for which the cost to j is
minimum). If one of the candidate interfaces is a non-MANET
interface, examine the next neighbor (j is not selected since
it will be advertised anyway).
(b) If adjacency reduction is used, and one of the candidate interfaces is a MANET interface on which j is a backbone neighbor (see Section 9.2), examine the next neighbor (j is not selected since it will be advertised anyway).
（b）は、隣接還元が使用される場合、候補インターフェイスの一方はjはバックボーンネイバー（セクション9.2を参照）されたMANETインタフェースである、（それはとにかくアドバタイズされるので、jが選択されていない）次の隣接を調べます。
(c) Otherwise, if there is more than one candidate MANET interface, select the "preferred" interface by using the following preference rules in the given order: an interface is preferred if (1) router i's SANS for that interface already includes j, (2) router i's Router Priority is larger on that interface, and (3) router i's MDR Level is larger on that interface.
（C）そうでない場合は、複数の候補MANETインタフェースがある場合は、所定の順序で次の優先ルールを使用して「好ましい」インターフェースを選択する：（1）そのインターフェイスのための私のSANSルータが既にJを含む場合インターフェイスが好ましく、 （2）ルータ私のルータの優先順位は、そのインターフェイス上で大きくなり、そして（3）ルータ私のMDRレベルは、そのインターフェイス上で大きくなっています。
(d) For each bi-neighbor k (on any interface) such that COST(k,j) > COST(k,i) + COST(i,j), determine whether there exists another bi-neighbor u such that either COST(k,u) + COST(u,j) < COST(k,i) + COST(i,j), or COST(k,u) + COST(u,j) = COST(k,i) + COST(i,j) and either of the following conditions is true:
（任意のインターフェイス上の）各双隣接kに対する（d）のようにCOST（K、J）> COST（K、I）+ COST（i、j）が、別の双方向隣接uがその結果が存在するかどうかを決定するいずれかCOST （K、U）+ COST（U、J）<COST（K、I）+ COST（i、j）を、またはCOST（K、U）+ COST（U、J）= COST（K、I）+ COST （i、j）は、次のいずれかの条件が真であります：
o BNM(u,j) = 1, or
O BNM（U、J）= 1、又は
o (SANM(j,u), SANM(u,j), RtrPri(u), RID(u)) is lexicographically greater than (SANM(j,i), SANM(i,j), RtrPri(i), RID(i)).
Oより辞書大きい（SANM（J、U）、SANM（U、j）は、RtrPri（u）は、u）は（RID）（SANM（j、i）に対して、SANM（i、j）は、RtrPri（I）、 RID（I））。
If for some such bi-neighbor k, there does not exist such a bi-neighbor u, then set new_sel_adv(j) = 1.
いくつかのこのような双隣接kの場合、このような双方向隣接U、次に設定new_sel_adv（J）= 1が存在しません。
(6) For each MANET interface I, update the SANS to equal the set of all bi-neighbors j such that new_sel_adv(j) = 1 and I is the preferred interface for j.
（6）各MANETインタフェースIについて、new_sel_adv（J）= 1とIがJのための好ましいインタフェースであるように、すべてのBI-ネイバーjのセットと等しくなるようにSANSを更新します。
(7) With the SANS updated, a new router-LSA may need to be originated as described in Section 9.4.
SANSが更新して（7）、新しいルータ - LSAは、9.4節で説明したように起源する必要があるかもしれません。
The lexicographical comparison of Step 5d gives preference to links that are already advertised, in order to improve LSA stability.
ステップ5dの辞書式比較は既にLSA安定性を向上させるために、アドバタイズされたリンクを優先します。
The above algorithm can be run in O(d^2) time if a single link change occurs. For example, if link (x,y) fails where x and y are neighbors of router i, and either SANS(x,y) = 1 or BNM(x,y) = 1, then Step 5 need only be performed for pairs j, k such that either j or k is equal to x or y.
単一リンクの変更が発生した場合、上記のアルゴリズムは、O（D ^ 2）の時間で実行することができます。 xおよびy iは、いずれかSANS（X、Y）= 1又はBNM（X、Y）= 1、次いで5のみペアのために実行される必要があるステップルータの近隣である場合、例えば、リンク（x、y）が失敗した場合JまたはKのいずれかがxまたはyに等しくなるようにJ、K。
Appendix D. Non-Ackable LSAs for Periodic Flooding
定期的なフラッディング付録D.非AckableのLSA
In a highly mobile network, it is possible that a router almost always originates a new router-LSA every MinLSInterval seconds. In this case, it should not be necessary to send Acks for such an LSA, or to retransmit such an LSA as a unicast, or to describe such an LSA in a DD packet. In this case, the originator of an LSA MAY indicate that the router-LSA is "non-ackable" by setting the L bit in the options field of the LSA (see Section A.1). For example, a router can originate non-ackable LSAs if it determines (e.g., based on an exponential moving average) that a new LSA is originated every MinLSInterval seconds at least 90 percent of the time. (Simulations can be used to determine the best threshold.)
非常にモバイルネットワークでは、ルータは、ほとんど常にすべてのMinLSInterval秒新しいルータ - LSAを発信することが可能です。この場合には、そのようなLSAのためのACKを送信する、またはユニキャストのようなLSAを再送信する、またはDDパケットにそのようなLSAを記述する必要はありません。この場合、LSAの発信元は、（セクションA.1を参照）ルータLSAは、LSAのオプションフィールド内のLビットを設定することにより、「非ackable」であることを示すことができます。それが決定した場合、例えば、ルータが新しいLSA毎MinLSInterval秒の時間の少なくとも90パーセントを発信していること（例えば、指数移動平均に基づいて）非ackable LSAを発信することができます。 （シミュレーションは、最良の閾値を決定するために使用することができます。）
A non-ackable LSA is never acknowledged, nor is it ever retransmitted as a unicast or described in a DD packet, thus saving substantial overhead. However, the originating router must periodically retransmit the current instance of its router-LSA as a multicast (until it originates a new LSA, which will usually happen before the previous instance is retransmitted), and each MDR must periodically retransmit each non-ackable LSA as a multicast (until it receives a new instance of the LSA, which will usually happen before the previous instance is retransmitted). For this option to work, RxmtInterval must be larger than MinLSInterval so that a new instance of the LSA is usually received before the previous one is retransmitted. Note that the reception of a retransmitted (duplicate) LSA does not result in immediate forwarding of the LSA; only a new LSA (with a larger sequence number) may be forwarded immediately, according to the flooding procedure of Section 8.
非ackable LSAは認めされることはありません、またそれは今までので、かなりのオーバーヘッドを節約し、ユニキャストとして再送信またはDDパケットに記述されています。 （それは前のインスタンスが再送信される前に、通常はどうなる新しいLSAを発信するまで）ただし、送信元ルータは定期的にマルチキャストとしてそのルータLSAの現在のインスタンスを再送信しなければならない、と各MDRは、定期的に各非ackable LSA再送信する必要がありますマルチキャストとして（それは前のインスタンスが再送信される前に、通常発生しますLSAの新しいインスタンスを、受信するまで）。このオプションを機能させるには、RxmtIntervalは以前のものが再送信される前に、LSAの新しいインスタンスは通常受信されるようにMinLSIntervalより大きくなければなりません。再送（重複）LSAの受信は、LSAの即時転送をもたらさないことに留意されたいです。 （より大きなシーケンス番号）のみ新しいLSAは、第8のフラッディング手順に従って、即時転送されてもよいです。
Appendix E. Simulation Results
付録E.シミュレーション結果
This section presents simulation results that predict the performance of OSPF-MDR for up to 160 nodes with min-cost LSAs and up to 200 nodes with minimal LSAs. The results were obtained using the GTNetS simulator with OSPF-MDR version 1.01, available at http://hipserver.mct.phantomworks.org/ietf/ospf.
このセクションでは、最小コストのLSAで最大160ノードのため、最小限のLSAで200個のノードまでのOSPF-MDRの性能を予測するシミュレーション結果を示します。結果はhttp://hipserver.mct.phantomworks.org/ietf/ospfで入手可能なOSPF-MDRバージョン1.01、でGTNetSシミュレータを用いて得ました。
The following scenario parameter values were used: radio range = 200 m and 250 m, grid length = 500 m, wireless alpha = 0.5, (maximum) velocity = 10 m/s, pause time = 0, packet rate = 10 pkts/s, packet size = 40 bytes, random seed = 8, start time (for gathering statistics) = 1800 s. The stop time was 3600 s for up to 80 nodes and 2700 s for more than 80 nodes. The source and destination are selected randomly for each generated UDP packet. The simulated MAC protocol is 802.11b.
次のシナリオのパラメータ値を使用した：無線範囲= 200 mおよび250メートル、グリッド長さ= 500 M、無線アルファ= 0.5、（最大）速度= 10のM / Sは、= 0時間を一時停止、パケットレート= 10パケット数/秒、パケットサイズ= 40バイト= 8ランダムシード（収集統計の）開始時間= 1800秒。停止時間は、最大80のノードと80個の以上のノードのための2700秒3600秒でした。ソースおよび宛先は、各発生UDPパケットのためにランダムに選択されます。シミュレートされたMACプロトコルは、802.11bです。
Tables 4 and 6 show the results for the default configuration of OSPF-MDR, except that differential Hellos were used (2HopRefresh = 3) since they are recommended when the number of neighbors is large. Tables 5 and 7 show the results for the same configuration except that minimal LSAs were used instead of min-cost LSAs. The tables show the results for total OSPF overhead in kb/s, the total number of OSPF packets per second, the delivery ratio for UDP packets, and the average number of hops traveled by UDP packets that reach their destination.
表4および6は、近隣の数が多い場合、それらが推奨されているので、その差動ハローズが（2HopRefresh = 3）を用いた以外は、OSPF-MDRのデフォルト設定の結果を示します。表5および7は、その最小のLSAを除いて、同じ構成についての結果ではなく、最小コストのLSAを使用した表示します。表は、KB /秒の総OSPFオーバーヘッド毎秒OSPFパケットの合計数、UDPパケットの到達率、及びそれらの宛先に到達するUDPパケットが移動ホップの平均数の結果を示します。
Tables 5 and 7 for minimal LSAs also show the following statistics: the average number of bidirectional neighbors per node, the average number of fully adjacent neighbors per node, the number of changes in the set of bidirectional neighbors per node per second, and the number of changes in the set of fully adjacent neighbors per node per second. These statistics do not change significantly when min-cost LSAs are used instead of minimal LSAs.
最小のLSAのための表5および7は、以下の統計情報を表示：ノードあたり双方向ネイバーの平均数、ノード当たりの完全隣接ネイバーの平均数、秒あたりのノードあたりの双方向の隣人のセットにおける変化の数、及び数毎秒ノードごとに完全に隣接する近隣の集合の変化。最小コストのLSAはなく、最小限のLSAの使用されている場合、これらの統計が大幅に変更されません。
The results show that OSPF-MDR achieves good performance for up to at least 160 nodes when min-cost LSAs are used, and up to at least 200 nodes when minimal LSAs are used. Also, the results for the number of hops show that the routes obtained with minimal LSAs are only 2.3% to 4.5% longer than with min-cost LSAs when the range is 250 m, and 3.5% to 7.4% longer when the range is 200 m.
結果は、OSPF-MDRは、最小コストのLSAが使用されるまで、少なくとも160個のノードのための良好な性能を達成し、少なくとも200ノードまでの最小のLSAが使用されるときことを示しています。また、ホップ数の結果は、ルートが最小のLSAを用いて得られたことを示す最小コストのLSAよりものみ2.3％〜4.5％、より長い範囲が200である場合範囲が長く7.4％〜250 M、および3.5％である場合メートル。
The results also show that the number of adjacencies per node and the number of adjacency changes per node per second do not increase as the number of nodes increases, and are dramatically smaller than the number of neighbors per node and the number of neighbor changes per node per second, respectively. These factors contribute to the low overhead achieved by OSPF-MDR. For example, the results in Table 5 imply that with 200 nodes and range 250 m, there are 2.136/.039 = 55 times as many adjacency formations with full-topology adjacencies as with uniconnected adjacencies. Additional simulation results for OSPF-MDR can be found at http://www.manet-routing.org.
結果はまた、ノードごと隣接の数と、毎秒当たりのノード隣接関係の変更の数は、ノードの数が増加するにつれて増加しないことを示し、ノード当たりの近隣の数及びノード当たりの隣接変更の数よりも大幅に小さくなっていますそれぞれ、毎秒。これらの要因は、OSPF-MDRによって達成低いオーバーヘッドに貢献します。例えば、表5の結果は、200個のノードおよび範囲250メートルで、uniconnected隣接関係と同様にフルトポロジー隣接を有する多くの隣接地層として2.136 / 0.039 = 55時間があることを示唆しています。 OSPF-MDRのための追加のシミュレーション結果はhttp://www.manet-routing.orgで見つけることができます。
Number of nodes
20 40 60 80 100 120 160
------------------------------------------------------------------
OSPF kb/s 27.1 74.2 175.3 248.6 354.6 479.2 795.7
OSPF pkts/s 29.9 69.2 122.9 163.7 210.3 257.2 357.7
Delivery ratio .970 .968 .954 .958 .957 .956 .953
Avg no. hops 1.433 1.348 1.389 1.368 1.411 1.361 1.386
Table 4: Results for range 250 m with min-cost LSAs
表4：最小コストのLSAとの範囲に対する結果250メートル
Number of nodes
20 40 60 80 120 160 200
------------------------------------------------------------------
OSPF kb/s 15.5 41.6 91.0 132.9 246.3 419.0 637.4
OSPF pkts/sec 18.8 42.5 78.6 102.8 166.8 245.6 321.0
Delivery ratio .968 .968 .951 .953 .962 .956 .951
Avg no. hops 1.466 1.387 1.433 1.412 1.407 1.430 1.411
Avg no. nbrs/node 11.38 25.82 36.30 50.13 75.87 98.65 125.59
Avg no. adjs/node 2.60 2.32 2.38 2.26 2.25 2.32 2.13
Nbr changes/node/s .173 .372 .575 .752 1.223 1.654 2.136
Adj changes/node/s .035 .036 .046 .040 .032 .035 .039
Table 5: Results for range 250 m with minimal LSAs
表5：最小のLSAと範囲250メートルのための結果
Number of nodes
20 40 60 80 100 120 160
------------------------------------------------------------------
OSPF kb/s 40.5 123.4 286.5 415.7 597.5 788.9 1309.8
OSPF pkts/s 37.6 83.9 135.1 168.6 205.4 247.7 352.3
Delivery ratio .926 .919 .897 .900 .898 .895 .892
Avg no. hops 1.790 1.628 1.666 1.632 1.683 1.608 1.641
Table 6: Results for range 200 m with min-cost LSAs
表6：最小コストのLSAと領域200 mに対する結果
Number of nodes
20 40 60 80 120 160 200
------------------------------------------------------------------
OSPF kb/s 24.0 63.6 140.6 195.2 346.9 573.2 824.6
OSPF pkts/sec 26.4 58.8 108.3 138.8 215.2 311.3 401.3
Delivery ratio .930 .927 .897 .907 .907 .904 .902
Avg no. hops 1.853 1.714 1.771 1.743 1.727 1.758 1.747
Avg no. nbrs/node 7.64 18.12 25.27 35.29 52.99 68.13 86.74
Avg no. adjs/node 2.78 2.60 2.70 2.50 2.39 2.36 2.24
Nbr changes/node/s .199 .482 .702 .959 1.525 2.017 2.611
Adj changes/node/s .068 .069 .081 .068 .055 .058 .057
Table 7: Results for range 200 m with minimal LSAs
表7：最小のLSAと領域200 mに対する結果
Authors' Addresses
著者のアドレス
Richard G. Ogier SRI International
リチャード・G・オジェSRIインターナショナル
EMail: rich.ogier@earthlink.net or rich.ogier@gmail.com
Eメール：rich.ogier@earthlink.netまたはrich.ogier@gmail.com
Phil Spagnolo Boeing Phantom Works
フィル・Spagnoloファントムワークス
EMail: phillipspagnolo@gmail.com
メールアドレス：phillipspagnolo@gmail.com