Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 6130 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
ISSN: 2070-1721 BAE Systems ATC
J. Dean
Naval Research Laboratory
April 2011
Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 6130 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
ISSN: 2070-1721 BAE Systems ATC
J. Dean
Naval Research Laboratory
April 2011
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
移动自组网（MANET）邻域发现协议（NHDP）
Abstract
摘要
This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
本文描述了一种用于移动自组织网络（MANET）的1跳和对称2跳邻域发现协议（NHDP）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6130.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6130.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。本协议某些部分的版权控制人
material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
材料可能未授予IETF信托允许在IETF标准过程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction .....................................................4
1.1. Motivation .................................................5
2. Terminology .....................................................6
3. Applicability Statement .........................................9
4. Protocol Overview and Functioning ..............................10
4.1. Routers and Interfaces ....................................11
4.2. Information Base Overview .................................12
4.2.1. Local Information Base .............................13
4.2.2. Interface Information Bases ........................13
4.2.3. Neighbor Information Base ..........................14
4.3. Signaling Overview ........................................14
4.3.1. HELLO Message Generation ...........................15
4.3.2. HELLO Message Content ..............................16
4.3.3. HELLO Message Processing ...........................17
4.4. Link Quality ..............................................17
5. Protocol Parameters and Constants ..............................18
5.1. Protocol and Port Numbers .................................18
5.2. Multicast Address .........................................18
5.3. Interface Parameters ......................................18
5.3.1. Message Intervals ..................................19
5.3.2. Information Validity Times .........................21
5.3.3. Link Quality .......................................22
5.3.4. Jitter .............................................22
5.4. Router Parameters .........................................23
5.4.1. Information Validity Time ..........................23
5.5. Parameter Change Constraints ..............................23
5.6. Constants .................................................24
6. Local Information Base .........................................24
6.1. Local Interface Set .......................................25
6.2. Removed Interface Address Set .............................26
7. Interface Information Bases ....................................26
7.1. Link Set ..................................................27
7.2. 2-Hop Set .................................................28
8. Neighbor Information Base ......................................28
8.1. Neighbor Set ..............................................28
8.2. Lost Neighbor Set .........................................29
9. Local Information Base Changes .................................29
1. Introduction .....................................................4
1.1. Motivation .................................................5
2. Terminology .....................................................6
3. Applicability Statement .........................................9
4. Protocol Overview and Functioning ..............................10
4.1. Routers and Interfaces ....................................11
4.2. Information Base Overview .................................12
4.2.1. Local Information Base .............................13
4.2.2. Interface Information Bases ........................13
4.2.3. Neighbor Information Base ..........................14
4.3. Signaling Overview ........................................14
4.3.1. HELLO Message Generation ...........................15
4.3.2. HELLO Message Content ..............................16
4.3.3. HELLO Message Processing ...........................17
4.4. Link Quality ..............................................17
5. Protocol Parameters and Constants ..............................18
5.1. Protocol and Port Numbers .................................18
5.2. Multicast Address .........................................18
5.3. Interface Parameters ......................................18
5.3.1. Message Intervals ..................................19
5.3.2. Information Validity Times .........................21
5.3.3. Link Quality .......................................22
5.3.4. Jitter .............................................22
5.4. Router Parameters .........................................23
5.4.1. Information Validity Time ..........................23
5.5. Parameter Change Constraints ..............................23
5.6. Constants .................................................24
6. Local Information Base .........................................24
6.1. Local Interface Set .......................................25
6.2. Removed Interface Address Set .............................26
7. Interface Information Bases ....................................26
7.1. Link Set ..................................................27
7.2. 2-Hop Set .................................................28
8. Neighbor Information Base ......................................28
8.1. Neighbor Set ..............................................28
8.2. Lost Neighbor Set .........................................29
9. Local Information Base Changes .................................29
9.1. Adding an Interface .......................................29
9.2. Removing an Interface .....................................30
9.3. Adding a Network Address to an Interface ..................30
9.4. Removing a Network Address from an Interface ..............31
10. Packets and Messages ..........................................32
10.1. HELLO Messages ...........................................32
10.1.1. Address Blocks ....................................33
11. HELLO Message Generation ......................................34
11.1. HELLO Message Specification ..............................35
11.2. HELLO Message Transmission ...............................37
11.2.1. HELLO Message Jitter ..............................37
12. HELLO Message Processing ......................................38
12.1. Invalid Message ..........................................38
12.2. Definitions ..............................................40
12.3. Updating the Neighbor Set ................................41
12.4. Updating the Lost Neighbor Set ...........................42
12.5. Updating the Link Sets ...................................42
12.6. Updating the 2-Hop Set ...................................44
13. Other Information Base Changes ................................45
13.1. Link Tuple Symmetric .....................................46
13.2. Link Tuple Not Symmetric .................................47
13.3. Link Tuple Heard Timeout .................................48
14. Link Quality ..................................................48
14.1. Deployment without Link Quality ..........................49
14.2. Basic Principles of Link Quality .........................49
14.3. When Link Quality Changes ................................50
14.4. Updating Link Quality ....................................51
15. Proposed Values for Parameters and Constants ..................51
15.1. Message Interval Interface Parameters ....................51
15.2. Information Validity Time Interface Parameters ...........51
15.3. Information Validity Time Router Parameters ..............52
15.4. Link Quality Interface Parameters ........................52
15.5. Jitter Interface Parameters ..............................52
15.6. Constants ................................................52
16. Usage with Other Protocols ....................................52
17. Security Considerations .......................................54
17.1. Invalid HELLO Messages ...................................56
17.2. Authentication, Integrity, and Confidentiality
Suggestions ..............................................57
18. IANA Considerations ...........................................57
18.1. Expert Review: Evaluation Guidelines .....................58
18.2. Message Types ............................................58
18.3. Message-Type-Specific TLV Type Registries ................58
18.4. Address Block TLV Types ..................................59
18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values ...........60
19. Contributors ..................................................61
20. Acknowledgments ...............................................61
21. References ....................................................62
9.1. Adding an Interface .......................................29
9.2. Removing an Interface .....................................30
9.3. Adding a Network Address to an Interface ..................30
9.4. Removing a Network Address from an Interface ..............31
10. Packets and Messages ..........................................32
10.1. HELLO Messages ...........................................32
10.1.1. Address Blocks ....................................33
11. HELLO Message Generation ......................................34
11.1. HELLO Message Specification ..............................35
11.2. HELLO Message Transmission ...............................37
11.2.1. HELLO Message Jitter ..............................37
12. HELLO Message Processing ......................................38
12.1. Invalid Message ..........................................38
12.2. Definitions ..............................................40
12.3. Updating the Neighbor Set ................................41
12.4. Updating the Lost Neighbor Set ...........................42
12.5. Updating the Link Sets ...................................42
12.6. Updating the 2-Hop Set ...................................44
13. Other Information Base Changes ................................45
13.1. Link Tuple Symmetric .....................................46
13.2. Link Tuple Not Symmetric .................................47
13.3. Link Tuple Heard Timeout .................................48
14. Link Quality ..................................................48
14.1. Deployment without Link Quality ..........................49
14.2. Basic Principles of Link Quality .........................49
14.3. When Link Quality Changes ................................50
14.4. Updating Link Quality ....................................51
15. Proposed Values for Parameters and Constants ..................51
15.1. Message Interval Interface Parameters ....................51
15.2. Information Validity Time Interface Parameters ...........51
15.3. Information Validity Time Router Parameters ..............52
15.4. Link Quality Interface Parameters ........................52
15.5. Jitter Interface Parameters ..............................52
15.6. Constants ................................................52
16. Usage with Other Protocols ....................................52
17. Security Considerations .......................................54
17.1. Invalid HELLO Messages ...................................56
17.2. Authentication, Integrity, and Confidentiality
Suggestions ..............................................57
18. IANA Considerations ...........................................57
18.1. Expert Review: Evaluation Guidelines .....................58
18.2. Message Types ............................................58
18.3. Message-Type-Specific TLV Type Registries ................58
18.4. Address Block TLV Types ..................................59
18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values ...........60
19. Contributors ..................................................61
20. Acknowledgments ...............................................61
21. References ....................................................62
21.1. Normative References .....................................62
21.2. Informative References ...................................62
Appendix A. Address Block TLV Combinations ........................63
Appendix B. Constraints ...........................................64
Appendix C. HELLO Message Example .................................66
Appendix D. Flow and Congestion Control ...........................69
Appendix E. Interval and Timer Illustrations ......................70
E.1. HELLO Message Generation Timing ..........................70
E.2. HELLO Message Processing Timing ..........................76
E.3. Other HELLO Message Timing ...............................77
Appendix F. Topology Pictures ....................................79
F.1. Example 1: Standard Single Interface Topology ............79
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor ....80
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor ....81
F.4. Example 4: Dual Addressed Interfaces .....................81
F.5. Example 5: Dual Interface on 2-Hop Neighbor ..............82
F.6. Example 6: Dual interface on 1-Hop Neighbor ..............82
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors ...83
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor ..84
F.9. Example 9: Dual Interface on All Routers .................85
F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers ......................................86
F.11. Example 11: Single Addressed Dual Interface Locally ......87
21.1. Normative References .....................................62
21.2. Informative References ...................................62
Appendix A. Address Block TLV Combinations ........................63
Appendix B. Constraints ...........................................64
Appendix C. HELLO Message Example .................................66
Appendix D. Flow and Congestion Control ...........................69
Appendix E. Interval and Timer Illustrations ......................70
E.1. HELLO Message Generation Timing ..........................70
E.2. HELLO Message Processing Timing ..........................76
E.3. Other HELLO Message Timing ...............................77
Appendix F. Topology Pictures ....................................79
F.1. Example 1: Standard Single Interface Topology ............79
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor ....80
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor ....81
F.4. Example 4: Dual Addressed Interfaces .....................81
F.5. Example 5: Dual Interface on 2-Hop Neighbor ..............82
F.6. Example 6: Dual interface on 1-Hop Neighbor ..............82
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors ...83
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor ..84
F.9. Example 9: Dual Interface on All Routers .................85
F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers ......................................86
F.11. Example 11: Single Addressed Dual Interface Locally ......87
This document describes a neighborhood discovery protocol (NHDP) for a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a local exchange of HELLO messages so that each router can determine the presence of, and connectivity to, its 1-hop and symmetric 2-hop neighbors. Messages are defined and sent in packets according to the specification [RFC5444].
本文档描述了用于移动自组织网络（MANET）[RFC2501]的邻域发现协议（NHDP）。该协议使用HELLO消息的本地交换，以便每个路由器可以确定其1-hop和对称2-hop邻居的存在和连接。消息根据规范[RFC5444]定义并以数据包的形式发送。
1-hop neighborhood information is recorded for use by MANET routing protocols to determine direct (1-hop) connectivity to neighboring routers. 2-hop symmetric neighborhood information is recorded so as to enable MANET routing protocols to employ flooding reduction techniques, e.g., to select reduced relay sets for efficient network-wide traffic dissemination.
记录1跳邻居信息，供MANET路由协议使用，以确定与相邻路由器的直接（1跳）连接。记录2跳对称邻域信息，以便使MANET路由协议能够采用洪泛减少技术，例如，选择减少的中继集以进行有效的网络范围流量传播。
1-hop and symmetric 2-hop neighborhood information is recorded in the form of Information Bases. These are available for use by other protocols, such as MANET routing protocols, that require information regarding the local network connectivity. This protocol is designed to maintain the information in these Information Bases even in the presence of a dynamic network topology and wireless communication channel characteristics.
1-hop和对称2-hop邻域信息以信息库的形式记录。这些协议可供其他协议（如MANET路由协议）使用，这些协议需要有关本地网络连接的信息。该协议旨在维护这些信息库中的信息，即使存在动态网络拓扑和无线通信信道特性。
This protocol makes no assumptions about the underlying link layer, other than support of local broadcast or multicast for communication to 1-hop neighbor routers. Link-layer information may be used if available and applicable.
该协议对底层链路层不作任何假设，只支持本地广播或多播与1跳邻居路由器通信。如果可用和适用，可以使用链路层信息。
This protocol is based on the neighborhood discovery process contained in the Optimized Link State Routing (OLSR) Protocol [RFC3626].
该协议基于优化链路状态路由（OLSR）协议[RFC3626]中包含的邻域发现过程。
MANETs differ from more traditional wired and infrastructure-based wireless networks due to their envisioned applicability over more challenging communication channels (e.g., wireless, lossy, broadcast channels with moderate and shared bandwidth, hidden and exposed terminals, and interference from other network devices and the environment) and in more challenging topological conditions (e.g., rapid and unpredictable mobility, dynamic and non-predetermined network membership).
移动自组网不同于传统的有线和基于基础设施的无线网络，因为其设想适用于更具挑战性的通信信道（例如，具有中等和共享带宽的无线、有损、广播信道、隐藏和暴露的终端以及来自其他网络设备和环境的干扰）以及在更具挑战性的拓扑条件下（例如，快速和不可预测的移动性、动态和非预定的网络成员资格）。
Due to the properties of wireless transmissions, communication between two neighboring routers may not be bi-directional; even if router A is able to receive packets from router B, the converse is not guaranteed to be true. Furthermore, because of the localized nature of wireless broadcast communication, neighboring routers within the same communications channel may have different sets of neighbors. That is, when using the same communication channel, even if router A is able to exchange packets with router B, and router B is able to exchange packets with router C, this does not guarantee that router A and router C can exchange packets directly.
由于无线传输的特性，两个相邻路由器之间的通信可能不是双向的；即使路由器A能够从路由器B接收数据包，也不能保证反之亦然。此外，由于无线广播通信的本地化性质，同一通信信道中的相邻路由器可能具有不同的邻居集。也就是说，当使用相同的通信信道时，即使路由器A能够与路由器B交换分组，并且路由器B能够与路由器C交换分组，这并不保证路由器A和路由器C能够直接交换分组。
Each router in a MANET may use more than one communication channel. In particular, between the same pair of routers, more than one distinct communication channel may exist, each with different properties. This may, for example, be the case where MANET routers are equipped with multiple distinct wireless interfaces, operating at different frequencies.
MANET中的每个路由器可以使用多个通信信道。特别地，在同一对路由器之间，可以存在多个不同的通信信道，每个信道具有不同的属性。例如，这可能是MANET路由器配备有以不同频率运行的多个不同无线接口的情况。
For use by MANET routing protocols, as well as for establishing a router's neighbors, a router may also need to determine whether each communication channel with that neighbor is bi-directional.
为了供MANET路由协议使用，以及为了建立路由器的邻居，路由器可能还需要确定与该邻居的每个通信信道是否是双向的。
The set of neighbor routers of a given MANET router may be continuously changing, often due to router mobility or a changing physical environment in which the MANET is located. There is typically no information from lower layers that would enable an IP routing protocol to detect and, as appropriate, react to such changes. Such changes can often take place on a short timescale,
给定MANET路由器的一组邻居路由器可能会不断变化，这通常是由于路由器移动性或MANET所在的物理环境的变化。通常不存在来自较低层的信息，这些信息将使IP路由协议能够检测并（视情况而定）响应此类更改。这种变化通常会在短时间内发生，
such as of the order of seconds, requiring MANET routing protocols to act rapidly to ensure suitable convergence properties.
例如秒级，要求MANET路由协议快速行动以确保合适的收敛特性。
MANET routing protocols, for example [RFC3626] and [RFC5449], often employ relay set reductions in order to conserve network capacity when maintaining network-wide topological information, with calculation of these reduced relay sets employing up to two hop information.
MANET路由协议，例如[RFC3626]和[RFC5449]，通常采用中继集缩减，以便在维护网络范围的拓扑信息时节省网络容量，这些缩减的中继集的计算最多采用两跳信息。
The neighborhood discovery protocol specified in this document provides continued tracking of neighborhood changes, link bi-directionality, and local topological information up to two hops. Combined, this allows a MANET routing protocol access to information describing link establishment/disappearance and provides the necessary topological information for reduced relay set selection and other purposes.
本文档中指定的邻域发现协议提供了对邻域变化、链路双向性和局部拓扑信息的持续跟踪（最多两跳）。结合起来，这允许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]中的说明进行解释。
All terms introduced in [RFC5444], including "packet", "message", "Address Block", "TLV Block", "TLV", "address", "address prefix", and "address object" are to be interpreted as described therein.
[RFC5444]中引入的所有术语，包括“数据包”、“消息”、“地址块”、“TLV块”、“TLV”、“地址”、“地址前缀”和“地址对象”，均应按照其中所述进行解释。
Additionally, this document uses the following terminology:
此外，本文件使用以下术语：
Network Address: An address plus an associated prefix length. This may be an address with an associated maximum prefix length or an address prefix including a prefix length. A network address thus represents a range of addresses.
网络地址：地址加上相关前缀长度。这可以是具有关联的最大前缀长度的地址，也可以是包括前缀长度的地址前缀。因此，网络地址代表一系列地址。
Router: A MANET router that implements this neighborhood discovery protocol.
路由器：一个MANET路由器，实现这个邻居发现协议。
Interface: A router's attachment to a communications medium. An interface is assigned one or more addresses.
接口：路由器与通信媒介的连接。接口被分配一个或多个地址。
MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces.
MANET接口：参与MANET并使用此邻居发现协议的接口。一个路由器可能有几个MANET接口。
Heard: A MANET interface of router X is considered heard on a MANET interface of a router Y if the latter can receive control messages, according to this specification, from the former.
Heard：根据本规范，如果路由器Y可以从前者接收控制消息，则认为路由器X的MANET接口在路由器Y的MANET接口上被听到。
Link: A link between two MANET interfaces exists if either can be heard by the other.
链路：如果两个MANET接口中的任何一个可以被另一个听到，则两个MANET接口之间存在链路。
Symmetric link: A symmetric link between two MANET interfaces exists if both can be heard by the other.
对称链路：如果两个MANET接口都能被对方听到，则两个MANET接口之间存在对称链路。
1-hop neighbor: A router X is a 1-hop neighbor of a router Y if a MANET interface of router X is heard by a MANET interface of router Y.
1跳邻居：如果路由器Y的MANET接口听到路由器X的MANET接口，则路由器X是路由器Y的1跳邻居。
Symmetric 1-hop neighbor: A router X is a symmetric 1-hop neighbor of a router Y if a symmetric link exists between a MANET interface on router X and a MANET interface on router Y.
对称1跳邻居：如果在路由器X上的MANET接口和路由器Y上的MANET接口之间存在对称链路，则路由器X是路由器Y的对称1跳邻居。
2-hop neighbor: A router X is a 2-hop neighbor of a router Y if router X is a 1-hop neighbor of a 1-hop neighbor of router Y, but is not router Y itself.
2-hop邻居：如果路由器X是路由器Y的1-hop邻居的1-hop邻居，但不是路由器Y本身，则路由器X是路由器Y的2-hop邻居。
Symmetric 2-hop neighbor: A router X is a symmetric 2-hop neighbor of a router Y if router X is a symmetric 1-hop neighbor of a symmetric 1-hop neighbor of router Y, but is not router Y itself.
对称2跳邻居：如果路由器X是路由器Y的对称1跳邻居的对称1跳邻居，但不是路由器Y本身，则路由器X是路由器Y的对称2跳邻居。
1-hop neighborhood: The 1-hop neighborhood of a router X is the set of the 1-hop neighbors of router X.
1-hop邻居：路由器X的1-hop邻居是路由器X的1-hop邻居的集合。
Symmetric 1-hop neighborhood: The symmetric 1-hop neighborhood of a router X is the set of the symmetric 1-hop neighbors of router X.
对称1跳邻居：路由器X的对称1跳邻居是路由器X的对称1跳邻居的集合。
2-hop neighborhood: The 2-hop neighborhood of a router X is the set of the 2-hop neighbors of router X. (This may include routers in the 1-hop neighborhood of router X.)
2-hop邻居：路由器X的2-hop邻居是路由器X的2-hop邻居的集合。（这可能包括路由器X的1-hop邻居中的路由器。）
Symmetric 2-hop neighborhood: The symmetric 2-hop neighborhood of a router X is the set of the symmetric 2-hop neighbors of router X. (This may include routers in the 1-hop neighborhood, or even in the symmetric 1-hop neighborhood, of router X.)
对称2-hop邻居：路由器X的对称2-hop邻居是路由器X的对称2-hop邻居的集合。（这可能包括路由器X的1-hop邻居，甚至对称1-hop邻居中的路由器。）
Constant: A numerical value that MUST be the same for all MANET interfaces of all routers in the MANET, at all times.
常量：MANET中所有路由器的所有MANET接口必须始终相同的数值。
Interface parameter: A boolean or numerical value, specified separately for each MANET interface of each router. A router MAY change interface parameter values at any time, subject to some constraints.
接口参数：布尔值或数值，分别为每个路由器的每个MANET接口指定。路由器可能随时更改接口参数值，但会受到一些限制。
Router parameter: A boolean or numerical value, specified for each router, and not specific to an interface. A router MAY change router parameter values at any time, subject to some constraints.
路由器参数：为每个路由器指定的布尔值或数值，不特定于接口。路由器可能会随时更改路由器参数值，但会受到一些限制。
Information Base: A collection of information maintained by this protocol and which is to be made available to MANET routing protocols. An Information Base may be associated with a MANET interface or with a router.
信息库：由该协议维护的信息集合，可供MANET路由协议使用。信息库可以与MANET接口或路由器相关联。
Furthermore, this document uses the following notational conventions:
此外，本文件使用以下符号约定：
X contains y, or y is contained in X An unordered list membership operator. X is an unordered list and y is an element. "X contains y" or "y is contained in X" returns true if the unordered list X includes the element y, and returns false otherwise.
X包含y，或者y包含在X中—一个无序列表成员资格运算符。X是无序列表，y是元素。如果无序列表X包含元素y，“X包含y”或“y包含在X中”，则返回true，否则返回false。
X contains Y, or Y is contained in X An unordered list inclusion operator. X and Y are both unordered lists. "X contains Y" or "Y is contained in X" returns true if the unordered list X contains all elements y which are contained in Y, and returns false otherwise.
X包含Y，或者Y包含在X中—一个无序列表包含运算符。X和Y都是无序列表。如果无序列表X包含Y中包含的所有元素Y，“X包含Y”或“Y包含在X中”返回true，否则返回false。
A overlaps B If A and B are network addresses, and the range of addresses represented by A and the range of addresses represented by B both contain at least one common address. (This is only possible if one range is a sub-range of the other.)
如果A和B是网络地址，则A与B重叠，并且由A表示的地址范围和由B表示的地址范围都包含至少一个公共地址。（只有当一个范围是另一个范围的子范围时，才可能这样做。）
a := b An assignment operator, whereby the left side (a) is assigned the value of the right side (b). a and b may be values, network addresses, or unordered lists (they must be of the same type).
a:=b赋值运算符，其中左侧（a）被赋值为右侧（b）的值。a和b可以是值、网络地址或无序列表（它们必须是相同的类型）。
c = d A comparison operator, returning true if the value of the left side (c) is equal to the value of the right side (d). c and d may be values, network addresses, or unordered lists (they must be of the same type). If c and d are unordered lists, then they are considered to be equal if c contains d and d contains c (i.e., they contain the same set of elements, regardless of the order in which they are recorded in the lists). If c and d are network addresses, they are considered equal only if both addresses and prefix lengths are equal (i.e., they represent the same).
c=d比较运算符，如果左侧（c）的值等于右侧（d）的值，则返回true。c和d可以是值、网络地址或无序列表（它们必须是相同的类型）。如果c和d是无序列表，那么如果c包含d和d包含c，则认为它们相等（即，它们包含相同的元素集，而不管它们在列表中的记录顺序如何）。如果c和d是网络地址，则只有当地址和前缀长度相等（即，它们表示相同）时，才认为它们相等。
e != f A comparison operator, returning not (e = f), i.e., returning true where (e = f) would have returned false, and returning false where (e = f) would have returned true.
e！=f一个比较运算符，返回not（e=f），即返回true，其中（e=f）将返回false，返回false，其中（e=f）将返回true。
This protocol:
本议定书：
o Is applicable to networks, especially wireless networks, in which unknown neighbors can be reached by local broadcast or multicast packets.
o 适用于通过本地广播或多播数据包可以到达未知邻居的网络，尤其是无线网络。
o Is designed to work in networks with a dynamic topology, and in which messages may be lost, such as due to collisions in wireless networks.
o 设计用于具有动态拓扑的网络中，并且在该网络中消息可能会丢失，例如由于无线网络中的冲突。
o Supports routers that each have one or more participating MANET interfaces. The set of a router's interfaces may change over time. Each interface may have one or more associated network addresses, and these may also be dynamically changing.
o 支持每个路由器都有一个或多个参与MANET接口的路由器。路由器的接口集可能会随着时间的推移而改变。每个接口可能有一个或多个关联的网络地址，并且这些地址也可能动态变化。
o Provides each router with current local topology information up to two hops away, and makes this local topology information available to MANET routing protocols in Information Bases.
o 为每个路由器提供最远两跳的当前本地拓扑信息，并使这些本地拓扑信息可用于信息库中的MANET路由协议。
o Uses the packet and message formats specified in [RFC5444]. This includes the definition of a HELLO Message Type, used for signaling local topology information.
o 使用[RFC5444]中指定的数据包和消息格式。这包括HELLO消息类型的定义，用于发送本地拓扑信息。
o Allows "external" and "internal" extensibility as enabled by [RFC5444].
o 允许[RFC5444]启用的“外部”和“内部”扩展性。
o May interact with, and be extended by, other protocols, such as MANET routing protocols, see Section 16.
o 可与其他协议（如MANET路由协议）交互，并可由其扩展，见第16节。
o Can use relevant link-layer information if it is available.
o 可以使用相关的链接层信息（如果可用）。
o Is designed to work in a completely distributed manner, and does not depend on any central entity.
o 设计为以完全分布式的方式工作，不依赖于任何中心实体。
The objective of this protocol is, for each router:
本协议的目标是，对于每个路由器：
o To identify 1-hop neighbors and symmetric 1-hop neighbors of this router.
o 识别此路由器的1跳邻居和对称1跳邻居。
o To find the interface network addresses of the router's symmetric 2-hop neighbors.
o 查找路由器对称2跳邻居的接口网络地址。
o To record this information in Information Bases and thus make this information available to other protocols that use this neighborhood discovery protocol.
o 在信息库中记录此信息，从而使此信息可供使用此邻居发现协议的其他协议使用。
o To be available for use by other protocols, which MAY extend the information in these Information Bases, including adding new Sets to Information Bases, new elements to protocol Tuples and new TLVs to be included in outgoing HELLO messages and processed when in incoming HELLO messages.
o 可供其他协议使用，这些协议可扩展这些信息库中的信息，包括向信息库添加新集合、向协议元组添加新元素以及在传出HELLO消息中包含并在传入HELLO消息中处理的新TLV。
These objectives are achieved using local (1-hop) signaling that:
这些目标是通过使用本地（1跳）信令实现的，该信令：
o Advertises the presence of a router and its interface network addresses.
o 通告路由器及其接口网络地址的存在。
o Discovers links from neighboring routers.
o 发现来自相邻路由器的链接。
o Performs bi-directionality checks on the discovered links.
o 对发现的链接执行双向性检查。
o Advertises discovered links, and whether each is symmetric, to its 1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
o 向其1-hop邻居播发发现的链接以及每个链接是否对称，从而发现对称的2-hop邻居。
This specification defines, in turn:
本规范反过来定义了：
o Parameters and constants used by the protocol. Parameters used by this protocol may, where appropriate, be specific to a given MANET interface or to a MANET router. This protocol allows all parameters to be changed dynamically, and to be set independently for each MANET router or MANET interface, as appropriate.
o 协议使用的参数和常量。在适当的情况下，该协议使用的参数可能特定于给定的MANET接口或MANET路由器。该协议允许动态更改所有参数，并根据需要为每个MANET路由器或MANET接口独立设置。
o The Information Bases describing local interfaces, discovered links and their status, current and former 1-hop neighbors, and symmetric 2-hop neighbors.
o 描述本地接口、发现的链路及其状态、当前和以前的1跳邻居以及对称2跳邻居的信息库。
o The format of the HELLO message that is used for local signaling.
o 用于本地信令的HELLO消息的格式。
o The generation of HELLO messages from some of the information in the Information Bases.
o 从信息库中的某些信息生成HELLO消息。
o The updating of the Information Bases according to received HELLO messages and other events.
o 根据收到的HELLO消息和其他事件更新信息库。
o The response to other events, such as the expiration of information in the Information Bases.
o 对其他事件的响应，例如信息库中的信息过期。
In order for a router to participate in a MANET, it MUST have at least one, and possibly more, MANET interfaces.
为了让路由器参与到MANET中，它必须至少有一个，甚至更多的MANET接口。
Each MANET interface:
每个MANET接口：
o Is configured with one or more network addresses. Each address in the range of addresses represented by that network address MUST satisfy the following properties:
o 配置了一个或多个网络地址。由该网络地址表示的地址范围内的每个地址必须满足以下属性：
o It MUST be unique to this router, i.e., it MUST NOT be assigned to any interface of any other router.
o 它必须是该路由器独有的，即不得分配给任何其他路由器的任何接口。
o If assigned to other MANET interfaces, on the same router, these MANET interfaces MUST be isolated, i.e., addresses may only be assigned to different interfaces on the same router if no MANET interface on another router can communicate with both. For example, interfaces using distinct radio "channels" MAY be assigned the same address.
o 如果分配给同一路由器上的其他MANET接口，则这些MANET接口必须隔离，即，如果另一路由器上的MANET接口不能与这两个接口通信，则只能将地址分配给同一路由器上的不同接口。例如，使用不同无线电“信道”的接口可以被分配相同的地址。
o Has a set of interface parameters, defining the behavior of this MANET interface. Each MANET interface MAY be individually parameterized.
o 具有一组接口参数，定义此MANET接口的行为。每个MANET接口可以单独参数化。
o Has an Interface Information Base, recording information regarding links to this MANET interface and symmetric 2-hop neighbors that can be reached through such links.
o 有一个接口信息库，记录有关到这个MANET接口的链接以及可以通过这种链接到达的对称2跳邻居的信息。
o Generates and processes HELLO messages.
o 生成和处理HELLO消息。
In addition to a set of MANET interfaces as described above, each router has:
除了如上所述的一组MANET接口外，每个路由器还具有：
o A Local Information Base, containing the network addresses of the interfaces (MANET and non-MANET) of this router. The contents of this Information Base are not changed by signaling.
o 本地信息库，包含该路由器接口（MANET和非MANET）的网络地址。此信息库的内容不会因信令而改变。
o A Neighbor Information Base, recording information regarding current and recently lost 1-hop neighbors of this router.
o 邻居信息库，记录有关此路由器当前和最近丢失的1跳邻居的信息。
A router may have both MANET interfaces and non-MANET interfaces. Interfaces of both of these types are recorded in a router's Local Information Base, which is used, but not updated, by the signaling of this protocol.
路由器可以同时具有MANET接口和非MANET接口。这两种类型的接口都记录在路由器的本地信息库中，该信息库由该协议的信令使用，但不更新。
Each router maintains protocol state using Information Bases, described in the following sections. Each Information Base consists of a number of Protocol Sets. Each Protocol Set contains a number of Protocol Tuples.
每个路由器都使用信息库维护协议状态，如下部分所述。每个信息库由多个协议集组成。每个协议集包含多个协议元组。
An implementation of this protocol MAY maintain this information in the indicated form, or in any other organization that offers access to this information. In particular, note that it is not necessary to remove Protocol Tuples from Protocol Sets at the exact time indicated, only to behave as if the Protocol Tuples were removed at that time.
本协议的实施可以以指定的形式维护该信息，或在提供访问该信息的任何其他组织中维护该信息。特别是，请注意，不必在指定的确切时间从协议集中删除协议元组，只需表现为协议元组在该时间被删除。
Information in the Local Information Base is defined locally and included in HELLO messages. Information in the Interface Information Base and the Neighbor Information Base is determined from received HELLO messages; some of this information may also be included in transmitted HELLO messages. Such information has a limited duration in which it is considered valid. This duration is determined from the VALIDITY_TIME TLV in the HELLO message in which the information is received, which in turn is set by the router that originated the HELLO message, using its corresponding interface parameter H_HOLD_TIME.
本地信息库中的信息在本地定义并包含在HELLO消息中。根据接收到的HELLO消息确定接口信息库和邻居信息库中的信息；其中一些信息也可能包含在传输的HELLO消息中。此类信息的有效期有限。该持续时间由接收信息的HELLO消息中的VALIDITY_TIME TLV确定，该TLV由发起HELLO消息的路由器使用其相应的接口参数H_HOLD_TIME设置。
Appendix E illustrates the relationship between message reception, included VALIDITY_TIME TLVs, and the duration for which information received in a HELLO message is considered valid. Appendix F illustrates some example topologies and how they correspond to information in the Information Bases.
附录E说明了消息接收（包括有效性时间TLV）与HELLO消息中接收的信息被视为有效的持续时间之间的关系。附录F说明了一些示例拓扑以及它们如何与信息库中的信息相对应。
Each router maintains a Local Information Base, which contains the router's local configuration information, specifically:
每个路由器维护一个本地信息库，其中包含路由器的本地配置信息，特别是：
o The Local Interface Set, which consists of Local Interface Tuples, each of which represents an interface (MANET or non-MANET) of the router.
o 本地接口集，由本地接口元组组成，每个元组表示路由器的一个接口（MANET或非MANET）。
o The Removed Interface Address Set, which consists of Removed Interface Address Tuples, each of which records a recently used network address of an interface (MANET or non-MANET) of the router.
o 删除的接口地址集，由删除的接口地址元组组成，每个元组记录路由器接口（MANET或非MANET）最近使用的网络地址。
The Local Interface Set is used for generating HELLO messages, specifically for determining which interface network addresses are to be included and identified as local interfaces. The Removed Interface Address Set is used to avoid incorrectly recording a formerly used network address as a symmetric 2-hop neighbor's network address.
本地接口集用于生成HELLO消息，特别是用于确定哪些接口网络地址将被包括并标识为本地接口。删除的接口地址集用于避免将以前使用的网络地址错误地记录为对称2跳邻居的网络地址。
The Local Information Base is used for generating signaling, but is not itself updated by signaling specified in this document. Updates to the Local Information Base are due to changes of the router configuration, and may be allowed to trigger signaling.
本地信息库用于生成信令，但其本身不会通过本文件中规定的信令进行更新。本地信息库的更新是由于路由器配置的改变，并且可能被允许触发信令。
Each router maintains, for each of its MANET interfaces, an Interface Information Base, which contains 1-hop neighborhood and symmetric 2-hop neighborhood information collected from this MANET interface, specifically:
每个路由器为其每个MANET接口维护一个接口信息库，其中包含从该MANET接口收集的1跳邻域和对称2跳邻域信息，具体而言：
o A Link Set, which records information about current and recently lost links between this MANET interface and MANET interfaces of 1-hop neighbors. The Link Set consists of Link Tuples, each of which contains information about a single link. Link quality information (see Section 14), when used, is recorded in Link Tuples.
o 一个链路集，记录有关此MANET接口和1跳邻居的MANET接口之间当前和最近丢失的链路的信息。链接集由链接元组组成，每个元组包含关于单个链接的信息。链接质量信息（见第14节）在使用时记录在链接元组中。
o A 2-Hop Set, which records the existence of symmetric links between symmetric 1-hop neighbors of this MANET interface and other routers (symmetric 2-hop neighbors). The 2-Hop Set consists of 2-Hop Tuples, each of which records a network address of a symmetric 2-hop neighbor, and all network addresses of the corresponding symmetric 1-hop neighbor.
o 一个2跳集，记录此MANET接口的对称1跳邻居和其他路由器（对称2跳邻居）之间存在的对称链路。2-Hop集合由2-Hop元组组成，每个元组记录对称2-Hop邻居的网络地址，以及相应对称1-Hop邻居的所有网络地址。
The Link Set for a MANET interface is used for generating HELLO messages. Specifically, the Link Set information is included to both allow other routers to identify symmetric links and to populate the 2-Hop Set. Recently lost links are recorded in the Link Set for a MANET interface so that they can be advertised in HELLO messages, accelerating their removal from relevant 1-hop neighbors' Link Sets.
MANET接口的链接集用于生成HELLO消息。具体而言，包括链路集信息以允许其他路由器识别对称链路并填充2跳集。最近丢失的链接记录在MANET接口的链接集中，以便在HELLO消息中公布它们，从而加快从相关1-hop邻居的链接集中删除它们的速度。
The Link Set for a MANET interface is itself updated on receiving a HELLO message, including recording symmetric links as indicated above. The 2-Hop Set for a MANET interface is updated as indicated above, and is not itself used in generating HELLO messages.
MANET接口的链路集本身在接收到HELLO消息时更新，包括如上所述记录对称链路。MANET接口的2-Hop集如上所述进行了更新，其本身并不用于生成HELLO消息。
Each router maintains a Neighbor Information Base, which contains collected information about current and recently lost 1-hop neighbors, specifically:
每个路由器维护一个邻居信息库，其中包含有关当前和最近丢失的1跳邻居的收集信息，特别是：
o The Neighbor Set consists of Neighbor Tuples, each of which records all network addresses of a single 1-hop neighbor. Neighbor Tuples are maintained as long as there are corresponding Link Tuples.
o 邻居集由邻居元组组成，每个元组记录单个1跳邻居的所有网络地址。只要存在相应的链接元组，就会维护相邻元组。
o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of which records a network address of a recently lost symmetric 1-hop neighbor.
o 丢失邻居集由丢失邻居元组组成，每个元组记录最近丢失的对称1跳邻居的网络地址。
The Neighbor Set associates all network addresses of each 1-hop neighbor. These network addresses may be included when generating a HELLO message, so that other symmetric 1-hop neighbors can record this information in a 2-Hop Set. The Neighbor Set can be updated on receiving a HELLO message.
邻居集关联每个1跳邻居的所有网络地址。在生成HELLO消息时，可以包括这些网络地址，以便其他对称1-hop邻居可以在2-hop集中记录此信息。可以在收到HELLO消息时更新邻居集。
The Lost Neighbor Set is used to determine which network addresses are to be included in a HELLO message as being lost (of a recently symmetric 1-hop neighbor). The Lost Neighbor Set can itself be updated on receiving a HELLO message.
丢失的邻居集用于确定（最近对称的1跳邻居）丢失的HELLO消息中要包括哪些网络地址。丢失的邻居集本身可以在收到HELLO消息时更新。
This protocol contains a signaling mechanism for maintaining the Interface Information Bases and the Neighbor Information Base. If information from the link layer, or any other source, is available and appropriate, it may also be used to update these Information Bases. Such updates are subject to the constraints specified in Appendix B.
该协议包含用于维护接口信息库和邻居信息库的信令机制。如果来自链接层或任何其他来源的信息可用且适当，则也可用于更新这些信息库。此类更新受附录B中规定的约束。
Signaling consists of a single type of message, known as a HELLO message. Each router generates HELLO messages on each of its MANET interfaces. HELLO messages are generated independently on each MANET interface of a MANET router; the content of a given HELLO message depends on the MANET interface for which it has been generated.
信令由单一类型的消息组成，称为HELLO消息。每个路由器在其每个MANET接口上生成HELLO消息。HELLO消息在MANET路由器的每个MANET接口上独立生成；给定HELLO消息的内容取决于生成该消息的MANET接口。
Each HELLO message:
每条问候信息：
o Identifies, as far as is required, the MANET interface for which it is generated and transmitted; this allows recipients of that HELLO message to identify that MANET interface from among those it may hear.
o 根据需要，识别生成和传输MANET接口的MANET接口；这允许HELLO消息的接收者从可能听到的消息中识别MANET接口。
o Reports the network addresses of other interfaces (MANET and non-MANET) of the router; this allows recipients of that HELLO message to associate a set of network addresses with a single 1-hop neighbor.
o 报告路由器其他接口（MANET和非MANET）的网络地址；这允许该HELLO消息的收件人将一组网络地址与单个1跳邻居关联。
o Includes 1-hop neighbor information from the Information Bases; this allows detection of local symmetric links, and symmetric 2-hop neighbors.
o 包括来自信息库的1跳邻居信息；这允许检测本地对称链路和对称2跳邻居。
HELLO message generation, and the validity of the information recorded as a consequence of processing a HELLO message, is affected by timers and validity information included in HELLO messages through TLVs. The relationship between message timers and intervals is illustrated in Appendix E.
HELLO消息的生成以及作为处理HELLO消息的结果而记录的信息的有效性受计时器和通过TLV包含在HELLO消息中的有效性信息的影响。消息计时器和间隔之间的关系如附录E所示。
HELLO messages are generated by a router for each of its MANET interfaces, and MAY be sent:
HELLO消息由路由器为其每个MANET接口生成，可通过以下方式发送：
o Proactively, at a regular interval, known as HELLO_INTERVAL. HELLO_INTERVAL may be fixed, or may be dynamic. For example, HELLO_INTERVAL may be backed off due to congestion or network stability.
o 主动地，以固定的间隔，称为HELLO_间隔。HELLO_间隔可以是固定的，也可以是动态的。例如，由于拥塞或网络稳定性，HELLO_间隔可能会被取消。
o As a response to a change in the router itself, or its 1-hop neighborhood, for example, on first becoming active or in response to a new, lost, or changed status link.
o 作为对路由器本身或其1-hop邻居更改的响应，例如，在第一次变为活动状态时，或响应新的、丢失的或更改的状态链接时。
o In a combination of these proactive and responsive mechanisms.
o 在这些主动和响应机制的组合中。
Jittering of HELLO message generation and transmission SHOULD be used as described in Section 11.2, unless the medium access control mechanism in use prevents any simultaneous transmissions by potentially interfering routers.
应按照第11.2节所述使用HELLO消息生成和传输的抖动，除非使用的介质访问控制机制阻止潜在干扰路由器的任何同步传输。
HELLO messages MAY be scheduled independently for each MANET interface, or, interface parameters permitting, using the same schedule for all MANET interfaces of a router.
HELLO消息可以为每个MANET接口单独调度，或者，在接口参数允许的情况下，为路由器的所有MANET接口使用相同的调度。
The content of a HELLO message MUST satisfy the following:
HELLO消息的内容必须满足以下要求：
o A HELLO message MUST contain all of the network addresses in the Local Interface Set of the router on which the HELLO message is being generated. This includes:
o HELLO消息必须包含生成HELLO消息的路由器本地接口集中的所有网络地址。这包括：
o At least one network address of each MANET interface of the router.
o 路由器的每个MANET接口的至少一个网络地址。
o Network addresses that include all source addresses of any IP datagrams sent by the router on any MANET interface.
o 网络地址，包括路由器在任何MANET接口上发送的任何IP数据报的所有源地址。
o All other network addresses of the router that are to be made known to any other router for any reason.
o 任何其他路由器因任何原因而知道的路由器的所有其他网络地址。
o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base. Note that when determining whether to include information in a HELLO message, the sender MUST consider all times up to the latest time when it may send its next HELLO message on this MANET interface.
o 对于每个MANET接口，在等于相应刷新间隔的每个时间间隔内，发送的HELLO消息必须共同包括相应链路集和邻居信息库中的所有相关信息。注意，当确定是否在hello消息中包含信息时，发送者必须考虑到在该MANET接口上发送下一个hello消息时的最新时间。
o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base.
o 对于每个MANET接口，在等于相应刷新间隔的每个时间间隔内，发送的HELLO消息必须共同包括相应链路集和邻居信息库中的所有相关信息。
o When determining whether to include a given piece of neighbor information in a HELLO message, it is not sufficient to consider whether that information has been sent in the interval of length REFRESH_INTERVAL up to the current time. Instead, the router MUST consider the interval of length REFRESH_INTERVAL that will end at the latest possible time at which the next HELLO message will be sent on this MANET interface. (Normally, this will be HELLO_INTERVAL past the current time, but MAY be earlier if this router elects to divide its neighbor information among more than one HELLO message in order to reduce the size of its HELLO messages.) All neighbor information MUST be sent in this interval, i.e., the router MUST ensure that this HELLO message includes all neighbor information that has not already been included in any HELLO messages sent since the start of this
o 当确定是否在Hello消息中包含给定的邻居信息时，不考虑是否已经在长度刷新间隔中发送到当前时间的信息。相反，路由器必须考虑长度刷新间隔的间隔，该间隔将在最新可能的时间结束，在下一个Hello消息将在该MANET接口上发送。（通常，这将是超过当前时间的HELLO_间隔，但如果此路由器选择将其邻居信息划分为多条HELLO消息以减小其HELLO消息的大小，则可能更早。）所有邻居信息必须在此间隔内发送，即。，路由器必须确保此HELLO消息包含自本次事件开始以来发送的任何HELLO消息中尚未包含的所有邻居信息
interval (normally, the current time - (REFRESH_INTERVAL - HELLO_INTERVAL)).
间隔（通常为当前时间-（刷新间隔-你好间隔））。
o A HELLO message MUST include exactly one VALIDITY_TIME Message TLV, as specified in [RFC5497], that indicates the length of time for which the message content is to be considered valid, and is therefore to be included in the receiving router's Interface Information Base.
o HELLO消息必须包含[RFC5497]中规定的一条有效时间消息TLV，该消息指示消息内容被视为有效的时间长度，因此将包含在接收路由器的接口信息库中。
o A periodically generated HELLO message SHOULD include exactly one INTERVAL_TIME Message TLV, as specified in [RFC5497], that indicates the current value of HELLO_INTERVAL for that MANET interface, i.e., the period within which a further HELLO message is guaranteed to be sent on that MANET interface.
o 按照[RFC5497]中的规定，周期性生成的HELLO消息应恰好包括一个INTERVAL_TIME消息TLV，该消息指示该MANET接口的HELLO_INTERVAL的当前值，即保证在该MANET接口上发送进一步HELLO消息的时间段。
HELLO messages received by a router are used to update the Interface Information Base for the MANET interface over which that HELLO message was received, as well as the Neighbor Information Base of the router. Specifically:
路由器接收的HELLO消息用于更新接收HELLO消息的MANET接口的接口信息库以及路由器的邻居信息库。明确地：
o The router ensures that there is a single Neighbor Tuple corresponding to the originator of that HELLO message.
o 路由器确保有一个与HELLO消息的发起者对应的邻居元组。
o The router ensures that there is a Link Tuple, with appropriate status (heard or symmetric) and advertised duration, corresponding to the link between the MANET interfaces on which that HELLO message was sent and received. One or more Lost Neighbor Tuples may be created if the HELLO message reports that the link was lost.
o 路由器确保有一个链路元组，具有适当的状态（听到或对称）和播发持续时间，对应于发送和接收HELLO消息的MANET接口之间的链路。如果HELLO消息报告链接丢失，则可能会创建一个或多个丢失的邻居元组。
o If the link between the MANET interfaces on which the HELLO message was sent and received is symmetric, then the router ensures that there are the appropriate 2-Hop Tuples, with advertised duration.
o 如果发送和接收HELLO消息的MANET接口之间的链路是对称的，则路由器确保存在适当的2跳元组，并具有广告的持续时间。
The processing defined in this specification handles any unexpected and erroneous information in a HELLO message, maintaining the constraints on Information Base contents specified in Appendix B.
本规范中定义的处理处理处理HELLO消息中的任何意外和错误信息，保持附录B中规定的信息库内容约束。
Some links in a MANET may be marginal, e.g., due to adverse wireless propagation. In order to avoid using such marginal links, a link quality value is recorded in each Link Tuple. A MANET router considers links for which an insufficient link quality is recorded as lost. Modifying the recorded link quality in a Link Tuple is
MANET中的一些链路可能是边缘链路，例如，由于不利的无线传播。为了避免使用这种边缘链接，在每个链接元组中记录一个链接质量值。MANET路由器将链路质量不足的链路视为丢失。修改链接元组中记录的链接质量是非常困难的
OPTIONAL. If link quality is not to be modified, it MUST be set to indicate an always usable quality link.
可选择的如果不修改链接质量，则必须将其设置为指示始终可用的质量链接。
Note that link quality is a "link admittance" mechanism, allowing a router to determine that a given link is too unstable to even consider for use. It is specifically not a link metric nor is it a substitute for one.
注意链路质量是一种“链路导纳”机制，允许路由器确定给定链路太不稳定，甚至不能考虑使用。它不是一个链接指标，也不是一个链接指标的替代品。
Link quality information is only used locally and is not used in signaling. Routers may interoperate whether they are using the same, different, or no link quality information. Link quality information is thus not equivalent to a link metric.
链路质量信息仅在本地使用，不用于信令。路由器可以互操作，无论它们使用相同、不同或没有链路质量信息。因此，链路质量信息并不等同于链路度量。
Link quality information is defined in this specification as a normalized, dimensionless value in the interval zero to one, inclusive, where the greater the value, the better the link quality. See Section 14 for further details.
链路质量信息在本规范中定义为0到1（包括0到1）区间内的标准化无量纲值，其中值越大，链路质量越好。详见第14节。
The parameters and constants used in this specification are described in this section.
本节介绍了本规范中使用的参数和常数。
This protocol specifies HELLO messages, which are included in packets as defined by [RFC5444]. These packets may be sent using either the "manet" protocol number or the "manet" well-known UDP port number, as specified in [RFC5498].
此协议指定HELLO消息，这些消息包含在[RFC5444]定义的数据包中。可以使用[RFC5498]中规定的“manet”协议号或“manet”众所周知的UDP端口号发送这些数据包。
This protocol specifies HELLO messages, which are included in packets as defined by [RFC5444]. These packets may be locally transmitted using the link-local multicast address "LL-MANET-Routers", as specified in [RFC5498].
此协议指定HELLO消息，这些消息包含在[RFC5444]定义的数据包中。这些包可以使用[RFC5498]中规定的链路本地多播地址“LL MANET路由器”本地传输。
The interface parameters used by this specification may be classified into the following four categories:
本规范使用的接口参数可分为以下四类：
o Message intervals
o 消息间隔
o Information validity times
o 信息有效期
o Link quality
o 链接质量
o Jitter
o 抖动
These are detailed in the following sections.
这些将在以下章节中详细介绍。
Different MANET interfaces (on the same or on different routers) MAY employ different interface parameter values and MAY change their interface parameter values dynamically, subject to the constraints given in this section. A particular case is where all MANET interfaces on all MANET routers within a given MANET employ the same set of interface parameter values.
不同的MANET接口（在相同或不同的路由器上）可能采用不同的接口参数值，并可能根据本节给出的约束动态更改其接口参数值。一种特殊情况是，给定MANET内所有MANET路由器上的所有MANET接口使用相同的接口参数值集。
HELLO messages serve two principal functions:
HELLO消息有两个主要功能：
o To advertise network addresses of this router's interface to its 1-hop neighbors. The frequency of these advertisements is regulated by the interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.
o 向其1跳邻居公布此路由器接口的网络地址。这些广告的频率由接口参数HELLO_INTERVAL和HELLO_MIN_INTERVAL调节。
o To advertise this router's knowledge of each of its 1-hop neighbors. The frequency of the advertisement of each such neighbor is regulated by the interface parameter REFRESH_INTERVAL.
o 宣传此路由器对其每个1跳邻居的了解。每个这样的邻居的广告频率由接口参数REFRESH_INTERVAL调节。
Specifically, these parameters are as follows:
具体而言，这些参数如下：
HELLO_INTERVAL: The maximum time between the transmission of two successive HELLO messages on this MANET interface. If using periodic transmission of HELLO messages, these SHOULD be at a separation of HELLO_INTERVAL, possibly modified by jitter as specified in [RFC5148].
HELLO_INTERVAL：在这个MANET接口上传输两个连续HELLO消息之间的最长时间。如果使用HELLO消息的周期性传输，则这些消息应以HELLO_间隔的间隔发送，可能会按照[RFC5148]中的规定通过抖动进行修改。
HELLO_MIN_INTERVAL: The minimum interval between transmission of two successive HELLO messages on this MANET interface. (This minimum interval MAY be modified by jitter, as defined in [RFC5148].)
HELLO_MIN_INTERVAL：在这个MANET接口上传输两个连续HELLO消息之间的最小间隔。（该最小间隔可根据[RFC5148]中定义的抖动进行修改。）
REFRESH_INTERVAL: The maximum interval between advertisements, in a HELLO message on this MANET interface, of each 1-hop neighbor network address and its status. In all intervals of length REFRESH_INTERVAL, a router MUST include each 1-hop neighbor network address and its status in at least one HELLO message on this MANET interface. (This may be in the same or in different HELLO messages.)
REFRESH_INTERVAL：在这个MANET接口上的HELLO消息中，每个1跳邻居网络地址及其状态的广告之间的最大间隔。在刷新间隔长度的所有间隔中，路由器必须在该MANET接口上至少一条HELLO消息中包含每个1跳邻居网络地址及其状态。（这可能在相同或不同的HELLO消息中。）
REFRESH_INTERVAL thus represents the frequency at which a piece of information, as received in HELLO messages, can be expected to be refreshed. Thus, the REFRESH_INTERVAL is used as a basis for determining when such information expires in receiving routers (see Section 5.3.2). HELLO_INTERVAL represents the frequency of HELLO message emissions. Logically, HELLO_INTERVAL cannot be greater than the REFRESH_INTERVAL; otherwise, information cannot be refreshed in a timely manner.
因此，REFRESH_INTERVAL表示在HELLO消息中接收到的信息的刷新频率。因此，刷新间隔被用作确定此类信息何时在接收路由器中过期的基础（见第5.3.2节）。HELLO_INTERVAL表示HELLO消息发射的频率。逻辑上，HELLO\u INTERVAL不能大于REFRESH\u INTERVAL；否则，无法及时刷新信息。
HELLO messages can, however, be sent with a higher frequency. A possible use for sending HELLO messages at such a higher frequency includes sending partial HELLO messages (e.g., accommodating constraints on packet sizes from the underlying medium) refreshing only part of the information in each HELLO message. Another use is for a router to send "empty HELLO messages", advertising its own presence frequently in smaller HELLO messages (e.g., in case HELLO message exchange success rates are used for link quality estimation, or to enable rapid detection by new routers in the neighborhood) in between HELLO messages refreshing neighbor information in other routers.
但是，HELLO消息可以以更高的频率发送。以如此高的频率发送HELLO消息的可能用途包括发送部分HELLO消息（例如，适应来自底层介质的分组大小的约束）仅刷新每个HELLO消息中的部分信息。另一个用途是路由器发送“空HELLO消息”，在较小的HELLO消息中频繁地宣传其自身的存在（例如，如果HELLO消息交换成功率用于链路质量估计，或使邻居中的新路由器能够快速检测）在HELLO消息之间刷新其他路由器中的邻居信息。
The following constraints apply to these interface parameters:
以下约束适用于这些接口参数：
o HELLO_INTERVAL > 0
o 您好\u间隔>0
o HELLO_MIN_INTERVAL >= 0
o 您好\u MIN\u间隔>=0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o HELLO\u INTERVAL>=HELLO\u MIN\u INTERVAL
o REFRESH_INTERVAL >= HELLO_INTERVAL
o 刷新\u间隔>=你好\u间隔
o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is included in a HELLO message, then HELLO_INTERVAL MUST be representable as described in [RFC5497].
o 如果HELLO消息中包含[RFC5497]中定义的间隔时间消息TLV，则HELLO\u间隔必须如[RFC5497]中所述可表示。
If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute its neighbor advertisements between HELLO messages in any manner, subject to the constraints above.
如果REFRESH\u INTERVAL>HELLO\u INTERVAL，则路由器可以根据上述约束，以任何方式在HELLO消息之间分发其邻居广告。
In the absence of any changes to the local neighborhood, a router will send a HELLO message on a MANET interface after an (possibly jittered) interval of length HELLO_INTERVAL. For a router to employ this protocol in a purely responsive manner on a MANET interface, i.e., for the router to only send HELLO messages on that MANET interface as a response to external events, HELLO_INTERVAL (and hence also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such that a responsive HELLO message is always expected with a shorter period than this value.
在没有对本地邻居进行任何更改的情况下，路由器将在一个长度为HELLO_interval的（可能是抖动的）间隔之后在MANET接口上发送HELLO消息。对于在MANET接口上以纯粹响应方式使用该协议的路由器，即，对于仅在该MANET接口上发送HELLO消息作为对外部事件的响应的路由器，HELLO_间隔（因此也包括REFRESH_间隔）应设置得足够大，即。，这样，响应的HELLO消息的周期总是比该值短。
If a router has more than one MANET interface, then, even if the router configures different values of HELLO_INTERVAL on each MANET interface, the router SHOULD configure the same value of HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO messages may be sent. (This ensures that changes observed on one MANET interface are reported on other MANET interfaces, so that 1-hop neighbors connected to the latter can maintain up-to-date 2-hop neighborhood information.)
如果路由器具有多个MANET接口，则即使路由器在每个MANET接口上配置了不同的HELLO_间隔值，路由器也应在所有可发送响应HELLO消息的MANET接口上配置相同的HELLO_MIN_间隔值。（这可确保在一个MANET接口上观察到的更改在其他MANET接口上报告，以便连接到后者的1-hop邻居可以保持最新的2-hop邻居信息。）
The following interface parameters manage the validity time of link information:
以下接口参数管理链接信息的有效时间：
L_HOLD_TIME: The period of advertisement, on this MANET interface, of former 1-hop neighbor network addresses as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their Link Sets. L_HOLD_TIME MAY be set to zero, if accelerated information removal is not required.
L_HOLD_TIME：在这个MANET接口上，以前的1跳邻居网络地址在HELLO消息中丢失的播发时间，允许这些HELLO消息的接收者加速从他们的链接集中删除这些信息。如果不需要加速信息删除，L_保持时间可以设置为零。
H_HOLD_TIME: Used as the Value in the VALIDITY_TIME Message TLV included in all HELLO messages on this MANET interface. It is then used by each router receiving such a HELLO message to indicate the validity of the information taken from that HELLO message and recorded in the receiving router's Information Bases.
H_HOLD_TIME：用作此MANET接口上所有HELLO消息中包含的VALIDITY_TIME消息TLV中的值。然后，接收这样一个HELLO消息的每个路由器使用它来指示从该HELLO消息中获取并记录在接收路由器的信息库中的信息的有效性。
Note that as each item of neighbor information is included in HELLO messages within an interval of length REFRESH_INTERVAL, constraints on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL.
请注意，由于每条邻居信息都包含在长度为REFRESH\u interval的HELLO消息中，因此对H\u HOLD\u时间的约束基于REFRESH\u interval，而不是HELLO\u interval。
The following constraints apply to these interface parameters:
以下约束适用于这些接口参数：
o L_HOLD_TIME >= 0
o 保持时间>=0
o H_HOLD_TIME >= REFRESH_INTERVAL
o H_保持时间>=刷新间隔
o If HELLO messages can be lost, then both parameters SHOULD be significantly greater than REFRESH_INTERVAL.
o 如果HELLO消息可能丢失，那么这两个参数都应该显著大于REFRESH\u INTERVAL。
o H_HOLD_TIME MUST be representable as described in [RFC5497].
o H_保持时间必须如[RFC5497]中所述可表示。
The following interface parameters manage the usage of link quality (see Section 14):
以下接口参数管理链路质量的使用（见第14节）：
HYST_ACCEPT: The link quality threshold at or above which a link becomes usable, if it was not already so.
HYST_ACCEPT：链路可用的链路质量阈值（如果尚未可用）。
HYST_REJECT: The link quality threshold below which a link becomes unusable, if it was not already so.
HYST_REJECT：链路质量阈值，低于该阈值时，链路将变得不可用（如果尚未可用）。
INITIAL_QUALITY: The initial quality of a newly identified link.
初始质量：新标识链接的初始质量。
INITIAL_PENDING: If true, then a newly identified link is considered pending, and is not usable until the link quality has reached or exceeded the HYST_ACCEPT threshold.
初始_挂起：如果为真，则新标识的链路被视为挂起，并且在链路质量达到或超过HYST_接受阈值之前不可用。
The following constraints apply to these interface parameters:
以下约束适用于这些接口参数：
o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= INITIAL_QUALITY <= 1.
o 0<=初始质量<=1。
o If link quality is not updated, then INITIAL_QUALITY >= HYST_ACCEPT.
o 如果未更新链接质量，则初始质量>=HYST\U接受。
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.
o 如果初始质量>=HYST\U ACCEPT，则初始待定：=false。
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true.
o 如果初始_质量<HYST_拒收，则初始_待定：=真。
If jitter, as defined in [RFC5148], is used, then these parameters are as follows:
如果使用[RFC5148]中定义的抖动，则这些参数如下：
HP_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for periodically generated HELLO messages on this MANET interface.
HP_MAXJITTER：表示[RFC5148]中用于此MANET接口上周期性生成HELLO消息的MAXJITTER值。
HT_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for externally triggered HELLO messages on this MANET interface.
HT_MAXJITTER：表示[RFC5148]中用于此MANET接口上外部触发HELLO消息的MAXJITTER值。
For constraints on these interface parameters, see [RFC5148].
有关这些接口参数的约束，请参见[RFC5148]。
The two router parameters defined by this specification are in the category of information validity time.
本规范定义的两个路由器参数属于信息有效期。
The following router parameter manages the validity time of lost symmetric 1-hop neighbor information:
以下路由器参数管理丢失的对称1跳邻居信息的有效时间：
N_HOLD_TIME: Used as the period during which former 1-hop neighbor network addresses are advertised as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their 2-Hop Sets. N_HOLD_TIME MAY be set to zero, if accelerated information removal is not required.
N_HOLD_TIME（保持时间）：用作之前的1跳邻居网络地址在HELLO消息中播发为丢失的期间，允许这些HELLO消息的收件人加速从其2跳集中删除此信息。如果不需要加速信息删除，N_保持时间可以设置为零。
I_HOLD_TIME: The period for which a recently used local interface network address is recorded.
I_保持时间：记录最近使用的本地接口网络地址的时间段。
The following constraints apply to these router parameters:
以下约束适用于这些路由器参数：
o N_HOLD_TIME >= 0
o N\u保持时间>=0
o I_HOLD_TIME >= 0
o 我保持时间>=0
If protocol parameters are changed dynamically, the constraints in this section apply.
如果协议参数动态更改，则本节中的约束将适用。
HELLO_INTERVAL
你好!
o If the HELLO_INTERVAL for a MANET interface increases, then the next HELLO message on this MANET interface MUST be generated according to the previous, shorter, HELLO_INTERVAL. A number of subsequent HELLO messages MAY be generated according to the previous, shorter, HELLO_INTERVAL (but MUST include times according to current parameters). This ensures that "promises" as to timely transmission of a future HELLO message are kept until these previous promises have expired.
o 如果MANET接口的HELLO_间隔增加，则必须根据先前更短的HELLO_间隔生成此MANET接口上的下一条HELLO消息。可以根据先前更短的HELLO_间隔生成许多后续HELLO消息（但必须根据当前参数包括时间）。这确保了在之前的承诺到期之前，及时传输未来HELLO消息的“承诺”一直保持不变。
o If the HELLO_INTERVAL for a MANET interface decreases, then the following HELLO messages on this MANET interface MUST be generated according to this current, shorter, HELLO_INTERVAL.
o 如果MANET接口的HELLO_间隔减小，则必须根据当前较短的HELLO_间隔生成此MANET接口上的以下HELLO消息。
REFRESH_INTERVAL
刷新间隔
o If the REFRESH_INTERVAL for a MANET interface increases, then the content of subsequent HELLO messages must be organized such that the specification of the old value of REFRESH_INTERVAL is satisfied for a further period equal to the old value of REFRESH_INTERVAL.
o 如果MANET接口的刷新间隔增加，则必须组织后续HELLO消息的内容，以便在与刷新间隔的旧值相等的更长时间内满足刷新间隔旧值的规范。
o If the REFRESH_INTERVAL for a MANET interface decreases, then it MAY be necessary to reschedule HELLO message generation on that MANET interface, in order for the specification of REFRESH_INTERVAL is satisfied from the time of change.
o 如果MANET接口的刷新间隔减小，则可能需要重新调度该MANET接口上的HELLO消息生成，以便从更改时起满足刷新间隔的规范。
HYST_ACCEPT and HYST_REJECT
HYST_接受和拒绝
o If HYST_ACCEPT or HYST_REJECT changes, then the appropriate actions for link quality change, as specified in Section 14.3, MUST be taken.
o 如果HYST_接受或拒绝变更，则必须采取第14.3节规定的链路质量变更的适当措施。
L_HOLD_TIME
等一下
o If L_HOLD_TIME changes, then the expiry times of all relevant Link Tuples MUST be changed.
o 如果L_保持时间更改，则必须更改所有相关链接元组的到期时间。
N_HOLD_TIME
等一下
o If N_HOLD_TIME changes, then the expiry times of all relevant Lost Neighbor Tuples MUST be changed.
o 如果N_HOLD_TIME更改，则必须更改所有相关丢失的相邻元组的到期时间。
HP_MAXJITTER
HP_最大抖动
o If HP_MAXJITTER changes, then the periodic HELLO message schedule on this MANET interface MAY be changed.
o 如果HP_MAXJITTER更改，则此MANET接口上的定期HELLO消息时间表可能会更改。
HT_MAXJITTER
HT_最大抖动
o If HT_MAXJITTER changes, then externally triggered HELLO messages on this MANET interface MAY be rescheduled.
o 如果HT_MAXJITTER发生变化，则此MANET接口上外部触发的HELLO消息可能会被重新调度。
The constant C (time granularity) is used as specified in [RFC5497].
按照[RFC5497]中的规定使用常数C（时间粒度）。
A router maintains a Local Information Base that records information about its interfaces (MANET and non-MANET). Each interface of a router MUST be identified by at least one network address. Such
路由器维护一个本地信息库，记录其接口（MANET和非MANET）的信息。路由器的每个接口必须至少由一个网络地址标识。这样的
network addresses MAY be specific to that interface, or MAY in some circumstances be used by more than one interface as specified below.
网络地址可能特定于该接口，或者在某些情况下可能由多个接口使用，如下所述。
The Local Information Base is not modified by signaling. If a router's interface configuration changes, then the Local Information Base MUST reflect these changes. This MAY also result in signaling to advertise these changes.
本地信息库不通过信令进行修改。如果路由器的接口配置发生变化，则本地信息库必须反映这些变化。这也可能导致发布这些更改的信号。
It is not necessary to include all addresses of an interface in the Local Information Base, and hence in HELLO messages. However, any address that may be the source address of an IP datagram sent from that interface MUST be included (and at least one address MUST be included). A protocol using this specification MAY add additional requirements to these, e.g., that any address that may be the destination address of an IP datagram is also included.
没有必要将接口的所有地址都包含在本地信息库中，因此也不必包含在HELLO消息中。但是，必须包括可能是从该接口发送的IP数据报的源地址的任何地址（并且必须包括至少一个地址）。使用本规范的协议可向这些协议添加附加要求，例如，也包括可能是IP数据报的目的地址的任何地址。
The addresses assigned to an interface are "owned" by the router, and MUST NOT be used by any other router as an interface address. If an address has a prefix length and represents a range of addresses, this applies to all addresses in that range (i.e., such ranges MUST NOT overlap).
分配给接口的地址由路由器“拥有”，任何其他路由器不得将其用作接口地址。如果地址具有前缀长度并表示地址范围，则这适用于该范围内的所有地址（即，此类范围不得重叠）。
The addresses assigned to different interfaces on the same router MUST be distinct (hence, network address ranges MUST NOT overlap) except that:
分配给同一路由器上不同接口的地址必须不同（因此，网络地址范围不得重叠），但以下情况除外：
o The same address MAY be assigned to any number of non-MANET interfaces as well as to one (or more if the following condition also applies) MANET interface.
o 同一地址可分配给任意数量的非MANET接口以及一个（或多个，如果以下条件也适用）MANET接口。
o The same address MAY be assigned to two (or more if each pair satisfies this condition) MANET interfaces if those two MANET interfaces cannot communicate to, from, or one to and one from any other MANET interface of another router.
o 如果两个MANET接口不能与另一路由器的任何其他MANET接口进行通信，或一个与另一路由器的任何其他MANET接口进行通信，则可以将相同的地址分配给两个（或更多，如果每对都满足此条件）MANET接口。
A router's Local Interface Set records its local interfaces. It consists of Local Interface Tuples, one per interface:
路由器的本地接口集记录其本地接口。它由本地接口元组组成，每个接口一个元组：
(I_local_iface_addr_list, I_manet)
（I_本地地址列表，I_manet）
where:
哪里：
I_local_iface_addr_list is an unordered list of the network addresses of this interface.
I_local_iface_addr_list是此接口的网络地址的无序列表。
I_manet is a boolean flag, describing if this interface is a MANET interface.
I_manet是一个布尔标志，描述此接口是否为manet接口。
Local Interface Tuples are removed from the Local Interface Set only when the routers' interface configuration changes, subject to Section 9, i.e., they are not subject to timer-based expiration.
仅当路由器的接口配置发生变化时，根据第9节，本地接口元组才从本地接口集中移除，即，它们不受基于计时器的过期限制。
A router's Removed Interface Address Set records network addresses that were recently used as local interface network addresses. If a router's interface network addresses are immutable, then the Removed Interface Address Set is always empty and MAY be omitted. It consists of Removed Interface Address Tuples, one per network address:
路由器删除的接口地址集记录最近用作本地接口网络地址的网络地址。如果路由器的接口网络地址是不可变的，那么删除的接口地址集总是空的，可以省略。它由删除的接口地址元组组成，每个网络地址一个元组：
(IR_local_iface_addr, IR_time)
（本地地址、时间）
where:
哪里：
IR_local_iface_addr is a recently used network address of an interface of this router.
IR_local_iface_addr是此路由器接口最近使用的网络地址。
IR_time specifies when this Tuple expires and MUST be removed.
IR_time指定此元组何时过期并且必须删除。
A router maintains an Interface Information Base for each of its MANET interfaces. This records information about links to that MANET interface and symmetric 2-hop neighbors that can be reached in two hops using those links as the first hop. Each Interface Information Base includes a Link Set and a 2-Hop Set.
路由器为其每个MANET接口维护一个接口信息库。这将记录有关到该MANET接口的链路以及使用这些链路作为第一跳在两跳中可以到达的对称2跳邻居的信息。每个接口信息库包括一个链接集和一个2跳集。
A network address of a symmetric 2-hop neighbor can also be present as the network address of a 1-hop neighbor. This allows the router using this network address to be immediately considered as a symmetric 2-hop neighbor if it fails to be a symmetric 1-hop neighbor.
对称2-hop邻居的网络地址也可以表示为1-hop邻居的网络地址。这允许使用此网络地址的路由器在不能成为对称1跳邻居时立即被视为对称2跳邻居。
An element that specifies a time is considered expired if the current time is greater than or equal to that time. One such element, present in most Tuples, indicates, when expired, that the Tuple itself is considered expired and MUST be removed. Tuples that do not have such a time element are removed at other times as specified; for example, a Neighbor Tuple is removed when all corresponding Link Tuples have been removed.
如果当前时间大于或等于某个时间，则指定该时间的元素将被视为已过期。大多数元组中都存在这样一个元素，当元组过期时，表示元组本身已过期，必须删除。没有时间元素的元组在指定的其他时间被删除；例如，当所有对应的链接元组都已删除时，相邻元组将被删除。
An interface's Link Set records links from other routers that are, or recently were, 1-hop neighbors. It consists of Link Tuples, each representing a single link:
接口的链路集记录来自或最近是单跳邻居的其他路由器的链路。它由链接元组组成，每个元组表示一个链接：
(L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, L_quality, L_pending, L_lost, L_time)
（邻居地址列表、听说时间、符号时间、质量、待处理、丢失、时间）
where:
哪里：
L_neighbor_iface_addr_list is an unordered list of the network addresses of the MANET interface of the 1-hop neighbor;
L_neighbor_iface_addr_list是一个无序的单跳邻居的MANET接口网络地址列表；
L_HEARD_time is the time up to which the MANET interface of the 1-hop neighbor would be considered heard if not considering link quality;
L_HEARD_time是在不考虑链路质量的情况下，1跳邻居的MANET接口将被视为听到的时间；
L_SYM_time is the time up to which the link to the 1-hop neighbor would be considered symmetric if not considering link quality;
L_SYM_time是指如果不考虑链路质量，则到1跳邻居的链路将被视为对称的时间；
L_quality is a dimensionless number between 0 (inclusive) and 1 (inclusive) describing the quality of a link; a greater value of L_quality indicating a higher quality link;
L_quality是一个介于0（含）和1（含）之间的无量纲数字，用于描述链接的质量；L_quality值越大，表示链接质量越高；
L_pending is a boolean flag, describing if a link is considered pending (i.e., a candidate, but not yet established, link);
Lpending是布尔标志，描述链接是否被认为挂起（即候选链接，但尚未建立链接）；
L_lost is a boolean flag, describing if a link is considered lost due to low link quality;
L_lost是一个布尔标志，描述是否由于低链路质量而认为链路丢失；
L_time specifies when this Tuple expires and MUST be removed.
L_time指定此元组何时过期并必须删除。
The status of the link, as obtained through HELLO message exchange and using link quality, is denoted L_status. L_status can take the Values PENDING, HEARD, SYMMETRIC, and LOST. The values LOST, SYMMETRIC, and HEARD are defined in Section 18.5. The Value PENDING is never used in a HELLO message, it is only used locally by a router, and any Value distinct from LOST, SYMMETRIC, and HEARD may be used.
通过HELLO消息交换和使用链接质量获得的链接状态表示为L_状态。L_状态可以采用挂起、听到、对称和丢失的值。丢失、对称和听到的值在第18.5节中定义。挂起的值从不在HELLO消息中使用，它仅由路由器本地使用，并且可以使用与LOST、SYMMETRIC和HEARD不同的任何值。
L_status is defined by:
L_状态定义如下：
1. If L_pending = true, then L_status := PENDING;
1. 如果L_pending=true，则L_状态：=pending；
2. otherwise, if L_lost = true, then L_status := LOST;
2. 否则，如果L_lost=true，则L_status:=lost；
3. otherwise, if L_SYM_time is not expired, then L_status := SYMMETRIC;
3. 否则，如果L_SYM_时间未过期，则L_状态：=对称；
4. otherwise, if L_HEARD_time is not expired, then L_status := HEARD;
4. 否则，如果L_HEARD_时间未过期，则L_状态：=HEARD；
5. otherwise, L_status := LOST.
5. 否则，L_状态：=丢失。
An interface's 2-Hop Set records network addresses of symmetric 2-hop neighbors, and the symmetric links to symmetric 1-hop neighbors through which these symmetric 2-hop neighbors can be reached. It consists of 2-Hop Tuples, each representing a single network address of a symmetric 2-hop neighbor, and a single MANET interface of a symmetric 1-hop neighbor.
接口的2-Hop集记录对称2-Hop邻居的网络地址，以及到对称1-Hop邻居的对称链路，通过这些对称2-Hop邻居可以到达这些对称2-Hop邻居。它由两跳元组（每个元组表示对称两跳邻居的单个网络地址）和对称一跳邻居的单个MANET接口组成。
(N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)
（N2邻居地址列表，N2跳地址，N2时间）
where:
哪里：
N2_neighbor_iface_addr_list is an unordered list of the network addresses of the MANET interface of the symmetric 1-hop neighbor from which this information was received;
N2_neighbor_iface_addr_list是接收到该信息的对称1跳邻居的MANET接口的网络地址的无序列表；
N2_2hop_addr is a network address of a symmetric 2-hop neighbor that has a symmetric link (using any MANET interface) to the indicated symmetric 1-hop neighbor;
N2_2hop_addr是对称2-hop邻居的网络地址，该邻居具有到所指示的对称1-hop邻居的对称链路（使用任何MANET接口）；
N2_time specifies when this Tuple expires and MUST be removed.
N2_time指定此元组何时过期且必须删除。
Each router maintains a Neighbor Information Base that records information about network addresses of current and recently symmetric 1-hop neighbors.
每个路由器维护一个邻居信息库，记录当前和最近对称的1跳邻居的网络地址信息。
A router's Neighbor Set records all network addresses of each 1-hop neighbor. It consists of Neighbor Tuples, each representing a single 1-hop neighbor:
路由器的邻居集记录每个1跳邻居的所有网络地址。它由邻居元组组成，每个元组表示一个1跳邻居：
(N_neighbor_addr_list, N_symmetric)
（N_邻居地址列表，N_对称）
where:
哪里：
N_neighbor_addr_list is an unordered list of the network addresses of a 1-hop neighbor;
N_neighbor_addr_list是一个1跳邻居网络地址的无序列表；
N_symmetric is a boolean flag, describing if this is a symmetric 1-hop neighbor.
N_symmetric是一个布尔标志，描述这是否是对称的1跳邻居。
Neighbor Tuples are removed from the Neighbor Set only when corresponding Link Tuples expire from the routers' Link Set, i.e., Neighbor Tuples are not directly subject to timer-based expiration.
只有当相应的链路元组从路由器的链路集中过期时，邻居元组才会从邻居集中删除，即，邻居元组不会直接受到基于计时器的过期的影响。
A router's Lost Neighbor Set records network addresses of routers that recently were symmetric 1-hop neighbors but that are now advertised as lost. It consists of Lost Neighbor Tuples, each representing a single such network address:
路由器的丢失邻居集记录最近是对称1跳邻居但现在被广告为丢失的路由器的网络地址。它由丢失的邻居元组组成，每个元组表示一个这样的网络地址：
(NL_neighbor_addr, NL_time)
（NL_邻居地址，NL_时间）
where:
哪里：
NL_neighbor_addr is a network address of a router that recently was a symmetric 1-hop neighbor of this router;
NL_neighbor_addr是路由器的网络地址，该路由器最近是该路由器的对称1跳邻居；
NL_time specifies when this Tuple expires and MUST be removed.
NL_time指定此元组何时过期并且必须删除。
The Local Information Base MUST be updated in response to changes in the router's local interface configuration. These MAY also change the Interface Information Base and the Neighbor Information Base. If any changes to the latter Information Bases satisfy any of the conditions described in Section 13, then those changes MUST be applied immediately, unless noted otherwise below.
必须更新本地信息库以响应路由器本地接口配置的更改。这些也可能改变接口信息库和邻居信息库。如果对后一信息库的任何更改满足第13节中描述的任何条件，则必须立即应用这些更改，除非下文另有说明。
A router MAY transmit HELLO messages in response to these changes.
路由器可以发送HELLO消息以响应这些更改。
If an interface is added to the router, then this is indicated by the addition of a Local Interface Tuple to the Local Interface Set. If the new interface is a MANET interface, then an initially empty Interface Information Base MUST be created for this new MANET interface. The actions in Section 9.3 MUST be taken for each network address of this added interface. A HELLO message MAY be sent on all MANET interfaces, it SHOULD be sent on the new interface if it is a
如果向路由器添加了接口，则通过向本地接口集添加本地接口元组来表示。如果新接口是MANET接口，则必须为此新MANET接口创建一个初始为空的接口信息库。必须对此添加接口的每个网络地址执行第9.3节中的操作。HELLO消息可以在所有MANET接口上发送，如果它是一个新接口，则应该在新接口上发送
MANET interface. If using scheduled messages, then a message schedule MUST be established on the new MANET interface.
移动自组网接口。如果使用计划消息，则必须在新的MANET接口上建立消息计划。
If an interface is removed from the router, then this MUST result in changes to the Local Information Base and to the Neighbor Information Base as follows:
如果从路由器中删除接口，则必须对本地信息库和邻居信息库进行如下更改：
1. Identify the Local Interface Tuple that corresponds to the interface to be removed.
1. 标识与要删除的接口对应的本地接口元组。
2. For each network address (henceforth removed address) in the I_local_iface_addr_list of that Local Interface Tuple, if that network address is not in the I_local_iface_addr_list of any other Local Interface Tuple, then create a Removed Interface Address Tuple with:
2. 对于该本地接口元组的I_local_iface_addr_列表中的每个网络地址（此后删除的地址），如果该网络地址不在任何其他本地接口元组的I_local_iface_addr_列表中，则创建一个删除的接口地址元组，其中包含：
o IR_local_iface_addr := removed address;
o IR\u local\u iface\u addr:=删除的地址；
o IR_time := current time + I_HOLD_TIME.
o IR_时间：=当前时间+I_保持时间。
3. Remove that Local Interface Tuple from the Local Interface Set.
3. 从本地接口集中删除该本地接口元组。
4. If the interface to be removed is a MANET interface (i.e., with I_manet = true), then:
4. 如果要删除的接口是MANET接口（即i_MANET=true），则：
1. Remove the Interface Information Base for that MANET interface;
1. 移除该MANET接口的接口信息库；
2. All Neighbor Tuples for which none of the network addresses in its N_neighbor_addr_list are contained in any L_neighbor_iface_addr_list in any remaining Link Tuple are removed.
2. 所有在其N_Neighbor_addr_列表中没有网络地址的邻居元组都将被删除在任何剩余链接元组的L_Neighbor_iface_addr_列表中。
If the removed interface is the last MANET interface of the router, then there will be no remaining Interface Information Bases, and the router will no longer participate in this protocol.
如果删除的接口是路由器的最后一个MANET接口，那么将没有剩余的接口信息库，路由器将不再参与该协议。
After removing the interface and making these changes, a HELLO message MAY be sent on all remaining MANET interfaces.
删除接口并进行这些更改后，可能会在所有剩余的MANET接口上发送HELLO消息。
If a network address is added to an interface, then this is indicated by the addition of a network address to the appropriate I_local_iface_addr_list. The following changes MUST be made to the Information Bases:
如果将网络地址添加到接口，则通过将网络地址添加到相应的I_local_iface_addr_列表来表示。必须对信息库进行以下更改：
1. Remove any Removed Interface Address Tuple whose IR_local_iface_addr is the added network address.
1. 删除IR_local_iface_addr为添加的网络地址的任何已删除接口地址元组。
2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a network address that overlaps the added network address.
2. 删除其N_Neighbor_addr_列表包含与添加的网络地址重叠的网络地址的任何邻居元组。
3. Remove any Link Tuples, in any Link Set, for which either:
3. 删除任何链接集中的任何链接元组，其中：
o L_neighbor_iface_addr_list contains any network address in the N_neighbor_addr_list of any removed Neighbor Tuple; OR
o L_neighbor_iface_addr_列表包含任何删除的邻居元组的N_neighbor_addr_列表中的任何网络地址；或
o L_neighbor_iface_addr_list contains a network address that overlaps the added network address.
o L_neighbor_iface_addr_列表包含与添加的网络地址重叠的网络地址。
Apply Section 13.2 but not Section 13.3.
适用第13.2节，但不适用第13.3节。
4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps the added network address.
4. 删除NL_Neighbor_addr与添加的网络地址重叠的任何丢失的邻居元组。
5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added network address.
5. 删除N2_2hop_addr与添加的网络地址重叠的任何2-Hop元组。
After adding the network address and making these changes, a HELLO message MAY be sent on all MANET interfaces.
添加网络地址并进行这些更改后，可以在所有MANET接口上发送HELLO消息。
These changes, other than to the appropriate I_local_iface_addr_list, are made in order to maintain consistency of the Information Bases. Specifically, these changes remove any record of any use of this network address by routers in the 1-hop neighborhood or in the symmetric 2-hop neighborhood of this router.
除了适当的I_local_iface_addr_列表，这些更改是为了保持信息库的一致性。具体而言，这些更改将删除路由器在该路由器的1跳邻居或对称2跳邻居中使用该网络地址的任何记录。
If a network address (henceforth removed address) is removed from an interface, then:
如果从接口中删除网络地址（此后删除的地址），则：
1. Identify the Local Interface Tuple that corresponds to the removed address.
1. 标识与已删除地址对应的本地接口元组。
2. If this is the only network address of that interface (the only network address in the corresponding I_local_iface_addr_list), then remove that interface as specified in Section 9.2.
2. 如果这是该接口的唯一网络地址（对应I_local_iface_addr_列表中的唯一网络地址），则按照第9.2节的规定删除该接口。
3. Otherwise:
3. 否则：
1. Remove the removed address from this I_local_iface_addr_list.
1. 从本地地址列表中删除删除的地址。
2. If the removed address is not in the I_local_iface_addr_list of any other Local Interface Tuple, then create a Removed Interface Address Tuple with:
2. 如果删除的地址不在任何其他本地接口元组的I_local_iface_addr_列表中，则使用以下内容创建删除的接口地址元组：
o IR_local_iface_addr := removed address;
o IR\u local\u iface\u addr:=删除的地址；
o IR_time := current time + I_HOLD_TIME.
o IR_时间：=当前时间+I_保持时间。
After removing the network address and making these changes, a HELLO message MAY be sent on all MANET interfaces.
删除网络地址并进行这些更改后，可以在所有MANET接口上发送HELLO消息。
The packet and message format used by this protocol is defined in [RFC5444], which is used with the following considerations:
[RFC5444]中定义了本协议使用的数据包和消息格式，使用该格式时应考虑以下因素：
o This protocol specifies one Message Type, the HELLO message.
o 此协议指定一种消息类型，即HELLO消息。
o A HELLO message MAY use any combination of Message Header options specified in [RFC5444].
o HELLO消息可以使用[RFC5444]中指定的消息头选项的任意组合。
o HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if present, MUST have the value 1.
o HELLO消息不得转发，即<msg hop limit>（如果存在）的值必须为1。
o HELLO messages MAY be included in multi-message packets as specified in [RFC5444].
o 如[RFC5444]所述，HELLO消息可包含在多消息包中。
o Received HELLO messages MUST be parsed in accordance with [RFC5444]. A HELLO message that is not in conformance with [RFC5444] MUST be discarded without being processed. A HELLO message can also be discarded without being processed for other reasons, see Section 12.1.
o 必须根据[RFC5444]对收到的HELLO消息进行分析。不符合[RFC5444]的HELLO消息必须在未经处理的情况下丢弃。由于其他原因，HELLO消息也可以在不进行处理的情况下被丢弃，请参见第12.1节。
o This protocol specifies three Address Block TLVs. It also uses two Message TLVs defined in [RFC5497]. These five TLV Types are all defined only with Type Extension = 0. TLVs of other types, and of these types but without Type Extension = 0, are ignored by this protocol. All references in this specification to, for example, an Address Block TLV with Type = LINK_STATUS, are to be considered as referring to an Address Block TLV with Type = LINK_STATUS and Type Extension = 0.
o 此协议指定三个地址块TLV。它还使用[RFC5497]中定义的两个消息TLV。这五种TLV类型都仅在类型扩展=0时定义。此协议将忽略其他类型的TLV，以及这些类型但没有类型扩展=0的TLV。例如，本规范中对类型=链路\状态的地址块TLV的所有引用应视为对类型=链路\状态且类型扩展=0的地址块TLV的引用。
A HELLO message MUST contain:
HELLO消息必须包含：
o Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497], representing H_HOLD_TIME for the transmitting MANET interface.
o [RFC5497]中规定的一条有效时间消息TLV，表示传输MANET接口的H_保持时间。
The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
不得使用[RFC5497]中包含的表示零次和无限次的选项。
A HELLO message transmitted due to a periodic timer SHOULD contain, and otherwise (i.e., transmitted for any other reason, in particular in response to any Information Base changes) MAY contain:
由于周期计时器而发送的HELLO消息应包含，否则（即，由于任何其他原因，特别是响应任何信息库更改而发送的HELLO消息）可能包含：
o Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497], representing HELLO_INTERVAL for the transmitting MANET interface. The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
o [RFC5497]中规定的正好一个间隔时间消息TLV，表示传输MANET接口的HELLO\u间隔。不得使用[RFC5497]中包含的表示零次和无限次的选项。
A HELLO message MAY contain:
HELLO消息可能包含：
o Other Message TLVs.
o 其他消息TLV。
o One or more Address Blocks, each with an associated Address Block TLV Block, which MAY contain other Address Block TLVs.
o 一个或多个地址块，每个地址块具有关联的地址块TLV块，该地址块可能包含其他地址块TLV。
All network addresses in a router's Local Interface Set (i.e., in any I_local_iface_addr_list) MUST be represented as address objects (see [RFC5444]), and included in the Address Blocks in all generated HELLO messages, with the following permitted exception:
路由器本地接口集中（即任何i_Local_iface_addr_列表中）的所有网络地址必须表示为地址对象（请参见[RFC5444]），并包含在所有生成的HELLO消息的地址块中，但以下允许的例外情况除外：
o If the MANET interface on which the HELLO message is to be sent has a single address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6), then that address MAY be omitted from being included in any Address Block, provided that this address is included as the sending address of the IP datagram in which the HELLO message is included.
o 如果要发送HELLO消息的MANET接口有一个具有最大前缀长度的地址（即，IPv4为/32，IPv6为/128），则该地址可以省略，不包括在任何地址块中，前提是该地址包括为包含HELLO消息的IP数据报的发送地址。
All network addresses of the router's interfaces included in any Address Block(s) MUST be associated with an Address Block TLV with Type = LOCAL_IF, as defined in Table 1.
任何地址块中包含的路由器接口的所有网络地址必须与类型为LOCAL_的地址块TLV相关联，如表1所定义。
+----------+---------+----------------------------------------------+
| Name | Value | Description |
| | Length | |
+----------+---------+----------------------------------------------+
| LOCAL_IF | 1 octet | Specifies that the network address is |
| | | associated with the MANET interface on which |
| | | the message was sent (THIS_IF) or another |
| | | interface of the sending router (OTHER_IF). |
+----------+---------+----------------------------------------------+
+----------+---------+----------------------------------------------+
| Name | Value | Description |
| | Length | |
+----------+---------+----------------------------------------------+
| LOCAL_IF | 1 octet | Specifies that the network address is |
| | | associated with the MANET interface on which |
| | | the message was sent (THIS_IF) or another |
| | | interface of the sending router (OTHER_IF). |
+----------+---------+----------------------------------------------+
Table 1: LOCAL_IF TLV Definition
表1:TLV定义中的局部_
Address Blocks MAY contain current or recently lost 1-hop neighbors' network addresses, represented as address objects (see [RFC5444]), each of which is associated with one or both Address Block TLVs as described in Table 2.
地址块可能包含当前或最近丢失的1跳邻居的网络地址，表示为地址对象（参见[RFC5444]），每个地址块与表2中所述的一个或两个地址块TLV相关联。
+--------------+---------+------------------------------------------+
| Name | Value | Description |
| | Length | |
+--------------+---------+------------------------------------------+
| LINK_STATUS | 1 octet | Specifies the status of the link from |
| | | the indicated network address and to the |
| | | MANET interface over which the HELLO |
| | | message is transmitted (LOST, SYMMETRIC, |
| | | or HEARD). |
| OTHER_NEIGHB | 1 octet | Specifies that the network address is |
| | | (SYMMETRIC) or was (LOST) of a MANET |
| | | interface of a symmetric 1-hop neighbor |
| | | of the router transmitting the HELLO |
| | | message. |
+--------------+---------+------------------------------------------+
+--------------+---------+------------------------------------------+
| Name | Value | Description |
| | Length | |
+--------------+---------+------------------------------------------+
| LINK_STATUS | 1 octet | Specifies the status of the link from |
| | | the indicated network address and to the |
| | | MANET interface over which the HELLO |
| | | message is transmitted (LOST, SYMMETRIC, |
| | | or HEARD). |
| OTHER_NEIGHB | 1 octet | Specifies that the network address is |
| | | (SYMMETRIC) or was (LOST) of a MANET |
| | | interface of a symmetric 1-hop neighbor |
| | | of the router transmitting the HELLO |
| | | message. |
+--------------+---------+------------------------------------------+
Table 2: LINK_STATUS and OTHER_NEIGHB TLV Definition
表2：链路状态和其他相邻TLV定义
An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or Value = LOST also performs the function of an Address Block TLV with Type = OTHER_NEIGHB and the same Value. Including the latter associated with the same address object is discouraged for efficiency reasons. If an Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an Address Block TLV with Type = OTHER_NEIGHB and Value = LOST associated with the same address object, then the latter MUST be ignored and SHOULD NOT be included. See Appendix A.
类型为链接状态且值为对称或值为丢失的地址块TLV也执行类型为其他相邻且值相同的地址块TLV的功能。出于效率原因，不鼓励将后者与同一地址对象关联。如果类型为LINK_STATUS且值为SYMMETRIC的地址块TLV与类型为OTHER_NEIGHB且值为LOST的地址块TLV与同一地址对象相结合，则后者必须被忽略且不应包括在内。见附录A。
Other network addresses MAY be represented as address objects (see [RFC5444]) and included in Address Blocks, but MUST NOT be associated with any of the Address Block TLVs specified in this specification.
其他网络地址可表示为地址对象（见[RFC5444]），并包含在地址块中，但不得与本规范中规定的任何地址块TLV相关联。
Each MANET interface MUST generate HELLO messages according to the specification in this section. HELLO messages are generated for each MANET interface independently. HELLO message generation and scheduling MUST be according to the interface parameters for that MANET interface, and MAY be independent for each MANET interface or, interface parameters permitting, MANET interfaces MAY use the same schedule.
每个MANET接口必须根据本节中的规范生成HELLO消息。为每个MANET接口独立生成HELLO消息。HELLO消息的生成和调度必须根据该MANET接口的接口参数，并且可以独立于每个MANET接口，或者，如果接口参数允许，MANET接口可以使用相同的调度。
If transmitting periodic HELLO messages, then, following a HELLO message transmission on a MANET interface, another HELLO message MUST be transmitted on the same MANET interface after an interval not greater than HELLO_INTERVAL. Two successive HELLO message transmissions on the same MANET interface MUST be separated by at least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.
如果定期发送HELLO消息，则在MANET接口上传输HELLO消息后，必须在不大于HELLO_interval的间隔后在同一MANET接口上传输另一条HELLO消息。同一MANET接口上的两个连续HELLO消息传输必须至少间隔HELLO_MIN_间隔，除非第11.2.1节另有说明。
HELLO messages are generated independently on each MANET interface.
HELLO消息在每个MANET接口上独立生成。
All network addresses in any I_local_iface_addr_list MUST be included, represented as address objects (see [RFC5444]), except that:
必须包括任何I_local_iface_addr_列表中的所有网络地址，以地址对象表示（请参见[RFC5444]），但以下情况除外：
o If the interface on which the HELLO message is to be sent has a single address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6), then that address MAY be omitted, provided that this address is included as the sending address of the IP datagram in which the HELLO message is included.
o 如果发送HELLO消息的接口有一个最大前缀长度的地址（即，IPv4为/32，IPv6为/128），则可以省略该地址，前提是该地址作为包含HELLO消息的IP数据报的发送地址。
All such included address objects MUST be associated with an Address Block TLV with Type := LOCAL_IF and Value according to the following:
所有此类包含的地址对象必须与地址块TLV相关联，地址块TLV的类型为：=LOCAL_IF，值如下所示：
o If the address object represents a network address of the sending MANET interface, then Value := THIS_IF.
o 如果address对象表示发送MANET接口的网络地址，则值：=此_If。
o Otherwise, Value := OTHER_IF.
o 否则，值：=其他_如果。
If such a network address is included in more than one I_local_iface_addr_list, then, for efficiency reasons, it is encouraged that the corresponding address object is associated with only one Value using an Address Block TLV with Type := LOCAL_IF; this MUST be Value := THIS_IF if the address object represents a network address of the sending MANET interface.
如果这样的网络地址包含在多个I_local_iface_addr_列表中，则出于效率原因，建议使用类型为=local_If；如果address对象表示发送MANET接口的网络地址，则该值必须为：=此_。
The following network addresses of current or former 1-hop neighbors MAY be represented as address objects (see [RFC5444]) and included in any HELLO message, respecting the parameter REFRESH_INTERVAL for each association for that MANET interface, and according to the following:
当前或以前的1-hop邻居的以下网络地址可以表示为地址对象（参见[RFC5444]），并包含在任何HELLO消息中，与MANET接口的每个关联的参数刷新间隔有关，并符合以下要求：
o Network addresses of MANET interfaces of 1-hop neighbors from the Link Set of the Interface Information Base for this MANET interface (i.e., from an L_neighbor_iface_addr_list), other than those from Link Tuples with L_status = PENDING.
o 来自该MANET接口接口信息库链路集的1跳邻居的MANET接口的网络地址（即，来自L_neighbor_iface_addr_列表），而不是来自L_status=PENDING的链路元组的网络地址。
o Other network addresses of symmetric 1-hop neighbors from the Neighbor Set of this router's Neighbor Information Base (i.e., from an N_neighbor_addr_list).
o 来自该路由器邻居信息库的邻居集（即，来自N_Neighbor_addr_列表）的对称1跳邻居的其他网络地址。
o Network addresses of MANET interfaces of previously symmetric or heard 1-hop neighbors connected on this MANET interface from the Link Set of the Interface Information Base for this MANET interface (i.e., from an L_neighbor_iface_addr_list with L_status = LOST).
o 从该MANET接口的接口信息库的链路集（即，从L_状态=丢失的L_邻居地址列表）连接到该MANET接口上的先前对称或听到的1跳邻居的MANET接口的网络地址。
o Other network addresses of previously symmetric 1-hop neighbors from the Lost Neighbor Set of this router's Neighbor Information Base (i.e., from an NL_neighbor_addr).
o 来自该路由器邻居信息库丢失邻居集（即来自NL_Neighbor_addr）的先前对称1跳邻居的其他网络地址。
Each such address object (see [RFC5444]) MUST be associated with one or more appropriate Address Block TLVs. Specifically:
每个这样的地址对象（参见[RFC5444]）必须与一个或多个适当的地址块TLV相关联。明确地：
1. For each address object (henceforth linked address) that represents a network address contained in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set for this MANET interface, for which L_status != PENDING, include the linked address with an associated Address Block TLV with:
1. 对于表示此MANET接口链接集中链接元组的L_neighbor_iface_addr_列表中包含的网络地址的每个地址对象（此后为链接地址），L_status！=挂起，将链接地址与关联地址块TLV包括在一起：
o Type := LINK_STATUS; AND
o 类型：=链路状态；和
o Value := L_status.
o 值：=L_状态。
2. For each address object (henceforth neighbor address) that represents a network address contained in an N_neighbor_addr_list in a Neighbor Tuple with N_symmetric = true and that has not already been included with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor network address with an associated Address Block TLV with:
2. 对于表示包含在N_symmetric=true的邻居元组中的N_neighbor_addr_列表中的网络地址且尚未包含在类型为LINK_STATUS且值为symmetric的关联地址块TLV中的每个地址对象（此后称为neighbor address），包括具有关联地址块TLV的邻居网络地址，地址块TLV具有：
o Type := OTHER_NEIGHB; AND
o 类型：=其他_NEIGHB；和
o Value := SYMMETRIC.
o 值：=对称。
3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth lost address) has not already been represented as an address object and included, include lost address with an associated Address Block TLV with:
3. 对于其NL_Neighbor_addr（此后为丢失地址）尚未表示为地址对象且未包含在内的每个丢失的邻居元组，将丢失的地址与关联的地址块TLV包括在一起：
o Type := OTHER_NEIGHB; AND
o 类型：=其他_NEIGHB；和
o Value := LOST.
o 值：=丢失。
If any such network addresses have been added to these Information Bases since the last HELLO message was sent on this MANET interface, or if their status (as indicated by these TLVs and the Values they associate with that network address) have changed since that network address was last reported on this MANET interface, then that network address, and the indicated TLVs, SHOULD be included in the HELLO message.
如果自上次在该MANET接口上发送HELLO消息以来，任何此类网络地址已添加到这些信息库中，或者自上次在该MANET接口上报告该网络地址以来，其状态（由这些TLV及其与该网络地址关联的值指示）已发生变化，则该网络地址，以及指示的TLV，应包含在HELLO消息中。
If the address object (see [RFC5444]) representing a network address of a 1-hop neighbor is specified with more than one associated Address Block TLV, then these Address Block TLVs MAY be independently included or excluded from each HELLO message. Each such Address Block TLV MUST be included associated with the address object representation of that network address in a HELLO message sent on that MANET interface in every interval of length equal to that MANET interface's parameter REFRESH_INTERVAL. Address Block TLVs associated with the same address object included in the same HELLO message MAY be applied to the same or different copies of that address object.
如果表示一跳邻居的网络地址的地址对象（参见[RFC5444]）被指定有多个相关联的地址块TLV，那么这些地址块TLV可以独立地从每个HELLO消息中包括或排除。每个这样的地址块TLV必须包括在该MANET接口上发送的HELLO消息中与该网络地址的地址对象表示相关联的地址块TLV，其长度的每个间隔等于该MANET接口的参数REFRESH_interval。与包含在同一HELLO消息中的同一地址对象相关联的地址块TLV可应用于该地址对象的相同或不同副本。
An implementation of this protocol MAY limit the information included in each HELLO message, for example, to accommodate smaller MTU sizes. HELLO messages remain constrained by the above requirements, in particular, that all local interface information MUST be included in all HELLO messages, and that all neighbor information MUST be sent within each interval of length REFRESH_INTERVAL. This neighbor information MAY, however, be sent in the same or in different HELLO messages.
该协议的实现可以限制包括在每个HELLO消息中的信息，例如，以适应较小的MTU大小。HELLO消息仍然受到上述要求的约束，特别是所有本地接口信息必须包含在所有HELLO消息中，并且所有邻居信息必须在每个长度间隔内发送。然而，该邻居信息可以在相同或不同的HELLO消息中发送。
HELLO messages are transmitted in the format specified by [RFC5444].
HELLO消息以[RFC5444]指定的格式传输。
HELLO messages MAY be sent using periodic message generation or externally triggered message generation. If using data link and physical layers that are subject to packet loss due to collisions, HELLO messages SHOULD be jittered as described in [RFC5148].
HELLO消息可以使用定期消息生成或外部触发消息生成来发送。如果使用的数据链路和物理层由于冲突而丢失数据包，HELLO消息应按照[RFC5148]中的说明进行抖动。
Internally triggered message generation (such as due to a change in local interfaces) MAY be treated as if externally generated message generation or MAY be not jittered.
内部触发的消息生成（例如由于本地接口的更改）可以被视为外部生成的消息生成，或者可以不受抖动。
HELLO messages MUST NOT be forwarded, and thus message forwarding jitter does not apply to HELLO messages.
HELLO消息不得转发，因此消息转发抖动不适用于HELLO消息。
Each form of jitter described in [RFC5148] requires a parameter MAXJITTER. These interface parameters may be dynamic and are specified by:
[RFC5148]中描述的每种形式的抖动都需要一个参数MAXJITTER。这些接口参数可能是动态的，由以下参数指定：
o For periodic message generation: HP_MAXJITTER.
o 对于定期消息生成：HP_MAXJITTER。
o For externally triggered message generation: HT_MAXJITTER.
o 对于外部触发的消息生成：HT_MAXJITTER。
When HELLO message generation is delayed in order that a HELLO message is not sent within HELLO_MIN_INTERVAL of the previous HELLO message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD be reduced by jitter, with maximum reduction HP_MAXJITTER, as described in [RFC5148]. In this case, HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL.
当HELLO消息生成延迟，以便在同一MANET接口上的前一条HELLO消息的HELLO_MIN_间隔内不发送HELLO_消息时，HELLO_MIN_间隔应通过抖动减小，最大程度地减小HP_MAXJITTER，如[RFC5148]所述。在这种情况下，HP_MAXJITTER不得大于HELLO_MIN_INTERVAL。
On receiving a HELLO message, a router MUST first check if the message is invalid for processing by this router, as defined in Section 12.1 and, if so, discard the message without further processing. Otherwise, for each received and valid HELLO message, the receiving router MUST update its appropriate Interface Information Base and its Neighbor Information Base as specified in Section 12.3 to Section 12.6. These updates MUST be performed in the order in which they are presented in this specification. If any changes satisfy any of the conditions described in Section 13, then the indicated consequences in that section MUST be applied immediately, unless noted otherwise.
在接收到HELLO消息时，路由器必须首先检查该消息是否对该路由器的处理无效，如第12.1节所定义，如果是，则丢弃该消息而不进行进一步处理。否则，对于每个接收到的有效HELLO消息，接收路由器必须按照第12.3节至第12.6节的规定更新其相应的接口信息库及其邻居信息库。这些更新必须按照本规范中的显示顺序执行。如果任何变更满足第13节中描述的任何条件，则必须立即应用该节中指明的后果，除非另有说明。
All message processing, including determination of whether a message is invalid, considers only TLVs with Type Extension = 0. TLVs with any other type extension are ignored. All references to, for example, a TLV with Type = LINK_STATUS refer to a TLV with Type = LINK_STATUS and Type Extension = 0.
所有消息处理，包括确定消息是否无效，只考虑扩展类型为0的TLV。忽略具有任何其他类型扩展的TLV。例如，对类型=链接\状态的TLV的所有引用均指类型=链接\状态且类型扩展=0的TLV。
A received HELLO message is invalid for processing by this router if any of the following conditions are true:
如果满足以下任一条件，则接收到的HELLO消息对此路由器的处理无效：
o The address length as specified in the Message Header is not equal to the length of the addresses used by this router.
o 消息头中指定的地址长度不等于此路由器使用的地址长度。
o The message has a <msg-hop-limit> field in its Message Header with a value other than one. (Note that the message does not need to have a <msg-hop-limit> field.)
o 消息的消息头中有一个值不是一的<msg hop limit>字段。（请注意，消息不需要有<msg hop limit>字段。）
o The message has a <msg-hop-count> field in its Message Header with a value other than zero. (Note that the message does not need to have a <msg-hop-count> field.)
o 消息的消息头中有一个值不是零的<msg hop count>字段。（请注意，消息不需要有<msg hop count>字段。）
o The message does not have a Message TLV with Type = VALIDITY_TIME in its Message TLV Block.
o 消息的消息TLV块中没有Type=VALIDITY\u TIME的消息TLV。
o The message has more than one Message TLV with Type = VALIDITY_TIME in its Message TLV Block.
o 该消息在其消息TLV块中有多个类型为VALIDITY\u TIME的消息TLV。
o The message has more than one Message TLV with Type = INTERVAL_TIME in its Message TLV Block.
o 该消息在其消息TLV块中有多个类型为INTERVAL_TIME的消息TLV。
o The message has any Address Block TLV(s) with Type = LOCAL_IF and any single Value v such that v != THIS_IF and v != OTHER_IF.
o 该消息具有任何类型为LOCAL_IF的地址块TLV和任何单个值v，以便v！=这是IF和v！=如果有的话。
o Any address object (including different address objects representing the same network address, in the same or different Address Blocks) is associated with more than one Value by one or more Address Block TLV(s) with Type = LOCAL_IF.
o Any address object (including different address objects representing the same network address, in the same or different Address Blocks) is associated with more than one Value by one or more Address Block TLV(s) with Type = LOCAL_IF.translate error, please retry
o Any address object (henceforth local address) associated with an Address Block TLV with Type = LOCAL_IF represents one of the receiving router's current or recently used network addresses (i.e., local address overlaps any network address in any I_local_iface_addr_list in the Local Interface Set or any IR_local_iface_addr in the Removed Interface Address Set).
o 与Type=local\u的地址块TLV关联的任何地址对象（此后为本地地址），如果表示接收路由器的当前或最近使用的网络地址之一（即，本地地址与本地接口集中的任何i_local_iface_addr_列表中的任何网络地址重叠，或与删除的接口地址集中的任何IR_local_iface_addr重叠）。
o The message has any Address Block TLV(s) with Type = LINK_STATUS with any single Value v such that v != LOST, v != SYMMETRIC, and v != HEARD.
o 消息具有类型为LINK_状态的任何地址块TLV，且具有任何单个值v，以便v！=迷路了，v！=对称，和v！=听到。
o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB with any single Value v such that v != LOST and v != SYMMETRIC.
o 该消息具有类型为OTHER_NEIGHB的任何地址块TLV和任何单个值v，以便v！=迷失与v！=对称的。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with an Address Block TLV with Type = LOCAL_IF and with an Address Block TLV with Type = LINK_STATUS.
o 任何地址对象（包括地址对象的不同副本，在相同或不同的地址块中）都与类型为LOCAL\u的地址块TLV关联，如果与类型为LINK\u状态的地址块TLV关联。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with an Address Block TLV with Type = LOCAL_IF and with an Address Block TLV with Type = OTHER_NEIGHB.
o 任何地址对象（包括相同或不同地址块中地址对象的不同副本）都与类型为LOCAL\u IF的地址块TLV关联，并且与类型为OTHER\u NEIGHB的地址块TLV关联。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with more than one Value by one or more Address Block TLVs with Type = LINK_STATUS.
o 任何地址对象（包括地址对象的不同副本，在相同或不同的地址块中）由一个或多个类型为LINK_状态的地址块TLV与多个值关联。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with more than one Value by one or more Address Block TLVs with Type = OTHER_NEIGHB.
o 任何地址对象（包括地址对象的不同副本，在相同或不同的地址块中）由一个或多个类型为OTHER_NEIGHB的地址块TLV与多个值关联。
A router MAY recognize additional reasons for identifying that a message is badly formed and therefore invalid for processing, e.g., to allow a security protocol as suggested in Section 17 to perform verification of HELLO message signatures and prevent processing of unverifiable HELLO messages by this protocol.
路由器可以识别用于识别消息格式错误并因此对处理无效的其他原因，例如，允许第17节中建议的安全协议执行HELLO消息签名的验证，并防止通过该协议处理无法验证的HELLO消息。
An invalid message MUST be silently discarded, without updating the router's Information Bases.
无效消息必须以静默方式丢弃，而不更新路由器的信息库。
For the purpose of this section, note the following definitions:
在本节中，请注意以下定义：
o "validity time" is calculated from the Message TLV with Type = VALIDITY_TIME of the HELLO message as specified in [RFC5497]. (Note that, as specified by Section 12.1, there must be exactly one such Message TLV in the HELLO message.) All information in the HELLO message used by this specification has the same validity time.
o “有效期时间”根据[RFC5497]中指定的HELLO消息的类型=有效期时间的消息TLV计算得出。（请注意，根据第12.1节的规定，HELLO消息中必须正好有一条此类消息TLV。）本规范使用的HELLO消息中的所有信息具有相同的有效期。
o "Receiving Address List" is the I_local_iface_addr_list corresponding to the MANET interface on which the HELLO message was received
o “接收地址列表”是与接收HELLO消息的MANET接口相对应的本地地址列表
o "Sending Address List" is an unordered list of network addresses of the MANET interface over which the HELLO message was sent, i.e., is an unordered list of the network addresses represented by address objects contained in the HELLO message with an associated Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If the Sending Address List is otherwise empty, then the Sending Address List contains a single network address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6) with an address equal to the sending address of the IP datagram in which the HELLO message was included.
o “发送地址列表”是发送HELLO消息的MANET接口的网络地址的无序列表，即，是由包含在HELLO消息中的地址对象表示的网络地址的无序列表，具有类型为LOCAL_IF且值为THIS_IF的关联地址块TLV。如果发送地址列表为空，则发送地址列表包含一个最大前缀长度的网络地址（即，IPv4为/32，IPv6为/128），其地址等于包含HELLO消息的IP数据报的发送地址。
o "Neighbor Address List" is an unordered list of all the network addresses of all the interfaces of the router that generated the HELLO message, i.e., is the Sending Address List, plus the network
o “邻居地址列表”是生成HELLO消息的路由器所有接口的所有网络地址的无序列表，即发送地址列表和网络
addresses represented by address objects contained in the HELLO message with an associated Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF.
由包含在HELLO消息中的地址对象表示的地址，其关联地址块TLV的类型为LOCAL_IF，值为OTHER_IF。
o "EXPIRED" indicates that a timer is set to a value clearly preceding the current time (e.g., current time - 1).
o “过期”表示计时器设置为明显早于当前时间的值（例如，当前时间-1）。
o "Removed Address List" is a list of network addresses created by this HELLO message processing that were formerly reported as local by the router originating the HELLO message but that are not included in the Neighbor Address List. This list is initialized as empty.
o “删除的地址列表”是通过此HELLO消息处理创建的网络地址列表，这些地址以前由发起HELLO消息的路由器报告为本地地址，但不包括在邻居地址列表中。此列表初始化为空。
o "Lost Address List" is a subset of the Removed Address List containing network addresses that were formerly considered as symmetric. This list is initialized as empty.
o “丢失的地址列表”是删除的地址列表的子集，其中包含以前被视为对称的网络地址。此列表初始化为空。
On receiving a HELLO message, the router MUST update its Neighbor Set and populate the Removed Address List and Lost Address List:
收到HELLO消息后，路由器必须更新其邻居集，并填充删除的地址列表和丢失的地址列表：
1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples) where N_neighbor_addr_list contains any network address that overlaps with any network address in the Neighbor Address List.
1. 查找所有邻居元组（此后匹配邻居元组），其中N_Neighbor_addr_列表包含与邻居地址列表中的任何网络地址重叠的任何网络地址。
2. If there are no matching Neighbor Tuples, then:
2. 如果没有匹配的相邻元组，则：
1. Create a new Neighbor Tuple with:
1. 使用以下内容创建新的邻居元组：
o N_neighbor_addr_list := Neighbor Address List;
o N_邻居地址列表：=邻居地址列表；
o N_symmetric := false.
o N_对称：=假。
3. If there is one matching Neighbor Tuple, then:
3. 如果存在一个匹配的邻居元组，则：
1. If the matching Neighbor Tuple's N_neighbor_addr_list != Neighbor Address List, then:
1. 如果匹配的邻居元组的N_Neighbor_addr_列表！=邻居地址列表，然后：
1. For each network address (henceforth removed address) that is contained in that N_neighbor_addr_list but that is not contained in the Neighbor Address List:
1. 对于包含在N_邻居地址列表中但不包含在邻居地址列表中的每个网络地址（此后删除的地址）：
1. Add the removed address to the Removed Address List.
1. 将删除的地址添加到删除的地址列表中。
2. If N_symmetric = true, then add the removed address to the Lost Address List.
2. 如果N_symmetric=true，则将删除的地址添加到丢失的地址列表中。
2. Update the matching Neighbor Tuple by:
2. 通过以下方式更新匹配的邻居元组：
o N_neighbor_addr_list := Neighbor Address List.
o N\u邻居地址列表：=邻居地址列表。
4. If there are two or more matching Neighbor Tuples, then:
4. 如果存在两个或多个匹配的相邻元组，则：
1. For each network address (henceforth removed address) that is contained in the N_neighbor_addr_list of any of the matching Neighbor Tuples but is not contained in the Neighbor Address List:
1. 对于包含在任何匹配邻居元组的N_neighbor_addr_列表中但不包含在邻居地址列表中的每个网络地址（此后删除的地址）：
1. Add removed address to the Removed Address List.
1. 将删除的地址添加到删除的地址列表中。
2. If N_symmetric = true, then add removed address to the Lost Address List.
2. 如果N_symmetric=true，则将删除的地址添加到丢失的地址列表中。
2. Replace the matching Neighbor Tuples by a single Neighbor Tuple with:
2. 将匹配的邻居元组替换为单个邻居元组：
o N_neighbor_addr_list := Neighbor Address List;
o N_邻居地址列表：=邻居地址列表；
o N_symmetric := false
o N_对称：=假
On receiving a HELLO message, a router MUST update its Lost Neighbor Set:
在收到HELLO消息时，路由器必须更新其丢失的邻居集：
1. For each network address (henceforth lost address) that is contained in the Lost Address List, if no Lost Neighbor Tuple with NL_neighbor_addr = lost address exists, then add a Lost Neighbor Tuple with:
1. 对于丢失地址列表中包含的每个网络地址（此后为丢失地址），如果不存在NL_Neighbor_addr=丢失地址的丢失邻居元组，则添加一个具有以下内容的丢失邻居元组：
o NL_neighbor_addr := lost address;
o NL_邻居_地址：=丢失的地址；
o NL_time := current time + N_HOLD_TIME.
o NL_时间：=当前时间+N_保持时间。
On receiving a HELLO message, a router MUST update its Link Sets:
收到HELLO消息时，路由器必须更新其链接集：
1. Remove all network addresses in the Removed Address List from the L_neighbor_iface_addr_list of all Link Tuples.
1. 从所有链接元组的L_neighbor_iface_addr_列表中删除已删除地址列表中的所有网络地址。
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now empty; apply Section 13.2 but not Section 13.3.
2. 删除L_neighbor_iface_addr_列表现在为空的所有链接元组；适用第13.2节，但不适用第13.3节。
The router MUST then update its Link Set for the MANET interface on which the HELLO message is received:
然后，路由器必须更新接收HELLO消息的MANET接口的链路集：
1. Find all Link Tuples (henceforth matching Link Tuples) where:
1. 查找所有链接元组（此后匹配链接元组），其中：
o L_neighbor_iface_addr_list contains one or more network addresses in the Sending Address List.
o L_neighbor_iface_addr_列表在发送地址列表中包含一个或多个网络地址。
2. If there is more than one matching Link Tuple, then remove them all; apply Section 13.2 but not Section 13.3.
2. 如果有多个匹配的链接元组，则将其全部删除；适用第13.2节，但不适用第13.3节。
3. If no matching Link Tuples remain, then create a new matching Link Tuple with:
3. 如果没有剩余的匹配链接元组，则使用以下内容创建新的匹配链接元组：
o L_neighbor_iface_addr_list := empty;
o L_neighbor_iface_addr_list:=空；
o L_HEARD_time := EXPIRED;
o L__时间：=过期；
o L_SYM_time := EXPIRED;
o L_SYM_时间：=过期；
o L_quality := INITIAL_QUALITY;
o L_质量：=初始_质量；
o L_pending := INITIAL_PENDING;
o L_pending:=初始_pending；
o L_lost := false;
o L_lost:=假；
o L_time := current time + validity time.
o L_时间：=当前时间+有效时间。
4. The matching Link Tuple, existing or new, is then modified as follows:
4. 然后，匹配的链接元组（现有或新的）修改如下：
1. If the router finds any network address (henceforth receiving address) in the Receiving Address List in an Address Block in the HELLO message, then the Link Tuple is modified as follows:
1. 如果路由器在HELLO消息的地址块中的接收地址列表中找到任何网络地址（此后为接收地址），则链路元组修改如下：
1. If any receiving address in the HELLO message is associated with an Address Block TLV with Type = LINK_STATUS and with Value = HEARD or Value = SYMMETRIC, then:
1. 如果HELLO消息中的任何接收地址与类型为LINK_STATUS且值为hard或值为SYMMETRIC的地址块TLV相关联，则：
o L_SYM_time := current time + validity time.
o L_SYM_时间：=当前时间+有效时间。
2. Otherwise, if any receiving address in the HELLO message is associated with an Address Block TLV with Type = LINK_STATUS and Value = LOST, then:
2. 否则，如果HELLO消息中的任何接收地址与类型为LINK_STATUS且值为LOST的地址块TLV相关联，则：
1. if L_SYM_time has not expired, then:
1. 如果L_SYM_时间未过期，则：
1. L_SYM_time := EXPIRED.
1. L_SYM_时间：=过期。
2. if L_status = HEARD, then:
2. 如果L_状态=听到，则：
o L_time := current time + L_HOLD_TIME.
o L_时间：=当前时间+L_保持时间。
2. L_neighbor_iface_addr_list := Sending Address List.
2. L_neighbor_iface_addr_list:=发送地址列表。
3. L_HEARD_time := max(current time + validity time, L_SYM_time).
3. L_时间：=最大值（当前时间+有效时间，L_符号时间）。
4. If L_status = PENDING, then:
4. 如果L_状态=挂起，则：
o L_time := max(L_time, L_HEARD_time).
o L_时间：=最大值（L_时间，L_时间）。
5. Otherwise, if L_status = HEARD or L_status = SYMMETRIC, then:
5. 否则，如果L_status=hear或L_status=SYMMETRIC，则：
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
o L_时间：=最大值（L_时间、L_听到的时间+L_保持时间）。
On receiving a HELLO message, a router MUST update its 2-Hop Set for the MANET interface on which the HELLO message was received:
在接收HELLO消息时，路由器必须更新接收HELLO消息的MANET接口的2-Hop集：
1. Remove all network addresses in the Removed Address List from the N2_neighbor_iface_addr_list of all 2-Hop Tuples.
1. 从所有2跳元组的N2_neighbor_iface_addr_列表中删除已删除地址列表中的所有网络地址。
2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending Address List, has L_status = SYMMETRIC, then:
2. 如果其L_邻居\u iface\u addr\u list=发送地址列表的链接元组的L_状态=对称，则：
1. For each network address (henceforth 2-hop address) in an Address Block of the HELLO message, where:
1. 对于HELLO消息地址块中的每个网络地址（此后为2跳地址），其中：
o a 2-hop address is not contained in the Neighbor Address List;
o 邻居地址列表中不包含2跳地址；
o a 2-hop address is not contained in any I_local_iface_addr_list; AND
o 任何I_local_iface_addr_列表中都不包含两跳地址；和
o a 2-hop address != any IR_local_iface_addr
o 两跳地址！=任何本地地址
perform the following processing:
执行以下处理：
1. If the 2-hop address has an associated Address Block TLV with:
1. 如果2-hop地址与地址块TLV关联，则：
o Type = LINK_STATUS and Value = SYMMETRIC; OR
o 类型=链路状态，值=对称；或
o Type = OTHER_NEIGHB and Value = SYMMETRIC,
o 类型=其他类型，值=对称，
then, if there is no 2-Hop Tuple such that:
然后，如果不存在2跳元组，则：
o N2_neighbor_iface_addr_list contains one or more network addresses in the Sending Address List; AND
o N2_邻居_iface_addr_列表在发送地址列表中包含一个或多个网络地址；和
o N2_2hop_addr = 2-hop address,
o N2跃点地址=2跃点地址，
then create a 2-Hop Neighbor Tuple with:
然后使用以下内容创建一个2跳邻居元组：
o N2_2hop_addr := 2-hop address.
o N2跃点地址：=2跃点地址。
This 2-Hop Tuple (existing or new) is then modified as follows:
然后对该2跳元组（现有元组或新元组）进行如下修改：
o N2_neighbor_iface_addr_list := Sending Address List;
o N2\u邻居\u地址列表：=发送地址列表；
o N2_time := current time + validity time.
o N2_时间：=当前时间+有效时间。
2. Otherwise, if a 2-hop address has an Address Block TLV with:
2. 否则，如果2跳地址具有地址块TLV，则：
o Type = LINK_STATUS and Value = LOST or Value = HEARD; OR
o 类型=链路\状态和值=丢失或值=听到；或
o Type = OTHER_NEIGHB and Value = LOST;
o 类型=其他_NEIGHB，值=丢失；
then remove all 2-Hop Tuples with:
然后使用以下命令删除所有2跳元组：
o N2_neighbor_iface_addr_list containing one or more network addresses in the Sending Address List; AND
o N2_邻居_iface_addr_列表，包含发送地址列表中的一个或多个网络地址；和
o N2_2hop_addr = 2-hop address.
o N2跃点地址=2跃点地址。
The Interface and Neighbor Information Bases MUST be changed when certain events occur. These events may result from HELLO message processing or may be otherwise generated (e.g., expiry of timers or link quality changes).
当某些事件发生时，必须更改接口和邻居信息库。这些事件可能由HELLO消息处理导致，也可能由其他方式生成（例如，计时器过期或链路质量更改）。
Events that cause changes in the Information Bases are:
导致信息库发生变化的事件包括：
o A Link Tuple's L_status changes to SYMMETRIC. In this case, the actions specified in Section 13.1 are performed.
o 链接元组的L_状态更改为对称。在这种情况下，执行第13.1节中规定的操作。
o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple is removed. In this case, the actions specified in Section 13.2 are performed.
o 链接元组的L_状态将从“对称”更改，或者链接元组将被删除。在这种情况下，执行第13.2节中规定的操作。
o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. In this case, the actions specified in Section 13.3 are performed.
o 链接元组的L_时间过期，或链接元组被删除。在这种情况下，执行第13.3节中规定的操作。
o Local interface network address changes. In this case, the actions specified in Section 9 are performed.
o 本地接口网络地址更改。在这种情况下，执行第9节中规定的操作。
o Link quality changes. In this case, the actions specified in Section 14 are performed.
o 链接质量变化。在这种情况下，执行第14节中规定的操作。
If a Link Tuple is removed, or if L_status changes from SYMMETRIC and L_HEARD_time expires, then the actions specified in Section 13.2 MUST be performed before the actions specified in Section 13.3 are performed for that Link Tuple.
如果一个链接元组被删除，或者如果L_状态从SYMMETRIC变为SYMMETRIC，并且L_HEARD_time过期，那么在对该链接元组执行第13.3节中指定的操作之前，必须执行第13.2节中指定的操作。
A router MAY report updated information in response to any of these changes in HELLO message(s), subject to the constraints in Section 11.
路由器可根据第11节中的约束，报告更新信息以响应HELLO消息中的任何这些更改。
A router that transmits HELLO messages in response to such changes SHOULD transmit a HELLO message:
为响应此类更改而发送HELLO消息的路由器应发送HELLO消息：
o On all MANET interfaces, if the Neighbor Set changes such as to indicate the change in symmetry of any 1-hop neighbors (including addition or removal of symmetric 1-hop neighbors).
o 在所有MANET接口上，如果邻居集发生变化，例如指示任何1-hop邻居的对称性变化（包括添加或删除对称1-hop邻居）。
o Otherwise, on all those MANET interfaces whose Link Set changes such as to indicate a change in L_status of any 1-hop neighbors (including the addition or removal of any 1-hop neighbors, other than those considered pending).
o 否则，在其链路集发生变化的所有MANET接口上，例如，指示任何1跳邻居的L_状态发生变化（包括添加或删除任何1跳邻居，被视为待定的邻居除外）。
If, for any Link Tuple that does not have L_status = SYMMETRIC:
如果，对于没有L_状态=对称的任何链接元组：
o L_status changes to SYMMETRIC;
o L_状态变为对称状态；
then:
然后：
1. For the Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list, set:
1. 对于其N_Neighbor_addr_列表包含L_Neighbor_iface_addr_列表的邻居元组，设置：
o N_symmetric := true.
o N_对称：=真。
2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is contained in that N_neighbor_addr_list.
2. 删除其NL_Neighbor_addr包含在N_Neighbor_addr_列表中的所有丢失的邻居元组。
This includes any newly created Link Tuples whose status is immediately updated such that L_status = SYMMETRIC. (Note that in this specification, all Link Tuples are created such that their L_status is not SYMMETRIC, but a Link Tuple may be immediately updated by subsequent processing of the same HELLO message that caused the creation of the Link Tuple such that the Link Tuple's L_status changes to SYMMETRIC.)
这包括任何新创建的链接元组，其状态将立即更新，以使L_status=对称。（请注意，在本规范中，创建所有链接元组时，其L_状态都不是对称的，但可以通过后续处理导致创建链接元组的同一HELLO消息来立即更新链接元组，从而使链接元组的L_状态变为对称。）
If for any Link Tuple with L_status = SYMMETRIC:
如果对于L_状态=对称的任何链接元组：
o L_status changes to any other value; OR
o L_状态更改为任何其他值；或
o the Link Tuple is removed;
o 删除链接元组；
then:
然后：
1. All 2-Hop Tuples for the same MANET interface with:
1. 同一MANET接口的所有2跳元组具有：
o N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list;
o N2_neighbor_iface_addr_列表包含L_neighbor_iface_addr_列表中的一个或多个网络地址；
are removed.
被移除。
2. For the Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list:
2. 对于其N_Neighbor_addr_列表包含L_Neighbor_iface_addr_列表的邻居元组：
1. If there are no remaining Link Tuples for any MANET interface where:
1. 如果任何MANET接口没有剩余的链路元组，其中：
o L_neighbor_iface_addr_list is contained in N_neighbor_addr_list; AND
o L_neighbor_iface_addr_列表包含在N_neighbor_addr_列表中；和
o L_status = SYMMETRIC;
o L_状态=对称；
then modify the Neighbor Tuple by:
然后通过以下方式修改相邻元组：
1. N_symmetric := false.
1. N_对称：=假。
2. For each network address (henceforth neighbor address) in N_neighbor_addr_list, add a Lost Neighbor Tuple with:
2. 对于N_neighbor_addr_列表中的每个网络地址（此后为邻居地址），添加一个丢失的邻居元组，其中包含：
o NL_neighbor_addr := neighbor address;
o NL_neighbor_addr:=邻居地址；
o NL_time := current time + N_HOLD_TIME.
o NL_时间：=当前时间+N_保持时间。
If, for any Link Tuple:
如果，对于任何链接元组：
o L_HEARD_time expires; OR
o L______________________________；或
o the Link Tuple is removed;
o 删除链接元组；
then:
然后：
1. For the Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list, if no Link Tuples for any MANET interface remain where:
1. 对于N_Neighbor_addr_列表包含L_Neighbor_iface_addr_列表的邻居元组，如果没有任何MANET接口的链接元组保留，其中：
o L_neighbor_iface_addr_list is contained in N_neighbor_addr_list; AND
o L_neighbor_iface_addr_列表包含在N_neighbor_addr_列表中；和
o L_HEARD_time is not expired;
o L___时间未到期；
then remove the Neighbor Tuple.
然后删除邻居元组。
Link quality is a mechanism whereby a router MAY take considerations other than message exchange into account for determining when a link is and is not a candidate for being considered as HEARD or SYMMETRIC. As such, it is a "link admission" mechanism.
链路质量是一种机制，路由器可通过该机制考虑除消息交换以外的其他因素，以确定链路何时被认为是或不被认为是可听到的或对称的。因此，它是一种“链接允许”机制。
Link quality information for a link is generated (e.g., through access to signal to noise ratio, packet loss rate, or other information from the link layer) and used only locally, i.e., is not included in signaling, and routers may interoperate whether they are using the same, different, or no, link quality information. Link quality information is specified as a normalized, dimensionless figure in the interval zero to one, inclusive, a higher value indicating a better link quality.
链路的链路质量信息被生成（例如，通过访问来自链路层的信噪比、分组丢失率或其他信息），并且仅在本地使用，即，不包括在信令中，并且路由器可以互操作，无论它们使用的是相同、不同还是否的链路质量信息。链接质量信息被指定为一个标准化的、无量纲的数字，间隔为0到1（包括0到1），更高的值表示更好的链接质量。
For deployments where no link quality is used, the considerations in Section 14.1 apply. For deployments where link quality is used, the general principles of link quality usage are described in Section 14.2. Sections 14.3 and 14.4 detail link quality functioning.
对于不使用链路质量的部署，第14.1节中的注意事项适用。对于使用链路质量的部署，第14.2节描述了链路质量使用的一般原则。第14.3节和第14.4节详细说明了链路质量功能。
In order for a router to not employ link quality, the router MUST define:
为了使路由器不采用链路质量，路由器必须定义：
o INITIAL_PENDING := false;
o 初始_挂起：=假；
o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define INITIAL_QUALITY := 1).
o 初始质量>=HYST\U拒收（没有理由不定义初始质量：=1）。
To enable link quality usage, the L_quality value of a Link Tuple is used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT, to set the flags L_pending and L_lost of that Link Tuple. Based on these flags, the link status to advertise for that Link Tuple is determined as described in Section 7.1.
为了启用链接质量使用，链接元组的L_质量值与两个阈值（HYST_ACCEPT和HYST_REJECT）一起使用，以设置该链接元组的标志L_pending和L_lost。根据这些标志，如第7.1节所述，确定为该链接元组播发的链接状态。
The use of two thresholds implements link hysteresis, whereby a link that has HYST_REJECT <= L_quality < HYST_ACCEPT may be either accepted or rejected (depending on which threshold it has most recently crossed, or, if neither, on the value of parameter INITIAL_PENDING). With appropriate values of these parameters, this prevents overly rapid changes of link status.
两个阈值的使用实现了链路滞后，因此具有HYST_REJECT<=L_quality<HYST_ACCEPT的链路可以被接受或拒绝（取决于它最近跨越的阈值，或者，如果两者都没有，则取决于参数INFINAL_PENDING的值）。通过这些参数的适当值，可以防止链路状态的过快变化。
The basic principles of link quality usage are as follows:
链路质量使用的基本原则如下：
o A router does not advertise a neighbor interface in any state until L_quality is acceptable:
o 在L_质量可接受之前，路由器不会在任何状态下公布邻居接口：
o If INITIAL_PENDING = true, then the link is advertised when link L_quality >= HYST_ACCEPT.
o 如果INITIAL_PENDING=true，则当链接L_quality>=HYST_ACCEPT时，将公布该链接。
o Otherwise, the link is advertised when L_quality >= HYST_REJECT.
o 否则，当L_quality>=HYST_REJECT时，将公布链接。
A link that is not yet advertised has L_pending = true.
尚未公布的链接的L_pending=true。
o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false, indicating that the link can be advertised.
o 一旦L_quality>=HYST_ACCEPT，路由器将L_pending:=false设置，表示可以公布链路。
o A link for which L_pending = false is advertised until its L_quality drops below HYST_REJECT.
o 对于L_pending=false的链接，将进行广告，直到其L_质量下降到HYST_REJECT以下。
o If a link has L_pending = false and L_quality < HYST_REJECT, the link is LOST and is advertised as such. This link is not reconsidered as a candidate HEARD or SYMMETRIC link until L_quality >= HYST_ACCEPT.
o 如果链接的L_pending=false且L_quality<HYST_REJECT，则该链接将丢失，并作为该链接进行广告。在L_quality>=HYST_接受之前，此链接不会被重新考虑为候选或对称链接。
o A link that has an acceptable quality may be advertised as HEARD, SYMMETRIC or LOST according to the exchange of HELLO messages.
o 根据HELLO消息的交换，具有可接受质量的链接可以被广告为听到、对称或丢失。
In order that these principles can all hold, a router MUST NOT define:
为了使这些原则都适用，路由器不得定义：
o INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR
o 初始_待定=错误，初始_质量<HYST_拒收；或
o INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.
o 初始待决=真实，初始质量>=HYST\U接受。
If L_quality for a link changes, then the following actions MUST be taken:
如果链路的L_质量发生变化，则必须采取以下措施：
1. If L_quality >= HYST_ACCEPT, then the corresponding Link Tuple is modified by:
1. 如果L_quality>=HYST_ACCEPT，则通过以下方式修改相应的链接元组：
1. L_pending := false;
1. L_pending:=假；
2. L_lost := false;
2. L_lost:=假；
3. If L_status = HEARD or L_status = SYMMETRIC, then:
3. 如果L_状态=听到或L_状态=对称，则：
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
o L_时间：=最大值（L_时间、L_听到的时间+L_保持时间）。
2. If L_status != PENDING, and L_quality < HYST_REJECT, then the corresponding Link Tuple is modified by:
2. 如果L_状态！=挂起，且L_quality<HYST_REJECT，则通过以下方式修改相应的链接元组：
1. If L_lost = false, then:
1. 如果L_lost=false，则：
o L_lost := true;
o L_lost:=真；
o L_time := min(L_time, current time + L_HOLD_TIME).
o L_时间：=分钟（L_时间，当前时间+L_保持时间）。
As a result of this processing, the L_STATUS of a Link Tuple may change. In this case, the processing actions corresponding to this change, as specified in Section 13, MUST also be taken.
作为该处理的结果，链路元组的L_状态可能会改变。在这种情况下，还必须采取第13节规定的与此变更对应的处理措施。
If L_quality for a link is updated based on HELLO message reception, or on reception of a packet including a HELLO message, then L_quality MUST be updated prior to the HELLO message processing described in Section 12. (If the receipt of the HELLO message, or the packet containing it, creates the Link Tuple, then the Link Tuple MUST be created with the appropriately updated L_quality value, rather than with L_quality := INITIAL_QUALITY.)
如果链路的L_质量基于HELLO消息接收或包括HELLO消息的分组的接收而更新，则必须在第12节中描述的HELLO消息处理之前更新L_质量。（如果收到HELLO消息或包含该消息的数据包创建了链接元组，则必须使用适当更新的L_质量值而不是L_质量：=初始_质量来创建链接元组。）
A router MAY update link quality based on any information available to it. Particular cases that MAY be used include:
路由器可以根据其可用的任何信息更新链路质量。可使用的特殊情况包括：
o Information from the link layer, such as signal-to-noise ratio or packet acknowledgment reception and loss information.
o 来自链路层的信息，例如信噪比或分组确认接收和丢失信息。
o Receipt or loss of control packets. If control packets include a sequential packet sequence number, as defined in [RFC5444], then link quality can be updated when a control packet is received, whether or not it contains a HELLO message. The link quality may then, for example, be based on whether the last N out of M control packets on the link were received, or may use a "leaky integrator" tracking packet reception and loss.
o 接收或丢失控制数据包。如果控制数据包包括[RFC5444]中定义的顺序数据包序列号，则在接收到控制数据包时，无论其是否包含HELLO消息，都可以更新链路质量。然后，例如，链路质量可以基于是否接收到链路上M个控制分组中的最后N个，或者可以使用跟踪分组接收和丢失的“泄漏积分器”。
o Receipt or loss of HELLO messages. If the maximum interval between HELLO messages is known (such as by inclusion in HELLO messages of a Message TLV with Type := INTERVAL_TIME, as defined in [RFC5497]), then the loss of HELLO messages can be determined without the need to receive a later HELLO message. Note that if this case is combined with the previous case, then care must be taken to avoid "double counting" a lost HELLO message in a lost packet.
o 收到或丢失HELLO消息。如果已知HELLO消息之间的最大间隔（例如，通过在HELLO消息中包含类型为：=interval_TIME的消息TLV，如[RFC5497]中所定义），则可以确定HELLO消息的丢失，而无需接收以后的HELLO消息。注意，如果本例与前一例合并，则必须注意避免在丢失的数据包中“重复计算”丢失的HELLO消息。
This section lists the parameters and constants used in the specification of the protocol, and proposed values of each that MAY be used when a single value of each is used.
本节列出了协议规范中使用的参数和常数，以及使用每个参数的单个值时可能使用的每个参数和常数的建议值。
o HELLO_INTERVAL := 2 seconds
o HELLO_间隔：=2秒
o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
o HELLO\u MIN\u INTERVAL:=HELLO\u INTERVAL/4
o REFRESH_INTERVAL := HELLO_INTERVAL
o 刷新间隔：=你好间隔
o H_HOLD_TIME := 3 x REFRESH_INTERVAL
o H_保持时间：=3 x刷新间隔
o L_HOLD_TIME := H_HOLD_TIME
o L_保持时间：=H_保持时间
o N_HOLD_TIME := L_HOLD_TIME
o N_保持时间：=L_保持时间
o I_HOLD_TIME := N_HOLD_TIME
o I_HOLD_TIME:=N_HOLD_TIME
If link quality is changed, then parameter values will depend on the link quality process. If link quality is not changed, then:
如果更改了链接质量，则参数值将取决于链接质量过程。如果链接质量没有改变，则：
o HYST_ACCEPT := 1
o HYST_验收：=1
o HYST_REJECT := 0
o HYST_拒绝：=0
o INITIAL_QUALITY := 1
o 初始质量：=1
o INITIAL_PENDING := false
o 初始_挂起：=false
o HP_MAXJITTER := HELLO_INTERVAL/4
o HP\u MAXJITTER:=你好\u间隔/4
o HT_MAXJITTER := HP_MAXJITTER
o HT\u MAXJITTER:=HP\u MAXJITTER
o C := 1/1024 second
o C:=1/1024秒
Other protocols, such as MANET routing protocols, that use neighborhood discovery, may need to interact with this protocol. This protocol is designed to permit such interactions, in particular:
使用邻域发现的其他协议（如MANET路由协议）可能需要与该协议交互。本协议旨在允许此类交互，特别是：
o Through accessing, and possibly extending, the information in the Local Information Base (Section 6), the Interface Information Base (Section 7), and the Neighbor Information Base (Section 8). These Information Bases record the interface configuration of the router, as well as the local connectivity, up to two hops away. All updates to the elements specified in this document are subject to the constraints specified in Appendix B.
o 通过访问并可能扩展本地信息库（第6节）、接口信息库（第7节）和邻居信息库（第8节）中的信息。这些信息库记录路由器的接口配置以及本地连接，最多可记录两个跃点。本文件中规定的要素的所有更新均受附录B中规定的约束。
o Through accessing an outgoing HELLO message prior to it being transmitted over any MANET interface, and to add information (e.g., TLVs) as specified in [RFC5444]. This may, for example, be to allow a security protocol, as suggested in Section 17, to add a TLV containing a cryptographic signature to the message, or be to
o 按照[RFC5444]中的规定，通过在通过任何MANET接口传输前访问传出HELLO消息，并添加信息（例如TLV）。例如，这可以是允许安全协议（如第17节中所建议的）将包含加密签名的TLV添加到消息中，或者
allow inserting relay selection information into a HELLO message by way of adding a TLV to an outgoing HELLO message prior to it being transmitted.
允许在发送HELLO消息之前，通过向传出HELLO消息添加TLV，将中继选择信息插入HELLO消息。
o Through accessing an incoming HELLO message, and potentially discarding it prior to processing by this protocol. This may, for example, allow a security protocol as suggested in Section 17 to perform verification of HELLO message signatures and prevent processing of unverifiable HELLO messages by this protocol.
o 通过访问传入的HELLO消息，并可能在使用此协议处理之前丢弃它。例如，这可以允许第17节中建议的安全协议执行HELLO消息签名的验证，并防止通过该协议处理无法验证的HELLO消息。
o Through accessing an incoming HELLO message after it has been completely processed by this protocol. This may, in particular, allow a protocol that has added information, such as relay selection information by way of inclusion of appropriate TLVs, access to such information after appropriate updates have been recorded in the Information Bases in this protocol.
o 通过访问传入的HELLO消息，在该消息被此协议完全处理之后。这尤其允许添加了信息（例如通过包括适当的tlv的中继选择信息）的协议在该协议的信息库中记录了适当的更新之后访问该信息。
o Through requesting that a HELLO message be generated at a specific time. In that case, HELLO message generation MUST still respect the constraints in Appendix B.
o 通过请求在特定时间生成HELLO消息。在这种情况下，HELLO消息生成仍必须遵守附录B中的约束。
Address objects in HELLO messages are processed according to their associated Address Block TLVs. All such address objects are to be processed according to this specification are associated with Address Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS (and type extension zero). Address objects not associated with an Address Block TLV of any of these Types are therefore not processed by the protocol described in this specification.
HELLO消息中的地址对象根据其关联的地址块TLV进行处理。所有这些地址对象都将根据本规范进行处理，它们与类型为LOCAL_IF、OTHER_NEIGHB或LINK_STATUS（和类型扩展零）的地址块tlv相关联。因此，与这些类型的地址块TLV不关联的地址对象不由本规范中描述的协议处理。
A protocol, such as a MANET routing protocol, interacting with this protocol may need to add information to HELLO messages. This may be in the form of associating TLVs (of Type other than LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS) to address objects already included by this specification.
与该协议交互的协议（如MANET路由协议）可能需要向HELLO消息添加信息。这可能是通过将TLV（除LOCAL_IF、other_NEIGHB或LINK_状态外的类型）与本规范中已包含的对象关联的形式。
A protocol, such as a MANET routing protocol, interacting with this protocol may also add information to HELLO messages by inserting address objects not already included by this specification. Such address objects are in the following called "inserted addresses". These inserted addresses may added to Address Blocks already present by virtue of the HELLO message generation in this specification, or may appear in new Address Blocks. In both cases, the following MUST be observed:
与该协议交互的协议（例如MANET路由协议）也可以通过插入本规范中尚未包含的地址对象来向HELLO消息添加信息。这样的地址对象在下面称为“插入地址”。这些插入的地址可以添加到通过本规范中的HELLO消息生成而已经存在的地址块中，或者可以出现在新的地址块中。在这两种情况下，必须遵守以下规定：
o An inserted address MUST NOT be associated with an Address Block TLV of Type LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS. Consequently, the processing in this specification will ignore such address objects.
o An inserted address MUST NOT be associated with an Address Block TLV of Type LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS. Consequently, the processing in this specification will ignore such address objects.translate error, please retry
o Each inserted address MUST be associated with an Address Block TLV, to be defined by the specification of the protocol inserting the address object. In this way, all addresses present in a HELLO message are associated with an Address Block TLV defining their semantics.
o 每个插入的地址必须与地址块TLV关联，该地址块TLV由插入地址对象的协议规范定义。这样，HELLO消息中的所有地址都与定义其语义的地址块TLV相关联。
Informally speaking, Address Block TLVs define the semantics of address objects in an Address Block. If an address object in an Address Block does not have any Address Block TLVs associated, that address object has no semantics. Consequently, all protocols using the protocol defined in this specification MUST respect the following:
非正式地说，地址块TLV定义地址块中地址对象的语义。如果地址块中的地址对象没有任何关联的地址块TLV，则该地址对象没有语义。因此，使用本规范中定义的协议的所有协议必须遵守以下规定：
o An address object in an Address Block, which is not associated with any Address Block TLV, MUST be silently ignored; the mere presence of an address object without an associated Address Block TLV in a HELLO message MUST NOT cause any processing.
o 地址块中未与任何地址块TLV关联的地址对象必须被静默忽略；HELLO消息中仅存在一个地址对象而没有关联的地址块TLV，不得引起任何处理。
A protocol interacting with this protocol MAY also add an originator address to HELLO messages, as specified in [RFC5444]. Such an originator address MUST be unique to the originating router, it MAY be a local interface address of the router. It SHOULD be used consistently, but SHOULD NOT be constrained in any other way.
如[RFC5444]中所述，与该协议交互的协议还可以向HELLO消息添加发起者地址。这种发端地址必须是发端路由器的唯一地址，它可能是路由器的本地接口地址。应始终如一地使用，但不应以任何其他方式加以限制。
Strict adherence to these points will enable unambiguous coexistence of future "extensions" to HELLO messages.
严格遵守这些要点将使HELLO消息的未来“扩展”能够明确共存。
In some cases, a protocol interacting with the protocol defined in this specification, may need to recognize which HELLO messages to process and which HELLO messages to discard. It is the responsibility of that protocol to ensure that such messages are suitably identifiable, e.g., through inclusion of a Message TLV or through recognizing an administrative configuration (such as address ranges). Note that such a protocol interacting with this protocol MAY specify such interaction by recognizing an additional reason for discarding a message. As suggested in Section 17 this might, for example, be a security protocol discarding a message that does not carry a Message TLV containing a cryptographic signature.
在某些情况下，与本规范中定义的协议交互的协议可能需要识别要处理的HELLO消息和要丢弃的HELLO消息。该协议负责确保此类消息具有适当的可识别性，例如，通过包含消息TLV或通过识别管理配置（如地址范围）。注意，与该协议交互的这样的协议可以通过识别丢弃消息的额外原因来指定这样的交互。例如，如第17节所述，这可能是一种安全协议，用于丢弃不携带包含加密签名的消息TLV的消息。
The objective of this protocol is to allow each router in the network to acquire information describing its 1-hop neighborhood and symmetric 2-hop neighborhood. This is acquired through HELLO message exchange between neighboring routers. This information is made available through the Interface Information Bases and Neighbor Information Base, describing the router's 1-hop neighborhood and symmetric 2-hop neighborhood.
该协议的目标是允许网络中的每个路由器获取描述其1跳邻居和对称2跳邻居的信息。这是通过相邻路由器之间的HELLO消息交换获得的。该信息通过接口信息库和邻居信息库提供，描述路由器的1跳邻居和对称2跳邻居。
Under normal circumstances, the information recorded in these Information Bases is correct, i.e., corresponds to the actual network topology, apart from any changes that have not (yet) been tracked by the HELLO message exchanges.
在正常情况下，这些信息库中记录的信息是正确的，即，除了HELLO消息交换尚未（尚未）跟踪的任何更改外，与实际网络拓扑相对应。
If a router for some reason, whether malice or malfunction, transmits invalid HELLO messages, incorrect information may be recorded in other routers' Information Bases. This protocol specification does, however, prevent inconsistent information from being included in the Information Bases through the specified processing, which maintains the constraints in Appendix B. The exact consequence of information inexactness depends on the use of these Information Bases, and SHOULD therefore be reflected in the specification of protocols that use information provided by this neighborhood discovery protocol.
如果一个路由器出于某种原因，无论是恶意还是故障，发送了无效的HELLO消息，则不正确的信息可能会记录在其他路由器的信息库中。然而，本协议规范通过规定的处理防止不一致的信息被包括在信息库中，这保持了附录B中的约束。信息不准确的确切后果取决于这些信息库的使用，因此，应该反映在使用该邻域发现协议提供的信息的协议规范中。
This section, therefore, firstly outlines the ways in which correctly formed, but still invalid, HELLO messages may appear, in Section 17.1.
因此，本节首先概述了第17.1节中正确格式但仍然无效的HELLO消息的显示方式。
Injection of invalid HELLO messages into a network may be prevented in a number of ways. If, for example, a network is deployed in a site to which access is strictly regulated, so that physical access and proximity to the network is prevented, then further security mechanisms to protect against malicious routers injecting invalid HELLO messages may not be required. Similarly, if the link layer over which the network is formed provides appropriate confidentiality, authentication, and integrity, then this may, for a given deployment, suffice to appropriately protect against disclosure of information to an eavesdropper, and against a malicious router injecting invalid HELLO messages. In the latter case, the link layer would discard frames that fail the link-layer checks, without attempting to deliver such frames to IP. Finally, certain usage may be of a nature where disruption of service is of no consequence, or at least not of sufficient consequence to warrant deployment of additional security mechanisms.
可以通过多种方式防止向网络中注入无效HELLO消息。例如，如果网络部署在访问受到严格监管的站点中，从而阻止物理访问和接近网络，则可能不需要进一步的安全机制来防止恶意路由器注入无效HELLO消息。类似地，如果在其上形成网络的链路层提供适当的机密性、认证和完整性，那么对于给定的部署，这可能足以适当地防止信息泄露给窃听者，以及防止恶意路由器注入无效HELLO消息。在后一种情况下，链路层将丢弃未通过链路层检查的帧，而不尝试将此类帧传送到IP。最后，某些用途的性质可能是服务中断没有后果，或者至少没有足够的后果来保证部署额外的安全机制。
A further point to stress, and which follows from the discussions above is, that it will not be the case that "one size security fits all". Different deployments may have different requirements. For example, in a deployment of a low-value sensor network, authentication using a simple message authentication code and shared symmetric keys may suffice, while anything beyond that may require too many computational resources to be viable. Conversely, in, for example, a community network, verifying not only that the originator of a HELLO message "has the right key" but also the precise identity of the originator may be required to be proved, and computational resources may be available to make such a requirement feasible.
从上述讨论中得出的另一点需要强调的是，“一刀切的安全”并非适用于所有人。不同的部署可能有不同的要求。例如，在低值传感器网络的部署中，使用简单的消息认证码和共享对称密钥的认证可能就足够了，而超出此范围的任何内容都可能需要太多的计算资源才可行。相反，例如，在社区网络中，可能需要证明不仅验证HELLO消息的发端人“具有正确的密钥”，而且验证发端人的准确身份，并且可以使用计算资源来实现这种要求。
Section 17.2, therefore, does not specify a single "one-size-fits-all" mechanism, but rather details how the security suggestions in [RFC5444] are considered for applicability within the context of this protocol, and with the purpose of aiding deployment-specific security mechanisms to be developed.
因此，第17.2节并未规定单一的“一刀切”机制，而是详细说明了如何考虑[RFC5444]中的安全建议，以便在本协议的上下文中适用，并帮助开发特定于部署的安全机制。
A correctly formed, but still invalid, HELLO message may take any of the following forms. Note that a present or absent address object in an Address Block, does not by itself cause a problem. It is the presence, absence, or incorrectness of associated LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Address Block TLVs that causes problems.
格式正确但仍然无效的HELLO消息可以采用以下任何形式。请注意，地址块中存在或不存在的地址对象本身不会导致问题。导致问题的是相关本地\u IF、链路\u状态和其他\u NEIGHB地址块TLV的存在、缺失或不正确。
A router may provide false information about its own identity:
路由器可能提供有关其自身身份的错误信息：
o The HELLO message may contain address objects with an associated LOCAL_IF Address Block TLV that do not correspond to addresses of interfaces of the router transmitting the HELLO message.
o HELLO消息可以包含具有相关联的本地_IF地址块TLV的地址对象，该地址块TLV不对应于发送HELLO消息的路由器的接口的地址。
o The HELLO message may omit network addresses, or their associated LOCAL_IF Address Block TLV, of interfaces of the router transmitting the HELLO message (other than the allowed omission of the only local interface network address of the MANET interface over which the HELLO message is transmitted, if that is the case).
o HELLO消息可以省略发送HELLO消息的路由器的接口的网络地址或其相关联的本地地址块TLV（如果是这种情况，则允许省略发送HELLO消息的MANET接口的唯一本地接口网络地址除外）。
o The HELLO message may incorrectly specify the LOCAL_IF Address Block TLV Value associated with one or more local interface network addresses, indicating incorrectly whether they are associated with the MANET interface over which the HELLO message is transmitted.
o HELLO消息可能错误地指定与一个或多个本地接口网络地址相关联的本地_IF地址块TLV值，从而错误地指示它们是否与发送HELLO消息的MANET接口相关联。
A router may provide false information about the identity of other routers:
路由器可能会提供有关其他路由器身份的错误信息：
o A present LINK_STATUS Address Block TLV may, incorrectly, identify a network address as being of a MANET interface that is or was heard on the MANET interface over which the HELLO message is transmitted.
o 当前链路u状态地址块TLV可能错误地将网络地址识别为在其上传输HELLO消息的MANET接口上听到或听到的MANET接口的网络地址。
o A consistently absent LINK_STATUS Address Block TLV may, incorrectly, fail to identify a network address as being of a MANET interface that is or was heard on the MANET interface over which the HELLO message is transmitted.
o 持续缺失的链路_状态地址块TLV可能错误地将网络地址识别为MANET接口的网络地址，该MANET接口正在或曾经在传送HELLO消息的MANET接口上听到。
o A present OTHER_NEIGHB Address Block TLV may, incorrectly, identify a network address as being of a router that is or was in the sending router's symmetric 1-hop neighborhood.
o 当前其他相邻地址块TLV可能错误地将网络地址识别为处于或曾经处于发送路由器的对称1跳邻居中的路由器的网络地址。
o A consistently absent OTHER_NEIGHB Address Block TLV may, incorrectly, fail to identify a network address as being of a router that is or was in the sending router's symmetric 1-hop neighborhood.
o 始终不存在的其他相邻地址块TLV可能会错误地将网络地址标识为发送路由器的对称1跳邻居中的路由器的地址。
o The Value of a LINK_STATUS Address Block TLV may incorrectly indicate the status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop neighbor.
o 链路状态地址块TLV的值可能错误地指示来自1跳邻居的链路的状态（丢失、对称或听到）。
o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.
o 其他_NEIGHB地址块TLV的值可能错误地指示对称1跳邻居的状态（丢失或对称）。
The security suggestions in [RFC5444] regarding inclusion of a cryptographic signature in a Message TLV or a Packet TLV can be applied to this protocol. Failure to verify either form of cryptographic signature should cause a HELLO message to be rejected without being processed.
[RFC5444]中关于在消息TLV或数据包TLV中包含加密签名的安全建议可应用于该协议。未能验证任何一种形式的加密签名都会导致HELLO消息被拒绝而不被处理。
The following simplification of the suggestions for end-to-end authentication for integrity in [RFC5444] may be applied to HELLO messages:
[RFC5444]中完整性端到端认证建议的以下简化可应用于HELLO消息：
o As the Message Header fields <msg-hop-count> and <msg-hop-limit> are either omitted or will always have the values 0 and 1, respectively, an end to end cryptographic signature can be calculated based on the entire HELLO message, including its unmodified Message Header.
o 由于消息头字段<msg-hop-count>和<msg-hop-limit>被省略或始终分别具有值0和1，因此可以基于整个HELLO消息（包括其未修改的消息头）计算端到端加密签名。
The security mechanisms suggested in [RFC5444] with respect to confidentiality can be directly applied to this protocol.
[RFC5444]中建议的保密性安全机制可直接应用于本协议。
This specification defines one Message Type, which has been allocated from the "Message Types" registry of [RFC5444], and three Address Block TLV Types, which have been allocated from the "Address Block TLV Types" registry of [RFC5444].
本规范定义了一种从[RFC5444]的“消息类型”注册表分配的消息类型，以及三种从[RFC5444]的“地址块TLV类型”注册表分配的地址块TLV类型。
For the registries where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444].
对于需要专家审查的登记处，指定专家应考虑[RFC5444]规定的一般性建议。
This specification defines one Message Type, which has been allocated from the 0-223 range of the "Message Types" namespace defined in [RFC5444], as specified in Table 3.
本规范定义了一种消息类型，它是从[RFC5444]中定义的“消息类型”命名空间的0-223范围中分配的，如表3所示。
+------+-------------------------+
| Type | Description |
+------+-------------------------+
| 0 | HELLO : Local signaling |
+------+-------------------------+
+------+-------------------------+
| Type | Description |
+------+-------------------------+
| 0 | HELLO : Local signaling |
+------+-------------------------+
Table 3: Message Type Assignment
表3：消息类型分配
IANA has created a registry for Message-Type-specific Message TLVs for HELLO messages, in accordance with Section 6.2.1 of [RFC5444], and with initial assignments and allocation policies as specified in Table 4.
IANA已根据[RFC5444]第6.2.1节为HELLO消息的消息类型特定消息TLV创建了一个注册表，初始分配和分配策略如表4所示。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 4: HELLO Message-Type-specific Message TLV Types
表4：HELLO消息类型特定的消息TLV类型
IANA has created a registry for Message-Type-specific Address Block TLVs for HELLO messages, in accordance with Section 6.2.1 of [RFC5444], and with initial assignments and allocation policies as specified in Table 5.
IANA已根据[RFC5444]第6.2.1节的规定，按照表5中规定的初始分配和分配策略，为HELLO消息的消息类型特定地址块TLV创建了一个注册表。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 5: HELLO Message-Type-specific Address Block TLV Types
表5：HELLO消息类型特定的地址块TLV类型
This specification defines three Address Block TLV Types, which have been allocated from the "Address Block TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 0-127 range for these types. Three new type extension registries have been created, with assignments as specified in Tables 6, 7, and 8. Specifications of these Address Block TLVs are in Section 10.1.1, with Value Constants defined in Section 18.5.
本规范定义了三种地址块TLV类型，它们是从[RFC5444]中定义的“地址块TLV类型”命名空间分配的。IANA为这些类型进行了0-127范围的分配。创建了三个新的类型扩展注册中心，其分配如表6、7和8所示。这些地址块TLV的规范见第10.1.1节，值常量见第18.5节。
+----------+------+-----------+------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+----------+------+-----------+------------------------+------------+
| LOCAL_IF | 2 | 0 | Specifies that the | |
| | | | network address is | |
| | | | associated with this | |
| | | | local interface of the | |
| | | | sending router | |
| | | | (THIS_IF = 0) or | |
| | | | another local | |
| | | | interface of the | |
| | | | sending router | |
| | | | (OTHER_IF = 1) | |
| LOCAL_IF | 2 | 1-255 | Unassigned | Expert |
| | | | | Review |
+----------+------+-----------+------------------------+------------+
+----------+------+-----------+------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+----------+------+-----------+------------------------+------------+
| LOCAL_IF | 2 | 0 | Specifies that the | |
| | | | network address is | |
| | | | associated with this | |
| | | | local interface of the | |
| | | | sending router | |
| | | | (THIS_IF = 0) or | |
| | | | another local | |
| | | | interface of the | |
| | | | sending router | |
| | | | (OTHER_IF = 1) | |
| LOCAL_IF | 2 | 1-255 | Unassigned | Expert |
| | | | | Review |
+----------+------+-----------+------------------------+------------+
Table 6: Address Block TLV Type Assignment: LOCAL_IF
表6：地址块TLV类型分配：本地
+-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+-------------+------+-----------+---------------------+------------+
| LINK_STATUS | 3 | 0 | Specifies the | |
| | | | status of the link | |
| | | | from the indicated | |
| | | | network address | |
| | | | (LOST = 0, | |
| | | | SYMMETRIC = 1, or | |
| | | | HEARD = 2) | |
| LINK_STATUS | 3 | 1-255 | Unassigned | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
+-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+-------------+------+-----------+---------------------+------------+
| LINK_STATUS | 3 | 0 | Specifies the | |
| | | | status of the link | |
| | | | from the indicated | |
| | | | network address | |
| | | | (LOST = 0, | |
| | | | SYMMETRIC = 1, or | |
| | | | HEARD = 2) | |
| LINK_STATUS | 3 | 1-255 | Unassigned | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
Table 7: Address Block TLV Type Assignment: LINK_STATUS
表7：地址块TLV类型分配：链路状态
+--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+--------------+------+-----------+--------------------+------------+
| OTHER_NEIGHB | 4 | 0 | Specifies the | |
| | | | status of the | |
| | | | relationship with | |
| | | | the router that | |
| | | | uses the indicated | |
| | | | network address on | |
| | | | one or more | |
| | | | interfaces (LOST = | |
| | | | 0, or SYMMETRIC = | |
| | | | 1) | |
| OTHER_NEIGHB | 4 | 1-255 | Unassigned | Expert |
| | | | | Review |
+--------------+------+-----------+--------------------+------------+
+--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+--------------+------+-----------+--------------------+------------+
| OTHER_NEIGHB | 4 | 0 | Specifies the | |
| | | | status of the | |
| | | | relationship with | |
| | | | the router that | |
| | | | uses the indicated | |
| | | | network address on | |
| | | | one or more | |
| | | | interfaces (LOST = | |
| | | | 0, or SYMMETRIC = | |
| | | | 1) | |
| OTHER_NEIGHB | 4 | 1-255 | Unassigned | Expert |
| | | | | Review |
+--------------+------+-----------+--------------------+------------+
Table 8: Address Block TLV Type Assignment: OTHER_NEIGHB
表8：地址块TLV类型分配：其他
Note: This information is recorded here for clarity and for use elsewhere in this specification. The information required by IANA is included in the descriptions of the Address Block TLVs allocated in Section 18.4.
注：本信息记录于此，以便于澄清，并在本规范其他地方使用。IANA要求的信息包含在第18.4节中分配的地址块TLV的描述中。
The Values that the LOCAL_IF Address Block TLV can use are the following:
本地_IF地址块TLV可以使用的值如下：
o THIS_IF := 0
o 如果：=0，则此值为0
o OTHER_IF := 1
o 如果：=1，则为其他
The Values that the LINK_STATUS Address Block TLV can use are the following:
链路状态地址块TLV可以使用的值如下：
o LOST := 0
o 丢失：=0
o SYMMETRIC := 1
o 对称：=1
o HEARD := 2
o 听说：=2
The Values that the OTHER_NEIGHB Address Block TLV can use are the following:
其他_NEIGHB地址块TLV可以使用的值如下：
o LOST := 0
o 丢失：=0
o SYMMETRIC := 1
o 对称：=1
This specification is the result of the joint efforts of the following contributors from the OLSRv2 Design Team, listed alphabetically:
本规范是以下OLSRv2设计团队贡献者共同努力的结果，按字母顺序列出：
o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>
o 布莱恩·亚当森，美国北爱尔兰共和国<adamson@itd.nrl.navy.mil>
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o 塞德里克·阿吉，法国因里亚，<塞德里克。Adjih@inria.fr>
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
o 托马斯·海德·克劳森，法国利克斯，<T。Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o 贾斯汀·迪恩，美国北爱尔兰共和国<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems ATC, UK, <chris.dearlove@baesystems.com>
o 克里斯托弗·迪尔洛夫，英国BAE系统公司空中交通管制，克里斯。dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o 菲利普·雅克，法国因里亚，<菲利普。Jacquet@inria.fr>
The authors would like to acknowledge the team behind OLSRv1, specified in RFC3626 for their contributions.
作者要感谢RFC3626中指定的OLSRv1背后的团队，感谢他们的贡献。
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews and comments on the specification and its components (listed alphabetically): Alan Cullen (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), and the entire IETF MANET working group.
作者衷心感谢以下人士对本规范及其组件（按字母顺序列出）进行了深入的技术讨论、早期审查和评论：艾伦·库伦（BAE Systems）、乌尔里希·赫伯格（LIX）、佐藤·广基（Hitachi）、乔·麦克尔（NRL）、查尔斯·珀金斯（WiChorus）、劳伦特·维诺（INRIA），以及整个IETF移动自组网工作组。
[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月。
[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月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444]Clausen，T.，Dearlove，C.，Dean，J.，和C.Adjih，“通用移动自组网（MANET）数据包/消息格式”，RFC 54442009年2月。
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009.
[RFC5497]Clausen，T.和C.Dearlove，“移动自组织网络（MANET）中代表多值时间”，RFC 54972009年3月。
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, March 2009.
[RFC5498]Chakeres，I.“移动自组网（MANET）协议的IANA分配”，RFC 5498，2009年3月。
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC2501]Corson，M.和J.Macker，“移动自组网（MANET）：路由协议性能问题和评估考虑”，RFC 2501，1999年1月。
[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月。
[RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks", RFC 5449, February 2009.
[RFC5449]Baccelli，E.，Jacquet，P.，Nguyen，D.，和T.Clausen，“专用网络的OSPF多点中继（MPR）扩展”，RFC 5449，2009年2月。
The algorithm for generating HELLO messages in Section 11 specifies which 1-hop neighbor network addresses may be included in the Address Blocks, and with which associated Address Block TLVs. These Address Block TLVs may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or both. Address Block TLVs with Type = LINK_STATUS may have three possible Values (Value = HEARD, Value = SYMMETRIC, or Value = LOST), and Address Block TLVs of TYPE = OTHER_NEIGHB may have two possible Values (Value = SYMMETRIC or Value = LOST). When both Address Block TLVs are associated with the same network address only certain combinations of these Address Block TLV Values are necessary, and are the only combinations generated by the algorithm in Section 11. These combinations are indicated in Table 9.
第11部分中用于生成HELLO消息的算法指定哪些1跳邻居网络地址可以包括在地址块中，以及与之相关联的地址块tlv。这些地址块TLV可能具有Type=LINK\u STATUS或Type=OTHER\u NEIGHB，或两者兼有。具有类型=链路\状态的地址块TLV可能有三个可能值（值=听到、值=对称或值=丢失），而类型=其他\相邻B的地址块TLV可能有两个可能值（值=对称或值=丢失）。当两个地址块TLV与相同的网络地址相关联时，仅需要这些地址块TLV值的某些组合，并且是由第11节中的算法生成的唯一组合。这些组合如表9所示。
Cells labeled with "Yes" indicate the possible combinations that are generated by the algorithm in Section 11. Cells labeled with "No" indicate combinations not generated by the algorithm in Section 11 but that are correctly parsed and interpreted by the algorithm in Section 12. The cell labeled with "No*" is actually inconsistent, it is handled by ignoring the Address Block TLV with Type = OTHER_NEIGHB, but SHOULD NOT be used.
标有“是”的单元格表示由第11节中的算法生成的可能组合。标有“否”的单元格表示并非由第11节中的算法生成的组合，而是由第12节中的算法正确解析和解释的组合。标有“No*”的单元格实际上不一致，它通过忽略Type=OTHER_NEIGHB的地址块TLV来处理，但不应使用。
+----------------+----------------+----------------+----------------+
| | Type = | Type = | Type = |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value = | Value = LOST |
| | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+
| Type = | No | Yes | Yes |
| LINK_STATUS | | | |
| (absent) | | | |
| Type = | Yes | Yes | Yes |
| LINK_STATUS, | | | |
| Value = HEARD | | | |
| Type = | Yes | No | No* |
| LINK_STATUS, | | | |
| Value = | | | |
| SYMMETRIC | | | |
| Type = | Yes | Yes | No |
| LINK_STATUS, | | | |
| Value = LOST | | | |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+
| | Type = | Type = | Type = |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value = | Value = LOST |
| | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+
| Type = | No | Yes | Yes |
| LINK_STATUS | | | |
| (absent) | | | |
| Type = | Yes | Yes | Yes |
| LINK_STATUS, | | | |
| Value = HEARD | | | |
| Type = | Yes | No | No* |
| LINK_STATUS, | | | |
| Value = | | | |
| SYMMETRIC | | | |
| Type = | Yes | Yes | No |
| LINK_STATUS, | | | |
| Value = LOST | | | |
+----------------+----------------+----------------+----------------+
Table 9: LINK_STATUS and OTHER_NEIGHB TLV Combinations
表9：链路状态和其他相邻TLV组合
Any process that updates the Local Information Base or the Neighbor Information Base MUST ensure that all constraints specified in this appendix are maintained.
任何更新本地信息库或邻居信息库的过程必须确保维护本附录中规定的所有约束。
In each Local Interface Tuple:
在每个本地接口元组中：
o I_local_iface_addr_list MUST NOT be empty.
o 本地地址列表不能为空。
o I_local_iface_addr_list MUST NOT contain any duplicated network addresses.
o I_local_iface_addr_列表不得包含任何重复的网络地址。
o If I_manet = true, then I_local_iface_addr_list MUST NOT contain any network address that overlaps any network address in the I_local_iface_addr_list of any other Local Interface Tuple with I_manet = true, unless it is known that the corresponding MANET interfaces will always communicate with separate sets of MANET interfaces on other routers.
o 如果I_manet=true，则I_local_iface_addr_列表不得包含与I_manet=true的任何其他本地接口元组的I_local_iface_addr_列表中的任何网络地址重叠的任何网络地址，除非已知相应的manet接口将始终与其他路由器上的单独manet接口集通信。
In each Removed Interface Address Tuple:
在每个删除的接口地址元组中：
o IR_local_iface_addr MUST NOT contain any network address that is in the I_local_iface_addr_list of any Local Interface Tuple.
o IR_local_iface_addr不得包含任何本地接口元组的I_local_iface_addr_列表中的任何网络地址。
o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any other Removed Interface Address Tuple.
o IR_local_iface_addr不得等于任何其他已删除接口地址元组的IR_local_iface_addr。
In each Link Tuple:
在每个链接元组中：
o L_neighbor_iface_addr_list MUST NOT be empty.
o L_neighbor_iface_addr_列表不能为空。
o L_neighbor_iface_addr_list MUST NOT contain any network address that overlaps any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o L_neighbor_iface_addr_列表不得包含与任何本地接口元组的I_local_iface_addr_列表或任何已删除接口地址元组的IR_local_iface_addr中的任何网络地址重叠的任何网络地址。
o L_neighbor_iface_addr_list MUST NOT contain any duplicated network addresses.
o L_neighbor_iface_addr_列表不得包含任何重复的网络地址。
o L_neighbor_iface_addr_list MUST NOT contain any network address which is in the L_neighbor_iface_addr_list of any other Link Tuple in the same Link Set.
o L_neighbor_iface_addr_列表不得包含同一链路集中任何其他链路元组的L_neighbor_iface_addr_列表中的任何网络地址。
o If L_HEARD_time has not expired, then there MUST be a Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list.
o 如果L_hear_time未过期，则必须存在一个邻居元组，其N_Neighbor_addr_列表包含L_Neighbor_iface_addr_列表。
o L_HEARD_time MUST NOT be greater than L_time.
o L_时间不得大于L_时间。
o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are expired).
o L_SYM_时间不得大于L_HEARD_时间（除非两者都已过期）。
o L_quality MUST NOT be less than 0 or greater than 1.
o L_质量不得小于0或大于1。
o If L_quality >= HYST_ACCEPT, then L_pending MUST be false.
o 如果L_quality>=HYST_ACCEPT，则L_pending必须为false。
o If L_quality < HYST_REJECT, then L_status MUST be PENDING or LOST.
o 如果L_quality<HYST_REJECT，则L_状态必须挂起或丢失。
o L_pending MUST NOT be set to true if it is currently false.
o 如果L_pending当前为false，则不能将其设置为true。
In each Neighbor Tuple:
在每个相邻元组中：
o N_neighbor_addr_list MUST NOT contain any network address that overlaps any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o N_neighbor_addr_列表不得包含与任何本地接口元组的I_local_iface_addr_列表或任何删除的接口地址元组的IR_local_iface_addr中的任何网络地址重叠的任何网络地址。
o N_neighbor_addr_list MUST NOT contain any duplicated network addresses.
o N_邻居地址列表不得包含任何重复的网络地址。
o N_neighbor_addr_list MUST NOT contain any network address that is in the N_neighbor_addr_list of any other Neighbor Tuple.
o N_neighbor_addr_列表不得包含任何其他邻居元组的N_neighbor_addr_列表中的任何网络地址。
o If N_symmetric is = true, then there MUST be one or more Link Tuples with:
o 如果N_symmetric=true，则必须有一个或多个链接元组：
o L_neighbor_iface_addr_list contained in N_neighbor_addr_list; AND
o N_neighbor_地址列表中包含的L_neighbor_iface_地址列表；和
o L_status = SYMMETRIC.
o L_状态=对称。
o If N_symmetric is = false, then there MUST be one or more Link Tuples with:
o 如果N_symmetric is=false，则必须有一个或多个链接元组具有：
o L_neighbor_iface_addr_list contained in N_neighbor_addr_list.
o 包含在N_邻居地址列表中的L_邻居地址列表。
All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least one such Link Tuple MUST have L_HEARD_time not expired.
所有此类链接元组不得具有L_status=SYMMETRIC。必须至少有一个这样的链接元组的L_hear_时间未过期。
In each Lost Neighbor Tuple:
在每个丢失的邻居元组中：
o NL_neighbor_addr MUST NOT overlap any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o NL_neighbor_addr不得与任何本地接口元组的I_local_iface_addr_列表中的任何网络地址重叠，也不得与任何删除的接口地址元组的IR_local_iface_addr重叠。
o NL_neighbor_addr MUST NOT equal the NL_neighbor_addr of any other Lost Neighbor Tuple.
o NL_neighbor_addr不能等于任何其他丢失邻居元组的NL_neighbor_addr。
o NL_neighbor_addr MUST NOT be in the N_neighbor_addr_list of any Neighbor Tuple with N_symmetric = true.
o NL_neighbor_addr不能位于N_symmetric=true的任何邻居元组的N_neighbor_addr_列表中。
In each 2-Hop Tuple:
在每个2跳元组中：
o There MUST be a Link Tuple associated with the same MANET interface with:
o 必须有一个链接元组与同一MANET接口关联，该接口具有：
o L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
o L_neighbor_iface_addr_list=N2_neighbor_iface_addr_list；和
o L_status = SYMMETRIC.
o L_状态=对称。
o N2_2hop_addr MUST NOT overlap any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o N2_2; hop_addr不得与任何本地接口元组的I_local_iface_addr_列表中的任何网络地址重叠，也不得与任何删除的接口地址元组的IR_local_iface_addr重叠。
o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple in the same 2-Hop Set and with the same N2_neighbor_iface_addr_list.
o N2跃点地址不得是同一2跃点集中具有相同N2跃点邻居地址列表的任何其他2跃点元组的N2跃点地址。
o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the same 2-Hop Tuple.
o N2跃点地址不得位于同一2跃点元组的N2跃点邻居地址列表中。
HELLO messages are instances of [RFC5444] messages, and this protocol supports any combination of message header options and address encodings, enabled by [RFC5444] that convey the required information. As a consequence, there is no single way to represent how all HELLO messages look. This appendix illustrates two HELLO message with similar content, the exact values included are explained in the following text.
HELLO消息是[RFC5444]消息的实例，此协议支持由[RFC5444]启用的消息头选项和地址编码的任意组合，以传递所需信息。因此，没有单一的方法来表示所有HELLO消息的外观。本附录举例说明了两条内容类似的HELLO消息，下文将解释其中包含的确切值。
The HELLO message's four bit Message Flags (MF) field has value 7 indicating that the message header contains hop limit, hop count, and message sequence number fields. Its four bit Message Address Length (MAL) field has value 3, indicating addresses in the message have a length of four octets, here being IPv4 addresses. The message is as transmitted, with a hop limit of 1 and a hop count of 0. The overall message length is 45 octets.
HELLO消息的四位消息标志（MF）字段的值为7，表示消息头包含跃点限制、跃点计数和消息序列号字段。其四位消息地址长度（MAL）字段的值为3，表示消息中的地址长度为四个八位字节，这里是IPv4地址。消息已发送，跃点限制为1，跃点计数为0。消息的总长度为45个八位字节。
The message contains a Message TLV Block with content length 8 octets containing two Message TLVs, of types VALIDITY_TIME and INTERVAL_TIME. Each uses a Message TLV with Flags octet (MTLVF) value 16, indicating that each has a Value, and each has a Value
该消息包含一个内容长度为8个八位字节的消息TLV块，其中包含两个消息TLV，类型为VALIDITY\u TIME和INTERVAL\u TIME。每一个都使用一个消息TLV，其标志八位字节（MTLVF）值为16，表示每个都有一个值，每个都有一个值
Length of 1 octet. The Values included are time codes (as defined in [RFC5497]) representing the parameters H_HOLD_TIME and HELLO_INTERVAL, respectively.
长度为1个八位组。包括的值是时间代码（如[RFC5497]中定义的），分别表示参数H_HOLD_time和HELLO_INTERVAL。
The message has a single Address Block containing 5 addresses. The Address Block Flags octet (ABF) value 128 indicates an address Head but no address Tail, and no address prefixes. The Head Length of 3 octets indicates address Mid sections of one octet each (Mid 0 to Mid 4).
消息有一个包含5个地址的地址块。地址块标志八位字节（ABF）值128表示地址头，但没有地址尾，也没有地址前缀。3个八位字节的头长表示每个八位字节的地址中间部分（中间0到中间4）。
The following Address Block TLV Block (content length 14 octets) includes two Address Block TLVs. The first is a LOCAL_IF Address Block TLV with Flags octet (ATLVF) value 80, which indicates that a single address, with index 0 (i.e., the address Head:Mid 0) is the single local interface address of this router (the one octet Value THIS_IF indicates that this address is of this interface). The second is a LINK_STATUS Address Block TLV with Flags octet (ATLVF) value 52, which specifies the link status values of all reported neighbors in a single multivalue Address Block TLV that covers the addresses with indexes 1 to 4, inclusive. The Address Block TLV Value Length of 4 octets indicates one octet per Value per address. The last four addresses thus are of neighbors, each an with associated link status: the first and second HEARD, the third SYMMETRIC, and the fourth LOST.
以下地址块TLV块（内容长度14个八位字节）包括两个地址块TLV。第一个是本地_IF地址块TLV，其标志八位字节（ATLVF）值为80，表示索引为0（即地址头：Mid 0）的单个地址是该路由器的单个本地接口地址（该_IF的一个八位字节值表示该地址属于该接口）。第二个是具有标志八位字节（ATLVF）值52的链路状态地址块TLV，它指定单个多值地址块TLV中所有报告邻居的链路状态值，该多值地址块TLV覆盖索引为1到4（包括1到4）的地址。地址块TLV值长度为4个八位字节，表示每个地址的每个值有一个八位字节。因此，最后四个地址是邻居地址，每个地址都有一个关联的链路状态：第一个和第二个被听到，第三个对称，第四个丢失。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO | MF=7 | MAL=3 | Message Length = 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit = 1 | Hop Count = 0 | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | Num Addrs = 5 | ABF = 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head Len = 3 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 4 | Address TLV Block Length = 14 | LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATLVF = 80 | Index = 0 | Value Len = 1 | THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS | ATLV = 52 | Strt Indx = 1 | Stop Indx = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 4 | HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO | MF=7 | MAL=3 | Message Length = 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit = 1 | Hop Count = 0 | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | Num Addrs = 5 | ABF = 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head Len = 3 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 4 | Address TLV Block Length = 14 | LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATLVF = 80 | Index = 0 | Value Len = 1 | THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS | ATLV = 52 | Strt Indx = 1 | Stop Indx = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 4 | HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
Note that this example is for illustrative purposes. The essential information can be conveyed, more efficiently (assuming that the local interface address will be supplied by IP, and that the INTERVAL_TIME TLV is not needed) by the 29 octets:
请注意，此示例用于说明目的。29个八位字节可以更有效地传输基本信息（假设本地接口地址将由IP提供，并且不需要间隔时间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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 1 | Mid 2 | Mid 3 | Mid 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 1 | Mid 2 | Mid 3 | Mid 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
Note that the above example assumes that H_HOLD_TIME and C have their default values of 6 seconds and 1/1024 second, and thus result in a time code of 100 (hexadecimal 64).
注意，上面的示例假设H_HOLD_TIME和C的默认值为6秒和1/1024秒，因此时间代码为100（十六进制64）。
This protocol specifies one Message Type, the HELLO message. The maximum size of a HELLO message is proportional to the size of the originating router's 1-hop neighborhood. HELLO messages MUST NOT be forwarded.
此协议指定一种消息类型，即HELLO消息。HELLO消息的最大大小与原始路由器的1跳邻居的大小成正比。HELLO消息不能被转发。
A router MUST report its 1-hop neighborhood in HELLO messages on each of its MANET interfaces at least each REFRESH_INTERVAL. This puts a lower bound on the control traffic generated by each router in the network employing this protocol.
路由器必须在其每个MANET接口上至少每个刷新间隔报告其HELLO消息中的1跳邻居。这对采用该协议的网络中的每个路由器生成的控制流量设置了一个下限。
A router MUST ensure that two successive HELLO messages sent on the same MANET interface are separated by at least HELLO_MIN_INTERVAL. (If using jitter, then this may be reduced to a mean minimum value of HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound on the control traffic generated by each router in the network employing this protocol.
路由器必须确保在同一MANET接口上发送的两个连续HELLO消息至少间隔HELLO_MIN_间隔。（如果使用抖动，那么这可能会降低到平均最小值HELLO_MIN_INTERVAL-HP_MAXJITTER/2。）因此，这会对使用此协议的网络中的每个路由器生成的控制流量设置上限。
This informative appendix illustrates the relationship between message timers and intervals. (The adjustments to this timing when using timing jitter, as defined in [RFC5148], are not shown.)
本资料性附录说明了消息计时器和间隔之间的关系。（未显示使用[RFC5148]中定义的定时抖动时对该定时的调整。）
Figure 1 illustrates a basic HELLO message schedule for a router, on a MANET interface, employing strictly periodic transmission of HELLO messages. The router transmits a HELLO message each HELLO_INTERVAL. Each HELLO message contains all 1-hop neighbor network addresses of the router that are to be reported in any such HELLO message. (The parameter REFRESH_INTERVAL, not shown, is in this example equal to the parameter HELLO_INTERVAL.)
图1说明了MANET接口上路由器的基本HELLO消息调度，使用HELLO消息的严格定期传输。路由器在每个HELLO_间隔发送HELLO消息。每个HELLO消息包含路由器的所有1跳邻居网络地址，这些地址将在任何此类HELLO消息中报告。（本例中未显示的参数REFRESH_INTERVAL等于参数HELLO_INTERVAL。）
The router includes a VALIDITY_TIME TLV in each HELLO message, encoding the parameter H_HOLD_TIME, the duration for which information received in the HELLO message should be considered valid by receiving routers. Receiving routers will, when recording the information received in the HELLO message, each use this for setting the L_HEARD_time, L_SYM_time and L_time elements of their corresponding Link Tuple, and the N2_time in the corresponding 2-Hop Tuple for each network address. Only L_time is illustrated in Figure 1.
路由器在每个HELLO消息中包括一个VALIDITY_TIME TLV，对参数H_HOLD_TIME进行编码，该参数是在HELLO消息中接收到的信息应被接收路由器视为有效的持续时间。接收路由器在记录HELLO消息中接收到的信息时，每个路由器都将使用此设置其相应链路元组的L_HEARD_time、L_SYM_time和L_time元素，以及每个网络地址的相应2跳元组中的N2_time。图1中仅显示了L_时间。
H_HOLD_TIME: |-----------------------------| ...
H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
Time: ---*---------*---------*---------*------>
Time: ---*---------*---------*---------*------>
^ ^ ^ ^
| | | |
HELLO (a, b, c, d) | | |
| | |
HELLO (a, b, c, d) | | ...
| |
HELLO (a, b, c, d) |
|
HELLO (a, b, c, d)
^ ^ ^ ^
| | | |
HELLO (a, b, c, d) | | |
| | |
HELLO (a, b, c, d) | | ...
| |
HELLO (a, b, c, d) |
|
HELLO (a, b, c, d)
L_time: |-----------------------------|
|-------------------- ...
|---------- ...
| ...
L_time: |-----------------------------|
|-------------------- ...
|---------- ...
| ...
Figure 1: HELLO Message Generation: Regular Schedule
图1：HELLO消息生成：常规计划
Figure 2 illustrates a message schedule similar to Figure 1, where the router announces its own presence more frequently by sending additional HELLO messages. HELLO messages are still sent regularly, at a reduced interval defined by a new value of HELLO_INTERVAL. However, REFRESH_INTERVAL has not been reduced. Each 1-hop neighbor network address included in these HELLO messages need be advertised only once within each REFRESH_INTERVAL. Consequently, the additional HELLO messages due to the reduced value of HELLO_INTERVAL may therefore be empty. (This is not the only allowed distribution of 1-hop neighbor network addresses, they could, for example, be sent alternately a, b and c, d.)
图2展示了一个类似于图1的消息调度，其中路由器通过发送额外的HELLO消息来更频繁地宣布自己的存在。HELLO消息仍会定期发送，发送间隔由新值HELLO_interval定义，并缩短。但是，刷新间隔并未缩短。这些HELLO消息中包含的每个1跳邻居网络地址只需在每个刷新间隔内发布一次。因此，由于HELLO_INTERVAL的值减小而产生的附加HELLO消息可能因此为空。（这不是唯一允许的1-hop邻居网络地址分布，例如，它们可以交替发送a、b和c、d。）
H_HOLD_TIME: |-----------------------------| ...
H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |---------|---------|---------| ...
REFRESH_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |----|----|----|----|----|----| ...
HELLO_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO (a, b, c, d) | | | | | |
| | | | | |
HELLO () | | | | |
| | | | |
HELLO (a, b, c, d) | | | |
| | | | ...
HELLO () | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO () |
|
HELLO (a, b, c, d)
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO (a, b, c, d) | | | | | |
| | | | | |
HELLO () | | | | |
| | | | |
HELLO (a, b, c, d) | | | |
| | | | ...
HELLO () | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO () |
|
HELLO (a, b, c, d)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 2: HELLO Message Generation: Regular Schedule with Different HELLO_INTERVAL and REFRESH_INTERVAL
图2：HELLO消息生成：具有不同HELLO\u间隔和REFRESH\u间隔的常规计划
HELLO messages may also be sent in response to events. The minimal interval between two successive HELLO message transmissions by a router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO message emission rate. Hence, for each HELLO message transmission, a router must wait at least HELLO_MIN_INTERVAL before the next HELLO message transmission. Similarly, the maximum interval between two successive HELLO message transmissions is HELLO_INTERVAL, setting a lower bound on the message transmission rate. Hence, for each HELLO message transmission, the router must ensure that the next HELLO message transmission must not wait more than HELLO_INTERVAL.
还可以发送HELLO消息以响应事件。路由器两次连续HELLO消息传输之间的最小间隔为HELLO_MIN_interval，设置HELLO消息发射率的上限。因此，对于每个HELLO消息传输，路由器必须在下一个HELLO消息传输之前至少等待HELLO_MIN_间隔。类似地，两次连续HELLO消息传输之间的最大间隔为HELLO_interval，设置消息传输速率的下限。因此，对于每个HELLO消息传输，路由器必须确保下一个HELLO消息传输的等待时间不得超过HELLO_间隔。
Figure 3 illustrates a message schedule similar to Figure 1, but with HELLO messages responding to events at maximum rate, i.e., with HELLO messages being sent each HELLO_MIN_INTERVAL. Note that when a HELLO message is sent, it is assumed that the following messages may all be scheduled at an interval of HELLO_INTERVAL, and hence each HELLO message contains all 1-hop neighbor network addresses. In each HELLO message in this example, a new 1-hop neighbor network address is added, reflecting the changes occurring since the last HELLO message was sent. HELLO messages are sent at the maximum allowed rate in order to signal these changes as rapidly as possible.
图3展示了一个类似于图1的消息调度，但是HELLO消息以最大速率响应事件，即，每个HELLO\u MIN\u间隔发送HELLO消息。注意，当发送HELLO消息时，假设以下消息都可以以HELLO_interval的间隔进行调度，因此每个HELLO消息包含所有1跳邻居网络地址。在本例中的每个HELLO消息中，添加了一个新的1跳邻居网络地址，反映自上次发送HELLO消息以来发生的更改。HELLO消息以允许的最大速率发送，以便尽快发出这些更改的信号。
H_HOLD_TIME: |-----------------------------| ...
H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (a, b) | | | |
| | | | ...
HELLO (a, b, c) | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO (a, b, c, d, e) |
|
HELLO (a, b, c, d, e, f)
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (a, b) | | | |
| | | | ...
HELLO (a, b, c) | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO (a, b, c, d, e) |
|
HELLO (a, b, c, d, e, f)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 3: HELLO Message Generation: Regular Schedule with Responsive Messages
图3：HELLO消息生成：带有响应消息的常规计划
Figure 4 shows the same example as Figure 3, but with an increased REFRESH_INTERVAL, and showing partial HELLO messages that include only the necessary network addresses.
图4显示了与图3相同的示例，但增加了刷新间隔，并显示了仅包含必要网络地址的部分HELLO消息。
H_HOLD_TIME: |-----------------------------| ...
H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |-------------------|---------- ...
|-------------------|----- ...
|-------------------| ...
|--------------- ...
|---------- ...
|----- ...
| ...
REFRESH_INTERVAL: |-------------------|---------- ...
|-------------------|----- ...
|-------------------| ...
|--------------- ...
|---------- ...
|----- ...
| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (b) | | | |
| | | | ...
HELLO (c) | | |
| | |
HELLO (a, d) | |
| |
HELLO (b, e) |
|
HELLO (c, f)
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (b) | | | |
| | | | ...
HELLO (c) | | |
| | |
HELLO (a, d) | |
| |
HELLO (b, e) |
|
HELLO (c, f)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 4: HELLO Message Generation: Regular Schedule with Responsive Messages and Different HELLO_INTERVAL and REFRESH_INTERVAL
图4：HELLO消息生成：具有响应消息和不同HELLO\u间隔和REFRESH\u间隔的常规计划
Figure 5 summarizes the overall relationship between the intervals governing HELLO message transmissions by a router.
图5总结了路由器控制HELLO消息传输的时间间隔之间的总体关系。
H_HOLD_TIME: |------------------------------------|
H_HOLD_TIME: |------------------------------------|
REFRESH_INTERVAL: |----------------|
REFRESH_INTERVAL: |----------------|
HELLO_INTERVAL: |----------|
HELLO_INTERVAL: |----------|
HELLO_MIN_INTERVAL: |---|
HELLO_MIN_INTERVAL: |---|
Time: ----------------------------------------------->
Time: ----------------------------------------------->
^ ^ ^ ^ ^
| | | | |
| | | | Time up to which
HELLO message | | | received HELLO
transmission | | | message content
| | | is valid.
| | |
| | Time before which all
| | neighbor information must
| | be transmitted in HELLO
| | messages (one or more)
| |
| Latest time for next HELLO message
| transmission
|
Earliest time for next HELLO message
transmission
^ ^ ^ ^ ^
| | | | |
| | | | Time up to which
HELLO message | | | received HELLO
transmission | | | message content
| | | is valid.
| | |
| | Time before which all
| | neighbor information must
| | be transmitted in HELLO
| | messages (one or more)
| |
| Latest time for next HELLO message
| transmission
|
Earliest time for next HELLO message
transmission
Figure 5: HELLO Message Generation Intervals
图5：HELLO消息生成间隔
Figure 6 illustrates the Link Set timers when receiving a HELLO message not including the network address of the receiving MANET interface.
图6说明了在接收不包括接收MANET接口的网络地址的HELLO消息时的链路设置计时器。
VALIDITY_TIME: |--------------------------|
VALIDITY_TIME: |--------------------------|
L_time: |--------------------------|
L_time: |--------------------------|
L_HEARD_time: |--------------------------|
L_HEARD_time: |--------------------------|
L_SYM_time: *-| (i.e., expired)
L_SYM_时间：*-|（即过期）
Time: ---*-------------------------------->
^
|
HELLO () received
Time: ---*-------------------------------->
^
|
HELLO () received
Figure 6: HELLO Message Processing: Network Address Not Present
图6：HELLO消息处理：网络地址不存在
Figure 7 illustrates the Link Set timers when, following the received HELLO message illustrated in Figure 6, a router receives a HELLO message including the network address (a) of the receiving interface with link status = HEARD (or SYM).
图7显示了当路由器在图6所示的接收到HELLO消息之后接收到包含接收接口网络地址（a）的HELLO消息（linkstatus=hear（或SYM））时的链路设置计时器。
VALIDITY_TIME: |--------------------------|
|--------------------------|
VALIDITY_TIME: |--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
L_SYM_time: *-| (i.e., expired)
L_SYM_time: |--------------------------|
L_SYM_time: *-| (i.e., expired)
L_SYM_time: |--------------------------|
Time: -*-----*--------------------------------->
^ ^
| |
HELLO () received |
|
HELLO (a:HEARD) received
Time: -*-----*--------------------------------->
^ ^
| |
HELLO () received |
|
HELLO (a:HEARD) received
Figure 7: HELLO Message Processing: Network Address Present
图7：HELLO消息处理：存在网络地址
Figure 8 illustrates the Link Set timers when, following the received HELLO messages illustrated in Figure 7, a router receives a HELLO message including the network address (a) of the receiving interface with link status = LOST.
图8说明了在图7所示的接收到HELLO消息之后，路由器接收到包含接收接口网络地址（a）的HELLO消息时的链路设置计时器，链路状态=丢失。
VALIDITY_TIME: |--------------------------|
|--------------------------|
|--------------------------|
VALIDITY_TIME: |--------------------------|
|--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
|--------------------------|
L_SYM_time: *-| (i.e., expired)
|--------------------------|
*-| (i.e., expired)
L_SYM_time: *-| (i.e., expired)
|--------------------------|
*-| (i.e., expired)
Time: -*-----*-----*--------------------------------->
^ ^ ^
| | |
HELLO () received | |
| |
HELLO (a:HEARD) received |
|
HELLO (a:LOST) received
Time: -*-----*-----*--------------------------------->
^ ^ ^
| | |
HELLO () received | |
| |
HELLO (a:HEARD) received |
|
HELLO (a:LOST) received
Figure 8: HELLO Message Processing: Network Address Lost
图8：HELLO消息处理：网络地址丢失
There are three other timing parameters that are used by a router to control HELLO message generation and processing.
路由器使用另外三个定时参数来控制HELLO消息的生成和处理。
Figure 9 illustrates the time, with duration L_HOLD_TIME, during which the appropriate network addresses of a formerly, but no longer, symmetric 1-hop neighbor, as connected by this MANET interface, are advertised as LOST using a LINK_STATUS TLV in HELLO messages on this MANET interface, thus allowing that 1-hop neighbor to update its Link Set accordingly.
图9说明了持续时间为L_HOLD_time的时间，在此期间，通过此MANET接口连接的以前但不再是对称1跳邻居的适当网络地址通过此MANET接口上的HELLO消息中的链路状态TLV宣布为丢失，因此，允许该1跳邻居相应地更新其链路集。
L_HOLD_TIME: |----------------------------|
L_HOLD_TIME: |----------------------------|
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric on this |
MANET interface |
|
Time up to which network addresses of
this neighbor connected using this MANET
interface are advertised in HELLO
messages on this MANET interface
using a LINK_STATUS TLV, Value = LOST
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric on this |
MANET interface |
|
Time up to which network addresses of
this neighbor connected using this MANET
interface are advertised in HELLO
messages on this MANET interface
using a LINK_STATUS TLV, Value = LOST
Figure 9: HELLO Message Generation: Advertisement of Formerly Symmetric 1-Hop Neighbor on This MANET Interface as Lost
图9：HELLO消息生成：此MANET接口上以前对称的1-Hop邻居的广告丢失
Figure 10 illustrates the time, with duration N_HOLD_TIME, during which all network addresses of a formerly, but no longer, symmetric 1-hop neighbor, are advertised as LOST in HELLO messages on all MANET interfaces using an OTHER_NEIGHB TLV (if not also reported using a LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to update their 2-Hop Sets accordingly.
图10说明了持续时间为N_HOLD_time的时间，在此期间，使用其他_NEIGHB TLV（如果未使用链路状态TLV报告）在所有MANET接口上的HELLO消息中将以前但不再是对称1跳邻居的所有网络地址通告为丢失因此，允许所有其他对称1跳邻居相应地更新其2跳集。
L_HOLD_TIME: |----------------------------|
L_HOLD_TIME: |----------------------------|
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric |
|
Time up to which network addresses of
this neighbor are advertised in HELLO
messages on all MANET interfaces
using an OTHER_NEIGHB TLV,
Value = LOST
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric |
|
Time up to which network addresses of
this neighbor are advertised in HELLO
messages on all MANET interfaces
using an OTHER_NEIGHB TLV,
Value = LOST
Figure 10: HELLO Message Generation: Advertisement of Formerly Symmetric 1-Hop Neighbor on Any MANET Interface as Lost
图10：HELLO消息生成：在任何MANET接口上公布以前对称的1-Hop邻居丢失
Figure 11 illustrates the time, with duration I_HOLD_TIME, during which a formerly, but no longer, used local interface network address is excluded from being considered as a 2-hop neighbor network address (in order that a router is not recorded as its own 2-hop neighbor during that period).
图11说明了持续时间为I_HOLD_time的时间，在此期间，以前使用但不再使用的本地接口网络地址被排除在2跳邻居网络地址之外（以便路由器在此期间不被记录为其自己的2跳邻居）。
I_HOLD_TIME: |----------------------------|
I_HOLD_TIME: |----------------------------|
Time: ---*----------------------------------->
^ ^
| |
Formerly used local interface |
network address ceases to be |
assigned to a local interface |
|
Time up to which this network
address is excluded from being
included in this router's 2-Hop Set
Time: ---*----------------------------------->
^ ^
| |
Formerly used local interface |
network address ceases to be |
assigned to a local interface |
|
Time up to which this network
address is excluded from being
included in this router's 2-Hop Set
Figure 11: Local Interface Removed Network Address
图11：删除的本地接口网络地址
This appendix illustrates various examples of physical topologies, as well as how these are logically recorded by NHDP from the point of view of the router A. This representation is a composite of information that would be contained within A's various Information Bases after NHDP has been running for sufficiently long time for the state to converge.
本附录说明了各种物理拓扑的示例，以及NHDP如何从路由器A的角度对其进行逻辑记录。该表示是在NHDP运行足够长的时间以使状态收敛后，将包含在A的各种信息库中的信息的组合。
Note that the examples given in this appendix are NOT exhaustive, but are selected to be illustrative of NHDP neighborhood representations of physical MANET topologies.
请注意，本附录中给出的示例并非详尽无遗，但选择这些示例是为了说明物理MANET拓扑的NHDP邻域表示。
The example topologies presented contain 3 physical routers A, B, and C. Each of these routers has one or two distinct interfaces, denoted "top" and "bottom". Each interface has one or two addresses, and symmetric connectivity between a pair of interfaces is illustrated by these being connected by a line.
给出的示例拓扑包含3个物理路由器A、B和C。每个路由器都有一个或两个不同的接口，分别表示为“顶部”和“底部”。每个接口都有一个或两个地址，一对接口之间的对称连接通过一条线连接来说明。
In all examples, the topology is described as it is recorded by NHDP in router A.
在所有示例中，拓扑都是由NHDP在路由器A中记录的。
In Figure 12, each router has a single interface, each with a single IP address. This is the simplest possible network, and the resulting representation is given to the right in Figure 12.
在图12中，每个路由器都有一个接口，每个接口都有一个IP地址。这是最简单的网络，图12中给出了结果表示。
__________ __________
| | |
{1} {2} {3}
| | | {1}--------{2}--------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
__________ __________
| | |
{1} {2} {3}
| | | {1}--------{2}--------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 12: Standard Single Interface Topology (Left), and Corresponding NHDP Representation (Right)
图12：标准单接口拓扑（左）和相应的NHDP表示（右）
The Local Information Set in A contains a single Local Interface Tuple that has an I_local_iface_addr_list of {1}. This value is denoted with a {1} on the leftmost part of the resulting representation.
中的本地信息集包含一个本地接口元组，该元组具有{1}的I_Local_iface_addr_列表。该值在结果表示的最左侧用{1}表示。
The Interface Information Base has only one Link Set, which represents the "top" interface of A, or {1}. This Link Set's only Link Tuple has an L_neighbor_iface_addr_list containing {2}; this corresponds to the dashed line from {1} to {2} to the right in Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}; this corresponds to the dashed line from {2} to {3} to the right in Figure 12.
接口信息库只有一个链接集，它表示，或{1}的“顶部”接口。此链接集的唯一链接元组有一个包含{2}的L_neighbor_iface_addr_列表；这对应于图12中从{1}到{2}右侧的虚线。2-Hop集合包含一个2-Hop元组，其中N2_neighbor_iface_addr_list为{2}，N2_2hop_addr为{3}；这对应于图12中从{2}到{3}右侧的虚线。
The descriptions of the following examples in this appendix will be derived similarly, and use the same notational conventions.
本附录中以下示例的描述将以类似方式导出，并使用相同的符号约定。
In Figure 13, the network is identical to that in Example 1, except that the middle router, B, has two IP addresses on its single interface.
在图13中，网络与示例1中的网络相同，只是中间路由器B在其单个接口上有两个IP地址。
__________ __________
| | |
{1} {2,4} {3}
| | | {1}-------{2,4}-------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
__________ __________
| | |
{1} {2,4} {3}
| | | {1}-------{2,4}-------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 13: Single Interfaces, with 1-Hop Neighbor B Having Two Addresses (Left), and Corresponding NHDP Representation (Right)
图13：单接口，单跳邻居B有两个地址（左）和相应的NHDP表示（右）
The content of the Interface Information Base is in this case identical to Example 1, except that L_neighbor_iface_addr_list is {2,4} and N2_neighbor_iface_addr_list is {2,4}.
在这种情况下，接口信息库的内容与示例1相同，只是L_neighbor_iface_addr_list为{2,4}，N2_neighbor_iface_addr_list为{2,4}。
In Figure 14, the network is identical to that in Example 1, except that the rightmost router, C, has two IP addresses on its interface.
在图14中，除了最右边的路由器C在其接口上有两个IP地址外，网络与示例1中的网络相同。
__________ __________
| | |
{1} {2} {3,4} +----{3}
| | | {1}--------{2}---+
+--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
__________ __________
| | |
{1} {2} {3,4} +----{3}
| | | {1}--------{2}---+
+--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 14: Single Interfaces, with 2-Hop Neighbor C Having Two Addresses (Left), and Corresponding NHDP Representation (Right)
图14：单接口，2跳邻居C有两个地址（左）和相应的NHDP表示（右）
The content of the Interface Information Base is in this case identical to than in Example 1, except that the 2-Hop Set contains an extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {4}. These two 2-Hop Tuples are illustrated by the two lines from {2} to {3} and (2) to {4}, respectively.
在这种情况下，接口信息库的内容与示例1中的内容相同，只是2-Hop集合包含一个额外的2-Hop元组，其中N2_neighbor_iface_addr_list为{2}，N2_2hop_addr为{4}。这两个2-Hop元组分别用{2}到{3}和（2）到{4}的两行表示。
In Figure 15, the network is identical to that in Example 1, except that all routers have two IP addresses on their interface. The Local Information Base in router A is the same as in Example 1, except that I_local_iface_addr_list is {1,5}.
在图15中，网络与示例1中的网络相同，只是所有路由器的接口上都有两个IP地址。路由器A中的本地信息库与示例1中的相同，只是I_Local_iface_addr_list是{1,5}。
__________ __________
| | |
{1,5} {2,6} {3,4} +----{3}
| | | {1,5}------{2,6}--+
+--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
__________ __________
| | |
{1,5} {2,6} {3,4} +----{3}
| | | {1,5}------{2,6}--+
+--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 15: Single interfaces, all routers having two addresses (left), and corresponding NHDP representation (right)
图15：单接口，所有路由器有两个地址（左），以及相应的NHDP表示（右）
The content of the Interface Information Base is in this case a combination of the Interface Information Bases from Examples 1, 2, and 3.
在这种情况下，接口信息库的内容是来自示例1、2和3的接口信息库的组合。
In Figure 16, all routers have a single IP address on each interface, and with the 2-hop neighbor having two interfaces.
在图16中，所有路由器在每个接口上都有一个IP地址，并且两跳邻居有两个接口。
__________ __________
| | |
{1} {2} {3} +----{3}
| | | {1}--------{2}---+
+--'--+ +--'--+ +-----+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
|
{4}
__________ __________
| | |
{1} {2} {3} +----{3}
| | | {1}--------{2}---+
+--'--+ +--'--+ +-----+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
|
{4}
Figure 16: Single Addresses, with 2-Hop Neighbor C Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
图16：单地址，2跳邻居C有两个接口（左）和相应的NHDP表示（右）
The Interface Information Base is identical to that in Example 3; NHDP does not distinguish topologically between this example and Example 3.
接口信息库与例3相同；NHDP不区分本例和例3的拓扑结构。
In Figure 17, all routers have a single IP address on each interface, and with the 1-hop neighbor having two interfaces.
在图17中，所有路由器在每个接口上都有一个IP地址，并且一跳邻居有两个接口。
__________
| |
{1} {2} +-----+
| | {1}-------| {2} |------{4}
+--'--+ +--'--+ +-----+ | {5} |
| A | | B | | C | +-----+
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
__________
| |
{1} {2} +-----+
| | {1}-------| {2} |------{4}
+--'--+ +--'--+ +-----+ | {5} |
| A | | B | | C | +-----+
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
Figure 17: Single Addresses, with 1-Hop Neighbor B Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
图17：单地址，单跳邻居B有两个接口（左）和相应的NHDP表示（右）
The Local Information Base is identical to that in Example 1.
本地信息库与示例1中的信息库相同。
The Interface Information Base has only one Link Set containing one Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {4}.
接口信息库只有一个链接集，其中包含一个链接元组，L_neighbor_iface_addr_list为{2}。2-Hop集合包含一个2-Hop元组，其中N2_neighbor_iface_addr_list为{2}，N2_2hop_addr为{4}。
The Neighbor Information Base contains a Neighbor Set containing a single Neighbor Tuple, which represents router B, with N_neighbor_addr_list being {2,5}. This entry is represented on the right of Figure 17 by boxing {2} with {5}.
邻居信息库包含一个邻居集，该邻居集包含一个表示路由器B的邻居元组，其中N_Neighbor_addr_list为{2,5}。这个条目在图17的右边用{5}来表示{2}。
Note that router A does not have information indicating which of router B's interfaces is connected to router C. However, router A knows that the address {4} (and thus router C) is reachable by using {2} as next hop.
注意，路由器A没有指示路由器B的哪个接口连接到路由器C的信息。但是，路由器A知道地址{4}（因此路由器C）可以通过使用{2}作为下一跳来访问。
In Figure 18, all routers have a single IP address on each interface, and both the 1-hop and 2-hop neighbors have two interfaces. Furthermore, there are now two physical links between routers B and C, over distinct interface pairs.
在图18中，所有路由器在每个接口上都有一个IP地址，1-hop和2-hop邻居都有两个接口。此外，路由器B和C之间现在有两个物理链路，通过不同的接口对。
__________ __________
| | |
{1} {2} {3} +-----+ +----{3}
| | | {1}-------| {2} |---+
+--'--+ +--'--+ +-----+ | {5} | +----{4}
| A | | B | | C | +-----+
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
__________ __________
| | |
{1} {2} {3} +-----+ +----{3}
| | | {1}-------| {2} |---+
+--'--+ +--'--+ +-----+ | {5} | +----{4}
| A | | B | | C | +-----+
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
Figure 18: Single Addresses, with 1-Hop and 2-Hop Neighbors B and C Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
图18：单地址，1-Hop和2-Hop邻居B和C有两个接口（左），以及相应的NHDP表示（右）
The Local Information Base is identical to that in Example 1.
本地信息库与示例1中的信息库相同。
The Link Set is identical to that in Example 6, and the 2-Hop Set contains, as in Example 5 (and similarly to Examples 3 and 4), two 2-Hop Tuples representing the two links between routers B and C.
链路集与示例6中的链路集相同，并且2-Hop集包含两个表示路由器B和C之间的两个链路的2-Hop元组，如示例5中所示（与示例3和4类似）。
Note that router A does not have information describing which of router B's interfaces is connected to which interfaces of router C, or even that the interfaces with addresses {3} and {4} are interfaces of the same router. However, router A knows that the addresses {3} and {4} (and thus router C) are reachable using {2} as next hop.
注意，路由器A没有描述路由器B的哪个接口连接到路由器C的哪个接口的信息，甚至没有描述地址为{3}和{4}的接口是同一路由器的接口的信息。然而，路由器A知道地址{3}和{4}（因此路由器C）可以使用{2}作为下一跳到达。
In Figure 19, all routers have a single IP address on each interface, and both A and its the 1-hop neighbor B have two interfaces. Furthermore, there are now two physical links between routers A and B, over distinct interface pairs.
在图19中，所有路由器在每个接口上都有一个IP地址，a和它的1跳邻居B都有两个接口。此外，路由器A和B之间现在有两个物理链路，通过不同的接口对。
__________ __________
| | | +-----+
{1} {2} {3} {1}-------| {2} |--------{3}
| | | | {5} |
+--'--+ +--'--+ +-----+ +-----+
| A | | B | | C |
+-----+ +-----+ +-----+ +-----+
| | | {2} |
{6} {5} {6}-------| {5} |--------{3}
|__________| +-----+
__________ __________
| | | +-----+
{1} {2} {3} {1}-------| {2} |--------{3}
| | | | {5} |
+--'--+ +--'--+ +-----+ +-----+
| A | | B | | C |
+-----+ +-----+ +-----+ +-----+
| | | {2} |
{6} {5} {6}-------| {5} |--------{3}
|__________| +-----+
Figure 19: Single Addresses, with Both A and 1-Hop Neighbor B Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
图19：单地址，A和1跳邻居B都有两个接口（左）和相应的NHDP表示（右）
The Local Information Set contains two Local Interface Tuples, with I_local_iface_addr_list of {1} and {6}, respectively.
本地信息集包含两个本地接口元组，I_Local_iface_addr_list分别为{1}和{6}。
Each Interface Information Base's Link Set contains one Link Tuple, representing the links between {1} and {2}, and between {6} and {5}, respectively. The 2-Hop Set for interface {1} contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}. The 2-Hop Set for interface {6} contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and N2_2hop_addr being {3}.
每个接口信息库的链接集包含一个链接元组，分别表示{1}和{2}之间以及{6}和{5}之间的链接。接口{1}的2-Hop集包含一个2-Hop元组，其中N2_neighbor_iface_addr_list为{2}，N2_2hop_addr为{3}。接口{6}的2-Hop集包含一个2-Hop元组，其中N2_neighbor_iface_addr_list为{5}，N2_2hop_addr为{3}。
The Neighbor Information Base contains a Neighbor Set containing a single Neighbor Tuple, which represents router B, with N_neighbor_addr_list being {2,5}. This entry is denoted by boxing {2} with {5}.
邻居信息库包含一个邻居集，该邻居集包含一个表示路由器B的邻居元组，其中N_Neighbor_addr_list为{2,5}。此条目由{2}与{5}装箱表示。
In Figure 20, all routers have a single IP address on each interface, and all routers have two interfaces. Furthermore, there are now two physical links between A and B, over distinct interface pairs, and two physical links between B and C, also over distinct interface pairs.
在图20中，所有路由器在每个接口上都有一个IP地址，并且所有路由器都有两个接口。此外，现在A和B之间有两个物理链路，通过不同的接口对，B和C之间有两个物理链路，也通过不同的接口对。
__________ __________
| | | +-----+ +----{3}
{1} {2} {3} {1}-------| {2} |---+
| | | | {5} | +----{4}
+--'--+ +--'--+ +-----+ +-----+
| A | | B | | C |
+-----+ +-----+ +-----+ +-----+
| | | | {2} | +----{3}
{6} {5} {4} {6}-------| {5} |---+
|__________|__________| +-----+ +----{4}
__________ __________
| | | +-----+ +----{3}
{1} {2} {3} {1}-------| {2} |---+
| | | | {5} | +----{4}
+--'--+ +--'--+ +-----+ +-----+
| A | | B | | C |
+-----+ +-----+ +-----+ +-----+
| | | | {2} | +----{3}
{6} {5} {4} {6}-------| {5} |---+
|__________|__________| +-----+ +----{4}
Figure 20: Single Addresses, with All Routers Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
图20：单个地址，所有路由器都有两个接口（左）和相应的NHDP表示（右）
The Local Information Set is identical to that in Example 8. The Interface Information Base for each interface in A is also identical to that in Example 8, except that an additional 2-Hop Tuple is present in each 2-Hop Set, each representing the link between router B and the interface of router C with address {4}.
本地信息集与示例8中的信息集相同。A中每个接口的接口信息库也与示例8中的接口信息库相同，不同之处在于每个2跳集中存在额外的2跳元组，每个元组表示路由器B和地址为{4}的路由器C的接口之间的链路。
As in Example 7, router A does not have information describing which of router B's interfaces is connected to which interface of C, or even that the interfaces with addresses {3} and {4} are interfaces of the same router. However, router A knows that the addresses {3} and {4} (and router C) are reachable by using {2} or {5} (depending on via which of its local interfaces) as next hop.
如例7所示，路由器A没有描述路由器B的哪个接口连接到C的哪个接口的信息，甚至没有描述地址为{3}和{4}的接口是同一路由器的接口的信息。然而，路由器A知道地址{3}和{4}（以及路由器C）可以通过使用{2}或{5}（取决于通过哪个本地接口）作为下一跳来访问。
In Figure 21, all routers have two IP addresses on each interface, and all routers have two interfaces. Furthermore, there are now two physical links between A and B, over distinct interface pairs, and two physical links between B and C, also over distinct interface pairs.
在图21中，所有路由器在每个接口上都有两个IP地址，并且所有路由器都有两个接口。此外，现在A和B之间有两个物理链路，通过不同的接口对，B和C之间有两个物理链路，也通过不同的接口对。
+--{9}
__________ __________ +------|
| | | +-----+ | +--{10}
{1,2} {5,6} {9,10} {1,2}--|{5,6}|---+
| | | |{7,8}| | +--{11}
+--'--+ +--'--+ +-----+ +-----+ +------|
| A | | B | | C | +--{12}
+-----+ +-----+ +-----+
| | | +--{9}
| | | +-----+ +------|
| | | |{5,6}| | +--{10}
{3,4} {7,8} {11,12} {3,4}--|{7,8}|---+
|__________|__________| +-----+ | +--{11}
+------|
+--{12}
+--{9}
__________ __________ +------|
| | | +-----+ | +--{10}
{1,2} {5,6} {9,10} {1,2}--|{5,6}|---+
| | | |{7,8}| | +--{11}
+--'--+ +--'--+ +-----+ +-----+ +------|
| A | | B | | C | +--{12}
+-----+ +-----+ +-----+
| | | +--{9}
| | | +-----+ +------|
| | | |{5,6}| | +--{10}
{3,4} {7,8} {11,12} {3,4}--|{7,8}|---+
|__________|__________| +-----+ | +--{11}
+------|
+--{12}
Figure 21: Dual Addresses, with All Routers Having Two Interfaces (Left) and Corresponding NHDP Representation (Right)
图21：双地址，所有路由器都有两个接口（左）和相应的NHDP表示（右）
This example is the combination of all the preceding examples in this appendix. The Local Information Set in A contains Local Information Tuples for each of its interfaces, and each Interface Information Base contains in its Link Set a representation of links {1,2}-{5,6} or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor Information Base) records the existence of router B and all of its addresses on all its interfaces, i.e., {5,6,7,8}.
本示例是本附录中所有前面示例的组合。A中的本地信息集包含其每个接口的本地信息元组，每个接口信息库在其链接集中分别包含链接{1,2}-{5,6}或{3,4}-{7,8}的表示。邻居集（在邻居信息库中）记录路由器B的存在及其所有接口上的所有地址，即{5,6,7,8}。
As in Example 9, each interface address of router C is represented in the 2-Hop Set of each Interface Information Base as a link from router B to each of these addresses. Router A does not have information describing which of router B's interfaces is connected to which interface of C, nor that the addresses {9}, {10}, {11}, and {12} are addresses of the same router (or that some of these, such as {9} and {10}, are addresses on the same interface of the router).
如在示例9中，路由器C的每个接口地址在每个接口信息库的2跳集合中表示为从路由器B到这些地址中的每个的链路。路由器A没有描述路由器B的哪个接口连接到C的哪个接口的信息，也没有描述地址{9}、{10}、{11}、和{12}是同一路由器的地址（或者其中一些，例如{9}和{10}，是路由器的同一接口上的地址）的信息。
In Figure 22, all routers have a single interface, except for router A which has two. Each of A's two interfaces has a link with the single interface of router B. All interfaces have a single address.
在图22中，除了路由器a有两个接口外，所有路由器都有一个接口。A的两个接口中的每一个都有一个与路由器B的单个接口的链接。所有接口都有一个地址。
__________ __________
| _____| |
{1} | {2} {3} {1}--------{2}---------{3}
| | | |
+--'--+ | +--'--+ +-----+
| A | | | B | | C |
+-----+ | +-----+ +-----+
| |
{6} | {6}--------{2}---------{3}
|____|
__________ __________
| _____| |
{1} | {2} {3} {1}--------{2}---------{3}
| | | |
+--'--+ | +--'--+ +-----+
| A | | | B | | C |
+-----+ | +-----+ +-----+
| |
{6} | {6}--------{2}---------{3}
|____|
Figure 22: Single Addresses, with A Having Two Interfaces, Both Linked to the Single Interface of B (Left), and Corresponding NHDP Representation (Right)
图22：单个地址，A有两个接口，都链接到B的单个接口（左）和相应的NHDP表示（右）
This is similar to Example 8, except that the single address {2} also replaces the address {5}. In particular, both Link Tuples (one in each Link Set, each in its corresponding Interface Information Base) have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the Neighbor Information Base) contains a single Neighbor Tuple with N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each 2-Hop Set, each in its corresponding Interface Information Base) have N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}.
这与示例8类似，只是单个地址{2}也替换了地址{5}。特别是，两个链路元组（每个链路集中一个，每个在其对应的接口信息库中）的L_neighbor_iface_addr_列表为{2}，邻居集（在邻居信息库中）包含一个N_neighbor_addr_列表为{2}的单个邻居元组，以及两个2跳元组（每个2-Hop集合中有一个，每个在其对应的接口信息库中）具有N2_邻居地址列表为{2}和N2_2hop地址为{3}。
Authors' Addresses
作者地址
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/
Christopher Dearlove BAE Systems ATC
克里斯托弗·迪尔洛夫BAE系统ATC
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Justin W. Dean Naval Research Laboratory
贾斯汀·W·迪安海军研究实验室
Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/
Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/