Network Working Group E. Baccelli
Request for Comments: 5449 P. Jacquet
Category: Experimental INRIA
D. Nguyen
CRC
T. Clausen
LIX, Ecole Polytechnique
February 2009
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
用于adhoc网络的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.
版权所有（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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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
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:
本文件规定了OSPFv3[RFC5340]的扩展，该扩展适用于移动自组网（MANET）[RFC2501]，并基于提供以下功能的机制：
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[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移动自组网接口——本文件规定的移动自组网的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接口的路由器，包括至少一种OSPFv3 MANET接口类型。
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-hop邻居-对称1-hop邻居的对称1-hop邻居，其本身不是所考虑路由器的对称1-hop邻居。
Symmetric strict 2-hop neighborhood - the set formed by all the symmetric strict 2-hop neighbors of the considered router.
对称严格2-hop邻居-由所考虑路由器的所有对称严格2-hop邻居组成的集合。
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-由其对称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.
路径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.
多点中继（MPR）-由其对称1跳邻居选择为泛洪MPR、路径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.
泛洪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选择器-选择其对称1跳邻居路由器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.
MANET[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通常表现出“半广播”特性，即，在MANET内进行传输的路由器R只能假设该传输将由该MANET内的路由器总数的子集接收。此外，如果两个路由器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接口类型的接口是OSPFv3路由器与可能具有MANET特性的网络的连接点。也就是说，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接口类型的推广；例如，在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接口类型使用泛洪减少、拓扑减少和邻接减少，所有这些都基于MPR，这是一种源自[RFC3626]的技术，在MANET工作组中标准化。在可能的情况下使用协议包的多播传输。
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]，其中只有一部分MANET邻居（被选为泛洪MPR）参与泛洪操作。这减少了泛洪操作[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接口使用拓扑缩减机制，表示为MPR拓扑缩减，其中LSA中仅包括指向MANET邻居（通过路径MPR选择识别为属于最短路径的那些）的必要链路。MANET中的路由器周期性地生成并洪泛路由器LSA，描述它们对其路径MPR的此类链路的选择。此类链接报告为点对点链接。这减少了MANET[MPR拓扑]上路由器发起的LSA的大小，同时保留了经典的OSPF属性：使用同步邻接的最佳路径（如果同步路径优先于成本相等的非同步路径）。
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中只有一小部分路由器（称为同步路由器）需要与所有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]的补充，并规定了操作一个或多个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:
对称1-hop邻居集N（i）在接口i上记录路由器的对称1-hop邻居集的路由器id。更准确地说，N（i）记录以下形式的元组：
(1_HOP_SYM_id, 1_HOP_SYM_time)
（1跳符号id，1跳符号时间）
where:
哪里：
1_HOP_SYM_id: is the router ID of the symmetric 1-hop neighbor of this router over interface i.
1-HOP\u SYM\u id：是接口i上此路由器的对称1-HOP邻居的路由器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).
（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跳符号id，1跳符号id，2跳符号时间）
where:
哪里：
2_HOP_SYM_id: is the router ID of a symmetric strict 2-hop neighbor.
2-HOP\u SYM\u id：对称严格2-HOP邻居的路由器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：此路由器的对称1-HOP邻居的路由器id，通过它可以到达对称严格2-HOP邻居。
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:
接口i上设置的泛洪MPR记录N（i）中列出的路由器子集的路由器id，所选择的路由器使得通过该子集，N2（i）中列出的每个路由器可由该路由器在2跳内到达。每个MANET接口有一个泛洪MPR集。更准确地说，泛洪MPR集记录以下形式的元组：
(Flooding_MPR_id, Flooding_MPR_time)
（泛洪\u MPR\u id，泛洪\u MPR\u时间）
where:
哪里：
Flooding_MPR_id: is the router ID of the symmetric 1-hop neighbor of this router that is selected as Flooding-MPR.
泛洪\u MPR\u id：选择为泛洪MPR的此路由器的对称1跳邻居的路由器id。
Flooding_MPR_time: specifies the time at which the tuple expires and MUST be removed from the set.
泛洪\u MPR\u 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:
接口i上的泛洪MPR选择器集记录接口i上此路由器的对称1跳邻居集的路由器ID，这些邻居选择此路由器作为其泛洪MPR。每个MANET接口有一个泛洪MPR选择器集。更准确地说，泛洪MPR选择器集记录以下形式的元组：
(Flooding_MPR_SELECTOR_id, Flooding_MPR_SELECTOR_time)
（泛洪\u MPR\u选择器\u id、泛洪\u MPR\u选择器\u时间）
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.
泛洪\u MPR\u选择器\u id：此路由器的对称1跳邻居的路由器id，该路由器已选择此路由器作为其泛洪MPR。
Flooding_MPR_SELECTOR_time: specifies the time at which the tuple expires and MUST be removed from the set.
泛洪\u MPR\u选择器\u时间：指定元组过期且必须从集合中删除的时间。
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:
路径MPR集合记录N中路由器的路由器ID，这些路由器提供从N2中的路由器到该路由器的最短路径。每个路由器有一个路径MPR集。更准确地说，路径MPR集记录以下形式的元组：
(Path_MPR_id, Path_MPR_time)
（路径id、路径时间）
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\u MPR\u 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。每个路由器设置一个路径MPR选择器。更准确地说，路径MPR选择器集记录以下形式的元组：
(Path_MPR_SELECTOR_id, Path_MPR_SELECTOR_time)
（路径选择器id、路径选择器时间）
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.
路径\u MPR\u选择器\u时间：指定元组过期且必须从集合中删除的时间。
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集和路径MPR集的并集。每个路由器有一个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选择器集和路径MPR选择器集的并集。每个路由器有一个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数据包中。如果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数据包必须设置OSPF选项字段的L位，以表示存在LLS块。
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 Hello数据包获得。
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.
路由器必须通过在生成的Hello数据包中包含FMPR TLV，向其邻居发送其泛洪MPR集的信号。包含此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数据包中列出的邻居必须按以下顺序包含：
1. symmetric 1-hop neighbors that are selected as Flooding-MPRs;
1. 选择作为泛洪MPR的对称1跳邻居；
2. other symmetric 1-hop neighbors;
2. 其他对称1跳邻居；
3. other 1-hop neighbors.
3. 其他1-hop邻居。
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接口发送的Hello数据包必须向发送路由器的所有对称MANET邻居公布链路成本。如果发送路由器具有多个OSPFv3 MANET接口，则通过该路由器的所有OSPFv3 MANET接口到所有对称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.
路由器与其在OSPFv3 MANET接口上的每个MANET邻居（Hello数据包通过该接口发送）之间的链路的成本必须通过包括METRIC-MPR TLV来表示。公制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接口的路由器必须从N中的路由器中选择路径MPR集。路由器路径MPR集中的路由器是那些参与从N2中的路由器到该路由器的最短（相对于所使用的度量）路径的路由器。附录B中给出了路径MPR选择的启发式方法。
A router MUST signal its Path-MPR set to its neighbors by including a PMPR TLV in generated Hello packets.
路由器必须通过在生成的Hello数据包中包含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.
1. 对于生成Hello包的路由器的任何OSPFv3 MANET接口，都是相邻的并被选择为路径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. 生成Hello数据包的路由器的任何OSPFv3 MANET接口上的对称1跳邻居之前未包含在此PMPR TLV中。
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列表之后是从这些邻居到生成包含此PMPR TLV的Hello数据包的路由器的链路的成本列表，详见第5.2.4节。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]中规定的处理外，当接收到的Hello数据包指示OSPFv3 MANET接口i附近的变化时，必须更新N和N2。特别地，如果接收到的Hello分组信号表示N（或N2）中的元组将被删除，则立即执行删除，而不等待元组过期。请注意，N2不仅记录接收到的Hello中列出的2-hop邻居，还记录附加的PMPR TLV中列出的2-hop邻居。
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信息信号相对于一个或多个链路代价改变，则必须重新计算路径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.
接收到包含LLS信息的Hello数据包时，必须更新泛洪MPR选择器集和路径MPR选择器集，该信息包指示已选择路由器作为MPR的邻居列表中的更改。
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.
如果在路由器的OSPFv3 MANET接口上接收到来自非相邻邻居的带S位集的Hello，则路由器必须将该邻居的状态转换为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接口上的控制通信开销，具有一个或多个这样的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邻居形成完全邻接时，该邻居的状态不会超过双向（如[RFC2328]中所定义）。路由器可以在双向状态下向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:
当路由器从对称1跳邻居接收Hello数据包时，该邻居不再将该路由器列为相邻路由器（见第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选择器集合中，或者邻居或路由器本身是同步路由器，则ExStart。
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
o 指向路径MPR集中所有邻居的链接，以及
o links to all neighbors that are in the Path-MPR-selector set.
o 指向路径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.
具有一个或多个OSPFv3 MANET接口的路由器可以列出它们通过这些OSPFv3 MANET接口拥有的其他链路，代价是较大的LSA。
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.
根据[RFC5340]，原始LSA被淹没在该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:
根据[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.
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具有相同链路状态ID、LS类型和广告路由器值的LSA，并且如果接收到的LSA不是较新的（参见[RFC2328]第13.1节），则不得处理接收到的LSA，除非第5.4.2节所述的确认。
(2) Otherwise, the LSA MUST be attributed a scope according to its type, as specified in Section 3.5 of [RFC5340].
(2) 否则，LSA必须按照[RFC5340]第3.5节的规定，根据其类型归属于一个范围。
(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必须安装在链路状态数据库中。
2. The Age of the LSA MUST be increased by InfTransDelay.
2. LSA的年龄必须延迟增加。
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还必须通过作用域所涉及的所有OSPFv3 MANET接口重新传输，多播地址为all_SPF_路由器。
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应设置为适合动态拓扑的值：在OSPF网络的MANET部分中，LSA更新可能需要比在OSPF网络的其他部分中更频繁。
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，则路由器不得确认该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接口上向多播地址all_SPF_路由器发送该LSA的确认。
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接口上向多播地址all_SPF_路由器发送此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:
除了第5.2节、第5.3节和第5.4节中描述的操作外，混合路由器必须：
o select ALL their MANET neighbors as Path-MPRs.
o 选择其所有MANET邻居作为路径MPR。
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:
在没有混合路由器的网络中，必须至少选择一个同步路由器。同步路由器必须：
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.
o 与所有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.
o 具有MANET接口且ID高于其所有当前邻居的ID，且其ID高于其链路状态数据库中路由器LSA中当前存在的任何其他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.
其他试探法是可能的；然而，选择同步路由器的任何启发式方法必须确保网络中至少存在一个同步或混合路由器。
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邻居之间的链路（因为数据和协议数据包也可以通过这些链路发送、接收和处理）。因此，用于计算路由的连接矩阵必须反映根与其处于双向或更高状态的所有邻居之间的链路，以及链路状态数据库中描述的链路。
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数据包，详见本节。
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定义用于信令泛洪MPR选择，如图1所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=FMPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Willingness | # Sym. Neigh. | # Flood MPR | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
#符号。嘶嘶声是一个8位无符号整数字段，指定对称1跳邻居的数量。这些对称的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-是一个8位无符号整数字段，指定选定为泛洪MPR的邻居数。这些泛洪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.
METRIC-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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中公布的成本是直接的（即，从路由器到邻居的链路的成本），则清除（'0'）；如果公布的成本是反向的（即，从邻居到路由器的链路的成本），则设置（'1'）。默认情况下，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所示），则清除（'0'）；如果包括适用于所有链路的单个度量值（如图4所示），则设置（'1'）。
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.
Cost n-是一个8位无符号整数字段，指定从Hello数据包开始计数时，该路由器与Hello数据包第n位所列邻居之间的链路成本，该链路的方向由R标志指定，第一个邻居位于位置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.
填充-是一个16位字段，在传输时应清除（“0”），在接收时应忽略。填充是为了使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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:Metric Advertision TLV（Metric-MPR）示例，具有显式的单个链接成本（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=METRIC-MPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |1|R| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:Metric广告TLV（Metric-MPR）示例，具有单一且统一的链路成本（U=1）（因此，没有填充）。
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定义用于信令路径MPR选择，如图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=PMPR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Sym Neigh | # Adj. Neigh | # Path-MPR | Reserved |U|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost 0 | Cost 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
#赛姆·奈格是一个8位无符号整数字段，指定路由器所有OSPFv3 MANET接口的对称1跳MANET邻居的数量，列在PMPR TLV中。
# 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-是一个8位无符号整数字段，用于指定选择为路径MPR的MANET邻居的数量。这些路径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中的每个播发邻居到发送路由器的每个链路的成本被明确包括（如图6所示），则清除（'0'）；如果包括适用于所有链路的单个度量值（如图7所示），则设置（'1'）。
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选择器集中的邻居相邻，则清除（'0'）；如果路由器作为同步路由器与所有MANET邻居相邻，则清除（'1'），根据第5.6节。
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-是一个32位字段，指定路由器OSPFv3 MANET接口的对称1跳邻居的路由器ID。
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-是一个16位无符号整数字段，指定从PMPR TLV中列出的第n个播发邻居到该路由器方向的链路成本。除非通过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.
填充-是一个16位字段，在传输时应清除（“0”），在接收时应忽略。包括填充，以使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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:Path-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：路径MPR TLV（PMPR），具有单一且统一的链路成本（U=1）（因此包括填充）。
[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].
本文件定义了三种LLS TLV，其类型值已从[RFC4813]中定义的LLS TLV类型注册表中分配。
+------------+------------+--------------+
| Mnemonic | Type Value | Name |
+------------+------------+--------------+
| FMPR | 3 | Flooding-MPR |
| METRIC-MPR | 4 | Metric-MPR |
| PMPR | 5 | Path-MPR |
+------------+------------+--------------+
+------------+------------+--------------+
| 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链路本地信令”，RFC 48132007年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，“IPv6的OSPF”，RFC 53402008年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.，Vienno，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选择的分析”，第二届无线网络性能分析和增强国际研讨会，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鲁棒性]Adjih，C.，Baccelli，E.，Clausen，T.，和P.Jacquet，“关于连通支配集的鲁棒性和稳定性”，INRIA研究报告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拓扑]Baccelli，E.，Clausen，T.，和P.Jacquet，“移动自组织网络上基于MPR的无线OSPF解决方案中的部分拓扑”，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]Corson，S.和J.Macker，“移动自组网（MANET）：路由协议性能问题和评估考虑”，RFC25011999年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，“移动自组网（MANET）中的抖动考虑”，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的建议启发式。它构造一个泛洪MPR集，使路由器能够通过一个泛洪MPR路由器的中继到达2跳邻居中的路由器。
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）的成员），定义为路由器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）中的所有路由器计算D（Y），其中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. 将N（i）中的路由器添加到泛洪MPR集合中，这些路由器是唯一为N2（i）中的路由器提供可达性的路由器。例如，如果N2（i）中的路由器B只能通过N（i）中的路由器a到达，则将路由器a添加到泛洪MPR集合。从N2（i）中移除路由器，这些路由器现在由泛洪MPR集合中的路由器覆盖。
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）中存在至少一个路由器未覆盖泛洪MPR集合中的路由器时：
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跳邻居到达的路由器的数量；
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）中具有非零可达性的路由器中意愿最高的邻居作为泛洪MPR。如果具有相同意愿的路由器之间存在平局，则选择可到达N2（i）中最大数量路由器的路由器。如果路由器之间的另一个连接也提供相同数量的可达性，则选择D（Y）较大的路由器作为泛洪MPR。从N2（i）中移除路由器，这些路由器现在由泛洪MPR集合中的路由器覆盖。
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的意愿的增加顺序：如果在排除路由器Y时，在N2（i）中的所有路由器仍然被洪泛MPR集合中的至少一个路由器覆盖，则路由器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路由器覆盖。
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集的建议启发式算法，该算法使路由器能够通过其路径MPR集中的路由器通过最短路径到达2跳邻居中的路由器。以下术语将用于描述此启发式：
A - The router performing the Path-MPR set calculation.
A-执行路径MPR集计算的路由器。
B, C, D, .... - Other routers in the network.
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.
距离（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）（该链路的直接成本）被设置为以路由器B为对称1跳邻居的所有接口上的最小成本。此链路的反向成本cost（B，A）设置为从路由器B接收的Hello数据包中的值。如果路由器B可以通过多个接口同时到达，则cost（B，A）设置为路由器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. 关于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. 将邻居B连接到2跳邻居C的链路的代价矩阵的系数cost（B，C）通过从路由器B接收的Hello分组获得。在这种情况下，代价（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. 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.translate error, please retry
2. Compute N' as the subset of N made of the elements X such that cost(X,A)=dist(X,A).
2. 计算N'作为由元素X构成的N的子集，使得成本（X，A）=距离（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'计算为N的子集，N2由不属于N'的元素Y构成，并且N'中存在X，这样的成本（Y，X）+成本（X，A）=距离（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选择算法，用N'代替N（i），用N2'代替N2（i）。生成的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集，即，它必须选择一个路径MPR集，以便对于不在路径MPR集中的N或N2的任何元素，存在一条从该元素通过选择为路径MPR的邻居到路由器的最短路径（除非最短路径只有一个跃点）。
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、Padma Pillay Esnault和Laurent Vienno对本文件的贡献。
The authors would like to thank Juan Antonio Cordero Fuertes, Ulrich Herberg, and Richard Ogier for reviewing this document.
作者感谢胡安·安东尼奥·科尔德罗·富尔特斯、乌尔里希·赫伯格和理查德·奥吉尔对本文件的审阅。
Authors' Addresses
作者地址
Emmanuel Baccelli INRIA
伊曼纽尔杆菌
Phone: +33 1 69 33 55 11
EMail: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
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
Phone: +33 1 3963 5263
EMail: Philippe.Jacquet@inria.fr
Dang-Quan Nguyen CRC
党全阮华润
Phone: +1-613-949-8216
EMail: dang.nguyen@crc.ca
Phone: +1-613-949-8216
EMail: dang.nguyen@crc.ca
Thomas Heide Clausen LIX, Ecole Polytechnique
托马斯·海德·克劳森·利克斯，理工学院
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/