[要約] 要約：RFC 5614は、Mobile Ad Hoc Network (MANET)におけるOSPFの拡張であり、Connected Dominating Set (CDS) Floodingを使用しています。 目的：このRFCの目的は、MANET環境での効率的なルーティングプロトコルを提供するために、CDSフラッディングを使用したOSPFの拡張を定義することです。
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
コネクテッドドミネートセット（CDS）洪水を使用したOSPFのモバイルアドホックネットワーク（MANET）拡張
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.
このドキュメントは、モバイルアドホックネットワーク（MANETS）をサポートするOSPFV3の拡張を指定しています。OSPF-MDRと呼ばれる拡張機能は、MANETの新しいOSPFインターフェイスタイプとして設計されています。OSPF-MDRは、MANET指定ルーター（MDR）とバックアップMDRで構成されるMANETルーターのサブセットの選択に基づいています。MDRは接続された支配セット（CD）を形成し、MDRとバックアップMDRは一緒になって、堅牢性のためにバイコン化されたCDを形成します。このCDは2つの方法で悪用されています。まず、洪水のオーバーヘッドを減らすために、最適化された洪水手順が使用されます。この手順では、（バックアップ）MDRが新しいリンク状態広告（LSA）が受信インターフェイスを取り戻します。LSAを隣接に沿って再送信することにより、信頼できる洪水が確保されます。第二に、隣接は（バックアップ）MDRと隣人のサブセットの間でのみ形成され、密なネットワークでのより良いスケーリングが可能になります。CDSは、Hello Protocol拡張機能で提供される2ホップの隣接情報を使用して構築されます。Helloプロトコルは、近隣状態の変更のみを報告する微分Hellosを許可することにより、さらに最適化されています。完全または部分的なトポロジー情報を提供するルーター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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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拡張は、Layer-3ルーティングを使用した非モバイルメッシュネットワークにも適用できます。この拡張機能は、既存のOSPFインターフェイスタイプの使用を排除するものではなく、Legacy 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インターフェイスタイプは、洪水プロトコルの操作に関するスケーリングの問題、指定されたルーター選挙プロトコルがすべてのシナリオで収束できないこと、およびポイントツーマルチポイントインターフェイスタイプを使用する場合の多数の隣接を使用できないため、マネーでは適切に機能しません。
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の概念をマルチホップワイヤレスネットワークに一般化することです。一般化された（バックアップ）指定ルーターは、（バックアップ）マネに指定されたルーター（MDR）と呼ばれます。MDRSは接続された支配セット（CD）を形成し、MDRとバックアップMDRは一緒になって、堅牢性のためにバイコン化されたCDを形成します（ネットワーク自体がバイコン接続されている場合）。定義上、マネの各ルーターはCDに属しているか、そこから1つのホップです。分散アルゴリズムを使用して、バイコン接続CDを選択して動的に維持します。隣接は（バックアップ）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.
Hello Packetは、OSPF Link-Local Signaling（LLS; [RFC5613]を参照）を使用して変更されます。隣国の変化。ヘロスは、トポロジの変化に迅速に対応するために、オーバーヘッドを大幅に増加させることなく、より頻繁に送信できます。
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のポイントツーポイントリンクとして、マネの隣人のサブセットを宣伝しています。どの隣人が宣伝するかの選択は柔軟であり、より少ないトポロジ情報を宣伝することでオーバーヘッドを減らすことができます。完全なトポロジー情報または部分的なトポロジー情報を提供するルーター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では、OSPF-MDRの概要を示します。セクション3では、拡張機能に必要な新しいインターフェイスと近隣データ項目を示します。セクション4では、2ホップ隣接情報を維持する手順を含むハロープロトコルについて説明します。セクション5ではMDRについて説明します。選択アルゴリズムのセクション6では、インターフェイス状態マシンの変更について説明します。セクション7では、隣接を形成し、どの隣接が隣接するべきかを決定する手順について説明します。セクション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選択アルゴリズムの詳細なアルゴリズム、Router-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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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インターフェイスMANETインターフェイスは、ブロードキャスト対応のマルチホップワイヤレスネットワークをサポートする新しいOSPFインターフェイスタイプです。Manetインターフェイス上の2つの隣接するルーターは、互いに直接通信できない場合があります。Manetインターフェイス上の隣接するルーターは、Manet Neighborと呼ばれます。MANETの隣人は、OSPFのHello Protocolの変更を使用して動的に発見されます。
MANET Router A MANET Router is an OSPF router that has at least one MANET interface.
MANETルーターMANETルーターは、少なくとも1つの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.
ディファレンシャルハローディファレンシャルハローは、最近変更された隣人のルーターIDのみを含めることにより、完全なHellosの送信のオーバーヘッドを減らすハローパケットです。
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ホップ隣人情報この情報は、各隣人の双方向の隣人を指定します。変更されたハロープロトコルは、各MANETルーターに2ホップの隣接情報を提供します。これは、MDRとバックアップMDRの選択に使用されます。
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.
MANET指定ルーター（MDR）MANET指定ルーターは、新しいLSAの洪水、および形成する必要がある一連の隣接を決定するためのルーターのセットの1つです。MDRSのセットは、接続された支配セットを形成し、ブロードキャストネットワークで見つかったDRの一般化です。各ルーターは、各MANETインターフェイスのMDR選択アルゴリズムを実行して、ルーターがMDR、バックアップ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指定ルーター（バックアップMDRまたはBMDR）は、隣接するMDRが失敗したときにバックアップ洪水を提供するバックアップマネに指定されたルーターの1つです。MDRとバックアップMDRのセットは、バイコン接続の支配セットを形成します。バックアップ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の他の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は、インターフェイスで送信された各Helloの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.
バックアップ親は、バイコン接続の隣接のオプションが選択されている場合、各MDRはバックアップ親を選択します。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.
routable隣人SPF計算が隣人へのルートを作成し、隣人が質の高い状態を満たした場合、双方向のマネの隣人がルーティング可能になります。隣人がルーティング可能になると、双方向のままである限り、それはルーティング可能なままです。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 An-Flooding MDRは、受信インターフェイスからLSAを自動的にfloodしないが、BMDRのようにバックアップ洪水を実行するMDRです。一部の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-MDRは、OSPFをサポートするためにOSPFを拡張したいという願望に動機付けられ、OSPFと同じデザイン哲学を維持し、OSPFの技術に似た技術を使用しました。たとえば、OSPFは、指定されたルーター（DR）とバックアップDRを選択することにより、ブロードキャストネットワークのオーバーヘッドを削減し、2つの隣接するルーターがDRまたはバックアップDRである場合にのみ隣接能力を形成することにより、オーバーヘッドを削減します。このアイデアは、スパニングツリーを形成することによりマルチホップワイヤレスネットワークに一般化できます。ツリーのエッジは、隣接する隣接（葉以外の）ノードであり、ツリーの内部（非葉）ノードは、MANET指定ルーター（MDR）と呼ばれる一般化されたDRSです。
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).
トポロジーの変化に対する堅牢性と迅速な応答を提供するために、ルーターは、それがNeighborsのHellosから取得できるローカル情報のみに基づいてMDRであるかどうかを決定する必要があることが決定されました。したがって、結果として生じる一連の隣接は、常にグローバルに木を形成するわけではありませんが、局所的な木のように見えます。同様に、バックアップDRは、バックアップMDR（BMDR）に一般化して、バイコンな冗長性を通じて堅牢性を提供できます。MDRSのセットは、接続された支配セット（CD）を形成し、MDRとBMDRのセットはバイコン化された支配セットを形成します（ネットワーク自体がバイコン接続されている場合）。
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、BMDR、および隣接が選択された方法の要約から始まる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選択アルゴリズムが分散されています。各ルーターは、近隣から受け取ったハローパケットから取得されるワンホップ近隣に関する情報に基づいて、MDR、BMDR、またはその他のルーター（「MDRその他」と呼ばれる）として選択します。ルーターは、タプル（RTRPRI、MDRレベル、RID）に基づいて辞書化されています。ここで、RTRPRIはルーターの優先順位です。MDRレベルはルーターの現在の状態を表します（MDRの場合は2、BMDRの場合は1、MDRの場合は0）、およびRIDはルーターIDです。（RTRPRI、MDRレベル、RID）の辞書的に大きい値を持つルーターは、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）の隣人を示します。次に、ルーターは、各隣接がRMAXからほとんどのKホップでRMAXから到達できる場合を除きます。これは、ルーター自体よりも（RTRPRI、MDRレベル、RID）の値が大きいネイバーを介して、パラメーターMDRConstraintであり、デフォルト値は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.
同様に、MDRとしてそれ自体を選択しないルーターは、2つのノードダイジョインストパスを介して各隣接がRMAXから到達できない限り、それ自体をBMDRとして選択します。、red）ルーター自体よりも。
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ルーターを選択し、すべてのルーターが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.
バイコン接続隣接のオプションが選択されている場合（adcononectivity = 2）、MDRとBMDRのセット、およびそれらの間の隣接がバイコンバックボーンを形成することを確認するために追加の隣接が選択されます。この場合、他の各MDRは、親に加えて、バックアップ親と呼ばれるMDR/BMDR隣接と隣接するものになります。
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選択はオプションですが、BMDRはバックアップ洪水を提供することで堅牢性を改善するため推奨されます。
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）を受信すると、そのような洪水が不要であると判断できない限り、LSAが受信インターフェイスに戻ります（セクション8.1で指定されています）。ルーターは、LSAの洪水をわずかにランダムな時間（たとえば100ミリ秒未満）に遅らせる可能性があります。遅延洪水は、同じリンク状態更新パケットで複数の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をflook濫させたり認めたりしていない隣人がいる場合にのみ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他のルーターは、レシーブインターフェイスをflosedしないでください。マネの放送の性質を活用するために、州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は、暗黙の承認として扱われます。リンク状態の謝辞は、同じパケット内の複数の承認を合体化できるように遅延する場合があります。唯一の例外は、（バックアップ）MDRSが、追加の再送信を防ぐために、複製LSAがユニキャストとして受信されるとすぐにマルチキャストリンク状態の確認を送信することです。隣接する隣人からのリンク状態の謝辞のみが処理され、再送信された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.
OSPFでは、隣人は通常、SPF計算で使用されるために完全に隣接（状態フル）でなければなりません。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.
MANETの隣人が双方向であり、SPF計算が隣人へのルートを生み出した場合、ルーティング可能になります。（柔軟な品質条件も必要になる場合があります。）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に隣接していない隣人を明示的に含める必要があります。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と呼ばれ、LSAFullness = 0に対応します。ただし、多数のノードを使用してネットワークのスケーラビリティを実現するのに役立ちます。
At the other extreme, if LSAFullness = 4, then the router originates a full-topology LSA, which includes all routable and Full neighbors.
もう1つの極端な場合、Lsafullness = 4の場合、ルーターはすべてのルーティング可能な隣人と完全な隣人を含む全トポロジー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.
LSAFullnessを1に設定すると、最小（最小コスト）パスに沿ったルーティングを提供するMin-COST LSAの結果が得られます。各ルーターは、隣人のHellosから取得した2ホップの近隣情報に基づいて、ルーターLSAにどの隣人を含めるかを決定します。各ルーターには、LSAには、隣人の各ペア間の最短経路を提供するために必要な隣接する最小セットが含まれています。
Setting LSAFullness to 2 also provides shortest-path routing, but allows the router to advertise additional neighbors to provide redundant routes.
Lsafullnessを2に設定することも最短パスルーティングを提供しますが、ルーターは追加の隣人を宣伝して冗長なルートを提供することができます。
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.
LSAFullnessを3つに設定してMDRフルLSAで結果をもたらし、各MDRがフルトポロジーLSAを発生させ、他のルーターは最小限のLSAを発生させます。この選択は、最短パスに沿ったルーティングを提供するものではありませんが、シミュレーションにより、オーバーヘッドが比較的低いほぼ最短パスに沿ってルーティングを提供することが示されています。
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に隣接の最小セットを含める必要があるため、ルーター-LSAの構築（セクション9.4で説明）が異なるルーター-LSAが異なることによって発生することを保証するためルーターは一貫しています。すべてのルーターがlsafullnessを1、2、または4に選択した場合にのみ、最短パスに沿ったルーティングが提供されます。
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選択アルゴリズムとMINで使用される双方向の隣人のセットとその他の情報を示すために、Link-Local Signaling（LLS）を使用してHelloパケットに追加情報を追加します。-COST LSAアルゴリズム。OSPFV3 HELLOSと同じ近隣IDを含むFull Hellosに加えて、OSPF-MDRは、状態（またはその他の情報）が最近変更された隣人のIDのみを含む差動Hellosの使用を許可します（最後のHellorePeatCount内でHellos）。
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.
HellosはすべてのHelloInterval秒を送信されます。完全なHellosは2hoprefresh Hellosごとに送信され、Hellosは他のすべての時間に送信されます。たとえば、2hoprefreshが3に等しい場合、3分の1のHelloは完全なHelloです。2hoprefreshのデフォルト値は1です。つまり、デフォルトは完全なHellosのみを送信することです。HelloIntervalのデフォルト値は2秒です。微分Hellosは、頭上を減らし、トポロジーの変化に対するより速い反応のために、Hellosをより頻繁に送信できるようにするために使用されます。
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レベルはMDR（値2）に等しく、ルーターがバックアップMDRである場合、バックアップMDR（値1）、MDRは他の場合（値0）。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のバックアップ親はルーター自体です。バイコン接続隣接のオプションが選択されている場合、各MDR他の人がバックアップ親を選択します。バックアップの親は0.0.0.0に初期化され、バックアップの親がいないことを示します。各ルーターは、インターフェイスで送信された各ハローのバックアップ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-Hello TLVが運ぶ16ビットシーケンス番号。HSNは、ハローパケットがインターフェイスに送信されるたびに1（Modulo 2^16）で増加します。
MDRNeighborChange A single-bit variable set to 1 if a neighbor change has occurred that requires the MDR selection algorithm to be executed.
mdrneighborchange MDR選択アルゴリズムを実行する必要がある隣接する変更が発生した場合、単一ビット変数を1に設定します。
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、RouterDeadedInterval、および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のデフォルト構成では、最短パスルーティング（LSAFULLNESS = 1）を提供するユニコン接続隣接（adcononectivity = 1）および部分トポロジLSAを使用します。これは、最短パスルーティングを提供する最もスケーラブルな構成です。特別な状況では、他の構成が望ましい場合があります。たとえば、LSAFullnessを4に設定すると、全トポロジーLSAが提供され、LSAFullnessを0に設定すると、最小限のLSAを最小限に抑えますが、最短パスルーティングを保証しません。2へのadjconnectivityを設定すると、バイコン接続された隣接サブグラフを提供し、アジャンコネクティティを0に設定することにより、フルトポロジーの隣接が得られます。
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).
新しいインターフェイスパラメーターのすべての可能な構成は機能的ですが、補正性が0の場合（フルトポロジー隣接）、Lsafullnessは1、2、または4でなければなりません（セクション9.3を参照）。
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.
微分Hellosは、隣人の平均数が大きい場合（たとえば、50を超える）、ハローパケットのサイズを減らすために使用する必要があります。差分Hellosは、パラメーター2Hoprefreshを1より大きい整数に設定することで取得されます。推奨値は3です。最大160ノードのシミュレートされたモバイルネットワークの良好なパフォーマンスは、差動Hellosのデフォルト構成を使用して取得されました。最小のLSA（LSAFullness = 0）を除き、同じ構成を使用して、最大200ノードのシミュレートされたモバイルネットワークの良好なパフォーマンスが取得されています。シミュレーション結果は、付録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のオプション値に等しい場合、隣接セットはバイコングラフを形成します。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.
MDRConstraint MDR選択アルゴリズムのパラメーターは、選択されたMDRの数に影響し、2以上の整数でなければなりません。値が3を超えると、MDRがわずかに少なくなり、値2がMDRの数が多いことになります。
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 LSAに浸水するかどうかを決定する前に、バックアップMDRが新しい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で宣伝すべきルーターがどの隣接するかを決定します。値0は、「バックボーン」の隣人のみを含む最小限のLSAをもたらします。値1と2は、最短パスルーティングを提供する部分トポロジーLSAをもたらし、値2は冗長ルートを提供します。値3は、最小限のLSAを発信するフルトポロジーLSAおよびその他のルーターを発信するMDRをもたらします。値4は、フルトポロジーLSAを発信するすべてのルーターをもたらします。デフォルト値は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 hellosごとに1つは完全な挨拶でなければなりません。他のすべてのHellosは差があります。デフォルト値は1です。つまり、デフォルトは完全なHellosのみを送信することです。微分Hellosを使用する場合、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差が使用されている場合、州の変更時に隣人を含める必要がある連続したHellosの数。このパラメーターは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に含まれるハローシーケンス番号。
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.
AビットAビットは、隣人から受け取った最後のHelloのMDR-Hello TLVからコピーされました。このビットは、隣人がフルトポロジーの隣接を使用している場合、つまり隣接削減を使用していない場合に1です。
FullHelloRcvd A single-bit variable equal to 1 if a full Hello has been received from the neighbor.
FullHellorCVD隣人から完全な挨拶を受け取った場合、1に等しい単一ビット変数。
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.
NeighborのMDRレベル隣人またはMDR-DD TLVから受信したDRおよびバックアップDRフィールドのDRおよびバックアップDRフィールドに基づいて、隣人からMDR-DD TLVから受け取ったMDR-DD TLVから、隣人から受信したパケット（DD）パケット。
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.
隣人の親は、隣人から受け取ったDDパケットから受け取った最後のハローパケットのDRフィールドから取得された親のための隣人の選択。
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.
隣人のバックアップ親は、隣人から受け取ったDDパケットで受け取った最後のハローパケットのバックアップDRフィールドから取得したバックアップ親のための隣人の選択。
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に等しい1つのビット変数が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.
隣人が選択された広告隣人である場合、選択された広告隣人（SAN）1に等しい単一ビット変数。選択された広告の隣人は、ルーター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）隣人の双方向の隣人のセットは、隣人からこんにちはが受け取られたときに更新されます。
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）隣人の依存した隣人のセット。
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）は、隣人からhelloが受け取られたときに更新される隣人の選択された隣人のセットです。
Neighbor's Link Metrics The link metric for each of the neighbor's bidirectional neighbors, obtained from the Metric TLV appended to Hello packets.
NeighborのリンクメトリックHelloパケットに追加されたメトリックTLVから取得した隣人の双方向の各隣接体のリンクメトリック。
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ホップの隣人情報を学習できるようにするためにHellosを利用しています。プロトコルは、完全または微分Hellosを使用できるため、柔軟です。完全なHellosは、OSPFV3のように、状態以下のインターフェイス上のすべての隣人をリストしますが、差分Hellosは、双方向の隣人、依存している隣人、または選択された宣伝された隣人としての地位が最近変更された隣人のみをリストしています。微分Hellosは頭上を減らすために使用され、Hellosをより頻繁に送信できるようにします（トポロジの変化に対するより速い反応のため）。微分Hellosが使用されている場合、すべての隣人が現在の2ホップの隣接情報を確保するために、完全なHellosはあまり頻繁に送信されます。
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.
こんにちはパケットは、[RFC5340]、セクション4.2.1.1、および[RFC2328]、セクション9.5に従って送信されます。次のMANET固有の仕様は、セクション9.5のパラグラフ3以降に始まります。Hello Packet形式は、[RFC5340]、セクションA.3.2で定義されています。ただし、以下に説明するように、隣接IDの順序とDRおよびバックアップDRフィールドの意味を除きます。
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).
HellosはすべてのHelloInterval秒を送信されます。完全なHellosは2hoprefresh Hellosごとに送信され、Hellosは他のすべての時間に送信されます。たとえば、2hoprefreshが3に等しい場合、3分の1のHelloは完全なHelloです。2hoprefreshが1に設定されている場合、すべてのHellosがいっぱいです（デフォルト）。
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:
各Helloの本体に含まれるNeighbor IDは、次の5つのnightointリストに分割されています（その一部は空になる可能性があります）、次の順序で表示する必要があります。
List 1. Neighbors whose state recently changed to Down (included only in differential Hellos).
リスト1.州が最近下に変更された隣人（微分Hellosにのみ含まれています）。
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.
リスト3〜5のすべての隣人は双方向の隣人であることに注意してください。これらのリストは、Helloが受信されたときに、隣人の双方向の隣接セット（BNS）、依存した隣接セット（DNS）、および選択された広告隣接セット（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.
Link-Local Signaling（LLS）を使用して、各MANET Hello Packetに最大2つのTLVを追加します。LLSの形式は、セクションA.2に記載されています。MDR-HELLO TLVは、それぞれ（完全または微分）マネットハローパケットに追加されます。Helloが完全か微分であるか、上記の各リスト1〜4のHello Sequence番号（HSN）と近隣IDの数を与えるかを示します。リスト5のサイズは、Helloのパケット長フィールドによって暗示されます。MDR-Hello TLVの形式は、セクションA.2.3に示されています。
In both full and differential Hellos, the appended MDR-Hello TLV is built as follows.
完全なHellosと微分Hellosの両方で、Appreded Mdr-Hello 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が増加します（Modulo 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-Hello TLVのDビットは、微分Helloの場合は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-HELLO 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にあるHelloのボディの近隣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-Metric TLV（またはMetric TLV）は、インターフェイス上の各双方向の隣人へのリンクコストを宣伝し、隣人の選択が部分トポロジーLSAに含めることができるようにします。lsafullnessが1または2の場合、すべてのリンクコストが1でない限り、メトリックTLVを各MANETハローパケットに追加する必要があります。メトリックTLVの形式はセクションA.2.5に記載されています。メトリックTLVのIビットは0または1に設定できます。Iビットが0に設定されている場合、メトリックTLVには隣接IDが含まれておらず、（フルまたは微分）にリストされている各双方向隣接のメトリックが含まれています。こんにちは、同じ順序で。iビットが1に設定されている場合、メトリックTLVには、メトリックがTLVのデフォルトメトリックフィールドに等しくないHelloにリストされている各双方向隣接の隣接IDとメトリックが含まれます。
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.
メトリックTLVのサイズを最小限に抑えるために、Iビットを選択する必要があります。これは、メトリックがデフォルトのメトリックフィールドと異なるHelloにリストされている双方向隣接の数が、Helloにリストされている双方向隣人の総数の1/3未満である場合にのみ、iビットを1にすることを選択することで達成できます。。
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ビットは1に設定する必要があります。デフォルトのメトリックはこのメトリックに等しく、TLVに近隣IDと対応するメトリックを含める必要性を回避します。もう一方の極端な場合、すべての隣人が異なるメトリックを持っている場合、I BITは0に設定して、Hello TLVとメトリックTLVのボディの両方に同じ隣接IDをリストすることを避けます。
In both full and differential Hello packets, the L bit is set in the Hello's option field to indicate LLS.
完全なハローパケットと微分の両方のパケットの両方で、LビットはLLSを示すためにHelloのオプションフィールドに設定されています。
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リストには、上記の順序で、状態init以上のインターフェイス上のすべての隣人が含まれています。MDR-Hello TLVは、上記のように構築されています。メトリックTLVが追加されている場合、セクションA.2.5で指定されているように構築されています。
In a differential Hello, the five neighbor ID lists defined in Section 4.1 are populated as follows:
微分Helloでは、セクション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 Hellosにまだ含まれていない状態ダウンの各隣人が含まれています。
List 2 includes each neighbor in state Init that has not yet been included in HelloRepeatCount Hellos since transitioning to this state.
リスト2には、この州に移行して以来、Hellorepeatcount Hellosにまだ含まれていない州の各隣人が含まれています。
List 3 includes each Dependent Neighbor that has not yet been included in HelloRepeatCount Hellos since becoming a Dependent Neighbor.
リスト3には、扶養隣人になって以来、Hellorepeatcount Hellosにまだ含まれていない各扶養隣人が含まれています。
List 4 includes each Selected Advertised Neighbor that has not yet been included in HelloRepeatCount Hellos since becoming a Selected Advertised Neighbor.
リスト4には、選択された広告の隣人になって以来、Hellorepeatcount Hellosにまだ含まれていない選択された各広告隣人が含まれています。
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 Hellosにまだ含まれていない選択されていない双方向隣人（セクション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がHelloに追加された場合、そのメトリックが最後に変更されて以来、HellorepeatCount Hellosにまだ含まれていない場合、双方向の隣人を（適切なリストに）含める必要があります。
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.
MANETインターフェイスで受信したハローパケットは、[RFC5340]、セクション4.2.2.1、および[RFC2328]の最初の2つの段落、セクション10.5で説明されているように処理され、次に以下に指定された処理が続きます。
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によって識別されます。一致する隣人がインターフェイスのデータ構造で見つからない場合、1つはOSPFパケットヘッダーにあるルーターIDに設定されたネイバーIDで作成されます。初期化され、隣人の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.
隣接構造のルーターの優先度は、受信したハローパケットの対応するフィールドの値に設定されます。隣人の親はDRフィールドの価値に設定され、隣人のバックアップ親はバックアップ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 Packetの残りの部分が調べられ、近隣およびインターフェイス状態マシンに与えられるイベントを生成します。これらの状態マシンは、実行またはスケジュールされるように指定されています（[RFC2328]、セクション4.4、「タスクサポート」を参照）。たとえば、近隣の状態マシンを並べて実行することを以下に指定することにより、いくつかの近隣の州の移行は、helloを受け取った単一の影響を受ける可能性があります。
o If the L bit in the options field is not set, then an error has occurred and the Hello is discarded.
o オプションフィールドのLビットが設定されていない場合、エラーが発生し、ハローが破棄されます。
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.
o LLSにMDR-Hello TLVが含まれている場合、近隣の状態マシンはイベントとともに実行されます。それ以外の場合、エラーが発生し、Helloが破棄されます。
o The Hello Sequence Number and the A-bit in the MDR-Hello TLV are copied to the neighbor's data structure.
o MDR-Hello 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.
(1) DRフィールドが隣人のルーターIDに等しい場合、隣人の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.
Helloの隣接IDリストは、次のように分割されます。セクション4.1で定義された5つのリストで、N1、N2、N3、およびN4はMDR-Hello TLVの対応するフィールドから取得されます。リスト1は最初のN1ネイバーIDであると定義され、リスト2は次のN2ネイバーIDであると定義され、リスト3は次のN3ネイバーIDであると定義され、リスト4は次のN4ネイバーIDであると定義され、リスト5は、Helloの残りの隣接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.
Helloのさらなる処理は、MDR-Hello TLVのDビットの値によって示される、それが完全か微分であるかによって異なります。
If the received Hello is full (the D-bit of the MDR-Hello TLV is 0), the following steps are performed:
受信したHelloがいっぱいである場合（MDR-Hello 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.
o MDR-Hello TLVのN1フィールドがゼロでない場合、エラーが発生し、Helloは破棄されます。それ以外の場合は、fullhellorcvdを1に設定します。
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 近隣の構造では、隣人のDNSを変更して、Helloのリスト3の近隣IDのセットに等しくなり、Helloのリスト4の近隣IDのセットに等しく隣接するIDを変更し、隣人のBNSを変更して隣人のセットに等しくなります。リスト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.
o HelloのNeighbor IDリストにルーター自体が表示される場合、Helloが処理された後、Neighbor State Machineは2ウェイレジットで実行されます。それ以外の場合、Helloが処理された後、Neighbor State Machineは1ウェイレジットされたイベントで実行されます。
If the received Hello is differential (the D-bit of the MDR-Hello TLV is 1), the following steps are performed:
受信したHelloが微分である場合（MDR-Hello TLVのDビットは1）、次の手順が実行されます。
(1) For each neighbor ID in List 1 or List 2 of the Hello:
(1) helloのリスト1またはリスト2の各隣接IDについて：
o Remove the neighbor ID from the neighbor's DNS, SANS, and BNS, if it belongs to the neighbor set.
o 隣人セットに属している場合、隣人のDNS、SANS、およびBNSから隣人IDを削除します。
(2) For each neighbor ID in List 3 of the Hello:
(2) helloのリスト3の各隣人IDについて：
o Add the neighbor ID to the neighbor's DNS and BNS, if it does not belong to the neighbor set.
o 近隣のIDを隣人のDNSとBNSに追加します。
o Remove the neighbor ID from the neighbor's SANS, if it belongs to the neighbor set.
o 隣人のセットに属している場合は、隣人のサンから隣人IDを削除します。
(3) For each neighbor ID in List 4 of the Hello:
(3) helloのリスト4の各隣人IDについて：
o Add the neighbor ID to the neighbor's SANS and BNS, if it does not belong to the neighbor set.
o 近隣のIDを隣人のSANSとBNSに追加します。
o Remove the neighbor ID from the neighbor's DNS, if it belongs to the neighbor set.
o 隣のDNSから隣のDNSから隣のIDを削除します。
(4) For each neighbor ID in List 5 of the Hello:
(4) Helloのリスト5の各隣接IDについて：
o Add the neighbor ID to the neighbor's BNS, if it does not belong to the neighbor set.
o ネイバーのBNSに隣のIDを追加します。
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.
(5) ルーター自身のRIDがリスト1に表示されている場合は、Helloが処理された後にイベントを1ウェイレシーで使用して近隣ステートマシンを実行します。
(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) ルーター自身のRIDがリスト2、3、4、または5に表示されている場合、Helloが処理された後、イベントを2ウェイレシーで使用してNeighbor Stateマシンを実行します。
(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がHelloの隣人IDリストに表示されず、近隣状態が2方向以上であり、Hello Sequence番号が以前のシーケンス番号とHellorePeatCount以下である場合、Neighbour StateマシンはHello Is Processed（状態は変更されない）後に2ウェイレシーブされたイベントで実行されます。
(8) If 2-WayReceived is not executed, then 1-WayReceived is executed after the Hello is processed.
(8) 2 wayreceivedが実行されない場合、Helloが処理された後、1ウェイレシーブが実行されます。
The following applies to both full and differential Hellos.
以下は、完全なHellosと微分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変数は、Helloの処理の結果として次の変更が発生した場合、1に設定されます。
o The neighbor's state changed from less than 2-Way to 2-Way or greater, or vice versa.
o 隣人の状態は、2方向未満から2ウェイ以上、またはその逆に変更されました。
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:
Neighbor State Machineは、イベントAdjokでスケジュールされていますか？以下の変更が発生した場合、Helloを処理した結果として：
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.
ワイヤレスネットワークでは、隣人がほとんど範囲外であるため、接続が不十分な隣人から1つのHelloを受信できます。質の低い隣人を受け入れないようにし、ヒステリシスを採用するために、ルーターは、マネの隣人の状態をダウンからイニシ材以上に変更する前に、より厳しい状態を満たす必要がある場合があります。この条件は「隣人受け入れ条件」と呼ばれ、デフォルトでは単一のHelloまたはDDパケットの受信です。たとえば、隣人の受け入れ条件では、隣人の状態をDownからInitに変更する前に、2連続のHellosを隣人から受け取ることを要求する場合があります。他の可能な条件には、3つの連続したHellosの受信、または最後の3つのHellosのうち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.
したがって、隣人の受け入れ条件に依存するように、州のダウンとイベントの地獄のイベントの移行が修正され（セクション7.1を参照）（セクション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).
このセクションでは、各MANETインターフェイスに対して実行されるMDR選択アルゴリズムについて説明し、ルーターがMDR、バックアップMDR、またはそのインターフェイスのその他のMDRであるかどうかを判断します。このアルゴリズムは、どの隣人と（バックアップ）親を選択します。
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.
MDRNeighborChangeビットがインターフェイスに設定されている場合、MDR選択アルゴリズムはHelloを送信する直前に実行する必要があります。また、双方向の隣接が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.
実装を簡素化するために、MDRNeighborchangeビットをいつ設定する必要があるかを判断する必要がないように、各ハローを送信する直前にMDR選択アルゴリズムを定期的に実行できます。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にバックアップリレーを提供することです。MDRSのセットはCDを形成し、MDRSとバックアップMDRのセットはバイコン接続CDを形成します（ネットワーク自体がバイコン接続されている場合）。
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が追加（バックアップ）MDRネイバーで隣接して隣接してバイコン接続のバックボーンを形成し、他の各MDRはバックアップ親と呼ばれる2番目の（バックアップ）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選択アルゴリズムは、Hellosから取得した2ホップの隣接情報を使用する分散CDSアルゴリズムです。より具体的には、双方向隣接のセット（状態2方向以下）、各隣接とルーター自体のトリーター（ルーターの優先度、MDRレベル、ルーターID）、および隣接変数の双方向の隣接を使用して、入力として使用します。そのような隣人ごとにセット（bns）とfullhellorcvd。MDR選択アルゴリズムは、O（d^2）時間で実装できます。ここで、Dは近隣の数です。
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、MDRレベル、RID）は、ルーター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であるかどうか、およびadjConnectivity = 2の場合、どの追加のMDR/BMDRネイバーが依存しているかを決定します。フェーズ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他のルーターは親を選択する必要はありません。また、Adconectivityが0または1の場合、フェーズ3（BMDR選択）は必要ありません。ただし、adjConnectivityが2の場合はフェーズ3を実行する必要があり、バックアップ洪水を提供することによりbmdrsが堅牢性を改善するため、adconectivityが0または1の場合は実行する必要があります。
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として選択したルーターは、フェーズ5を実行して、それ自体が非フローリングMDRであると宣言する可能性があります。非フローディング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選択アルゴリズムについて説明します。便利なため、「bi-neighbor」という用語は、「双方向隣人」の略語として使用されます。
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は、インターフェイス上のBi-neighborsのセットのトポロジグラフを定義する対称マトリックスです。NCMは、Bi neighborの各ペアに対して0または1の値を割り当てます。1の値は、近隣がMDR選択アルゴリズムで互いに双方向であると想定されていることを示しています。ルーター自体を表すと、NCM（I、J）とNCM（J、I）は、各Bi-Neighbor jに対して1に設定されています。マトリックスの値は、インターフェイス上のbi-neighbors 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）neighbors jとk：ncm（j、k）= ncm（k、j）の両方でfullhellorcvdが1の場合、jが隣接kとkの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.
（1.2）FullhellorcvdがNeighbor Jの場合は1で、隣接kでは0の場合k：ncm（j、k）= ncm（k、j）は1のみがkのbnsに属している場合にのみ1です。
(1.3) If FullHelloRcvd is 0 for both neighbors j and k: NCM(j,k) = NCM(k,j) = 0.
（1.3）近隣jとk：ncm（j、k）= ncm（k、j）= 0の両方でfullhellorcvdが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が互いのbiネイバーであるかどうかを決定すると信じられています。ステップ1.3が示すように、どちらの隣人がその完全なBNを報告していない場合、2人の隣人が互いの双方向ではないと想定されています。
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に依存します。3のデフォルト値はMDRのほぼ最小数を結果にしますが、値2はMDRの数が多いことになります。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.
（2.2）ルーターのすべてのbi neighborよりも（rtrpri、MDRレベル、RID）の値が大きい場合、ルーターはMDRとしてそれ自体を選択します。そのすべてのMDR Bi neighborsを依存している隣人として選択します。adjConnectivity = 2の場合、そのすべてのBMDR Bi-neighborsを依存の隣人として選択します。その後、フェーズ4に進みます。
(2.3) Let Rmax be the bi-neighbor with the largest value of (RtrPri, MDR Level, RID).
（2.3）rmaxを（rtrpri、mdr level、rid）の最大値を持つbi-neighborとします。
(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）ncmを使用して、bi-neighborsの接続性を決定し、rmaxから互いのbi-neighbor uまで、ホップ（u）の最小ホップ数を計算します。ルーター自体よりも（rtrpri、mdrレベル、red）。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）各bi-neighbor uのホップ（u）が最大のmdrconstraintである場合、ルーターは依存の隣接を選択しず、次のようにMDRレベルを設定します。MDRレベルが現在MDRの場合、PHASフェーズの場合はBMDRに変更されます3が実行され、フェーズ3が実行されない場合は、3が実行されます。それ以外の場合、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。各MDR bi-neighbor uは、ホップ（u）がmdrconstraintよりも大きくなるようにします。adjConnectivity = 2の場合、各BMDR Bi-neighbor uは、HOP（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.1から2.6の結果、MDRレベルがBMDRに変化する場合、または1または2に等しいアジャン接続性のMDRに変化した場合、ステップ2.1から2.6を再び実行します。（これは、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は、幅第一検索（BFS）アルゴリズムを使用して実装できます。RMAXから他のすべてのBi-neighborsにMin-Hopパスを計算します。MDRレベル、RID）は、ルーター自体のレベルよりも大きくなっています。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.)
（3.1）MDRレベルがMDR（フェーズ2を実行した後）で、adconectivityが2ではない場合、フェーズ4に進みます（MDRレベルがMDRおよびadjcononectivity = 2の場合、フェーズ3は追加の依存隣接を選択して作成することができます。バックボーンはバックボーンです。）
(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を使用してbi-neighborsの接続を決定するには、rmaxから互いのbi-neighbor uへの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.
（3.3）rmaxから互いのbi-neighbor uに2つのこのようなノードdisjointパスが存在する場合、ルーターは追加の従属隣人を選択せず、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.
（3.4）その他、ルーターは、フェーズ2でMDRとして既に選択されていない限り、MDRレベルをMDRに設定し、adjconnectivity = 2の場合、依存する隣人のセットに次の各隣接を追加します。MDRまたはBMDR、および各MDR/BMDR Bi-Neighbor 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.1から3.4の結果、MDRレベルがMDRの他のMDRからBMDRに変化した場合、再びフェーズ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は、付録Bに示されているアルゴリズムを使用してO（d^2）時間で実装できます。アルゴリズムの単純化されたバージョンも指定されているため、BMDRの数が増えます。
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になります。バイコン接続隣接のオプションが選択されている場合、各MDR他の人がバックアップ親を選択します。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インターフェイスについて、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）ルーターのすべてのbi neighborよりも（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）Rmaxを（Rtrpri、MDRレベル、RID）の最大値を持つBi-Neighborとします。
(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).
（5.3）ncmを使用してbi-neighborsの接続性を決定し、rmaxから互いのbi-neighbor uまで、ホップ（u）の最小ホップ数を計算します。ルーター自体よりも（rtrpri、red）の値。（これは、ステップ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）各bi-neighbor 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).
この状態で待っているルーターは、受信したハローパケットからネイバー情報を学習しますが、待機状態から遷移するまでMDR選択アルゴリズムを実行することは許可されていません（待機タイマーが期限切れになると）。これにより、不完全な近隣情報に起因するMDR選択の不必要な変更が防止されます。待機タイマーの長さは2hoprefresh * hellointerval秒（完全なHellos間の間隔）です。
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.
ルーター博士は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は、バックアップシーンと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は、新しいインターフェイス変数mdrneighborchangeに置き換えられます。これは、近隣情報の変更のためにMDR選択アルゴリズムを実行する必要があることを示しています（セクション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がDRSの代わりに選択されるため、アクションの説明を変更しました。[RFC2328]の状態遷移は、neighbourchangeが省略されています。代わりに、新しいインターフェイス変数mdrneighborchangeを使用して、MDR選択アルゴリズムを実行する必要があることを示します。このイベントがMANETインターフェイスに呼び出されることはないため、イベントバックアップシーンの状態移行はMANETインターフェイスには適用されません。イベントループバックとUnloopindのインターフェイス状態遷移は、[RFC2328]から変化しません。
State: Down Event: InterfaceUp New state: Depends on action routine.
状態：ダウンイベント：インターフェイスアップ新しい状態：アクションルーチンに依存します。
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.
アクション：インターバルのハロータイマーを開始し、インターフェイスからハローパケットの定期的な送信を可能にします。状態が待機に移行し、シングルショット待機タイマーが開始されます。
State: Waiting Event: WaitTimer New state: Depends on action routine.
状態：待機イベント：Waittimer New State：アクションルーチンに依存します。
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 other、Backup、またはDRになります。
As a result of these changes, the AdjOK? neighbor event may be invoked for some or all neighbors. (See Section 7.)
これらの変更の結果、アジック？近隣のイベントは、一部またはすべての隣人のために呼び出される場合があります。（セクション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], 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.
非マネットインターフェイスでの隣接形成と排除は、変更されていません。MANETインターフェイスの隣接するメンテナンスには、近隣状態マシンの遷移（[RFC2328]、セクション10.3）、隣接する（[RFC2328]、セクション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.
フルトポロジーの隣接が使用されている場合（adcononectivity = 0）、ルーターは各双方向の隣人と隣接を形成します。隣接削減を使用する場合（アジャン接続性は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つのイベントのいずれかがルーターとその隣人の間で発生すると、隣接するメンテナンスの決定が下されます。この決定は、Neighbor Event Adjokを実行することによって行われます。
(1) The neighbor state changes from Init to 2-Way.
(1) 隣国の状態は、initから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.
以下は、Neighbour State Machineの新しい遷移を指定しています。
State(s): Down Event: HelloReceived New state: Depends on action routine.
状態：ダウンイベント：Helloreceived New State：アクションルーチンに依存します。
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を参照）、近隣の状態はinitに移行し、非アクティブタイマーが開始されます。そうでなければ、隣人はダウン状態にとどまります。
State(s): Init Event: 2-WayReceived New state: 2-Way
状態：initイベント：2ウェイレシーブされた新しい状態：2ウェイ
Action: Transition to neighbor state 2-Way.
アクション：近隣の州2ウェイへの移行。
State(s): 2-Way Event: AdjOK? New state: Depends on action routine.
状態：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.
それ以外の場合、隣国の状態がExstartに変更され、次のアクションが実行されます。隣人がルーター自身のIDよりも大きなルーターIDを持っている場合、受信したパケットが初期化（i）、more（m）、およびmaster（ms）bitsセットを備えたDDパケットである場合、イベントネゴシエーションドーンを実行します。交換に移行する州。
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）、more（m）、およびmaster（ms）bitsセットでデータベースの説明パケットの送信を開始します。LLS、およびLビットセット。このデータベースの説明パケットは、それ以外の場合は空にする必要があります。このデータベースの説明パケットは、次の状態が入力されるまでrxmtintervalの間隔で再送信する必要があります（[RFC2328]、セクション10.8を参照）。
State(s): ExStart or greater Event: AdjOK? New state: Depends on action routine.
状態：ExstartまたはGreater Event：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ウェイに移行します。Link Stateの再送信リスト、データベースの概要リスト、およびリンク状態リクエストリストは、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ウェイの隣人の間で隣接を形成する必要があるかどうかを判断する方法を定義しています。次の手順は、アジャンコネクタビティが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ウェイの隣人と隣接することが形成されます。
(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パケットを送信することは、[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を使用してApplesed MDR-DD TLVを使用して送信され、LビットはDDパケットのオプションフィールドに設定されます。MDR-DD TLVの形式は、セクションA.2.4で指定されています。MDR-DD TLVのDRおよびバックアップDRフィールドは、同じインターフェイスで送信されたHelloのDRおよびバックアップ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.
o DDパケットのLビットがオプションフィールドに設定され、MDR-DD TLVが追加されている場合、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) Neighborの従属セレクター変数を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) Neighborの従属セレクター変数を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 隣国の状態が初めての場合、隣接イベント2ウェイレシーブが実行されます。
o If the MDR Level of the neighbor changed, the neighbor state machine is scheduled with the event AdjOK?.
o 隣人のMDRレベルが変更された場合、近隣の州のマシンはイベントアジックでスケジュールされていますか？
o If the neighbor's Child status has changed from 0 to 1, the neighbor state machine is scheduled with the event AdjOK?.
o 隣人の子供のステータスが0から1に変更された場合、隣人のマシンはイベントアジャックでスケジュールされていますか？
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?.
o 隣人の州が2ウェイ未満から2ウェイ以上に変更された場合、隣人のマシンはイベントアジックでスケジュールされていますか？
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に対して次の追加ステップを実行する必要があります（ルーターがマスターまたはスレーブであるかどうか）。データベースの概要リストに、リストされているLSAと同じまたは最新のLSAのインスタンスが含まれている場合、LSAはデータベースの概要リストから削除されます。これにより、隣人がすでに同じまたはより最近のLSAのインスタンスを持っている場合、隣人に送信されたDDパケットにLSAをリストすることが避けられます。この最適化により、DDパケットが大規模なネットワークで約50％減少します。
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（セクション13.1以前）の最初の部分は、次の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.
o マネの放送の性質を活用するために、リンク状態アップデート（LSU）パケットがMANETインターフェイスで受信された場合、送信隣人が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):
o 受信したLSAがデータベースコピーと同じインスタンスである場合、LSAに対してバックアップウェイトネイバーリストが存在する各MANETインターフェイスについて、ステップ7に加えて次のアクションが実行されます（セクション8.1を参照）：
(a) Remove the sending neighbor from the BackupWait Neighbor List if it belongs to the list.
(a) リストに属している場合は、BackUpWait Neighborリストから送信隣人を削除します。
(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.
o ステップ8は、LSAのデータベースコピーが受信したLSAよりも最近であるケースを処理し、次のように変更されます。送信隣人が交換よりも小さい状態にある場合、ルーターは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の再送信）、および[RFC2328]の13.7（リンク状態承認の受信）の変更について説明します。
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を受信すると、[RFC2328]の手順1〜5、セクション13.3は、タイプのMANETではない適格な（発信）インターフェイスごとに変更なしで実行されます。このセクションでは、適格なMANETインターフェイスごとに実行する必要がある変更された手順を指定します。適格なインターフェイスは、[RFC5340]、セクション4.5.2に記載されているように、LSAの洪水範囲に依存します。LSAがMANETインターフェイスに浸水するたびに、マルチキャストアドレスAllSPFRouterに送信される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.
[RFC2328]のステップ1、セクション13.3は、適格なMANETインターフェースごとに次の変更を加えて実行され、新しいLSAが適切な隣接する各隣人のリンク状態再送信リストに配置されます。ステップ1Cは、LSAがすでにLSAを認めている隣人の再送信リストに配置されないように、次のアクションに置き換えられます。
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.
新しいLSAのACKが隣人から受信されたかどうかを判断するために、セクション8.4で説明されているように、ルーターは隣接する各隣人のACKED LSAリストを維持します。新しいLSAを受信すると、各MANETインターフェイスの各近隣のACKED LSAリストは、受け取ったLSAよりも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.)
次の説明では、「カバーされた」隣人の概念を使用します。LSAがManet Neighbor Jによってマルチキャストとして送信された場合、隣接Kはカバーされるように定義され、隣人Kは隣人Jの双方向隣接セット（BNS）に属します。また、LSAが隣のJとKの両方が近隣のインターフェイスで近隣jによってマルチキャストアドレスAllSPFRouterに送られた場合、隣接Kはカバーされるように定義されます。（これらのルーターのみがブロードキャストネットワーク上のAllSPFRouterに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).
(2) インターフェイス上のすべての双方向の隣人が次の3つの条件の少なくとも1つを満たしている場合、次のインターフェイスを調べます（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.
このステップを簡素化するために、条件（c）を省略することができます（したがって、Acksを無視してください）。上記の条件は、発信インターフェイスが受信インターフェイスと同じであると想定していないことに注意してください。
(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).
(3) LSAがこのインターフェイスで受信され、ルーターがこのインターフェイスのMDRのMDRである場合、次のインターフェイスを調べます（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).
(4) LSAがこのインターフェイスで受信され、ルーターがこのインターフェイスのバックアップMDRまたは非フローディングMDRである場合、ルーターはLSAに浸水するかどうかを決定する前にBackUpWaitIntervalを待機します。これを達成するために、ルーターはLSAのバックアップウェイト隣人リストを作成します。これには、最初はステップ2の条件を満たさないこのインターフェイスにすべての双方向の隣接を含めます。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.
(6) LSAがこの（発信）インターフェイスとは異なるMANETまたはブロードキャストインターフェイスで受信された場合、冗長洪水を避けるために、次の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 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).
(b) それ以外の場合、ルーターは、バックアップMDRのステップ4のアクションを実行することにより、インターフェイス上でLSAをフラッディングするかどうかを決定する前にBackUpWaitIntervalを待機します（ルーターがこのインターフェイスのバックアップMDRであるかどうか）。MANETインターフェイスごとに個別のバックアップウェイトネイバーリストが作成されますが、LSAに関連付けられているバックアップウェイトタイマーは1つだけです。次のインターフェイスを調べます（LSAはまだこのインターフェイスにあふれていません）。
(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).
オプションのステップ6を実行すると、LSAがMANETまたはブロードキャストインターフェイスで受信された場合、洪水オーバーヘッドを大幅に減らすことができます。たとえば、LSAが100個のルーターを含むブロードキャストネットワークのDRから受信されたと仮定し、50個のルーター（DRを含まない）もMANETに取り付けられています。これらの50のルーターは、マネの互いに隣の隣にあり、それぞれがブロードキャストネットワークに取り付けられていない（したがってカバーされていない）隣人がいると仮定します。次に、LSA転送手順のステップ6を実行することにより、LSAをブロードキャストネットワークからMANETに転送するルーターの数が50からわずか1に減少します（50ルーターのうち1つがMDRであると仮定します）。
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タイマーが有効期限が切れる場合、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.
(1) インターフェイスのBackUpWait Neighborリストに、現在双方向の隣人である少なくとも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.
(b) LSAがインターフェイスのACKリストに載っている場合（つまり、遅延リンク状態の確認パケットに含まれる予定です）、ルーターは浸水したLSAが暗黙として扱われるため、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秒後に再送信を再スケジュールする必要があります。
(2) The BackupWait Neighbor List is then deleted (whether or not the LSA is flooded).
(2) その後、BackUpWait Neighledリストが削除されます（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インターフェイスにLink State Aunponledgments（LS ACK）を送信する手順について説明します。[RFC2328]のセクション13.5は、非マネットインターフェイスでは変更されていませんが、MANETインターフェイスには適用されません。LS ACKによるオーバーヘッドを最小限に抑え、MANETのブロードキャスト性を活用するために、MANETインターフェイスで送信されたすべてのLS ACKパケットは、IPアドレスALLSPFRouterを使用してマルチキャストです。さらに、マルチキャストとして受信した重複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を送信するかどうかを決定する必要があります。インターフェイスパラメーターAckintervalは、遅延したACKのみを送信する必要がある場合のLS ACKパケット間の間隔です。遅延ACKは、少なくとも（rxmtinterval -ackinterval -0.5）秒、および最大で（rxmtinterval -0.5）秒がLSAインスタンスが最初に受信されてから遅延する必要があります。ACKINTERVALおよびRXMTINTERVALがそれぞれ1秒と7秒のデフォルト値に等しい場合、これにより、遅延ACKが送信される前にLSAの新しいインスタンスが受信される可能性を高めることにより、ACKトラフィックが減少します。即時のACKは、マルチキャストLS ACKパケットですぐに送信されます。これには、送信される予定の遅延ACKも含まれる場合があります。
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を送信するか即時の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.
(1) 受信したLSAが新しい場合、LSAがインターフェイスに浸水しない限り、エリアに関連付けられた各MANETインターフェイスに遅延したACKが送信されます。
(2) If the LSA is a duplicate and was received as a multicast, the LSA is not acknowledged.
(2) LSAが重複しており、マルチキャストとして受信された場合、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.
(a) ルーターがMDR、またはadjConnectivity = 2であり、ルーターがバックアップMDR、またはadjConnectivity = 0である場合、即時ACKが受信インターフェイスから送信されます。
(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.
（バックアップ）MDRが再送信されたLSAを受け取ったときに即時ACKを送信する理由は、（バックアップ）MDRには通常、多数の隣接する隣人がいるため、他の隣接する隣人がLSAを再送信するのを防ぐためです。MDR他のルーターは、隣接する近隣が少ないため、即時のACKを送信しません（AdjConnectivity = 0を除く）。したがって、潜在的な利点は、即時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に再送信することはありません。
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秒です。オーバーヘッドを減らすには、可能な限り、いくつかの再送信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.
各ルーターは、隣接する各近隣のAcked LSAリストを維持し、隣人が認めたがルーター自体がまだ受信していない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.
(1) ルーターに確認されているLSAのデータベースコピーがない場合、または認められているものよりも最近ではないデータベースコピーがある場合、LS ACKは送信中の隣人のACKED 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.
(2) ルーターに認識されているLSAのデータベースコピーがある場合、これは確認されているインスタンスと同じである場合、次のアクションが実行されます。LSAにバックアップウェイトネイバーリストが存在する各MANETインターフェイスについて（セクション8.1を参照）、リストに属している場合は、BackUpWait Neighborリストから送信隣人を削除します。
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.
OSPFブロードキャストネットワークのDRとは異なり、ネットワークLSAを使用してマネの一般的なトポロジーを記述することができないため、MDRはネットワークLSAを発信しません。代わりに、各ルーターは、そのルーター-LSAのポイントツーポイントリンクとして、マネの隣人のサブセットを宣伝しています。ルーター-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.
隣接削減が使用される場合（adconectivityは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).
これをやる気にさせるために、OSPFは、ルーターと隣人の両方が同じブロードキャストネットワークに属している場合（そしてどちらもDRに隣接している）、隣接していない隣人が次のホップになることを許可していることに注意してください。ブロードキャストネットワーク用のネットワーク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を使用してマネの一般的なトポロジーを説明することはできないため、次のホップとして使用できる隣接していない隣人を宣伝する唯一の方法は、ルーター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にルーター自体を含める必要があることです（隣人が接続が双方向であることに同意することを示します）。オプションで、ルーターはより厳しい状態を課す場合があります。たとえば、ルーターでは、隣人から（明示的または暗黙的に）隣人のBNがルーター自体を含むことを示す2つのHellosを隣人から受信する必要がある場合があります。
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.
単一ビットネイバーの変数ルーファブルは、隣人がルーティング可能であり、最初に0に設定されているかどうかを示します。隣接の状態が変更された場合、またはSPF計算が隣人へのルートを見つけたときに、隣接削減が使用される場合、ルーティング可能は次のように更新されます。、または、ルーティング可能な隣人の品質状態に影響を与えるハローが受け取られます。
(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.
(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を参照）。隣接する削減が使用されない場合（adcononectivity = 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にすべての完全な隣人とすべてのルーティング可能なバックボーン隣人を含める必要があります。LSafullness = 0に対応する最小限のLSAには、これらの隣人のみが含まれます。この選択は接続性を保証しますが、最短パスを保証しません。ただし、この選択は、最大のスケーラビリティを実現するために、大規模なネットワークで役立ちます。
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がルーターIへのリンクを宣伝する場合にのみ）ルーターがバックボーンの隣人を含めずに、ルーターLSAで宣伝するために選択したマネの隣人の。SANSにはバックボーンの隣人（したがって依存している隣人）が含まれていないため、SANSとDNSはばらばらです。これらの隣人セットは両方ともHellosで宣伝されています。
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は空です。もう1つの極端な場合、Lsafullnessが4（フルトポロジーLSA）の場合、SANSにはバックボーンの隣人を除くすべての双方向のマネの隣人が含まれます。これらの2つの極端な間に、隣接削減を使用しているルーターは、双方向の非骨骨隣接のサブセットをSANSとして選択する場合があります。結果のルーター-LSAは、セクション9.4で指定されているように構築されます。
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を含むためにSANを選択する必要があります。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の場合、ルーターはMin-COST LSAを発信します。これは、各ルーターに各宛先への最短（最小コスト）パスを計算するのに十分な情報を各ルーターに提供する部分トポロジーLSAです。付録Cでは、Min-COST LSAをもたらすSANに含める近隣を選択するためのアルゴリズムについて説明しています。このアルゴリズムへの入力には、隣人の双方向隣接セット（BNS）、依存隣接セット（DNS）、選択された広告隣接セット（SANS）、およびメトリックTLVなど、各MANET隣人から受け取ったHellosから得られた情報が含まれます。セクションA.2.5で指定されているメトリックTLVは、各双方向の隣人へのリンクコストを宣伝するために、各ハロー（すべてのリンクコストが1でない限り）に追加されます。
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のスーパーセットになるように選択する必要があります。この選択は、Routerが追加の隣人を広告して冗長ルートを提供できるようにしながら、最も短いパスルーティングを提供します。
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が発生すると、宣伝されている各マネ隣人のポイントツーポイント（タイプ1）リンクが含まれます。宣伝される隣人のセットは、次のように決定されます。隣接削減が使用される場合、ルーターはすべての完全な隣人を宣伝し、次の3つの条件のいずれかを満たす各ルーティング可能な隣人Jを宣伝します。隣接する削減が使用されていない場合（adconconnectivity = 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のサンズにはルーターが含まれています（対称性を確保するため）。
(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にはルータブルで完全な隣人のみが含まれる場合があることに注意してください。これは、Hellosで宣伝されている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を発信するイベントは、[RFC2328]および[RFC5340]と同じです。代わりに、次の3つの条件のいずれかを発生させる変更が発生するたびに、新しいルーター-LSAが発生します。
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に含めるための上記の条件を満たすが、現在のルーターLSAには含まれていないマネ隣人Jが存在します。
o The current router-LSA includes a MANET neighbor that is no longer bidirectional.
o 現在のルーターLSAには、双方向ではなくなったマネの隣人が含まれています。
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.
上記の条件は、近隣の1つが変更されるたびにチェックする代わりに、各helloを送信する直前に定期的にチェックすることができます。次の実装はうまく機能することがわかりました。各helloを送信する直前、および双方向の隣接が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.
ルーティングテーブルの計算は、[RFC2328]で指定されたものと同じですが、セクション16.1の次の変更を除き（エリアで最も短いパスツリーの計算）。フルトポロジーの隣接および全トポロジーLSAを使用している場合（adcononectivity = 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.
隣接する削減が使用される場合（adclonectivityは1または2）、セクション16.1が次のように変更されます。セクション9から、ルーターがルーターLSAで宣伝されているかどうかにかかわらず、ルーターがルーティング可能な隣人を次のホップとして目的地へのホップとして使用できることを思い出してください。これは、ルート頂点に関連付けられたルーターLSAが、すべての完全な隣人およびルーティング可能なすべてのMANET隣人へのリンクを含むダミールーターLSAに置き換えるように、ステップ2を変更することによって達成されます。さらに、vがルート頂点であり、Wがルーティング可能なMANETネイバーである場合、ステップ2B（WからVへのリンクをチェック）はスキップする必要があります。ただし、vがルート頂点ではない場合は、OSPFV3との互換性を確保するために、ステップ2Bを実行する必要があります。
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が次のように変更されます。ステップ2が変更され、ルート頂点に関連付けられているルーター-LSAが、すべての完全な近隣へのリンクを含むダミールーターLSAに置き換えられます。さらに、vがルート頂点であり、Wがフルマネ隣接の場合、ステップ2Bをスキップする必要があります。（隣人のルーター-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に含まれていなかったルーティング可能な隣人がダウン状態またはinit状態に遷移する場合に発生する可能性があります。したがって、ルータブル隣人のセットが変更された場合、ルーター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番目の計算では、ルーティング可能な近隣のセットは再び変更されないため、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]を使用して、認証、整合性、および/または機密性を提供できます。OSOSPFV3の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の拡張では、新しいセキュリティの脅威は導入されません。ただし、マネルーターに固有のワイヤレスメディアとインフラストラクチャの欠如は、[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.
同様に、干渉攻撃は、ワイヤレスの性質のために、マネルーターに対しても簡単に取り付けられます。このような攻撃は、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ルーターの場合、これは、同じマネに取り付けられたすべてのルーターがマルチリキャストパケットに同じキーを使用する必要があることを意味します。[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]で説明したように、手動キーの使用は脆弱性を高める可能性があります。たとえば、手動キーは通常長生きしているため、攻撃者にキーを発見する時間が増えます。さらに、同じマネに取り付けられたすべてのルーターで同じキーを使用すると、ルーターのいずれかが侵害された場合、すべてのルーターがなりすまし攻撃に対して不安定になります。
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.
[RFC4302]および[RFC4303]は、AHおよびESPの実装は、手動でキー化されたSASと組み合わせてアンチレプレイサービスを提供すべきではないと述べていますが、送信者のシーケンス番号カウンターが許可されている場合は、そのようなサービスが許可されていることに注意することが重要です。キーが交換されるまで、ローカルの再起動全体で正しく維持されます。したがって、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領域を持つ固定ネットワークから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).
このドキュメントでは、MDR-Hello TLV（14）、MDR-Metric TLV（16）、およびMDR-DD TLV（15）の3つの新しいLLS TLVタイプを定義します（セクションA.2を参照）。
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およびBMDRを選択する際の（RTRPRI、MDRレベル、RID）の辞書的な比較のMDRレベルの前にルーターの優先順位が来るべきであるという提案を含む、有益な議論とコメントについては、Aniket Desaiに感謝します。MDRレベルが変更されます。また、トム・ヘンダーソン、エイシー・リンデム、エマニュエル・バッケリにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
[RFC5243] Ogier, R., "OSPF Database Exchange Summary List Optimization", RFC 5243, May 2008.
[RFC5243] Ogier、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.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、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] Zinin、A.、Roy、A.、Nguyen、L.、Friedman、B。、およびD. Yeung、「OSPF Link-Local Signaling」、RFC 5613、2009年8月。
[Lawler] Lawler, E., "Combinatorial Optimization: Networks and Matroids", Holt, Rinehart, and Winston, New York, 1976.
[Lawler] Lawler、E。、「組み合わせの最適化：ネットワークとMatroids」、Holt、Rinehart、Winston、New York、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.タルジャン、「嫌悪パスの最短ペアを見つけるための迅速な方法」、ネットワーク、Vol。14、pp。325-336、1984。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
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ビットは、リンクローカルシグナル伝達に使用されます。ルーターは、LITをHelloとDDパケットに設定して、パケットにLLSデータブロックが含まれていることを示します。ルーターは、LSAが適切でないことを示すために、自己陽性のルーターLSAにLビットを設定します。
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は、Link-Local Signaling [RFC5613]を使用して、MDR-Hello TLVおよびMDRメトリックTLVをHelloパケットに追加し、MDR-DD TLVをデータベース説明パケットに追加します。Link-Localシグナル伝達は、既存のOSPFパケットタイプを使用して任意のデータを交換できるOSPFV2とOSPFV3の拡張です。ここでは、OSPFV3にLLSを使用します。これは、OSPFV3パケットの最後にLLSデータブロックを追加することで実現されます。OSPFパケット長フィールドには、LLSデータブロックの長さは含まれていませんが、IPv6パケットの長さにはこの長さが含まれます。
The data block used for link-local signaling is formatted as described below in Figure A.1.
Link-Localシグナル伝達に使用されるデータブロックは、図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ビット語）が含まれています。実装は、IPv6パケットヘッダーの長さフィールドを使用して、LLSデータブロックの長さを決定しないでください。
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ビットアラインドしている必要があります（必要に応じてパディングを使用）。
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.
タイプフィールドには、TLV IDが含まれています。これは、TLVのタイプごとに一意です。長さフィールドには、変数で任意のデータが含まれる値フィールド（バイト単位）の長さが含まれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
TLVは常に32ビットの境界にパッドにされていますが、パディングバイトはTLV長いフィールドに含まれていません（ただし、LLSブロックヘッダーのLLSデータ長さフィールドに含まれています）。すべての未知の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-Hello TLVは、LLSを使用して各MANET Helloに追加されます。これには、送信インターフェイスの現在のハローシーケンス番号（HSN）と、ハローの本体にリストされている各タイプの近隣の数が含まれます（セクション4.1を参照）。また、Helloが（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は、（微分または完全）Helloがインターフェイスに送信されるたびに1（Modulo 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 a（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ビット）：差分のために1に設定し、完全なhelloで0を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ビット）：Helloにリストされている隣人の数。Helloが違いがない場合、N1はゼロです。
o N2 (8 bits): The number of neighbors listed in the Hello that are in state Init.
o N2（8ビット）：Helloに記載されている隣人の数は、州の初期的です。
o N3 (8 bits): The number of neighbors listed in the Hello that are Dependent.
o N3（8ビット）：依存しているHelloにリストされている隣人の数。
o N4 (8 bits): The number of neighbors listed in the Hello that are Selected Advertised Neighbors.
o N4（8ビット）：選択された隣人に宣伝されている隣人の数。
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).
データベースの説明パケットがState Exstartの隣人に送信されると、MDR-DD TLVがLLSを使用してパケットに追加されます。これには、ルーターが送信したHelloのDRおよびバックアップDRフィールドに含まれる同じ2つのルーターIDが含まれ、ルーターの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：ルーターから送信されたHelloの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：ルーターが送信したハローのバックアップDRフィールドに含まれる同じルーターID（セクションA.3を参照）。
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の場合、すべてのリンクメトリックが1でない限り、MDRメトリックTLVをLLSを使用して各MANETハローパケットに追加する必要があります。少なくとも、このTLVは単一のデフォルトメトリックを宣伝します。iビットが設定されている場合、リンクメトリックがデフォルトのメトリックに等しくないHelloの本体にリストされている各双方向隣接にルーターIDとリンクメトリックが含まれています。このオプションは、すべての隣人が同じリンクメトリックを持っている場合、またはデフォルトのメトリックとは異なるリンクメトリックを持っている隣人の数だけを持っている場合、オーバーヘッドを減らします。Iビットがゼロの場合、Helloの本体にリストされている各双方向隣接と隣人のRIDSがTLVから省略されている各双方向隣接に含まれるリンクメトリックが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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ビットが1の場合は4 6*nに設定され、iビットが0の場合は4 2*nに設定されます。ここで、nはTLVに含まれる近隣の数です。
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 BITが1の場合、これはメトリックTLVにridがリストされていない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の場合、リンクメトリックがデフォルトのメトリックに等しくないHelloの本体の双方向隣接（セクション4.1で定義されている3〜5のリスト3〜5）のRIDがリストされます。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の場合、TLVの隣接IDと同じ順序でリストされている各双方向隣人のリンクメトリック、および双方向隣接の隣接IDと同じ順序でリストされています（セクション4.1で定義されているように、リスト3〜5）I Bitが0の場合、Helloの本体。
The Designated Router (DR) and Backup DR fields of a Hello packet are set as follows:
Helloパケットの指定されたルーター（DR）とバックアップ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の親は、常にルーター自身の削除です。
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のバックアップの親は、常にルーター自身の削除です。
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は、単一の領域のマネのネットワークマップの例を示しています。
o Four MANET routers RT1, RT2, RT3, and RT4 are in area 1.
o 4つの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
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とリンクローカルアドレス
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つのマネ、1つのブロードキャスト、1つのループバックインターフェイスで構成されています。
RT3's router-LSA
RT3のRouter-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)
Consider the link-LSA that RT3 would originate for its MANET interface.
RT3がMANETインターフェイスのために発生するLink-LSAを検討してください。
RT3's link-LSA for its MANET interface
MANETインターフェイスのRT3のLink-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
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が構築するエリア内-Prefix-LSAを検討してください。
RT2's intra-area-prefix-LSA for its own prefixes
独自のプレフィックスについては、RT2のエリア内-Prefix-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
Appendix B. Detailed Algorithms for MDR/BMDR Selection
付録B. MDR/BMDR選択の詳細なアルゴリズム
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で説明されているMDR選択アルゴリズムのフェーズ2（MDR選択）のステップ2.4およびステップ3（BMDR選択）の詳細なアルゴリズムを提供します。ステップ2.4では、幅最初の検索（BFS）アルゴリズム、およびステップを使用します。3.2は、RMAXから他のすべての隣人へのノードディスジョイントパスのペアを見つけるために効率的なアルゴリズムを使用します。両方のアルゴリズムはO（d^2）時間で実行されます。ここで、dは隣接の数です。
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.
便宜上、次の説明では、「bi-neighbor」という用語は、「双方向隣人」の略語として使用されます。また、ノードIは、計算を実行するルーターを示します。
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を実行し、フェーズ1とステップ2.1から2.3が実行されていると仮定して、隣接マトリックスNCMが計算され、RMAXは（辞書的に）最大の価値を持つBi-neighborです。of（rtrpri、MDRレベル、RID）。BFSアルゴリズムはFIFOキューを使用して、Node RMAXのすべてのノード1ホップが最初に処理され、次に2ホップなどが処理されます。ノードrmaxからノードuへの最小ホップ数に等しく、ノードiのバイネギーであり、ノードiよりも大きな値（rtrpri、mdrレベル、RID）の中間ノードのみを使用しています。アルゴリズムは、各ノードuに対して、rmaxからuへのツリーパス上のツリー親P（u）と2番目のノードr（u）を計算します。これはステップ3.2で使用されます。
(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.)
(a) 次のように、bi-neighbors uおよびvの各ペアのリンクコストc（u、v）のマトリックスを計算します。ノードuの（rtrpri、mdr level、rid）の値がノードiとncm（u、u、ncm）の値が大きい場合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) rmax以外のすべてのbi-neighbor uのホップ（u）=無限をセットし、ホップ（rmax）= 0をセットします。c（rmax、u）= 1、set 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と呼んでください。c（u、v）= 1：ホップ（v）>ホップ（u）1の場合、ノードiの各bi-neighbor vについて、ホップ（v）= hops（u）1、set p（v）を設定します= u、r（v）= r（u）の場合はr（v）= r（u）hops（v）> 1を設定し、キューのテールにノードvを追加します。
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.
MDR選択アルゴリズムのステップ3.2では、ルーターがRmaxから互いに互いに2つのノードdisjointパスが存在するかどうかを判断する必要があります。ルーター自体。この情報は、ルーターが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.
bi-neighbor uの各bi-neighbor uの個別に決定することは、o（n^2）時間で実行されるよく知られている拡張パスアルゴリズム[lawler]を使用して、rmaxからuまでの2つのノードダイジョイントパスが存在するかどうかを決定することができますが、これは必須ですすべてのBi-neighbors Uに対して行われるため、O（n^3）の合計実行時間が必要です。以下で説明するアルゴリズムは、すべてのBi neighbors Uに対して同時に同じ決定を行い、O（n^2）のはるかに速い合計実行時間を達成します。このアルゴリズムは、ばらばらのパスのペアを見つけるための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.
以下に説明するアルゴリズムは、フェーズ2の次の出力を使用します。各ノードのツリー親p（u）（フェーズ2で計算されたBFSツリーを定義）、およびrmaxからuへのツリーパス上の2番目のノードr（u）を使用します。。
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以外のラベル付きノードが存在する場合、g（u）がuからrmaxまでの逆ツリーパスで最初のラベルのあるノードであると定義します。（逆ツリーパスは、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（k）が示されているkにルートした非標識サブツリーを、g（u）= kになるようなノードuのセットであると定義します。したがって、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アルゴリズムは、最初は空です。ノードuは、ルーター自体よりも（rtrpri、mdrレベル、RID）の値が大きいノードを介してrmaxからuに2つのノードダイジョイントパスが存在することがわかっている場合、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。r（u）がr（v）（すなわち、uとvが異なる2番目のノード）、ncm（u、v）= 1に等しくないように、rmax以外のbfsツリー上のvの各ペアu、vについてvノードuの値は、ルーター自体よりも（rtrpri、mdrレベル、red）の値が大きくなり、vにvを追加します（明らかにRmaxからvまでの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（j）がs（k）を削除することにより小さくなります。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 ルーター自体よりも（rtrpri、mdrレベル、RID）の値が大きく、vがBにない場合は、vにvを追加します。
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.
o vがルーター自体よりも（rtrpri、mdrレベル、RID）の値が大きく、uがBにない場合は、uをBに追加します。
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）を省略して実行できます。ただし、単純化されたアルゴリズムはより多くのBMDRを引き起こし、adconectivity = 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.
上記のアルゴリズムは、O（n^2）時間で実行できます。ここで、nは近隣の数です。ステップ（a）ノードのすべてのペアとv。ステップ（b）のすべてのペアを考慮するため、O（n^2）時間が必要になることは明らかです。これは、ノードの標識を、非標識サブツリーをより小さな非標識サブツリーに分割し、特定のペアu、Vは、uとvが異なる非標識サブツリーに属するのは初めてであると見なされるためです。
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が1の場合、ルーター-LSAに含めるマネの隣人を決定するためのアルゴリズムについて説明します。最小LSAアルゴリズムは、リンク状態データベースが少なくとも1つの短い（最小コスト）パスを計算するのに十分な情報を提供することを保証します。各目的地に。アルゴリズムは、ルーターに複数のインターフェイスがあると想定しており、そのうちの1つは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.
このアルゴリズムへの入力には、各MANETインターフェイスの各近隣から受け取ったHellosから得られた情報が含まれます。これには、隣人の双方向の隣接セット（BNS）、依存した隣接セット（DNS）、選択された広告隣接セット（SANS）、リンクメトリックが含まれます。入力には、ルーターに非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を構築するために使用されます。Min-COST 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、親、またはリンクメトリックの変化を示しています。
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.
以下で説明するアルゴリズムはO（d^3）時間で実行されますが、Dは近隣の数ですが、アルゴリズムの説明に従って説明されているように、単一のトポロジの変更の増分バージョンは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.
便宜上、次の説明では、「bi-neighbor」という用語は、「双方向隣人」の略語として使用されます。また、ルーターIは計算を行うルーターを示します。Min-COST 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.)
(1) セクション5.1で説明されているように、各MANETインターフェイスの近隣接続マトリックス（NCM）を作成します。次のように、マルチインターフェイスネイバー接続マトリックスMNCMを作成します。各bi-neighbor jについて、mncm（i、j）= mncm（j、i）= 1を設定します。各ペアj、manet bi-neighborsのkについて、ncm（j、j、set mncm（j、k）= 1k）MANETインターフェイスの場合は1に等しくなります。各ペアj、非manet bi-neighborsのkについて、MNCM（j、k）= 1を設定します。リンク状態データベースがjとkの間に直接リンクが存在することを示している場合。それ以外の場合は、MNCM（J、K）= 0を設定します。
(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) 次のように、隣人間コストマトリックス（コスト）を作成します。各ペアj、kのkのkとjとkのそれぞれがbi-neighborまたはルーターI自体になるようにする。
(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.
(a) mncm（j、k）= 1、jのhellos（manetインターフェイス用）またはリンク状態データベース（非aの場合）から取得したjからkへのリンクのメトリックにコスト（j、k）を設定する場合MANETインターフェイス）。JからK（複数のインターフェイスを介して）に複数のリンクがある場合、コスト（J、K）がこれらのリンクの最小コストに設定されます。
(b) Otherwise, set COST(j,k) to LSInfinity.
(b) それ以外の場合は、コスト（j、k）をlsinfinityに設定します。
(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 Bi-neighborsのどのペアが互いのバックボーンネイバーであるかを示します。隣接削減が使用されない場合（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.
以下では、複数のインターフェイスにルーターJからルーターKへのリンクが存在する場合、jからkへのコストがコスト（j、k）に等しいインターフェイスのみを検討します。このようなインターフェイスは、「候補」インターフェイスと呼ばれます。
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のK、KのK、BNM（J、K）は、JとKが候補MANETインターフェイスで互いにバックボーンネイバーである場合、1に設定されます。つまり、bnm（j、k）は、候補のmanetインターフェイスについて、NCM（j、k）= 1で、次のいずれかの条件のいずれかが満たされている場合、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がbi-neighborまたはルーターI自体になるようにkのkについて、Sanm（j、k）は1に設定されています。1とKはJのSANSに含まれています。それ以外の場合、SANM（J、K）は0に設定されています。Kが現在選択されている隣人である場合、SANM（I、K）は1に設定されていることに注意してください。
(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 bi-neighbor jについて、ビット変数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).
(a) Jが複数のインターフェイスのBi-neighborである場合、候補インターフェイスのみ（Jのコストは最小）を検討してください。候補のインターフェイスの1つが非Manetインターフェイスである場合、次の隣人を調べます（Jはとにかく宣伝されるため選択されません）。
(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) 隣接する削減が使用され、候補インターフェイスの1つがjがバックボーン隣人であるMANETインターフェイスである場合（セクション9.2を参照）、次の隣人を調べます（とにかく宣伝されるため、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インターフェイスがある場合は、特定の順序で次の優先ルールを使用して「優先」インターフェイスを選択します。ルーターIのルーターの優先度はそのインターフェイスで大きく、（3）ルーターIの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:
(d) コスト（k、j）>コスト（k、i）コスト（i、j）などの各bi-neighbor K（任意のインターフェイス上）について、どちらかのコスト（k、uなどの別のbi-neighbor uが存在するかどうかを決定します。）cost（u、j）<cost（k、i）cost（i、j）、またはcost（k、u）cost（u、j）= cost（k、i）cost（i、j）andいずれか次の条件が当てはまります：
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）、rid（u））は、辞書編成的に（sanm（j、i）、sanm（i、j）、rtrpri（i）、rid（私））。
If for some such bi-neighbor k, there does not exist such a bi-neighbor u, then set new_sel_adv(j) = 1.
そのようなbi-neighbor Kの場合、そのようなbi-neighbor 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について、sansを更新して、new_sel_adv（j）= 1とiがjの優先インターフェイスになるように、すべてのbi-neighbors jのセットに等しくなります。
(7) With the SANS updated, a new router-LSA may need to be originated as described in Section 9.4.
(7) SANSが更新された場合、セクション9.4で説明されているように、新しいルーターLSAを発信する必要がある場合があります。
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）時間で実行できます。たとえば、link（x、y）がxとyがルーターIの近隣である場合、sans（x、y）= 1またはbnm（x、y）= 1のいずれかで失敗した場合、ステップ5はペアに対してのみ実行する必要があります。j、kはjまたはkのいずれかがxまたはyに等しくなるようなものです。
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の創始者は、LSAのオプションフィールドにLビットを設定することにより、ルーターLSAが「不適当」であることを示している可能性があります（セクションA.1を参照）。たとえば、ルーターは、新しいLSAが少なくとも90％の時間ごとに毎分ミンセルバル秒ごとに発信されることを決定する（例えば、指数移動平均に基づいて）決定できない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.
適切でないLSAは認められず、ユニキャストとして再送信されたり、DDパケットで説明されているため、大幅なオーバーヘッドを節約します。ただし、発信元のルーターは、ルーターLSAの現在のインスタンスをマルチキャストとして定期的に再送信する必要があります（以前のインスタンスが再送信される前に通常発生する新しいLSAを発信するまで）。マルチキャストとして（LSAの新しいインスタンスを受信するまで、通常、前のインスタンスが再送信される前に発生します）。このオプションを機能させるには、rxmtintervalがminlsintervalよりも大きくなければならないため、LSAの新しいインスタンスが通常再送信される前に受信されます。再送信された（重複）LSAの受信は、LSAの即時転送をもたらさないことに注意してください。セクション8の洪水手順に従って、新しいLSA（より大きなシーケンス番号を含む）のみをすぐに転送できます。
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.
このセクションでは、Min-COST LSAを備えた最大160ノードのOSPF-MDRのパフォーマンスを予測するシミュレーション結果と、最小限のLSAで最大200ノードを予測します。結果は、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 m、グリッド長= 500 m、ワイヤレスアルファ= 0.5、（最大）速度= 10 m/s、一時停止時間= 0、パケットレート= 10 pkts/s、パケットサイズ= 40バイト、ランダムシード= 8、開始時間（統計の収集の場合）= 1800秒。停止時間は、最大80ノードで3600秒、80個以上のノードで2700秒でした。ソースと宛先は、生成された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は、微分Hellosが使用されたことを除いて、OSPF-MDRのデフォルト構成の結果を示しています（2hoprefresh = 3）。表5および7は、MIN-COST LSAの代わりに最小限のLSAが使用されたことを除いて、同じ構成の結果を示しています。テーブルは、KB/sの総OSPF間接費、1秒あたりの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は、次の統計も示しています：ノードあたりの双方向隣接の平均数、ノードあたりの完全に隣接する隣接の平均数、ノードあたりの双方向隣接のセットの変化数、および数字ノードあたり1秒あたりの完全に隣接する近隣のセットの変更。これらの統計は、最小限のLSAの代わりにMin-COST 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.
結果は、Min-COST LSAを使用すると、OSPF-MDRが少なくとも160ノードまで優れたパフォーマンスを達成し、最小限のLSAを使用すると少なくとも200ノードまで優れたパフォーマンスを達成することを示しています。また、ホップ数の結果は、最小限のLSAで得られたルートが、範囲が250 mの場合、範囲が200の場合は3.5％から7.4％長い場合、Min-COST LSAよりも2.3％から4.5％長いことを示しています。m。
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 mの範囲で、2.136/.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：Min-Cost LSAで250 mの範囲の結果
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 mの範囲の結果
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・オギエ・スリ・インターナショナル
EMail: rich.ogier@earthlink.net or rich.ogier@gmail.com
Phil Spagnolo Boeing Phantom Works
Phil Spagnolo Boeing Phantom Works
EMail: phillipspagnolo@gmail.com