Network Working Group T. Clausen, Ed.
Request for Comments: 3626 P. Jacquet, Ed.
Category: Experimental Project Hipercom, INRIA
October 2003
Network Working Group T. Clausen, Ed.
Request for Comments: 3626 P. Jacquet, Ed.
Category: Experimental Project Hipercom, INRIA
October 2003
Optimized Link State Routing Protocol (OLSR)
优化链路状态路由协议（OLSR）
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.
本文档描述了用于移动自组织网络的优化链路状态路由（OLSR）协议。该协议是对经典链路状态算法的优化，适合移动无线局域网的要求。协议中使用的关键概念是多点继电器（MPR）。MPR是在泛洪过程中转发广播消息的选定节点。与经典的泛洪机制相比，该技术显著降低了消息开销，其中每个节点在接收到消息的第一个副本时重新传输每个消息。在OLSR中，链路状态信息仅由选择为MPR的节点生成。因此，通过最小化网络中淹没的控制消息的数量来实现第二优化。作为第三种优化，MPR节点可以选择仅报告其自身与其MPR选择器之间的链路。因此，与经典的链路状态算法相反，部分链路状态信息分布在网络中。然后将此信息用于路线计算。OLSR提供最佳路由（以跳数为单位）。该协议特别适用于大型密集网络，因为MPRs技术在这种情况下工作良好。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. OLSR Terminology. . . . . . . . . . . . . . . . . . . . 5
1.2. Applicability. . . . . . . . . . . . . . . . . . . . . . 7
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . 8
1.4. Multipoint Relays . . . . . . . . . . . . . . . . . . . 9
2. Protocol Functioning . . . . . . . . . . . . . . . . . . . . 9
2.1. Core Functioning . . . . . . . . . . . . . . . . . . . 10
2.2. Auxiliary Functioning . . . . . . . . . . . . . . . . . 12
3. Packet Format and Forwarding . . . . . . . . . . . . . . . . 13
3.1. Protocol and Port Number. . . . . . . . . . . . . . . . 13
3.2. Main Address . . . . . . . . . . . . . . . . . . . . . 13
3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. Packet Header . . . . . . . . . . . . . . . . . . 14
3.3.2. Message Header . . . . . . . . . . . . . . . . . 15
3.4. Packet Processing and Message Flooding . . . . . . . . . 16
3.4.1. Default Forwarding Algorithm. . . . . . . . . . . 18
3.4.2. Considerations on Processing and Forwarding . . . 20
3.5. Message Emission and Jitter. . . . . . . . . . . . . . . 21
4. Information Repositories . . . . . . . . . . . . . . . . . . 22
4.1. Multiple Interface Association Information Base . . . . 22
4.2. Link sensing: Local Link Information Base. . . . . . . . 22
4.2.1. Link Set. . . . . . . . . . . . . . . . . . . . . 22
4.3. Neighbor Detection: Neighborhood Information Base. . . . 23
4.3.1. Neighbor Set. . . . . . . . . . . . . . . . . . . 23
4.3.2. 2-hop Neighbor Set. . . . . . . . . . . . . . . . 23
4.3.3. MPR Set . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. MPR Selector Set. . . . . . . . . . . . . . . . . 23
4.4. Topology Information Base . . . . . . . . . . . . . . . 24
5. Main Addresses and Multiple Interfaces . . . . . . . . . . . 24
5.1. MID Message Format . . . . . . . . . . . . . . . . . . . 25
5.2. MID Message Generation . . . . . . . . . . . . . . . . . 25
5.3. MID Message Forwarding . . . . . . . . . . . . . . . . . 26
5.4. MID Message Processing . . . . . . . . . . . . . . . . . 26
5.5. Resolving a Main Address from an Interface Address . . . 27
6. HELLO Message Format and Generation . . . . . . . . . . . . . 27
6.1. HELLO Message Format . . . . . . . . . . . . . . . . . . 27
6.1.1. Link Code as Link Type and Neighbor Type. . . . . 29
6.2. HELLO Message Generation . . . . . . . . . . . . . . . . 30
6.3. HELLO Message Forwarding . . . . . . . . . . . . . . . . 33
6.4. HELLO Message Processing . . . . . . . . . . . . . . . . 33
7. Link Sensing . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Populating the Link Set . . . . . . . . . . . . . . . . 33
7.1.1. HELLO Message Processing . . . . . . . . . . . . 34
8. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . 35
8.1. Populating the Neighbor Set . . . . . . . . . . . . . . . 35
8.1.1. HELLO Message Processing . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. OLSR Terminology. . . . . . . . . . . . . . . . . . . . 5
1.2. Applicability. . . . . . . . . . . . . . . . . . . . . . 7
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . 8
1.4. Multipoint Relays . . . . . . . . . . . . . . . . . . . 9
2. Protocol Functioning . . . . . . . . . . . . . . . . . . . . 9
2.1. Core Functioning . . . . . . . . . . . . . . . . . . . 10
2.2. Auxiliary Functioning . . . . . . . . . . . . . . . . . 12
3. Packet Format and Forwarding . . . . . . . . . . . . . . . . 13
3.1. Protocol and Port Number. . . . . . . . . . . . . . . . 13
3.2. Main Address . . . . . . . . . . . . . . . . . . . . . 13
3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. Packet Header . . . . . . . . . . . . . . . . . . 14
3.3.2. Message Header . . . . . . . . . . . . . . . . . 15
3.4. Packet Processing and Message Flooding . . . . . . . . . 16
3.4.1. Default Forwarding Algorithm. . . . . . . . . . . 18
3.4.2. Considerations on Processing and Forwarding . . . 20
3.5. Message Emission and Jitter. . . . . . . . . . . . . . . 21
4. Information Repositories . . . . . . . . . . . . . . . . . . 22
4.1. Multiple Interface Association Information Base . . . . 22
4.2. Link sensing: Local Link Information Base. . . . . . . . 22
4.2.1. Link Set. . . . . . . . . . . . . . . . . . . . . 22
4.3. Neighbor Detection: Neighborhood Information Base. . . . 23
4.3.1. Neighbor Set. . . . . . . . . . . . . . . . . . . 23
4.3.2. 2-hop Neighbor Set. . . . . . . . . . . . . . . . 23
4.3.3. MPR Set . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. MPR Selector Set. . . . . . . . . . . . . . . . . 23
4.4. Topology Information Base . . . . . . . . . . . . . . . 24
5. Main Addresses and Multiple Interfaces . . . . . . . . . . . 24
5.1. MID Message Format . . . . . . . . . . . . . . . . . . . 25
5.2. MID Message Generation . . . . . . . . . . . . . . . . . 25
5.3. MID Message Forwarding . . . . . . . . . . . . . . . . . 26
5.4. MID Message Processing . . . . . . . . . . . . . . . . . 26
5.5. Resolving a Main Address from an Interface Address . . . 27
6. HELLO Message Format and Generation . . . . . . . . . . . . . 27
6.1. HELLO Message Format . . . . . . . . . . . . . . . . . . 27
6.1.1. Link Code as Link Type and Neighbor Type. . . . . 29
6.2. HELLO Message Generation . . . . . . . . . . . . . . . . 30
6.3. HELLO Message Forwarding . . . . . . . . . . . . . . . . 33
6.4. HELLO Message Processing . . . . . . . . . . . . . . . . 33
7. Link Sensing . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Populating the Link Set . . . . . . . . . . . . . . . . 33
7.1.1. HELLO Message Processing . . . . . . . . . . . . 34
8. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . 35
8.1. Populating the Neighbor Set . . . . . . . . . . . . . . . 35
8.1.1. HELLO Message Processing . . . . . . . . . . . . 37
8.2. Populating the 2-hop Neighbor Set. . . . . . . . . . . . 37
8.2.1. HELLO Message Processing. . . . . . . . . . . . . 37
8.3. Populating the MPR set . . . . . . . . . . . . . . . . . 38
8.3.1. MPR Computation . . . . . . . . . . . . . . . . . 39
8.4. Populating the MPR Selector Set. . . . . . . . . . . . . 41
8.4.1. HELLO Message Processing. . . . . . . . . . . . . 41
8.5. Neighborhood and 2-hop Neighborhood Changes. . . . . . . 42
9. Topology Discovery . . . . . . . . . . . . . . . . . . . . . 43
9.1. TC Message Format. . . . . . . . . . . . . . . . . . . . 43
9.2. Advertised Neighbor Set. . . . . . . . . . . . . . . . . 44
9.3. TC Message Generation. . . . . . . . . . . . . . . . . . 45
9.4. TC Message Forwarding. . . . . . . . . . . . . . . . . . 45
9.5. TC Message Processing. . . . . . . . . . . . . . . . . . 45
10. Routing Table Calculation . . . . . . . . . . . . . . . . . . 47
11. Node Configuration. . . . . . . . . . . . . . . . . . . . . . 50
11.1. Address Assignment. . . . . . . . . . . . . . . . . . . 50
11.2. Routing Configuration . . . . . . . . . . . . . . . . . 51
11.3. Data Packet Forwarding. . . . . . . . . . . . . . . . . 51
12. Non OLSR Interfaces . . . . . . . . . . . . . . . . . . . . . 51
12.1. HNA Message Format. . . . . . . . . . . . . . . . . . . 52
12.2. Host and Network Association Information Base . . . . . 52
12.3. HNA Message Generation. . . . . . . . . . . . . . . . . 53
12.4. HNA Message Forwarding. . . . . . . . . . . . . . . . . 53
12.5. HNA Message Processing. . . . . . . . . . . . . . . . . 53
12.6. Routing Table Calculation . . . . . . . . . . . . . . . 54
12.7. Interoperability Considerations . . . . . . . . . . . . 55
13. Link Layer Notification . . . . . . . . . . . . . . . . . . . 55
13.1. Interoperability Considerations . . . . . . . . . . . . 56
14. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 56
14.1. Local Link Set . . . . . . . . . . . . . . . . . . . . 56
14.2. Hello Message Generation . . . . . . . . . . . . . . . 57
14.3. Hysteresis Strategy . . . . . . . . . . . . . . . . . . 57
14.4. Interoperability Considerations . . . . . . . . . . . . 59
15. Redundant Topology Information. . . . . . . . . . . . . . . . 59
15.1. TC_REDUNDANCY Parameter . . . . . . . . . . . . . . . . 60
15.2. Interoperability Considerations . . . . . . . . . . . . 60
16. MPR Redundancy. . . . . . . . . . . . . . . . . . . . . . . . 60
16.1. MPR_COVERAGE Parameter. . . . . . . . . . . . . . . . . 61
16.2. MPR Computation . . . . . . . . . . . . . . . . . . . . 61
16.3. Interoperability Considerations . . . . . . . . . . . . 62
17. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 63
18. Proposed Values for Constants . . . . . . . . . . . . . . . . 63
18.1. Setting emission interval and holding times . . . . . . 63
18.2. Emission Interval . . . . . . . . . . . . . . . . . . . 64
18.3. Holding time . . . . . . . . . . . . . . . . . . . . . 64
18.4. Message Types . . . . . . . . . . . . . . . . . . . . . 65
18.5. Link Types. . . . . . . . . . . . . . . . . . . . . . . 65
18.6. Neighbor Types . . . . . . . . . . . . . . . . . . . . 65
8.2. Populating the 2-hop Neighbor Set. . . . . . . . . . . . 37
8.2.1. HELLO Message Processing. . . . . . . . . . . . . 37
8.3. Populating the MPR set . . . . . . . . . . . . . . . . . 38
8.3.1. MPR Computation . . . . . . . . . . . . . . . . . 39
8.4. Populating the MPR Selector Set. . . . . . . . . . . . . 41
8.4.1. HELLO Message Processing. . . . . . . . . . . . . 41
8.5. Neighborhood and 2-hop Neighborhood Changes. . . . . . . 42
9. Topology Discovery . . . . . . . . . . . . . . . . . . . . . 43
9.1. TC Message Format. . . . . . . . . . . . . . . . . . . . 43
9.2. Advertised Neighbor Set. . . . . . . . . . . . . . . . . 44
9.3. TC Message Generation. . . . . . . . . . . . . . . . . . 45
9.4. TC Message Forwarding. . . . . . . . . . . . . . . . . . 45
9.5. TC Message Processing. . . . . . . . . . . . . . . . . . 45
10. Routing Table Calculation . . . . . . . . . . . . . . . . . . 47
11. Node Configuration. . . . . . . . . . . . . . . . . . . . . . 50
11.1. Address Assignment. . . . . . . . . . . . . . . . . . . 50
11.2. Routing Configuration . . . . . . . . . . . . . . . . . 51
11.3. Data Packet Forwarding. . . . . . . . . . . . . . . . . 51
12. Non OLSR Interfaces . . . . . . . . . . . . . . . . . . . . . 51
12.1. HNA Message Format. . . . . . . . . . . . . . . . . . . 52
12.2. Host and Network Association Information Base . . . . . 52
12.3. HNA Message Generation. . . . . . . . . . . . . . . . . 53
12.4. HNA Message Forwarding. . . . . . . . . . . . . . . . . 53
12.5. HNA Message Processing. . . . . . . . . . . . . . . . . 53
12.6. Routing Table Calculation . . . . . . . . . . . . . . . 54
12.7. Interoperability Considerations . . . . . . . . . . . . 55
13. Link Layer Notification . . . . . . . . . . . . . . . . . . . 55
13.1. Interoperability Considerations . . . . . . . . . . . . 56
14. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 56
14.1. Local Link Set . . . . . . . . . . . . . . . . . . . . 56
14.2. Hello Message Generation . . . . . . . . . . . . . . . 57
14.3. Hysteresis Strategy . . . . . . . . . . . . . . . . . . 57
14.4. Interoperability Considerations . . . . . . . . . . . . 59
15. Redundant Topology Information. . . . . . . . . . . . . . . . 59
15.1. TC_REDUNDANCY Parameter . . . . . . . . . . . . . . . . 60
15.2. Interoperability Considerations . . . . . . . . . . . . 60
16. MPR Redundancy. . . . . . . . . . . . . . . . . . . . . . . . 60
16.1. MPR_COVERAGE Parameter. . . . . . . . . . . . . . . . . 61
16.2. MPR Computation . . . . . . . . . . . . . . . . . . . . 61
16.3. Interoperability Considerations . . . . . . . . . . . . 62
17. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 63
18. Proposed Values for Constants . . . . . . . . . . . . . . . . 63
18.1. Setting emission interval and holding times . . . . . . 63
18.2. Emission Interval . . . . . . . . . . . . . . . . . . . 64
18.3. Holding time . . . . . . . . . . . . . . . . . . . . . 64
18.4. Message Types . . . . . . . . . . . . . . . . . . . . . 65
18.5. Link Types. . . . . . . . . . . . . . . . . . . . . . . 65
18.6. Neighbor Types . . . . . . . . . . . . . . . . . . . . 65
18.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . 66
18.8. Willingness . . . . . . . . . . . . . . . . . . . . . . 66
18.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . 67
19. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 67
20. Security Considerations . . . . . . . . . . . . . . . . . . . 67
20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . 67
20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . 68
20.3. Interaction with External Routing Domains . . . . . . . 69
20.4. Node Identity . . . . . . . . . . . . . . . . . . . . . 70
21. Flow and congestion control . . . . . . . . . . . . . . . . . 70
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
24. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 71
25. References. . . . . . . . . . . . . . . . . . . . . . . . . . 73
26. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 74
27. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 75
18.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . 66
18.8. Willingness . . . . . . . . . . . . . . . . . . . . . . 66
18.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . 67
19. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 67
20. Security Considerations . . . . . . . . . . . . . . . . . . . 67
20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . 67
20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . 68
20.3. Interaction with External Routing Domains . . . . . . . 69
20.4. Node Identity . . . . . . . . . . . . . . . . . . . . . 70
21. Flow and congestion control . . . . . . . . . . . . . . . . . 70
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
24. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 71
25. References. . . . . . . . . . . . . . . . . . . . . . . . . . 73
26. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 74
27. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 75
The Optimized Link State Routing Protocol (OLSR) is developed for mobile ad hoc networks. It operates as a table driven, proactive protocol, i.e., exchanges topology information with other nodes of the network regularly. Each node selects a set of its neighbor nodes as "multipoint relays" (MPR). In OLSR, only nodes, selected as such MPRs, are responsible for forwarding control traffic, intended for diffusion into the entire network. MPRs provide an efficient mechanism for flooding control traffic by reducing the number of transmissions required.
提出了一种适用于移动adhoc网络的优化链路状态路由协议（OLSR）。它作为一个表驱动的主动协议运行，即定期与网络的其他节点交换拓扑信息。每个节点选择一组相邻节点作为“多点中继”（MPR）。在OLSR中，只有被选为mpr的节点负责转发控制流量，以便扩散到整个网络中。MPR通过减少所需的传输数量，为泛洪控制流量提供了一种有效的机制。
Nodes, selected as MPRs, also have a special responsibility when declaring link state information in the network. Indeed, the only requirement for OLSR to provide shortest path routes to all destinations is that MPR nodes declare link-state information for their MPR selectors. Additional available link-state information may be utilized, e.g., for redundancy.
被选为MPR的节点在网络中声明链路状态信息时也有特殊的责任。实际上，OLSR提供到所有目的地的最短路径路由的唯一要求是MPR节点为其MPR选择器声明链路状态信息。可利用额外的可用链路状态信息，例如用于冗余。
Nodes which have been selected as multipoint relays by some neighbor node(s) announce this information periodically in their control messages. Thereby a node announces to the network, that it has reachability to the nodes which have selected it as an MPR. In route calculation, the MPRs are used to form the route from a given node to any destination in the network. Furthermore, the protocol uses the MPRs to facilitate efficient flooding of control messages in the network.
被一些邻居节点选为多点中继的节点在其控制消息中定期宣布此信息。因此，节点向网络宣布，它可以到达选择它作为MPR的节点。在路由计算中，MPR用于形成从给定节点到网络中任何目的地的路由。此外，该协议使用MPR来促进网络中控制消息的有效泛洪。
A node selects MPRs from among its one hop neighbors with "symmetric", i.e., bi-directional, linkages. Therefore, selecting the route through MPRs automatically avoids the problems associated
节点从其具有“对称”（即双向）链接的单跳邻居中选择MPR。因此，通过MPR选择路线可自动避免相关问题
with data packet transfer over uni-directional links (such as the problem of not getting link-layer acknowledgments for data packets at each hop, for link-layers employing this technique for unicast traffic).
使用单向链路上的数据包传输（例如，对于采用此技术的单播通信量的链路层，在每个跃点上都无法获得数据包的链路层确认的问题）。
OLSR is developed to work independently from other protocols. Likewise, OLSR makes no assumptions about the underlying link-layer.
OLSR是为独立于其他协议工作而开发的。同样，OLSR也不对底层链路层进行假设。
OLSR inherits the concept of forwarding and relaying from HIPERLAN (a MAC layer protocol) which is standardized by ETSI [3]. The protocol is developed in the IPANEMA project (part of the Euclid program) and in the PRIMA project (part of the RNRT program).
OLSR继承了由ETSI标准化的HIPERLAN（MAC层协议）的转发和中继概念[3]。该协议在IPANEMA项目（欧几里德计划的一部分）和PRIMA项目（RNRT计划的一部分）中开发。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[5]中所述进行解释。
Additionally, this document uses the following terminology:
此外，本文件使用以下术语：
node
节点
A MANET router which implements the Optimized Link State Routing protocol as specified in this document.
一种MANET路由器，它实现了本文档中指定的优化链路状态路由协议。
OLSR interface
OLSR接口
A network device participating in a MANET running OLSR. A node may have several OLSR interfaces, each interface assigned an unique IP address.
参与运行OLSR的MANET的网络设备。一个节点可能有几个OLSR接口，每个接口分配一个唯一的IP地址。
non OLSR interface
非OLSR接口
A network device, not participating in a MANET running OLSR. A node may have several non OLSR interfaces (wireless and/or wired). Routing information from these interfaces MAY be injected into the OLSR routing domain.
一种网络设备，不参与运行OLSR的MANET。一个节点可以有几个非OLSR接口（无线和/或有线）。来自这些接口的路由信息可以注入OLSR路由域。
single OLSR interface node
单OLSR接口节点
A node which has a single OLSR interface, participating in an OLSR routing domain.
具有单个OLSR接口的节点，参与OLSR路由域。
multiple OLSR interface node
多OLSR接口节点
A node which has multiple OLSR interfaces, participating in an OLSR routing domain.
具有多个OLSR接口的节点，参与OLSR路由域。
main address
主地址
The main address of a node, which will be used in OLSR control traffic as the "originator address" of all messages emitted by this node. It is the address of one of the OLSR interfaces of the node.
节点的主地址，将在OLSR控制通信中用作此节点发出的所有消息的“发起者地址”。它是节点的一个OLSR接口的地址。
A single OLSR interface node MUST use the address of its only OLSR interface as the main address.
单个OLSR接口节点必须使用其唯一OLSR接口的地址作为主地址。
A multiple OLSR interface node MUST choose one of its OLSR interface addresses as its "main address" (equivalent of "router ID" or "node identifier"). It is of no importance which address is chosen, however a node SHOULD always use the same address as its main address.
多个OLSR接口节点必须选择其一个OLSR接口地址作为其“主地址”（相当于“路由器ID”或“节点标识符”）。选择哪个地址并不重要，但是节点应始终使用与其主地址相同的地址。
neighbor node
邻居节点
A node X is a neighbor node of node Y if node Y can hear node X (i.e., a link exists between an OLSR interface on node X and an OLSR interface on Y).
如果节点Y可以听到节点X（即，节点X上的OLSR接口和Y上的OLSR接口之间存在链路），则节点X是节点Y的邻居节点。
2-hop neighbor
二跳邻居
A node heard by a neighbor.
邻居听到的节点。
strict 2-hop neighbor
严格二跳邻居
a 2-hop neighbor which is not the node itself or a neighbor of the node, and in addition is a neighbor of a neighbor, with willingness different from WILL_NEVER, of the node.
一个2跳邻居，它不是节点本身或节点的邻居，而且是该节点的邻居的邻居，意愿不同于WILL_NEVER。
multipoint relay (MPR)
多点继电器（MPR）
A node which is selected by its 1-hop neighbor, node X, to "re-transmit" all the broadcast messages that it receives from X, provided that the message is not a duplicate, and that the time to live field of the message is greater than one.
由其1跳邻居节点X选择的一种节点，用于“重新发送”从X接收的所有广播消息，前提是该消息不是重复的，并且该消息的生存时间字段大于1。
multipoint relay selector (MPR selector, MS)
多点继电器选择器（MPR选择器，MS）
A node which has selected its 1-hop neighbor, node X, as its multipoint relay, will be called a multipoint relay selector of node X.
选择其1跳邻居节点X作为其多点中继的节点称为节点X的多点中继选择器。
link
链接
A link is a pair of OLSR interfaces (from two different nodes) susceptible to hear one another (i.e., one may be able to receive traffic from the other). A node is said to have a link to another node when one of its interface has a link to one of the interfaces of the other node.
链路是一对OLSR接口（来自两个不同的节点），容易相互听到（即，一个可以从另一个接收通信量）。当一个节点的一个接口与另一个节点的一个接口有链接时，该节点被称为与另一个节点有链接。
symmetric link
对称链路
A verified bi-directional link between two OLSR interfaces.
两个OLSR接口之间经过验证的双向链路。
asymmetric link
不对称链路
A link between two OLSR interfaces, verified in only one direction.
两个OLSR接口之间的链路，仅在一个方向上验证。
symmetric 1-hop neighborhood
对称1跳邻域
The symmetric 1-hop neighborhood of any node X is the set of nodes which have at least one symmetric link to X.
任何节点X的对称1跳邻域是至少有一个到X的对称链路的节点集。
symmetric 2-hop neighborhood
对称二跳邻域
The symmetric 2-hop neighborhood of X is the set of nodes, excluding X itself, which have a symmetric link to the symmetric 1-hop neighborhood of X.
X的对称2-hop邻域是一组节点，不包括X本身，它们与X的对称1-hop邻域具有对称链接。
symmetric strict 2-hop neighborhood
对称严格2跳邻域
The symmetric strict 2-hop neighborhood of X is the set of nodes, excluding X itself and its neighbors, which have a symmetric link to some symmetric 1-hop neighbor, with willingness different of WILL_NEVER, of X.
X的对称严格2-hop邻域是一组节点，不包括X本身及其邻居，它们与X的某个对称1-hop邻居有一个对称链接，其意愿不同于X的WILL_NEVER。
OLSR is a proactive routing protocol for mobile ad-hoc networks (MANETs) [1], [2]. It is well suited to large and dense mobile networks, as the optimization achieved using the MPRs works well in this context. The larger and more dense a network, the more optimization can be achieved as compared to the classic link state algorithm. OLSR uses hop-by-hop routing, i.e., each node uses its local information to route packets.
OLSR是一种用于移动自组织网络（MANET）的主动式路由协议[1]，[2]。它非常适合于大型和密集的移动网络，因为使用MPRs实现的优化在这种情况下运行良好。与经典的链路状态算法相比，网络越大、越密集，可以实现的优化就越多。OLSR使用逐跳路由，即每个节点使用其本地信息路由数据包。
OLSR is well suited for networks, where the traffic is random and sporadic between a larger set of nodes rather than being almost exclusively between a small specific set of nodes. As a proactive
OLSR非常适合于网络，在这种网络中，流量在较大的一组节点之间是随机的和零星的，而不是几乎完全在一组特定的小节点之间。作为一个积极主动的人
protocol, OLSR is also suitable for scenarios where the communicating pairs change over time: no additional control traffic is generated in this situation since routes are maintained for all known destinations at all times.
协议，OLSR也适用于通信对随时间变化的场景：在这种情况下不会产生额外的控制流量，因为路由始终为所有已知目的地维护。
OLSR is a proactive routing protocol for mobile ad hoc networks. The protocol inherits the stability of a link state algorithm and has the advantage of having routes immediately available when needed due to its proactive nature. OLSR is an optimization over the classical link state protocol, tailored for mobile ad hoc networks.
OLSR是一种用于移动自组织网络的主动路由协议。该协议继承了链路状态算法的稳定性，并且由于其主动性，具有在需要时立即提供路由的优点。OLSR是对经典链路状态协议的优化，专为移动adhoc网络量身定制。
OLSR minimizes the overhead from flooding of control traffic by using only selected nodes, called MPRs, to retransmit control messages. This technique significantly reduces the number of retransmissions required to flood a message to all nodes in the network. Secondly, OLSR requires only partial link state to be flooded in order to provide shortest path routes. The minimal set of link state information required is, that all nodes, selected as MPRs, MUST declare the links to their MPR selectors. Additional topological information, if present, MAY be utilized e.g., for redundancy purposes.
OLSR通过仅使用被称为MPR的选定节点来重新传输控制消息，从而最大限度地减少控制流量泛滥带来的开销。该技术显著减少了将消息大量发送到网络中所有节点所需的重新传输次数。其次，OLSR只需要部分链路状态被淹没，以提供最短路径。所需的最小链路状态信息集是，所有被选为MPR的节点必须向其MPR选择器声明链路。附加拓扑信息（如有）可用于冗余目的。
OLSR MAY optimize the reactivity to topological changes by reducing the maximum time interval for periodic control message transmission. Furthermore, as OLSR continuously maintains routes to all destinations in the network, the protocol is beneficial for traffic patterns where a large subset of nodes are communicating with another large subset of nodes, and where the [source, destination] pairs are changing over time. The protocol is particularly suited for large and dense networks, as the optimization done using MPRs works well in this context. The larger and more dense a network, the more optimization can be achieved as compared to the classic link state algorithm.
OLSR可以通过减少周期性控制消息传输的最大时间间隔来优化对拓扑变化的反应性。此外，由于OLSR持续地维护到网络中所有目的地的路由，因此该协议对于其中一大群节点正在与另一大群节点通信并且其中[源，目的地]对随着时间而改变的业务模式是有益的。该协议特别适用于大型和密集的网络，因为使用MPRs进行的优化在这种情况下效果良好。与经典的链路状态算法相比，网络越大、越密集，可以实现的优化就越多。
OLSR is designed to work in a completely distributed manner and does not depend on any central entity. The protocol does NOT REQUIRE reliable transmission of control messages: each node sends control messages periodically, and can therefore sustain a reasonable loss of some such messages. Such losses occur frequently in radio networks due to collisions or other transmission problems.
OLSR设计为以完全分布式的方式工作，不依赖于任何中心实体。该协议不要求控制消息的可靠传输：每个节点定期发送控制消息，因此可以承受一些此类消息的合理丢失。由于碰撞或其他传输问题，这种损失在无线网络中经常发生。
Also, OLSR does not require sequenced delivery of messages. Each control message contains a sequence number which is incremented for each message. Thus the recipient of a control message can, if required, easily identify which information is more recent - even if messages have been re-ordered while in transmission.
此外，OLSR不需要按顺序传递消息。每个控制消息都包含一个序列号，该序列号在每条消息中递增。因此，如果需要，控制消息的接收者可以很容易地识别哪些信息是最新的，即使消息在传输过程中被重新排序。
Furthermore, OLSR provides support for protocol extensions such as sleep mode operation, multicast-routing etc. Such extensions may be introduced as additions to the protocol without breaking backwards compatibility with earlier versions.
此外，OLSR提供对协议扩展的支持，如睡眠模式操作、多播路由等。这些扩展可以作为协议的补充引入，而不会破坏与早期版本的向后兼容性。
OLSR does not require any changes to the format of IP packets. Thus any existing IP stack can be used as is: the protocol only interacts with routing table management.
OLSR不需要对IP数据包的格式进行任何更改。因此，任何现有IP堆栈都可以按原样使用：该协议仅与路由表管理交互。
The idea of multipoint relays is to minimize the overhead of flooding messages in the network by reducing redundant retransmissions in the same region. Each node in the network selects a set of nodes in its symmetric 1-hop neighborhood which may retransmit its messages. This set of selected neighbor nodes is called the "Multipoint Relay" (MPR) set of that node. The neighbors of node N which are *NOT* in its MPR set, receive and process broadcast messages but do not retransmit broadcast messages received from node N.
多点中继的思想是通过减少同一区域内的冗余重传来最小化网络中泛洪消息的开销。网络中的每个节点在其对称1跳邻居中选择一组节点，这些节点可以重传其消息。这组选定的邻居节点称为该节点的“多点中继”（MPR）集。节点N的邻居（在其MPR集合中不是*）接收并处理广播消息，但不重新传输从节点N接收的广播消息。
Each node selects its MPR set from among its 1-hop symmetric neighbors. This set is selected such that it covers (in terms of radio range) all symmetric strict 2-hop nodes. The MPR set of N, denoted as MPR(N), is then an arbitrary subset of the symmetric 1-hop neighborhood of N which satisfies the following condition: every node in the symmetric strict 2-hop neighborhood of N must have a symmetric link towards MPR(N). The smaller a MPR set, the less control traffic overhead results from the routing protocol. [2] gives an analysis and example of MPR selection algorithms.
每个节点从其1跳对称邻居中选择其MPR集。选择此集合时，它将覆盖（就无线电范围而言）所有对称严格2跳节点。N的MPR集表示为MPR（N），是N的对称1-hop邻域的任意子集，满足以下条件：N的对称严格2-hop邻域中的每个节点必须具有指向MPR（N）的对称链路。MPR集越小，路由协议产生的控制流量开销就越小。[2] 给出了MPR选择算法的分析和实例。
Each node maintains information about the set of neighbors that have selected it as MPR. This set is called the "Multipoint Relay Selector set" (MPR selector set) of a node. A node obtains this information from periodic HELLO messages received from the neighbors.
每个节点维护有关已将其选为MPR的邻居集的信息。该集合称为节点的“多点继电器选择器集合”（MPR选择器集合）。节点从邻居定期接收的HELLO消息中获取此信息。
A broadcast message, intended to be diffused in the whole network, coming from any of the MPR selectors of node N is assumed to be retransmitted by node N, if N has not received it yet. This set can change over time (i.e., when a node selects another MPR-set) and is indicated by the selector nodes in their HELLO messages.
如果节点N尚未接收到来自节点N的任何MPR选择器的打算在整个网络中传播的广播消息，则假定该广播消息由节点N重传。该集合可以随时间变化（即，当一个节点选择另一个MPR集合时），并由选择器节点在其HELLO消息中指示。
This section outlines the overall protocol functioning.
本节概述了整个协议的功能。
OLSR is modularized into a "core" of functionality, which is always required for the protocol to operate, and a set of auxiliary functions.
OLSR模块化为一个“核心”功能和一组辅助功能，该功能始终是协议运行所必需的。
The core specifies, in its own right, a protocol able to provide routing in a stand-alone MANET.
核心本身指定了一种能够在独立MANET中提供路由的协议。
Each auxiliary function provides additional functionality, which may be applicable in specific scenarios, e.g., in case a node is providing connectivity between the MANET and another routing domain.
每个辅助功能提供附加功能，其可适用于特定场景，例如，在节点提供MANET和另一路由域之间的连接的情况下。
All auxiliary functions are compatible, to the extent where any (sub)set of auxiliary functions may be implemented with the core. Furthermore, the protocol allows heterogeneous nodes, i.e., nodes which implement different subsets of the auxiliary functions, to coexist in the network.
所有辅助功能都是兼容的，任何（子）辅助功能集都可以通过核心实现。此外，该协议允许异构节点，即实现辅助功能的不同子集的节点，在网络中共存。
The purpose of dividing the functioning of OLSR into a core functionality and a set of auxiliary functions is to provide a simple and easy-to-comprehend protocol, and to provide a way of only adding complexity where specific additional functionality is required.
将OLSR的功能划分为一个核心功能和一组辅助功能的目的是提供一个简单易理解的协议，并提供一种仅在需要特定附加功能时增加复杂性的方法。
The core functionality of OLSR specifies the behavior of a node, equipped with OLSR interfaces participating in the MANET and running OLSR as routing protocol. This includes a universal specification of OLSR protocol messages and their transmission through the network, as well as link sensing, topology diffusion and route calculation.
OLSR的核心功能指定了节点的行为，该节点配备有参与MANET的OLSR接口，并将OLSR作为路由协议运行。这包括OLSR协议消息的通用规范及其通过网络的传输，以及链路感知、拓扑扩散和路由计算。
Specifically, the core is made up from the following components:
具体而言，核心由以下组件组成：
Packet Format and Forwarding
数据包格式和转发
A universal specification of the packet format and an optimized flooding mechanism serves as the transport mechanism for all OLSR control traffic.
数据包格式的通用规范和优化的泛洪机制用作所有OLSR控制流量的传输机制。
Link Sensing
链路感应
Link Sensing is accomplished through periodic emission of HELLO messages over the interfaces through which connectivity is checked. A separate HELLO message is generated for each interface and emitted in correspondence with the provisions in section 7.
链路感知是通过在接口上定期发送HELLO消息来完成的，通过该接口可以检查连接。为每个接口生成单独的HELLO消息，并根据第7节的规定发出。
Resulting from Link Sensing is a local link set, describing links between "local interfaces" and "remote interfaces" - i.e., interfaces on neighbor nodes.
链路感应产生的是一个本地链路集，描述“本地接口”和“远程接口”（即邻居节点上的接口）之间的链路。
If sufficient information is provided by the link-layer, this may be utilized to populate the local link set instead of HELLO message exchange.
如果链路层提供了足够的信息，则可以利用该信息来填充本地链路集，而不是HELLO消息交换。
Neighbor detection
邻居检测
Given a network with only single interface nodes, a node may deduct the neighbor set directly from the information exchanged as part of link sensing: the "main address" of a single interface node is, by definition, the address of the only interface on that node.
给定只有单个接口节点的网络，节点可以直接从作为链路感知的一部分交换的信息中扣除邻居集：根据定义，单个接口节点的“主地址”是该节点上唯一接口的地址。
In a network with multiple interface nodes, additional information is required in order to map interface addresses to main addresses (and, thereby, to nodes). This additional information is acquired through multiple interface declaration (MID) messages, described in section 5.
在具有多个接口节点的网络中，需要额外的信息才能将接口地址映射到主地址（从而映射到节点）。此附加信息通过多个接口声明（MID）消息获取，如第5节所述。
MPR Selection and MPR Signaling
MPR选择和MPR信令
The objective of MPR selection is for a node to select a subset of its neighbors such that a broadcast message, retransmitted by these selected neighbors, will be received by all nodes 2 hops away. The MPR set of a node is computed such that it, for each interface, satisfies this condition. The information required to perform this calculation is acquired through the periodic exchange of HELLO messages, as described in section 6. MPR selection procedures are detailed in section 8.3.
MPR选择的目标是节点选择其邻居的子集，使得由这些选择的邻居重新传输的广播消息将被所有2跳之外的节点接收。计算节点的MPR集，使其对于每个接口都满足此条件。执行此计算所需的信息是通过定期交换HELLO消息获得的，如第6节所述。MPR选择程序详见第8.3节。
MPR signaling is provided in correspondence with the provisions in the section 6.
MPR信号按照第6节的规定提供。
Topology Control Message Diffusion
拓扑控制消息扩散
Topology Control messages are diffused with the purpose of providing each node in the network with sufficient link-state information to allow route calculation. Topology Control messages are diffused in correspondence with the provisions in section 9.
传播拓扑控制消息的目的是为网络中的每个节点提供足够的链路状态信息，以便进行路由计算。拓扑控制信息的传播应符合第9节的规定。
Route Calculation
路线计算
Given the link state information acquired through periodic message exchange, as well as the interface configuration of the nodes, the routing table for each node can be computed. This is detailed in section 10.
给定通过定期消息交换获得的链路状态信息以及节点的接口配置，可以计算每个节点的路由表。第10节对此进行了详细说明。
The key notion for these mechanisms is the MPR relationship.
这些机制的关键概念是MPR关系。
The following table specifies the component of the core functionality of OLSR, as well as their relations to this document.
下表规定了OLSR核心功能的组成部分及其与本文档的关系。
Feature | Section
------------------------------+--------------
Packet format and forwarding | 3
Information repositories | 4
Main addr and multiple if. | 5
Hello messages | 6
Link sensing | 7
Neighbor detection | 8
Topology discovery | 9
Routing table computation | 10
Node configuration | 11
Feature | Section
------------------------------+--------------
Packet format and forwarding | 3
Information repositories | 4
Main addr and multiple if. | 5
Hello messages | 6
Link sensing | 7
Neighbor detection | 8
Topology discovery | 9
Routing table computation | 10
Node configuration | 11
In addition to the core functioning of OLSR, there are situations where additional functionality is desired. This includes situations where a node has multiple interfaces, some of which participate in another routing domain, where the programming interface to the networking hardware provides additional information in form of link layer notifications and where it is desired to provide redundant topological information to the network on expense of protocol overhead.
除了OLSR的核心功能外，还需要其他功能。这包括节点具有多个接口的情况，其中一些接口参与另一个路由域，网络硬件的编程接口以链路层通知的形式提供附加信息，并且需要以协议开销为代价向网络提供冗余拓扑信息。
The following table specifies auxiliary functions and their relation to this document.
下表规定了辅助功能及其与本文件的关系。
Feature | Section
------------------------------+--------------
Non-OLSR interfaces | 12
Link-layer notifications | 13
Advanced link sensing | 14
Redundant topology | 15
Redundant MPR flooding | 16
Feature | Section
------------------------------+--------------
Non-OLSR interfaces | 12
Link-layer notifications | 13
Advanced link sensing | 14
Redundant topology | 15
Redundant MPR flooding | 16
The interpretation of the above table is as follows: if the feature listed is required, it SHOULD be provided as specified in the corresponding section.
上表的解释如下：如果需要列出的特性，应按照相应章节的规定提供。
OLSR communicates using a unified packet format for all data related to the protocol. The purpose of this is to facilitate extensibility of the protocol without breaking backwards compatibility. This also provides an easy way of piggybacking different "types" of information into a single transmission, and thus for a given implementation to optimize towards utilizing the maximal frame-size, provided by the network. These packets are embedded in UDP datagrams for transmission over the network. The present document is presented with IPv4 addresses. Considerations regarding IPv6 are given in section 17.
OLSR使用与协议相关的所有数据的统一数据包格式进行通信。这样做的目的是在不破坏向后兼容性的情况下促进协议的可扩展性。这还提供了一种将不同“类型”的信息背载到单个传输中的简单方法，因此对于给定的实现，可以优化利用网络提供的最大帧大小。这些数据包嵌入UDP数据报中，以便通过网络传输。本文档提供了IPv4地址。第17节给出了有关IPv6的注意事项。
Each packet encapsulates one or more messages. The messages share a common header format, which enables nodes to correctly accept and (if applicable) retransmit messages of an unknown type.
每个数据包封装一个或多个消息。这些消息共享一种通用的头格式，使节点能够正确地接受和（如果适用）重新传输未知类型的消息。
Messages can be flooded onto the entire network, or flooding can be limited to nodes within a diameter (in terms of number of hops) from the originator of the message. Thus transmitting a message to the neighborhood of a node is just a special case of flooding. When flooding any control message, duplicate retransmissions will be eliminated locally (i.e., each node maintains a duplicate set to prevent transmitting the same OLSR control message twice) and minimized in the entire network through the usage of MPRs as described in later sections.
消息可以被淹没在整个网络上，或者淹没可以被限制在消息发起者直径（以跳数计）内的节点上。因此，将消息传输到节点的邻域只是泛洪的一种特殊情况。当泛洪任何控制消息时，重复的重传将在本地消除（即，每个节点维护一个重复集以防止两次传输相同的OLSR控制消息），并通过使用mpr在整个网络中最小化，如后面部分所述。
Furthermore, a node can examine the header of a message to obtain information on the distance (in terms of number of hops) to the originator of the message. This feature may be useful in situations where, e.g., the time information from a received control messages stored in a node depends on the distance to the originator.
此外，节点可以检查消息的报头以获得关于到消息的发起者的距离（以跳数为单位）的信息。例如，在来自存储在节点中的接收控制消息的时间信息取决于到发端人的距离的情况下，该特征可能有用。
Packets in OLSR are communicated using UDP. Port 698 has been assigned by IANA for exclusive usage by the OLSR protocol.
OLSR中的数据包使用UDP进行通信。IANA已将端口698分配给OLSR协议专用。
For a node with one interface, the main address of a node, as defined in "OLSR Terminology", MUST be set to the address of that interface.
对于具有一个接口的节点，“OLSR术语”中定义的节点主地址必须设置为该接口的地址。
The basic layout of any packet in OLSR is as follows (omitting IP and UDP headers):
OLSR中任何数据包的基本布局如下（省略IP和UDP头）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length | Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
(etc.)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length | Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
(etc.)
Packet Length
数据包长度
The length (in bytes) of the packet
数据包的长度（以字节为单位）
Packet Sequence Number
包序列号
The Packet Sequence Number (PSN) MUST be incremented by one each time a new OLSR packet is transmitted. "Wrap-around" is handled as described in section 19. A separate Packet Sequence Number is maintained for each interface such that packets transmitted over an interface are sequentially enumerated.
每次传输新的OLSR数据包时，数据包序列号（PSN）必须增加1。“缠绕”的处理如第19节所述。为每个接口维护单独的分组序列号，使得通过接口传输的分组被顺序地枚举。
The IP address of the interface over which a packet was transmitted is obtainable from the IP header of the packet.
传输数据包的接口的IP地址可从数据包的IP报头获得。
If the packet contains no messages (i.e., the Packet Length is less than or equal to the size of the packet header), the packet MUST silently be discarded.
如果数据包不包含任何消息（即，数据包长度小于或等于数据包头的大小），则必须以静默方式丢弃数据包。
For IPv4 addresses, this implies that packets, where the Packet Length < 16 MUST silently be discarded.
对于IPv4地址，这意味着必须以静默方式丢弃数据包，其中数据包长度<16。
Message Type
消息类型
This field indicates which type of message is to be found in the "MESSAGE" part. Message types in the range of 0-127 are reserved for messages in this document and in possible extensions.
此字段指示在“消息”部分可以找到哪种类型的消息。0-127范围内的消息类型是为本文档和可能的扩展中的消息保留的。
Vtime
时间
This field indicates for how long time after reception a node MUST consider the information contained in the message as valid, unless a more recent update to the information is received. The validity time is represented by its mantissa (four highest bits of Vtime field) and by its exponent (four lowest bits of Vtime field). In other words:
此字段指示接收后多长时间节点必须将消息中包含的信息视为有效的，除非接收到对信息的最近更新。有效时间由尾数（Vtime字段的四个最高位）和指数（Vtime字段的四个最低位）表示。换言之：
validity time = C*(1+a/16)* 2^b [in seconds]
validity time = C*(1+a/16)* 2^b [in seconds]
where a is the integer represented by the four highest bits of Vtime field and b the integer represented by the four lowest bits of Vtime field. The proposed value of the scaling factor C is specified in section 18.
其中a是由Vtime字段的四个最高位表示的整数，b是由Vtime字段的四个最低位表示的整数。第18节规定了比例因子C的建议值。
Message Size
消息大小
This gives the size of this message, counted in bytes and measured from the beginning of the "Message Type" field and until the beginning of the next "Message Type" field (or - if there are no following messages - until the end of the packet).
这给出了该消息的大小，以字节为单位，从“消息类型”字段的开头到下一个“消息类型”字段的开头（或者-如果没有后续消息-直到数据包的结尾）测量。
Originator Address
发起者地址
This field contains the main address of the node, which has originally generated this message. This field SHOULD NOT be confused with the source address from the IP header, which is changed each time to the address of the intermediate interface
此字段包含最初生成此消息的节点的主地址。此字段不应与IP头中的源地址混淆，IP头每次都会更改为中间接口的地址
which is re-transmitting this message. The Originator Address field MUST *NEVER* be changed in retransmissions.
正在重新传输此消息。在重新传输时，必须*从不*更改“发起者地址”字段。
Time To Live
活下去的时间
This field contains the maximum number of hops a message will be transmitted. Before a message is retransmitted, the Time To Live MUST be decremented by 1. When a node receives a message with a Time To Live equal to 0 or 1, the message MUST NOT be retransmitted under any circumstances. Normally, a node would not receive a message with a TTL of zero.
此字段包含消息将传输的最大跳数。在重新传输消息之前，生存时间必须减少1。当节点接收到生存时间等于0或1的消息时，在任何情况下都不得重新传输该消息。通常，节点不会接收TTL为零的消息。
Thus, by setting this field, the originator of a message can limit the flooding radius.
因此，通过设置此字段，消息的发起者可以限制泛洪半径。
Hop Count
跳数
This field contains the number of hops a message has attained. Before a message is retransmitted, the Hop Count MUST be incremented by 1.
此字段包含消息已达到的跃点数。在重新传输消息之前，跃点计数必须增加1。
Initially, this is set to '0' by the originator of the message.
最初，消息的原始发件人将其设置为“0”。
Message Sequence Number
消息序列号
While generating a message, the "originator" node will assign a unique identification number to each message. This number is inserted into the Sequence Number field of the message. The sequence number is increased by 1 (one) for each message originating from the node. "Wrap-around" is handled as described in section 19. Message sequence numbers are used to ensure that a given message is not retransmitted more than once by any node.
生成消息时，“发起者”节点将为每条消息分配一个唯一的标识号。此编号将插入到消息的序列号字段中。对于源自节点的每条消息，序列号增加1（一）。“缠绕”的处理如第19节所述。消息序列号用于确保给定消息不会被任何节点多次重传。
Upon receiving a basic packet, a node examines each of the "message headers". Based on the value of the "Message Type" field, the node can determine the fate of the message. A node may receive the same message several times. Thus, to avoid re-processing of some messages which were already received and processed, each node maintains a Duplicate Set. In this set, the node records information about the most recently received messages where duplicate processing of a message is to be avoided. For such a message, a node records a "Duplicate Tuple" (D_addr, D_seq_num, D_retransmitted, D_iface_list, D_time), where D_addr is the originator address of the message, D_seq_num is the message sequence number of the message, D_retransmitted is a boolean indicating whether the message has been
在接收到基本数据包后，节点检查每个“消息头”。根据“消息类型”字段的值，节点可以确定消息的命运。一个节点可以多次接收相同的消息。因此，为了避免重新处理一些已经接收和处理的消息，每个节点都维护一个重复的集合。在该集合中，节点记录关于最近接收的消息的信息，其中要避免重复处理消息。对于这样的消息，节点记录“重复元组”（D_addr、D_seq_num、D_retransmitted、D_iface_list、D_time），其中D_addr是消息的发起者地址，D_seq_num是消息的消息序列号，D_retransmitted是指示消息是否已被发送的布尔值
already retransmitted, D_iface_list is a list of the addresses of the interfaces on which the message has been received and D_time specifies the time at which a tuple expires and *MUST* be removed.
D_iface_list是已重传消息的接口地址列表，D_time指定元组过期和*必须*删除的时间。
In a node, the set of Duplicate Tuples are denoted the "Duplicate set".
在节点中，重复元组集表示为“重复集”。
In this section, the term "Originator Address" will be used for the main address of the node which sent the message. The term "Sender Interface Address" will be used for the sender address (given in the IP header of the packet containing the message) of the interface which sent the message. The term "Receiving Interface Address" will be used for the address of the interface of the node which received the message.
在本节中，术语“发起者地址”将用于发送消息的节点的主地址。术语“发送方接口地址”将用于发送消息的接口的发送方地址（在包含消息的数据包的IP报头中给出）。术语“接收接口地址”将用于接收消息的节点的接口地址。
Thus, upon receiving a basic packet, a node MUST perform the following tasks for each encapsulated message:
因此，在接收到基本数据包时，节点必须为每个封装的消息执行以下任务：
1 If the packet contains no messages (i.e., the Packet Length is less than or equal to the size of the packet header), the packet MUST silently be discarded.
1如果数据包不包含任何消息（即，数据包长度小于或等于数据包头的大小），则必须以静默方式丢弃数据包。
For IPv4 addresses, this implies that packets, where the Packet Length < 16 MUST silently be discarded.
对于IPv4地址，这意味着必须以静默方式丢弃数据包，其中数据包长度<16。
2 If the time to live of the message is less than or equal to '0' (zero), or if the message was sent by the receiving node (i.e., the Originator Address of the message is the main address of the receiving node): the message MUST silently be dropped.
2如果消息的生存时间小于或等于“0”（零），或者如果消息是由接收节点发送的（即，消息的发起者地址是接收节点的主地址）：消息必须以静默方式丢弃。
3 Processing condition:
3加工条件：
3.1 if there exists a tuple in the duplicate set, where:
3.1 如果重复集中存在元组，其中：
D_addr == Originator Address, AND
D_addr==发起人地址，以及
D_seq_num == Message Sequence Number
D_seq_num==消息序列号
then the message has already been completely processed and MUST not be processed again.
则消息已被完全处理，不得再次处理。
3.2 Otherwise, if the node implements the Message Type of the message, the message MUST be processed according to the specifications for the message type.
3.2 否则，如果节点实现消息的消息类型，则必须根据消息类型的规范处理消息。
4 Forwarding condition:
4转发条件：
4.1 if there exists a tuple in the duplicate set, where:
4.1 如果重复集中存在元组，其中：
D_addr == Originator Address, AND
D_addr==发起人地址，以及
D_seq_num == Message Sequence Number, AND
D_seq_num==消息序列号，以及
the receiving interface (address) is in D_iface_list
接收接口（地址）在D_iface_列表中
then the message has already been considered for forwarding and SHOULD NOT be retransmitted again.
则已考虑转发该消息，不应再次重新传输。
4.2 Otherwise:
4.2 否则：
4.2.1 If the node implements the Message Type of the message, the message MUST be considered for forwarding according to the specifications for the message type.
4.2.1 如果节点实现了消息的消息类型，则必须根据消息类型的规范考虑转发消息。
4.2.2 Otherwise, if the node does not implement the Message Type of the message, the message SHOULD be processed according to the default forwarding algorithm described below.
4.2.2 否则，如果节点未实现消息的消息类型，则应根据下面描述的默认转发算法处理消息。
The default forwarding algorithm is the following:
默认的转发算法如下所示：
1 If the sender interface address of the message is not detected to be in the symmetric 1-hop neighborhood of the node, the forwarding algorithm MUST silently stop here (and the message MUST NOT be forwarded).
1如果未检测到消息的发送方接口地址位于节点的对称1-hop邻域中，则转发算法必须在此静默停止（且消息不得转发）。
2 If there exists a tuple in the duplicate set where:
2如果重复集中存在元组，其中：
D_addr == Originator Address
D_addr==发起者地址
D_seq_num == Message Sequence Number
D_seq_num==消息序列号
Then the message will be further considered for forwarding if and only if:
只有在以下情况下，才会进一步考虑转发该消息：
D_retransmitted is false, AND
D_重新传输为假，并且
the (address of the) interface which received the message is not included among the addresses in D_iface_list
接收消息的（接口地址）不包括在D_iface_列表中的地址中
3 Otherwise, if such an entry doesn't exist, the message is further considered for forwarding.
3否则，如果不存在这样的条目，则进一步考虑转发该消息。
If after those steps, the message is not considered for forwarding, then the processing of this section stops (i.e., steps 4 to 8 are ignored), otherwise, if it is still considered for forwarding then the following algorithm is used:
如果在这些步骤之后，不考虑转发该消息，则该部分的处理停止（即忽略步骤4至8），否则，如果仍考虑转发，则使用以下算法：
4 If the sender interface address is an interface address of a MPR selector of this node and if the time to live of the message is greater than '1', the message MUST be retransmitted (as described later in steps 6 to 8).
4如果发送方接口地址是该节点MPR选择器的接口地址，并且如果消息的生存时间大于“1”，则必须重新传输该消息（如后面步骤6至8所述）。
5 If an entry in the duplicate set exists, with same Originator Address, and same Message Sequence Number, the entry is updated as follows:
5如果重复集合中存在具有相同发起者地址和相同消息序列号的条目，则该条目更新如下：
D_time = current time + DUP_HOLD_TIME.
D_时间=当前时间+重复保持时间。
The receiving interface (address) is added to D_iface_list.
接收接口（地址）被添加到D_iface_列表中。
D_retransmitted is set to true if and only if the message will be retransmitted according to step 4.
当且仅当消息将根据步骤4重新传输时，D_retransmitted设置为true。
Otherwise an entry in the duplicate set is recorded with:
否则，重复集合中的条目将记录为：
D_addr = Originator Address
D_addr = Originator Address
D_seq_num = Message Sequence Number
D_seq_num = Message Sequence Number
D_time = current time + DUP_HOLD_TIME.
D_时间=当前时间+重复保持时间。
D_iface_list contains the receiving interface address.
D_iface_列表包含接收接口地址。
D_retransmitted is set to true if and only if the message will be retransmitted according to step 4.
当且仅当消息将根据步骤4重新传输时，D_retransmitted设置为true。
If, and only if, according to step 4, the message must be retransmitted then:
如果且仅当根据步骤4，必须重新传输消息时，则：
6 The TTL of the message is reduced by one.
6消息的TTL减少1。
7 The hop-count of the message is increased by one
7消息的跃点计数增加1
8 The message is broadcast on all interfaces (Notice: The remaining fields of the message header SHOULD be left unmodified.)
8消息在所有接口上广播（注意：消息头的其余字段应保持不变。）
It should be noted that processing and forwarding messages are two different actions, conditioned by different rules. Processing relates to using the content of the messages, while forwarding is related to retransmitting the same message for other nodes of the network.
应该注意的是，处理和转发消息是两种不同的操作，受不同规则的制约。处理涉及使用消息的内容，而转发涉及为网络的其他节点重新传输相同的消息。
Notice that this specification includes a description for both the forwarding and the processing of each known message type. Messages with known message types MUST *NOT* be forwarded "blindly" by this algorithm. Forwarding (and setting the correct message header in the forwarded, known, message) is the responsibility of the algorithm specifying how the message is to be handled and, if necessary, retransmitted. This enables a message type to be specified such that the message can be modified while in transit (e.g., to reflect the route the message has taken). It also enables bypassing of the MPR flooding mechanism if for some reason classical flooding of a message type is required, the algorithm which specifies how such messages should be handled will simply rebroadcast the message, regardless of MPRs.
请注意，此规范包括对每个已知消息类型的转发和处理的描述。具有已知消息类型的消息不得通过此算法“盲目”转发。转发（并在转发的已知消息中设置正确的消息头）是算法的责任，该算法指定如何处理消息，以及在必要时重新传输消息。这使得可以指定消息类型，以便在传输过程中修改消息（例如，反映消息所采用的路由）。如果出于某种原因需要消息类型的经典泛洪，则它还可以绕过MPR泛洪机制。指定如何处理此类消息的算法将简单地重播消息，而不考虑MPR。
By defining a set of message types, which MUST be recognized by all implementations of OLSR, it will be possible to extend the protocol through introduction of additional message types, while still being able to maintain compatibility with older implementations. The REQUIRED message types for the core functionality of OLSR are:
通过定义一组必须由OLSR的所有实现识别的消息类型，可以通过引入其他消息类型来扩展协议，同时仍然能够保持与旧实现的兼容性。OLSR核心功能所需的消息类型包括：
- HELLO-messages, performing the task of link sensing, neighbor detection and MPR signaling,
- HELLO消息，执行链路感知、邻居检测和MPR信令任务，
- TC-messages, performing the task of topology declaration (advertisement of link states).
- TC消息，执行拓扑声明任务（公布链路状态）。
- MID-messages, performing the task of declaring the presence of multiple interfaces on a node.
- MID消息，执行声明节点上存在多个接口的任务。
Other message types include those specified in later sections, as well as possible future extensions such as messages enabling power conservation / sleep mode, multicast routing, support for unidirectional links, auto-configuration/address assignment etc.
其他消息类型包括后面章节中指定的消息类型，以及将来可能的扩展，如启用节能/休眠模式的消息、多播路由、支持单向链路、自动配置/地址分配等。
As a basic implementation requirement, synchronization of control messages SHOULD be avoided. As a consequence, OLSR control messages SHOULD be emitted such that they avoid synchronization.
作为一项基本的实现要求，应该避免控制消息的同步。因此，应发出OLSR控制消息，以避免同步。
Emission of control traffic from neighboring nodes may, for various reasons (mainly timer interactions with packet processing), become synchronized such that several neighbor nodes attempt to transmit control traffic simultaneously. Depending on the nature of the underlying link-layer, this may or may not lead to collisions and hence message loss - possibly loss of several subsequent messages of the same type.
由于各种原因（主要是与分组处理的定时器交互），来自相邻节点的控制流量的发射可能变得同步，使得多个相邻节点尝试同时发送控制流量。根据底层链接层的性质，这可能会或可能不会导致冲突，从而导致消息丢失-可能会丢失同一类型的多条后续消息。
To avoid such synchronizations, the following simple strategy for emitting control messages is proposed. A node SHOULD add an amount of jitter to the interval at which messages are generated. The jitter must be a random value for each message generated. Thus, for a node utilizing jitter:
为了避免这种同步，提出了以下发送控制消息的简单策略。节点应在生成消息的间隔中添加一定数量的抖动。抖动必须是生成的每条消息的随机值。因此，对于利用抖动的节点：
Actual message interval = MESSAGE_INTERVAL - jitter
实际消息间隔=消息间隔-抖动
Where jitter is a value, randomly selected from the interval [0,MAXJITTER] and MESSAGE_INTERVAL is the value of the message interval specified for the message being emitted (e.g., HELLO_INTERVAL for HELLO messages, TC_INTERVAL for TC-messages etc.).
其中jitter是一个值，从间隔[0，MAXJITTER]中随机选择，MESSAGE_interval是为发出的消息指定的消息间隔的值（例如，HELLO消息的HELLO_interval，TC消息的TC_interval等）。
Jitter SHOULD also be introduced when forwarding messages. The following simple strategy may be adopted: when a message is to be forwarded by a node, it should be kept in the node during a short period of time :
转发消息时还应引入抖动。可以采用以下简单策略：当节点转发消息时，应在短时间内将其保存在节点中：
Keep message period = jitter
保持消息周期=抖动
Where jitter is a random value in [0,MAXJITTER].
其中jitter是[0，MAXJITTER]中的随机值。
Notice that when the node sends a control message, the opportunity to piggyback other messages (before their keeping period is expired) may be taken to reduce the number of packet transmissions.
注意，当节点发送控制消息时，可以利用搭载其他消息的机会（在它们的保持期到期之前）来减少分组传输的数量。
Notice, that a minimal rate of control messages is imposed. A node MAY send control messages at a higher rate, if beneficial for a specific deployment.
请注意，施加了最小速率的控制消息。如果有利于特定部署，节点可以以更高的速率发送控制消息。
Through the exchange of OLSR control messages, each node accumulates information about the network. This information is stored according to the descriptions in this section.
通过交换OLSR控制消息，每个节点积累有关网络的信息。此信息根据本节中的说明存储。
For each destination in the network, "Interface Association Tuples" (I_iface_addr, I_main_addr, I_time) are recorded. I_iface_addr is an interface address of a node, I_main_addr is the main address of this node. I_time specifies the time at which this tuple expires and *MUST* be removed.
对于网络中的每个目的地，记录“接口关联元组”（I_iface_addr、I_main_addr、I_time）。I_iface_addr是节点的接口地址，I_main_addr是该节点的主地址。I_time指定此元组过期和*必须*删除的时间。
In a node, the set of Interface Association Tuples is denoted the "Interface Association Set".
在节点中，接口关联元组集表示为“接口关联集”。
The local link information base stores information about links to neighbors.
本地链接信息库存储有关到邻居的链接的信息。
A node records a set of "Link Tuples" (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, L_ASYM_time, L_time). L_local_iface_addr is the interface address of the local node (i.e., one endpoint of the link), L_neighbor_iface_addr is the interface address of the neighbor node (i.e., the other endpoint of the link), L_SYM_time is the time until which the link is considered symmetric, L_ASYM_time is the time until which the neighbor interface is considered heard, and L_time specifies the time at which this record expires and *MUST* be removed. When L_SYM_time and L_ASYM_time are expired, the link is considered lost.
节点记录一组“链接元组”（L_local_iface_addr、L_neighbor_iface_addr、L_SYM_time、L_ASYM_time、L_time）。L_local_iface_addr是本地节点（即链路的一个端点）的接口地址，L_neighbor_iface_addr是邻居节点（即链路的另一个端点）的接口地址，L_SYM_time是链路被视为对称的时间，L_ASYM_time是认为听到邻居接口的时间，L_time指定此记录过期和*必须*删除的时间。当L_SYM_时间和L_ASYM_时间过期时，链接被视为丢失。
This information is used when declaring the neighbor interfaces in the HELLO messages.
在HELLO消息中声明邻居接口时使用此信息。
L_SYM_time is used to decide the Link Type declared for the neighbor interface. If L_SYM_time is not expired, the link MUST be declared symmetric. If L_SYM_time is expired, the link MUST be declared asymmetric. If both L_SYM_time and L_ASYM_time are expired, the link MUST be declared lost.
L_SYM_time用于确定为邻居接口声明的链路类型。如果L_SYM_time未过期，则必须声明链路对称。如果L_SYM_time过期，则必须声明链接为非对称。如果L_SYM_时间和L_ASYM_时间均已过期，则必须声明链接已丢失。
In a node, the set of Link Tuples are denoted the "Link Set".
在节点中，链接元组集表示为“链接集”。
The neighborhood information base stores information about neighbors, 2-hop neighbors, MPRs and MPR selectors.
邻居信息库存储有关邻居、2跳邻居、MPR和MPR选择器的信息。
A node records a set of "neighbor tuples" (N_neighbor_main_addr, N_status, N_willingness), describing neighbors. N_neighbor_main_addr is the main address of a neighbor, N_status specifies if the node is NOT_SYM or SYM. N_willingness in an integer between 0 and 7, and specifies the node's willingness to carry traffic on behalf of other nodes.
一个节点记录一组描述邻居的“邻居元组”（N_neighbor_main_addr、N_status、N_意愿）。N_neighbor\u main\u addr是邻居的主地址，N_status指定节点是非SYM还是SYM。N_意愿为0到7之间的整数，并指定节点代表其他节点承载流量的意愿。
A node records a set of "2-hop tuples" (N_neighbor_main_addr, N_2hop_addr, N_time), describing symmetric (and, since MPR links by definition are also symmetric, thereby also MPR) links between its neighbors and the symmetric 2-hop neighborhood. N_neighbor_main_addr is the main address of a neighbor, N_2hop_addr is the main address of a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, and N_time specifies the time at which the tuple expires and *MUST* be removed.
节点记录一组“2-hop元组”（N_neighbor_main_addr，N_2hop_addr，N_time），描述其邻居和对称2-hop邻居之间的对称（并且，由于MPR链路根据定义也是对称的，因此也是MPR）链路。N_neighbor_main_addr是邻居的主地址，N_2hop_addr是具有到N_neighbor_main_addr的对称链接的2跳邻居的主地址，N_time指定元组过期和*必须*删除的时间。
In a node, the set of 2-hop tuples are denoted the "2-hop Neighbor Set".
在节点中，两跳元组集表示为“两跳邻居集”。
A node maintains a set of neighbors which are selected as MPR. Their main addresses are listed in the MPR Set.
节点维护一组被选为MPR的邻居。他们的主要地址列在MPR集合中。
A node records a set of MPR-selector tuples (MS_main_addr, MS_time), describing the neighbors which have selected this node as a MPR. MS_main_addr is the main address of a node, which has selected this node as MPR. MS_time specifies the time at which the tuple expires and *MUST* be removed.
节点记录一组MPR选择器元组（MS_main_addr，MS_time），描述选择此节点作为MPR的邻居。MS_main_addr是节点的主地址，该节点已选择此节点作为MPR。MS_time指定元组过期和*必须*删除的时间。
In a node, the set of MPR-selector tuples are denoted the "MPR Selector Set".
在节点中，MPR选择器元组集表示为“MPR选择器集”。
Each node in the network maintains topology information about the network. This information is acquired from TC-messages and is used for routing table calculations.
网络中的每个节点都维护有关网络的拓扑信息。此信息从TC消息中获取，并用于路由表计算。
Thus, for each destination in the network, at least one "Topology Tuple" (T_dest_addr, T_last_addr, T_seq, T_time) is recorded. T_dest_addr is the main address of a node, which may be reached in one hop from the node with the main address T_last_addr. Typically, T_last_addr is a MPR of T_dest_addr. T_seq is a sequence number, and T_time specifies the time at which this tuple expires and *MUST* be removed.
因此，对于网络中的每个目的地，至少记录一个“拓扑元组”（T_dest_addr，T_last_addr，T_seq，T_time）。T_dest_addr是节点的主地址，从主地址T_last_addr的节点一跳就可以到达。通常，T_last_addr是T_dest_addr的MPR。T_seq是一个序列号，T_time指定此元组过期和*必须*删除的时间。
In a node, the set of Topology Tuples are denoted the "Topology Set".
在节点中，拓扑元组集表示为“拓扑集”。
For single OLSR interface nodes, the relationship between an OLSR interface address and the corresponding main address is trivial: the main address is the OLSR interface address. For multiple OLSR interface nodes, the relationship between OLSR interface addresses and main addresses is defined through the exchange of Multiple Interface Declaration (MID) messages. This section describes how MID messages are exchanged and processed.
对于单个OLSR接口节点，OLSR接口地址和相应的主地址之间的关系很简单：主地址就是OLSR接口地址。对于多个OLSR接口节点，OLSR接口地址和主地址之间的关系通过交换多个接口声明（MID）消息来定义。本节介绍如何交换和处理MID消息。
Each node with multiple interfaces MUST announce, periodically, information describing its interface configuration to other nodes in the network. This is accomplished through flooding a Multiple Interface Declaration message to all nodes in the network through the MPR flooding mechanism.
具有多个接口的每个节点必须定期向网络中的其他节点宣布描述其接口配置的信息。这是通过MPR泛洪机制将多接口声明消息泛洪到网络中的所有节点来实现的。
Each node in the network maintains interface information about the other nodes in the network. This information acquired from MID messages, emitted by nodes with multiple interfaces participating in the MANET, and is used for routing table calculations.
网络中的每个节点维护有关网络中其他节点的接口信息。该信息从MID消息中获取，由参与MANET的具有多个接口的节点发出，并用于路由表计算。
Specifically, multiple interface declaration associates multiple interfaces to a node (and to a main address) through populating the multiple interface association base in each node.
具体地说，多接口声明通过在每个节点中填充多接口关联库，将多个接口关联到一个节点（和一个主地址）。
The proposed format of a MID message is as follows:
MID报文的建议格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data-portion of the general packet format described in section 3.4, with the "Message Type" set to MID_MESSAGE. The time to live SHOULD be set to 255 (maximum value) to diffuse the message into the entire network and Vtime set accordingly to the value of MID_HOLD_TIME, as specified in section 18.3.
这是作为第3.4节中描述的通用数据包格式的数据部分发送的，“消息类型”设置为MID_消息。应将生存时间设置为255（最大值），以将消息扩散到整个网络中，并根据第18.3节规定的MID_HOLD_time值设置Vtime。
OLSR Interface Address
OLSR接口地址
This field contains the address of an OLSR interface of the node, excluding the nodes main address (which already indicated in the originator address).
此字段包含节点的OLSR接口地址，不包括节点主地址（已在发起者地址中指示）。
All interface addresses other than the main address of the originator node are put in the MID message. If the maximum allowed message size (as imposed by the network) is reached while there are still interface addresses which have not been inserted into the MIDmessage, more MID messages are generated until the entire interface addresses set has been sent.
除了发端节点的主地址之外的所有接口地址都放在MID消息中。如果在仍有未插入MIDmessage的接口地址的情况下，达到了允许的最大消息大小（由网络强制），则会生成更多MID消息，直到发送了整个接口地址集。
A MID message is sent by a node in the network to declare its multiple interfaces (if any). I.e., the MID message contains the list of interface addresses which are associated to its main address. The list of addresses can be partial in each MID message (e.g., due to message size limitations, imposed by the network), but parsing of all MID messages describing the interface set from a node MUST be complete within a certain refreshing period (MID_INTERVAL). The information diffused in the network by these MID messages will help each node to calculate its routing table. A node which has only a single interface address participating in the MANET (i.e., running OLSR), MUST NOT generate any MID message.
MID消息由网络中的节点发送，以声明其多个接口（如果有）。即，MID消息包含与其主地址相关联的接口地址列表。每个MID消息中的地址列表可以是部分的（例如，由于网络施加的消息大小限制），但描述节点接口集的所有MID消息的解析必须在某个刷新周期（MID_间隔）内完成。这些MID消息在网络中传播的信息将帮助每个节点计算其路由表。只有一个接口地址参与MANET（即运行OLSR）的节点不得生成任何MID消息。
A node with several interfaces, where only one is participating in the MANET and running OLSR (e.g., a node is connected to a wired network as well as to a MANET) MUST NOT generate any MID messages.
具有多个接口的节点，其中只有一个参与MANET并运行OLSR（例如，一个节点连接到有线网络以及MANET），不得生成任何MID消息。
A node with several interfaces, where more than one is participating in the MANET and running OLSR MUST generate MID messages as specified.
具有多个接口的节点（其中多个节点参与MANET并运行OLSR）必须按照指定生成MID消息。
MID messages are broadcast and retransmitted by the MPRs in order to diffuse the messages in the entire network. The "default forwarding algorithm" (described in section 3.4) MUST be used for forwarding of MID messages.
MID消息由MPR广播和重新传输，以便在整个网络中传播消息。“默认转发算法”（如第3.4节所述）必须用于转发MID消息。
The tuples in the multiple interface association set are recorded with the information that is exchanged through MID messages.
多接口关联集中的元组记录有通过MID消息交换的信息。
Upon receiving a MID message, the "validity time" MUST be computed from the Vtime field of the message header (as described in section 3.3.2). The Multiple Interface Association Information Base SHOULD then be updated as follows:
收到MID消息后，必须从消息头的Vtime字段计算“有效时间”（如第3.3.2节所述）。然后，应按如下方式更新多接口关联信息库：
1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded.
1如果此消息的发送方接口（NB：非发起方）不在此节点的对称1跳邻居中，则必须丢弃该消息。
2 For each interface address listed in the MID message:
2对于MID消息中列出的每个接口地址：
2.1 If there exist some tuple in the interface association set where:
2.1 如果接口关联集中存在某些元组，其中：
I_iface_addr == interface address, AND
I_iface_addr==接口地址，以及
I_main_addr == originator address,
I_main_addr==发起人地址，
then the holding time of that tuple is set to:
然后将该元组的保持时间设置为：
I_time = current time + validity time.
I_时间=当前时间+有效时间。
2.2 Otherwise, a new tuple is recorded in the interface association set where:
2.2 否则，将在接口关联集中记录一个新元组，其中：
I_iface_addr = interface address,
I_iface_addr=接口地址，
I_main_addr = originator address,
I_main_addr=发起人地址，
I_time = current time + validity time.
I_时间=当前时间+有效时间。
In general, the only part of OLSR requiring use of "interface addresses" is link sensing. The remaining parts of OLSR operate on nodes, uniquely identified by their "main addresses" (effectively, the main address of a node is its "node id" - which for convenience corresponds to the address of one of its interfaces). In a network with only single interface nodes, the main address of a node will, by definition, be equal to the interface address of the node. In networks with multiple interface nodes operating within a common OLSR area, it is required to be able to map any interface address to the corresponding main address.
通常，OLSR中唯一需要使用“接口地址”的部分是链路感知。OLSR的其余部分在节点上运行，由节点的“主地址”唯一标识（实际上，节点的主地址是其“节点id”-为了方便起见，其对应于其一个接口的地址）。在只有单个接口节点的网络中，根据定义，节点的主地址将等于节点的接口地址。在多个接口节点在公共OLSR区域内运行的网络中，需要能够将任何接口地址映射到相应的主地址。
The exchange of MID messages provides a way in which interface information is acquired by nodes in the network. This permits identification of a node's "main address", given one of its interface addresses.
MID消息的交换提供了一种由网络中的节点获取接口信息的方式。这允许识别节点的“主地址”，给定其一个接口地址。
Given an interface address:
给定接口地址：
1 if there exists some tuple in the interface association set where:
1如果接口关联集中存在某个元组，其中：
I_iface_addr == interface address
I_iface_addr==接口地址
then the result of the main address search is the originator address I_main_addr of the tuple.
然后，主地址搜索的结果是元组的发起者地址I_main_addr。
2 Otherwise, the result of the main address search is the interface address itself.
2否则，主地址搜索的结果就是接口地址本身。
A common mechanism is employed for populating the local link information base and the neighborhood information base, namely periodic exchange of HELLO messages. Thus this section describes the general HELLO message mechanism, followed by a description of link sensing and topology detection, respectively.
采用一种通用机制来填充本地链路信息库和邻域信息库，即定期交换HELLO消息。因此，本节描述了一般的HELLO消息机制，然后分别描述了链路感知和拓扑检测。
To accommodate for link sensing, neighborhood detection and MPR selection signalling, as well as to accommodate for future extensions, an approach similar to the overall packet format is taken. Thus the proposed format of a HELLO message is as follows:
为了适应链路感测、邻域检测和MPR选择信令，以及适应未来的扩展，采用了一种类似于整体分组格式的方法。因此，HELLO消息的建议格式如下所示：
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Htime | Willingness |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . . . :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
(etc.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Htime | Willingness |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . . . :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
(etc.)
This is sent as the data-portion of the general packet format described in section 3.4, with the "Message Type" set to HELLO_MESSAGE, the TTL field set to 1 (one) and Vtime set accordingly to the value of NEIGHB_HOLD_TIME, specified in section 18.3.
它作为第3.4节中描述的通用数据包格式的数据部分发送，其中“消息类型”设置为HELLO_消息，TTL字段设置为1（一），Vtime设置为与第18.3节中规定的NEIGHB_HOLD_TIME值相应的值。
Reserved
含蓄的
This field must be set to "0000000000000" to be in compliance with this specification.
此字段必须设置为“0000000000000”才能符合本规范。
HTime
时可通
This field specifies the HELLO emission interval used by the node on this particular interface, i.e., the time before the transmission of the next HELLO (this information may be used in advanced link sensing, see section 14). The HELLO emission interval is represented by its mantissa (four highest bits of Htime field) and by its exponent (four lowest bits of Htime field). In other words:
该字段指定该特定接口上的节点使用的HELLO发射间隔，即下一个HELLO发射前的时间（该信息可用于高级链路感知，参见第14节）。HELLO发射间隔由尾数（Htime字段的四个最高位）和指数（Htime字段的四个最低位）表示。换言之：
HELLO emission interval=C*(1+a/16)*2^b [in seconds]
HELLO emission interval=C*(1+a/16)*2^b [in seconds]
where a is the integer represented by the four highest bits of Htime field and b the integer represented by the four lowest bits of Htime field. The proposed value of the scaling factor C is specified in section 18.
其中a是由Htime字段的四个最高位表示的整数，b是由Htime字段的四个最低位表示的整数。第18节规定了比例因子C的建议值。
Willingness
意愿
This field specifies the willingness of a node to carry and forward traffic for other nodes.
此字段指定节点是否愿意为其他节点承载和转发流量。
A node with willingness WILL_NEVER (see section 18.8, for willingness constants) MUST never be selected as MPR by any node. A node with willingness WILL_ALWAYS MUST always be selected as MPR. By default, a node SHOULD advertise a willingness of WILL_DEFAULT.
任何节点不得将具有意愿的节点（参见第18.8节意愿常数）选作MPR。具有意愿的节点始终必须被选择为MPR。默认情况下，一个节点应该公布一个意愿。
Link Code
链接代码
This field specifies information about the link between the interface of the sender and the following list of neighbor interfaces. It also specifies information about the status of the neighbor.
此字段指定有关发送方接口和以下邻居接口列表之间的链接的信息。它还指定有关邻居状态的信息。
Link codes, not known by a node, are silently discarded.
节点不知道的链接代码将被悄悄地丢弃。
Link Message Size
链接消息大小
The size of the link message, counted in bytes and measured from the beginning of the "Link Code" field and until the next "Link Code" field (or - if there are no more link types - the end of the message).
链接消息的大小，以字节为单位，从“链接代码”字段的开头到下一个“链接代码”字段（或者，如果没有更多链接类型，则为消息的结尾）测量。
Neighbor Interface Address
邻居接口地址
The address of an interface of a neighbor node.
邻居节点的接口地址。
This document only specifies processing of Link Codes < 16.
本文件仅规定了小于16的链接代码的处理。
If the Link Code value is less than or equal to 15, then it MUST be interpreted as holding two different fields, of two bits each:
如果链路代码值小于或等于15，则必须将其解释为包含两个不同的字段，每个字段有两位：
7 6 5 4 3 2 1 0
+-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | 0 | 0 | 0 | Neighbor Type | Link Type |
+-------+-------+-------+-------+-------+-------+-------+-------+
7 6 5 4 3 2 1 0
+-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | 0 | 0 | 0 | Neighbor Type | Link Type |
+-------+-------+-------+-------+-------+-------+-------+-------+
The following four "Link Types" are REQUIRED by OLSR:
OLSR要求以下四种“链路类型”：
- UNSPEC_LINK - indicating that no specific information about the links is given.
- UNSPEC_链接-表示未提供有关链接的具体信息。
- ASYM_LINK - indicating that the links are asymmetric (i.e., the neighbor interface is "heard").
- ASYM_链路-表示链路是不对称的（即，邻居接口是“听到的”）。
- SYM_LINK - indicating that the links are symmetric with the interface.
- SYM_链路-表示链路与接口对称。
- LOST_LINK - indicating that the links have been lost.
- 丢失链接-表示链接已丢失。
The following three "Neighbor Types" are REQUIRED by OLSR:
OLSR需要以下三种“邻居类型”：
- SYM_NEIGH - indicating that the neighbors have at least one symmetrical link with this node.
- SYM_NEIGH-表示邻居与该节点至少有一条对称链路。
- MPR_NEIGH - indicating that the neighbors have at least one symmetrical link AND have been selected as MPR by the sender.
- MPR_NEIGH-表示邻居至少有一个对称链路，并且已被发送方选择为MPR。
- NOT_NEIGH - indicating that the nodes are either no longer or have not yet become symmetric neighbors.
- NOT_NEIGH-表示节点不再是或尚未成为对称邻居。
Note that an implementation should be careful in confusing neither Link Type with Neighbor Type nor the constants (confusing SYM_NEIGH with SYM_LINK for instance).
注意，一个实现在混淆链接类型和邻居类型以及常量时应该小心（例如，混淆SYM_NEIGH和SYM_Link）。
A link code advertising:
链接代码广告：
Link Type == SYM_LINK AND
链路类型==SYM_链路和
Neighbor Type == NOT_NEIGH
邻居类型==不相邻
is invalid, and any links advertised as such MUST be silently discarded without any processing.
是无效的，因此必须在不进行任何处理的情况下以静默方式丢弃作为广告的任何链接。
Likewise a Neighbor Type field advertising a numerical value which is not one of the constants SYM_NEIGH, MPR_NEIGH, NOT_NEIGH, is invalid, and any links advertised as such MUST be silently discarded without any processing.
同样地，一个邻居类型字段公布的数值不是常数SYM_NEIGH、MPR_NEIGH、not_NEIGH中的一个，它是无效的，任何这样公布的链接都必须在没有任何处理的情况下被悄悄地丢弃。
This involves transmitting the Link Set, the Neighbor Set and the MPR Set. In principle, a HELLO message serves three independent tasks:
这涉及传输链路集、邻居集和MPR集。原则上，HELLO消息服务于三个独立的任务：
- link sensing
- 链路感应
- neighbor detection
- 邻居检测
- MPR selection signaling
- MPR选择信令
Three tasks are all are based on periodic information exchange within a nodes neighborhood, and serve the common purpose of "local topology discovery". A HELLO message is therefore generated based on the information stored in the Local Link Set, the Neighbor Set and the MPR Set from the local link information base.
这三项任务都是基于节点邻域内的周期性信息交换，并服务于“局部拓扑发现”的共同目的。因此，基于存储在本地链路集合、邻居集合和来自本地链路信息库的MPR集合中的信息来生成HELLO消息。
A node must perform link sensing on each interface, in order to detect links between the interface and neighbor interfaces. Furthermore, a node must advertise its entire symmetric 1-hop neighborhood on each interface in order to perform neighbor detection. Hence, for a given interface, a HELLO message will contain a list of links on that interface (with associated link types), as well as a list of the entire neighborhood (with an associated neighbor types).
节点必须在每个接口上执行链路感知，以便检测接口和相邻接口之间的链路。此外，节点必须在每个接口上公布其整个对称1跳邻居，以便执行邻居检测。因此，对于给定的接口，HELLO消息将包含该接口上的链接列表（具有关联的链接类型），以及整个邻居列表（具有关联的邻居类型）。
The Vtime field is set such that it corresponds to the value of the node's NEIGHB_HOLD_TIME parameter. The Htime field is set such that it corresponds to the value of the node's HELLO_INTERVAL parameter (see section 18.3).
Vtime字段设置为与节点的NEIGHB_HOLD_TIME参数的值相对应。设置Htime字段，使其与节点的HELLO_INTERVAL参数的值相对应（参见第18.3节）。
The Willingness field is set such that it corresponds to the node's willingness to forward traffic on behalf of other nodes (see section 18.8). A node MUST advertise the same willingness on all interfaces.
意愿字段的设置应与节点代表其他节点转发流量的意愿相对应（参见第18.8节）。节点必须在所有接口上公布相同的意愿。
The lists of addresses declared in a HELLO message is a list of neighbor interface addresses computed as follows:
HELLO消息中声明的地址列表是按如下方式计算的邻居接口地址列表：
For each tuple in the Link Set, where L_local_iface_addr is the interface where the HELLO is to be transmitted, and where L_time >= current time (i.e., not expired), L_neighbor_iface_addr is advertised with:
对于链路集中的每个元组，其中L_local_iface_addr是要传输HELLO的接口，而L_time>=当前时间（即，未过期），L_neighbor_iface_addr通过以下方式进行广告：
1 The Link Type set according to the following:
1根据以下内容设置的链路类型：
1.1 if L_SYM_time >= current time (not expired)
1.1 如果L_SYM_time>=当前时间（未过期）
Link Type = SYM_LINK
链路类型=SYM_链路
1.2 Otherwise, if L_ASYM_time >= current time (not expired) AND
1.2 否则，如果L_ASYM_time>=当前时间（未过期），并且
L_SYM_time < current time (expired)
L_SYM_时间<当前时间（过期）
Link Type = ASYM_LINK
链路类型=异步链路
1.3 Otherwise, if L_ASYM_time < current time (expired) AND
1.3 否则，如果L_ASYM_time<当前时间（过期），并且
L_SYM_time < current time (expired)
L_SYM_时间<当前时间（过期）
Link Type = LOST_LINK
链接类型=丢失的链接
2 The Neighbor Type is set according to the following:
2邻居类型的设置如下：
2.1 If the main address, corresponding to L_neighbor_iface_addr, is included in the MPR set:
2.1 如果MPR集合中包含与L_neighbor_iface_addr相对应的主地址：
Neighbor Type = MPR_NEIGH
邻居类型=MPR_NEIGH
2.2 Otherwise, if the main address, corresponding to L_neighbor_iface_addr, is included in the neighbor set:
2.2 否则，如果与L_neighbor_iface_addr相对应的主地址包含在邻居集中：
2.2.1 if N_status == SYM
2.2.1 如果N_状态==SYM
Neighbor Type = SYM_NEIGH
邻居类型=SYM_NEIGH
2.2.2 Otherwise, if N_status == NOT_SYM Neighbor Type = NOT_NEIGH
2.2.2 否则，如果N_status==NOT_SYM Neighbor Type=NOT_NEIGH
For each tuple in the Neighbor Set, for which no L_neighbor_iface_addr from an associated link tuple has been advertised by the previous algorithm, N_neighbor_main_addr is advertised with:
对于邻居集中的每个元组，如果前面的算法没有公布来自关联链路元组的L_Neighbor_iface_addr，则N_Neighbor_main_addr将通过以下方式公布：
- Link Type = UNSPEC_LINK,
- 链路类型=UNSPEC_链路，
- Neighbor Type set as described in step 2 above
- 如上步骤2所述的邻居类型集
For a node with a single OLSR interface, the main address is simply the address of the OLSR interface, i.e., for a node with a single OLSR interface the main address, corresponding to L_neighbor_iface_addr is simply L_neighbor_iface_addr.
对于具有单个OLSR接口的节点，主地址仅为OLSR接口的地址，即对于具有单个OLSR接口的节点，对应于L_neighbor_iface_addr的主地址仅为L_neighbor_iface_addr。
A HELLO message can be partial (e.g., due to message size limitations, imposed by the network), the rule being the following, on each interface: each link and each neighbor node MUST be cited at least once within a predetermined refreshing period, REFRESH_INTERVAL. To keep track of fast connectivity changes, a HELLO message must be sent at least every HELLO_INTERVAL period, smaller than or equal to REFRESH_INTERVAL.
HELLO消息可以是部分的（例如，由于网络施加的消息大小限制），规则如下，在每个接口上：每个链路和每个邻居节点必须在预定的刷新周期、刷新间隔内至少被引用一次。要跟踪快速连接更改，必须至少在每个HELLO_间隔期间（小于或等于REFRESH_间隔）发送HELLO消息。
Notice that for limiting the impact from loss of control messages, it is desirable that a message (plus the generic packet header) can fit into a single MAC frame.
请注意，为了限制控制消息丢失的影响，需要将消息（加上通用分组报头）放入单个MAC帧中。
Each HELLO message generated is broadcast by the node on one interface to its neighbors (i.e. the interface for which the HELLO was generated). HELLO messages MUST never be forwarded.
生成的每个HELLO消息由节点在一个接口上广播给其邻居（即生成HELLO的接口）。“你好”消息绝对不能转发。
A node processes incoming HELLO messages for the purpose of conducting link sensing (detailed in section 7), neighbor detection and MPR selector set population (detailed in section 8)
节点处理传入的HELLO消息，以进行链路感知（详见第7节）、邻居检测和MPR选择器集填充（详见第8节）
Link sensing populates the local link information base. Link sensing is exclusively concerned with OLSR interface addresses and the ability to exchange packets between such OLSR interfaces.
链路感应填充本地链路信息库。链路感知专门涉及OLSR接口地址以及在此类OLSR接口之间交换数据包的能力。
The mechanism for link sensing is the periodic exchange of HELLO messages.
链路感知的机制是定期交换HELLO消息。
The Link Set is populated with information on links to neighbor nodes. The process of populating this set is denoted "link sensing" and is performed using HELLO message exchange, updating a local link information base in each node.
链接集填充了有关到相邻节点的链接的信息。填充此集合的过程表示为“链路感知”，并使用HELLO消息交换执行，更新每个节点中的本地链路信息库。
Each node should detect the links between itself and neighbor nodes. Uncertainties over radio propagation may make some links unidirectional. Consequently, all links MUST be checked in both directions in order to be considered valid.
每个节点都应该检测自身和相邻节点之间的链路。无线传播的不确定性可能使某些链路具有单向性。因此，必须在两个方向上检查所有链接，才能将其视为有效链接。
A "link" is described by a pair of interfaces: a local and a remote interface.
“链接”由一对接口描述：本地接口和远程接口。
For the purpose of link sensing, each neighbor node (more specifically, the link to each neighbor) has an associated status of either "symmetric" or "asymmetric". "Symmetric" indicates, that the link to that neighbor node has been verified to be bi-directional, i.e., it is possible to transmit data in both directions. "Asymmetric" indicates that HELLO messages from the node have been
为了链路感测的目的，每个邻居节点（更具体地说，到每个邻居的链路）具有“对称”或“非对称”的关联状态。“对称”表示到该邻居节点的链路已被验证为双向的，即，可以在两个方向上传输数据。“不对称”表示来自节点的HELLO消息已被删除
heard (i.e., communication from the neighbor node is possible), however it is not confirmed that this node is also able to receive messages (i.e., communication to the neighbor node is not confirmed).
已听到（即，可以从邻居节点进行通信），但是未确认该节点也能够接收消息（即，未确认与邻居节点的通信）。
The information, acquired through and used by the link sensing, is accumulated in the link set.
通过链路感测获取并由链路感测使用的信息累积在链路集中。
The "Originator Address" of a HELLO message is the main address of the node, which has emitted the message.
HELLO消息的“发起者地址”是发出消息的节点的主地址。
Upon receiving a HELLO message, a node SHOULD update its Link Set. Notice, that a HELLO message MUST neither be forwarded nor be recorded in the duplicate set.
收到HELLO消息后，节点应更新其链接集。请注意，HELLO消息既不能转发，也不能记录在重复集中。
Upon receiving a HELLO message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). Then, the Link Set SHOULD be updated as follows:
收到HELLO消息后，必须从消息头的Vtime字段计算“有效时间”（见第3.3.2节）。然后，链接集应更新如下：
1 Upon receiving a HELLO message, if there exists no link tuple with
1在收到HELLO消息时，如果不存在与的链接元组
L_neighbor_iface_addr == Source Address
L_neighbor_iface_addr==源地址
a new tuple is created with
一个新的元组是用
L_neighbor_iface_addr = Source Address
L_neighbor_iface_addr = Source Address
L_local_iface_addr = Address of the interface which received the HELLO message
L_local_iface_addr=接收HELLO消息的接口地址
L_SYM_time = current time - 1 (expired)
L_SYM_time=当前时间-1（过期）
L_time = current time + validity time
L_时间=当前时间+有效时间
2 The tuple (existing or new) with:
2元组（现有或新）包含：
L_neighbor_iface_addr == Source Address
L_neighbor_iface_addr==源地址
is then modified as follows:
然后修改如下：
2.1 L_ASYM_time = current time + validity time;
2.1 L_ASYM_time = current time + validity time;
2.2 if the node finds the address of the interface which received the HELLO message among the addresses listed in the link message then the tuple is modified as follows:
2.2 如果节点在链接消息中列出的地址中找到接收HELLO消息的接口的地址，则元组修改如下：
2.2.1 if Link Type is equal to LOST_LINK then
2.2.1 如果链接类型等于丢失的链接，则
L_SYM_time = current time - 1 (i.e., expired)
L_SYM_time=当前时间-1（即过期）
2.2.2 else if Link Type is equal to SYM_LINK or ASYM_LINK then
2.2.2 否则，如果链接类型等于SYM_链接或ASYM_链接，则
L_SYM_time = current time + validity time,
L_SYM_时间=当前时间+有效时间，
L_time = L_SYM_time + NEIGHB_HOLD_TIME
L_时间=L_符号时间+相邻保持时间
2.3 L_time = max(L_time, L_ASYM_time)
2.3 L_时间=最大值（L_时间，L_同步时间）
The above rule for setting L_time is the following: a link losing its symmetry SHOULD still be advertised during at least the duration of the "validity time" advertised in the generated HELLO. This allows neighbors to detect the link breakage.
设置L_时间的上述规则如下：丢失对称性的链接至少应在生成的HELLO中公布的“有效期”期间公布。这允许邻居检测链路中断。
Neighbor detection populates the neighborhood information base and concerns itself with nodes and node main addresses. The relationship between OLSR interface addresses and main addresses is described in section 5.
邻居检测填充邻居信息库，并关注节点和节点主地址。第5节描述了OLSR接口地址和主地址之间的关系。
The mechanism for neighbor detection is the periodic exchange of HELLO messages.
邻居检测的机制是定期交换HELLO消息。
A node maintains a set of neighbor tuples, based on the link tuples. This information is updated according to changes in the Link Set.
节点根据链接元组维护一组邻居元组。此信息将根据链接集中的更改进行更新。
The Link Set keeps the information about the links, while the Neighbor Set keeps the information about the neighbors. There is a clear association between those two sets, since a node is a neighbor of another node if and only if there is at least one link between the two nodes.
链接集保留有关链接的信息，而邻居集保留有关邻居的信息。这两个集合之间存在明确的关联，因为一个节点是另一个节点的邻居，当且仅当两个节点之间至少存在一条链路时。
In any case, the formal correspondence between links and neighbors is defined as follows:
在任何情况下，链路和邻居之间的正式通信定义如下：
The "associated neighbor tuple" of a link tuple, is, if it exists, the neighbor tuple where:
链接元组的“关联邻居元组”（如果存在）是邻居元组，其中：
N_neighbor_main_addr == main address of L_neighbor_iface_addr
N_neighbor_main_addr==L_neighbor_iface_addr的主地址
The "associated link tuples" of a neighbor tuple, are all the link tuples, where:
相邻元组的“关联链接元组”是所有链接元组，其中：
N_neighbor_main_addr == main address of L_neighbor_iface_addr
N_neighbor_main_addr==L_neighbor_iface_addr的主地址
The Neighbor Set MUST be populated by maintaining the proper correspondence between link tuples and associated neighbor tuples, as follows:
必须通过保持链接元组和关联的邻居元组之间的正确对应来填充邻居集，如下所示：
Creation
创造
Each time a link appears, that is, each time a link tuple is created, the associated neighbor tuple MUST be created, if it doesn't already exist, with the following values:
每次出现链接时，即每次创建链接元组时，必须使用以下值创建关联的相邻元组（如果它不存在）：
N_neighbor_main_addr = main address of L_neighbor_iface_addr (from the link tuple)
N\u neighbor\u main\u addr=L\u neighbor\u iface\u addr的主地址（来自链接元组）
In any case, the N_status MUST then be computed as described in the next step
在任何情况下，必须按照下一步中的说明计算N_状态
Update
使现代化
Each time a link changes, that is, each time the information of a link tuple is modified, the node MUST ensure that the N_status of the associated neighbor tuple respects the property:
每次更改链接时，即每次修改链接元组的信息时，节点必须确保关联的相邻元组的N_状态尊重以下属性：
If the neighbor has any associated link tuple which indicates a symmetric link (i.e., with L_SYM_time >= current time), then
如果邻居有任何指示对称链路的关联链路元组（即，L_SYM_time>=当前时间），则
N_status is set to SYM
N_状态设置为SYM
else N_status is set to NOT_SYM
否则N_状态设置为非SYM
Removal
移动
Each time a link is deleted, that is, each time a link tuple is removed, the associated neighbor tuple MUST be removed if it has no longer any associated link tuples.
每次删除链接时，即每次删除链接元组时，如果关联的相邻元组不再具有任何关联的链接元组，则必须删除关联的相邻元组。
These rules ensure that there is exactly one associated neighbor tuple for a link tuple, and that every neighbor tuple has at least one associated link tuple.
这些规则确保链接元组只有一个关联的邻居元组，并且每个邻居元组至少有一个关联的链接元组。
The "Originator Address" of a HELLO message is the main address of the node, which has emitted the message. Likewise, the "willingness" MUST be computed from the Willingness field of the HELLO message (see section 6.1).
HELLO消息的“发起者地址”是发出消息的节点的主地址。同样，“意愿”必须从HELLO消息的意愿字段中计算出来（参见第6.1节）。
Upon receiving a HELLO message, a node SHOULD first update its Link Set as described before. It SHOULD then update its Neighbor Set as follows:
在收到HELLO消息后，节点应首先更新其链接集，如前所述。然后，它应更新其邻居集，如下所示：
- if the Originator Address is the N_neighbor_main_addr from a neighbor tuple included in the Neighbor Set:
- 如果发起者地址是邻居集中包含的邻居元组中的N_neighbor_main_addr：
then, the neighbor tuple SHOULD be updated as follows:
然后，应按如下方式更新邻居元组：
N_willingness = willingness from the HELLO message
N_willingness = willingness from the HELLO message
The 2-hop neighbor set describes the set of nodes which have a symmetric link to a symmetric neighbor. This information set is maintained through periodic exchange of HELLO messages as described in this section.
2跳邻居集描述了与对称邻居具有对称链路的节点集。如本节所述，通过定期交换HELLO消息来维护此信息集。
The "Originator Address" of a HELLO message is the main address of the node, which has emitted the message.
HELLO消息的“发起者地址”是发出消息的节点的主地址。
Upon receiving a HELLO message from a symmetric neighbor, a node SHOULD update its 2-hop Neighbor Set. Notice, that a HELLO message MUST neither be forwarded nor be recorded in the duplicate set.
从对称邻居接收HELLO消息后，节点应更新其2跳邻居集。请注意，HELLO消息既不能转发，也不能记录在重复集中。
Upon receiving a HELLO message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2).
收到HELLO消息后，必须从消息头的Vtime字段计算“有效时间”（见第3.3.2节）。
If the Originator Address is the main address of a L_neighbor_iface_addr from a link tuple included in the Link Set with
如果发起者地址是包含在链接集中的链接元组中的L_neighbor_iface_addr的主地址
L_SYM_time >= current time (not expired)
L_SYM_time>=当前时间（未过期）
(in other words: if the Originator Address is a symmetric neighbor) then the 2-hop Neighbor Set SHOULD be updated as follows:
（换句话说：如果发起者地址是对称邻居），则应按如下方式更新2跳邻居集：
1 for each address (henceforth: 2-hop neighbor address), listed in the HELLO message with Neighbor Type equal to SYM_NEIGH or MPR_NEIGH:
对于HELLO消息中列出的邻居类型等于SYM_NEIGH或MPR_NEIGH的每个地址（此后为2跳邻居地址），为1：
1.1 if the main address of the 2-hop neighbor address = main address of the receiving node:
1.1 如果2跳邻居地址的主地址=接收节点的主地址：
silently discard the 2-hop neighbor address.
以静默方式放弃2跳邻居地址。
(in other words: a node is not its own 2-hop neighbor).
（换句话说：节点不是它自己的2跳邻居）。
1.2 Otherwise, a 2-hop tuple is created with:
1.2 否则，将使用以下命令创建2跳元组：
N_neighbor_main_addr = Originator Address;
N_neighbor_main_addr=发起者地址；
N_2hop_addr = main address of the 2-hop neighbor;
N_2hop_addr=2-hop邻居的主地址；
N_time = current time + validity time.
N_时间=当前时间+有效时间。
This tuple may replace an older similar tuple with same N_neighbor_main_addr and N_2hop_addr values.
此元组可以用相同的N_neighbor_main_addr和N_2hop_addr值替换较旧的类似元组。
2 For each 2-hop node listed in the HELLO message with Neighbor Type equal to NOT_NEIGH, all 2-hop tuples where:
2对于邻居类型等于NOT_NEIGH的HELLO消息中列出的每个2-hop节点，所有2-hop元组，其中：
N_neighbor_main_addr == Originator Address AND
N_neighbor_main_addr==发起者地址和
N_2hop_addr == main address of the 2-hop neighbor
N_2hop_addr==两跳邻居的主地址
are deleted.
已删除。
MPRs are used to flood control messages from a node into the network while reducing the number of retransmissions that will occur in a region. Thus, the concept of MPR is an optimization of a classical flooding mechanism.
MPR用于将洪水控制消息从节点发送到网络中，同时减少区域内发生的重传次数。因此，MPR的概念是对经典注水机制的优化。
Each node in the network selects, independently, its own set of MPRs among its symmetric 1-hop neighborhood. The symmetric links with MPRs are advertised with Link Type MPR_NEIGH instead of SYM_NEIGH in HELLO messages.
网络中的每个节点在其对称1跳邻居中独立地选择其自己的MPR集。带有MPR的对称链路在HELLO消息中以链接类型MPR_NEIGH而不是SYM_NEIGH进行广告。
The MPR set MUST be calculated by a node in such a way that it, through the neighbors in the MPR-set, can reach all symmetric strict 2-hop neighbors. (Notice that a node, a, which is a direct neighbor of another node, b, is not also a strict 2-hop neighbor of node b). This means that the union of the symmetric 1-hop neighborhoods of the MPR nodes contains the symmetric strict 2-hop neighborhood. MPR set recalculation should occur when changes are detected in the symmetric neighborhood or in the symmetric strict 2-hop neighborhood.
节点必须以这样的方式计算MPR集：它通过MPR集中的邻居可以到达所有对称严格2跳邻居。（请注意，作为另一个节点b的直接邻居的节点a也不是节点b的严格2跳邻居）。这意味着MPR节点的对称1跳邻域的并集包含对称严格2跳邻域。在对称邻域或对称严格2跳邻域中检测到更改时，应重新计算MPR集。
MPRs are computed per interface, the union of the MPR sets of each interface make up the MPR set for the node.
每个接口计算MPR，每个接口的MPR集的并集构成节点的MPR集。
While it is not essential that the MPR set is minimal, it is essential that all strict 2-hop neighbors can be reached through the selected MPR nodes. A node SHOULD select an MPR set such that any strict 2-hop neighbor is covered by at least one MPR node. Keeping the MPR set small ensures that the overhead of the protocol is kept at a minimum.
虽然MPR集不一定是最小的，但所有严格的2跳邻居都可以通过选定的MPR节点到达，这一点很重要。节点应选择一个MPR集，以使任何严格的2跳邻居被至少一个MPR节点覆盖。保持MPR设置较小可确保协议的开销保持在最小值。
The MPR set can coincide with the entire symmetric neighbor set. This could be the case at network initialization (and will correspond to classic link-state routing).
MPR集可以与整个对称邻居集重合。网络初始化时可能会出现这种情况（并将对应于经典的链路状态路由）。
The following specifies a proposed heuristic for selection of MPRs. It constructs an MPR-set that enables a node to reach any node in the symmetrical strict 2-hop neighborhood through relaying by one MPR node with willingness different from WILL_NEVER. The heuristic MUST be applied per interface, I. The MPR set for a node is the union of the MPR sets found for each interface. The following terminology will be used in describing the heuristics:
以下规定了MPR选择的建议启发式。它构造了一个MPR集，通过一个MPR节点以不同于WILL_NEVER的意愿进行中继，使一个节点能够到达对称严格2跳邻域中的任何节点。启发式必须应用于每个接口，即，节点的MPR集是为每个接口找到的MPR集的并集。以下术语将用于描述启发式：
neighbor of an interface
接口的邻居
a node is a "neighbor of an interface" if the interface (on the local node) has a link to any one interface of the neighbor node.
如果接口（在本地节点上）与邻居节点的任何一个接口有链接，则节点是“接口的邻居”。
2-hop neighbors reachable from an interface
可从接口访问的2跳邻居
the list of 2-hop neighbors of the node that can be reached from neighbors of this interface.
可以从此接口的邻居访问的节点的2跳邻居列表。
MPR set of an interface
接口的MPR集
a (sub)set of the neighbors of an interface with a willingness different from WILL_NEVER, selected such that through these selected nodes, all strict 2-hop neighbors reachable from that interface are reachable.
意愿不同于WILL_NEVER的接口邻居的（子）集合，通过选择这些节点，可以从该接口访问所有严格的2跳邻居。
N: N is the subset of neighbors of the node, which are neighbor of the interface I.
N:N是节点邻居的子集，它们是接口I的邻居。
N2: The set of 2-hop neighbors reachable from the interface I, excluding:
N2：可从接口I访问的2跳邻居集，不包括：
(i) the nodes only reachable by members of N with willingness WILL_NEVER
(i) 只有N个成员愿意访问的节点永远不会
(ii) the node performing the computation
（ii）执行计算的节点
(iii) all the symmetric neighbors: the nodes for which there exists a symmetric link to this node on some interface.
（iii）所有对称邻居：在某些接口上存在到此节点的对称链接的节点。
D(y): The degree of a 1-hop neighbor node y (where y is a member of N), is defined as the number of symmetric neighbors of node y, EXCLUDING all the members of N and EXCLUDING the node performing the computation.
D（y）：一跳邻居节点y（其中y是N的成员）的度定义为节点y的对称邻居的数量，不包括N的所有成员，也不包括执行计算的节点。
The proposed heuristic is as follows:
建议的启发式方法如下：
1 Start with an MPR set made of all members of N with N_willingness equal to WILL_ALWAYS
1从一个MPR集合开始，该集合由N的所有成员组成，N_意愿始终等于WILL_
2 Calculate D(y), where y is a member of N, for all nodes in N.
2计算N中所有节点的D（y），其中y是N的成员。
3 Add to the MPR set those nodes in N, which are the *only* nodes to provide reachability to a node in N2. For example, if node b in N2 can be reached only through a symmetric link to node a in N, then add node a to the MPR set. Remove the nodes from N2 which are now covered by a node in the MPR set.
3将N中的节点添加到MPR集合中，这些节点是为N2中的节点提供可达性的*唯一*节点。例如，如果N2中的节点b只能通过到N中的节点a的对称链路到达，则将节点a添加到MPR集合中。从N2中删除节点，这些节点现在由MPR集中的节点覆盖。
4 While there exist nodes in N2 which are not covered by at least one node in the MPR set:
4当N2中存在未被MPR集中至少一个节点覆盖的节点时：
4.1 For each node in N, calculate the reachability, i.e., the number of nodes in N2 which are not yet covered by at least one node in the MPR set, and which are reachable through this 1-hop neighbor;
4.1 对于N中的每个节点，计算可达性，即，N2中尚未被MPR集中的至少一个节点覆盖且可通过该1跳邻居到达的节点的数量；
4.2 Select as a MPR the node with highest N_willingness among the nodes in N with non-zero reachability. In case of multiple choice select the node which provides reachability to the maximum number of nodes in N2. In case of multiple nodes providing the same amount of reachability, select the node as MPR whose D(y) is greater. Remove the nodes from N2 which are now covered by a node in the MPR set.
4.2 在N中具有非零可达性的节点中，选择N_意愿最高的节点作为MPR。在多选的情况下，选择可到达N2中最大数量节点的节点。如果多个节点提供相同数量的可达性，则选择D（y）较大的节点作为MPR。从N2中删除节点，这些节点现在由MPR集中的节点覆盖。
5 A node's MPR set is generated from the union of the MPR sets for each interface. As an optimization, process each node, y, in the MPR set in increasing order of N_willingness. If all nodes in N2 are still covered by at least one node in the MPR set excluding node y, and if N_willingness of node y is smaller than WILL_ALWAYS, then node y MAY be removed from the MPR set.
5节点的MPR集由每个接口的MPR集的并集生成。作为优化，以N_的递增顺序处理MPR集中的每个节点y。如果N2中的所有节点仍然被MPR集中不包括节点y的至少一个节点覆盖，并且如果节点y的N_比WILL_总是小，则可以从MPR集中移除节点y。
Other algorithms, as well as improvements over this algorithm, are possible. For example, assume that in a multiple-interface scenario there exists more than one link between nodes 'a' and 'b'. If node 'a' has selected node 'b' as MPR for one of its interfaces, then node 'b' can be selected as MPR without additional performance loss by any other interfaces on node 'a'.
其他算法以及对该算法的改进是可能的。例如，假设在多接口场景中，节点“a”和“b”之间存在多个链路。如果节点“a”已选择节点“b”作为其某个接口的MPR，则节点“b”可以选择为MPR，而不会因节点“a”上的任何其他接口而导致额外的性能损失。
The MPR selector set of a node, n, is populated by the main addresses of the nodes which have selected n as MPR. MPR selection is signaled through HELLO messages.
节点n的MPR选择器集由选择n作为MPR的节点的主地址填充。MPR选择通过HELLO消息发出信号。
Upon receiving a HELLO message, if a node finds one of its own interface addresses in the list with a Neighbor Type equal to MPR_NEIGH, information from the HELLO message must be recorded in the MPR Selector Set.
收到HELLO消息后，如果节点在列表中发现其自己的接口地址之一的邻居类型等于MPR_NEIGH，则来自HELLO消息的信息必须记录在MPR选择器集中。
The "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The MPR Selector Set SHOULD then be updated as follows:
“有效时间”必须根据消息头的Vtime字段计算（见第3.3.2节）。MPR选择器集应更新如下：
1 If there exists no MPR selector tuple with:
1如果不存在具有以下内容的MPR选择器元组：
MS_main_addr == Originator Address
MS_main_addr==发起人地址
then a new tuple is created with:
然后创建一个新的元组，其中包含：
MS_main_addr = Originator Address
MS_main_addr = Originator Address
2 The tuple (new or otherwise) with
2使用
MS_main_addr == Originator Address
MS_main_addr==发起人地址
is then modified as follows:
然后修改如下：
MS_time = current time + validity time.
MS_时间=当前时间+有效时间。
Deletion of MPR selector tuples occurs in case of expiration of the timer or in case of link breakage as described in the "Neighborhood and 2-hop Neighborhood Changes".
如“邻域和2跳邻域更改”中所述，在计时器过期或链路中断的情况下，会删除MPR选择器元组。
A change in the neighborhood is detected when:
当出现以下情况时，会检测到附近的变化：
- The L_SYM_time field of a link tuple expires. This is considered as a neighbor loss if the link described by the expired tuple was the last link with a neighbor node (on the contrary, a link with an interface may break while a link with another interface of the neighbor node remains without being observed as a neighborhood change).
- 链接元组的L_SYM_时间字段过期。如果过期元组描述的链路是与邻居节点的最后一个链路，则这被视为邻居丢失（相反，具有接口的链路可能会断开，而具有邻居节点的另一个接口的链路保持不变，而不会被视为邻居变化）。
- A new link tuple is inserted in the Link Set with a non expired L_SYM_time or a tuple with expired L_SYM_time is modified so that L_SYM_time becomes non-expired. This is considered as a neighbor appearance if there was previously no link tuple describing a link with the corresponding neighbor node.
- 在链接集中插入一个新的链接元组，该元组具有未过期的L_SYM_时间，或者修改一个具有过期的L_SYM_时间的元组，以便L_SYM_时间变为未过期。如果以前没有描述与相应邻居节点的链接的链接元组，则这被视为邻居外观。
A change in the 2-hop neighborhood is detected when a 2-hop neighbor tuple expires or is deleted according to section 8.2.
根据第8.2节，当2跳邻居元组过期或被删除时，检测到2跳邻居的变化。
The following processing occurs when changes in the neighborhood or the 2-hop neighborhood are detected:
当检测到邻域或2跳邻域中的更改时，会发生以下处理：
- In case of neighbor loss, all 2-hop tuples with N_neighbor_main_addr == Main Address of the neighbor MUST be deleted.
- 在邻居丢失的情况下，必须删除所有N_neighbor_main_addr==邻居主地址的2跳元组。
- In case of neighbor loss, all MPR selector tuples with MS_main_addr == Main Address of the neighbor MUST be deleted
- 如果邻居丢失，则必须删除所有MS_main_addr==邻居主地址的MPR选择器元组
- The MPR set MUST be re-calculated when a neighbor appearance or loss is detected, or when a change in the 2-hop neighborhood is detected.
- 当检测到邻居出现或丢失，或检测到2跳邻居发生变化时，必须重新计算MPR集。
- An additional HELLO message MAY be sent when the MPR set changes.
- MPR设置更改时，可能会发送额外的HELLO消息。
The link sensing and neighbor detection part of the protocol basically offers, to each node, a list of neighbors with which it can communicate directly and, in combination with the Packet Format and Forwarding part, an optimized flooding mechanism through MPRs. Based on this, topology information is disseminated through the network. The present section describes which part of the information given by the link sensing and neighbor detection is disseminated to the entire network and how it is used to construct routes.
协议的链路感知和邻居检测部分基本上为每个节点提供了一个可以直接通信的邻居列表，并结合包格式和转发部分，通过MPR提供了一个优化的泛洪机制。在此基础上，通过网络传播拓扑信息。本节描述链路感知和邻居检测给出的信息的哪一部分被传播到整个网络，以及如何使用它来构建路由。
Routes are constructed through advertised links and links with neighbors. A node must at least disseminate links between itself and the nodes in its MPR-selector set, in order to provide sufficient information to enable routing.
路由通过广告链接和与邻居的链接构建。节点必须至少传播自身与其MPR选择器集中的节点之间的链接，以便提供足够的信息来启用路由。
The proposed format of a TC message is as follows:
TC报文的建议格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data-portion of the general message format with the "Message Type" set to TC_MESSAGE. The time to live SHOULD be set to 255 (maximum value) to diffuse the message into the entire network and Vtime set accordingly to the value of TOP_HOLD_TIME, as specified in section 18.3.
这是作为“消息类型”设置为TC_消息的通用消息格式的数据部分发送的。应将生存时间设置为255（最大值），以将消息扩散到整个网络中，并根据第18.3节中规定的TOP_HOLD_time的值设置Vtime。
Advertised Neighbor Sequence Number (ANSN)
播发邻居序列号（ANSN）
A sequence number is associated with the advertised neighbor set. Every time a node detects a change in its advertised neighbor set, it increments this sequence number ("Wraparound" is handled as described in section 19). This number is sent in this ANSN field of the TC message to keep track of the most recent information. When a node receives a TC message, it can decide on the basis of this Advertised Neighbor Sequence Number, whether or not the received information about the advertised neighbors of the originator node is more recent than what it already has.
序列号与播发的邻居集相关联。每当节点检测到其播发的邻居集中的变化时，它就会增加该序列号（“环绕”按照第19节中的描述进行处理）。此号码在TC消息的ANSN字段中发送，以跟踪最新信息。当节点接收到TC消息时，它可以基于该播发的邻居序列号来决定所接收的关于发端节点的播发的邻居的信息是否比它已经拥有的信息更新。
Advertised Neighbor Main Address
播发邻居主地址
This field contains the main address of a neighbor node. All main addresses of the advertised neighbors of the Originator node are put in the TC message. If the maximum allowed message size (as imposed by the network) is reached while there are still advertised neighbor addresses which have not been inserted into the TC-message, more TC messages will be generated until the entire advertised neighbor set has been sent. Extra main addresses of neighbor nodes may be included, if redundancy is desired.
此字段包含邻居节点的主地址。发端节点的通告邻居的所有主地址都放在TC消息中。如果在仍有未插入TC消息的播发邻居地址的情况下，达到了允许的最大消息大小（由网络施加），则将生成更多TC消息，直到发送完整个播发邻居集。如果需要冗余，可以包括相邻节点的额外主地址。
Reserved
含蓄的
This field is reserved, and MUST be set to "0000000000000000" for compliance with this document.
此字段为保留字段，必须设置为“0000000000000000”以符合本文档的要求。
A TC message is sent by a node in the network to declare a set of links, called advertised link set which MUST include at least the links to all nodes of its MPR Selector set, i.e., the neighbors which have selected the sender node as a MPR.
TC消息由网络中的节点发送，以声明一组链路，称为广告链路集，该链路集必须至少包括到其MPR选择器集的所有节点的链路，即选择发送方节点作为MPR的邻居。
If, for some reason, it is required to distribute redundant TC information, refer to section 15.
如果出于某种原因，需要分发冗余TC信息，请参阅第15节。
The sequence number (ANSN) associated with the advertised neighbor set is also sent with the list. The ANSN number MUST be incremented when links are removed from the advertised neighbor set; the ANSN number SHOULD be incremented when links are added to the advertised neighbor set.
与播发的邻居集关联的序列号（ANSN）也随列表一起发送。当从播发的邻居集中删除链接时，ANSN编号必须增加；将链接添加到播发的邻居集时，ANSN编号应增加。
In order to build the topology information base, each node, which has been selected as MPR, broadcasts Topology Control (TC) messages. TC messages are flooded to all nodes in the network and take advantage of MPRs. MPRs enable a better scalability in the distribution of topology information [1].
为了建立拓扑信息库，每个被选为MPR的节点广播拓扑控制（TC）消息。TC消息被淹没到网络中的所有节点，并利用MPR。MPR使拓扑信息的分布具有更好的可伸缩性[1]。
The list of addresses can be partial in each TC message (e.g., due to message size limitations, imposed by the network), but parsing of all TC messages describing the advertised link set of a node MUST be complete within a certain refreshing period (TC_INTERVAL). The information diffused in the network by these TC messages will help each node calculate its routing table.
每个TC消息中的地址列表可以是部分的（例如，由于网络施加的消息大小限制），但是描述节点的广告链接集的所有TC消息的解析必须在特定刷新周期（TC_间隔）内完成。这些TC消息在网络中传播的信息将帮助每个节点计算其路由表。
When the advertised link set of a node becomes empty, this node SHOULD still send (empty) TC-messages during the a duration equal to the "validity time" (typically, this will be equal to TOP_HOLD_TIME) of its previously emitted TC-messages, in order to invalidate the previous TC-messages. It SHOULD then stop sending TC-messages until some node is inserted in its advertised link set.
当节点的播发链路集变为空时，该节点仍应在等于其先前发出的TC消息的“有效期”（通常，这将等于TOP_HOLD_time）的持续时间内发送（空）TC消息，以便使先前的TC消息无效。然后，它应该停止发送TC消息，直到将某个节点插入其播发的链接集中。
A node MAY transmit additional TC-messages to increase its reactiveness to link failures. When a change to the MPR selector set is detected and this change can be attributed to a link failure, a TC-message SHOULD be transmitted after an interval shorter than TC_INTERVAL.
节点可以发送额外的TC消息，以提高其对链路故障的反应能力。当检测到MPR选择器集发生变化且该变化可归因于链路故障时，应在短于TC_间隔的间隔后发送TC消息。
TC messages are broadcast and retransmitted by the MPRs in order to diffuse the messages in the entire network. TC messages MUST be forwarded according to the "default forwarding algorithm" (described in section 3.4).
TC消息由MPR广播和重传，以便在整个网络中传播消息。TC消息必须根据“默认转发算法”（如第3.4节所述）进行转发。
Upon receiving a TC message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The topology set SHOULD then be updated as follows (using section 19 for comparison of ANSN):
收到TC消息后，必须从消息头的Vtime字段计算“有效时间”（见第3.3.2节）。然后，拓扑集应更新如下（使用第19节比较ANSN）：
1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded.
1如果此消息的发送方接口（NB：非发起方）不在此节点的对称1跳邻居中，则必须丢弃该消息。
2 If there exist some tuple in the topology set where:
2如果拓扑集中存在某些元组，其中：
T_last_addr == originator address AND
T_last_addr==发起人地址和
T_seq > ANSN,
答案如下：，
then further processing of this TC message MUST NOT be performed and the message MUST be silently discarded (case: message received out of order).
然后，不得执行此TC消息的进一步处理，必须以静默方式丢弃该消息（情况：消息接收顺序错误）。
3 All tuples in the topology set where:
3拓扑集中的所有元组，其中：
T_last_addr == originator address AND
T_last_addr==发起人地址和
T_seq < ANSN
T_seq<ANSN
MUST be removed from the topology set.
必须从拓扑集中删除。
4 For each of the advertised neighbor main address received in the TC message:
4对于TC消息中接收到的每个播发邻居主地址：
4.1 If there exist some tuple in the topology set where:
4.1 如果拓扑集中存在某些元组，其中：
T_dest_addr == advertised neighbor main address, AND
T_dest_addr==公布的邻居主地址，以及
T_last_addr == originator address,
T_last_addr==发起人地址，
then the holding time of that tuple MUST be set to:
然后，该元组的保持时间必须设置为：
T_time = current time + validity time.
T_时间=当前时间+有效时间。
4.2 Otherwise, a new tuple MUST be recorded in the topology set where:
4.2 否则，必须在拓扑集中记录新元组，其中：
T_dest_addr = advertised neighbor main address,
T_dest_addr=公布的邻居主地址，
T_last_addr = originator address,
T_last_addr=发起人地址，
T_seq = ANSN,
T_seq=ANSN，
T_time = current time + validity time.
T_时间=当前时间+有效时间。
Each node maintains a routing table which allows it to route data, destined for the other nodes in the network. The routing table is based on the information contained in the local link information base and the topology set. Therefore, if any of these sets are changed, the routing table is recalculated to update the route information about each destination in the network. The route entries are recorded in the routing table in the following format:
每个节点维护一个路由表，该表允许它路由数据，目的地为网络中的其他节点。路由表基于本地链路信息库和拓扑集中包含的信息。因此，如果这些集合中的任何一个发生更改，将重新计算路由表以更新网络中每个目的地的路由信息。路由条目以以下格式记录在路由表中：
1. R_dest_addr R_next_addr R_dist R_iface_addr 2. R_dest_addr R_next_addr R_dist R_iface_addr 3. ,, ,, ,, ,,
1. R\u dest\u addr R\u next\u addr\u distr\u R\u iface\u addr 2。R\u dest\u addr R\u next\u addr\u distr\u R\u iface\u addr 3，，，，，
Each entry in the table consists of R_dest_addr, R_next_addr, R_dist, and R_iface_addr. Such entry specifies that the node identified by R_dest_addr is estimated to be R_dist hops away from the local node, that the symmetric neighbor node with interface address R_next_addr is the next hop node in the route to R_dest_addr, and that this symmetric neighbor node is reachable through the local interface with the address R_iface_addr. Entries are recorded in the routing table for each destination in the network for which a route is known. All the destinations, for which a route is broken or only partially known, are not recorded in the table.
表中的每个条目由R\u dest\u addr、R\u next\u addr、R\u dist和R\u iface\u addr组成。这样的条目指定由R_dest_addr标识的节点被估计为距离本地节点R_dist hops，具有接口地址R_next_addr的对称邻居节点是到R_dest_addr的路由中的下一个hop节点，并且该对称邻居节点可以通过地址R_iface_addr的本地接口访问。对于已知路由的网络中的每个目的地，条目都记录在路由表中。表中未记录路由中断或仅部分已知的所有目的地。
More precisely, the routing table is updated when a change is detected in either:
更准确地说，当检测到以下任一项中的更改时，路由表将更新：
- the link set,
- 链接集，
- the neighbor set,
- 邻居设置，
- the 2-hop neighbor set,
- 2跳邻居集，
- the topology set,
- 拓扑集，
- the Multiple Interface Association Information Base,
- 多接口关联信息库，
More precisely, the routing table is recalculated in case of neighbor appearance or loss, when a 2-hop tuple is created or removed, when a topology tuple is created or removed or when multiple interface association information changes. The update of this routing information does not generate or trigger any messages to be transmitted, neither in the network, nor in the 1-hop neighborhood.
更准确地说，在邻居出现或丢失、创建或删除两跳元组、创建或删除拓扑元组或更改多个接口关联信息时，将重新计算路由表。该路由信息的更新不会生成或触发任何要传输的消息，无论是在网络中还是在1-hop邻居中。
To construct the routing table of node X, a shortest path algorithm is run on the directed graph containing the arcs X -> Y where Y is any symmetric neighbor of X (with Neighbor Type equal to SYM), the
为了构造节点X的路由表，在包含弧X->Y的有向图上运行最短路径算法，其中Y是X的任何对称邻居（邻居类型等于SYM），其中
arcs Y -> Z where Y is a neighbor node with willingness different of WILL_NEVER and there exists an entry in the 2-hop Neighbor set with Y as N_neighbor_main_addr and Z as N_2hop_addr, and the arcs U -> V, where there exists an entry in the topology set with V as T_dest_addr and U as T_last_addr.
弧Y->Z，其中Y是一个意愿不同的邻居节点，Y为N_neighbor_main_addr，Z为N_2hop_addr，在2跳邻居集中存在一个条目；弧U->V，其中在拓扑集中存在一个条目，V为T_dest_addr，U为T_last_addr。
The following procedure is given as an example to calculate (or recalculate) the routing table:
以下步骤作为计算（或重新计算）路由表的示例：
1 All the entries from the routing table are removed.
1删除路由表中的所有条目。
2 The new routing entries are added starting with the symmetric neighbors (h=1) as the destination nodes. Thus, for each neighbor tuple in the neighbor set where:
2从对称邻居（h=1）开始添加新的路由条目作为目标节点。因此，对于邻居集中的每个邻居元组，其中：
N_status = SYM
N_status = SYM
(there is a symmetric link to the neighbor), and for each associated link tuple of the neighbor node such that L_time >= current time, a new routing entry is recorded in the routing table with:
（存在到邻居的对称链路），并且对于邻居节点的每个关联链路元组，使得L_time>=当前时间，在路由表中记录一个新的路由条目，其中包括：
R_dest_addr = L_neighbor_iface_addr, of the associated link tuple;
R_dest_addr＝关联链路元组的L_邻居_iface_addr；
R_next_addr = L_neighbor_iface_addr, of the associated link tuple;
R_next_addr＝关联链路元组的L_nexter_iface_addr；
R_dist = 1;
R_dist=1；
R_iface_addr = L_local_iface_addr of the associated link tuple.
R_iface_addr=关联链接元组的L_local_iface_addr。
If in the above, no R_dest_addr is equal to the main address of the neighbor, then another new routing entry with MUST be added, with:
如果在上述情况下，没有R_dest_addr等于邻居的主地址，则必须添加另一个新的路由条目，其中包括：
R_dest_addr = main address of the neighbor;
R_dest_addr=邻居的主地址；
R_next_addr = L_neighbor_iface_addr of one of the associated link tuple with L_time >= current time;
R_next_addr=L_nexter_iface_addr，其中一个关联链接元组的L_time>=当前时间；
R_dist = 1;
R_dist=1；
R_iface_addr = L_local_iface_addr of the associated link tuple.
R_iface_addr=关联链接元组的L_local_iface_addr。
3 for each node in N2, i.e., a 2-hop neighbor which is not a neighbor node or the node itself, and such that there exist at least one entry in the 2-hop neighbor set where N_neighbor_main_addr correspond to a neighbor node with willingness different of WILL_NEVER, one selects one 2-hop tuple and creates one entry in the routing table with:
3对于N2中的每个节点，即不是邻居节点或节点本身的2跳邻居，并且使得2跳邻居集中存在至少一个条目，其中N_neighbor_main_addr对应于意愿不同于WILL_NEVER的邻居节点，选择一个2跳元组并在路由表中创建一个条目，其中：
R_dest_addr = the main address of the 2-hop neighbor;
R_dest_addr=2跳邻居的主地址；
R_next_addr = the R_next_addr of the entry in the routing table with:
R_next_addr=路由表中条目的R_next_addr，具有：
R_dest_addr == N_neighbor_main_addr of the 2-hop tuple;
R_dest_addr==2跳元组的N_neighbor_main_addr；
R_dist = 2;
R_dist=2；
R_iface_addr = the R_iface_addr of the entry in the routing table with:
R_iface_addr=路由表中条目的R_iface_addr，具有：
R_dest_addr == N_neighbor_main_addr of the 2-hop tuple;
R_dest_addr==2跳元组的N_neighbor_main_addr；
3 The new route entries for the destination nodes h+1 hops away are recorded in the routing table. The following procedure MUST be executed for each value of h, starting with h=2 and incrementing it by 1 each time. The execution will stop if no new entry is recorded in an iteration.
3目的地节点h+1跳的新路由条目记录在路由表中。必须对h的每个值执行以下过程，从h=2开始，每次递增1。如果迭代中没有记录新条目，则执行将停止。
3.1 For each topology entry in the topology table, if its T_dest_addr does not correspond to R_dest_addr of any route entry in the routing table AND its T_last_addr corresponds to R_dest_addr of a route entry whose R_dist is equal to h, then a new route entry MUST be recorded in the routing table (if it does not already exist) where:
3.1 对于拓扑表中的每个拓扑条目，如果其T_dest_addr不对应于路由表中任何路由条目的R_dest_addr，且其T_last_addr对应于R_dist等于h的路由条目的R_dest_addr，则必须在路由表中记录新路由条目（如果它不存在），其中：
R_dest_addr = T_dest_addr;
R_dest_addr=T_dest_addr；
R_next_addr = R_next_addr of the recorded route entry where:
R_next_addr=记录的路线条目的R_next_addr，其中：
R_dest_addr == T_last_addr
R_dest_addr==T_last_addr
R_dist = h+1; and
R_dist = h+1; and
R_iface_addr = R_iface_addr of the recorded route entry where:
R_iface_addr=记录的路线条目的R_iface_addr，其中：
R_dest_addr == T_last_addr.
R_dest_addr==T_last_addr。
3.2 Several topology entries may be used to select a next hop R_next_addr for reaching the node R_dest_addr. When h=1, ties should be broken such that nodes with highest willingness and MPR selectors are preferred as next hop.
3.2 几个拓扑条目可用于选择下一跳R_next_addr以到达节点R_dest_addr。当h=1时，应断开连接，以便具有最高意愿的节点和MPR选择器优先作为下一跳。
4 For each entry in the multiple interface association base where there exists a routing entry such that:
4对于存在路由条目的多接口关联库中的每个条目，如下所示：
R_dest_addr == I_main_addr (of the multiple interface association entry)
R_dest_addr==I_main_addr（多接口关联项的）
AND there is no routing entry such that:
并且没有路由条目，因此：
R_dest_addr == I_iface_addr
R\u dest\u addr==I\u iface\u addr
then a route entry is created in the routing table with:
然后在路由表中创建路由条目，其中包含：
R_dest_addr = I_iface_addr (of the multiple interface association entry)
R_dest_addr=I_iface_addr（多接口关联项的）
R_next_addr = R_next_addr (of the recorded route entry)
R_next_addr=R_next_addr（记录的路线条目）
R_dist = R_dist (of the recorded route entry)
R_dist=R_dist（记录的路线条目）
R_iface_addr = R_iface_addr (of the recorded route entry).
R_iface_addr=R_iface_addr（记录的路线条目）。
This section outlines how a node should be configured, in order to operate in an OLSR MANET.
本节概述如何配置节点，以便在OLSR MANET中运行。
The nodes in the MANET network SHOULD be assigned addresses within a defined address sequence, i.e., the nodes in the MANET SHOULD be addressable through a network address and a netmask.
MANET网络中的节点应在定义的地址序列内分配地址，即MANET中的节点应可通过网络地址和网络掩码进行寻址。
Likewise, the nodes in each associated network SHOULD be assigned addresses from a defined address sequence, distinct from that being used in the MANET.
同样，每个相关网络中的节点都应该根据定义的地址序列分配地址，这与MANET中使用的地址序列不同。
Any MANET node with associated networks or hosts SHOULD be configured such that it has routes set up to the interfaces with associated hosts or network.
任何具有关联网络或主机的MANET节点都应进行配置，以使其具有设置到与关联主机或网络的接口的路由。
OLSR itself does not perform packet forwarding. Rather, it maintains the routing table in the underlying operating system, which is assumed to be forwarding packets as specified in RFC1812.
OLSR本身不执行数据包转发。相反，它在底层操作系统中维护路由表，该表被假定为转发RFC1812中指定的数据包。
A node MAY be equipped with multiple interfaces, some of which do not participate in the OLSR MANET. These non OLSR interfaces may be point to point connections to other singular hosts or may connect to separate networks.
一个节点可以配备多个接口，其中一些接口不参与OLSR MANET。这些非OLSR接口可以是到其他单一主机的点对点连接，或者可以连接到单独的网络。
In order to provide connectivity from the OLSR MANET interface(s) to these non OLSR interface(s), a node SHOULD be able to inject external route information to the OLSR MANET.
为了提供从OLSR MANET接口到这些非OLSR接口的连接，节点应该能够向OLSR MANET注入外部路由信息。
Injecting routing information from the OLSR MANET to non OLSR interfaces is outside the scope of this specification. It should be clear, however, that the routing information for the OLSR MANET can be extracted from the topology table (see section 4.4) or directly from the routing table of OLSR, and SHOULD be injected onto the non OLSR interfaces following whatever mechanism (routing protocol, static configuration etc.) is provided on these interfaces.
将路由信息从OLSR MANET注入非OLSR接口不在本规范的范围内。然而，应该清楚的是，OLSR MANET的路由信息可以从拓扑表中提取（参见第4.4节）或直接从OLSR的路由表中提取，并且应该按照这些接口上提供的任何机制（路由协议、静态配置等）注入到非OLSR接口上。
An example of such a situation could be where a node is equipped with a fixed network (e.g., an Ethernet) connecting to a larger network as well as a wireless network interface running OLSR.
这种情况的一个示例可以是节点配备有连接到更大网络的固定网络（例如，以太网）以及运行OLSR的无线网络接口。
Notice that this is a different case from that of "multiple interfaces", where all the interfaces are participating in the MANET through running the OLSR protocol.
注意，这与“多接口”的情况不同，其中所有接口都通过运行OLSR协议参与MANET。
In order to provide this capability of injecting external routing information into an OLSR MANET, a node with such non-MANET interfaces periodically issues a Host and Network Association (HNA) message, containing sufficient information for the recipients to construct an appropriate routing table.
为了提供将外部路由信息注入OLSR MANET的这种能力，具有这种非MANET接口的节点周期性地发出主机和网络关联（HNA）消息，该消息包含足够的信息，以便接收方构造适当的路由表。
The proposed format of an HNA-message is:
海航信息的拟定格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data part of the general packet format with the "Message Type" set to HNA_MESSAGE, the TTL field set to 255 and Vtime set accordingly to the value of HNA_HOLD_TIME, as specified in section 18.3.
按照第18.3节的规定，这是作为一般数据包格式的数据部分发送的，“消息类型”设置为HNA_消息，TTL字段设置为255，Vtime设置为HNA_保持时间值。
Network Address
网络地址
The network address of the associated network
关联网络的网络地址
Netmask
子网掩码
The netmask, corresponding to the network address immediately above.
网络掩码，对应于正上方的网络地址。
Each node maintains information concerning which nodes may act as "gateways" to associated hosts and networks by recording "association tuples" (A_gateway_addr, A_network_addr, A_netmask, A_time), where A_gateway_addr is the address of an OLSR interface of the gateway, A_network_addr and A_netmask specify the network address and netmask of a network, reachable through this gateway, and A_time specifies the time at which this tuple expires and hence *MUST* be removed.
每个节点通过记录“关联元组”（A_gateway_addr、A_network_addr、A_netmask、A_time）来维护关于哪些节点可以充当关联主机和网络的“网关”的信息，其中A_gateway_addr是网关的OLSR接口的地址，_network_addr和_netmask指定可通过此网关访问的网络的网络地址和网络掩码，而_time指定此元组过期的时间，因此*必须*删除。
The set of all association tuples in a node is called the "association set".
节点中所有关联元组的集合称为“关联集”。
It should be noticed, that the HNA-message can be considered as a "generalized version" of the TC-message: the originator of both the HNA- and TC-messages announce "reachability" to some other host(s).
应该注意的是，HNA消息可以被视为TC消息的“通用版本”：HNA消息和TC消息的发起者都宣布对其他主机的“可达性”。
In the TC-message, no netmask is required, since all reachability is announced on a per-host basis. In HNA-messages, announcing reachability to an address sequence through a network- and netmask address is typically preferred over announcing reachability to individual host addresses.
在TC消息中，不需要网络掩码，因为所有可达性都是基于每台主机宣布的。在HNA消息中，通过网络和网络掩码地址宣布对地址序列的可达性通常优于宣布对单个主机地址的可达性。
An important difference between TC- and HNA-messages is, that a TC message may have a canceling effect on previous information (if the ANSN is incremented), whereas information in HNA-messages is removed only upon expiration.
TC消息和HNA消息之间的一个重要区别是，TC消息可能对以前的信息具有取消作用（如果ANSN增加），而HNA消息中的信息只有在到期时才会被删除。
A node with associated hosts and/or networks SHOULD periodically generate a Host and Network Association (HNA) message, containing pairs of (network address, netmask) corresponding to the connected hosts and networks. HNA-messages SHOULD be transmitted periodically every HNA_INTERVAL. The Vtime is set accordingly to the value of HNA_HOLD_TIME, as specified in section 18.3.
具有关联主机和/或网络的节点应定期生成主机和网络关联（HNA）消息，其中包含对应于所连接主机和网络的成对（网络地址、网络掩码）。HNA消息应每隔HNA_间隔定期发送。根据第18.3节规定的HNA_HOLD_TIME值设置Vtime。
A node without any associated hosts and/or networks SHOULD NOT generate HNA-messages.
没有任何关联主机和/或网络的节点不应生成HNA消息。
Upon receiving a HNA message, and thus following the rules of section 3, in this version of the specification, the message MUST be forwarded according to section 3.4.
在收到海航信息后，并遵循本规范第3节的规则，必须根据第3.4节转发信息。
In this section, the term "originator address" is used to designate the main address on the OLSR MANET of the node which originally issued the HNA-message.
在本节中，术语“发起者地址”用于指定最初发出HNA消息的节点的OLSR MANET上的主地址。
Upon processing a HNA-message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The association base SHOULD then be updated as follows:
在处理HNA消息时，必须从消息头的Vtime字段计算“有效时间”（见第3.3.2节）。然后，关联基础应更新如下：
1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded.
1如果此消息的发送方接口（NB：非发起方）不在此节点的对称1跳邻居中，则必须丢弃该消息。
2 Otherwise, for each (network address, netmask) pair in the message:
2否则，对于消息中的每个（网络地址、网络掩码）对：
2.1 if an entry in the association set already exists, where:
2.1 如果关联集中已存在条目，其中：
A_gateway_addr == originator address
A_gateway_addr==发起者地址
A_network_addr == network address
A_network_addr==网络地址
A_netmask == netmask
A_netmask==网络掩码
then the holding time for that tuple MUST be set to:
然后，该元组的保持时间必须设置为：
A_time = current time + validity time
A_时间=当前时间+有效时间
2.2 otherwise, a new tuple MUST be recorded with:
2.2 否则，新元组必须记录为：
A_gateway_addr = originator address
A_gateway_addr = originator address
A_network_addr = network address
A_network_addr = network address
A_netmask = netmask
A_netmask = netmask
A_time = current time + validity time
A_时间=当前时间+有效时间
In addition to the routing table computation as described in section 10, the host and network association set MUST be added as follows:
除第10节所述的路由表计算外，还必须按如下方式添加主机和网络关联集：
For each tuple in the association set,
对于关联集中的每个元组，
1 If there is no entry in the routing table with:
1如果路由表中没有包含以下内容的条目：
R_dest_addr == A_network_addr/A_netmask
R_dest_addr == A_network_addr/A_netmask
then a new routing entry is created.
然后创建一个新的路由条目。
2 If a new routing entry was created at the previous step, or else if there existed one with:
2如果在上一步中创建了新的路由条目，或者存在具有以下内容的路由条目：
R_dest_addr == A_network_addr/A_netmask
R_dest_addr == A_network_addr/A_netmask
R_dist > dist to A_gateway_addr of current association set tuple,
R\u dist>dist到当前关联集元组的\u gateway\u addr，
then the routing entry is modified as follows:
然后将路由条目修改如下：
R_dest_addr = A_network_addr/A_netmask
R_dest_addr = A_network_addr/A_netmask
R_next_addr = the next hop on the path from the node to A_gateway_addr
R_next_addr=从节点到\u网关\u addr的路径上的下一跳
R_dist = dist to A_gateway_addr
R_dist = dist to A_gateway_addr
R_next_addr and R_iface_addr MUST be set to the same values as the tuple from the routing set with R_dest_addr == A_gateway_addr.
R_next_addr和R_iface_addr必须设置为与路由集中R_dest_addr==A_gateway_addr的元组相同的值。
Nodes, which do not implement support for non OLSR interfaces, can coexist in a network with nodes which do implement support for non OLSR interfaces: the generic packet format and message forwarding (section 3) ensures that HNA messages are correctly forwarded by all nodes. Nodes which implement support for non OLSR interfaces may thus transmit and process HNA messages according to this section.
不支持非OLSR接口的节点可以与支持非OLSR接口的节点共存于网络中：通用数据包格式和消息转发（第3节）确保所有节点正确转发HNA消息。因此，实现对非OLSR接口支持的节点可以根据本节传输和处理HNA消息。
Nodes, which do not implement support for non OLSR interfaces can not take advantage of the functionality specified in this section, however they will forward HNA messages correctly, as specified in section 3.
不支持非OLSR接口的节点不能利用本节中规定的功能，但它们将按照第3节的规定正确转发HNA消息。
OLSR is designed not to impose or expect any specific information from the link layer. However, if information from the link-layer describing link breakage is available, a node MAY use this as described in this section.
OLSR的设计目的是不强加或期望来自链路层的任何特定信息。然而，如果来自链路层的描述链路中断的信息可用，则节点可以如本节中所述使用该信息。
If link layer information describing connectivity to neighboring nodes is available (i.e., loss of connectivity such as through absence of a link layer acknowledgment), this information is used in addition to the information from the HELLO-messages to maintain the neighbor information base and the MPR selector set.
如果描述到相邻节点的连接性的链路层信息可用（例如，由于缺少链路层确认而导致的连接性丧失），则除了来自HELLO消息的信息之外，还使用该信息来维护邻居信息库和MPR选择器集。
Thus, upon receiving a link-layer notification that the link between a node and a neighbor interface is broken, the following actions are taken with respect to link sensing:
因此，在接收到节点和邻居接口之间的链路断开的链路层通知时，针对链路感测采取以下动作：
Each link tuple in the local link set SHOULD, in addition to what is described in section 4.2, include a L_LOST_LINK_time field. L_LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending. (Notice, that this is a subset of what is recommended in section 14, thus link hysteresis and link layer notifications can coexist).
除了第4.2节所述内容外，本地链接集中的每个链接元组还应包括一个L_LOST_link_time字段。L_LOST_LINK_time是一个计时器，用于在已建立的链接挂起时将链接声明为丢失。（注意，这是第14节中建议的子集，因此链路滞后和链路层通知可以共存）。
HELLO message generation should consider those new fields as follows:
Hello消息生成应考虑以下新字段：
1 if L_LOST_LINK_time is not expired, the link is advertised with a link type of LOST_LINK. In addition, it is not considered as a symmetric link in the updates of the associated neighbor tuple (see section 8.1).
1如果L_LOST_LINK_时间未过期，则会使用LOST_LINK的链接类型播发该链接。此外，在相关相邻元组的更新中，它不被视为对称链接（参见第8.1节）。
2 if the link to a neighboring symmetric or asymmetric interface is broken, the corresponding link tuple is modified: L_LOST_LINK_time and L_time are set to current time + NEIGHB_HOLD_TIME.
2如果到相邻对称或非对称接口的链路中断，则修改相应的链路元组：L_LOST_link_time和L_time设置为current time+NEIGHB_HOLD_time。
3 this is considered as a link loss and the appropriate processing described in section 8.5 should be performed.
3这被视为链路丢失，应执行第8.5节中所述的适当处理。
Link layer notifications provide, for a node, an additional criterion by which a node may determine if a link to a neighbor node is lost. Once a link is detected as lost, it is advertised, in accordance with the provisions described in the previous sections of this specification.
链路层通知为节点提供了一个额外的标准，节点可根据该标准确定到邻居节点的链路是否丢失。一旦检测到链路丢失，将根据本规范前面章节中所述的规定对其进行公告。
Established links should be as reliable as possible to avoid data packet loss. This implies that link sensing should be robust against bursty loss or transient connectivity between nodes. Hence, to enhance the robustness of the link sensing mechanism, the following implementation recommendations SHOULD be considered.
建立的链路应尽可能可靠，以避免数据包丢失。这意味着链路感知应该对突发性丢失或节点之间的瞬时连接具有鲁棒性。因此，为了增强链路感知机制的鲁棒性，应考虑以下实施建议。
Each link tuple in the local link set SHOULD, in addition to what is described in section 4.2, include a L_link_pending field, a L_link_quality field, and a L_LOST_LINK_time field. L_link_pending is a boolean value specifying if the link is considered pending (i.e., the link is not considered established). L_link_quality is a dimensionless number between 0 and 1 describing the quality of the link. L_LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending.
除第4.2节所述内容外，本地链接集中的每个链接元组还应包括一个L_link_pending字段、一个L_link_quality字段和一个L_LOST_link_time字段。L_link_pending是一个布尔值，指定链接是否被视为挂起（即，链接未被视为已建立）。L_link_quality是一个介于0和1之间的无量纲数字，用于描述链接的质量。L_LOST_LINK_time是一个计时器，用于在已建立的链接挂起时将链接声明为丢失。
HELLO message generation should consider those new fields as follows:
Hello消息生成应考虑以下新字段：
1 if L_LOST_LINK_time is not expired, the link is advertised with a link type of LOST_LINK.
1如果L_LOST_LINK_时间未过期，则会使用LOST_LINK的链接类型播发该链接。
2 otherwise, if L_LOST_LINK_time is expired and L_link_pending is set to "true", the link SHOULD NOT be advertised at all;
2否则，如果L_loss_LINK_time过期且L_LINK_pending设置为“true”，则根本不应公布该链接；
3 otherwise, if L_LOST_LINK_time is expired and L_link_pending is set to "false", the link is advertised as described previously in section 6.
3否则，如果L_loss_LINK_time过期，并且L_LINK_pending设置为“false”，则按照前面第6节中的描述公布链接。
A node considers that it has a symmetric link for each link tuple where:
节点认为每个链接元组都有一个对称链接，其中：
1 L_LOST_LINK_time is expired, AND
1 L_丢失_链接_时间已过期，并且
2 L_link_pending is "false", AND
2 L_link_pending为“false”，且
3 L_SYM_time is not expired.
3 L_SYM_时间未过期。
This definition for "symmetric link" SHOULD be used in updating the associated neighbor tuple (see section 8.1) for computing the N_status of a neighbor node. This definition SHOULD thereby also be used as basis for the symmetric neighborhood when computing the MPR set, as well as for "the symmetric neighbors" in the first steps of the routing table calculation.
“对称链路”的定义应用于更新相关的邻居元组（见第8.1节），以计算邻居节点的N_状态。因此，在计算MPR集时，该定义还应作为对称邻域的基础，以及在路由表计算的第一步中作为“对称邻域”的基础。
Apart from the above, what has been described previously does not interfere with the advanced link sensing fields in the link tuples. The L_link_quality, L_link_pending and L_LOST_LINK_time fields are exclusively updated according to the present section. This section does not modify the function of any other fields in the link tuples.
除上述之外，前面描述的内容不会干扰链路元组中的高级链路感测字段。L_link_quality、L_link_pending和L_LOST_link_time字段根据本节专门更新。本节不修改链接元组中任何其他字段的函数。
The link between a node and some of its neighbor interfaces might be "bad", i.e., from time to time let HELLOs pass through only to fade out immediately after. In this case, the neighbor information base would contain a bad link for at least "validity time". The following hysteresis strategy SHOULD be adopted to counter this situation.
一个节点和它的一些邻居接口之间的链接可能是“坏的”，也就是说，不时地让他通过，然后立即消失。在这种情况下，邻居信息库至少在“有效期”内包含坏链接。应采取以下滞后策略来应对这种情况。
For each neighbor interface NI heard by interface I, the L_link_quality field of the corresponding Link Tuple determines the establishment of the link. The value of L_link_quality is compared to two thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed
对于接口I听到的每个相邻接口NI，对应链路元组的L_link_quality字段确定链路的建立。将L_链路_质量的值与两个阈值HYST_THRESHOLD_HIGH、HYST_THRESHOLD_LOW和fixed进行比较
between 0 and 1 and such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW.
介于0和1之间，使得HYST\u阈值\u高>=HYST\u阈值\u低。
The L_link_pending field is set according to the following:
L_link_pending字段根据以下内容设置：
1 if L_link_quality > HYST_THRESHOLD_HIGH:
1如果链路质量>HYST阈值高：
L_link_pending = false
L_link_pending = false
L_LOST_LINK_time = current time - 1 (expired)
L_丢失_链接_时间=当前时间-1（过期）
2 otherwise, if L_link_quality < HYST_THRESHOLD_LOW:
2否则，如果链路质量<HYST阈值低：
L_link_pending = true
L_link_pending = true
L_LOST_LINK_time = min (L_time, current time + NEIGHB_HOLD_TIME)
L_丢失链接时间=分钟（L_时间、当前时间+相邻保持时间）
(the link is then considered as lost according to section 8.5 and this may produce a neighbor loss).
（然后，根据第8.5节，链路被视为丢失，这可能会导致邻居丢失）。
3 otherwise, if HYST_THRESHOLD_LOW <= L_link_quality <= HYST_THRESHOLD_HIGH:
3否则，如果HYST\U阈值低<=L\U链路质量<=HYST\U阈值高：
L_link_pending and L_LOST_LINK_time remain unchanged.
链路挂起和链路丢失时间保持不变。
The condition for considering a link established is thus stricter than the condition for dropping a link. Notice thus, that a link can be dropped based on either timer expiration (as described in section 7) or on L_link_quality dropping below HYST_THRESHOLD_LOW.
因此，考虑建立链路的条件比丢弃链路的条件更严格。因此，请注意，可以基于计时器到期（如第7节所述）或链路质量下降到低于HYST\u阈值\u低来丢弃链路。
Also notice, that even if a link is not considered as established by the link hysteresis, the link tuples are still updated for each received HELLO message (as described in section 7). Specifically, this implies that, regardless of whether or not the link hysteresis considers a link as "established", tuples in the link set do not expire except as determined by the L_time field of the link tuples.
还要注意的是，即使链路不被认为是由链路滞后建立的，链路元组仍然会针对每个接收到的HELLO消息进行更新（如第7节所述）。具体地说，这意味着，无论链路迟滞是否将链路视为“已建立”，链路集中的元组不会过期，除非由链路元组的L_时间字段确定。
As a basic implementation requirement, an estimation of the link quality must be maintained and stored in the L_link_quality field. If some measure of the signal/noise level on a received message is available (e.g., as a link layer notification), then it can be used as estimation after normalization.
作为一项基本的实施要求，必须维护链路质量的估计，并将其存储在L_link_quality字段中。如果接收到的消息上的信号/噪声级的某些度量是可用的（例如，作为链路层通知），那么它可以在标准化后用作估计。
If no signal/noise information or other link quality information is available from the link layer, an algorithm such as the following can be utilized (it is an exponentially smoothed moving average of the transmission success rate). The algorithm is parameterized by a
如果没有来自链路层的信号/噪声信息或其他链路质量信息可用，则可以使用诸如以下的算法（它是传输成功率的指数平滑移动平均值）。该算法由一个
scaling parameter HYST_SCALING which is a number fixed between 0 and 1. For each neighbor interface NI heard by interface I, the first time NI is heard by I, L_link_quality is set to HYST_SCALING (L_link_pending is set to true and L_LOST_LINK_time to current time - 1).
缩放参数HYST_scaling是一个固定在0和1之间的数字。对于接口I听到的每个相邻接口NI，I第一次听到NI时，L_link_quality设置为HYST_SCALING（L_link_pending设置为true，L_LOST_link_time设置为当前时间-1）。
A tuple is updated according to two rules. Every time an OLSR packet emitted by NI is received by I, the stability rule is applied:
元组根据两条规则进行更新。每当I接收到NI发出的OLSR包时，应用稳定性规则：
L_link_quality = (1-HYST_SCALING)*L_link_quality
+ HYST_SCALING.
L_link_quality = (1-HYST_SCALING)*L_link_quality
+ HYST_SCALING.
When an OLSR packet emitted by NI is lost by I, the instability rule is applied:
当NI发出的OLSR包被I丢失时，应用不稳定性规则：
L_link_quality = (1-HYST_SCALING)*L_link_quality.
L_link_quality = (1-HYST_SCALING)*L_link_quality.
The loss of OLSR packet is detected by tracking the missing Packet Sequence Numbers on a per interface basis and by "long period of silence" from a node. A "long period of silence may be detected thus: if no OLSR packet has been received on interface I from interface NI during HELLO emission interval of interface NI (computed from the Htime field in the last HELLO message received from NI), a loss of an OLSR packet is detected.
OLSR数据包的丢失是通过在每个接口的基础上跟踪丢失的数据包序列号以及通过节点的“长时间静默”来检测的。因此，可以检测到“长时间的静默：如果在接口NI的HELLO发射间隔期间（根据从NI接收的最后HELLO消息中的Htime字段计算），在接口I上没有从接口NI接收到OLSR分组，则检测到OLSR分组的丢失。
Link hysteresis determines, for a node, the criteria at which a link to a neighbor node is accepted or rejected. Nodes in a network may have different criteria, according to the nature of the media over which they are communicating. Once a link is accepted, it is advertised, in accordance with the provisions described in the previous sections of this specification.
链路滞后决定了节点接受或拒绝与相邻节点的链路的标准。网络中的节点可能具有不同的标准，这取决于它们正在通信的媒体的性质。一旦链接被接受，将根据本规范前面章节中所述的规定进行广告。
In order to provide redundancy to topology information base, the advertised link set of a node MAY contain links to neighbor nodes which are not in MPR selector set of the node. The advertised link set MAY contain links to the whole neighbor set of the node. The minimal set of links that any node MUST advertise in its TC messages is the links to its MPR selectors. The advertised link set can be built according to the following rule based on a local parameter called TC_REDUNDANCY parameter.
为了向拓扑信息库提供冗余，节点的通告链路集可以包含到不在节点的MPR选择器集中的邻居节点的链路。广告链接集可以包含到节点的整个邻居集的链接。任何节点必须在其TC消息中公布的最小链接集是指向其MPR选择器的链接。可以根据以下规则，基于名为TC_REDUNDANCY parameter的本地参数，构建播发链路集。
The parameter TC_REDUNDANCY specifies, for the local node, the amount of information that MAY be included in the TC messages. The parameter SHOULD be interpreted as follows:
参数TC_REDUNDANCY为本地节点指定可能包含在TC消息中的信息量。该参数应解释如下：
- if the TC_REDUNDANCY parameter of the node is 0, then the advertised link set of the node is limited to the MPR selector set (as described in section 8.3),
- 如果节点的TC_冗余参数为0，则节点的播发链路集仅限于MPR选择器集（如第8.3节所述），
- if the TC_REDUNDANCY parameter of the node is 1, then the advertised link set of the node is the union of its MPR set and its MPR selector set,
- 如果节点的TC_冗余参数为1，则节点的播发链路集是其MPR集和MPR选择器集的并集，
- if the TC_REDUNDANCY parameter of the node is 2, then the advertised link set of the node is the full neighbor link set.
- 如果节点的TC_冗余参数为2，则该节点的播发链路集为全邻居链路集。
A node with willingness equal to WILL_NEVER SHOULD have TC_REDUNDANCY also equal to zero.
意愿等于WILL_NEVER的节点的TC_冗余也应等于零。
A TC message is sent by a node in the network to declare a set of links, called advertised link set, which MUST include at least the links to all nodes of its MPR Selector set, i.e., the neighbors which have selected the sender node as a MPR. This is sufficient information to ensure that routes can be computed in accordance with section 10.
TC消息由网络中的节点发送，以声明一组链路，称为广告链路集，该链路集必须至少包括到其MPR选择器集的所有节点的链路，即选择发送方节点作为MPR的邻居。这是足够的信息，以确保可根据第10节计算路线。
The provisions in this section specifies how additional information may be declared, as specified through a TC_REDUNDANCY parameter. TC_REDUNDANCY = 0 implies that the information declared corresponds exactly to the MPR Selector set, identical to section 9. Other values of TC_REDUNDANCY specifies additional information to be declared, i.e., the contents of the MPR Selector set is always declared. Thus, nodes with different values of TC_REDUNDANCY may coexist in a network: control messages are carried by all nodes in accordance with section 3, and all nodes will receive at least the link-state information required to construct routes as described in section 10.
本节中的规定规定了如何通过TC_冗余参数声明附加信息。TC_REDUNDANCY=0表示声明的信息与MPR选择器集完全对应，与第9节相同。TC_冗余的其他值指定要声明的附加信息，即始终声明MPR选择器集的内容。因此，具有不同TC_冗余值的节点可以在网络中共存：根据第3节，控制消息由所有节点承载，并且所有节点将至少接收如第10节所述的构建路由所需的链路状态信息。
MPR redundancy specifies the ability for a node to select redundant MPRs. Section 4.5 specifies that a node should select its MPR set to be as small as possible, in order to reduce protocol overhead. The criteria for selecting MPRs is, that all strict 2-hop nodes must be reachable through, at least, one MPR node. Redundancy of the MPR set
MPR冗余指定节点选择冗余MPR的能力。第4.5节规定节点应选择尽可能小的MPR集，以减少协议开销。选择MPR的标准是，所有严格的2-hop节点必须至少通过一个MPR节点达到。MPR集的冗余
affects the overhead through affecting the amount of links being advertised, the amount of nodes advertising links and the efficiency of the MPR flooding mechanism. On the other hand, redundancy in the MPR set ensures that reachability for a node is advertised by more nodes, thus additional links are diffused to the network.
通过影响正在播发的链接数量、节点播发链接数量和MPR泛洪机制的效率来影响开销。另一方面，MPR集中的冗余确保了一个节点的可达性被更多的节点通告，因此额外的链路被扩散到网络。
While, in general, a minimal MPR set provides the least overhead, there are situations in which overhead can be traded off for other benefits. For example, a node may decide to increase its MPR coverage if it observes many changes in its neighbor information base caused by mobility, while otherwise keeping a low MPR coverage.
虽然一般来说，最小MPR集提供的开销最小，但在某些情况下，开销可以用来换取其他好处。例如，如果节点观察到其邻居信息库中由移动性引起的许多变化，则节点可以决定增加其MPR覆盖，而其他情况下保持较低的MPR覆盖。
The MPR coverage is defined by a single local parameter, MPR_COVERAGE, specifying by how many MPR nodes any strict 2-hop node should be covered. MPR_COVERAGE=1 specifies that the overhead of the protocol is kept at a minimum and causes the MPR selection to operate as described in section 8.3.1. MPR_COVERAGE=m ensures that, if possible, a node selects its MPR set such that all strict 2-hop nodes for an interface are reachable through at least m MPR nodes on that interface. MPR_COVERAGE can assume any integer value > 0. The heuristic MUST be applied per interface, I. The MPR set for a node is the union of the MPR sets found for each interface.
MPR覆盖率由单个本地参数MPR_覆盖率定义，该参数指定任何严格的2跳节点应覆盖多少个MPR节点。MPR_COVERAGE=1指定将协议的开销保持在最小，并使MPR选择按照第8.3.1节所述进行操作。MPR_COVERAGE=m确保，如果可能的话，节点选择其MPR集，以便通过该接口上的至少m个MPR节点可以访问接口的所有严格2跳节点。MPR_覆盖范围可以采用任何大于0的整数值。启发式必须应用于每个接口，即，节点的MPR集是为每个接口找到的MPR集的并集。
Notice that MPR_COVERAGE can be tuned locally without affecting the consistency of the protocol. For example, nodes in a network may operate with different values of MPR_COVERAGE.
请注意，MPR_覆盖范围可以在本地进行调整，而不会影响协议的一致性。例如，网络中的节点可以使用不同的MPR_覆盖值进行操作。
Using MPR coverage, the MPR selection heuristics is extended from that described in the section 8.3.1 by one definition:
使用MPR覆盖率，MPR选择启发式从第8.3.1节中描述的扩展为一个定义：
Poorly covered node:
覆盖不良的节点：
A poorly covered node is a node in N2 which is covered by less than MPR_COVERAGE nodes in N.
覆盖较差的节点是N2中的节点，其在N中被小于MPR_覆盖的节点覆盖。
The proposed heuristic for selecting MPRs is then as follows:
选择MPR的建议启发式如下：
1 Start with an MPR set made of all members of N with willingness equal to WILL_ALWAYS
1从一个MPR集合开始，该集合由N的所有成员组成，其意愿始终等于WILL_
2 Calculate D(y), where y is a member of N, for all nodes in N.
2计算N中所有节点的D（y），其中y是N的成员。
3 Select as MPRs those nodes in N which cover the poorly covered nodes in N2. The nodes are then removed from N2 for the rest of the computation.
3选择N中覆盖N2中覆盖不良节点的节点作为MPR。然后，在剩余的计算中，节点从N2中移除。
4 While there exist nodes in N2 which are not covered by at least MPR_COVERAGE nodes in the MPR set:
4当N2中存在未被MPR集合中至少MPR_覆盖节点覆盖的节点时：
4.1 For each node in N, calculate the reachability, i.e., the number of nodes in N2 which are not yet covered by at least MPR_COVERAGE nodes in the MPR set, and which are reachable through this 1-hop neighbor;
4.1 对于N中的每个节点，计算可达性，即，N2中尚未被MPR集中的至少MPR_覆盖节点覆盖且可通过该1跳邻居到达的节点的数量；
4.2 Select as a MPR the node with highest willingness among the nodes in N with non-zero reachability. In case of multiple choice select the node which provides reachability to the maximum number of nodes in N2. In case of multiple nodes providing the same amount of reachability, select the node as MPR whose D(y) is greater. Remove the nodes from N2 which are now covered by MPR_COVERAGE nodes in the MPR set.
4.2 在具有非零可达性的N个节点中选择意愿最高的节点作为MPR。在多选的情况下，选择可到达N2中最大数量节点的节点。如果多个节点提供相同数量的可达性，则选择D（y）较大的节点作为MPR。从N2中删除节点，这些节点现在由MPR集合中的MPR_覆盖节点覆盖。
5 A node's MPR set is generated from the union of the MPR sets for each interface. As an optimization, process each node, y, in the MPR set in increasing order of N_willingness. If all nodes in N2 are still covered by at least MPR_COVERAGE nodes in the MPR set excluding node y, and if N_willingness of node y is smaller than WILL_ALWAYS, then node y MAY be removed from the MPR set.
5节点的MPR集由每个接口的MPR集的并集生成。作为优化，以N_的递增顺序处理MPR集中的每个节点y。如果N2中的所有节点仍然被MPR集中不包括节点y的至少MPR_覆盖节点覆盖，并且如果节点y的N_意愿小于WILL_始终，则可以从MPR集中移除节点y。
When the MPR set has been computed, all the corresponding main addresses are stored in the MPR Set.
当计算MPR集时，所有相应的主地址都存储在MPR集中。
The MPR set of a node MUST, according to section 8.3, be calculated by a node in such a way that it, through the neighbors in the MPR-set, can reach all symmetric strict 2-hop neighbors. This is achieved by the heuristics in this section, for all values of MPR_COVERAGE > 0. MPR_COVERAGE is a local parameter for each node. Setting this parameter affects only the amount of redundancy in part of the network.
根据第8.3节，节点的MPR集必须由节点计算，其计算方式应确保其通过MPR集中的邻居可以到达所有对称严格2跳邻居。对于MPR_覆盖率>0的所有值，这是通过本节中的启发式实现的。MPR_覆盖率是每个节点的本地参数。设置此参数仅影响部分网络中的冗余量。
Notice that for MPR_COVERAGE=1, the heuristics in this section is identical to the heuristics specified in the section 8.3.1.
请注意，对于MPR_覆盖率=1，本节中的启发式与第8.3.1节中规定的启发式相同。
Nodes with different values of MPR_COVERAGE may coexist in a network: control messages are carried by all nodes in accordance with section 3, and all nodes will receive at least the link-state information required to construct routes as described in sections 9 and 10.
具有不同MPR_覆盖值的节点可以在网络中共存：根据第3节，所有节点都携带控制消息，并且所有节点将至少接收到构建第9节和第10节所述路由所需的链路状态信息。
All the operations and parameters described in this document used by OLSR for IP version 4 are the same as those used by OLSR for IP version 6. To operate with IP version 6, the only required change is to replace the IPv4 addresses with IPv6 address. The minimum packet and message sizes (under which there is rejection) should be adjusted accordingly, considering the greater size of IPv6 addresses.
OLSR在IP版本4中使用的所有操作和参数与OLSR在IP版本6中使用的操作和参数相同。要使用IP版本6运行，唯一需要的更改是将IPv4地址替换为IPv6地址。考虑到IPv6地址的更大大小，应相应调整最小数据包和消息大小（在此情况下存在拒绝）。
This section list the values for the constants used in the description of the protocol.
本节列出了协议描述中使用的常数值。
The proposed constant for C is the following:
C的建议常数如下所示：
C = 1/16 seconds (equal to 0.0625 seconds)
C=1/16秒（等于0.0625秒）
C is a scaling factor for the "validity time" calculation ("Vtime" and "Htime" fields in message headers, see section 18.3). The "validity time" advertisement is designed such that nodes in a network may have different and individually tuneable emission intervals, while still interoperate fully. For protocol functioning and interoperability to work:
C是“有效期”计算的比例因子（“消息头中的Vtime”和“Htime”字段，见第18.3节）。“有效期”广告的设计使得网络中的节点可以具有不同的且可单独调谐的发射间隔，同时仍然完全互操作。要使协议功能和互操作性发挥作用：
- the advertised holding time MUST always be greater than the refresh interval of the advertised information. Moreover, it is recommended that the relation between the interval (from section 18.2), and the hold time is kept as specified in section 18.3, to allow for reasonable packet loss.
- 播发的保持时间必须始终大于播发信息的刷新间隔。此外，建议按照第18.3节的规定保持间隔（从第18.2节开始）和保持时间之间的关系，以允许合理的数据包丢失。
- the constant C SHOULD be set to the suggested value. In order to achieve interoperability, C MUST be the same on all nodes.
- 常数C应设置为建议值。为了实现互操作性，C在所有节点上必须相同。
- the emission intervals (section 18.2), along with the advertised holding times (subject to the above constraints) MAY be selected on a per node basis.
- 发射间隔（第18.2节）以及公布的保持时间（受上述约束条件的约束）可在每个节点的基础上进行选择。
Note that the timer resolution of a given implementation might not be sufficient to wake up the system on precise refresh times or on precise expire times: the implementation SHOULD round up the
请注意，给定实现的计时器分辨率可能不足以在精确的刷新时间或过期时间唤醒系统：该实现应将
'validity time' ("Vtime" and "Htime" of packets) to compensate for coarser timer resolution, at least in the case where "validity time" could be shorter than the sum of emission interval and maximum expected timer error.
“有效时间”（“数据包的Vtime”和“Htime”）以补偿较粗的计时器分辨率，至少在“有效时间”可能短于发射间隔和最大预期计时器错误之和的情况下。
HELLO_INTERVAL = 2 seconds
HELLO_INTERVAL = 2 seconds
REFRESH_INTERVAL = 2 seconds
REFRESH_INTERVAL = 2 seconds
TC_INTERVAL = 5 seconds
TC_INTERVAL = 5 seconds
MID_INTERVAL = TC_INTERVAL
MID_INTERVAL = TC_INTERVAL
HNA_INTERVAL = TC_INTERVAL
HNA_INTERVAL = TC_INTERVAL
NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL
NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL
TOP_HOLD_TIME = 3 x TC_INTERVAL
TOP_HOLD_TIME = 3 x TC_INTERVAL
DUP_HOLD_TIME = 30 seconds
DUP_HOLD_TIME = 30 seconds
MID_HOLD_TIME = 3 x MID_INTERVAL
MID_HOLD_TIME = 3 x MID_INTERVAL
HNA_HOLD_TIME = 3 x HNA_INTERVAL
HNA_HOLD_TIME = 3 x HNA_INTERVAL
The Vtime in the message header (see section 3.3.2), and the Htime in the HELLO message (see section 6.1) are the fields which hold information about the above values in mantissa and exponent format (rounded up). In other words:
消息头中的Vtime（见第3.3.2节）和HELLO消息中的Htime（见第6.1节）是以尾数和指数格式（四舍五入）保存上述值信息的字段。换言之：
value = C*(1+a/16)*2^b [in seconds]
value = C*(1+a/16)*2^b [in seconds]
where a is the integer represented by the four highest bits of the field and b the integer represented by the four lowest bits of the field.
其中a是由字段的四个最高位表示的整数，b是由字段的四个最低位表示的整数。
Notice, that for the previous proposed value of C, (1/16 seconds), the values, in seconds, expressed by the formula above can be stored, without loss of precision, in binary fixed point or floating point numbers with at least 8 bits of fractional part. This corresponds with NTP time-stamps and single precision IEEE Standard 754 floating point numbers.
请注意，对于之前提出的C值（1/16秒），上述公式表示的值（以秒为单位）可以存储在二进制定点或浮点数中，且至少有8位小数。这与NTP时间戳和单精度IEEE标准754浮点数相对应。
Given one of the above holding times, a way of computing the mantissa/exponent representation of a number T (of seconds) is the following:
给定上述保持时间之一，计算数字T（秒）的尾数/指数表示的方法如下：
- find the largest integer 'b' such that: T/C >= 2^b
- 求最大整数“b”，使：T/C>=2^b
- compute the expression 16*(T/(C*(2^b))-1), which may not be a integer, and round it up. This results in the value for 'a'
- 计算表达式16*（T/（C*（2^b））-1），它可能不是整数，并将其四舍五入。这将产生“a”的值
- if 'a' is equal to 16: increment 'b' by one, and set 'a' to 0
- 如果“a”等于16：将“b”增加1，并将“a”设置为0
- now, 'a' and 'b' should be integers between 0 and 15, and the field will be a byte holding the value a*16+b
- 现在，'a'和'b'应该是介于0和15之间的整数，字段将是一个保存值a*16+b的字节
For instance, for values of 2 seconds, 6 seconds, 15 seconds, and 30 seconds respectively, a and b would be: (a=0,b=5), (a=8,b=6), (a=14,b=7) and (a=14,b=8) respectively.
例如，对于分别为2秒、6秒、15秒和30秒的值，a和b分别为：（a=0，b=5）、（a=8，b=6）、（a=14，b=7）和（a=14，b=8）。
HELLO_MESSAGE = 1
HELLO_MESSAGE = 1
TC_MESSAGE = 2
TC_MESSAGE = 2
MID_MESSAGE = 3
MID_MESSAGE = 3
HNA_MESSAGE = 4
HNA_MESSAGE = 4
UNSPEC_LINK = 0
UNSPEC_LINK = 0
ASYM_LINK = 1
ASYM_LINK = 1
SYM_LINK = 2
SYM_LINK = 2
LOST_LINK = 3
LOST_LINK = 3
NOT_NEIGH = 0
NOT_NEIGH = 0
SYM_NEIGH = 1
SYM_NEIGH = 1
MPR_NEIGH = 2
MPR_NEIGH = 2
HYST_THRESHOLD_HIGH = 0.8
HYST_阈值_高=0.8
HYST_THRESHOLD_LOW = 0.3
HYST_阈值_低=0.3
HYST_SCALING = 0.5
HYST_比例=0.5
WILL_NEVER = 0
WILL_NEVER = 0
WILL_LOW = 1
WILL_LOW = 1
WILL_DEFAULT = 3
WILL_DEFAULT = 3
WILL_HIGH = 6
WILL_HIGH = 6
WILL_ALWAYS = 7
WILL_ALWAYS = 7
The willingness of a node may be set to any integer value from 0 to 7, and specifies how willing a node is to be forwarding traffic on behalf of other nodes. Nodes will, by default, have a willingness WILL_DEFAULT. WILL_NEVER indicates a node which does not wish to carry traffic for other nodes, for example due to resource constraints (like being low on battery). WILL_ALWAYS indicates that a node always should be selected to carry traffic on behalf of other nodes, for example due to resource abundance (like permanent power supply, high capacity interfaces to other nodes).
节点的意愿可以设置为0到7之间的任何整数值，并指定节点代表其他节点转发流量的意愿。默认情况下，节点将具有默认的意愿。WILL_从不表示不希望为其他节点承载流量的节点，例如由于资源限制（如电池电量不足）。WILL_始终指示应始终选择一个节点代表其他节点承载流量，例如，由于资源丰富（如永久电源、与其他节点的高容量接口）。
A node may dynamically change its willingness as its conditions change.
节点可以随着其条件的变化动态地改变其意愿。
One possible application would, for example, be for a node, connected to a permanent power supply and with fully charged batteries, to advertise a willingness of WILL_ALWAYS. Upon being disconnected from the permanent power supply (e.g., a PDA being taken out of its charging cradle), a willingness of WILL_DEFAULT is advertised. As battery capacity is drained, the willingness would be further reduced. First to the intermediate value between WILL_DEFAULT and WILL_LOW, then to WILL_LOW and finally to WILL_NEVER, when the battery capacity of the node does no longer support carrying foreign traffic.
例如，一种可能的应用是，一个节点连接到永久性电源，并使用充满电的电池，以宣传WILL_ALWAYS的意愿。断开与永久电源的连接（例如，将PDA从充电支架中取出）后，将显示愿意违约。随着电池容量的耗尽，这种意愿将进一步降低。当节点的电池容量不再支持承载外部通信量时，首先是WILL_DEFAULT和WILL_LOW之间的中间值，然后是WILL_LOW，最后是WILL_NEVER。
TC_REDUNDANCY = 0
TC_REDUNDANCY = 0
MPR COVERAGE = 1
MPR覆盖率=1
MAXJITTER = HELLO_INTERVAL / 4
MAXJITTER = HELLO_INTERVAL / 4
Sequence numbers are used in OLSR with the purpose of discarding "old" information, i.e., messages received out of order. However with a limited number of bits for representing sequence numbers, wrap-around (that the sequence number is incremented from the maximum possible value to zero) will occur. To prevent this from interfering with the operation of the protocol, the following MUST be observed.
序列号用于OLSR，目的是丢弃“旧”信息，即无序接收的消息。但是，对于表示序列号的位数有限的情况，将出现环绕（即序列号从最大可能值增加到零）。为防止干扰协议的运行，必须遵守以下规定。
The term MAXVALUE designates in the following the largest possible value for a sequence number.
术语MAXVALUE在下面指定序列号的最大可能值。
The sequence number S1 is said to be "greater than" the sequence number S2 if:
如果：
S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR
S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR
S2 > S1 AND S2 - S1 > MAXVALUE/2
S2 > S1 AND S2 - S1 > MAXVALUE/2
Thus when comparing two messages, it is possible - even in the presence of wrap-around - to determine which message contains the most recent information.
因此，在比较两条消息时，即使存在环绕，也可以确定哪条消息包含最新信息。
Currently, OLSR does not specify any special security measures. As a proactive routing protocol, OLSR makes a target for various attacks. The various possible vulnerabilities are discussed in this section.
目前，OLSR未规定任何特殊安全措施。作为一种主动路由协议，OLSR成为各种攻击的目标。本节将讨论各种可能的漏洞。
Being a proactive protocol, OLSR periodically diffuses topological information. Hence, if used in an unprotected wireless network, the network topology is revealed to anyone who listens to OLSR control messages.
作为一种主动协议，OLSR周期性地扩散拓扑信息。因此，如果在未受保护的无线网络中使用，网络拓扑将显示给任何侦听OLSR控制消息的人。
In situations where the confidentiality of the network topology is of importance, regular cryptographic techniques such as exchange of OLSR control traffic messages encrypted by PGP [9] or encrypted by some shared secret key can be applied to ensure that control traffic can be read and interpreted by only those authorized to do so.
在网络拓扑的机密性非常重要的情况下，可以应用常规加密技术，例如交换由PGP[9]加密或由某些共享密钥加密的OLSR控制流量消息，以确保控制流量只能由授权的人读取和解释。
In OLSR, each node is injecting topological information into the network through transmitting HELLO messages and, for some nodes, TC messages. If some nodes for some reason, malicious or malfunction, inject invalid control traffic, network integrity may be compromised. Therefore, message authentication is recommended.
在OLSR中，每个节点通过传输HELLO消息和TC消息将拓扑信息注入网络。如果某些节点出于某种原因，恶意或故障，注入无效的控制流量，网络完整性可能会受到损害。因此，建议使用消息身份验证。
Different such situations may occur, for instance:
可能会出现不同的情况，例如：
1 a node generates TC (or HNA) messages, advertising links to non-neighbor nodes:
1节点生成TC（或HNA）消息，向非邻居节点发送广告链接：
2 a node generates TC (or HNA) messages, pretending to be another node,
2一个节点生成TC（或HNA）消息，假装是另一个节点，
3 a node generates HELLO messages, advertising non-neighbor nodes,
3节点生成HELLO消息，通知非邻居节点，
4 a node generates HELLO messages, pretending to be another node.
4一个节点生成HELLO消息，假装是另一个节点。
5 a node forwards altered control messages,
5节点转发更改的控制消息，
6 a node does not broadcast control messages,
6节点不广播控制消息，
7 a node does not select multipoint relays correctly.
7节点未正确选择多点继电器。
8 a node forwards broadcast control messages unaltered, but does not forward unicast data traffic;
8节点转发未改变的广播控制消息，但不转发单播数据业务；
9 a node "replays" previously recorded control traffic from another node.
9一个节点“重放”先前从另一个节点记录的控制流量。
Authentication of the originator node for control messages (for situation 2, 4 and 5) and on the individual links announced in the control messages (for situation 1 and 3) may be used as a countermeasure. However to prevent nodes from repeating old (and correctly authenticated) information (situation 9) temporal information is required, allowing a node to positively identify such delayed messages.
对于控制消息（对于情形2、4和5）和在控制消息（对于情形1和3）中宣布的各个链路上的发端节点的认证可以用作对策。然而，为了防止节点重复旧的（并且经过正确验证的）信息（情况9），需要时间信息，允许节点积极识别此类延迟消息。
In general, digital signatures and other required security information may be transmitted as a separate OLSR message type, thereby allowing that "secured" and "unsecured" nodes can coexist in the same network, if desired.
通常，数字签名和其他所需的安全信息可以作为单独的OLSR消息类型来传输，从而允许“安全”和“不安全”节点可以在同一网络中共存（如果需要）。
Specifically, the authenticity of entire OLSR control messages can be established through employing IPsec authentication headers, whereas authenticity of individual links (situation 1 and 3) require additional security information to be distributed.
具体而言，整个OLSR控制消息的真实性可以通过使用IPsec身份验证头来建立，而单个链路（情况1和3）的真实性需要分发额外的安全信息。
An important consideration is, that all control messages in OLSR are transmitted either to all nodes in the neighborhood (HELLO messages) or broadcast to all nodes in the network (e.g., TC messages).
一个重要的考虑因素是，OLSR中的所有控制消息要么被传输到邻居中的所有节点（HELLO消息），要么被广播到网络中的所有节点（例如，TC消息）。
For example, a control message in OLSR is always a point-to-multipoint transmission. It is therefore important that the authentication mechanism employed permits that any receiving node can validate the authenticity of a message. As an analogy, given a block of text, signed by a PGP private key, then anyone with the corresponding public key can verify the authenticity of the text.
例如，OLSR中的控制消息始终是点对多点传输。因此，所采用的认证机制必须允许任何接收节点验证消息的真实性。作为类比，给定一个由PGP私钥签名的文本块，那么任何拥有相应公钥的人都可以验证文本的真实性。
OLSR does, through the HNA messages specified in section 12, provide a basic mechanism for injecting external routing information to the OLSR domain. Section 12 also specifies that routing information can be extracted from the topology table or the routing table of OLSR and, potentially, injected into an external domain if the routing protocol governing that domain permits.
OLSR确实通过第12节中规定的HNA消息提供了向OLSR域注入外部路由信息的基本机制。第12节还规定，可以从OLSR的拓扑表或路由表中提取路由信息，如果管理该域的路由协议允许，则可能将其注入到外部域中。
Other than as described in the section 20.2, when operating nodes, connecting OLSR to an external routing domain, care MUST be taken not to allow potentially insecure and un-trustworthy information to be injected from the OLSR domain to external routing domains. Care MUST be taken to validate the correctness of information prior to it being injected as to avoid polluting routing tables with invalid information.
除第20.2节所述之外，当操作节点将OLSR连接到外部路由域时，必须注意不要允许潜在的不安全和不可信信息从OLSR域注入外部路由域。在注入信息之前，必须小心验证信息的正确性，以避免使用无效信息污染路由表。
A recommended way of extending connectivity from an existing routing domain to an OLSR routed MANET is to assign an IP prefix (under the authority of the nodes/gateways connecting the MANET with the exiting routing domain) exclusively to the OLSR MANET area, and to configure the gateways statically to advertise routes to that IP sequence to nodes in the existing routing domain.
将连接从现有路由域扩展到OLSR路由MANET的推荐方法是将IP前缀（在连接MANET和现有路由域的节点/网关的授权下）专门分配给OLSR MANET区域，以及静态地配置网关，以便将到该IP序列的路由播发到现有路由域中的节点。
OLSR does not make any assumption about node addresses, other than that each node is assumed to have a unique IP address.
除了假设每个节点都有一个唯一的IP地址之外，OLSR不对节点地址进行任何假设。
Due to its proactive nature, the OLSR protocol has a natural control over the flow of its control traffic. Nodes transmits control message at predetermined rates fixed by predefined refresh intervals. Furthermore the MPR optimization greatly saves on control overhead, and this is done on two sides. First, the packets that advertise the topology are much shorter since only MPR selectors may be advertised. Second, the cost of flooding this information is greatly reduced since only MPR nodes forward the broadcast packets. In dense networks, the reduction of control traffic can be of several orders of magnitude compared to routing protocols using classical flooding (such as OSPF) [10]. This feature naturally provides more bandwidth for useful data traffic and pushes further the frontier of congestion. Since the control traffic is continuous and periodic, it keeps more stable the quality of the links used in routing, where reactive protocols, with bursty floodings for route discoveries and repairs, may damage the link qualities for short times by causing numerous collisions on those links, possibly provoking route repair cascades. However, in certain OLSR options, some control messages may be intentionally sent in advance of their deadline(TC or Hello messages) in order to increase the reactiveness of the protocol against topology changes. This may cause a small, temporary and local increase of control traffic.
由于其主动性，OLSR协议对其控制流量具有自然控制。节点以预定义刷新间隔固定的预定速率传输控制消息。此外，MPR优化大大节省了控制开销，这是在两个方面完成的。首先，播发拓扑的数据包要短得多，因为只能播发MPR选择器。第二，由于只有MPR节点转发广播数据包，因此淹没该信息的成本大大降低。在密集网络中，与使用经典泛洪（如OSPF）的路由协议相比，控制流量的减少可以达到几个数量级[10]。这一特性自然为有用的数据流量提供了更多的带宽，并进一步推动了拥塞的前沿。由于控制流量是连续的和周期性的，因此它使路由中使用的链路的质量保持更稳定，其中反应性协议（用于路由发现和修复的突发洪水）可能会在短时间内通过在这些链路上引起多次碰撞而损坏链路质量，可能引发路由修复级联。然而，在某些OLSR选项中，一些控制消息可能有意在其截止日期之前发送（TC或Hello消息），以增加协议对拓扑更改的反应性。这可能会导致控制流量的小规模、临时性和局部性增加。
OLSR defines a "Message Type" field for control messages. A new registry has been created for the values for this Message Type field, and the following values assigned:
OLSR为控制消息定义“消息类型”字段。已为此邮件类型字段的值创建了一个新注册表，并分配了以下值：
Message Type Value
-------------------- -----
HELLO_MESSAGE 1
TC_MESSAGE 2
MID_MESSAGE 3
HNA_MESSAGE 4
Message Type Value
-------------------- -----
HELLO_MESSAGE 1
TC_MESSAGE 2
MID_MESSAGE 3
HNA_MESSAGE 4
Future values in the range 5-127 of the Message Type can be allocated using standards action [7].
可以使用标准操作[7]分配消息类型5-127范围内的未来值。
Additionally, values in the range 128-255 are reserved for private/local use.
此外，128-255范围内的值保留供私人/本地使用。
The authors would like to thank Joseph Macker <macker@itd.nrl.navy.mil> and his team, including Justin Dean <jdean@itd.nrl.navy.mil>, for their valuable suggestions on the advanced neighbor sensing mechanism and other various aspects of the protocol, including careful review of the protocol specification.
作者要感谢约瑟夫·麦克尔<macker@itd.nrl.navy.mil>还有他的团队，包括贾斯汀·迪恩<jdean@itd.nrl.navy.mil>，感谢他们对高级邻居感知机制和协议其他各个方面的宝贵建议，包括仔细审查协议规范。
The authors would also like to thank Christopher Dearlove <chris.dearlove@baesystems.com> for valuable input on the MPR selection heuristics and for careful reviews of the protocol specification.
作者还要感谢Christopher Dearlove<chris。dearlove@baesystems.com>对于MPR选择启发法的有价值的输入和对协议规范的仔细审查。
During the development of this specification, the following list of people contributed. The contributors are listed alphabetically.
在本规范的制定过程中，下列人员参与了本规范的制定。贡献者按字母顺序列出。
Cedric Adjih Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Cedric Adjih项目HIPERCOM INRIA Rocurcourt，英国石油公司105 78153勒切斯奈Cedex，法国
Phone: +33 1 3963 5215
EMail: Cedric.Adjih@inria.fr
Phone: +33 1 3963 5215
EMail: Cedric.Adjih@inria.fr
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Thomas Heide Clausen项目HIPERCOM INRIA Rokuncourt，英国石油公司105 78153勒切斯奈塞德斯，法国
Phone: +33 1 3963 5133
EMail: T.Clausen@computer.org
Phone: +33 1 3963 5133
EMail: T.Clausen@computer.org
Philippe Jacquet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Philippe Jacquet项目HIPERCOM INRIA Rocuncourt，BP 105 78153 Le Chesnay Cedex，法国
Phone: +33 1 3963 5263
EMail: Philippe.Jacquet@inria.fr
Phone: +33 1 3963 5263
EMail: Philippe.Jacquet@inria.fr
Anis Laouiti Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Anis Laouiti项目HIPERCOM INRIA Rocurcourt，英国石油公司105 78153勒切斯奈塞德斯，法国
Phone: +33 1 3963 5088
EMail: Anis.Laouiti@inria.fr
Phone: +33 1 3963 5088
EMail: Anis.Laouiti@inria.fr
Pascale Minet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Pascale Minet项目HIPERCOM INRIA Rocurcourt，BP 105 78153 Le Chesnay Cedex，法国
Phone: +33 1 3963 5233
EMail: Pascale.Minet@inria.fr
Phone: +33 1 3963 5233
EMail: Pascale.Minet@inria.fr
Paul Muhlethaler Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Paul Muhlethaler项目HIPERCOM INRIA Rocuncourt，BP 105 78153 Le Chesnay Cedex，法国
Phone: +33 1 3963 5278
EMail: Paul.Muhlethaler@inria.fr
Phone: +33 1 3963 5278
EMail: Paul.Muhlethaler@inria.fr
Amir Qayyum Center for Advanced Research in Engineering Pvt. Ltd. 19 Ataturk Avenue Islamabad, Pakistan
阿米尔·卡尤姆工程高级研究中心私人有限公司，巴基斯坦伊斯兰堡阿塔图克大道19号
Phone: +92-51-2874115
EMail: amir@carepvtltd.com
Phone: +92-51-2874115
EMail: amir@carepvtltd.com
Laurent Viennot Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Laurent Vienno项目HIPERCOM INRIA Rocuncourt，英国石油公司105 78153勒切斯奈塞德斯，法国
Phone: +33 1 3963 5225
EMail: Laurent.Viennot@inria.fr
Phone: +33 1 3963 5225
EMail: Laurent.Viennot@inria.fr
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A. Qayyum and L. Viennot. Optimized Link State Routing Protocol. IEEE INMIC Pakistan 2001.
[7] 克劳森、雅克、劳伊特、穆勒泰勒、卡尤姆和维诺。优化链路状态路由协议。IEEE INMIC巴基斯坦2001。
[1] P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing reliability in cable free radio LANs: Low level forwarding in HIPERLAN. Wireless Personal Communications, 1996.
[1] P.雅克，P.米内，P.穆勒泰勒，N.里维埃尔。提高无电缆无线局域网的可靠性：HIPERLAN中的低层转发。无线个人通信，1996年。
[2] A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An efficient technique for flooding in mobile wireless networks. 35th Annual Hawaii International Conference on System Sciences (HICSS'2001).
[2] A.Qayyum，L.Vienno，A.Laouiti。多点中继：移动无线网络中一种有效的泛洪技术。第35届夏威夷系统科学国际年会（HICSS'2001）。
[3] ETSI STC-RES10 Committee. Radio equipment and systems: HIPERLAN type 1, functional specifications ETS 300-652, ETSI, June 1996.
[3] ETSI STC-RES10委员会。无线电设备和系统：HIPERLAN 1型，功能规范ETS 300-652，ETSI，1996年6月。
[4] P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network Protocols, INRIA research report RR-3965, 2000.
[4] P.Jacquet和L.Vienno，《移动自组织网络协议中的开销》，INRIA研究报告RR-3965，2000年。
[6] T. Clausen, G. Hansen, L. Christensen and G. Behrmann. The Optimized Link State Routing Protocol, Evaluation through Experiments and Simulation. IEEE Symposium on "Wireless Personal Mobile Communications", September 2001.
[6] T.克劳森、G.汉森、L.克里斯滕森和G.贝尔曼。优化后的链路状态路由协议，通过实验和仿真进行评估。IEEE“无线个人移动通信”研讨会，2001年9月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[9] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[9] Atkins，D.，Stallings，W.和P.Zimmermann，“PGP消息交换格式”，RFC 1991，1996年8月。
[10] P. Jacquet, A. Laouiti, P. Minet, L. Viennot. Performance analysis of OLSR multipoint relay flooding in two ad hoc wireless network models, INRIA research report RR-4260, 2001.
[10] P.雅克，A.拉乌蒂，P.米内，L.维诺。OLSR多点中继泛洪在两种adhoc无线网络模型中的性能分析，INRIA研究报告RR-42602001。
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Thomas Heide Clausen项目HIPERCOM INRIA Rokuncourt，英国石油公司105 78153勒切斯奈塞德斯，法国
Phone: +33 1 3963 5133
EMail: T.Clausen@computer.org
Phone: +33 1 3963 5133
EMail: T.Clausen@computer.org
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Philippe Jacquet，HIPERCOM项目，INRIA Roquencourt，BP 105 78153 Le Chesnay Cedex，法国
Phone: +33 1 3963 5263,
EMail: Philippe.Jacquet@inria.fr
Phone: +33 1 3963 5263,
EMail: Philippe.Jacquet@inria.fr
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。