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
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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:
このドキュメントは[RFC2501]モバイルアドホックネットワーク（MANET）に適合し、提供メカニズムに基づいているの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].
これらのメカニズムは、マルチポイントリレー（MPR）、最適化リンク状態ルーティングプロトコル（OLSR）[RFC3626]で開発された技術に基づいています。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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]、およびリンクローカルシグナリング（LLS）の用語で定義されるように[RFC4813]で定義されるように、このドキュメントは、OSPFの用語を使用します。それは、OSPFの命名法に次の用語を紹介します：
OSPFv3 MANET interface - the OSPFv3 interface type for MANETs, as specified in this document.
OSPFv3 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 MANETインタフェース以外のタイプの唯一の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).
ネイバー - （任意の型の）OSPFv3のインタフェースを介して到達可能なルータ。
MANET neighbor - a neighbor, reachable through an OSPFv3 MANET interface.
MANETの隣人 - の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.
同期ルータ - そのMANETネイバーのすべてとの隣接関係が表示されますルータ。
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.
フラッディング-MPR - それはルータXから受信したすべてのブロードキャストプロトコルパケットを再送信するために、その対称の1ホップ隣人、ルータ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.
パス-MPR - XをルータにルータXの対称厳密2ホップ隣接ルータからの最短パス上にあるように、対称的な1ホップ隣人、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.
マルチポイントリレー（MPR） - フラッディング-MPR、パスMPR、または両方のいずれかとして、その対称の1ホップ隣人によって選択されたルータ。
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.
フラッディング-MPRセレクタ - その対称の1ホップ隣人を選択したルータ、ルータX、そのフラッディング-のMPRの一つとしては、ルータ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.
パス-MPRセレクタ - その対称の1ホップ隣人を選択したルータ、ルータX、そのパスのMPRの一つとしては、ルータ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セレクタ - そのフラッディング-のMPRのいずれか、そのパスのMPRの一つとして、その対称の1ホップ隣人、ルータXを、選択された、またはその両方がルータ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.
また、一般ネイバー間の帯域幅不足と干渉の問題を伴うそのうち後者 - アドホックネットワークにおける[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.
また、アドホックネットワークにおけるはしばしばすなわち「半ブロードキャスト」特性を示す、MANET内で伝送を行うルータRは、そのMANET内のルータの総数のサブセットが受信すること送信をとることができます。また、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インターフェイスタイプのインタフェースは、MANETの特性を有することができるネットワークへのOSPFv3ルータの結合点です。すなわち、OSPFv3のMANETインターフェイスタイプのインターフェイスは、セクション3.1に記載MANET特性に対応することが可能です。 OSPFv3のMANETインタフェースタイプは、動作や、ネットワークを満たすために必要とされる期待のセットを規定されていません。むしろ、それは（すなわち、プロトコルは3.1節で説明した特性に直面した場合に正常に動作することができるように要求されている）、そのネットワークに向かってインタフェース上のプロトコルが機能することができなければならない操作条件を記述しています。このように、
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インタフェースタイプは、他のOSPFv3インターフェイスタイプの一般化です。 （逆は必ずしも真ではない一方）は、例えば、MANETのOSPFv3インタフェースを介して正しく動作プロトコルは、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ワーキンググループで標準化ソリューションから誘導機構（フラッディング還元、トポロジー低減、および隣接還元）を積分することによってOSPFv3のフレームワークにMANET特性を有するネットワークを可能にします。
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.
MANETワーキンググループで標準化され、本明細書で定義されたOSPFv3 MANETインタフェースタイプは、フラッディング還元、トポロジー低減、および隣接還元、MPR、[RFC3626]に由来する技術に基づいて、すべてを利用します。プロトコルパケットのマルチキャスト送信が可能な場合に使用されています。
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インタフェースはフラッディング還元機構を使用し、MANETネイバー（フラッディング-MPRとして選択されたもの）のサブセットのみがフラッディング操作に関与することにより、MPRフラッディング[MPR]は、示さ。これは、（無線リンクを使用する場合、固有の）伝送エラーに対する耐性を保持しながら、時代遅れ2ホップネイバー情報に対して（例えば、ルータの移動によって引き起こされる）、フラッディング動作[MPR-分析]のために必要な（再）送信回数を減少させます[MPR-堅牢]。
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インタフェースはトポロジ減速機構を使用し、MANETネイバー（最短経路に属するものとしてパスMPR選択により同定されたもの）にのみ必要なリンクをのLSAに含まれていることにより、MPRのトポロジ還元は、示さ。 MANETにおけるルータは定期的にパスのMPRにこのようなリンクの彼らの選択を記述したルータ - LSAを生成し、洪水。このようなリンクは、ポイントツーポイントリンクとして報告されています。 （同期パスが等しいコストの非同期経路よりも好まれる場合）同期隣接関係を使用して、最適な経路：古典的なOSPFの特性を保持しながら、これは、MANET [MPR-トポロジー]上のルータによって発信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確認応答は、これらのインタフェース上のマルチキャストを介して送信され、同じインターフェイス上の再送信を暗黙の確認応答と見なされます。そのようなパケット（再）送信を遅らせるようジッター管理は、いくつかのパケットが原因パケット衝突[RFC5148]に余分な再送信を回避することができる単一の送信、にバンドルすることを可能にするために使用することができます。
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インタフェースに選出されていません。むしろ、隣接関係は唯一のMPRとMPRセレクタでのOSPFv3 MANETインタフェースを介し育っています。 MANET（Synchのルーターと呼ばれる）内のルータの小さなサブセットのみがすべての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]で定義されたプロトコルの構造に加えて、一つ以上の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:
N（i）を設定対称1ホップネイバーは、インターフェイス上のルータの対称の1ホップ隣人のセットIのルータ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:
：対称厳密2ホップネイバーは、N2（i）を除く、Nのルータ間のリンク（i）とその対称の1ホップ隣接を記録し
(i) the router performing the computation, and
（I）の演算を行うルータ、および
(ii) all routers in N(i).
（ⅱ）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は、このサブセットを通して、N2（I）に記載されている各ルータはこのルータによって2つのホップで到達可能であるよう、ことを選択N（I）に記載されているルータのサブセットのインタフェースIレコードルータIDに設定します。 MANETのインターフェイスごとに1つフラッディング-MPRセットがあります。より正確には、フラッディング-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:
そのフラッディング-MPRとしてこのルーターを選択したインターフェース上でこのルータの対称の1ホップ隣人のセットIのインタフェースIレコードのルータIDにフラッディング-MPRセレクタのセット。 MANETのインターフェイスごとに1つフラッディング-MPRセレクタセットがあります。より正確には、フラッディング-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は：そのフラッディング-MPRとしてこのルーターを選択したこのルータの対称の1ホップネイバーのルータIDです。
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:
このルータへのN2のルータからの最短経路を提供N内のルータの経路MPRセット・レコードのルータID。ルータごとに1パス-MPRセットがあります。より正確には、パス-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：パス-MPRとして選択し、このルータの対称1ホップ隣人のルータIDがあります。
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.
パス-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:
パスMPRセレクタは、それらのパス-MPRとしてこのルーターを選択した任意のMANETインタフェースを介して対称的な1ホップ隣人のセットのレコードのルータIDを設定します。ルータごとに1パス-MPRセレクタセットがあります。より正確には、パス-MPRセレクタは、フォームのレコードのタプルを設定します。
(Path_MPR_SELECTOR_id, Path_MPR_SELECTOR_time)
（Path_MPR_SELECTOR_id、Path_MPR_SELECTOR_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：そのパス-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.
パス-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セット（S）とパス-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セレクタのセット（S）とパス-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.
MANETのOSPFv3インターフェイスで、パケットは、送信され受信され、処理された[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.
MANETのOSPFv3インターフェイスのすべての追加のシグナリングは、Helloパケットに付加されたLLSブロック[RFC4813]内のTLVを含めることによって行われます。 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.
ハローのOSPFv3 MANETインタフェースを介して送信されるパケットは、LLSブロックの存在を示す、[RFC4813]に従って、OSPFオプションフィールドセットのLビットを持たなければなりません。
This document defines and employs the following TLVs in Hello packets sent over OSPFv3 MANET interfaces:
この文書は、定義とのOSPFv3 MANETインタフェースを介して送信されるHelloパケットの次のTLVを採用します。
FMPR - signaling Flooding-MPR selection;
FMPR - フラッディング-MPRの選択をシグナリング。
PMPR - signaling Path-MPR selection;
PMPR - パス-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.
フラッディング-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少なくとも一つの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を含むことによって、その隣接に設定されフラッディング-のMPRを通知しなければなりません。このFMPR TLVを含めることは、他のルータによりフラッディング-MPRを選出する送信ルータがフラッディング-のMPR、ならびに送信ルータの意欲として選択した対称の1ホップネイバーのリストを通知します。 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パケットに記載されている隣人が順番に含まれなければなりません。
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インタフェースを介して送信されたパケットが送信ルータのALL対称MANET隣人に対するリンクのコストを広告しなければなりません。送信ルータは、複数のOSPFv3 MANETインタフェースを持っている場合は、そのコストが宣伝していなければならないことをルータのすべてのOSPFv3 MANETインタフェース経由ALL対称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パケットが送信されるのOSPFv3 MANETインターフェイス上のルータとそのMANET隣人の各間のリンクのコストはMETRIC-MPR TLVを含むことによって合図しなければなりません。 METRIC-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.
一の以上のOSPFv3 MANETインタフェースを有するルータは、ルータの経路MPRセット内N.ルータのルータの中からパスMPRセットを選択しなければならない（使用されるメトリックに対して）最短経路に参加するものですこのルータへのN2のルータから。パス-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:
PMPR TLVは、ルータのすべてのOSPFv3 MANETインタフェースのすべての対称の1ホップネイバーのIDのリストを含まなければなりません。下記のように、これらのIDは、順番にPMPR TLVに含まれなければなりません：
1. Neighbors that are both adjacent AND selected as Path-MPR for any OSPFv3 MANET interface of the router generating the Hello packet.
両方の隣接したHelloパケットを生成ルータの任意のOSPFv3 MANETインタフェースのパス-MPRとして選択された1隣人。
2. Neighbors that are adjacent over any OSPFv3 MANET interface of the router generating the Hello packet.
Helloパケットを生成し、ルータのいずれかのOSPFv3 MANETインタフェースを介して隣接している2.隣人。
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.
以前にこのPMPR TLVには含まれていないHelloパケットを生成し、ルータのいずれかのOSPFv3 MANETインタフェース3.対称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.
5.2.4項で説明するように隣人IDのリストは、このPMPR TLVを含むHelloパケットを生成するルータにこれらの隣人からのリンクのためのコストのリストが続きます。 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.
ハローパケットはのOSPFv3 MANETインタフェースIの近傍への変更を示す受信したときに[RFC5340]で指定された処理に加えて、NおよびN2を更新する必要があります。具体的には、N（またはN2）にタプルが受信したHelloパケット信号を削除する場合、削除はタプルが期限切れを待つことなく、すぐに行われます。 N2レコードが受信ハローズに記載されている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のいずれかが変更されたときにパスMPRセットが再計算されなければなりません。添付LLS情報信号は、1つ以上のリンクコストに対して変更した場合また、パス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セレクタのセットとパス-MPRセレクタのセットは、MPRとしてのルータを選択した近隣のリストの変化を示すLLS情報を含むHelloパケットの受信時に更新されなければなりません。
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ビットが設定されたハローが非隣接ネイバーからルータのOSPFv3 MANETインタフェース上で受信された場合、ルータはのExStartこの隣人の状態に遷移しなければなりません。
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.
ルータはMANETネイバーとの完全な隣接関係を形成しない場合、そのネイバーの状態は、2ウェイ（[RFC2328]で定義される）を超えて進行しません。ルータは、2ウェイ状態でMANETネイバーに、そのようなLSAのようなプロトコルパケットを送信することができます。したがって、対称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:
ルータは（セクション5.2.6を参照）は、隣接するものとしてこのルータをリストしなくなる対称の1ホップ隣人からHelloパケットを受信した場合、そのネイバーの状態に変更されなければなりません。
1. 2-Way if the neighbor is not in the MPR set or MPR-selector set, or
1. 2ウェイネイバーは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.のExStartかのいずれかの隣人が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:
一の以上のOSPFv3 MANETインタフェースを持つルータは、彼らが発生するルータ - LSAの中に以下のリンクを含める必要があります。
o links to all neighbors that are in the Path-MPR set, AND
パス-MPRセット内にあるすべてのネイバーへのOリンク、
o links to all neighbors that are in the Path-MPR-selector set.
パス-MPRセレクタセット内にあるすべてのネイバーへのOリンク。
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.
一の以上の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:
次のいずれかが発生した場合に加えて、一の以上のOSPFv3 MANETインタフェースを持つルータは、ルータ - LSAを更新し生成する必要があります
o a new adjacency has been brought up, reflecting a change in the Path-MPR set;
O新しい隣接関係をパス-MPRセットの変化を反映して、育ててきました。
o a new adjacency has been brought up, reflecting a change in the Path-MPR-selector set;
O新しい隣接はパス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.
発信LSAは、このLSAの範囲によって関係、アウトすべてのインターフェイス[RFC5340]によれば、フラッディングされます。
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:
リンク状態の更新は、すべてのインタフェース上で、[RFC2328]及び[RFC5340]に従って処理し、フラッディングさのOSPFv3 MANETインタフェース以外のタイプのインターフェイスで受信しました。リンクステート更新の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.
リンク状態更新が対称1ホップネイバー以外のルータから受信された2.場合、リンク状態の更新は、さらなる処理なしで捨てなければなりません。
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.リンク状態更新情報に含まれる各LSAは、MANETのOSPFv3インタフェースを介して受信するためのそれ以外の場合は、次の手順は、[RFC2328]のセクション13.3の5〜ステップ1を置き換えます。
(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.
(2) Otherwise, the LSA MUST be attributed a scope according to its type, as specified in Section 3.5 of [RFC5340].
[RFC5340]のセクション3.5で指定されるように（2）それ以外の場合は、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.
+ 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.
+そうでない場合、LSAは、5.4.1.1項で説明するデフォルトのフラッディングアルゴリズムに従って、ルータのすべてのOSPFv3インターフェイスにフラッディングされなければなりません。
The default LSA flooding algorithm is as follows:
次のようにデフォルトのLSAフラッディングアルゴリズムは次のとおりです。
3. The LSA MUST be retransmitted over all OSPFv3 interfaces of types other than OSPFv3 MANET interface.
3. LSAは、MANETのOSPFv3インターフェイス以外のタイプのすべての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.
LSA更新は、OSPFネットワークの他の部分よりもOSPFネットワークのMANET部においてより頻繁である必要があります。MinLSArrivalは動的トポロジに適切な値に設定されるべきであることに注意してください。
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.
LSAは、隣接するネイバーから受信されなかった場合は1を、ルータがそれを承認してはなりません。
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にこのLSAに対する肯定応答を送らなければなりませんマルチキャストアドレスall_SPF_RoutersにMANETインタフェース。
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.
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を再送信しないことを決定する場合にそうでない場合、ルータは、マルチキャストアドレスall_SPF_RoutersにすべてのOSPFv3 MANETインタフェース上でこのLSAのための明示的な承認を送らなければなりません。
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.
また、パケットのジッタ[RFC5148]は（再）送信は、各送信で複数のパケットを一緒にバンドルする機会を増大させるために使用されてもよいです。
In addition to the operations described in Section 5.2, Section 5.3 and Section 5.4, Hybrid routers MUST:
、ハイブリッドルータはMUST 5.2節、5.3節および5.4節で説明した動作に加えて：
o select ALL their MANET neighbors as Path-MPRs.
OパスのMPRとしてすべてのMANETネイバーを選択します。
o list adjacencies over OSPFv3 interfaces of types other than OSPFv3 MANET interface, as specified in [RFC5340] and [RFC2328], in generated Router-LSAs.
生成されたルータのLSA-に、[RFC5340]及び[RFC2328]で指定されたOSPFv3のMANETインタフェース以外のタイプのOSPFv3インターフェイス、オーバーOリスト隣接。
In a network with no Hybrid routers, at least one Synch router MUST be selected. A Synch router MUST:
ないハイブリッドルータとネットワークでは、少なくとも一つの同期ルータが選択されなければなりません。 SynchのルータMUST：
o set the S bit in the PMPR TLV appended to the Hello packets it generates, AND
Oが生成Helloパケットに付加PMPR TLVのSビットを設定し、
o become adjacent with ALL MANET neighbors.
ALL MANETネイバーと隣接するようになります。
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.
MANETインタフェースとその現在の近隣の全てのIDよりも高く、かつそのIDルータ-LSAの中に存在する任意の他のIDが現在のリンク状態データベースに同期ルータとしてそれ自身を選択するよりも高いあるIDを有するルータO。
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つのSynchまたはハイブリッドルータの存在を確実にしなければなりません。
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]で定義されたリンクステートデータベースの処理に加えて、一つ以上の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.
[RFC5340]及び[RFC2328]で定義されるようにOSPFv3のパケットです。このセクションで詳述されるように[RFC4813]をシグナリング追加LLSは、MANETのOSPFv3インターフェイスを介して送信されるHelloパケットに使用されます。
This specification uses network byte order (most significant octet first) for all fields.
この仕様は、すべてのフィールドにネットワークバイト順（最上位オクテット）を使用しています。
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ビットの符号なし整数フィールドです。ルータがWILL_DEFAULT = 3の意欲をアドバタイズSHOULD、デフォルトで1から6までの任意の整数値に設定することができます。
# 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.
＃交響曲。いななき。 - 対称の1ホップ隣人の数を指定する8ビット符号なし整数フィールドです。これらの対称1ホップ隣人はHelloパケット中の隣人の間で最初に記載されています。
# 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.
＃洪水MPR - フラッディング-MPRとして選択されたネイバーの数を指定する8ビット符号なし整数フィールドです。これらのフラッディング-のMPRは、対称1ホップ隣人の間で最初に記載されています。
Reserved - is an 8-bit field that SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception.
予約 - 送信にクリアする必要があり、8ビットフィールド（「0」）であり、受信時に無視されるべきです。
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.
予約 - 送信にクリアする必要が14ビットフィールド（「0」）であり、受信時に無視されるべきです。
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」）をクリア、バイナリフラグであり、逆（すなわち、ルータへの隣人からのリンクのコスト）。デフォルトでは、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に示されている）が含まれ、または設定されている場合、単一のメトリック値があれば（「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は - 最初から数えたときにこのルータとのHelloパケットのn番目の位置に記載されている隣人の間、Rフラグによって指定された方向に、リンクのコストを指定する8ビット符号なし整数フィールドでありますHelloパケットのと最初の隣人が位置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：メトリック広告TLV明示的な個別リンクコスト（U = 0）とコストの奇数（及び、従って、パディングなし）と（メトリック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：メトリック広告TLV（したがって、無パディング）単一かつ均一なリンクコスト（U = 1）と（メトリック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：パス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.
＃交響曲いななき。 - 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.
＃調整]。いななき。 - 隣接する近隣の数を指定する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.
＃パス-MPRは、 - パス-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.
予約 - 送信にクリアする必要が6ビットのフィールド（「0」）であり、受信時に無視されるべきです。
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及び送信ルータに各アドバタイズ隣人から各リンクのコストを明示的に（「1」）（図6に示すように）含まれ、または設定されている場合（「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 - ルータはセクション5.3に従って、唯一のMPRセットとMPRセレクタのセットで隣人と隣接関係をもたらす、またはルータが隣接関係を立ち上げる場合（「1」）に設定した場合（「0」）クリア、バイナリフラグであります5.6節ごとなどのSynchルータなど、すべての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.
ネイバー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.
コストnは - PMPR TLVにこのルータに向かっアドバタイズネイバーリストされたn番目から方向リンクのコストを指定する16ビット符号なし整数フィールドです。隣人からのHelloパケットを介して受信した情報が受信された情報が広告されなければならない場合には、別段の指定がない限り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：パスMPR TLV（PMPR）明示的な個別のリンクコスト（U = 0）とコストフィールド（したがって、パディングなし）の偶数です。
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.
無線トラフィックを「リッスン」するために、どこかの無線範囲内にあることが十分であるように、例えば、スニッフィング制御トラフィック及び制御トラフィックの分析は、ワイヤよりも無線有する単純なタスクです。右ケーブル（S）の目立たない盗聴は不要です。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
[RFC4813]フリードマン、B.、グエン、L.、ロイ、A.、ヨン、D.、およびA.ジニン、 "OSPFリンクローカルシグナリング"、RFC 4813、2007年3月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[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選択の分析"、第二の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.
、INRIA研究報告RR-5609 2005年 "接続支配セットのロバスト性及び安定性について、" [MPR-堅牢] Adjih、C.、Baccelli、E.、Clausenの、T.、およびP.ジャケ、。
[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-トポロジ] Baccelli、E.、クラウゼン、T.、およびP.ジャケ、 "アドホックネットワーク上のワイヤレスOSPFのためのMPRベースのソリューションでは部分的なトポロジ"、INRIA研究報告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]コルソン、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]クラウゼン、T.およびP.ジャケ、 "最適化されたリンクステートルーティングプロトコル（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.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、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.アダムソン、RFC 5148、2008年2月 "モバイルアドホックネットワーク（MANET）におけるジッタの考慮事項"。
Appendix A. Flooding-MPR Selection Heuristic
付録A.洪水-MPR選択ヒューリスティック
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）は、ルータYの近傍の数として定義されるYは、N（i）のメンバーである1ホップ隣人、ルータY（の程度である除きます。次のようにN（i）とのすべてのメンバーは、計算を実行するルータを除く提案ヒューリスティックは、次に説明することができる空のフラッディング-MPRセットで開始します。：
1. Calculate D(Y), where Y is a member of N(i), for all routers in N(i).
1.計算D Yは、N（i）のメンバーである（Y）、N（I）のすべてのルータのために。
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.洪水-MPRに追加するには、N2（I）でルータに到達可能性を提供する唯一のルータであるN（i）におけるそれらのルータを設定します。 N2（I）のルータBは、N（i）におけるルータAを介してのみ到達できる場合、例えば、次にフラッディング-MPRセットにルータAを追加します。今フラッディング-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.フラッディング-MPRセットにおける少なくとも1つのルータによって覆われていないN2（I）内のルータが存在しているが：
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;
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.フラッディング-MPR等の非ゼロ到達可能性のあるN（I）内のルータの中で最高の意欲と隣接。同じ意欲とルータ間で同数の場合には、N2（i）におけるルータの最大数に到達可能性を提供するルータを選択します。また、到達可能性の同じ量を提供するルータの間に別のタイの場合には、フラッディング-MPRとしてそのD（Y）大きいルータを選択します。今フラッディング-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.
その後、N2（I）内のすべてのルータがまだフラッディング-MPRセットに少なくとも一つのルータで覆われている場合、ルータYを除いたとき：4.最適化として、フラッディング-MPRセットの各ルータY意欲の増加順に考えますルータYはフラッディング-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セットをルータに提供しなければならない、すなわち、それはフラッディング-MPRは、任意の2ホップネイバーは、少なくとも一つのフラッディング-MPRルータによって覆われるように設定選択しなければなりません。
Appendix B. Path-MPR Selection Heuristic
付録B.パス-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.
- パス-MPR集合計算を実行するルータ。
B, C, D, .... - Other routers in the network.
B、C、D、... - ネットワーク内の他のルータ。
cost(A,B) - The cost of the path through the direct link, from A to B.
コスト（A、B） - から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（利用可能なローカル）から発信リンクのコストの値とし、Helloパケットに記載されている値が移入された隣接ルータから受信しました。次のように、より正確には、コスト・マトリックスが取り込まれます。
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）は、対称1-としてルータBを備えてすべてのインターフェイス上の最小コストに設定されています隣人をホップ。ルータBは、コスト（B、A）のように設定され、同時に複数のインタフェースを介して到達可能である場合、このリンクのための逆方向コスト、コスト（B、A）は、ルータBからのHelloパケットで受信した値に設定されていますルータA.に対するそのリンクのルータBによってアドバタイズ最小コスト
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. A、ルータC及びBの両隣の間のリンクに関するコスト行列の係数は、それらのHelloパケットの受信に移入されます。コスト（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. 2ホップネイバーCに隣接Bを接続するリンクのコスト行列の係数コスト（B、C）はHelloパケットを介して得られるが、この場合には、ルータBから受信し、コスト（B、C）そして、コスト（C、B）は、それぞれ、直接コストのルータBによってアドバタイズ値に設定し、ノードCのコストを逆転さ
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がNまたはN2はXとAの間の経路のコストの和を最小化することである（X、A）のための最短距離。
2. Compute N' as the subset of N made of the elements X such that cost(X,A)=dist(X,A).
2.計算N」Nのサブセットは元素Xからなるようなそのコスト（X、A）= DIST（X、A）。
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' など（X、A）N「コスト（Y、X）+コストにXが存在することが= DIST Nに属していない要素YからなるNおよびN2のサブセットとして」（ 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.計算N」の代わりに、N（i）及びN2' の代わりにN2（I）と付録Aに提示MPR選択アルゴリズム。その結果MPRセットはパス-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).
他のアルゴリズムと同様に、このアルゴリズムに対する改良が可能です。異なるルータは、独立して、異なるアルゴリズムを使用することができます。しかし、使用されるアルゴリズムは、パスカバレッジ基準を満たすパスMPRセット、すなわちでルータを提供しなければなりません、それは、Path-MPRパス-MPRセットにないN又はN2の任意の要素のためにそのような設定を選択しなければなりません、（最短経路が一つだけのホップである場合を除く）パスMPRとして選択された隣接ルータを介してこの要素から行く最短経路が存在します。
Appendix C. Contributors
付録C.協力者
The authors would like to thank Cedric Adjih, Acee Lindem, Padma Pillay-Esnault, and Laurent Viennot for their contributions to this document.
作者はこのドキュメントへの貢献のためのセドリックAdjih、ACEE Lindem、パドマPillay-Esnault、およびローランViennotに感謝したいと思います。
Appendix D. Acknowledgments
付録D.謝辞
The authors would like to thank Juan Antonio Cordero Fuertes, Ulrich Herberg, and Richard Ogier for reviewing this document.
作者はこのドキュメントを再検討するためにフアン・アントニオ・コルデロFuertes、ウルリッヒHerberg、およびリチャードオジェに感謝したいと思います。
Authors' Addresses
著者のアドレス
Emmanuel Baccelli INRIA
エマニュエルBaccelli INRIA
Phone: +33 1 69 33 55 11 EMail: Emmanuel.Baccelli@inria.fr URI: http://www.emmanuelbaccelli.org/
電話：+33 1 69 33 55 11 Eメール：Emmanuel.Baccelli@inria.fr URI：http://www.emmanuelbaccelli.org/
Philippe Jacquet INRIA
フィリップジャケINRIA
Phone: +33 1 3963 5263 EMail: Philippe.Jacquet@inria.fr
電話：+33 1 3963 5263 Eメール：Philippe.Jacquet@inria.fr
Dang-Quan Nguyen CRC
ダン・グエン・クアンCRC
Phone: +1-613-949-8216 EMail: dang.nguyen@crc.ca
電話：+ 1-613-949-8216 Eメール：dang.nguyen@crc.ca
Thomas Heide Clausen LIX, Ecole Polytechnique
トーマス・ハイデクラウゼンLIX、エコールポリテクニック
Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.thomasclausen.org/
電話：+33 6 6058 9349 Eメール：T.Clausen@computer.org URI：http://www.thomasclausen.org/