[要約] RFC 5449は、アドホックネットワークにおけるOSPF Multipoint Relay（MPR）拡張に関するものであり、その目的は、ネットワークの効率性とスケーラビリティを向上させるために、MPRの選択と使用方法を定義することです。
Network Working Group E. Baccelli
Request for Comments: 5449 P. Jacquet
Category: Experimental INRIA
D. Nguyen
CRC
T. Clausen
LIX, Ecole Polytechnique
February 2009
OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks
アドホックネットワーク用のOSPFマルチポイントリレー（MPR）拡張
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 (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type".
このドキュメントは、モバイルアドホックネットワーク用に合わせたOSPFV3インターフェイスタイプを指定します。このインターフェイスタイプは、ブロードキャストインターフェイスタイプから導出され、「OSPFV3 MANETインターフェイスタイプ」と示されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
3.1. MANET Characteristics . . . . . . . . . . . . . . . . . . 5
3.2. OSPFv3 MANET Interface Characteristics . . . . . . . . . . 5
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
4.1. Efficient Flooding Using MPRs . . . . . . . . . . . . . . 6
4.2. MPR Topology-Reduction . . . . . . . . . . . . . . . . . . 6
4.3. Multicast Transmissions of Protocol Packets . . . . . . . 7
4.4. MPR Adjacency-Reduction . . . . . . . . . . . . . . . . . 7
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. N(i): Symmetric 1-Hop Neighbor Set . . . . . . . . . . 7
5.1.2. N2(i): Symmetric Strict 2-Hop Neighbor Set . . . . . . 8
5.1.3. Flooding-MPR Set . . . . . . . . . . . . . . . . . . . 8
5.1.4. Flooding-MPR-Selector Set . . . . . . . . . . . . . . 9
5.1.5. Path-MPR Set . . . . . . . . . . . . . . . . . . . . . 9
5.1.6. Path-MPR-Selector Set . . . . . . . . . . . . . . . . 10
5.1.7. MPR Set . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.8. MPR-Selector Set . . . . . . . . . . . . . . . . . . . 10
5.2. Hello Protocol . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Flooding-MPR Selection . . . . . . . . . . . . . . . . 11
5.2.2. Flooding-MPR Selection Signaling - FMPR TLV . . . . . 11
5.2.3. Neighbor Ordering . . . . . . . . . . . . . . . . . . 12
5.2.4. Metric Signaling - METRIC-MPR TLV and PMPR TLV . . . . 12
5.2.5. Path-MPR Selection . . . . . . . . . . . . . . . . . . 12
5.2.6. Path-MPR Selection Signaling - PMPR TLV . . . . . . . 12
5.2.7. Hello Packet Processing . . . . . . . . . . . . . . . 13
5.3. Adjacencies . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Packets over 2-Way Links . . . . . . . . . . . . . . . 14
5.3.2. Adjacency Conservation . . . . . . . . . . . . . . . . 14
5.4. Link State Advertisements . . . . . . . . . . . . . . . . 14
5.4.1. LSA Flooding . . . . . . . . . . . . . . . . . . . . . 15
5.4.2. Link State Acknowledgments . . . . . . . . . . . . . . 17
5.5. Hybrid Routers . . . . . . . . . . . . . . . . . . . . . . 18
5.6. Synch Routers . . . . . . . . . . . . . . . . . . . . . . 18
5.7. Routing Table Computation . . . . . . . . . . . . . . . . 18
6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Flooding-MPR TLV . . . . . . . . . . . . . . . . . . . . 19
6.2. Metric-MPR TLV . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Path-MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Flooding-MPR Selection Heuristic . . . . . . . . . . 28
Appendix B. Path-MPR Selection Heuristic . . . . . . . . . . . . 29
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 30
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 30
This document specifies an extension of OSPFv3 [RFC5340] that is adapted to mobile ad hoc networks (MANETs) [RFC2501] and based on mechanisms providing:
このドキュメントは、モバイルアドホックネットワーク（MANETS）[RFC2501]に適応し、次のことを提供するメカニズムに基づいて、OSPFV3 [RFC5340]の拡張を指定します。
Flooding-reduction: only a subset of all routers will be involved in (re)transmissions during a flooding operation.
洪水削減：すべてのルーターのサブセットのみが、洪水操作中に（再）送信に関与します。
Topology-reduction: only a subset of links are advertised, hence both the number and the size of Link State Advertisements (LSAs) are decreased.
トポロジ削減：リンクのサブセットのみが宣伝されているため、リンク状態広告（LSA）の数とサイズの両方が減少します。
Adjacency-reduction: adjacencies are brought up only with a subset of neighbors for lower database synchronization overhead.
隣接削減：隣接は、より低いデータベース同期オーバーヘッドのために近隣のサブセットでのみ育ちます。
These mechanisms are based on multipoint relays (MPR), a technique developed in the Optimized Link State Routing Protocol (OLSR) [RFC3626].
これらのメカニズムは、最適化されたリンク状態ルーティングプロトコル（OLSR）[RFC3626]で開発された手法であるマルチポイントリレー（MPR）に基づいています。
The extension specified in this document integrates into the OSPF framework by defining the OSPFv3 MANET interface type. While this extension enables OSPFv3 to function efficiently on mobile ad hoc networks, operation of OSPFv3 on other types of interfaces or networks, or in areas without OSPFv3 MANET interfaces, remains unaltered.
このドキュメントで指定された拡張機能は、OSPFV3 MANETインターフェイスタイプを定義することにより、OSPFフレームワークに統合されます。この拡張により、OSPFV3はモバイルアドホックネットワークで効率的に機能することができますが、他のタイプのインターフェイスまたはネットワークでのOSPFV3の動作、またはOSPFV3 MANETインターフェイスのないエリアでは、変更されていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、[RFC2119]で説明されているように解釈されます。
This document uses OSPF terminology as defined in [RFC2328] and [RFC5340], and Link-Local Signaling (LLS) terminology as defined in [RFC4813]; it introduces the following terminology to the OSPF nomenclature:
このドキュメントでは、[RFC2328]および[RFC5340]で定義されているOSPF用語を使用し、[RFC4813]で定義されているリンクローカルシグナル伝達（LLS）の用語を使用します。次の用語をOSPFの命名法に紹介します。
OSPFv3 MANET interface - the OSPFv3 interface type for MANETs, as specified in this document.
OSPFV3 MANETインターフェイス-MANETのOSPFV3インターフェイスタイプ、このドキュメントで指定されています。
Additionally, the following terms are used in this document:
さらに、このドキュメントでは、次の用語が使用されています。
MANET router - a router that has only OSPFv3 MANET interfaces.
MANETルーター - OSPFV3 MANETインターフェイスのみを備えたルーター。
Wired router - a router that has only OSPFv3 interface of types other than OSPFv3 MANET interfaces.
有線ルーター-OSPFV3マネインターフェイス以外のタイプのOSPFV3インターフェイスのみを備えたルーター。
Hybrid router - a router that has OSPFv3 interfaces of several types, including at least one of the OSPFv3 MANET interface type.
ハイブリッドルーター - OSPFV3 MANETインターフェイスタイプの少なくとも1つを含むいくつかのタイプのOSPFV3インターフェイスを備えたルーター。
Neighbor - a router, reachable through an OSPFv3 interface (of any type).
Neighbor-（あらゆるタイプの）OSPFV3インターフェイスを介して到達可能なルーター。
MANET neighbor - a neighbor, reachable through an OSPFv3 MANET interface.
MANET Neighbor-隣人、OSPFV3 MANETインターフェイスを通じて到達可能。
Symmetric 1-hop neighbor - a neighbor, in a state greater than or equal to 2-Way (through an interface of any type).
対称1ホップネイバー - 隣人、2ウェイ以上の状態（あらゆるタイプのインターフェイスを介して）。
Symmetric strict 2-hop neighbor - a symmetric 1-hop neighbor of a symmetric 1-hop neighbor, which is not itself a symmetric 1-hop neighbor of the considered router.
対称的な厳密な2ホップ隣人 - 対称1ホップ隣人の対称1ホップ隣人。それ自体が考慮されたルーターの対称1ホップ隣人ではありません。
Symmetric strict 2-hop neighborhood - the set formed by all the symmetric strict 2-hop neighbors of the considered router.
対称的な厳密な2ホップ近隣 - 考慮されたルーターのすべての対称的な厳密な2ホップネイバーによって形成されたセット。
Synch router - a router that brings up adjacencies with all of its MANET neighbors.
同期ルーター - すべてのマネの隣人と隣接するルーター。
Flooding-MPR - a router that is selected by its symmetric 1-hop neighbor, router X, to retransmit all broadcast protocol packets that it receives from router X, provided that the broadcast protocol packet is not a duplicate and that the Hop Limit field of the protocol packet is greater than one.
Flooding-MPR-対称1ホップネイバー、ルーターXによって選択されたルーターは、ローターXから受信するすべてのブロードキャストプロトコルパケットを再送信します。プロトコルパケットは1より大きいです。
Path-MPR - a router that is selected by a symmetric 1-hop neighbor, X, as being on the shortest path from a router in the symmetric strict 2-hop neighborhood of router X to router X.
Path-MPR-対称1ホップ隣接Xによって選択されたルーター、X、対称的な厳密な2ホップ近傍のルーターからルーターXまでのルーターから最短パスにあります。
Multipoint relay (MPR) - a router that is selected by its symmetric 1-hop neighbor as either a Flooding-MPR, a Path-MPR, or both.
Multipoint Relay（MPR） - 対称1-HOP隣接がフラッディングMPR、PATH-MPR、またはその両方として選択されるルーター。
Flooding-MPR-selector - a router that has selected its symmetric 1-hop neighbor, router X, as one of its Flooding-MPRs is a Flooding-MPR-selector of router X.
Flooding-MPR-Selector-対称1ホップネイバー、ルーターXを選択したルーターであるルーターXの1つは、ルーターXの洪水MPRセレクターです。
Path-MPR-selector - a router that has selected its symmetric 1-hop neighbor, router X, as one of its Path-MPRs is a Path-MPR selector of router X.
PATH-MPRセレクター - そのPATH-MPRSの1つとして、対称1ホップ隣接Xを選択したルーターは、ルーターXのパスMPRセレクターです。
MPR-selector - a router that has selected its symmetric 1-hop neighbor, router X, as either one of its Flooding-MPRs, one of its Path-MPRs, or both is an MPR-selector of router X.
MPRセレクター - 対称1ホップ隣接Xを選択したルーター、ルーターXは、その洪水MPRのいずれか、そのパスMPRのいずれか、またはその両方がルーターXのMPRセレクターです。
The OSPFv3 MANET interface type, defined in this specification, allows OSPFv3 to be deployed within an area where parts of that area are a mobile ad hoc network (MANET) with moderate mobility properties.
この仕様で定義されているOSPFV3 MANETインターフェイスタイプにより、OSPFV3は、その領域の一部が中程度のモビリティ特性を備えたモバイルアドホックネットワーク（MANET）であるエリア内に展開できます。
MANETs [RFC2501] are networks in which a dynamic network topology is a frequently expected condition, often due to router mobility and/or to varying quality of wireless links -- the latter of which also generally entails bandwidth scarcity and interference issues between neighbors.
MANETS [RFC2501]は、動的ネットワークトポロジが頻繁に予想される状態であるネットワークであり、多くの場合、ルーターの移動性やワイヤレスリンクの品質が変化するためです。
Moreover, MANETs often exhibit "semi-broadcast" properties, i.e., a router R that makes a transmission within a MANET can only assume that transmission to be received by a subset of the total number of routers within that MANET. Further, if two routers, R1 and R2, each make a transmission, neither of these transmissions is guaranteed to be received by the same subset of routers within the MANET -- even if R1 and R2 can mutually receive transmissions from each other.
さらに、マネはしばしば「半ブロードキャスト」プロパティを示します。つまり、マネ内のトランスミッションを作成するルーターRは、そのマネ内のルーターの総数のサブセットによって受信される伝送を想定することしかできません。さらに、2つのルーター、R1とR2がそれぞれ伝送を行う場合、これらの送信はどちらもMANET内の同じルーターのサブセットによって受信されることは保証されていません - R1とR2が相互に互いに送信を受信できる場合でも。
These characteristics are incompatible with several OSPFv3 mechanisms, including, but not limited to, existing mechanisms for control-traffic reduction, such as flooding-reduction, topology-reduction, and adjacency-reduction (e.g., Designated Router).
これらの特性は、洪水削減、トポロジ還元、隣接還元（例えば、指定ルーター）など、対照交通削減のための既存のメカニズムを含むがこれらに限定されないいくつかのOSPFV3メカニズムと互換性がありません。
An interface of the OSPFv3 MANET interface type is the point of attachment of an OSPFv3 router to a network that may have MANET characteristics. That is, an interface of the OSPFv3 MANET interface type is able to accommodate the MANET characteristics described in Section 3.1. An OSPFv3 MANET interface type is not prescribing a set of behaviors or expectations that the network is required to satisfy. Rather, it is describing operating conditions under which protocols on an interface towards that network must be able to function (i.e., the protocols are required to be able to operate correctly when faced with the characteristics described in Section 3.1). As such, the OSPFv3 MANET interface type is a generalization of other OSPFv3 interface types; for example, a protocol operating correctly over an OSPFv3 MANET interface would also operate correctly over an OSPFv3 broadcast interface (whereas the inverse would not necessarily be true).
OSPFV3 MANETインターフェイスタイプのインターフェイスは、MANET特性を持つ可能性のあるネットワークにOSPFV3ルーターを付着するポイントです。つまり、OSPFV3 MANETインターフェイスタイプのインターフェイスは、セクション3.1で説明されているMANET特性に対応できます。OSPFV3 MANETインターフェイスタイプは、ネットワークが満たすために必要な一連の動作や期待を処方するものではありません。むしろ、そのネットワークに向かってインターフェイス上のプロトコルが機能できる必要がある操作条件を説明しています（つまり、セクション3.1で説明されている特性に直面した場合、プロトコルは正しく動作できるようにする必要があります）。そのため、OSPFV3 MANETインターフェイスタイプは、他のOSPFV3インターフェイスタイプの一般化です。たとえば、OSPFV3 MANETインターフェイスで正しく動作するプロトコルは、OSPFV3ブロードキャストインターフェイスでも正しく動作します（逆は必ずしも真実ではありません）。
Efficient OSPFv3 operation over MANETs relies on control-traffic reduction and on using mechanisms appropriate for semi-broadcast. The OSPFv3 MANET interface type, defined in this document, allows networks with MANET characteristics into the OSPFv3 framework by integrating mechanisms (flooding-reduction, topology-reduction, and adjacency-reduction) derived from solutions standardized by the MANET working group.
マネットを介した効率的なOSPFV3操作は、対照交通削減とセミブロードキャストに適したメカニズムの使用に依存しています。このドキュメントで定義されているOSPFV3 MANETインターフェイスタイプは、MANETワーキンググループによって標準化されたソリューションから導出されたメカニズム（洪水還元、トポロジ還元、隣接還元）を統合することにより、MANET特性を備えたネットワークをOSPFV3フレームワークに入れます。
The OSPFv3 MANET interface type, defined in this specification, makes use of flooding-reduction, topology-reduction, and adjacency-reduction, all based on MPR, a technique derived from [RFC3626], as standardized in the MANET working group. Multicast transmissions of protocol packets are used when possible.
この仕様で定義されているOSPFV3 MANETインターフェイスタイプは、MANETワーキンググループで標準化された[RFC3626]に由来する手法であるMPRに基づいて、洪水削減、トポロジ削減、および隣接還元を利用しています。プロトコルパケットのマルチキャストトランスミッションは、可能であれば使用されます。
OSPFv3 MANET interfaces use a flooding-reduction mechanism, denoted MPR flooding [MPR], whereby only a subset of MANET neighbors (those selected as Flooding-MPR) participate in a flooding operation. This reduces the number of (re)transmissions necessary for a flooding operation [MPR-analysis], while retaining resilience against transmission errors (inherent when using wireless links) and against obsolete two-hop neighbor information (e.g., as caused by router mobility) [MPR-robustness].
OSPFV3 MANETインターフェイスは、MPR洪水[MPR]を示している洪水削減メカニズムを使用します。これにより、洪水操作に必要な（再）送信の数が減り、伝送エラー（ワイヤレスリンクを使用する場合は固有）および廃止された2ホップ隣接情報（例えば、ルーターの可動性によって引き起こされるような）に対する回復力を保持しながら、[MPR-robustness]。
OSPFv3 MANET interfaces use a topology-reduction mechanism, denoted MPR topology-reduction, whereby only necessary links to MANET neighbors (those identified by Path-MPR selection as belonging to shortest paths) are included in LSAs. Routers in a MANET periodically generate and flood Router-LSAs describing their selection of such links to their Path-MPRs. Such links are reported as point-to-point links. This reduces the size of LSAs originated by routers on a MANET [MPR-topology], while retaining classic OSPF properties: optimal paths using synchronized adjacencies (if synchronized paths are preferred over non-synchronized paths of equal cost).
OSPFV3 MANETインターフェイスは、MPRトポロジ還元を示すトポロジ削減メカニズムを使用します。これにより、MANET隣接（最短経路に属するパス-MPR選択によって識別されるもの）がLSAに含まれているものが必要です。マネのルーターは、パスMPRへのそのようなリンクの選択を説明するルーターLSAを定期的に生成および洪水します。このようなリンクは、ポイントツーポイントリンクとして報告されます。これにより、MANET [MPR-Topology]のルーターから由来するLSAのサイズが削減され、同期された隣接を使用して最適なパスを保持しながら、同期されたパスが同期されたパスが等しいコストの非同期パスよりも優先される場合）。
OSPFv3 MANET interfaces employ multicast transmissions when possible, thereby taking advantage of inherent broadcast capabilities of the medium, if present (with wireless interfaces, this can often be the case [RFC2501]). In particular, LSA acknowledgments are sent via multicast over these interfaces, and retransmissions over the same interfaces are considered as implicit acknowledgments. Jitter management, such as delaying packet (re)transmission, can be employed in order to allow several packets to be bundled into a single transmission, which may avoid superfluous retransmissions due to packet collisions [RFC5148].
OSPFV3 MANETインターフェイスは、可能な場合はマルチキャストトランスミッションを採用しているため、存在する場合（ワイヤレスインターフェイスを使用して、これはしばしば[RFC2501]）になる可能性があります）。特に、LSAの謝辞はこれらのインターフェイスを介してマルチキャストを介して送信され、同じインターフェイス上の再送信は暗黙的な確認と見なされます。パケット（RE）送信の遅延などのジッター管理を使用するために、いくつかのパケットを単一の送信にバンドルできるようにすることができます。
Adjacencies over OSPFv3 MANET interfaces are required to be formed only with a subset of the neighbors of that OSPFv3 MANET interface. No Designated Router or Backup Designated Router are elected on an OSPFv3 MANET interface. Rather, adjacencies are brought up over an OSPFv3 MANET interface only with MPRs and MPR selectors. Only a small subset of routers in the MANET (called Synch routers) are required to bring up adjacencies with all their MANET neighbors. This reduces the amount of control traffic needed for database synchronization, while ensuring that LSAs still describe only synchronized adjacencies.
OSPFV3 MANETインターフェイスを介した隣接は、そのOSPFV3 MANETインターフェイスの近隣のサブセットでのみ形成する必要があります。指定されたルーターまたはバックアップ指定ルーターは、OSPFV3 MANETインターフェイスで選出されません。むしろ、隣接は、MPRSおよびMPRセレクターとのみOSPFV3 MANETインターフェースを介して提起されます。マネのルーターの小さなサブセットのみ（同期ルーターと呼ばれる）は、すべてのマネの隣人と隣接するために必要です。これにより、データベースの同期に必要な制御トラフィックの量が減少し、LSAが同期した隣接のみを記述することを保証します。
This section complements [RFC5340] and specifies the information that must be maintained, processed, and transmitted by routers that operate one or more OSPFv3 MANET interfaces.
このセクションは[RFC5340]を補完し、1つ以上のOSPFV3 MANETインターフェイスを操作するルーターで維持、処理、送信する必要がある情報を指定します。
In addition to the values used in [RFC5340], the Type field in the interface data structure can take a new value, "MANET". Furthermore, and in addition to the protocol structures defined by [RFC5340], routers that operate one or more MANET interfaces make use of the data structures described below.
[RFC5340]で使用される値に加えて、インターフェイスデータ構造の型フィールドは、新しい値「Manet」を取得できます。さらに、[RFC5340]で定義されたプロトコル構造に加えて、1つ以上のMANETインターフェイスを動作させるルーターは、以下に説明するデータ構造を利用します。
The Symmetric 1-hop Neighbor set N(i) records router IDs of the set of symmetric 1-hop neighbors of the router on interface i. More precisely, N(i) records tuples of the form:
対称1ホップネイバーセットn（i）は、インターフェイス上のルーターの対称1ホップネイバーのセットのルーターIDを記録します。より正確には、n（i）はフォームのタプルを記録します。
(1_HOP_SYM_id, 1_HOP_SYM_time)
（1_HOP_SYM_ID、1_HOP_SYM_TIME）
where:
ただし：
1_HOP_SYM_id: is the router ID of the symmetric 1-hop neighbor of this router over interface i.
1_HOP_SYM_ID：インターフェイス上のこのルーターの対称1ホップ隣接のルーターIDです。
1_HOP_SYM_time: specifies the time at which the tuple expires and MUST be removed from the set.
1_HOP_SYM_TIME：タプルの期限が切れる時間を指定し、セットから削除する必要があります。
For convenience throughout this document, N will denote the union of all N(i) sets for all MANET interfaces on the router.
このドキュメント全体で利便性のために、nはルーター上のすべてのMANETインターフェイスのすべてのn（i）セットの結合を示します。
The Symmetric strict 2-hop Neighbor set N2(i) records links between routers in N(i) and their symmetric 1-hop neighbors, excluding:
対称Strict 2-Hop Neighborは、N2（I）のルーターとその対称1ホップネイバーの間のリンクを記録します。
(i) the router performing the computation, and
(i) 計算を実行するルーター、および
(ii) all routers in N(i).
（ii）n（i）のすべてのルーター。
More precisely, N2(i) records tuples of the form:
より正確には、n2（i）はフォームのタプルを記録します。
(2_HOP_SYM_id, 1_HOP_SYM_id, 2_HOP_SYM_time)
（2_HOP_SYM_ID、1_HOP_SYM_ID、2_HOP_SYM_TIME）
where:
ただし：
2_HOP_SYM_id: is the router ID of a symmetric strict 2-hop neighbor.
2_HOP_SYM_ID：対称的な厳密な2ホップネイバーのルーターIDです。
1_HOP_SYM_id: is the router ID of the symmetric 1-hop neighbor of this router through which the symmetric strict 2-hop neighbor can be reached.
1_HOP_SYM_ID：対称的な厳密な2ホップ隣人に到達できるこのルーターの対称1ホップネイバーのルーターIDです。
2_HOP_SYM_time: specifies the time at which the tuple expires and MUST be removed from the set.
2_HOP_SYM_TIME：タプルの期限が切れる時間を指定し、セットから削除する必要があります。
For convenience throughout this document, N2 will denote the union of all N2(i) sets for all MANET interfaces on the router.
このドキュメント全体で便利なため、N2はルーター上のすべてのMANETインターフェイスのすべてのN2（i）セットの結合を示します。
The Flooding-MPR set on interface i records router IDs of a subset of the routers listed in N(i), selected such that, through this subset, each router listed in N2(i) is reachable in 2 hops by this router. There is one Flooding-MPR set per MANET interface. More precisely, the Flooding-MPR set records tuples of the form:
インターフェイスに設定されたフラッディング-MPR Iは、N（i）にリストされているルーターのサブセットのルーターIDを記録し、このサブセットを介してN2（i）にリストされている各ルーターがこのルーターによって2ホップで到達可能であるように選択されます。マネットインターフェイスごとに1つのフラッディングMPRセットがあります。より正確には、Flooding-MPRセットはフォームのタプルを記録します。
(Flooding_MPR_id, Flooding_MPR_time)
（flooding_mpr_id、flooding_mpr_time）
where:
ただし：
Flooding_MPR_id: is the router ID of the symmetric 1-hop neighbor of this router that is selected as Flooding-MPR.
Flooding_mpr_id：フラッディングMPRとして選択されているこのルーターの対称1ホップ隣接のルーターIDです。
Flooding_MPR_time: specifies the time at which the tuple expires and MUST be removed from the set.
flooding_mpr_time：タプルの有効期限が切れ、セットから削除する必要がある時間を指定します。
Flooding-MPR selection is detailed in Section 5.2.1.
洪水MPR選択については、セクション5.2.1で詳しく説明しています。
The Flooding-MPR-selector set on interface i records router IDs of the set of symmetric 1-hop neighbors of this router on interface i that have selected this router as their Flooding-MPR. There is one Flooding-MPR-selector set per MANET interface. More precisely, the Flooding-MPR-selector set records tuples of the form:
インターフェイスにflooding-MPRセレクターセットIインターフェイスIを記録します。このルーターの対称1ホップネイバーのセットのルーターIDは、このルーターをFlooding-MPRとして選択したインターフェイスIに記録します。MANETインターフェイスごとに1つのフラッディングMPRセレクターセットがあります。より正確には、Flooding-MPRセレクターセットは、フォームのタプルを記録します。
(Flooding_MPR_SELECTOR_id, Flooding_MPR_SELECTOR_time)
（flooding_mpr_selector_id、flooding_mpr_selector_time）
where:
ただし：
Flooding_MPR_SELECTOR_id: is the router ID of the symmetric 1-hop neighbor of this router, that has selected this router as its Flooding-MPR.
Flooding_mpr_selector_id：このルーターの対称1-HOP隣人のルーターIDは、このルーターをフラッディングMPRとして選択しました。
Flooding_MPR_SELECTOR_time: specifies the time at which the tuple expires and MUST be removed from the set.
flooding_mpr_selector_time：タプルの期限が切れる時間を指定し、セットから削除する必要があります。
Flooding-MPR selection is detailed in Section 5.2.1.
洪水MPR選択については、セクション5.2.1で詳しく説明しています。
The Path-MPR set records router IDs of routers in N that provide shortest paths from routers in N2 to this router. There is one Path-MPR set per router. More precisely, the Path-MPR set records tuples of the form:
Path-MPRは、N2のルーターからこのルーターまでの最短パスを提供するNのルーターのルーターIDを記録します。ルーターごとに1つのパスMPRセットがあります。より正確には、Path-MPRセットはフォームのタプルを記録します。
(Path_MPR_id, Path_MPR_time)
（path_mpr_id、path_mpr_time）
where:
ただし：
Path_MPR_id: is the router ID of the symmetric 1-hop neighbor of this router, selected as Path-MPR.
path_mpr_id：このルーターの対称1ホップ隣接のルーターIDで、path-mprとして選択されています。
Path_MPR_time: specifies the time at which the tuple expires and MUST be removed from the set.
PATH_MPR_TIME：タプルの有効期限が切れ、セットから削除する必要がある時間を指定します。
Path-MPR selection is detailed in Section 5.2.5.
PATH-MPR選択については、セクション5.2.5で詳しく説明しています。
The Path-MPR-selector set records router IDs of the set of symmetric 1-hop neighbors over any MANET interface that have selected this router as their Path-MPR. There is one Path-MPR-selector set per router. More precisely, the Path-MPR-selector set records tuples of the form:
Path-MPRセレクターセットは、このルーターをPath-MPRとして選択したMANETインターフェイスの上に、対称1ホップネイバーのセットのルーターIDを記録します。ルーターごとに1つのPath-MPRセレクターセットがあります。より正確には、Path-MPRセレクターはフォームのタプルを記録します。
(Path_MPR_SELECTOR_id, Path_MPR_SELECTOR_time)
（PATH_MPR_SELECTRE_ID、PATH_MPR_SELECTRE_TIME）
where:
ただし：
Path_MPR_SELECTOR_id: is the router ID of the symmetric 1-hop neighbor of this router that has selected this router as its Path-MPR.
path_mpr_selector_id：このルーターをそのpath-mprとして選択したこのルーターの対称1ホップ隣接のルーターIDです。
Path_MPR_SELECTOR_time: specifies the time at which the tuple expires and MUST be removed from the set.
PATH_MPR_SELECTOR_TIME：タプルが期限切れになり、セットから削除する必要がある時間を指定します。
Path-MPR selection is detailed in Section 5.2.5.
PATH-MPR選択については、セクション5.2.5で詳しく説明しています。
The MPR set is the union of the Flooding-MPR set(s) and the Path-MPR set. There is one MPR set per router.
MPRセットは、洪水とMPRセットの結合とPATH-MPRセットです。ルーターごとに1つのMPRセットがあります。
The MPR-selector set is the union of the Flooding-MPR-selector set(s) and the Path-MPR-selector set. There is one MPR-selector set per router.
MPRセレクターセットは、洪水とMPRセレクターセットの結合とPATH-MPRセレクターセットです。ルーターごとに1つのMPRセレクターセットがあります。
On OSPFv3 MANET interfaces, packets are sent, received, and processed as defined in [RFC5340] and [RFC2328], and augmented for MPR selection as detailed in this section.
OSPFV3 MANETインターフェイスでは、[RFC5340]および[RFC2328]で定義されているように、パケットが送信、受信、および処理され、このセクションで詳述されているようにMPR選択のために拡張されます。
All additional signaling for OSPFv3 MANET interfaces is done through inclusion of TLVs within an LLS block [RFC4813], which is appended to Hello packets. If an LLS block is not already present, an LLS block MUST be created and appended to the Hello packets.
OSPFV3 MANETインターフェイスのすべての追加シグナルは、LLSブロック[RFC4813]内にTLVを含めることで行われ、Hello Packetsに追加されます。LLSブロックがまだ存在していない場合、LLSブロックを作成してHelloパケットに追加する必要があります。
Hello packets sent over an OSPFv3 MANET interface MUST have the L bit of the OSPF Options field set, as per [RFC4813], indicating the presence of an LLS block.
[RFC4813]に従って、OSPFV3 MANETインターフェイスを介して送信されたHello PacketsがOSPFオプションフィールドセットのLビットを持つ必要があり、LLSブロックの存在を示しています。
This document defines and employs the following TLVs in Hello packets sent over OSPFv3 MANET interfaces:
このドキュメントでは、OSPFV3 MANETインターフェイスを介して送信されたHello Packetsで次のTLVを定義および採用しています。
FMPR - signaling Flooding-MPR selection;
FMPR -Signaling Flooding -MPR選択。
PMPR - signaling Path-MPR selection;
PMPR -Signaling Path -MPR選択。
METRIC-MPR - signaling metrics.
Metric -MPR-シグナリングメトリック。
The layout and internal structure of these TLVs is detailed in Section 6.
これらのTLVのレイアウトと内部構造については、セクション6で詳しく説明しています。
The objective of Flooding-MPR selection is for a router to select a subset of its neighbors such that a packet, retransmitted by these selected neighbors, will be received by all routers 2 hops away. This property is called the Flooding-MPR "coverage criterion". The Flooding-MPR set of a router is computed such that, for each OSPFv3 MANET interface, it satisfies this criterion. The information required to perform this calculation (i.e., link sensing and neighborhood information) is acquired through periodic exchange of OSPFv3 Hello packets.
Flood-MPR選択の目的は、ルーターが近隣のサブセットを選択して、これらの選択された隣人が再送信するパケットが2ホップ離れたすべてのルーターによって受信されるようにすることです。このプロパティは、洪水とMPR「カバレッジ基準」と呼ばれます。ルーターのフラッディングMPRセットは、各OSPFV3 MANETインターフェイスについて、この基準を満たすように計算されます。この計算を実行するために必要な情報（つまり、リンクセンシングと近隣情報）は、OSPFV3ハローパケットの定期的な交換を通じて取得されます。
Flooding-MPRs are computed by each router that operates at least one OSPFv3 MANET interface. The smaller the Flooding-MPR set is, the lower the overhead will be. However, while it is not essential that the Flooding-MPR set is minimal, the "coverage criterion" MUST be satisfied by the selected Flooding-MPR set.
フラッディングMPRは、少なくとも1つのOSPFV3 MANETインターフェイスを操作する各ルーターによって計算されます。フラッディングMPRセットが小さいほど、オーバーヘッドは低くなります。ただし、フラッディングMPRセットが最小限であることは必須ではありませんが、「カバレッジ基準」は選択したフラッディングMPRセットによって満たされる必要があります。
The willingness of a neighbor router to act as Flooding-MPR MAY be taken into consideration by a heuristic for Flooding-MPR selection. An example heuristic that takes willingness into account is given in Appendix A.
隣人のルーターが洪水MPRとして機能する意欲は、洪水MPR選択のためのヒューリスティックによって考慮されるかもしれません。意欲を考慮したヒューリスティックの例は、付録Aに記載されています。
A router MUST signal its Flooding-MPRs set to its neighbors by including an FMPR TLV in generated Hello packets. Inclusion of this FMPR TLV signals the list of symmetric 1-hop neighbors that the sending router has selected as Flooding-MPRs, as well as the willingness of the sending router to be elected Flooding-MPR by other routers. The FMPR TLV structure is detailed in Section 6.1.
ルーターは、生成されたハローパケットにFMPR TLVを含めることにより、近隣に設定された洪水MPRSを信号する必要があります。このFMPR TLVを含めると、送信ルーターが洪水MPRとして選択した対称1ホップ近隣のリストと、他のルーターによってフラッディングMPRに選出されるルーターの送信意欲があります。FMPR TLV構造は、セクション6.1で詳しく説明されています。
Neighbors listed in the Hello packets sent over OSPFv3 MANET interfaces MUST be included in the order as given below:
OSPFV3 MANETインターフェイスを介して送信されたHello Packetsにリストされている隣人は、以下に示すように順序に含める必要があります。
1. symmetric 1-hop neighbors that are selected as Flooding-MPRs;
1. 洪水MPRSとして選択された対称1ホップ隣接。
2. other symmetric 1-hop neighbors;
2. その他の対称1ホップ隣人。
3. other 1-hop neighbors.
3. 他の1ホップの隣人。
This ordering allows correct interpretation of an included FMPR TLV.
この順序付けにより、含まれているFMPR TLVの正しい解釈が可能になります。
Hello packets sent over OSPFv3 MANET interfaces MUST advertise the costs of links towards ALL the symmetric MANET neighbors of the sending router. If the sending router has more than one OSPFv3 MANET interface, links to ALL the symmetric MANET neighbors over ALL the OSPFv3 MANET interfaces of that router MUST have their costs advertised.
ospfv3 manetインターフェイスを介して送信されたこんにちはパケットは、送信ルーターのすべての対称的なマネの隣人へのリンクのコストを宣伝する必要があります。送信ルーターに複数のOSPFV3 MANETインターフェイスがある場合、そのルーターのすべてのOSPFV3 MANETインターフェイスのすべての対称的なマネの隣人にリンクして、コストを宣伝する必要があります。
The costs of the links between the router and each of its MANET neighbors on the OSPFv3 MANET interface over which the Hello packet is sent MUST be signaled by including METRIC-MPR TLVs. The METRIC-MPR TLV structure is detailed in Section 6.2.
ルーターとその各マネの隣人との間のリンクのコストは、Hello Packetが送信されるOSPFV3 MANETインターフェイスに登場します。メトリック-MPR TLV構造は、セクション6.2で詳しく説明されています。
Moreover, the lowest cost from each MANET neighbor towards the router (regardless of over which interface) MUST be specified in the included PMPR TLV. Note that the lowest cost can be over an interface that is not an OSPFv3 MANET interface.
さらに、各MANET隣人からルーターに向かう最低コスト（どのインターフェースに関係なく）を含むPMPR TLVで指定する必要があります。最低コストは、OSPFV3 MANETインターフェイスではないインターフェイスを介して行うことができることに注意してください。
A router that has one or more OSPFv3 MANET interfaces MUST select a Path-MPR set from among routers in N. Routers in the Path-MPR set of a router are those that take part in the shortest (with respect to the metrics used) path from routers in N2 to this router. A heuristic for Path-MPR selection is given in Appendix B.
1つ以上のOSPFV3 MANETインターフェイスを備えたルーターは、ルーターのパスMPRセットのN.ルーターのルーターの中からパスMPRセットを選択する必要があります。N2のルーターからこのルーターまで。PATH-MPR選択のヒューリスティックは、付録Bに記載されています。
A router MUST signal its Path-MPR set to its neighbors by including a PMPR TLV in generated Hello packets.
ルーターは、生成されたハローパケットにPMPR TLVを含めることにより、そのパス-MPRセットを隣接したものに信号する必要があります。
A PMPR TLV MUST contain a list of IDs of all symmetric 1-hop neighbors of all OSPFv3 MANET interfaces of the router. These IDs MUST be included in the PMPR TLV in the order as given below: 1. Neighbors that are both adjacent AND selected as Path-MPR for any OSPFv3 MANET interface of the router generating the Hello packet.
PMPR TLVには、ルーターのすべてのOSPFV3 MANETインターフェイスのすべての対称1ホップネイバーのIDのリストを含める必要があります。これらのIDは、以下に示すように、PMPR TLVに順序で含める必要があります。1。Helloパケットを生成するルーターの任意のOSPFv3 MANETインターフェイスのPath-MPRとして隣接および選択されている近隣。
2. Neighbors that are adjacent over any OSPFv3 MANET interface of the router generating the Hello packet.
2. Helloパケットを生成するルーターのOSPFV3 MANETインターフェイスに隣接する隣人。
3. Symmetric 1-hop neighbors on any OSPFv3 MANET interface of the router generating the Hello packet that have not been previously included in this PMPR TLV.
3. このPMPR TLVに以前に含まれていなかったハローパケットを生成するルーターのOSPFV3 MANETインターフェイスの対称1ホップネイバー。
The list of neighbor IDs is followed by a list of costs for the links from these neighbors to the router generating the Hello packet containing this PMPR TLV, as detailed in Section 5.2.4. The PMPR TLV structure is detailed in Section 6.3.
近隣IDのリストの後に、セクション5.2.4で詳述されているように、このPMPR TLVを含むハローパケットを生成するこれらの隣人からルーターへのリンクのコストのリストが続きます。PMPR TLV構造は、セクション6.3で詳しく説明されています。
In addition to the processing specified in [RFC5340], N and N2 MUST be updated when received Hello packets indicate changes to the neighborhood of an OSPFv3 MANET interface i. In particular, if a received Hello packet signals that a tuple in N (or N2) is to be deleted, the deletion is done immediately, without waiting for the tuple to expire. Note that N2 records not only 2-hop neighbors listed in received Hellos but also 2-hop neighbors listed in the appended PMPR TLVs.
[RFC5340]で指定された処理に加えて、受信した場合はNおよびN2を更新する必要があります。ハローパケットは、OSPFV3 MANETインターフェイスIの近傍の変更を示しています。特に、受信したハローパケットがN（またはN2）のタプルが削除されることを信号する場合、タプルが期限切れになるのを待つことなく、削除がすぐに行われます。N2は、受信したHellosにリストされている2ホップの隣人だけでなく、追加されたPMPR TLVにリストされている2ホップの隣人も記録することに注意してください。
The Flooding-MPR set MUST be recomputed when either of N(i) or N2(i) has changed. The Path-MPR set MUST be recomputed when either of N or N2 has changed. Moreover, the Path-MPR set MUST be recomputed if appended LLS information signals change with respect to one or more link costs.
n（i）またはn2（i）のいずれかが変更された場合、洪水MPRセットは再計算する必要があります。NまたはN2のいずれかが変更された場合、Path-MPRセットは再計算する必要があります。さらに、1つ以上のリンクコストに関してLLS情報信号が変更された場合、PATH-MPRセットを再計算する必要があります。
The Flooding-MPR-selector set and the Path-MPR-selector set MUST be updated upon receipt of a Hello packet containing LLS information indicating changes in the list of neighbors that has selected the router as MPR.
フラッディング-MPRセレクターセットとPath-MPRセレクターセットは、ルーターをMPRとして選択した近隣のリストの変更を示すLLS情報を含むハローパケットを受け取ったときに更新する必要があります。
If a Hello with the S bit set is received on an OSPFv3 MANET interface of a router, from a non-adjacent neighbor, the router MUST transition this neighbor's state to ExStart.
S BITセットのHelloがルーターのOSPFV3 MANETインターフェイスで受信された場合、隣接していない隣人から、ルーターはこの隣人の状態をエクススタートするために移行する必要があります。
Adjacencies are brought up between OSPFv3 MANET interfaces as described in [RFC5340] and [RFC2328]. However, in order to reduce the control-traffic overhead over the OSPFv3 MANET interfaces, a router that has one or more such OSPFv3 MANET interfaces MAY bring up adjacencies with only a subset of its MANET neighbors.
[RFC5340]と[RFC2328]に記載されているように、OSPFV3 MANETインターフェイスの間に隣接が発生します。ただし、OSPFV3 MANETインターフェイス上のコントロールトラフィックオーバーヘッドを減らすために、1つ以上のOSPFV3 MANETインターフェイスを備えたルーターは、MANET隣人のサブセットのみを備えた隣接を引き起こす可能性があります。
Over an OSPFv3 MANET interface, a router MUST bring up adjacencies with all MANET neighbors that are included in its MPR set and its MPR-selector set; this ensures that, beyond the first hop, routes use synchronized links (if synchronized paths are preferred over non-synchronized paths of equal cost). A router MAY bring up adjacencies with other MANET neighbors, at the expense of additional synchronization overhead.
OSPFV3 MANETインターフェイスを超えると、ルーターは、MPRセットとMPRセレクターセットに含まれるすべてのMANET隣人と隣接する必要があります。これにより、最初のホップを超えて、ルートは同期リンクを使用することが保証されます（同期されたパスが等しいコストの非同期パスよりも優先される場合）。ルーターは、追加の同期オーバーヘッドを犠牲にして、他のMANETの隣人と隣接することがあります。
When a router does not form a full adjacency with a MANET neighbor, the state of that neighbor does not progress beyond 2-Way (as defined in [RFC2328]). A router can send protocol packets, such as LSAs, to a MANET neighbor in 2-Way state. Therefore, any packet received from a symmetric MANET neighbor MUST be processed.
ルーターがマネの隣人との完全な隣接を形成しない場合、その隣人の状態は2ウェイを超えて進行しません（[RFC2328]で定義されています）。ルーターは、LSAなどのプロトコルパケットを2ウェイ状態のMANET隣人に送信できます。したがって、対称的なマネの隣人から受け取ったパケットを処理する必要があります。
As with the OSPF broadcast interface [RFC2328], the next hop in the forwarding table MAY be a neighbor that is not adjacent. However, when a data packet has travelled beyond its first hop, the MPR-selection process guarantees that subsequent hops in the shortest path tree (SPT) will be over adjacencies (if synchronized paths are preferred over non-synchronized paths of equal cost).
OSPFブロードキャストインターフェイス[RFC2328]と同様に、フォワーディングテーブルの次のホップは、隣接していない隣人である場合があります。ただし、データパケットが最初のホップを超えて移動した場合、MPR選択プロセスは、最短パスツリー（SPT）の後続のホップが隣接を超えることを保証します（同期されたパスが等しいコストの非同期パスよりも優先される場合）。
Adjacencies are torn down according to [RFC2328]. When the MPR set or MPR-selector set is updated (due to changes in the neighborhood), and when a neighbor was formerly, but is no longer, in the MPR set or the MPR-selector set, then the adjacency with that neighbor is kept unless the change causes the neighbor to cease being a symmetric 1-hop neighbor.
隣接は[RFC2328]に従って取り壊されます。MPRセットまたはMPRセレクターセットが更新された場合（近隣の変更により）、隣人が以前にいたが、MPRセットまたはMPRセレクターセットではもはやいない場合、その隣人の隣接は変更により、隣人が対称1ホップ隣人であることをやめない限り、保持されます。
When a router receives Hello packets from a symmetric 1-hop neighbor that ceases to list this router as being adjacent (see Section 5.2.6), the state of that neighbor MUST be changed to:
ルーターが、このルーターを隣接するものとしてリストするのをやめる対称1ホップ隣人からハローパケットを受信する場合（セクション5.2.6を参照）、その隣人の状態は次のものに変更する必要があります。
1. 2-Way if the neighbor is not in the MPR set or MPR-selector set, or
1. 隣人がMPRセットまたはMPRセレクターセットにない場合、または
2. ExStart if either the neighbor is in the MPR set or MPR-selector set, or the neighbor or the router itself is a Synch router.
2. 隣接がMPRセットまたはMPRセレクターセットにあるか、隣接またはルーター自体が同期ルーターであるかのいずれかがスタートします。
Routers generate Router-LSAs periodically, using the format specified in [RFC5340] and [RFC2328].
ルーターは、[RFC5340]および[RFC2328]で指定された形式を使用して、ルーター-LSAを定期的に生成します。
Routers that have one or more OSPFv3 MANET interfaces MUST include the following links in the Router-LSAs that they generate:
1つ以上のOSPFV3 MANETインターフェイスを持つルーターは、生成するルーターLSAに次のリンクを含める必要があります。
o links to all neighbors that are in the Path-MPR set, AND
o Path-MPRセットにあるすべての隣人へのリンクと
o links to all neighbors that are in the Path-MPR-selector set.
o Path-MPRセレクターセットにあるすべての隣人へのリンク。
Routers that have one or more OSPFv3 MANET interfaces MAY list other links they have through those OSPFv3 MANET interfaces, at the expense of larger LSAs.
1つ以上のOSPFV3 MANETインターフェイスを備えたルーターは、LSAを大規模に犠牲にして、これらのOSPFV3 MANETインターフェイスを介して持っている他のリンクを一覧表示する場合があります。
In addition, routers that have one or more OSPFv3 MANET interfaces MUST generate updated Router-LSAs when either of the following occurs:
さらに、1つ以上のOSPFV3 MANETインターフェイスを持つルーターは、次のいずれかが発生した場合に更新されたルーター-LSAを生成する必要があります。
o a new adjacency has been brought up, reflecting a change in the Path-MPR set;
o Path-MPRセットの変更を反映して、新しい隣接能力が育ちました。
o a new adjacency has been brought up, reflecting a change in the Path-MPR-selector set;
o Path-MPRセレクターセットの変化を反映して、新しい隣接が育ちました。
o a formerly adjacent and advertised neighbor ceases to be adjacent;
o 以前は隣接し、宣伝されていた隣人が隣接することをやめます。
o the cost of a link to (or from) an advertised neighbor has changed.
o 広告された隣人へのリンクのコストが変更されました。
An originated LSA is flooded, according to [RFC5340], out all interfaces concerned by the scope of this LSA.
[RFC5340]によると、このLSAの範囲に関係するすべてのインターフェイスを出した[RFC5340]によると、起源のLSAが浸水しています。
Link State Updates received on an interface of a type other than OSPFv3 MANET interface are processed and flooded according to [RFC2328] and [RFC5340], over every interface. If a Link State Update was received on an OSPFv3 MANET interface, it is processed as follows:
OSPFV3 MANETインターフェイス以外のタイプのインターフェイスで受信されたリンク状態の更新は、すべてのインターフェイスで[RFC2328]および[RFC5340]に従って処理および浸水します。OSPFV3 MANETインターフェイスでリンク状態の更新が受信された場合、次のように処理されます。
1. Consistency checks are performed on the received packet according to [RFC2328] and [RFC5340], and the Link State Update packet is thus associated with a particular neighbor and a particular area.
1. [RFC2328]および[RFC5340]に従って受信パケットで一貫性チェックが実行されるため、リンク状態の更新パケットは特定の隣の領域と特定の領域に関連付けられています。
2. If the Link State Update was received from a router other than a symmetric 1-hop neighbor, the Link State Update MUST be discarded without further processing.
2. 対称1ホップ隣接以外のルーターからリンク状態の更新が受信された場合、リンク状態の更新は、さらに処理することなく破棄する必要があります。
3. Otherwise, for each LSA contained in Link State Updates received over an OSPFv3 MANET interface, the following steps replace steps 1 to 5 of Section 13.3 of [RFC2328].
3. それ以外の場合、OSPFV3 MANETインターフェイスを介して受信したリンク状態の更新に含まれる各LSAについて、次の手順は[RFC2328]のセクション13.3のステップ1から5を置き換えます。
(1) If an LSA exists in the Link State Database, with the same Link State ID, LS Type, and Advertising Router values as the received LSA, and if the received LSA is not newer (see Section 13.1 of [RFC2328]), then the received LSA MUST NOT be processed, except for acknowledgment as described in Section 5.4.2.
(1) LSAがリンク状態データベースに存在し、受信したLSAと同じリンク状態ID、LSタイプ、および広告ルーター値を持つ場合、受信したLSAが新しい場合（[RFC2328]のセクション13.1を参照）、受信したものを参照）セクション5.4.2で説明されている承認を除き、LSAを処理してはなりません。
(2) Otherwise, the LSA MUST be attributed a scope according to its type, as specified in Section 3.5 of [RFC5340].
(2) それ以外の場合、[RFC5340]のセクション3.5で指定されているように、LSAはそのタイプに従ってスコープに起因する必要があります。
(3) If the scope of the LSA is link local or reserved, the LSA MUST NOT be flooded on any interface.
(3) LSAの範囲がローカルまたは予約されている場合、LSAをどのインターフェースにも浸水させてはなりません。
(4) Otherwise:
(4) さもないと：
+ If the scope of the LSA is the area, the LSA MUST be flooded on all the OSPFv3 interfaces of the router in that area, according to the default flooding algorithm described in Section 5.4.1.1.
+ LSAの範囲が領域である場合、セクション5.4.1.1で説明されているデフォルトの洪水アルゴリズムに従って、その領域のルーターのすべてのOSPFV3インターフェイスにLSAを浸水させる必要があります。
+ Otherwise, the LSA MUST be flooded on all the OSPFv3 interfaces of the router according to the default flooding algorithm described in Section 5.4.1.1.
+ それ以外の場合、セクション5.4.1.1で説明したデフォルトのフラッディングアルゴリズムに従って、ルーターのすべてのOSPFV3インターフェイスにLSAを浸水させる必要があります。
The default LSA flooding algorithm is as follows:
デフォルトのLSAフラッディングアルゴリズムは次のとおりです。
1. The LSA MUST be installed in the Link State Database.
1. LSAは、Link Stateデータベースにインストールする必要があります。
2. The Age of the LSA MUST be increased by InfTransDelay.
2. LSAの年齢は、Inftransdelayによって増加する必要があります。
3. The LSA MUST be retransmitted over all OSPFv3 interfaces of types other than OSPFv3 MANET interface.
3. LSAは、OSPFV3 MANETインターフェイス以外のすべてのOSPFV3インターフェイスで再送信する必要があります。
4. If the sending OSPFv3 interface is a Flooding-MPR-selector of this router, then the LSA MUST also be retransmitted over all OSPFv3 MANET interfaces concerned by the scope, with the multicast address all_SPF_Routers.
4. 送信OSPFV3インターフェイスがこのルーターのフラッディングMPRセレクターである場合、LSAは、マルチキャストアドレスALL_SPF_Routersを使用して、スコープによって関係するすべてのOSPFV3 MANETインターフェイスにも再送信する必要があります。
Note that MinLSArrival SHOULD be set to a value that is appropriate to dynamic topologies: LSA updating may need to be more frequent in MANET parts of an OSPF network than in other parts of an OSPF network.
MinlSarrivalは、動的なトポロジに適した値に設定する必要があることに注意してください。LSAの更新は、OSPFネットワークの他の部分よりもOSPFネットワークのMANET部分でより頻繁になる必要がある場合があります。
When a router receives an LSA over an OSPFv3 MANET interface, the router MUST proceed to acknowledge the LSA as follows:
ルーターがOSPFV3 MANETインターフェイスを介してLSAを受信した場合、ルーターは次のようにLSAを確認するために進む必要があります。
1. If the LSA was not received from an adjacent neighbor, the router MUST NOT acknowledge it.
1. LSAが隣接する隣人から受信されなかった場合、ルーターはそれを確認してはなりません。
2. Otherwise, if the LSA was received from an adjacent neighbor and if the LSA is already in the Link State Database (i.e., the LSA has already been received and processed), then the router MUST send an acknowledgment for this LSA on all OSPFv3 MANET interfaces to the multicast address all_SPF_Routers.
2. それ以外の場合は、LSAが隣接する隣人から受信され、LSAがすでにリンク状態データベースにある場合（つまり、LSAはすでに受信および処理されています）、ルーターはすべてのOSPFV3 MANETインターフェイスでこのLSAの確認を送信する必要があります。マルチキャストアドレスALL_SPF_Routers。
3. Otherwise, if the LSA is not already in the Link State Database:
3. それ以外の場合、LSAがまだリンク状態データベースにない場合：
1. If the router decides to retransmit the LSA (as part of the flooding procedure), the router MUST NOT acknowledge it, as this retransmission will be considered as an implicit acknowledgment.
1. ルーターがLSAを再送信することを決定した場合（洪水手順の一部として）、ルーターはそれを認めてはなりません。この再送信は暗黙の承認と見なされるためです。
2. Otherwise, if the router decides to not retransmit the LSA (as part of the flooding procedure), the router MUST send an explicit acknowledgment for this LSA on all OSPFv3 MANET interfaces to the multicast address all_SPF_Routers.
2. それ以外の場合、ルーターがLSAを再送信しないことを決定した場合（洪水手順の一部として）、ルーターはすべてのOSPFV3 MANETインターフェイスでこのLSAの明示的な確認をマルチキャストアドレスALL_SPF_ROUTERSに送信する必要があります。
If a router sends an LSA on an OSPFv3 MANET interface, it expects acknowledgments (explicit or implicit) from all adjacent neighbors. In the case where the router did not generate, but simply relays, the LSA, then the router MUST expect acknowledgments (explicit or implicit) only from adjacent neighbors that have not previously acknowledged this LSA. If a router detects that some adjacent neighbor has not acknowledged the LSA, then that router MUST retransmit the LSA.
ルーターがOSPFV3 MANETインターフェイスでLSAを送信する場合、すべての隣接する隣人から謝辞（明示的または暗黙的）が期待されます。ルーターがLSAを生成せず、単にリレーした場合、ルーターは、このLSAを以前に認めていなかった隣接する隣人からのみ謝辞（明示的または暗黙的）を期待する必要があります。ルーターが隣接する隣人がLSAを認めていないことを検出した場合、そのルーターはLSAを再送信する必要があります。
If, due to the MPR flooding-reduction mechanism employed for LSA flooding as described in Section 5.4.1, a router decides to not relay an LSA, the router MUST still expect acknowledgments of this LSA (explicit or implicit) from adjacent neighbors that have not previously acknowledged this LSA. If a router detects that some adjacent neighbor has not acknowledged the LSA, then the router MUST retransmit the LSA.
セクション5.4.1で説明されているようにLSA洪水に使用されたMPR洪水削減メカニズムのために、ルーターがLSAを中継しないことを決定した場合、ルーターは、このLSA（明示的または暗黙的）の隣接する隣人からの承認を期待する必要があります。以前はこのLSAを認めていませんでした。ルーターが隣接する隣人がLSAを認めていないことを検出した場合、ルーターはLSAを再送信する必要があります。
Note that it may be beneficial to aggregate several acknowledgments in the same transmission, taking advantage of native multicasting (if available). A timer wait MAY thus be used before any acknowledgment transmission.
ネイティブマルチキャストを利用して、同じトランスミッションにいくつかの承認を集約することが有益であることに注意してください（利用可能な場合）。したがって、承認伝送の前にタイマーの待機が使用される場合があります。
Additionally, jitter [RFC5148] on packet (re)transmission MAY be used in order to increase the opportunities to bundle several packets together in each transmission.
さらに、各伝送で複数のパケットをバンドルする機会を増やすために、パケット（RE）送信のJitter [RFC5148]を使用することができます。
In addition to the operations described in Section 5.2, Section 5.3 and Section 5.4, Hybrid routers MUST:
セクション5.2、セクション5.3およびセクション5.4で説明されている操作に加えて、ハイブリッドルーターは次のとおりです。
o select ALL their MANET neighbors as Path-MPRs.
o すべてのマネの隣人をPath-MPRSとして選択します。
o list adjacencies over OSPFv3 interfaces of types other than OSPFv3 MANET interface, as specified in [RFC5340] and [RFC2328], in generated Router-LSAs.
o 生成されたルーター-LSAの[RFC5340]および[RFC2328]で指定されているように、OSPFV3 MANETインターフェイス以外のタイプのOSPFV3インターフェイスの隣接をリストします。
In a network with no Hybrid routers, at least one Synch router MUST be selected. A Synch router MUST:
ハイブリッドルーターのないネットワークでは、少なくとも1つの同期ルーターを選択する必要があります。同期ルーターは次のことをする必要があります。
o set the S bit in the PMPR TLV appended to the Hello packets it generates, AND
o 生成するハローパケットに追加されたPMPR TLVにSビットを設定し、
o become adjacent with ALL MANET neighbors.
o すべてのマネの隣人と隣接する。
A proposed heuristic for selection of Sync routers is as follows:
同期ルーターの選択のための提案されたヒューリスティックは次のとおりです。
o A router that has a MANET interface and an ID that is higher than the ID of all of its current neighbors, and whose ID is higher than any other ID present in Router-LSAs currently in its Link State Database selects itself as Synch router.
o MANETインターフェイスを備えたルーターと、現在のすべての近隣のIDよりも高いIDで、現在リンク状態データベースにあるルーターLSAに存在する他のIDよりもIDが同期ルーターとして選択されています。
Other heuristics are possible; however, any heuristic for selecting Synch routers MUST ensure the presence of at least one Synch or Hybrid router in the network.
他のヒューリスティックが可能です。ただし、同期ルーターを選択するためのヒューリスティックは、ネットワーク内に少なくとも1つの同期またはハイブリッドルーターの存在を保証する必要があります。
When routing table (re)computation occurs, in addition to the processing of the Link State Database defined in [RFC5340] and [RFC2328], routers that have one or more MANET interfaces MUST take into account links between themselves and MANET neighbors that are in state 2-Way or higher (as data and protocol packets may be sent, received, and processed over these links too). Thus, the connectivity matrix used to compute routes MUST reflect links between the root and all its neighbors in state 2-Way and higher, as well as links described in the Link State Database.
[RFC5340]および[RFC2328]で定義されているリンク状態データベースの処理に加えて、テーブル（RE）計算をルーティング（RE）計算が発生する場合、1つ以上のMANETインターフェイスを持つルーターは、自分自身とMANET隣人との間のリンクを考慮に入れる必要があります。2方向以上の状態（データおよびプロトコルパケットは、これらのリンクで送信、受信、および処理される可能性があります）。したがって、ルートを計算するために使用される接続マトリックスは、ルート2ウェイ以上のルートとそのすべての近隣のリンク、ならびにリンク状態データベースで説明されているリンクを反映する必要があります。
OSPFv3 packets are as defined by [RFC5340] and [RFC2328]. Additional LLS signaling [RFC4813] is used in Hello packets sent over OSPFv3 MANET interfaces, as detailed in this section.
OSPFV3パケットは、[RFC5340]および[RFC2328]で定義されています。追加のLLSシグナル伝達[RFC4813]は、このセクションで詳述されているように、OSPFV3 MANETインターフェイスを介して送信されたHello Packetで使用されます。
This specification uses network byte order (most significant octet first) for all fields.
この仕様では、すべてのフィールドにネットワークバイト順序（最も重要なOctetの最初）を使用します。
A TLV of Type FMPR is defined for signaling Flooding-MPR selection, shown in Figure 1.
タイプFMPRのTLVは、図1に示すシグナリングフラッディングMPR選択のために定義されています。
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=FMPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Willingness | # Sym. Neigh. | # Flood MPR | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Flooding-MPR TLV (FMPR)
図1：フラッディング-MPR TLV（FMPR）
where:
ただし：
Willingness - is an 8-bit unsigned integer field that specifies the willingness of the router to flood link-state information on behalf of other routers. It can be set to any integer value from 1 to 6. By default, a router SHOULD advertise a willingness of WILL_DEFAULT = 3.
意欲 - は、他のルーターに代わってリンク状態情報をフラッディングするルーターの意欲を指定する8ビットの署名されていない整数フィールドです。1〜6の整数値に設定できます。デフォルトでは、ルーターはwill_default = 3の意欲を宣伝する必要があります。
# Sym. Neigh. - is an 8-bit unsigned integer field that specifies the number of symmetric 1-hop neighbors. These symmetric 1-hop neighbors are listed first among the neighbors in a Hello packet.
＃sym。いななき。 - 対称1ホップ近隣の数を指定する8ビットの署名されていない整数フィールドです。これらの対称1ホップの隣人は、ハローパケットの隣人の間で最初にリストされています。
# Flood MPR - is an 8-bit unsigned integer field that specifies the number of neighbors selected as Flooding-MPR. These Flooding-MPRs are listed first among the symmetric 1-hop neighbors.
＃flood MPR-は、8ビットの署名されていない整数フィールドで、フラッディングMPRとして選択された近隣の数を指定します。これらの洪水MPRは、対称1ホップの隣人の中に最初にリストされています。
Reserved - is an 8-bit field that SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception.
予約済み - 伝送でクリア（ '0'）をクリアする必要がある8ビットフィールドであり、レセプションで無視する必要があります。
A TLV of Type METRIC-MPR is defined for signaling costs of links to neighbors, shown in Figure 2.
型メトリック-MPRのTLVは、図2に示すように、近隣へのリンクのシグナルコストについて定義されています。
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=METRIC-MPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |U|R| Cost 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost 1 | Cost 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Metric TLV (METRIC-MPR)
図2：メトリックTLV（メトリック-MPR）
where:
ただし：
Reserved - is a 14-bit field that SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception.
予約済み - 伝送でクリア（ '0'）をクリアする必要がある14ビットフィールドであり、受信で無視する必要があります。
R - is a binary flag, cleared ('0') if the costs advertised in the TLV are direct (i.e., the costs of the links from the router to the neighbors), or set ('1') if the costs advertised are reverse (i.e., the costs of the links from the neighbors to the router). By default, R is cleared ('0').
r-はバイナリフラグであり、TLVで宣伝されているコストが直接（つまり、ルーターからネイバーへのリンクのコスト）、または宣伝されているコストの場合（ '1'）を設定する場合（ '0'）クリアされます（ '0'）逆（つまり、隣人からルーターへのリンクのコスト）。デフォルトでは、Rはクリアされています（ '0'）。
U - is a binary flag, cleared ('0') if the cost for each link from the sending router and to each advertised neighbor is explicitly included (shown in Figure 3), or set ('1') if a single metric value is included that applies to all links (shown in Figure 4).
u-はバイナリフラグであり、送信ルーターと宣伝されている各隣人への各リンクのコストが明示的に含まれている場合（図3に示す）、または単一のメトリック値の場合はset（ '1'）が明確になります（ '0'）すべてのリンクに適用される（図4に示す）が含まれています。
Cost n - is an 8-bit unsigned integer field that specifies the cost of the link, in the direction specified by the R flag, between this router and the neighbor listed at the n-th position in the Hello packet when counting from the beginning of the Hello packet and with the first neighbor being at position 0.
コストn - は、このルーターと最初からカウントするときにハローパケットのn番目の位置にリストされているrフラグで指定された方向に、リンクのコストを指定する8ビットの署名されていない整数フィールドです。ハローパケットと最初の隣人が位置0にあります。
Padding - is a 16-bit field that SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception. Padding is included in order that the TLV is 32-bit aligned. Padding MUST be included when the TLV contains an even number of Cost fields and MUST NOT be included otherwise.
パディング - トランスミッションでクリア（ '0'）をクリアする必要がある16ビットフィールドであり、レセプションで無視する必要があります。パディングは、TLVが32ビットアライメントされるために含まれています。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=METRIC-MPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |0|R| Cost 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost 1 | Cost 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Metric Advertisement TLV (METRIC-MPR) example with explicit individual link costs (U=0) and an odd number of Costs (and, hence, no padding).
図3：明示的な個々のリンクコスト（U = 0）と奇数のコスト（したがって、パディングなし）を備えたメトリック広告TLV（メトリック-MPR）の例。
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=METRIC-MPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |1|R| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Metric Advertisement TLV (METRIC-MPR) example with a single and uniform link cost (U=1) (and, hence, no padding).
図4：単一および均一なリンクコスト（u = 1）（したがって、パディングなし）のメトリック広告TLV（メトリック-MPR）の例。
A TLV of Type PMPR is defined for signaling Path-MPR selection, shown in Figure 1, as well as the link cost associated with these Path-MPRs.
タイプPMPRのTLVは、図1に示すシグナリングパスMPR選択と、これらのパスMPRに関連付けられたリンクコストのために定義されます。
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=PMPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Sym Neigh | # Adj. Neigh | # Path-MPR | Reserved |U|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost 0 | Cost 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Path-MPR TLV (PMPR)
図5：Path-MPR TLV（PMPR）
# Sym Neigh. - is an 8-bit unsigned integer field that specifies the number of symmetric 1-hop MANET neighbors of all OSPFv3 MANET interfaces of the router, listed in the PMPR TLV.
＃sym neight。-PMPR TLVにリストされているルーターのすべてのOSPFV3 MANETインターフェイスの対称1ホップMANETネイバーの数を指定する8ビットの署名されていない整数フィールドです。
# Adj. Neigh. - is an 8-bit unsigned integer field that specifies the number of adjacent neighbors. These adjacent neighbors are listed first among the symmetric 1-hop MANET neighbors of all OSPFv3 MANET interfaces of the router in the PMPR TLV.
＃adj。いななき。 - 隣接する隣人の数を指定する8ビットの署名されていない整数フィールドです。これらの隣接する隣人は、PMPR TLVのルーターのすべてのOSPFV3 MANETインターフェイスの対称1ホップMANET隣接の中に最初にリストされています。
# Path-MPR - is an 8-bit unsigned integer field that specifies the number of MANET neighbors selected as Path-MPR. These Path-MPRs are listed first among the adjacent MANET neighbors in the PMPR TLV.
＃path-mpr-は、Path-MPRとして選択されたMANET隣人の数を指定する8ビットの署名されていない整数フィールドです。これらのパス-MPRは、PMPR TLVの隣接するMANET隣人の中に最初にリストされています。
Reserved - is a 6-bit field that SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception.
予約済み - 送信時にクリア（ '0'）をクリアする必要がある6ビットフィールドであり、レセプションで無視する必要があります。
U - is a binary flag, cleared ('0') if the cost for each link from each advertised neighbor in the PMPR TLV and to the sending router is explicitly included (as shown in Figure 6), or set ('1') if a single metric value is included that applies to all links (as shown in Figure 7).
u-はバイナリフラグであり、PMPR TLVおよび送信ルーターに広告された各リンクのコストが明示的に含まれている場合（図6を参照）、またはSET（ '1'）を明確にした場合（ '0'）クリアされています（ '0'）すべてのリンクに適用される単一のメトリック値が含まれている場合（図7に示すように）。
S - is a binary flag, cleared ('0') if the router brings up adjacencies only with neighbors in its MPR set and MPR-selector set, as per Section 5.3, or set ('1') if the router brings up adjacencies with all MANET neighbors as a Synch router, as per Section 5.6.
s-はバイナリフラグです。ルーターがMPRセットの近隣とMPRセレクターセットのみに隣接する場合（ '0'）、セクション5.3に従って、またはルーターが隣接する場合（ '1'）セット（ '1'）に隣接しますセクション5.6に従って、すべてのMANET隣人を同期ルーターとして。
Neighbor ID - is a 32-bit field that specifies the router ID of a symmetric 1-hop neighbor of an OSPFv3 MANET interface of the router.
Neighbor ID-は、ルーターのOSPFV3 MANETインターフェイスの対称1ホップネイバーのルーターIDを指定する32ビットフィールドです。
Cost n - is a 16-bit unsigned integer field that specifies the cost of the link in the direction from the n-th listed advertised neighbor in the PMPR TLV and towards this router. A default value of 0xFFFF (i.e., infinity) MUST be advertised unless information received via Hello packets from the neighbor specifies otherwise, in which case the received information MUST be advertised. If a neighbor is reachable via more than one interface, the cost advertised MUST be the minimum of the costs by which that neighbor can be reached.
Cost N-は、PMPR TLVおよびこのルーターに向かって、n番目にリストされている広告neighborからリンクのコストを指定する16ビットの署名のない整数フィールドです。0xFFFF（つまり、無限）のデフォルト値は、近隣からのハローパケットを介して受け取った情報が特に指定されていない限り、宣伝する必要があります。この場合、受信した情報を宣伝する必要があります。隣人が複数のインターフェイスを介して到達可能である場合、宣伝されているコストは、その隣人に到達できるコストの最小でなければなりません。
Padding - is a 16-bit field that SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception. Padding is included in order that the PMPR TLV is 32-bit aligned. Padding MUST be included when the TLV contains an odd number of Cost fields and MUST NOT be included otherwise.
パディング - トランスミッションでクリア（ '0'）をクリアする必要がある16ビットフィールドであり、レセプションで無視する必要があります。PMPR TLVが32ビットアライメントされるため、パディングは含まれています。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=PMPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Sym Neigh | # Adj. Neigh | # Path-MPR | Reserved |0|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost 1 | Cost 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ....... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost n-1 | Cost n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Path-MPR TLV (PMPR) with explicit individual link costs (U=0) and an even number of Cost fields (hence, no padding).
図6：明示的な個々のリンクコスト（U = 0）と偶数のコストフィールド（したがって、パディングなし）を備えたPath-MPR TLV（PMPR）。
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=PMPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Sym Neigh | # Adj. Neigh | # Path-MPR | Reserved |1|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Path-MPR TLV (PMPR) with a single and uniform link cost (U=1) (hence, padding included).
図7：単一および均一なリンクコスト（U = 1）（したがって、パディングが含まれている）を備えたパスMPR TLV（PMPR）。
[RFC4593] describes generic threats to routing protocols, whose applicability to OSPFv3 [RFC5340] is not altered by the presence of OSPFv3 MANET interfaces. As such, the OSPFv3 MANET interface type does not introduce new security threats to [RFC5340].
[RFC4593]は、OSPFV3 [RFC5340]への適用性がOSPFV3 MANETインターフェイスの存在によって変化しないというルーティングプロトコルに対する一般的な脅威を説明しています。そのため、OSPFV3 MANETインターフェイスタイプは、[RFC5340]に新しいセキュリティの脅威をもたらしません。
However, the use of a wireless medium and the lack of infrastructure, as enabled by the use of the OSPFv3 MANET interface type, may render some of the attacks described in [RFC4593] easier to undertake.
ただし、OSPFV3 MANETインターフェイスタイプを使用することで有効にされているワイヤレス媒体とインフラストラクチャの欠如は、[RFC4593]に記載されている攻撃の一部を実施しやすくする可能性があります。
For example, control-traffic sniffing and control-traffic analysis are simpler tasks with wireless than with wires, as it is sufficient to be somewhere within radio range in order to "listen" to wireless traffic. Inconspicuous wiretapping of the right cable(s) is not necessary.
たとえば、コントロールトラフィックのスニッフィングとコントロールトラフィック分析は、ワイヤよりもワイヤのないワイヤレスのタスクです。無線トラフィックを「聞く」ために無線範囲内のどこかにいるだけで十分です。右のケーブルの目立たない盗聴は必要ありません。
In a similar fashion, physical signal interference is also a simpler task with wireless than with wires, as it is sufficient to emit from somewhere within radio range in order to be able to disrupt the communication medium. No complex wire connection is required.
同様に、物理的な信号干渉は、通信媒体を破壊できるように無線範囲内のどこかから放出するのに十分であるため、ワイヤよりもワイヤレスを使用するより単純なタスクでもあります。複雑なワイヤ接続は必要ありません。
Other types of interference (including not forwarding packets), spoofing, and different types of falsification or overloading (as described in [RFC4593]) are also threats to which routers using OSPFv3 MANET interfaces may be subject. In these cases, the lack of predetermined infrastructure or authority, enabled by the use of OSPFv3 MANET interfaces, may facilitate such attacks by making it easier to forge legitimacy.
他のタイプの干渉（転送パケットを含む）、スプーフィング、およびさまざまな種類の偽造または過負荷（[RFC4593]に記載されている）も、OSPFV3 MANET界面を使用してルーターが対象となる脅威です。これらの場合、OSPFV3 MANET界面を使用することで有効になっている所定のインフラストラクチャまたは権限の欠如は、正当性を容易にすることにより、そのような攻撃を促進する可能性があります。
Moreover, the consequence zone of a given threat, and its consequence period (as defined in [RFC4593]), may also be slightly altered over the wireless medium, compared to the same threat over wired networks. Indeed, mobility and the fact that radio range spans "further" than a mere cable may expand the consequence zone in some cases; meanwhile, the more dynamic nature of MANET topologies may decrease the consequence period, as harmful information (or lack of information) will tend to be replaced quicker by legitimate information.
さらに、特定の脅威の結果ゾーンとその結果期間（[RFC4593]で定義されている）も、有線ネットワーク上の同じ脅威と比較して、ワイヤレス媒体でわずかに変更される可能性があります。実際、モビリティと、無線範囲が単なるケーブルよりも「さらに」範囲に及ぶという事実は、場合によっては結果ゾーンを拡大する可能性があります。一方、MANETトポロジーのより動的な性質は、有害な情報（または情報の欠如）が正当な情報によってより迅速に置き換える傾向があるため、結果期間を短縮する可能性があります。
This document defines three LLS TLVs, for which type values have been allocated from the LLS TLV type registry defined in [RFC4813].
このドキュメントでは、[RFC4813]で定義されているLLS TLVタイプレジストリからタイプ値が割り当てられている3つのLLS TLVを定義します。
+------------+------------+--------------+
| Mnemonic | Type Value | Name |
+------------+------------+--------------+
| FMPR | 3 | Flooding-MPR |
| METRIC-MPR | 4 | Metric-MPR |
| PMPR | 5 | Path-MPR |
+------------+------------+--------------+
Table 1: LLS TLV Type Assignments
表1：LLS TLVタイプの割り当て
[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月。
[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
[RFC4813] Friedman、B.、Nguyen、L.、Roy、A.、Yeung、D。、およびA. Zinin、「OSPF Link-Local Signaling」、RFC 4813、2007年3月。
[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月。
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint Relaying for Flooding Broadcast Messages in Mobile Wireless Networks", Proceedings of HICSS , 2002.
[MPR] Qayyum、A.、Viennot、L。、およびA. Laouiti、「モバイルワイヤレスネットワークでの放送メッセージの洪水のための多重化リレー」、HICSSの議事録、2002年。
[MPR-analysis] Ngyuen, D. and P. Minet, "Analysis of MPR Selection in the OLSR Protocol", 2nd Int. Workshop on Performance Analysis and Enhancement of Wireless Networks, 2007.
[MPR分析] Ngyuen、D。およびP. Minet、「OLSRプロトコルにおけるMPR選択の分析」、2nd int。パフォーマンス分析とワイヤレスネットワークの強化に関するワークショップ、2007年。
[MPR-robustness] Adjih, C., Baccelli, E., Clausen, T., and P. Jacquet, "On the Robustness and Stability of Connected Dominated Sets", INRIA Research Report RR-5609, 2005.
[MPR-robustness] Adjih、C.、Baccelli、E.、Clausen、T。、およびP. Jacquet、「接続された支配セットの堅牢性と安定性について」、INRIA Research Report RR-5609、2005。
[MPR-topology] Baccelli, E., Clausen, T., and P. Jacquet, "Partial Topology in an MPR-based Solution for Wireless OSPF on Mobile Ad Hoc Networks", INRIA Research Report RR-5619, 2005.
[MPR-Topology] Baccelli、E.、Clausen、T。、およびP. Jacquet、「モバイルアドホックネットワーク上のワイヤレスOSPFのMPRベースのソリューションにおける部分トポロジ」、INRIA Research Report RR-5619、2005。
[RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, February 1999.
[RFC2501] Corson、S。およびJ. Macker、「モバイルアドホックネットワーキング（MANET）：ルーティングプロトコルのパフォーマンスの問題と評価の考慮事項」、RFC 2501、1999年2月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「最適化されたリンク状態ルーティングプロトコル（OLSR）」、RFC 3626、2003年10月。
[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月。
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008.
[RFC5148] Clausen、T.、Dearlove、C。、およびB. Adamson、「モバイルアドホックネットワーク（MANETS）におけるジッター考慮事項」、RFC 5148、2008年2月。
The following specifies a proposed heuristic for selection of Flooding-MPRs on interface i. It constructs a Flooding-MPR set that enables a router to reach routers in the 2-hop neighborhood through relaying by one Flooding-MPR router.
以下は、インターフェイスIでの洪水MPRの選択のための提案されたヒューリスティックを指定します。1つのフラッディングMPRルーターで中継して、ルーターが2ホップ近隣のルーターに到達できるようにする洪水MPRセットを構築します。
The following terminology will be used in describing the heuristics: D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a member of N(i), defined as the number of neighbors of router Y, EXCLUDING all the members of N(i) and EXCLUDING the router performing the computation. The proposed heuristic can then be described as follows. Begin with an empty Flooding-MPR set. Then:
次の用語は、ヒューリスティックの記述に使用されます。D（y）は1ホップ隣のルーターYの程度です（yはn（i）のメンバーであり、ルーターyの隣人の数として定義されます。n（i）のすべてのメンバーと計算を実行するルーターを除外します。提案されたヒューリスティックは次のように説明できます。空のフラッディングMPRセットから始めます。
1. Calculate D(Y), where Y is a member of N(i), for all routers in N(i).
1. n（i）のすべてのルーターについて、yはn（i）のメンバーであるd（y）を計算します。
2. Add to the Flooding-MPR set those routers in N(i) that are the only routers to provide reachability to a router in N2(i). For example, if router B in N2(i) can be reached only through a router A in N(i), then add router A to the Flooding-MPR set. Remove the routers from N2(i) that are now covered by a router in the Flooding-MPR set.
2. n2（i）のルーターに到達可能性を提供する唯一のルーターであるn（i）のこれらのルーターを洪水に追加します（i）。たとえば、n2（i）のルーターBにn（i）のルーターAを介してのみ到達できる場合、ルーターAをフラッディング-MPRセットに追加します。フラッディングMPRセットのルーターで覆われたN2（i）からルーターを取り外します。
3. While there exist routers in N2(i) that are not covered by at least one router in the Flooding-MPR set:
3. N2（i）にはルーターが存在しますが、Flood-MPRセットには少なくとも1つのルーターでカバーされていません。
1. For each router in N(i), calculate the reachability, i.e., the number of routers in N2(i) that are not yet covered by at least one router in the Flooding-MPR set, and that are reachable through this 1-hop neighbor;
1. n（i）の各ルーターについて、到達可能性、つまり、n2（i）のルーターの数を計算します。これは、フラッディングMPRセットの少なくとも1つのルーターでまだカバーされておらず、この1ホップで到達可能です。近所の人;
2. Select as a Flooding-MPR the neighbor with the highest willingness among the routers in N(i) with non-zero reachability. In case of a tie among routers with the same willingness, select the router that provides reachability to the maximum number of routers in N2(i). In case of another tie between routers also providing the same amount of reachability, select as Flooding-MPR the router whose D(Y) is greater. Remove the routers from N2(i) that are now covered by a router in the Flooding-MPR set.
2. n（i）のルーターの中で最高の意欲を持つ隣人を洪水として選択します。同じ意欲のあるルーター間のネクタイの場合、N2（i）の最大数のルーターに到達可能性を提供するルーターを選択します。ルーター間の別のネクタイの場合、同じ量の到達可能性も提供する場合、d（y）が大きいルーターをフラッディングMPRとして選択します。フラッディングMPRセットのルーターで覆われたN2（i）からルーターを取り外します。
4. As an optimization, consider in increasing order of willingness each router Y in the Flooding-MPR set: if all routers in N2(i) are still covered by at least one router in the Flooding-MPR set when excluding router Y, then router Y MAY be removed from the Flooding-MPR set.
4. 最適化として、フラッディング-MPRセットの各ルーターYの意欲の順序を増やすことを検討してください。N2（I）のすべてのルーターが、ルーターYを除外するときにフラッディングMPRセットの少なくとも1つのルーターで覆われている場合、ルーターYFlooding-MPRセットから削除できます。
Other algorithms, as well as improvements over this algorithm, are possible. Different routers may use different algorithms independently. However, the algorithm used MUST provide the router with a Flooding-MPR set that fulfills the flooding coverage criterion, i.e., it MUST select a Flooding-MPR set such that any 2-hop neighbor is covered by at least one Flooding-MPR router.
他のアルゴリズムと、このアルゴリズムの改善が可能です。異なるルーターは、異なるアルゴリズムを個別に使用する場合があります。ただし、使用されるアルゴリズムは、ルーターにフラッディングカバレッジ基準を満たすフラッディングMPRセットを提供する必要があります。つまり、2ホップ隣人が少なくとも1つのフラッディングMPRルーターでカバーされるように、フラッディングMPRセットを選択する必要があります。
The following specifies a proposed heuristic for calculating a Path-MPR set that enables a router to reach routers in the 2-hop neighborhood through shortest paths via routers in its Path-MPR set. The following terminology will be used for describing this heuristic:
以下は、パスMPRセットのルーターを介して最短パスを介してルーターが2ホップ近隣のルーターに到達できるようにするパスMPRセットを計算するための提案されたヒューリスティックを指定します。次の用語は、このヒューリスティックを説明するために使用されます。
A - The router performing the Path-MPR set calculation.
A -PATH -MPRセット計算を実行するルーター。
B, C, D, .... - Other routers in the network.
cost(A,B) - The cost of the path through the direct link, from A to B.
コスト（a、b） - 直接リンクを通るパスのコスト、aからBまで
dist(C,A) - The cost of the shortest path from C to A.
dist（c、a） - CからAまでの最短経路のコスト
A cost matrix is populated with the values of the costs of links originating from router A (available locally) and with values listed in Hello packets received from neighbor routers. More precisely, the cost matrix is populated as follows:
コストマトリックスには、ルーターA（ローカルで利用可能）から発信されるリンクのコストの値と、近隣ルーターから受信したハローパケットにリストされている値が埋め込まれています。より正確には、コストマトリックスは次のように入力されます。
1. The coefficients of the cost matrix are set by default to 0xFFFF (maximal value, i.e., infinity).
1. コストマトリックスの係数は、デフォルトで0xffff（最大値、つまり無限）に設定されます。
2. The coefficient cost(A,B) of the cost matrix for a link from router A to a neighbor B (the direct cost for this link) is set to the minimum cost over all interfaces that feature router B as a symmetric 1-hop neighbor. The reverse cost for this link, cost(B,A), is set at the value received in Hello packets from router B. If router B is reachable through several interfaces at the same time, cost(B,A) is set as the minimum cost advertised by router B for its links towards router A.
2. ルーターAからネイバーBへのリンクのコストマトリックスの係数コスト（a、b）（このリンクの直接コスト）は、ルーターBを対称1ホップネイバーとして囲むすべてのインターフェイスにわたって最小コストに設定されます。このリンクの逆コスト、コスト（b、a）は、ルーターBからハローパケットで受信された値に設定されます。ルーターBが複数のインターフェイスを介して同時に到達可能である場合、コスト（b、a）が設定されます。ルーターAへのリンクについてRouter Bが宣伝する最低コストA。
3. The coefficients of the cost matrix concerning the link between two neighbors of A, routers C and B, are populated at the reception of their Hello packets. The cost(B,C) is set to the value advertised by the Hello packets from B, and, respectively, the cost(C,B) is set to the value advertised in Hello packets from C.
3. ルーターCとBの2つの近隣の間のリンクに関するコストマトリックスの係数は、ハローパケットの受信時に入力されます。コスト（b、c）は、それぞれbからのhelloパケットによって宣伝されている値に設定され、それぞれコスト（c、b）はCからのhelloパケットで宣伝されている値に設定されます。
4. The coefficients cost(B,C) of the cost matrix for a link that connects a neighbor B to a 2-hop neighbor C are obtained via the Hello packets received from router B. In this case, cost(B,C) and cost(C,B) are respectively set to the values advertised by router B for the direct cost and reverse cost for node C.
4. ネイバーBを2ホップ隣接Cに接続するリンクのコストマトリックスの係数コスト（b、c）は、ルーターBから受信したハローパケットを介して取得されます。この場合、コスト（b、c）とコスト（c、b）ノードCの直接コストと逆コストのために、ルーターBによって宣伝された値にそれぞれ設定されます。
Once the cost matrix is populated, the proposed heuristic can then be described as follows. Begin with an empty Path-MPR set. Then:
コストマトリックスが入力されると、提案されたヒューリスティックは次のように説明できます。空のパスMPRセットから始めます。それから：
1. Using the cost matrix and the Dijkstra algorithm, compute the router distance vector, i.e., the shortest distance for each pair (X,A) where X is in N or N2 minimizing the sum of the cost of the path between X and A.
1. コストマトリックスとダイクストラアルゴリズムを使用して、ルーター距離ベクトル、つまり各ペアの最短距離（x、a）を計算します。ここで、xはnまたはn2です。
2. Compute N' as the subset of N made of the elements X such that cost(X,A)=dist(X,A).
2. コスト（x、a）= dist（x、a）である要素xで作られたnのサブセットとしてn 'を計算します。
3. Compute N2' as the subset of N and N2 made of the elements Y that do not belong to N' and such that there exist X in N' such cost(Y,X)+cost(X,A)=dist(Y,A).
3. N2 'をN2'として、N 'に属していない要素yで構成されたnおよびn2のサブセットとして、そのようなn'そのようなコスト（y、x）コスト（x、a）= dist（y、a）。
4. Compute the MPR selection algorithm presented in Appendix A with N' instead of N(i) and N2' instead of N2(i). The resulting MPR set is the Path-MPR set.
4. 付録Aで提示されたMPR選択アルゴリズムを計算します。N2（I）の代わりにN（I）およびN2 'の代わりにN'とN 'を使用します。結果のMPRセットはPATH-MPRセットです。
Other algorithms, as well as improvements over this algorithm, are possible. Different routers may use different algorithms independently. However, the algorithm used MUST provide the router with a Path-MPR set that fulfills the path coverage criterion, i.e., it MUST select a Path-MPR set such that for any element of N or N2 that is not in the Path-MPR set, there exists a shortest path that goes from this element to the router through a neighbor selected as Path-MPR (unless the shortest path is only one hop).
他のアルゴリズムと、このアルゴリズムの改善が可能です。異なるルーターは、異なるアルゴリズムを個別に使用する場合があります。ただし、使用されるアルゴリズムは、パスカバレッジ基準を満たすPATH-MPRセットをルーターに提供する必要があります。つまり、パス-MPRセットにないnまたはn2の要素に対してパスMPRセットを選択する必要があります。、この要素からルーターに移動する最も短いパスが存在します。パスMPRとして選択された隣接を介して（最も短いパスが1つのホップでない限り）。
The authors would like to thank Cedric Adjih, Acee Lindem, Padma Pillay-Esnault, and Laurent Viennot for their contributions to this document.
著者は、この文書への貢献について、Cedric Adjih、Acee Lindem、Acee Lindem、Padma Pillay-Esnault、およびLaurent Viennotに感謝したいと思います。
The authors would like to thank Juan Antonio Cordero Fuertes, Ulrich Herberg, and Richard Ogier for reviewing this document.
著者は、この文書をレビューしてくれたJuan Antonio Cordero Fuertes、Ulrich Herberg、Richard Ogierに感謝したいと思います。
Authors' Addresses
著者のアドレス
Emmanuel Baccelli INRIA
エマニュエル・バッケリ・インリア
Phone: +33 1 69 33 55 11
EMail: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Philippe Jacquet INRIA
フィリップ・ジャケット・インリア
Phone: +33 1 3963 5263
EMail: Philippe.Jacquet@inria.fr
Dang-Quan Nguyen CRC
Dang-quan nguyen Crc
Phone: +1-613-949-8216
EMail: dang.nguyen@crc.ca
Thomas Heide Clausen LIX, Ecole Polytechnique
Thomas Heide Clausen Lix、Ecole Polytechnique
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/