Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 7181 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
ISSN: 2070-1721 BAE Systems ATC
P. Jacquet
Alcatel-Lucent Bell Labs
U. Herberg
Fujitsu Laboratories of America
April 2014
Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 7181 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
ISSN: 2070-1721 BAE Systems ATC
P. Jacquet
Alcatel-Lucent Bell Labs
U. Herberg
Fujitsu Laboratories of America
April 2014
The Optimized Link State Routing Protocol Version 2
优化链路状态路由协议版本2
Abstract
摘要
This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).
本规范描述了用于移动自组织网络（MANET）的优化链路状态路由协议（OLSRv2）的第2版。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7181.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7181.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................5
2. Terminology .....................................................6
3. Applicability Statement .........................................9
4. Protocol Overview and Functioning ..............................10
4.1. Overview ..................................................10
4.2. Routers and Interfaces ....................................12
4.3. Information Base Overview .................................13
4.3.1. Local Information Base .............................13
4.3.2. Interface Information Base .........................14
4.3.3. Neighbor Information Base ..........................14
4.3.4. Topology Information Base ..........................14
4.3.5. Received Message Information Base ..................16
4.4. Signaling Overview ........................................16
4.5. Link Metrics ..............................................17
4.6. Flooding MPRs and Routing MPR .............................18
4.7. Routing Set Use ...........................................19
5. Protocol Parameters and Constants ..............................19
5.1. Protocol and Port Numbers .................................19
5.2. Multicast Address .........................................20
5.3. Interface Parameters ......................................20
5.3.1. Received Message Validity Time .....................20
5.4. Router Parameters .........................................20
5.4.1. Local History Times ................................20
5.4.2. Link Metric Parameters .............................21
5.4.3. Message Intervals ..................................21
5.4.4. Advertised Information Validity Times ..............22
5.4.5. Processing and Forwarding Validity Times ...........22
5.4.6. Jitter .............................................23
5.4.7. Hop Limit ..........................................23
5.4.8. Willingness ........................................24
5.5. Parameter Change Constraints ..............................25
5.6. Constants .................................................27
5.6.1. Link Metric Constants ..............................27
5.6.2. Willingness Constants ..............................28
1. Introduction ....................................................5
2. Terminology .....................................................6
3. Applicability Statement .........................................9
4. Protocol Overview and Functioning ..............................10
4.1. Overview ..................................................10
4.2. Routers and Interfaces ....................................12
4.3. Information Base Overview .................................13
4.3.1. Local Information Base .............................13
4.3.2. Interface Information Base .........................14
4.3.3. Neighbor Information Base ..........................14
4.3.4. Topology Information Base ..........................14
4.3.5. Received Message Information Base ..................16
4.4. Signaling Overview ........................................16
4.5. Link Metrics ..............................................17
4.6. Flooding MPRs and Routing MPR .............................18
4.7. Routing Set Use ...........................................19
5. Protocol Parameters and Constants ..............................19
5.1. Protocol and Port Numbers .................................19
5.2. Multicast Address .........................................20
5.3. Interface Parameters ......................................20
5.3.1. Received Message Validity Time .....................20
5.4. Router Parameters .........................................20
5.4.1. Local History Times ................................20
5.4.2. Link Metric Parameters .............................21
5.4.3. Message Intervals ..................................21
5.4.4. Advertised Information Validity Times ..............22
5.4.5. Processing and Forwarding Validity Times ...........22
5.4.6. Jitter .............................................23
5.4.7. Hop Limit ..........................................23
5.4.8. Willingness ........................................24
5.5. Parameter Change Constraints ..............................25
5.6. Constants .................................................27
5.6.1. Link Metric Constants ..............................27
5.6.2. Willingness Constants ..............................28
5.6.3. Time Constant ......................................28
6. Link Metric Values .............................................28
6.1. Link Metric Representation ................................28
6.2. Link Metric Compressed Form ...............................29
7. Local Information Base .........................................29
7.1. Originator Set ............................................30
7.2. Local Attached Network Set ................................30
8. Interface Information Base .....................................31
8.1. Link Set ..................................................31
8.2. 2-Hop Set .................................................32
9. Neighbor Information Base ......................................32
10. Topology Information Base .....................................34
10.1. Advertising Remote Router Set ............................34
10.2. Router Topology Set ......................................35
10.3. Routable Address Topology Set ............................35
10.4. Attached Network Set .....................................36
10.5. Routing Set ..............................................37
11. Received Message Information Base .............................37
11.1. Received Set .............................................38
11.2. Processed Set ............................................38
11.3. Forwarded Set ............................................39
12. Information Base Properties ...................................39
12.1. Corresponding Protocol Tuples ............................39
12.2. Address Ownership ........................................40
13. Packets and Messages ..........................................41
13.1. Messages .................................................41
13.2. Packets ..................................................41
13.3. TLVs .....................................................42
13.3.1. Message TLVs ......................................42
13.3.2. Address Block TLVs ................................42
14. Message Processing and Forwarding .............................45
14.1. Actions When Receiving a Message .........................45
14.2. Message Considered for Processing ........................46
14.3. Message Considered for Forwarding ........................47
15. HELLO Messages ................................................49
15.1. HELLO Message Generation .................................49
15.2. HELLO Message Transmission ...............................51
15.3. HELLO Message Processing .................................51
15.3.1. HELLO Message Discarding ..........................51
15.3.2. HELLO Message Usage ...............................52
16. TC Messages ...................................................56
16.1. TC Message Generation ....................................56
16.2. TC Message Transmission ..................................58
16.3. TC Message Processing ....................................59
16.3.1. TC Message Discarding .............................59
16.3.2. TC Message Processing Definitions .................61
16.3.3. Initial TC Message Processing .....................61
16.3.4. Completing TC Message Processing ..................65
5.6.3. Time Constant ......................................28
6. Link Metric Values .............................................28
6.1. Link Metric Representation ................................28
6.2. Link Metric Compressed Form ...............................29
7. Local Information Base .........................................29
7.1. Originator Set ............................................30
7.2. Local Attached Network Set ................................30
8. Interface Information Base .....................................31
8.1. Link Set ..................................................31
8.2. 2-Hop Set .................................................32
9. Neighbor Information Base ......................................32
10. Topology Information Base .....................................34
10.1. Advertising Remote Router Set ............................34
10.2. Router Topology Set ......................................35
10.3. Routable Address Topology Set ............................35
10.4. Attached Network Set .....................................36
10.5. Routing Set ..............................................37
11. Received Message Information Base .............................37
11.1. Received Set .............................................38
11.2. Processed Set ............................................38
11.3. Forwarded Set ............................................39
12. Information Base Properties ...................................39
12.1. Corresponding Protocol Tuples ............................39
12.2. Address Ownership ........................................40
13. Packets and Messages ..........................................41
13.1. Messages .................................................41
13.2. Packets ..................................................41
13.3. TLVs .....................................................42
13.3.1. Message TLVs ......................................42
13.3.2. Address Block TLVs ................................42
14. Message Processing and Forwarding .............................45
14.1. Actions When Receiving a Message .........................45
14.2. Message Considered for Processing ........................46
14.3. Message Considered for Forwarding ........................47
15. HELLO Messages ................................................49
15.1. HELLO Message Generation .................................49
15.2. HELLO Message Transmission ...............................51
15.3. HELLO Message Processing .................................51
15.3.1. HELLO Message Discarding ..........................51
15.3.2. HELLO Message Usage ...............................52
16. TC Messages ...................................................56
16.1. TC Message Generation ....................................56
16.2. TC Message Transmission ..................................58
16.3. TC Message Processing ....................................59
16.3.1. TC Message Discarding .............................59
16.3.2. TC Message Processing Definitions .................61
16.3.3. Initial TC Message Processing .....................61
16.3.4. Completing TC Message Processing ..................65
17. Information Base Changes ......................................66
17.1. Originator Address Changes ...............................66
17.2. Link State Changes .......................................66
17.3. Neighbor State Changes ...................................67
17.4. Advertised Neighbor Changes ..............................67
17.5. Advertising Remote Router Tuple Expires ..................68
17.6. Neighborhood Changes and MPR Updates .....................68
17.7. Routing Set Updates ......................................70
18. Selecting MPRs ................................................71
18.1. Overview .................................................72
18.2. Neighbor Graph ...........................................72
18.3. MPR Properties ...........................................73
18.4. Flooding MPRs ............................................74
18.5. Routing MPRs .............................................76
18.6. Calculating MPRs .........................................77
19. Routing Set Calculation .......................................78
19.1. Network Topology Graph ...................................78
19.2. Populating the Routing Set ...............................80
20. Proposed Values for Parameters ................................81
20.1. Local History Time Parameters ............................82
20.2. Message Interval Parameters ..............................82
20.3. Advertised Information Validity Time Parameters ..........82
20.4. Received Message Validity Time Parameters ................82
20.5. Jitter Time Parameters ...................................82
20.6. Hop Limit Parameter ......................................82
20.7. Willingness Parameters ...................................82
21. Sequence Numbers ..............................................83
22. Extensions ....................................................83
23. Security Considerations .......................................84
23.1. Security Architecture ....................................84
23.2. Integrity ................................................85
23.3. Confidentiality ..........................................86
23.4. Interaction with External Routing Domains ................87
23.5. Mandatory Security Mechanisms ............................87
23.6. Key Management ...........................................88
24. IANA Considerations ...........................................90
24.1. Expert Review: Evaluation Guidelines .....................91
24.2. Message Types ............................................91
24.3. Message-Type-Specific TLV Type Registries ................91
24.4. Message TLV Types ........................................92
24.5. Address Block TLV Types ..................................93
24.6. NBR_ADDR_TYPE and MPR Values .............................96
25. Contributors ..................................................96
26. Acknowledgments ...............................................97
27. References ....................................................97
27.1. Normative References .....................................97
27.2. Informative References ...................................98
Appendix A. Constraints .........................................100
17. Information Base Changes ......................................66
17.1. Originator Address Changes ...............................66
17.2. Link State Changes .......................................66
17.3. Neighbor State Changes ...................................67
17.4. Advertised Neighbor Changes ..............................67
17.5. Advertising Remote Router Tuple Expires ..................68
17.6. Neighborhood Changes and MPR Updates .....................68
17.7. Routing Set Updates ......................................70
18. Selecting MPRs ................................................71
18.1. Overview .................................................72
18.2. Neighbor Graph ...........................................72
18.3. MPR Properties ...........................................73
18.4. Flooding MPRs ............................................74
18.5. Routing MPRs .............................................76
18.6. Calculating MPRs .........................................77
19. Routing Set Calculation .......................................78
19.1. Network Topology Graph ...................................78
19.2. Populating the Routing Set ...............................80
20. Proposed Values for Parameters ................................81
20.1. Local History Time Parameters ............................82
20.2. Message Interval Parameters ..............................82
20.3. Advertised Information Validity Time Parameters ..........82
20.4. Received Message Validity Time Parameters ................82
20.5. Jitter Time Parameters ...................................82
20.6. Hop Limit Parameter ......................................82
20.7. Willingness Parameters ...................................82
21. Sequence Numbers ..............................................83
22. Extensions ....................................................83
23. Security Considerations .......................................84
23.1. Security Architecture ....................................84
23.2. Integrity ................................................85
23.3. Confidentiality ..........................................86
23.4. Interaction with External Routing Domains ................87
23.5. Mandatory Security Mechanisms ............................87
23.6. Key Management ...........................................88
24. IANA Considerations ...........................................90
24.1. Expert Review: Evaluation Guidelines .....................91
24.2. Message Types ............................................91
24.3. Message-Type-Specific TLV Type Registries ................91
24.4. Message TLV Types ........................................92
24.5. Address Block TLV Types ..................................93
24.6. NBR_ADDR_TYPE and MPR Values .............................96
25. Contributors ..................................................96
26. Acknowledgments ...............................................97
27. References ....................................................97
27.1. Normative References .....................................97
27.2. Informative References ...................................98
Appendix A. Constraints .........................................100
Appendix B. Example Algorithm for Calculating MPRs ..............104
B.1. Additional Notation ......................................104
B.2. MPR Selection Algorithm ................................. 105
Appendix C. Example Algorithm for Calculating the Routing Set ...105
C.1. Local Interfaces and Neighbors ...........................106
C.2. Add Neighbor Routers .....................................107
C.3. Add Remote Routers .......................................107
C.4. Add Neighbor Addresses ...................................108
C.5. Add Remote Routable Addresses ............................109
C.6. Add Attached Networks ....................................110
C.7. Add 2-Hop Neighbors ......................................110
Appendix D. TC Message Example ..................................111
Appendix E. Flow and Congestion Control .........................114
Appendix B. Example Algorithm for Calculating MPRs ..............104
B.1. Additional Notation ......................................104
B.2. MPR Selection Algorithm ................................. 105
Appendix C. Example Algorithm for Calculating the Routing Set ...105
C.1. Local Interfaces and Neighbors ...........................106
C.2. Add Neighbor Routers .....................................107
C.3. Add Remote Routers .......................................107
C.4. Add Neighbor Addresses ...................................108
C.5. Add Remote Routable Addresses ............................109
C.6. Add Attached Networks ....................................110
C.7. Add 2-Hop Neighbors ......................................110
Appendix D. TC Message Example ..................................111
Appendix E. Flow and Congestion Control .........................114
The Optimized Link State Routing Protocol version 2 (OLSRv2) is the successor to OLSR (version 1) as published in [RFC3626]. Compared to [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, enhanced by the ability to use a link metric other than hop count in the selection of shortest routes. OLSRv2 also uses a more flexible and efficient signaling framework and includes some simplification of the messages being exchanged.
优化链路状态路由协议版本2（OLSRv2）是[RFC3626]中发布的OLSR（版本1）的后续版本。与[RFC3626]相比，OLSRv2保留了相同的基本机制和算法，通过在选择最短路由时使用跳数以外的链路度量来增强。OLSRv2还使用了更灵活、更高效的信令框架，并对正在交换的消息进行了一些简化。
OLSRv2 is developed for Mobile Ad Hoc Networks (MANETs). It operates as a table-driven, proactive protocol, i.e., it exchanges topology information with other routers in the network regularly. OLSRv2 is an optimization of the classic link state routing protocol. Its key concept is that of multipoint relays (MPRs). Each router selects two sets of MPRs, each being a set of its neighbor routers that "cover" all of its symmetrically connected 2-hop neighbor routers. These two sets are "flooding MPRs" and "routing MPRs", which are used to achieve flooding reduction and topology reduction, respectively.
OLSRv2是为移动自组织网络（MANET）开发的。它作为一个表驱动的主动协议运行，即，它定期与网络中的其他路由器交换拓扑信息。OLSRv2是对经典链路状态路由协议的优化。其关键概念是多点继电器（MPR）。每个路由器选择两组MPR，每个MPR是一组其邻居路由器，“覆盖”其所有对称连接的2跳邻居路由器。这两组是“泛洪MPR”和“路由MPR”，分别用于实现泛洪减少和拓扑减少。
Flooding reduction is achieved by control traffic being flooded through the network using hop-by-hop forwarding, but with a router only needing to forward control traffic that is first received directly from one of the routers that have selected it as a flooding MPR (its "flooding MPR selectors"). This mechanism, denoted "MPR flooding", provides an efficient mechanism for information distribution within the MANET by reducing the number of transmissions required [MPR].
洪泛减少是通过使用逐跳转发将控制流量通过网络洪泛来实现的，但是路由器只需要转发首先直接从选择它作为洪泛MPR的其中一个路由器（其“洪泛MPR选择器”）接收的控制流量。这种机制被称为“MPR泛洪”，通过减少所需的传输次数[MPR]，为MANET内的信息分发提供了一种有效的机制。
Topology reduction is achieved by assigning a special responsibility to routers selected as routing MPRs when declaring link state information. A sufficient requirement for OLSRv2 to provide shortest routes to all destinations is that routers declare link state information for their routing MPR selectors, if any. Routers that
拓扑减少是通过在声明链路状态信息时为选择为路由MPR的路由器分配特殊责任来实现的。OLSRv2提供到所有目的地的最短路由的充分要求是路由器为其路由MPR选择器（如果有）声明链路状态信息。路由器
are not selected as routing MPRs need not send any link state information. Based on this reduced link state information, routing MPRs are used as intermediate routers in multi-hop routes.
未选择，因为路由MPR不需要发送任何链路状态信息。基于这种简化的链路状态信息，路由mpr被用作多跳路由的中间路由器。
Thus, the use of MPRs allows reduction of the number and the size of link state messages and reduction in the amount of link state information maintained in each router. When possible (in particular if using a hop count metric), the same routers may be picked as both flooding MPRs and routing MPRs.
因此，mpr的使用允许减少链路状态消息的数量和大小，并减少每个路由器中维护的链路状态信息量。在可能的情况下（特别是如果使用跳数度量），可以选择相同的路由器作为泛洪MPR和路由MPR。
A router selects both routing and flooding MPRs from among its one-hop neighbors connected by "symmetric", i.e., bidirectional, links. Therefore, selecting routes through routing MPRs avoids the problems associated with data packet transfer over unidirectional links (e.g., the problem of not getting link-layer acknowledgments at each hop, for link layers employing this technique).
路由器从其通过“对称”（即双向）链路连接的单跳邻居中选择路由和泛洪MPR。因此，通过路由mpr选择路由避免了与单向链路上的数据分组传输相关联的问题（例如，对于采用该技术的链路层，在每个跃点处不获得链路层确认的问题）。
OLSRv2 uses and extends the MANET Neighborhood Discovery Protocol (NHDP) defined in [RFC6130] and also uses the Generalized MANET Packet/Message Format [RFC5444], the TLVs specified in [RFC5497] and, optionally, message jitter as specified in [RFC5148]. These four other protocols and specifications were all originally created as part of OLSRv2 but have been specified separately for wider use.
OLSRv2使用并扩展了[RFC6130]中定义的MANET邻域发现协议（NHDP），还使用了广义MANET数据包/消息格式[RFC5444]、[RFC5497]中指定的TLV以及[RFC5148]中指定的消息抖动（可选）。这四个其他协议和规范最初都是作为OLSRv2的一部分创建的，但为了更广泛的使用而单独指定。
OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, through its use of [RFC6130], may use link-layer information and notifications when available and applicable. In addition, OLSRv2 uses link metrics that may be derived from link layer or any other information. OLSRv2 does not specify the physical meaning of link metrics but specifies a means by which new types of link metrics may be specified in the future but used by OLSRv2 without modification.
OLSRv2不对底层链路层进行任何假设。OLSRv2通过使用[RFC6130]，可以在可用和适用时使用链路层信息和通知。此外，OLSRv2使用可从链路层或任何其他信息导出的链路度量。OLSRv2未指定链路度量的物理含义，但指定了一种方法，通过该方法，将来可以指定新类型的链路度量，但OLSRv2无需修改即可使用。
OLSRv2, like OLSR [RFC3626], inherits its concept of forwarding and relaying from the High Performance Radio Local Area Network (HIPERLAN) (a MAC-layer protocol), which is standardized by ETSI [HIPERLAN] [HIPERLAN2]. This document does not obsolete [RFC3626], which is left in place for further experimentation.
与OLSR[RFC3626]一样，OLSRv2继承了高性能无线局域网（HIPERLAN）（MAC层协议）的转发和中继概念，该协议由ETSI[HIPERLAN][HIPERLAN 2]标准化。本文件并未废弃[RFC3626]，该文件留作进一步试验之用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
All terms introduced in [RFC5444], including "packet", "Packet Header", "message", "Message Header", "Message Body", "Message Type", "message sequence number", "hop limit", "hop count", "Address Block",
[RFC5444]中介绍的所有术语，包括“包”、“包头”、“消息”、“消息头”、“消息体”、“消息类型”、“消息序列号”、“跃点限制”、“跃点计数”、“地址块”，
"TLV Block", "TLV", "Message TLV", "Address Block TLV", "type" (of TLV), "type extension" (of TLV), "value" (of TLV), "address", "address prefix", and "address object" are to be interpreted as described there.
“TLV块”、“TLV”、“消息TLV”、“地址块TLV”、“类型”（TLV的）、“类型扩展”（TLV的）、“值”（TLV的）、“地址”、“地址前缀”和“地址对象”将按此处所述进行解释。
All terms introduced in [RFC6130], including "interface", "MANET interface", "network address", "link", "symmetric link", "symmetric 1-hop neighbor", "symmetric 2-hop neighbor", "symmetric 1-hop neighborhood" "constant", "interface parameter", "router parameter", "Information Base", and "HELLO message" are to be interpreted as described there.
[RFC6130]中介绍的所有术语，包括“接口”、“MANET接口”、“网络地址”、“链路”、“对称链路”、“对称1-hop邻居”、“对称2-hop邻居”、“对称1-hop邻居”、“常数”、“接口参数”、“路由器参数”、“信息库”和“HELLO消息”，均应按照此处所述进行解释。
Additionally, this specification uses the following terminology:
此外，本规范使用以下术语：
Router: A MANET router that implements this protocol.
路由器：实现此协议的MANET路由器。
OLSRv2 interface: A MANET interface running this protocol. A router running this protocol MUST have at least one OLSRv2 interface.
OLSRv2接口：运行此协议的MANET接口。运行此协议的路由器必须至少有一个OLSRv2接口。
Routable address: A network address that may be used as the destination of a data packet. A router that implements this protocol will need to distinguish a routable address from a non-routable address by direct inspection of the network address, based on global-scope address allocations by IANA and/or administrative configuration (consistently across the MANET). Broadcast and multicast addresses, and addresses that are limited in scope to less than the entire MANET, MUST NOT be considered as routable addresses. Anycast addresses may be considered as routable addresses.
可路由地址：可用作数据包目的地的网络地址。实现此协议的路由器需要根据IANA和/或管理配置（一致地跨MANET）分配的全局作用域地址，通过直接检查网络地址来区分可路由地址和不可路由地址。广播和多播地址，以及限制范围小于整个MANET的地址，不得视为可路由地址。选播地址可视为可路由地址。
Originator address: An address that is unique (within the MANET) to a router. A router MUST select an originator address; it MAY choose one of its interface addresses as its originator address; and it MAY select either a routable or non-routable address. A broadcast, multicast, or anycast address MUST NOT be chosen as an originator address. If the router selects a routable address, then it MUST be one that the router will accept as destination. An originator address MUST NOT have a prefix length, except when included in an Address Block where it MAY be associated with a prefix of maximum prefix length (e.g., if the originator address is an IPv6 address, it MUST have either no prefix length or have a prefix length of 128).
发起者地址：路由器的唯一地址（在MANET内）。路由器必须选择发起者地址；可选择其中一个接口地址作为发起人地址；它可以选择可路由或不可路由的地址。不得将广播、多播或选播地址选作发端地址。如果路由器选择一个可路由的地址，那么它必须是路由器将接受作为目的地的地址。发端地址不得具有前缀长度，除非包含在地址块中，该地址块可能与最大前缀长度的前缀相关联（例如，如果发端地址是IPv6地址，则必须没有前缀长度或前缀长度为128）。
Message originator address: The originator address of the router that created a message, as deduced from that message by its recipient. For all messages used in this specification, including HELLO messages defined in [RFC6130], the recipient MUST be able to deduce an originator address. The message originator address will usually be included in the message as its <msg-orig-addr> element as defined in [RFC5444]. However, an exceptional case, which does not add a <msg-orig-addr> element to a HELLO message, may be used by a router that only has a single address.
消息发起者地址：创建消息的路由器的发起者地址，由其接收者从该消息推断。对于本规范中使用的所有邮件，包括[RFC6130]中定义的HELLO邮件，收件人必须能够推断出发起者地址。消息发起者地址通常作为[RFC5444]中定义的<msg orig addr>元素包含在消息中。然而，一个例外情况，即不向HELLO消息添加<msg orig addr>元素，可能被只有一个地址的路由器使用。
Willingness: A numerical value between WILL_NEVER and WILL_ALWAYS (both inclusive) that represents the router's willingness to be selected as an MPR. A router has separate willingness values to be a flooding MPR and a routing MPR.
意愿：介于WILL_NEVER和WILL_ALWAYS（包括两者）之间的数值，表示路由器被选为MPR的意愿。路由器有单独的意愿值作为泛洪MPR和路由MPR。
Willing symmetric 1-hop neighbor: A symmetric 1-hop neighbor that has willingness not equal to WILL_NEVER.
意愿对称1跳邻居：意愿不等于WILL_NEVER的对称1跳邻居。
Multipoint relay (MPR): A router, X, is an MPR for a router, Y, if router Y has indicated its selection of router X as an MPR in a recent HELLO message. Router X may be a flooding MPR for Y if it is indicated to participate in the flooding process of messages received from router Y, or it may be a routing MPR for Y if it is indicated to declare link state information for the link from X to Y. It may also be both at the same time.
多点中继（MPR）：路由器X是路由器Y的MPR，如果路由器Y在最近的HELLO消息中已将其选择的路由器X表示为MPR。如果指示路由器X参与从路由器Y接收的消息的泛洪过程，则它可以是Y的泛洪MPR，或者如果指示它声明从X到Y的链路的链路状态信息，则它可以是Y的路由MPR。它也可以同时是两者。
MPR selector: A router, Y, is a flooding/routing MPR selector of router X if router Y has selected router X as a flooding/routing MPR.
MPR选择器：如果路由器Y选择路由器X作为泛洪/路由MPR，则路由器Y是路由器X的泛洪/路由MPR选择器。
MPR flooding: The optimized MANET-wide information distribution mechanism, employed by this protocol, in which a message is relayed by only a reduced subset of the routers in the network. MPR flooding is the mechanism by which flooding reduction is achieved.
MPR泛洪：该协议采用的优化MANET范围内的信息分发机制，其中消息仅由网络中路由器的一个子集进行中继。MPR驱油是实现驱油减少的机制。
EXPIRED: Indicates that a timer is set to a value clearly preceding the current time (e.g., current time - 1).
过期：表示计时器设置为明显早于当前时间的值（例如，当前时间-1）。
This specification employs the same notational conventions as [RFC5444] and [RFC6130].
本规范采用与[RFC5444]和[RFC6130]相同的符号约定。
This document specifies OLSRv2, a proactive routing protocol intended for use in Mobile Ad Hoc Networks (MANETs) [RFC2501]. The protocol's applicability is determined by its characteristics, which are that this protocol:
本文件规定了OLSRv2，一种用于移动自组网（MANET）的主动式路由协议[RFC2501]。本协议的适用性由其特点决定，即本协议：
o Is designed to work in networks with a dynamic topology and in which messages may be lost, such as due to collisions over wireless media.
o 设计用于具有动态拓扑结构的网络中，在这种网络中，消息可能会丢失，例如由于无线媒体上的冲突。
o Supports routers that each have one or more participating OLSRv2 interfaces, which will consist of some or all of its MANET interfaces using [RFC6130]. The set of a router's OLSRv2 interfaces, and the sets of its other MANET and non-MANET interfaces, may change over time. Each interface may have one or more network addresses (which may have prefix lengths), and these may also be dynamically changing.
o 支持每个路由器都有一个或多个参与OLSRv2接口的路由器，该接口将使用[RFC6130]由其部分或全部MANET接口组成。路由器的OLSRv2接口集及其其他MANET和非MANET接口集可能随时间而变化。每个接口可能有一个或多个网络地址（可能有前缀长度），并且这些地址也可能动态变化。
o Enables hop-by-hop routing, i.e., each router can use its local information provided by this protocol to route packets.
o 启用逐跳路由，即每个路由器可以使用此协议提供的本地信息路由数据包。
o Continuously maintains routes to all destinations in the network, i.e., routes are instantly available and data traffic is subject to no delays due to route discovery. Consequently, no data traffic buffering is required.
o 持续维护到网络中所有目的地的路由，即路由立即可用，并且数据流量不会因路由发现而延迟。因此，不需要数据流量缓冲。
o Supports routers that have non-OLSRv2 interfaces that may be local to a router or that can serve as gateways towards other networks.
o 支持具有非OLSRv2接口的路由器，这些接口可能是路由器的本地接口，也可以用作通向其他网络的网关。
o Enables the use of bidirectional additive link metrics to use shortest distance routes (i.e., routes with smallest total of link metrics). Incoming link metric values are to be determined by a process outside this specification.
o 允许使用双向附加链路度量来使用最短距离路由（即链路度量总和最小的路由）。传入链路度量值将由本规范之外的流程确定。
o Is optimized for large and dense networks; the larger and more dense a network, the more optimization can be achieved by using MPRs, compared to the classic link state algorithm [MPR].
o 针对大型密集网络进行了优化；与经典的链路状态算法[MPR]相比，网络越大、越密集，使用MPR可以实现的优化就越多。
o Uses [RFC5444] as described in its "Intended Usage" appendix and by [RFC5498].
o 使用[RFC5444]，如其“预期用途”附录和[RFC5498]所述。
o Allows "external" and "internal" extensibility (adding new Message Types and adding information to existing messages) as enabled by [RFC5444].
o 允许[RFC5444]启用的“外部”和“内部”扩展性（添加新消息类型和向现有消息添加信息）。
o Is designed to work in a completely distributed manner and does not depend on any central entity.
o 设计为以完全分布式的方式工作，不依赖于任何中心实体。
The objectives of this protocol are for each router to:
本协议的目标是使每个路由器：
o Identify all destinations in the network.
o 识别网络中的所有目的地。
o Identify a sufficient subset of links in the network, in order that shortest routes can be calculated to all available destinations.
o 确定网络中足够多的链路子集，以便计算到所有可用目的地的最短路由。
o Provide a Routing Set containing these shortest routes from this router to all destinations (routable addresses and local links).
o 提供包含从该路由器到所有目的地（可路由地址和本地链接）的最短路由的路由集。
These objectives are achieved, for each router, by:
对于每个路由器，通过以下方式实现这些目标：
o Using NHDP [RFC6130] to identify symmetric 1-hop neighbors and symmetric 2-hop neighbors.
o 使用NHDP[RFC6130]识别对称1跳邻居和对称2跳邻居。
o Reporting its participation in OLSRv2, and its willingness to be a flooding MPR and to be a routing MPR, by extending the HELLO messages defined in [RFC6130] by the addition of an MPR_WILLING Message TLV. The router's "flooding willingness" indicates how willing it is to participate in MPR flooding. The router's "routing willingness" indicates how willing it is to be an intermediate router for routing. Note that a router is still able to be a routing source or destination, even if unwilling to perform either function.
o 通过添加MPR_意愿消息TLV扩展[RFC6130]中定义的HELLO消息，报告其参与OLSRv2，并愿意成为泛洪MPR和路由MPR。路由器的“泛洪意愿”表示其参与MPR泛洪的意愿。路由器的“路由意愿”表示它愿意成为路由的中间路由器的程度。请注意，即使不愿意执行这两种功能，路由器仍然可以作为路由源或目的地。
o Extending the HELLO messages defined in [RFC6130] to allow the addition of directional link metrics to advertised links with other routers participating in OLSRv2 and to indicate which link metric type is being used by those routers. Both incoming and outgoing link metrics may be reported, the former determined by the advertising router.
o 扩展[RFC6130]中定义的HELLO消息，以允许向与参与OLSRv2的其他路由器的播发链路添加定向链路度量，并指示这些路由器正在使用哪种链路度量类型。可以报告传入和传出链路度量，前者由广告路由器确定。
o Selecting flooding MPRs and routing MPRs from among its willing symmetric 1-hop neighbors such that, for each set of MPRs, all symmetric 2-hop neighbors are reachable either directly or via at least one selected MPR, using a path of appropriate minimum total metric for at least routing MPR selection. An analysis and examples of MPR selection algorithms are given in [MPR]; a suggested algorithm, appropriately adapted for each set of MPRs, is included in Appendix B of this specification. Note that it is not necessary for routers to use the same algorithm in order to interoperate in the same MANET, but each such algorithm must have the appropriate properties, described in Section 18.
o 从其愿意的对称1-hop邻居中选择泛洪MPR和路由MPR，使得对于每一组MPR，所有对称2-hop邻居都可以直接或通过至少一个选择的MPR到达，使用至少路由MPR选择的适当最小总度量的路径。[MPR]中给出了MPR选择算法的分析和示例；本规范附录B中包含了适用于每组MPR的建议算法。注意，为了在同一MANET中进行互操作，路由器不必使用相同的算法，但每个这样的算法必须具有第18节中描述的适当属性。
o Signaling its flooding MPR and routing MPR selections, by extending the HELLO messages defined in [RFC6130] to report this information by the addition of MPR Address Block TLV(s) associated with the appropriate network addresses.
o 通过添加与适当网络地址相关联的MPR地址块TLV，扩展[RFC6130]中定义的HELLO消息来报告该信息，从而向其泛洪MPR和路由MPR选择发送信号。
o Extracting its flooding MPR selectors and routing MPR selectors from received HELLO messages, using the included MPR Address Block TLV(s).
o 使用包含的MPR地址块TLV，从收到的HELLO消息中提取其泛洪MPR选择器和路由MPR选择器。
o Defining a TC (Topology Control) Message Type using the message format specified in [RFC5444]. TC messages are used to periodically signal links between routing MPR selectors and itself throughout the MANET. This signaling includes suitable directional neighbor metrics (the best link metric in that direction between those routers).
o 使用[RFC5444]中指定的消息格式定义TC（拓扑控制）消息类型。TC消息用于在整个MANET中周期性地向路由MPR选择器和自身之间的链路发送信号。该信令包括合适的定向邻居度量（这些路由器之间该方向的最佳链路度量）。
o Allowing its TC messages, as well as HELLO messages, to be included in packets specified in [RFC5444], using the "manet" IP protocol or UDP port as specified in [RFC5498].
o 使用[RFC5498]中指定的“manet”IP协议或UDP端口，允许其TC消息以及HELLO消息包含在[RFC5444]中指定的数据包中。
o Diffusing TC messages by using a flooding reduction mechanism, denoted "MPR flooding"; only the flooding MPRs of a router will retransmit messages received from (i.e., originated or last relayed by) that router.
o 通过使用泛洪减少机制传播TC消息，表示为“MPR泛洪”；只有路由器的泛洪MPR将重新传输从该路由器接收（即，由该路由器发起或最后中继）的消息。
Note that the indicated extensions to [RFC6130] are of forms permitted by that specification.
请注意，[RFC6130]的所示扩展是该规范允许的形式。
This specification defines:
本规范规定：
o The requirement to use [RFC6130], its parameters, constants, HELLO messages, and Information Bases, each as extended in this specification.
o 使用[RFC6130]及其参数、常量、HELLO消息和信息库的要求，每个都在本规范中进行了扩展。
o Two new Information Bases: the Topology Information Base and the Received Message Information Base.
o 两个新的信息库：拓扑信息库和接收消息信息库。
o TC messages, which are used for MANET wide signaling (using MPR flooding) of selected topology (link state) information.
o TC消息，用于所选拓扑（链路状态）信息的MANET范围信令（使用MPR泛洪）。
o A requirement for each router to have an originator address to be included in, or deducible from, HELLO messages and TC messages.
o 要求每个路由器在HELLO消息和TC消息中包含或可从中推断出发起者地址。
o The specification of new Message TLVs and Address Block TLVs that are used in HELLO messages and TC messages, including for reporting neighbor status, MPR selection, external gateways, link metrics, willingness to be an MPR, and content sequence numbers. Note that the generation of (incoming) link metric values is to be
o 在HELLO消息和TC消息中使用的新消息TLV和地址块TLV的规范，包括用于报告邻居状态、MPR选择、外部网关、链路度量、成为MPR的意愿以及内容序列号。注意，（传入）链路度量值的生成是
undertaken by a process outside this specification; this specification concerns only the distribution and use of those metrics.
由本规范以外的工艺进行；本规范仅涉及这些指标的分布和使用。
o The generation of TC messages from the appropriate information in the Information Bases.
o 从信息库中的适当信息生成TC消息。
o The updating of the Topology Information Base according to received TC messages.
o 根据接收到的TC消息更新拓扑信息库。
o The MPR flooding mechanism, including the inclusion of message originator address and sequence number to manage duplicate messages, using information recorded in the Received Message Information Base.
o MPR泛洪机制，包括使用接收到的消息信息库中记录的信息，包含消息发起人地址和序列号，以管理重复消息。
o The response to other events, such as the expiration of information in the Information Bases.
o 对其他事件的响应，例如信息库中的信息过期。
This 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.
该协议继承了链路状态算法的稳定性，并且由于其主动性，具有在需要时使路由立即可用的优点。
This protocol only interacts with IP through routing table management and the use of the sending IP address for IP datagrams containing messages used by this specification.
此协议仅通过路由表管理和使用包含本规范使用的消息的IP数据报的发送IP地址与IP进行交互。
In order for a router to participate in a MANET using this protocol, it must have at least one, and possibly more, OLSRv2 interfaces. Each OLSRv2 interface:
为了让路由器参与使用该协议的MANET，它必须至少有一个，甚至可能更多的OLSRv2接口。每个OLSRv2接口：
o Is a MANET interface, as specified in [RFC6130]. In particular, it must be configured with one or more network addresses; these addresses must each be specific to this router and must include any address that will be used as the sending address of any IP packet sent on this OLSRv2 interface.
o 是[RFC6130]中规定的MANET接口。特别是，它必须配置一个或多个网络地址；这些地址必须各自特定于此路由器，并且必须包括将用作此OLSRv2接口上发送的任何IP数据包的发送地址的任何地址。
o Has a number of interface parameters, adding to those specified in [RFC6130].
o 具有许多接口参数，添加到[RFC6130]中指定的参数。
o Has an Interface Information Base, extending that specified in [RFC6130].
o 具有接口信息库，扩展了[RFC6130]中指定的接口信息库。
o Generates and processes HELLO messages according to [RFC6130], extended as specified in Section 15.
o 根据[RFC6130]生成和处理HELLO消息，并按照第15节的规定进行扩展。
In addition to a set of OLSRv2 interfaces as described above, each router:
除如上所述的一组OLSRv2接口外，每个路由器：
o May have one or more non-OLSRv2 interfaces (which may include MANET interfaces and/or non-MANET interfaces) and/or local attached networks for which this router can accept IP packets. All routable addresses for which the router is to accept IP packets must be used as an (OLSRv2 or non-OLSRv2) interface network address or as an address of a local attached network of the router.
o 可能有一个或多个非OLSRv2接口（可能包括MANET接口和/或非MANET接口）和/或本地连接网络，该路由器可以接受IP数据包。路由器接受IP数据包的所有可路由地址必须用作（OLSRv2或非OLSRv2）接口网络地址或路由器本地连接网络的地址。
o Has a number of router parameters, adding to those specified in [RFC6130].
o 具有多个路由器参数，添加到[RFC6130]中指定的参数。
o Has a Local Information Base, extending that specified in [RFC6130], including selection of an originator address and recording any locally attached networks.
o 具有本地信息库，扩展了[RFC6130]中规定的信息库，包括选择发起者地址和记录任何本地连接的网络。
o Has a Neighbor Information Base, extending that specified in [RFC6130] to record MPR selection and advertisement information.
o 具有邻居信息库，扩展[RFC6130]中指定的信息库，以记录MPR选择和广告信息。
o Has a Topology Information Base, recording information received in TC messages.
o 具有拓扑信息库，记录TC消息中接收到的信息。
o Has a Received Message Information Base, recording information about received messages to ensure that each TC message is only processed once, and forwarded at most once on each OLSRv2 interface, by a router.
o 具有接收消息信息库，记录有关接收消息的信息，以确保每个TC消息仅由路由器处理一次，并在每个OLSRv2接口上最多转发一次。
o Generates, receives, and processes TC messages.
o 生成、接收和处理TC消息。
Each router maintains the Information Bases described in the following sections. These are used for describing the protocol in this specification. An implementation of this protocol may maintain this information in the indicated form or in any other organization that offers access to this information. In particular, note that it is not necessary to remove Tuples from Sets at the exact time indicated, only to behave as if the Tuples were removed at that time.
每个路由器维护以下部分中描述的信息库。这些用于描述本规范中的协议。本协议的实施可以以指定的形式或在提供访问该信息的任何其他组织中维护该信息。特别要注意的是，不必在指定的确切时间从集合中移除元组，只需表现为元组在该时间被移除。
The Local Information Base is specified in [RFC6130] and contains a router's local configuration. It is extended in this specification to also record an originator address and to include a router's:
本地信息库在[RFC6130]中指定，并包含路由器的本地配置。本规范对其进行了扩展，以记录发起者地址，并包括路由器的：
o Originator Set, containing addresses that were recently used as this router's originator address, that is used, together with the router's current originator address, to enable a router to recognize and discard control traffic that was originated by the router itself.
o 发起人集，包含最近用作此路由器发起人地址的地址，该地址与路由器的当前发起人地址一起使用，以使路由器能够识别和丢弃由路由器本身发起的控制流量。
o Local Attached Network Set, containing network addresses of networks to which this router can act as a gateway, that it advertises in its TC messages.
o 本地连接的网络集，包含此路由器可作为网关的网络的网络地址，它在其TC消息中播发。
The Interface Information Base for each OLSRv2 interface is as specified in [RFC6130], extended to also record, in each Link Set, link metric values (incoming and outgoing) and flooding MPR selector information.
每个OLSRv2接口的接口信息库如[RFC6130]所述，扩展后还可在每个链路集中记录链路度量值（传入和传出）和泛洪MPR选择器信息。
The Neighbor Information Base is specified in [RFC6130] and is extended to also record, in the Neighbor Tuple for each neighbor:
[RFC6130]中指定了邻居信息库，并将其扩展为在每个邻居的邻居元组中记录：
o Its originator address.
o 它的发起者地址。
o Neighbor metric values, these being the minimum of the link metric values in the indicated direction for all symmetric 1-hop links with that neighbor.
o 邻居度量值，这些是与该邻居的所有对称1跳链路在指示方向上的链路度量值的最小值。
o Its willingness to be a flooding MPR and to be a routing MPR.
o 它愿意成为泛洪MPR和路由MPR。
o Whether it has been selected by this router as a flooding MPR or as a routing MPR and whether it is a routing MPR selector of this router. (Whether it is a flooding MPR selector of this neighbor is recorded in the Interface Information Base.)
o 它是否已被此路由器选择为泛洪MPR或路由MPR，以及它是否是此路由器的路由MPR选择器。（是否为该邻居的泛洪MPR选择器记录在接口信息库中。）
o Whether it is to be advertised in TC messages sent by this router.
o 是否在该路由器发送的TC消息中公布。
The Topology Information Base in each router contains:
每个路由器中的拓扑信息库包含：
o An Advertising Remote Router Set, recording each remote router from which TC messages have been received. This is used in order to determine if a received TC message contains fresh or outdated information; a received TC message is ignored in the latter case.
o 广告远程路由器集，记录接收到TC消息的每个远程路由器。这用于确定接收到的TC消息是否包含新的或过时的信息；在后一种情况下，接收到的TC消息将被忽略。
o A Router Topology Set, recording links between routers in the MANET, as described by received TC messages.
o 路由器拓扑集，记录MANET中路由器之间的链路，如接收到的TC消息所述。
o A Routable Address Topology Set, recording routable addresses in the MANET (available as IP packet destinations) and from which remote router these routable addresses can be directly reached (i.e., in a single IP hop from that remote router), as reported by received TC messages.
o 一种可路由地址拓扑集，记录MANET中的可路由地址（可用作IP数据包目的地），从远程路由器可直接到达这些可路由地址（即，在来自该远程路由器的单个IP跃点中），如接收到的TC消息所述。
o An Attached Network Set, recording networks to which a remote router has advertised that it may act as a gateway. These networks may be reached in one or more IP hops from that remote router.
o 一种连接的网络集，记录远程路由器公布它可以充当网关的网络。这些网络可以通过一个或多个IP跃点从远程路由器到达。
o A Routing Set, recording routes from this router to all available destinations. The IP routing table is to be updated using this Routing Set. (A router may choose to use any or all destination network addresses in the Routing Set to update the IP routing table. This selection is outside the scope of this specification.)
o 一个路由集，记录从此路由器到所有可用目的地的路由。将使用此路由集更新IP路由表。（路由器可以选择使用路由集中的任何或所有目标网络地址来更新IP路由表。此选择不在本规范的范围内。）
The purpose of the Topology Information Base is to record information used, in addition to that in the Local Information Base, the Interface Information Bases, and the Neighbor Information Base, to construct the Routing Set (which is also included in the Topology Information Base).
拓扑信息库的目的是记录除本地信息库、接口信息库和邻居信息库中的信息外，用于构建路由集（也包括在拓扑信息库中）的信息。
This specification describes the calculation of the Routing Set based on a Topology Graph constructed in two phases. First, a "backbone" graph representing the routers in the MANET, and the connectivity between them, is constructed from the Local Information Base, the Neighbor Information Base, and the Router Topology Set. Second, this graph is "decorated" with additional destination network addresses using the Local Information Base, the Routable Address Topology Set, and the Attached Network Set.
本规范描述了基于分两个阶段构造的拓扑图的路由集计算。首先，从本地信息库、邻居信息库和路由器拓扑集构造一个“主干”图，表示MANET中的路由器以及它们之间的连接。其次，使用本地信息库、可路由地址拓扑集和连接的网络集，使用附加的目标网络地址对该图进行“修饰”。
The Topology Graph does not need to be recorded in the Topology Information Base; it can either be constructed as required when the Routing Set is to be changed or need not be explicitly constructed (as illustrated in Appendix C). An implementation may, however, construct and retain the Topology Graph if preferred.
拓扑图不需要记录在拓扑信息库中；当路由集要更改时，可以根据需要构造路由集，也可以不显式构造路由集（如附录C所示）。然而，如果首选，实现可以构造并保留拓扑图。
The Received Message Information Base in each router contains:
每个路由器中的接收消息信息库包含：
o A Received Set for each OLSRv2 interface, describing TC messages received by this router on that OLSRv2 interface.
o 每个OLSRv2接口的接收集，描述该路由器在该OLSRv2接口上接收的TC消息。
o A Processed Set, describing TC messages processed by this router.
o 已处理集，描述此路由器处理的TC消息。
o A Forwarded Set, describing TC messages forwarded by this router.
o 转发集，描述此路由器转发的TC消息。
The Received Message Information Base serves the MPR flooding mechanism by ensuring that received messages are forwarded at most once by a router and also ensures that received messages are processed exactly once by a router. The Received Message Information Base may also record information about other Message Types that use the MPR flooding mechanism.
接收到的消息信息库通过确保路由器最多转发一次接收到的消息来服务于MPR泛洪机制，并且还确保路由器只处理一次接收到的消息。接收到的消息信息库还可以记录关于使用MPR泛洪机制的其他消息类型的信息。
This protocol generates and processes HELLO messages according to [RFC6130]. HELLO messages transmitted on OLSRv2 interfaces are extended according to Section 15 of this specification to include an originator address, link metrics, and MPR selection information.
该协议根据[RFC6130]生成和处理HELLO消息。OLSRv2接口上传输的HELLO消息根据本规范第15节进行扩展，以包括发起者地址、链路度量和MPR选择信息。
This specification defines a single Message Type, the TC message. TC messages are sent by their originating router proactively, at a regular interval, on all OLSRv2 interfaces. This interval may be fixed or dynamic, for example, it may be backed off due to congestion or network stability. TC messages may also be sent as a response to a change in the router itself, or its advertised symmetric 1-hop neighborhood, for example, on first being selected as a routing MPR.
本规范定义了一种消息类型，即TC消息。TC消息由其原始路由器在所有OLSRv2接口上以固定间隔主动发送。该间隔可以是固定的或动态的，例如，由于拥塞或网络稳定性，它可能会被取消。TC消息还可以作为对路由器本身或其广告的对称1-hop邻域中的改变的响应而发送，例如，在第一次被选择为路由MPR时。
Because TC messages are sent periodically, this protocol is tolerant of unreliable transmissions of TC messages. Message losses may occur more frequently in wireless networks due to collisions or other transmission problems. This protocol may use "jitter", randomized adjustments to message transmission times, to reduce the incidence of collisions, as specified in [RFC5148].
由于TC消息是周期性发送的，因此该协议能够容忍TC消息的不可靠传输。在无线网络中，由于冲突或其他传输问题，消息丢失可能会更频繁地发生。根据[RFC5148]中的规定，该协议可以使用“抖动”，即对消息传输时间的随机调整，以减少冲突的发生。
This protocol is tolerant of out-of-sequence delivery of TC messages due to in-transit message reordering. Each router maintains an Advertised Neighbor Sequence Number (ANSN) that is incremented when its recorded neighbor information that is to be included in its TC messages changes. This ANSN is included in the router's TC messages. The recipient of a TC message can use this included ANSN to identify which of the information it has received is most recent, even if
该协议允许由于传输中的消息重新排序而导致TC消息的无序传递。每个路由器维护一个播发的邻居序列号（ANSN），该序列号在其TC消息中包含的记录的邻居信息发生变化时递增。此ANSN包含在路由器的TC消息中。TC消息的接收者可以使用这个包含的ANSN来识别它接收到的信息中哪一个是最新的，即使
messages have been reordered while in transit. Only the most recent information received is used; older information received later is discarded.
邮件在传输过程中已重新排序。仅使用收到的最新信息；以后收到的旧信息将被丢弃。
TC messages may be "complete" or "incomplete". A complete TC message advertises all of the originating router's routing MPR selectors; it may also advertise other symmetric 1-hop neighbors. Complete TC messages are generated periodically (and also, optionally, in response to symmetric 1-hop neighborhood changes). Incomplete TC messages may be used to report additions to advertised information, without repeating unchanged information.
TC消息可能是“完整”或“不完整”。完整的TC消息播发所有始发路由器的路由MPR选择器；它还可以宣传其他对称1跳邻居。周期性地生成完整的TC消息（并且，可选地，响应对称的1跳邻居更改）。不完整的TC消息可用于报告广告信息的添加，而不重复未更改的信息。
TC messages, and HELLO messages as extended by this specification, define (by inclusion or by deduction when having a single address) an originator address for the router that created the message. A TC message reports both the originator addresses and routable addresses of its advertised neighbors, distinguishing the two using an Address Block TLV (an address may be both routable and an originator address). TC messages also report the originator's locally attached networks.
TC消息，以及本规范扩展的HELLO消息，定义了创建消息的路由器的发起者地址（当具有单个地址时，通过包含或扣除）。TC消息报告其播发邻居的发端地址和可路由地址，并使用地址块TLV（地址可以是可路由的，也可以是发端地址）区分两者。TC消息还报告发端人的本地连接网络。
TC messages are MPR flooded throughout the MANET. A router retransmits a TC message received on an OLSRv2 interface if and only if the message did not originate at this router and has not been previously forwarded by this router, this is the first time the message has been received on this OLSRv2 interface, and the message is received from (i.e., originated from or was last relayed by) one of this router's flooding MPR selectors.
TC消息在整个MANET中被MPR淹没。路由器重新传输在OLSRv2接口上接收到的TC消息，如果且仅当该消息不是源于此路由器且之前未由此路由器转发时，这是在该OLSRv2接口上第一次接收到该消息，并且该消息是从（即，源于或最后由）接收到的此路由器的泛洪MPR选择器之一。
Some TC messages may be MPR flooded over only part of the network, e.g., allowing a router to ensure that nearer routers are kept more up to date than distant routers, such as is used in Fisheye State Routing [FSR] and Fuzzy Sighted Link State routing [FSLS]. This is enabled using [RFC5497].
一些TC消息可能仅在网络的一部分上被MPR淹没，例如，允许路由器确保较近的路由器比较远的路由器保持更新，例如在鱼眼状态路由[FSR]和模糊可视链路状态路由[FSLS]中使用的。这是使用[RFC5497]启用的。
TC messages include outgoing neighbor metrics that will be used in the selection of routes.
TC消息包括将在路由选择中使用的传出邻居度量。
OLSRv1 [RFC3626] created minimum hop routes to destinations. However, in many, if not most, circumstances, better routes (in terms of quality of service for end users) can be created by use of link metrics.
OLSRv1[RFC3626]创建了到目的地的最小跃点路由。然而，在许多（如果不是大多数的话）情况下，可以通过使用链路度量来创建更好的路由（就最终用户的服务质量而言）。
OLSRv2, as defined in this specification, supports metric-based routing, i.e., it allows links to each have a chosen metric. Link metrics as defined in OLSRv2 are additive, and the routes that are to be created are those with the minimum sum of the link metrics along that route.
本规范中定义的OLSRv2支持基于度量的路由，即，它允许到每个节点的链路都有一个选定的度量。OLSRv2中定义的链路度量是相加的，要创建的路由是沿该路由具有最小链路度量和的路由。
Link metrics are defined to be directional; the link metric from one router to another may be different from that on the reverse link. The link metric is assessed at the receiver, as on a (typically) wireless link, that is the better informed as to link information. Both incoming and outgoing link information is used by OLSRv2; the distinctions in this specification must be clearly followed.
链路度量被定义为定向的；从一个路由器到另一个路由器的链路度量可能不同于反向链路上的链路度量。链路度量在接收器处被评估，如在（通常）无线链路上，该无线链路对于链路信息是更好地被告知的。OLSRv2使用传入和传出链路信息；必须明确遵守本规范中的区别。
This specification also defines both incoming and outgoing neighbor metrics for each symmetric 1-hop neighbor, these being the minimum value of the link metrics in the same direction for all symmetric links with that neighbor. Note that this means that all neighbor metric values are link metric values and that specification of, for example, link metric value encoding also includes encoding of neighbor metric values.
该规范还定义了每个对称1跳邻居的传入和传出邻居度量，它们是与该邻居的所有对称链路在同一方向上的链路度量的最小值。注意，这意味着所有相邻度量值都是链路度量值，并且例如链路度量值编码的规范还包括相邻度量值的编码。
This specification does not define the nature of the link metric. However, this specification allows, through use of the type extension of a defined Address Block TLV, for link metrics with specific meanings to be defined and either allocated by IANA or privately used. Each HELLO or TC message carrying link (or neighbor) metrics thus indicates which link metric information it is carrying, allowing routers to determine if they can interoperate. If link metrics require additional signaling to determine their values, whether in HELLO messages or otherwise, then this is permitted but is outside the scope of this specification.
本规范未定义链路度量的性质。然而，通过使用已定义地址块TLV的类型扩展，本规范允许定义具有特定含义的链路度量，并由IANA分配或私人使用。因此，每个携带链路（或邻居）度量的HELLO或TC消息指示它携带的链路度量信息，从而允许路由器确定它们是否可以互操作。如果链路度量需要额外的信令来确定它们的值，无论是在HELLO消息中还是在其他情况下，那么这是允许的，但超出了本规范的范围。
Careful consideration should be given to how to use link metrics. In particular, it is advisable to not simply default to use of all links with equal metrics (i.e., hop count) for routing without careful consideration of whether that is appropriate or not.
应仔细考虑如何使用链接度量。特别是，建议不要简单地默认使用具有相同度量（即跳数）的所有链路进行路由，而不仔细考虑这是否合适。
This specification uses two sets of MPRs: flooding MPRs and routing MPRs. These are selected separately, because:
本规范使用两组MPR：泛洪MPR和路由MPR。这些是单独选择的，因为：
o Flooding MPRs may use metrics; routing MPRs must use metrics.
o 泛洪MPR可以使用度量；路由MPR必须使用度量。
o When flooding MPRs use metrics, these are outgoing link metrics; routing MPRs use incoming neighbor metrics.
o 当泛洪MPR使用度量时，这些是传出链路度量；路由MPR使用传入的邻居度量。
o Flooding MPRs must be selected per OLSRv2 interface; routing MPRs need not be selected per OLSRv2 interface.
o 必须根据OLSRv2接口选择泛洪MPR；无需根据OLSRv2接口选择路由MPR。
The purpose of the Routing Set is to determine and record routes (local interface network address and next-hop interface network address) to all possible routable addresses advertised by this protocol as well as all destinations that are local, i.e., within one hop, to the router (whether using routable addresses or not). Only symmetric links are used in such routes.
路由集的目的是确定和记录路由（本地接口网络地址和下一跳接口网络地址）到本协议公布的所有可能的可路由地址，以及到路由器（无论是否使用可路由地址）的所有本地目的地，即在一跳内。此类路由中仅使用对称链路。
It is intended that the Routing Set can be used for IP packet routing, by using its contents to update the IP routing table. That update, and whether any Routing Tuples are not used when updating the IP routing table, is outside the scope of this specification.
通过使用路由集的内容更新IP路由表，可以将路由集用于IP分组路由。该更新以及更新IP路由表时是否未使用任何路由元组不在本规范的范围内。
The signaling in this specification has been designed so that a "backbone" Topology Graph of routers, each identified by its originator address, with at most one direct connection between any pair of routers, can be constructed (from the Neighbor Set and the Router Topology Set) using a suitable minimum path length algorithm. This Topology Graph can then have other network addresses (routable or of symmetric 1-hop neighbors) added to it (using the Interface Information Bases, the Routable Address Topology Set, and the Attached Network Set).
本规范中的信令设计为，可以使用合适的最小路径长度算法（从邻居集和路由器拓扑集）构造路由器的“主干”拓扑图，每个路由器由其发起者地址标识，任何一对路由器之间最多有一个直接连接。然后，此拓扑图可以添加其他网络地址（可路由或对称1跳邻居的地址）（使用接口信息库、可路由地址拓扑集和连接的网络集）。
The parameters and constants used in this specification are those defined in [RFC6130] plus those defined in this section. The separation in [RFC6130] into interface parameters, router parameters, and constants is also used in this specification.
本规范中使用的参数和常数为[RFC6130]中定义的参数和常数加上本节中定义的参数和常数。[RFC6130]中的接口参数、路由器参数和常数分离也用于本规范中。
Similarly to the parameters in [RFC6130], parameters defined in this specification MAY be changed dynamically by a router and need not be the same on different routers, even in the same MANET, or, for interface parameters, on different interfaces of the same router.
与[RFC6130]中的参数类似，本规范中定义的参数可由路由器动态更改，并且在不同路由器上不必相同，即使在同一MANET中，或者对于接口参数，在同一路由器的不同接口上也不必相同。
This protocol specifies TC messages, which are included in packets as defined by [RFC5444]. These packets MUST be sent either using the "manet" protocol number or the "manet" UDP well-known port number, as specified in [RFC5498].
此协议指定TC消息，这些消息包含在[RFC5444]定义的数据包中。必须使用[RFC5498]中规定的“manet”协议号或“manet”UDP已知端口号发送这些数据包。
TC messages and HELLO messages [RFC6130] MUST, in a given MANET, either both use IP or both use UDP, in order for it to be possible to combine messages of both protocols into the same [RFC5444] packet for transmission.
TC消息和HELLO消息[RFC6130]必须在给定的MANET中同时使用IP或UDP，以便能够将两个协议的消息组合到同一个[RFC5444]数据包中进行传输。
This protocol specifies TC messages, which are included in packets as defined by [RFC5444]. These packets MAY be transmitted using the Link-Local multicast address "LL-MANET-Routers", as specified in [RFC5498].
此协议指定TC消息，这些消息包含在[RFC5444]定义的数据包中。这些数据包可以使用[RFC5498]中规定的链路本地多播地址“LL MANET路由器”进行传输。
A single additional interface parameter is specified for OLSRv2 interfaces only.
仅为OLSRv2接口指定了一个附加接口参数。
The following parameter manages the validity time of recorded received message information:
以下参数管理记录的接收消息信息的有效时间：
RX_HOLD_TIME: The period after receipt of a message by the appropriate OLSRv2 interface of this router for which that information is recorded, in order that the message is recognized as having been previously received on this OLSRv2 interface.
RX_HOLD_时间：该路由器的相应OLSRv2接口接收到消息后的一段时间，记录该信息，以便识别该消息之前已在此OLSRv2接口上收到。
The following constraints apply to this parameter:
以下约束适用于此参数：
o RX_HOLD_TIME > 0
o 接收保持时间>0
o RX_HOLD_TIME SHOULD be greater than the maximum difference in time that a message may take to traverse the MANET, taking into account any message forwarding jitter as well as propagation, queuing, and processing delays.
o 考虑到任何消息转发抖动以及传播、排队和处理延迟，RX_HOLD_TIME应大于消息穿越MANET所需的最大时间差。
The following router parameters are specified for routers.
为路由器指定以下路由器参数。
The following router parameter manages the time for which local information is retained:
以下路由器参数管理本地信息保留的时间：
O_HOLD_TIME: The time for which a recently used and replaced originator address is used to recognize the router's own messages.
O_HOLD_TIME：最近使用和替换的发起者地址用于识别路由器自身消息的时间。
The following constraint applies to this parameter:
以下约束适用于此参数：
o O_HOLD_TIME > 0
o O保持时间>0
All routes found using this specification use a single link metric type that is specified by the router parameter LINK_METRIC_TYPE, which may take any value from 0 to 255, both inclusive.
使用此规范找到的所有路由都使用由路由器参数link_metric_type指定的单个链路度量类型，该类型可以采用0到255（包括0和255）之间的任意值。
The following parameters regulate TC message transmissions by a router. TC messages are usually sent periodically but MAY also be sent in response to changes in the router's Neighbor Set and/or Local Attached Network Set. In a highly dynamic network, and with a larger value of the parameter TC_INTERVAL and a smaller value of the parameter TC_MIN_INTERVAL, TC messages MAY be transmitted more often in response to changes than periodically. However, because a router has no knowledge of, for example, routers remote to it (i.e., beyond two hops away) joining the network, TC messages MUST NOT be sent purely responsively.
以下参数调节路由器的TC消息传输。TC消息通常定期发送，但也可以响应路由器的邻居集和/或本地连接网络集的变化而发送。在高度动态的网络中，并且具有较大的参数TC_INTERVAL值和较小的参数TC_MIN_INTERVAL值，TC消息可以响应于变化而不是周期性地发送。然而，由于路由器不知道（例如）远程路由器（即，超过两个跃点）加入网络，因此不能纯粹响应地发送TC消息。
TC_INTERVAL: The maximum time between the transmission of two successive TC messages by this router. When no TC messages are sent in response to local network changes (by design or because the local network is not changing), then TC messages MUST be sent at a regular interval TC_INTERVAL, possibly modified by jitter, as specified in [RFC5148].
TC_间隔：此路由器传输两个连续TC消息之间的最长时间。当没有发送TC消息以响应本地网络变化时（通过设计或因为本地网络没有变化），则必须按照[RFC5148]中的规定，以常规间隔TC_间隔发送TC消息，可能通过抖动进行修改。
TC_MIN_INTERVAL: The minimum interval between transmission of two successive TC messages by this router. (This minimum interval MAY be modified by jitter, as specified in [RFC5148].)
TC_MIN_INTERVAL：此路由器传输两个连续TC消息之间的最小间隔。（该最小间隔可根据[RFC5148]中规定的抖动进行修改。）
The following constraints apply to these parameters:
以下约束适用于这些参数：
o TC_INTERVAL > 0
o TC_间隔>0
o 0 <= TC_MIN_INTERVAL <= TC_INTERVAL
o 0 <= TC_MIN_INTERVAL <= TC_INTERVAL
o If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are included in TC messages, then TC_INTERVAL MUST be representable by way of the exponent-mantissa notation described in Section 5 of [RFC5497].
o 如果TC消息中包含[RFC5497]中定义的类型为间隔时间的TLV，则TC间隔必须可通过[RFC5497]第5节中所述的指数尾数表示法表示。
The following parameters manage the validity time of information advertised in TC messages:
以下参数管理TC消息中公布的信息的有效时间：
T_HOLD_TIME: Used as the minimum value in the TLV with Type = VALIDITY_TIME included in all TC messages sent by this router. If a single value of parameter TC_HOP_LIMIT (see Section 5.4.7) is used, then this will be the only value in that TLV.
T_HOLD_TIME：用作TLV中的最小值，Type=VALIDITY_TIME包含在此路由器发送的所有TC消息中。如果使用参数TC_HOP_LIMIT（见第5.4.7节）的单个值，则这将是该TLV中的唯一值。
A_HOLD_TIME: The period during which TC messages are sent after they no longer have any advertised information to report but are sent in order to accelerate outdated information removal by other routers.
A_HOLD_TIME（等待时间）：TC消息不再有任何广告信息要报告，但被发送以加速其他路由器删除过时信息后发送的时间。
The following constraints apply to these parameters:
以下约束适用于这些参数：
o T_HOLD_TIME > 0
o 保持时间>0
o A_HOLD_TIME >= 0
o 保持时间>=0
o T_HOLD_TIME >= TC_INTERVAL
o T\u保持时间>=TC\u间隔
o If TC messages can be lost, then both T_HOLD_TIME and A_HOLD_TIME SHOULD be significantly greater than TC_INTERVAL; a value >= 3 x TC_INTERVAL is RECOMMENDED.
o 如果TC消息可能丢失，则T_保持时间和A_保持时间应明显大于TC_间隔；建议使用大于等于3 x TC_间隔的值。
o T_HOLD_TIME MUST be representable by way of the exponent-mantissa notation described in Section 5 of [RFC5497].
o T_保持时间必须通过[RFC5497]第5节中所述的指数尾数表示法表示。
The following parameters manage the processing and forwarding validity time of recorded message information:
以下参数管理记录的消息信息的处理和转发有效时间：
P_HOLD_TIME: The period after receipt of a message that is processed by this router for which that information is recorded, in order that the message is not processed again if received again.
P_HOLD_TIME（保存时间）：该路由器处理的消息接收后的一段时间，记录该信息，以便在再次接收时不再处理该消息。
F_HOLD_TIME: The period after receipt of a message that is forwarded by this router for which that information is recorded, in order that the message is not forwarded again if received again.
F_HOLD_TIME（保持时间）：接收到该路由器转发的消息后的一段时间，记录该信息，以便在再次收到消息时不再转发该消息。
The following constraints apply to these parameters:
以下约束适用于这些参数：
o P_HOLD_TIME > 0
o P_保持时间>0
o F_HOLD_TIME > 0
o F_保持时间>0
o Both of these parameters SHOULD be greater than the maximum difference in time that a message may take to traverse the MANET, taking into account any message forwarding jitter as well as propagation, queuing, and processing delays.
o 考虑到任何消息转发抖动以及传播、排队和处理延迟，这两个参数都应该大于消息在MANET中可能需要的最大时间差。
If jitter, as defined in [RFC5148], is used, then the governing jitter parameters are as follows:
如果使用[RFC5148]中定义的抖动，则控制抖动参数如下：
TP_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for periodically generated TC messages sent by this router.
TP_MAXJITTER：表示[RFC5148]中用于此路由器发送的周期性生成TC消息的MAXJITTER值。
TT_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for externally triggered TC messages sent by this router.
TT_MAXJITTER：表示[RFC5148]中用于此路由器发送的外部触发TC消息的MAXJITTER值。
F_MAXJITTER: Represents the default value of MAXJITTER used in [RFC5148] for messages forwarded by this router. However, before using F_MAXJITTER, a router MAY attempt to deduce a more appropriate value of MAXJITTER, for example, based on any TLVs with Type = INTERVAL_TIME or Type = VALIDITY_TIME contained in the message to be forwarded.
F_MAXJITTER：表示[RFC5148]中用于此路由器转发的消息的MAXJITTER的默认值。然而，在使用F_MAXJITTER之前，路由器可以尝试推断更合适的MAXJITTER值，例如，基于要转发的消息中包含的Type=INTERVAL_TIME或Type=VALIDITY_TIME的任何tlv。
For constraints on these parameters, see [RFC5148].
有关这些参数的约束，请参见[RFC5148]。
The parameter TC_HOP_LIMIT is the hop limit set in each TC message. TC_HOP_LIMIT MAY be a single fixed value or MAY be different in TC messages sent by the same router. However, each other router, at any hop count distance, MUST see a regular pattern of TC messages in order that meaningful values of TLVs with Type = INTERVAL_TIME and Type = VALIDITY_TIME at each hop count distance can be included as defined in [RFC5497]. Thus, the pattern of TC_HOP_LIMIT MUST be
参数TC_HOP_LIMIT是在每个TC消息中设置的跃点限制。TC_HOP_LIMIT可以是单个固定值，也可以是同一路由器发送的TC消息中的不同值。然而，在任何跳数距离上的每个其他路由器必须看到TC消息的规则模式，以便可以按照[RFC5497]中的定义包括每个跳数距离上类型=间隔时间且类型=有效性时间的TLV的有意义值。因此，TC_-HOP_限制的模式必须是
defined to have this property. For example, the repeating pattern (255 4 4) satisfies this property (having period TC_INTERVAL at hop counts up to 4, inclusive, and 3 x TC_INTERVAL at hop counts greater than 4), but the repeating pattern (255 255 4 4) does not satisfy this property because at hop counts greater than 4, message intervals are alternately TC_INTERVAL and 3 x TC_INTERVAL.
定义为具有此属性。例如，重复模式（255 4 4）满足此属性（跃点计数时的周期TC_间隔为4，包括4，跃点计数时的3 x TC_间隔大于4），但重复模式（255 255 4 4）不满足此属性，因为在跃点计数大于4，消息间隔交替为TC_间隔和3 x TC_间隔。
The following constraints apply to this parameter:
以下约束适用于此参数：
o The maximum value of TC_HOP_LIMIT >= the network diameter in hops; a value of 255 is RECOMMENDED. Note that if using a pattern of different values of TC_HOP_LIMIT as described above, then only the maximum value in the pattern is so constrained.
o TC_HOP_LIMIT>的最大值=网络直径（以跳数为单位）；建议值为255。请注意，如果如上所述使用TC_-HOP_-LIMIT的不同值的模式，则只有模式中的最大值受到约束。
o All values of TC_HOP_LIMIT >= 2.
o TC_-HOP_LIMIT的所有值>=2。
Each router has two willingness parameters: WILL_FLOODING and WILL_ROUTING, each of which MUST be in the range WILL_NEVER to WILL_ALWAYS, inclusive.
每个路由器都有两个意愿参数：WILL_FLOODING和WILL_ROUTING，每个参数都必须在WILL_NEVER到WILL_ALWAYS的范围内，包括这两个参数。
WILL_FLOODING represents the router's willingness to be selected as a flooding MPR and hence to participate in MPR flooding, in particular of TC messages.
WILL_泛洪表示路由器愿意被选择为泛洪MPR，从而参与MPR泛洪，尤其是TC消息。
WILL_ROUTING represents the router's willingness to be selected as a routing MPR and hence to be an intermediate router on routes.
WILL_ROUTING表示路由器愿意被选为路由MPR，从而成为路由上的中间路由器。
In either case, the higher the value, the greater the router's willingness to be a flooding or routing MPR, as appropriate. If a router has a willingness value of WILL_NEVER (the lowest possible value), it does not perform the corresponding task. A MANET using this protocol with too many routers having either of the willingness parameters WILL_FLOODING or WILL_ROUTING equal to WILL_NEVER will not function; it MUST be ensured, by administrative or other means, that this does not happen.
在这两种情况下，值越高，路由器越愿意成为泛洪或路由MPR（视情况而定）。如果路由器的意愿值为WILL_NEVER（最低可能值），则它不会执行相应的任务。使用此协议的MANET，如果有太多路由器具有任意一个意愿参数，则将\u泛洪或将\u路由等于将\u永远不会起作用；必须通过行政或其他手段确保这种情况不会发生。
Note that the proportion at which the routers having a willingness value equal to WILL_NEVER is "too many" depends on the network topology -- which, in a MANET, may change dynamically. Willingness is intended to enable that certain routers (e.g., routers that have generous resources, such as a permanent power supply) can be configured to assume more of the network operation, while others (e.g., routers that have lesser resources, such as are battery operated) can avoid such tasks. A general guideline would be that
请注意，意愿值等于WILL_的路由器所占的比例“太多”取决于网络拓扑结构——在MANET中，网络拓扑结构可能会动态变化。意愿旨在使某些路由器（例如，具有大量资源的路由器，例如永久电源）能够配置为承担更多的网络操作，而其他路由器（例如，具有较少资源的路由器，例如电池操作的路由器）能够避免此类任务。一般的指导方针是：
only if a router is not actually able to assume the task (flooding or routing) should it be configured with the corresponding willingness WILL_NEVER.
只有当路由器实际上无法承担任务（泛洪或路由）时，它才应该配置相应的意愿。
If a router has a willingness value equal to WILL_ALWAYS (the highest possible value), then it will always be selected as a flooding or routing MPR, as appropriate, by all symmetric 1-hop neighbors.
如果一个路由器的意愿值等于WILL_ALWAYS（可能的最高值），那么它将始终被所有对称1跳邻居选择为泛洪或路由MPR（视情况而定）。
In a MANET in which all routers have WILL_FLOODING = WILL_ALWAYS, flooding reduction will effectively be disabled, and flooding will perform as blind flooding.
在所有路由器都具有WILL_FLOODING=WILL_ALWAYS的MANET中，泛洪减少将被有效地禁用，并且泛洪将作为盲泛洪执行。
In a MANET in which all routers have WILL_ROUTING = WILL_ALWAYS, topology reduction will effectively be disabled, and all routers will advertise all of their links in TC messages.
在所有路由器都具有WILL_ROUTING=WILL_ALWAYS的MANET中，拓扑缩减将被有效禁用，并且所有路由器将在TC消息中公布其所有链路。
A router that has WILL_ROUTING = WILL_NEVER will not act as an intermediate router in the MANET. Such a router can act as a source, destination, or gateway to another routing domain.
具有WILL_ROUTING=WILL_NEVER的路由器不会充当MANET中的中间路由器。这样的路由器可以充当到另一个路由域的源、目的地或网关。
Different routers MAY have different values for WILL_FLOODING and/or WILL_ROUTING.
不同的路由器可能具有不同的WILL_泛洪和/或WILL_路由值。
The following constraints apply to these parameters:
以下约束适用于这些参数：
o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
o 永远不会
o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS
o 永远不会
If protocol parameters are changed dynamically, then the constraints in this section apply.
如果协议参数是动态更改的，则本节中的约束将适用。
RX_HOLD_TIME
接收保持时间
* If RX_HOLD_TIME for an OLSRv2 interface changes, then the expiry time for all Received Tuples for that OLSRv2 interface MAY be changed.
* 如果OLSRv2接口的RX_HOLD_时间更改，则该OLSRv2接口的所有接收元组的到期时间可能会更改。
O_HOLD_TIME
等一下
* If O_HOLD_TIME changes, then the expiry time for all Originator Tuples MAY be changed.
* 如果O_HOLD_时间更改，则可能会更改所有原始元组的到期时间。
TC_INTERVAL
TC_间期
* If TC_INTERVAL increases, then the next TC message generated by this router MUST be generated according to the previous, shorter TC_INTERVAL. Additional subsequent TC messages MAY be generated according to the previous, shorter, TC_INTERVAL.
* 如果TC_间隔增加，则此路由器生成的下一个TC消息必须根据上一个较短的TC_间隔生成。可根据先前较短的TC_间隔生成额外的后续TC消息。
* If TC_INTERVAL decreases, then the following TC messages from this router MUST be generated according to the current, shorter, TC_INTERVAL.
* 如果TC_间隔减小，则必须根据当前较短的TC_间隔生成来自此路由器的以下TC消息。
P_HOLD_TIME
P_保持时间
* If P_HOLD_TIME changes, then the expiry time for all Processed Tuples MAY be changed.
* 如果P_-HOLD_-TIME更改，则所有已处理元组的到期时间都可能更改。
F_HOLD_TIME
等一下
* If F_HOLD_TIME changes, then the expiry time for all Forwarded Tuples MAY be changed.
* 如果F_保持时间更改，则所有转发元组的到期时间可能会更改。
TP_MAXJITTER
最大抖动
* If TP_MAXJITTER changes, then the periodic TC message schedule on this router MAY be changed immediately.
* 如果TP_MAXJITTER发生变化，则该路由器上的定期TC消息调度可能会立即发生变化。
TT_MAXJITTER
TT_最大抖动
* If TT_MAXJITTER changes, then externally triggered TC messages on this router MAY be rescheduled.
* 如果TT_MAXJITTER发生变化，则此路由器上的外部触发TC消息可能会被重新调度。
F_MAXJITTER
F_最大抖动
* If F_MAXJITTER changes, then TC messages waiting to be forwarded with a delay based on this parameter MAY be rescheduled.
* 如果F_MAXJITTER发生变化，则等待转发的TC消息可能会根据此参数进行重新调度。
TC_HOP_LIMIT
TC_-HOP_极限
* If TC_HOP_LIMIT changes, and the router uses multiple values after the change, then message intervals and validity times included in TC messages MUST be respected. The simplest way to do this is to start any new repeating pattern of TC_HOP_LIMIT values with its largest value.
* 如果TC_HOP_LIMIT更改，并且路由器在更改后使用多个值，则必须遵守TC消息中包含的消息间隔和有效时间。做到这一点的最简单的方法是开始任何新的TC_-HOP_限制值的重复模式，并使用其最大值。
LINK_METRIC_TYPE
链接\度量\类型
* If LINK_METRIC_TYPE changes, then all link metric information recorded by the router is invalid. The router MUST take the following actions and all consequent actions described in Section 17 and [RFC6130].
* 如果链路度量类型更改，则路由器记录的所有链路度量信息无效。路由器必须采取以下行动以及第17节和[RFC6130]中所述的所有后续行动。
+ For each Link Tuple in any Link Set for an OLSRv2 interface, either update L_in_metric (the value MAXIMUM_METRIC MAY be used) or remove the Link Tuple from the Link Set.
+ 对于OLSRv2接口的任何链接集中的每个链接元组，更新L_in_度量（可以使用最大值度量）或从链接集中删除链接元组。
+ For each Link Tuple that is not removed, set:
+ 对于每个未删除的链接元组，设置：
- L_out_metric := UNKNOWN_METRIC;
- L_out_度量：=未知_度量；
- L_SYM_time := EXPIRED;
- L_SYM_时间：=过期；
- L_MPR_selector := false.
- L\u MPR\u选择器：=false。
+ Remove all Router Topology Tuples, Routable Address Topology Tuples, Attached Network Tuples, and Routing Tuples from their respective Protocol Sets in the Topology Information Base.
+ 从拓扑信息库中各自的协议集中删除所有路由器拓扑元组、可路由地址拓扑元组、连接的网络元组和路由元组。
The following constants are specified for routers. Unlike router parameters, constants MUST NOT change and MUST be the same on all routers.
为路由器指定以下常量。与路由器参数不同，常数不得更改，并且在所有路由器上必须相同。
The constant minimum and maximum link metric values are defined by:
恒定最小和最大链路度量值由以下公式定义：
o MINIMUM_METRIC := 1
o 最小度量：=1
o MAXIMUM_METRIC := 16776960
o 最大度量：=16776960
The symbolic value UNKNOWN_METRIC is defined in Section 6.1.
第6.1节定义了符号值未知_度量。
The constant minimum, RECOMMENDED default, and maximum willingness values are defined by:
恒定最小值、推荐默认值和最大意愿值由以下公式定义：
o WILL_NEVER := 0
o 永远不会：=0
o WILL_DEFAULT := 7
o 将默认值：=7
o WILL_ALWAYS := 15
o 将永远：=15
The constant C (time granularity) is used as specified in [RFC5497]. It MUST be the same as is used by [RFC6130], with RECOMMENDED value:
按照[RFC5497]中的规定使用常数C（时间粒度）。它必须与[RFC6130]使用的相同，建议值为：
o C := 1/1024 second
o C:=1/1024秒
Note that this constant is used in the representation of time intervals. Time values (such as are stored in Protocol Tuples) are not so represented. A resolution of C in such values is sufficient (but not necessary) for such values.
请注意，此常数用于表示时间间隔。时间值（例如存储在协议元组中的时间值）不是这样表示的。对于这些值，C在这些值中的分辨率是足够的（但不是必需的）。
A router records a link metric value for each direction of a link of which it has knowledge. These link metric values are used to create metrics for routes by the addition of link metric values.
路由器记录它所知道的链路的每个方向的链路度量值。这些链路度量值用于通过添加链路度量值为路由创建度量。
Link metrics are reported in messages using a compressed representation that occupies 12 bits, consisting of a 4-bit field and an 8-bit field. The compressed representation represents positive integer values with a minimum value of 1 and a maximum value that is slightly smaller than the maximum 24-bit value. Only those values that have exact representation in the compressed form are used. Route metrics are the summation of no more than 256 link metric values and can therefore be represented using no more than 32 bits.
链路度量使用占12位的压缩表示在消息中报告，该压缩表示由4位字段和8位字段组成。压缩表示法表示正整数值，最小值为1，最大值略小于最大24位值。仅使用压缩形式中具有精确表示形式的值。路由度量是不超过256个链路度量值的总和，因此可以使用不超过32位来表示。
Link and route metrics used in the Information Bases defined in this specification refer to the uncompressed values, and arithmetic involving them does likewise and assumes full precision in the result. (How an implementation records the values is not part of this specification, as long as it behaves as if recording uncompressed values. An implementation can, for example, use 32-bit values for all link and route metrics.)
本规范中定义的信息库中使用的链路和路由度量指的是未压缩的值，涉及这些值的算法也同样如此，并假设结果完全精确。（实现记录值的方式不属于本规范的一部分，只要其行为与记录未压缩的值类似。例如，实现可以对所有链路和路由度量使用32位值。）
In some cases, a link metric value may be unknown. This is indicated in this specification by the symbolic value UNKNOWN_METRIC. An implementation may use any representation of UNKNOWN_METRIC as it is never included in messages or used in any computation. (Possible representations are zero or any value greater than the maximum representable metric value.)
在某些情况下，链路度量值可能未知。这在本规范中由符号值未知度量表示。实现可以使用未知度量的任何表示，因为它从未包含在消息中或在任何计算中使用。（可能的表示为零或大于最大可表示度量值的任何值。）
The 12-bit compressed form of a link metric uses a modified form of a representation with an 8-bit mantissa (denoted a) and a 4-bit exponent (denoted b). Note that if represented as the 12-bit value 256b+a, then the ordering of those 12-bit values is identical to the ordering of the represented values.
链接度量的12位压缩形式使用修改后的表示形式，表示形式为8位尾数（表示a）和4位指数（表示b）。注意，如果表示为12位值256b+a，则这些12位值的顺序与表示的值的顺序相同。
The value so represented is (257+a)2^b - 256, where ^ denotes exponentiation. This has a minimum value (when a = 0 and b = 0) of MINIMUM_METRIC = 1 and a maximum value (when a = 255 and b = 15) of MAXIMUM_METRIC = 2^24 - 256.
这样表示的值是（257+a）2^b-256，其中^表示幂运算。它的最小值（当a=0和b=0时）为最小度量=1，最大值（当a=255和b=15时）为最大度量=2^24-256。
An algorithm for computing a and b for the smallest representable value not less than a link metric value v such that MINIMUM_METRIC <= v <= MAXIMUM_METRIC is:
一种算法，用于计算不小于链路度量值v的最小可表示值a和b，使得最小度量<=v<=最大度量为：
1. Find the smallest integer b such that v + 256 <= 2^(b + 9).
1. 求最小整数b，使v+256<=2^（b+9）。
2. Set a := (v - 256(2^b - 1)) / (2^b) - 1, rounded up to the nearest integer.
2. 设置a:=（v-256（2^b-1））/（2^b）-1，四舍五入到最接近的整数。
The Local Information Base, as defined for each router in [RFC6130], is extended by this protocol by:
[RFC6130]中为每个路由器定义的本地信息库通过以下协议扩展：
o Recording the router's originator address. The originator address MUST be unique to this router. It MUST NOT be used by any other router as an originator address. It MAY be included in any network address in any I_local_iface_addr_list of this router; it MUST NOT be included in any network address in any I_local_iface_addr_list of any other router. It MAY be included in, but MUST NOT be equal to, the AL_net_addr in any Local Attached Network Tuple in this or any other router.
o 记录路由器的发起者地址。发起者地址对此路由器必须是唯一的。任何其他路由器不得将其用作发端地址。它可以包含在该路由器的任何I_local_iface_addr_列表中的任何网络地址中；它不得包含在任何其他路由器的任何I_local_iface_addr_列表中的任何网络地址中。它可以包含在该路由器或任何其他路由器的任何本地连接网络元组中，但不得等于该元组中的AL_net_addr。
o The addition of an Originator Set, defined in Section 7.1, and a Local Attached Network Set, defined in Section 7.2.
o 添加第7.1节中定义的发起人集和第7.2节中定义的本地连接网络集。
All routable addresses of the router for which it is to accept IP packets as destination MUST be included in the Local Interface Set or the Local Attached Network Set.
接受IP数据包作为目的地的路由器的所有可路由地址必须包含在本地接口集或本地连接网络集中。
A router's Originator Set records addresses that were recently used as originator addresses by this router. If a router's originator address is immutable, then the Originator Set is always empty and MAY be omitted. It consists of Originator Tuples:
路由器的发起者设置记录最近被此路由器用作发起者地址的地址。如果路由器的发起者地址是不可变的，那么发起者集总是空的，可以省略。它由原始元组组成：
(O_orig_addr, O_time)
（原地址，原时间）
where:
哪里：
O_orig_addr is a recently used originator address; note that this does not include a prefix length.
O_orig_addr是最近使用的发起人地址；请注意，这不包括前缀长度。
O_time specifies the time at which this Tuple expires and MUST be removed.
O_time指定此元组过期且必须删除的时间。
A router's Local Attached Network Set records its local non-OLSRv2 interfaces via which it can act as a gateway to other networks. The Local Attached Network Set MUST be provided to this protocol and MUST reflect any changes in the router's status. (In cases where the router's configuration is static, the Local Attached Network Set will be constant; in cases where the router has no such non-OLSRv2 interfaces, the Local Attached Network Set will be empty.) The Local Attached Network Set is not modified by this protocol. This protocol will respond to (externally provided) changes to the Local Attached Network Set. It consists of Local Attached Network Tuples:
路由器的本地连接网络集记录其本地非OLSRv2接口，通过该接口它可以充当其他网络的网关。必须为此协议提供本地连接网络集，并且必须反映路由器状态的任何更改。（如果路由器的配置是静态的，则本地连接的网络集将保持不变；如果路由器没有此类非OLSRv2接口，则本地连接的网络集将为空。）本地连接的网络集不受此协议的修改。此协议将响应（外部提供的）本地连接网络集的更改。它由本地连接的网络元组组成：
(AL_net_addr, AL_dist, AL_metric)
（AL_净地址、AL_区、AL_公制）
where:
哪里：
AL_net_addr is the network address of an attached network that can be reached via this router. This SHOULD be a routable address. It is constrained as described below.
AL_net_addr是可通过此路由器访问的连接网络的网络地址。这应该是一个可路由的地址。如下所述对其进行约束。
AL_dist is the number of hops to the network with network address AL_net_addr from this router.
AL_dist是从该路由器到网络地址为AL_net_addr的网络的跳数。
AL_metric is the metric of the link to the attached network with address AL_net_addr from this router.
AL_metric是从该路由器连接到地址为AL_net_addr的连接网络的链路的度量。
Attached networks local to this router only (i.e., not reachable except via this router) SHOULD be treated as local non-MANET interfaces and added to the Local Interface Set, as specified in [RFC6130], rather than added to the Local Attached Network Set.
按照[RFC6130]中的规定，仅此路由器本地连接的网络（即，除通过此路由器外无法访问）应视为本地非MANET接口，并添加到本地接口集，而不是添加到本地连接的网络集。
Because an attached network is not specific to the router and may be outside the MANET, an attached network MAY also be attached to other routers. Routing to an AL_net_addr will use maximum prefix length matching; consequently, an AL_net_addr MAY include, but MUST NOT equal or be included in, any network address that is of any interface of any router (i.e., is included in any I_local_iface_addr_list) or equal any router's originator address.
因为连接的网络不是特定于路由器的，并且可能在MANET之外，所以连接的网络也可能连接到其他路由器。路由到AL_net_addr将使用最大前缀长度匹配；因此，AL_net_addr可包括但不得等于或包括在任何路由器的任何接口的任何网络地址（即，包括在任何i_local_iface_addr_列表中）或等于任何路由器的发起者地址。
It is not the responsibility of this protocol to maintain routes from this router to networks recorded in the Local Attached Network Set.
本协议不负责维护从该路由器到本地连接网络集中记录的网络的路由。
Local Attached Network Tuples are removed from the Local Attached Network Set only when the router's local attached network configuration changes, i.e., they are not subject to timer-based expiration or changes due to received messages.
仅当路由器的本地连接网络配置更改时，本地连接网络元组才会从本地连接网络集中删除，即，它们不会因接收到的消息而受到基于计时器的过期或更改的影响。
An Interface Information Base, as defined in [RFC6130], is maintained for each MANET interface. The Link Set and 2-Hop Set in the Interface Information Base for an OLSRv2 interface are modified by this protocol. In some cases, it may be convenient to consider these Sets as also containing these additional elements for other MANET interfaces, taking the indicated values on creation but never being updated.
为每个MANET接口维护[RFC6130]中定义的接口信息库。OLSRv2接口的接口信息库中的链路集和2跳集由该协议修改。在某些情况下，可以方便地将这些集合视为包含其他MANET接口的这些附加元素，在创建时使用所指示的值，但不被更新。
The Link Set is modified by adding these additional elements to each Link Tuple:
通过向每个链接元组添加以下附加元素来修改链接集：
L_in_metric is the metric of the link from the OLSRv2 interface with addresses L_neighbor_iface_addr_list to this OLSRv2 interface;
L_in_metric是从具有地址L_neighbor_iface_addr_列表的OLSRv2接口到该OLSRv2接口的链路的度量；
L_out_metric is the metric of the link to the OLSRv2 interface with addresses L_neighbor_iface_addr_list from this OLSRv2 interface;
L_out_metric是指向OLSRv2接口的链路的度量，地址为该OLSRv2接口的L_neighbor_iface_addr_列表；
L_mpr_selector is a boolean flag, describing if this neighbor has selected this router as a flooding MPR, i.e., is a flooding MPR selector of this router.
L_mpr_选择器是一个布尔标志，描述此邻居是否选择此路由器作为泛洪mpr，即，是此路由器的泛洪mpr选择器。
L_in_metric will be specified by a process that is external to this specification. Any Link Tuple with L_status = HEARD or L_status = SYMMETRIC MUST have a specified value of L_in_metric if it is to be used by this protocol.
L_in_度量将由本规范之外的流程指定。任何L_status=hear或L_status=SYMMETRIC的链接元组必须具有指定的L_in_metric值，才能由该协议使用。
A Link Tuple created (but not updated) by [RFC6130] MUST set:
[RFC6130]创建（但未更新）的链接元组必须设置：
o L_in_metric := UNKNOWN_METRIC;
o L_in_度量：=未知_度量；
o L_out_metric := UNKNOWN_METRIC;
o L_out_度量：=未知_度量；
o L_mpr_selector := false.
o L\u mpr\u选择器：=false。
The 2-Hop Set is modified by adding these additional elements to each 2-Hop Tuple:
通过向每个2-Hop元组添加以下附加元素来修改2-Hop集：
N2_in_metric is the neighbor metric from the router with address N2_2hop_iface_addr to the router with OLSRv2 interface addresses N2_neighbor_iface_addr_list;
N2_in_metric是从地址为N2_2hop_iface_addr的路由器到具有OLSRv2接口地址N2_neighbor_iface_addr_列表的路由器的邻居度量；
N2_out_metric is the neighbor metric to the router with address N2_2hop_iface_addr from the router with OLSRv2 interface addresses N2_neighbor_iface_addr_list.
N2_out_metric是从具有OLSRv2接口地址N2_neighbor_iface_addr的路由器到地址为N2_2; hop_iface_addr的路由器的邻居度量。
A 2-Hop Tuple created (but not updated) by [RFC6130] MUST set:
[RFC6130]创建（但未更新）的两跳元组必须设置：
o N2_in_metric := UNKNOWN_METRIC;
o N2_in_度量：=未知_度量；
o N2_out_metric := UNKNOWN_METRIC.
o N2_out_度量：=未知_度量。
A Neighbor Information Base, as defined in [RFC6130], is maintained for each router. It is modified by this protocol by adding these additional elements to each Neighbor Tuple in the Neighbor Set. In some cases, it may be convenient to consider these Sets as also containing these additional elements for other MANET interfaces, taking the indicated values on creation but never being updated.
为每个路由器维护[RFC6130]中定义的邻居信息库。该协议通过将这些附加元素添加到邻居集中的每个邻居元组来修改它。在某些情况下，可以方便地将这些集合视为包含其他MANET接口的这些附加元素，在创建时使用所指示的值，但不被更新。
N_orig_addr is the neighbor's originator address, which may be unknown. Note that this originator address does not include a prefix length;
N_orig_addr是邻居的发起者地址，可能未知。请注意，此发起者地址不包括前缀长度；
N_in_metric is the neighbor metric of any link from this neighbor to an OLSRv2 interface of this router, i.e., the minimum of all corresponding L_in_metric with L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no such Link Tuples;
N_in_metric是从该邻居到该路由器的OLSRv2接口的任何链路的邻居度量，即，L_status=对称且L_in_metric！=未知_度量，如果没有此类链接元组，则未知_度量；
N_out_metric is the neighbor metric of any link from an OLSRv2 interface of this router to this neighbor, i.e., the minimum of all corresponding L_out_metric with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no such Link Tuples;
N_out_metric是从该路由器的OLSRv2接口到该邻居的任何链路的邻居度量，即所有对应的L_out_度量的最小值，L_status=对称，L_out_metric！=未知_度量，如果没有此类链接元组，则未知_度量；
N_will_flooding is the neighbor's willingness to be selected as a flooding MPR, in the range from WILL_NEVER to WILL_ALWAYS, both inclusive, taking the value WILL_NEVER if no OLSRv2-specific information is received from this neighbor;
N_will_flooding是邻居愿意被选为泛洪MPR，范围从will_NEVER到will_ALWAYS，包括两者，如果没有从该邻居收到OLSRv2特定信息，则取will_NEVER的值；
N_will_routing is the neighbor's willingness to be selected as a routing MPR, in the range from WILL_NEVER to WILL_ALWAYS, both inclusive, taking the value WILL_NEVER if no OLSRv2-specific information is received from this neighbor;
N_will_routing是邻居愿意被选为路由MPR的意愿，范围从will_NEVER到will_ALWAYS，包括两者，如果没有从该邻居收到OLSRv2特定信息，则取will_NEVER的值；
N_flooding_mpr is a boolean flag, describing if this neighbor is selected as a flooding MPR by this router;
N_flooding_mpr是一个布尔标志，描述此路由器是否选择此邻居作为泛洪mpr；
N_routing_mpr is a boolean flag, describing if this neighbor is selected as a routing MPR by this router;
N_routing_mpr是一个布尔标志，描述该路由器是否选择该邻居作为路由mpr；
N_mpr_selector is a boolean flag, describing if this neighbor has selected this router as a routing MPR, i.e., is a routing MPR selector of this router.
N_mpr_选择器是一个布尔标志，描述此邻居是否选择此路由器作为路由mpr，即，是此路由器的路由mpr选择器。
N_advertised is a boolean flag, describing if this router has elected to advertise a link to this neighbor in its TC messages.
N_Adverted是一个布尔标志，描述此路由器是否选择在其TC消息中播发指向此邻居的链接。
A Neighbor Tuple created (but not updated) by [RFC6130] MUST set:
[RFC6130]创建（但未更新）的相邻元组必须设置：
o N_orig_addr := unknown;
o N_orig_addr:=未知；
o N_in_metric := UNKNOWN_METRIC;
o N_in_度量：=未知_度量；
o N_out_metric := UNKNOWN_METRIC;
o N_out_度量：=未知_度量；
o N_will_flooding := WILL_NEVER;
o N_will_泛洪：=永远不会；
o N_will_routing := WILL_NEVER;
o N\u will\u路由：=will\u NEVER；
o N_routing_mpr := false;
o N_routing_mpr:=假；
o N_flooding_mpr := false;
o N\u泛洪\u mpr:=假；
o N_mpr_selector := false;
o N\u mpr\u选择器：=假；
o N_advertised := false.
o N_广告：=假。
The Neighbor Information Base also includes a variable, the Advertised Neighbor Sequence Number (ANSN), whose value is included in TC messages to indicate the freshness of the information transmitted. The ANSN is incremented whenever advertised information (the originator and routable addresses included in Neighbor Tuples with N_advertised = true and local attached networks recorded in the Local Attached Network Set in the Local Information Base) changes, including addition or removal of such information.
邻居信息库还包括一个变量，广告邻居序列号（ANSN），其值包括在TC消息中，以指示所传输信息的新鲜度。每当播发信息（包含在邻居元组中的发起者和可路由地址，其中N_advised=true，本地连接网络记录在本地信息库中的本地连接网络集中）发生变化，包括添加或删除此类信息时，ANSN就会增加。
The Topology Information Base, defined for each router by this specification, stores information received in TC messages in the Advertising Remote Router Set, the Router Topology Set, the Routable Address Topology Set, and the Attached Network Set.
本规范为每个路由器定义的拓扑信息库将TC消息中接收的信息存储在广告远程路由器集、路由器拓扑集、可路由地址拓扑集和连接的网络集中。
Additionally, a Routing Set is maintained, derived from the information recorded in the Local Information Base, the Interface Information Bases, the Neighbor Information Base, and the rest of the Topology Information Base.
此外，维护路由集，该路由集源自本地信息库、接口信息库、邻居信息库和拓扑信息库的其余部分中记录的信息。
A router's Advertising Remote Router Set records information describing each remote router in the network that transmits TC messages, allowing outdated TC messages to be recognized and discarded. It consists of Advertising Remote Router Tuples:
路由器的广告远程路由器集记录描述网络中传输TC消息的每个远程路由器的信息，允许识别和丢弃过时的TC消息。它由远程路由器元组组成：
(AR_orig_addr, AR_seq_number, AR_time)
（应收账款原始地址、应收账款序号、应收账款时间）
where:
哪里：
AR_orig_addr is the originator address of a received TC message, note that this does not include a prefix length;
AR_orig_addr是接收到的TC消息的发起者地址，请注意，这不包括前缀长度；
AR_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address AR_orig_addr (i.e., that contributed to the information contained in this Tuple);
AR_seq_number是从发起者地址为AR_orig_addr的路由器接收到的任何TC消息中最大的ANSN（即，对该元组中包含的信息作出贡献的ANSN）；
AR_time is the time at which this Tuple expires and MUST be removed.
AR_time是此元组过期且必须删除的时间。
A router's Topology Set records topology information about the links between routers in the MANET. It consists of Router Topology Tuples:
路由器的拓扑集记录MANET中路由器之间链路的拓扑信息。它由路由器拓扑元组组成：
(TR_from_orig_addr, TR_to_orig_addr, TR_seq_number, TR_metric, TR_time)
（TR_from_orig_addr，TR_to_orig_addr，TR_seq_number，TR_metric，TR_time）
where:
哪里：
TR_from_orig_addr is the originator address of a router that can reach the router with originator address TR_to_orig_addr in one hop (note that this does not include a prefix length);
TR_from_orig_addr是路由器的发起者地址，可以在一个跃点内到达发起者地址为TR_to_orig_addr的路由器（注意，这不包括前缀长度）；
TR_to_orig_addr is the originator address of a router that can be reached by the router with originator address TR_from_orig_addr in one hop (note that this does not include a prefix length);
TR_to_orig_addr是路由器的发端地址，发端地址TR_from_orig_addr的路由器可以在一个跃点内到达该发端地址（注意，这不包括前缀长度）；
TR_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address TR_from_orig_addr (i.e., that contributed to the information contained in this Tuple);
TR_seq_number是从路由器接收到的任何TC消息中最大的ANSN，其发端地址为TR_from_orig_addr（即，对该元组中包含的信息作出贡献）；
TR_metric is the neighbor metric from the router with originator address TR_from_orig_addr to the router with originator address TR_to_orig_addr;
TR_metric是从发端地址为TR_from_orig_addr的路由器到发端地址为TR_to_orig_addr的路由器的邻居度量；
TR_time specifies the time at which this Tuple expires and MUST be removed.
TR_time指定此元组过期且必须删除的时间。
A router's Routable Address Topology Set records topology information about the routable addresses within the MANET, including via which routers they may be reached. It consists of Routable Address Topology Tuples:
路由器的可路由地址拓扑集记录有关MANET内可路由地址的拓扑信息，包括可通过哪些路由器访问这些地址。它由可路由地址拓扑元组组成：
(TA_from_orig_addr, TA_dest_addr, TA_seq_number, TA_metric, TA_time)
（原始地址、目的地址、序号、度量、时间）
where:
哪里：
TA_from_orig_addr is the originator address of a router that can reach the router with routable address TA_dest_addr in one hop (note that this does not include a prefix length);
TA_from_orig_addr是路由器的发起者地址，可在一个跃点内通过可路由地址TA_dest_addr到达路由器（注意，这不包括前缀长度）；
TA_dest_addr is a routable address of a router that can be reached by the router with originator address TA_from_orig_addr in one hop;
TA_dest_addr是路由器的一个可路由地址，路由器可以在一个跃点内通过原始地址TA_从_orig_addr到达该地址；
TA_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address TA_from_orig_addr (i.e., that contributed to the information contained in this Tuple);
TA_seq_number是从路由器收到的任何TC消息中最大的ANSN，其发起者地址为TA_from_orig_addr（即，对该元组中包含的信息作出贡献）；
TA_metric is the neighbor metric from the router with originator address TA_from_orig_addr to the router with OLSRv2 interface address TA_dest_addr;
TA_metric是从具有发端地址TA_from_orig_addr的路由器到具有OLSRv2接口地址TA_dest_addr的路由器的邻居度量；
TA_time specifies the time at which this Tuple expires and MUST be removed.
TA_time指定此元组过期且必须删除的时间。
A router's Attached Network Set records information about networks (which may be outside the MANET) attached to other routers and their routable addresses. It consists of Attached Network Tuples:
路由器的连接网络集记录连接到其他路由器的网络（可能在MANET之外）及其可路由地址的信息。它由附加的网络元组组成：
(AN_orig_addr, AN_net_addr, AN_seq_number, AN_dist, AN_metric, AN_time)
（原始地址、净地址、序号、距离、度量、时间）
where:
哪里：
AN_orig_addr is the originator address of a router that can act as gateway to the network with network address AN_net_addr (note that this does not include a prefix length);
a_orig_addr是路由器的发起者地址，它可以作为网络地址为a_net_addr的网络网关（注意，这不包括前缀长度）；
AN_net_addr is the network address of an attached network that may be reached via the router with originator address AN_orig_addr;
a_net_addr是连接网络的网络地址，可通过具有原始地址a_orig_addr的路由器访问该网络；
AN_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address AN_orig_addr (i.e., that contributed to the information contained in this Tuple);
_seq_number是从发起者地址为_orig_addr的路由器接收到的任何TC消息中最大的ANSN（即，对该元组中包含的信息作出贡献的ANSN）；
AN_dist is the number of hops to the network with network address AN_net_addr from the router with originator address AN_orig_addr;
AN_dist是从具有发起者地址AN_orig_addr的路由器到具有网络地址AN_net_addr的网络的跳数；
AN_metric is the metric of the link from the router with originator address AN_orig_addr to the attached network with address AN_net_addr;
_度量是从发端地址为_orig_addr的路由器到地址为_net_addr的连接网络的链路的度量；
AN_time specifies the time at which this Tuple expires and MUST be removed.
_time指定此元组过期且必须删除的时间。
A router's Routing Set records the first hop along a selected path to each destination for which any such path is known. It consists of Routing Tuples:
路由器的路由集记录沿选定路径到已知任何此类路径的每个目的地的第一跳。它由路由元组组成：
(R_dest_addr, R_next_iface_addr, R_local_iface_addr, R_dist, R_metric)
（地址、下一个地址、本地地址、距离、度量）
where:
哪里：
R_dest_addr is the network address of the destination, either the network address of an interface of a destination router or the network address of an attached network;
R_dest_addr是目的地的网络地址，目的地路由器接口的网络地址或连接网络的网络地址；
R_next_iface_addr is the network address of the "next hop" on the selected path to the destination;
R_next_iface_addr是指向目的地的选定路径上的“下一跳”的网络地址；
R_local_iface_addr is an address of the local interface over which an IP packet MUST be sent to reach the destination by the selected path.
R_local_iface_addr是本地接口的地址，必须通过该地址发送IP数据包才能通过所选路径到达目的地。
R_dist is the number of hops on the selected path to the destination;
R_dist是指向目的地的选定路径上的跳数；
R_metric is the metric of the route to the destination with address R_dest_addr.
R_metric是到地址为R_dest_addr的目的地的路由的度量。
The Routing Set for a router is derived from the contents of other Protocol Sets of the router (the Link Sets, the Neighbor Set, the Router Topology Set, the Routable Address Topology Set, the Attached Network Set, and OPTIONAL use of the 2-Hop Sets). The Routing Set is updated (Routing Tuples added or removed, or the complete Routing Set recalculated) when routing paths are calculated, based on changes to these other Protocol Sets. Routing Tuples are not subject to timer-based expiration.
路由器的路由集源自路由器的其他协议集的内容（链路集、邻居集、路由器拓扑集、可路由地址拓扑集、连接的网络集以及2跳集的可选使用）。当根据对这些其他协议集的更改计算路由路径时，将更新路由集（添加或删除路由元组，或重新计算整个路由集）。路由元组不受基于计时器的过期限制。
The Received Message Information Base, defined by this specification, records information required to ensure that a message is processed at most once and is forwarded at most once per OLSRv2 interface of a router, using MPR flooding. Messages are recorded using their "signature", consisting of their type, originator address, and message sequence number.
本规范定义的接收消息信息库记录了确保消息最多处理一次所需的信息，并使用MPR泛洪，在路由器的每个OLSRv2接口上最多转发一次。使用“签名”记录消息，签名包括消息类型、发起者地址和消息序列号。
A router has a Received Set per OLSRv2 interface. Each Received Set records the signatures of messages that have been received over that OLSRv2 interface. Each consists of Received Tuples:
路由器具有每个OLSRv2接口的接收集。每个接收集记录通过OLSRv2接口接收的消息的签名。每个由接收到的元组组成：
(RX_type, RX_orig_addr, RX_seq_number, RX_time)
（接收类型、接收起始地址、接收序号、接收时间）
where:
哪里：
RX_type is the received Message Type;
RX_type是接收到的消息类型；
RX_orig_addr is the originator address of the received message (note that this does not include a prefix length);
RX_orig_addr是接收到的消息的发起者地址（注意，这不包括前缀长度）；
RX_seq_number is the message sequence number of the received message;
RX_seq_number是接收到的消息的消息序列号；
RX_time specifies the time at which this Tuple expires and MUST be removed.
RX_time指定此元组过期且必须删除的时间。
A router has a single Processed Set that records signatures of messages that have been processed by the router. It consists of Processed Tuples:
路由器有一个单独的处理集，用于记录已由路由器处理的消息的签名。它由经过处理的元组组成：
(P_type, P_orig_addr, P_seq_number, P_time)
（P_类型、P_原始地址、P_序号、P_时间）
where:
哪里：
P_type is the processed Message Type;
P_type为已处理的消息类型；
P_orig_addr is the originator address of the processed message (note that this does not include a prefix length);
P_orig_addr是已处理邮件的发起者地址（注意，这不包括前缀长度）；
P_seq_number is the message sequence number of the processed message;
P_seq_number为已处理报文的报文序列号；
P_time specifies the time at which this Tuple expires and MUST be removed.
P_time指定此元组过期且必须删除的时间。
A router has a single Forwarded Set that records signatures of messages that have been forwarded by the router. It consists of Forwarded Tuples:
路由器有一个转发集，记录路由器转发的消息的签名。它由转发的元组组成：
(F_type, F_orig_addr, F_seq_number, F_time)
（F_类型、F_原始地址、F_序号、F_时间）
where:
哪里：
F_type is the forwarded Message Type;
F_type是转发的消息类型；
F_orig_addr is the originator address of the forwarded message (note that this does not include a prefix length);
F_orig_addr是转发消息的发起者地址（注意，这不包括前缀长度）；
F_seq_number is the message sequence number of the forwarded message;
F_seq_number为转发报文的报文序列号；
F_time specifies the time at which this Tuple expires and MUST be removed.
F_time指定此元组过期且必须删除的时间。
This section describes some additional properties of Information Bases and their contents.
本节介绍信息库及其内容的一些附加属性。
As part of this specification, in a number of cases, there is a natural correspondence from a Protocol Tuple in one Protocol Set to a single Protocol Tuple in another Protocol Set, in the same or another Information Base. The latter Protocol Tuple is referred to as "corresponding" to the former Protocol Tuple.
作为本规范的一部分，在许多情况下，在相同或另一信息库中，从一个协议集中的协议元组到另一个协议集中的单个协议元组存在自然对应关系。后一个协议元组被称为“对应于”前一个协议元组。
Specific examples of corresponding Protocol Tuples include:
相应协议元组的具体示例包括：
o There is a Local Interface Tuple corresponding to each Link Tuple, where the Link Tuple is in the Link Set for a MANET interface and the Local Interface Tuple represents that MANET interface.
o 每个链路元组对应一个本地接口元组，其中链路元组位于MANET接口的链路集中，本地接口元组表示该MANET接口。
o There is a Neighbor Tuple corresponding to each Link Tuple that has L_HEARD_time not EXPIRED, such that N_neighbor_addr_list contains L_neighbor_iface_addr_list.
o 有一个邻居元组对应于L_hear_time未过期的每个链接元组，这样N_Neighbor_addr_list包含L_Neighbor_iface_addr_list。
o There is a Link Tuple (in the Link Set in the same Interface Information Base) corresponding to each 2-Hop Tuple such that L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.
o 有一个链接元组（在同一接口信息库中的链接集中）对应于每个2跳元组，这样L_neighbor_iface_addr_list=N2_neighbor_iface_addr_list。
o There is a Neighbor Tuple corresponding to each 2-Hop Tuple, such that N_neighbor_addr_list contains N2_neighbor_iface_addr_list. (This is the Neighbor Tuple corresponding to the Link Tuple corresponding to the 2-Hop Tuple.)
o 每个2跳元组对应一个邻居元组，这样N_Neighbor_addr_列表包含N2_Neighbor_iface_addr_列表。（这是对应于2跳元组的链接元组的邻居元组。）
o There is an Advertising Remote Router Tuple corresponding to each Router Topology Tuple such that AR_orig_addr = TR_from_orig_addr.
o 有一个广告远程路由器元组对应于每个路由器拓扑元组，这样AR_orig_addr=TR_from_orig_addr。
o There is an Advertising Remote Router Tuple corresponding to each Routable Address Topology Tuple such that AR_orig_addr = TA_from_orig_addr.
o 有一个广告远程路由器元组对应于每个可路由地址拓扑元组，这样AR_orig_addr=TA_from_orig_addr。
o There is an Advertising Remote Router Tuple corresponding to each Attached Network Tuple such that AR_orig_addr = AN_orig_addr.
o 存在对应于每个连接的网络元组的广告远程路由器元组，使得AR_orig_addr=an_orig_addr。
o There is a Neighbor Tuple corresponding to each Routing Tuple such that N_neighbor_addr_list contains R_next_iface_addr.
o 每个路由元组对应一个邻居元组，使得N_nexter_addr_列表包含R_next_iface_addr。
Addresses or network addresses with the following properties are considered as "fully owned" by a router when processing a received message:
在处理接收到的消息时，具有以下属性的地址或网络地址被视为路由器“完全拥有”：
o Equaling its originator address; OR
o 等于其发起人地址；或
o Equaling the O_orig_addr in an Originator Tuple; OR
o 等于原始元组中的O_orig_addr；或
o Equaling or being a sub-range of the I_local_iface_addr_list in a Local Interface Tuple; OR
o 等于或是本地接口元组中I_local_iface_addr_列表的子范围；或
o Equaling or being a sub-range of the IR_local_iface_addr in a Removed Interface Address Tuple; OR
o 等于或是已移除接口地址元组中的IR_local_iface_addr的子范围；或
o Equaling an AL_net_addr in a Local Attached Network Tuple.
o 等于本地连接网络元组中的AL_net_addr。
Addresses or network addresses with the following properties are considered as "partially owned" (which may include being fully owned) by a router when processing a received message:
在处理接收到的消息时，具有以下属性的地址或网络地址被视为路由器“部分拥有”（可能包括完全拥有）：
o Overlapping (equaling or containing) its originator address; OR
o 重叠（等于或包含）其发起人地址；或
o Overlapping (equaling or containing) the O_orig_addr in an Originator Tuple; OR
o 重叠（等于或包含）原始元组中的O_orig_addr；或
o Overlapping the I_local_iface_addr_list in a Local Interface Tuple; OR
o 在本地接口元组中重叠I_local_iface_addr_列表；或
o Overlapping the IR_local_iface_addr in a Removed Interface Address Tuple; OR
o 在移除的接口地址元组中重叠IR_local_iface_addr；或
o Equaling or having as a sub-range an AL_net_addr in a Local Attached Network Tuple.
o 等于或具有本地连接网络元组中的AL_net_addr作为子范围。
The packet and message format used by this protocol is defined in [RFC5444]. Except as otherwise noted, options defined in [RFC5444] may be freely used, in particular alternative formats defined by packet, message, Address Block, and TLV flags.
[RFC5444]中定义了本协议使用的数据包和消息格式。除非另有说明，[RFC5444]中定义的选项可以自由使用，特别是由数据包、消息、地址块和TLV标志定义的替代格式。
This section describes the usage of the packets and messages defined in [RFC5444] by this specification and the TLVs defined by, and used in, this specification.
本节描述了本规范[RFC5444]中定义的数据包和消息以及本规范中定义和使用的TLV的用法。
Routers using this protocol exchange information through messages. The Message Types used by this protocol are the HELLO message and the TC message. The HELLO message is defined by [RFC6130] and extended by this specification (see Section 15). The TC message is defined by this specification (see Section 16).
使用此协议的路由器通过消息交换信息。此协议使用的消息类型为HELLO消息和TC消息。HELLO消息由[RFC6130]定义，并由本规范扩展（见第15节）。TC信息由本规范定义（见第16节）。
One or more messages sent by a router at the same time SHOULD be combined into a single packet, subject to any constraints on maximum packet size (such as derived from the MTU over a local single hop) that MAY be imposed. These messages may have originated at the sending router or at another router and are being forwarded by the sending router. Messages with different originating routers MAY be combined for transmission within the same packet. Messages from other protocols defined using [RFC5444], including but not limited to NHDP [RFC6130], MAY be combined for transmission within the same packet. This specification does not define or use any contents of the Packet Header.
路由器同时发送的一个或多个消息应组合成单个分组，并受可能施加的最大分组大小（例如从本地单跳上的MTU导出）的任何约束。这些消息可能起源于发送路由器或其他路由器，并由发送路由器转发。具有不同始发路由器的消息可被组合以在同一分组内传输。来自使用[RFC5444]定义的其他协议（包括但不限于NHDP[RFC6130]）的消息可以组合在同一分组内进行传输。本规范不定义或使用数据包头的任何内容。
Forwarded messages MAY be jittered as described in [RFC5148], including the observation that the forwarding jitter of all messages received in a single packet SHOULD be the same. The value of MAXJITTER used in jittering a forwarded message MAY be based on information in that message (in particular any Message TLVs with Type = INTERVAL_TIME or Type = VALIDITY_TIME) or otherwise SHOULD be with a maximum delay of F_MAXJITTER. A router MAY modify the jitter applied to a message in order to more efficiently combine messages in packets, as long as the maximum jitter is not exceeded.
转发的消息可以如[RFC5148]中所述进行抖动，包括观察到在单个分组中接收的所有消息的转发抖动应该相同。在抖动转发消息时使用的MAXJITTER值可以基于该消息中的信息（特别是类型=间隔时间或类型=有效性时间的任何消息TLV），或者应该具有F_MAXJITTER的最大延迟。路由器可以修改应用于消息的抖动，以便在分组中更有效地组合消息，只要不超过最大抖动。
This specification defines two Message TLVs and four Address Block TLVs.
本规范定义了两个消息TLV和四个地址块TLV。
All references in this specification to TLVs that do not indicate a type extension assume Type Extension = 0. TLVs in processed messages with a type extension that is neither zero as so assumed, nor a specifically indicated non-zero type extension, are ignored.
本规范中所有对未指示类型扩展的TLV的引用均假定类型扩展=0。已处理消息中的TLV类型扩展既不是假定的零，也不是专门指定的非零类型扩展，将被忽略。
Note that, following [RFC5444] and network byte order, bits in an octet are numbered from 0 (most significant) to 7 (least significant).
注意，在[RFC5444]和网络字节顺序之后，八位字节中的位从0（最高有效）到7（最低有效）进行编号。
The MPR_WILLING TLV is used in HELLO messages. A message MUST NOT contain more than one MPR_WILLING TLV.
MPR\u TLV用于HELLO消息中。一条消息不能包含多个MPR\U TLV。
+-------------+--------------+--------------------------------------+
| Type | Value Length | Value |
+-------------+--------------+--------------------------------------+
| MPR_WILLING | 1 octet | Bits 0-3 encode the parameter |
| | | WILL_FLOODING; bits 4-7 encode the |
| | | parameter WILL_ROUTING. |
+-------------+--------------+--------------------------------------+
+-------------+--------------+--------------------------------------+
| Type | Value Length | Value |
+-------------+--------------+--------------------------------------+
| MPR_WILLING | 1 octet | Bits 0-3 encode the parameter |
| | | WILL_FLOODING; bits 4-7 encode the |
| | | parameter WILL_ROUTING. |
+-------------+--------------+--------------------------------------+
Table 1: MPR_WILLING TLV Definition
表1:MPR\U TLV定义
The CONT_SEQ_NUM TLV is used in TC messages. A message MUST NOT contain more than one CONT_SEQ_NUM TLV.
CONT_SEQ_NUM TLV用于TC消息中。一条消息不能包含多个CONT_SEQ_NUM TLV。
+--------------+--------------+-------------------------------------+
| Type | Value Length | Value |
+--------------+--------------+-------------------------------------+
| CONT_SEQ_NUM | 2 octets | The ANSN contained in the Neighbor |
| | | Information Base. |
+--------------+--------------+-------------------------------------+
+--------------+--------------+-------------------------------------+
| Type | Value Length | Value |
+--------------+--------------+-------------------------------------+
| CONT_SEQ_NUM | 2 octets | The ANSN contained in the Neighbor |
| | | Information Base. |
+--------------+--------------+-------------------------------------+
Table 2: CONT_SEQ_NUM TLV Definition
表2：CONT_SEQ_NUM TLV定义
The LINK_METRIC TLV is used in HELLO messages and TC messages. It MAY use any type extension; only LINK_METRIC TLVs with type extension equal to LINK_METRIC_TYPE will be used by this specification. An
链接度量TLV用于HELLO消息和TC消息中。它可以使用任何类型的扩展；本规范仅使用类型扩展名等于LINK_METRIC_type的LINK_METRIC TLV。一
address MUST NOT be associated with more than one link metric value for any given type extension, kind (link or neighbor), and direction using this TLV.
对于使用此TLV的任何给定类型扩展、种类（链路或邻居）和方向，地址不得与多个链路度量值关联。
+-------------+--------------+--------------------------------------+
| Type | Value Length | Value |
+-------------+--------------+--------------------------------------+
| LINK_METRIC | 2 octets | Bits 0-3 indicate kind(s) and |
| | | direction(s); bits 4-7 indicate |
| | | exponent (b); and bits 8-15 indicate |
| | | mantissa (a). |
+-------------+--------------+--------------------------------------+
+-------------+--------------+--------------------------------------+
| Type | Value Length | Value |
+-------------+--------------+--------------------------------------+
| LINK_METRIC | 2 octets | Bits 0-3 indicate kind(s) and |
| | | direction(s); bits 4-7 indicate |
| | | exponent (b); and bits 8-15 indicate |
| | | mantissa (a). |
+-------------+--------------+--------------------------------------+
Table 3: LINK_METRIC TLV Definition
表3：链路度量TLV定义
The exponent and mantissa use the representation defined in Section 6. Each bit of the types and directions sub-field, if set ('1'), indicates that the link metric is of the indicated kind and direction. Any combination of these bits MAY be used.
指数和尾数使用第6节中定义的表示法。“类型和方向”子字段的每一位（如果设置为“1”），表示链接度量为所指示的类型和方向。可以使用这些位的任何组合。
+-----+-----------------+-----------+
| Bit | Kind | Direction |
+-----+-----------------+-----------+
| 0 | Link metric | Incoming |
| 1 | Link metric | Outgoing |
| 2 | Neighbor metric | Incoming |
| 3 | Neighbor metric | Outgoing |
+-----+-----------------+-----------+
+-----+-----------------+-----------+
| Bit | Kind | Direction |
+-----+-----------------+-----------+
| 0 | Link metric | Incoming |
| 1 | Link metric | Outgoing |
| 2 | Neighbor metric | Incoming |
| 3 | Neighbor metric | Outgoing |
+-----+-----------------+-----------+
Table 4: LINK_METRIC TLV Types and Directions
表4:LINK_公制TLV类型和方向
The MPR TLV is used in HELLO messages and indicates that an address with which it is associated is of a symmetric 1-hop neighbor that has been selected as an MPR.
MPR TLV用于HELLO消息中，并指示与其关联的地址是已选择为MPR的对称1跳邻居。
+------+--------------+---------------------------------------------+
| Type | Value Length | Value |
+------+--------------+---------------------------------------------+
| MPR | 1 octet | FLOODING indicates that the corresponding |
| | | address is of a neighbor selected as a |
| | | flooding MPR; ROUTING indicates that the |
| | | corresponding address is of a neighbor |
| | | selected as a routing MPR; and FLOOD_ROUTE |
| | | indicates both (see Section 24.6). |
+------+--------------+---------------------------------------------+
+------+--------------+---------------------------------------------+
| Type | Value Length | Value |
+------+--------------+---------------------------------------------+
| MPR | 1 octet | FLOODING indicates that the corresponding |
| | | address is of a neighbor selected as a |
| | | flooding MPR; ROUTING indicates that the |
| | | corresponding address is of a neighbor |
| | | selected as a routing MPR; and FLOOD_ROUTE |
| | | indicates both (see Section 24.6). |
+------+--------------+---------------------------------------------+
Table 5: MPR TLV Definition
表5:MPR TLV定义
The NBR_ADDR_TYPE TLV is used in TC messages.
在TC消息中使用NBR_ADDR_类型TLV。
+---------------+--------------+------------------------------------+
| Type | Value Length | Value |
+---------------+--------------+------------------------------------+
| NBR_ADDR_TYPE | 1 octet | ORIGINATOR indicates that the |
| | | corresponding address (which MUST |
| | | have maximum prefix length) is an |
| | | originator address; ROUTABLE |
| | | indicates that the corresponding |
| | | network address is a routable |
| | | address of an interface; and |
| | | ROUTABLE_ORIG indicates that the |
| | | corresponding address is both (see |
| | | Section 24.6). |
+---------------+--------------+------------------------------------+
+---------------+--------------+------------------------------------+
| Type | Value Length | Value |
+---------------+--------------+------------------------------------+
| NBR_ADDR_TYPE | 1 octet | ORIGINATOR indicates that the |
| | | corresponding address (which MUST |
| | | have maximum prefix length) is an |
| | | originator address; ROUTABLE |
| | | indicates that the corresponding |
| | | network address is a routable |
| | | address of an interface; and |
| | | ROUTABLE_ORIG indicates that the |
| | | corresponding address is both (see |
| | | Section 24.6). |
+---------------+--------------+------------------------------------+
Table 6: NBR_ADDR_TYPE TLV Definition
表6:NBR\U ADDR\U型TLV定义
If an address is both an originator address and a routable address, then it may be associated with either one Address Block TLV with Type := NBR_ADDR_TYPE and Value := ROUTABLE_ORIG, or with two Address Block TLVs with Type:= NBR_ADDR_TYPE, one with Value := ORIGINATOR and one with Value := ROUTABLE.
如果一个地址既是发起者地址又是可路由地址，那么它可能与一个地址块TLV（类型：=NBR\U ADDR\U Type，值：=routable\U ORIG）相关联，或者与两个地址块TLV（类型：=NBR\U ADDR\U Type）相关联，一个地址块TLV（值：=发起者），另一个地址块TLV（值：=routable）相关联。
The GATEWAY TLV is used in TC messages. An address MUST NOT be associated with more than one hop count value using this TLV.
网关TLV用于TC消息中。使用此TLV时，地址不得与多个跃点计数值关联。
+---------+--------------+-------------------------------------+
| Type | Value Length | Value |
+---------+--------------+-------------------------------------+
| GATEWAY | 1 octet | Number of hops to attached network. |
+---------+--------------+-------------------------------------+
+---------+--------------+-------------------------------------+
| Type | Value Length | Value |
+---------+--------------+-------------------------------------+
| GATEWAY | 1 octet | Number of hops to attached network. |
+---------+--------------+-------------------------------------+
Table 7: GATEWAY TLV Definition
表7：网关TLV定义
All address objects included in a TC message according to this specification MUST be associated either with at least one TLV with Type := NBR_ADDR_TYPE or with a TLV with Type := GATEWAY, but not both. Any other address objects MAY be included in Address Blocks in a TC message but are ignored by this specification.
根据本规范，TC消息中包含的所有地址对象必须与至少一个类型为：=NBR\U ADDR\U Type的TLV或类型为：=GATEWAY的TLV相关联，但不能同时与这两个TLV相关联。任何其他地址对象都可以包含在TC消息的地址块中，但本规范将忽略这些对象。
This section describes the optimized flooding operation (MPR flooding) used when control messages, as instances of [RFC5444], are intended for MANET-wide distribution. This flooding mechanism defines when a received message is, or is not, processed and/or forwarded.
本节描述了当控制消息（如[RFC5444]的实例）用于MANET范围的分发时使用的优化泛洪操作（MPR泛洪）。此泛洪机制定义何时处理和/或转发接收到的消息。
This flooding mechanism is used by this protocol and MAY be used by extensions to this protocol that define, and hence own, other Message Types, to manage processing and/or forwarding of these messages. This specification contains elements (P_type, RX_type, F_type) required only for such usage.
该泛洪机制由该协议使用，并且可由该协议的扩展使用，该扩展定义并因此拥有其他消息类型，以管理这些消息的处理和/或转发。本规范包含仅用于此类用途的元件（P_型、RX_型、F_型）。
This flooding mechanism is always used for TC messages (see Section 16). Received HELLO messages (see Section 15) are, unless invalid, always processed and never forwarded by this flooding mechanism. They thus do not need to be recorded in the Received Message Information Base.
此泛洪机制始终用于TC消息（参见第16节）。除非无效，否则接收到的HELLO消息（参见第15节）将始终由该泛洪机制进行处理，并且从不转发。因此，它们不需要记录在接收到的消息信息库中。
The processing selection and forwarding mechanisms are designed to only need to parse the Message Header in order to determine whether a message is to be processed and/or forwarded and not to have to parse the Message Body even if the message is forwarded (but not processed). An implementation MAY only parse the Message Body if necessary or MAY always parse the Message Body and reject the message if it cannot be so parsed or any other error is identified.
处理选择和转发机制被设计为仅需要解析消息头以确定消息是否要被处理和/或转发，并且即使消息被转发（但未被处理），也不必解析消息体。实现可能仅在必要时解析消息体，也可能始终解析消息体，并在无法解析消息或发现任何其他错误时拒绝消息。
An implementation MUST discard the message silently if it is unable to parse the Message Header or (if attempted) the Message Body, or if a message (other than a HELLO message) does not include a message sequence number.
如果实现无法解析消息头或（如果尝试）消息体，或者如果消息（HELLO消息除外）不包含消息序列号，则实现必须以静默方式丢弃消息。
On receiving, on an OLSRv2 interface, a message of a type specified to be using this mechanism, which includes the TC messages defined in this specification, a router MUST perform the following:
在OLSRv2接口上接收指定使用此机制的类型的消息（包括本规范中定义的TC消息）时，路由器必须执行以下操作：
1. If the router recognizes from the originator address of the message that the message is one that the receiving router itself originated (i.e., the message originator address is the originator address of this router or is an O_orig_addr in an Originator Tuple), then the message MUST be silently discarded.
1. 如果路由器从消息的发起者地址识别出该消息是接收路由器本身发起的消息（即，消息发起者地址是该路由器的发起者地址，或者是发起者元组中的一个O_orig_addr），则必须以静默方式丢弃该消息。
2. Otherwise:
2. 否则：
1. If the message is of a type that may be processed, then the message is considered for processing according to Section 14.2.
1. 如果该信息属于可以处理的类型，则根据第14.2节考虑处理该信息。
2. If the message is of a type that may be forwarded, AND:
2. 如果该消息属于可转发的类型，并且：
+ <msg-hop-limit> is present and <msg-hop-limit> > 1; AND
+ <msg-hop-limit> is present and <msg-hop-limit> > 1; AND
+ <msg-hop-count> is not present or <msg-hop-count> < 255,
+ <msg hop count>不存在或<msg hop count><255，
then the message is considered for forwarding according to Section 14.3.
然后根据第14.3节考虑转发该消息。
If a message (the "current message") is considered for processing, then the following tasks MUST be performed:
如果考虑处理消息（“当前消息”），则必须执行以下任务：
1. If the sending address (i.e., the source address of the IP datagram containing the current message) does not match (taking into account any address prefix) a network address in an L_neighbor_iface_addr_list of a Link Tuple, with L_status = SYMMETRIC, in the Link Set for the OLSRv2 interface on which the current message was received (the "receiving interface"), then processing the current message is OPTIONAL. If the current message is not processed, then the following steps are not carried out.
1. 如果发送地址（即，包含当前消息的IP数据报的源地址）与接收当前消息的OLSRv2接口的链路集中链路元组的L_neighbor_iface_addr_列表中的网络地址（L_status=SYMMETRIC）不匹配（考虑到任何地址前缀），则“接收接口”），则处理当前消息是可选的。如果未处理当前消息，则不执行以下步骤。
2. If a Processed Tuple exists with:
2. 如果已处理的元组与以下元组一起存在：
* P_type = the Message Type of the current message; AND
* P_type=当前报文的报文类型；和
* P_orig_addr = the originator address of the current message; AND
* P_orig_addr=当前消息的发起人地址；和
* P_seq_number = the message sequence number of the current message,
* P_seq_number=当前消息的消息序列号，
then the current message MUST NOT be processed.
则不能处理当前消息。
3. Otherwise:
3. 否则：
1. Create a Processed Tuple in the Processed Set with:
1. 在已处理集中创建已处理元组，方法是：
+ P_type := the Message Type of the current message;
+ P_type:=当前报文的报文类型；
+ P_orig_addr := the originator address of the current message;
+ P_orig_addr:=当前消息的发起人地址；
+ P_seq_number := the sequence number of the current message;
+ P_seq_number:=当前报文的序列号；
+ P_time := current time + P_HOLD_TIME.
+ P_时间：=当前时间+P_保持时间。
2. Process the current message according to its Message Type. For a TC message, this is as defined in Section 16.3.
2. 根据消息类型处理当前消息。对于TC消息，其定义见第16.3节。
If a message (the "current message") is considered for forwarding, then the following tasks MUST be performed:
如果考虑转发邮件（“当前邮件”），则必须执行以下任务：
1. If the sending address (i.e., the source address of the IP datagram containing the current message) does not match (taking into account any address prefix) a network address in an L_neighbor_iface_addr_list of a Link Tuple, with L_status = SYMMETRIC, in the Link Set for the OLSRv2 interface on which the current message was received (the "receiving interface"), then the current message MUST be silently discarded.
1. 如果发送地址（即，包含当前消息的IP数据报的源地址）与接收当前消息的OLSRv2接口的链路集中链路元组的L_neighbor_iface_addr_列表中的网络地址（L_status=SYMMETRIC）不匹配（考虑到任何地址前缀），则“接收接口”），则必须以静默方式丢弃当前消息。
2. Otherwise:
2. 否则：
1. If a Received Tuple exists in the Received Set for the receiving interface, with:
1. 如果接收接口的接收集中存在接收元组，则：
+ RX_type = the Message Type of the current message; AND
+ RX_type=当前消息的消息类型；和
+ RX_orig_addr = the originator address of the current message; AND
+ RX_orig_addr=当前消息的发起人地址；和
+ RX_seq_number = the sequence number of the current message,
+ RX_seq_number=当前消息的序列号，
then the current message MUST be silently discarded.
然后当前消息必须以静默方式丢弃。
2. Otherwise:
2. 否则：
1. Create a Received Tuple in the Received Set for the receiving interface with:
1. 在接收集中为接收接口创建接收元组，方法为：
- RX_type := the Message Type of the current message;
- RX_type:=当前报文的报文类型；
- RX_orig_addr := originator address of the current message;
- RX_orig_addr:=当前消息的发起人地址；
- RX_seq_number := sequence number of the current message;
- RX_seq_number:=当前报文的序列号；
- RX_time := current time + RX_HOLD_TIME.
- 接收时间：=当前时间+接收保持时间。
2. If a Forwarded Tuple exists with:
2. 如果存在转发的元组，则包含：
- F_type = the Message Type of the current message; AND
- F_type=当前消息的消息类型；和
- F_orig_addr = the originator address of the current message; AND
- F_orig_addr=当前消息的发起人地址；和
- F_seq_number = the sequence number of the current message,
- F_seq_number=当前消息的序列号，
then the current message MUST be silently discarded.
然后当前消息必须以静默方式丢弃。
3. Otherwise, if the sending address matches (taking account of any address prefix), any network address in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set for the receiving OLSRv2 interface that has L_status = SYMMETRIC and L_mpr_selector = true, then:
3. 否则，如果发送地址匹配（考虑任何地址前缀），则接收OLSRv2接口的链路集中链路元组的L_neighbor_iface_addr_列表中的任何网络地址（L_status=SYMMETRIC，L_mpr_selector=true），则：
1. Create a Forwarded Tuple in the Forwarded Set with:
1. 使用以下内容在转发集中创建转发元组：
o F_type := the Message Type of the current message;
o F_type:=当前报文的报文类型；
o F_orig_addr := originator address of the current message;
o F_orig_addr:=当前消息的发起人地址；
o F_seq_number := sequence number of the current message;
o F_seq_number:=当前报文的序号；
o F_time := current time + F_HOLD_TIME.
o F_时间：=当前时间+F_保持时间。
2. The Message Header of the current message is modified by:
2. 当前消息的消息头由以下内容修改：
o Decrement <msg-hop-limit> in the Message Header by 1; AND
o 将消息头中的<msg hop limit>减少1；和
o If present, increment <msg-hop-count> in the Message Header by 1.
o 如果存在，则将消息头中的<msg hop count>增加1。
3. The message is transmitted over all OLSRv2 interfaces, as described in Section 13.
3. 如第13节所述，该消息通过所有OLSRv2接口传输。
4. Otherwise, the current message MUST be silently discarded.
4. 否则，必须以静默方式丢弃当前消息。
The HELLO Message Type is owned by NHDP [RFC6130], and HELLO messages are thus generated, transmitted, received, and processed by NHDP. This protocol, as permitted by [RFC6130], also uses HELLO messages, including adding to HELLO message generation and implementing additional processing based on received HELLO messages. HELLO messages are not forwarded by NHDP [RFC6130] or by OLSRv2.
HELLO消息类型由NHDP[RFC6130]拥有，因此HELLO消息由NHDP生成、传输、接收和处理。[RFC6130]允许该协议也使用HELLO消息，包括添加HELLO消息生成和基于接收到的HELLO消息实现附加处理。NHDP[RFC6130]或OLSRv2不会转发HELLO消息。
HELLO messages sent over OLSRv2 interfaces are generated as defined in [RFC6130] and then modified as described in this section. HELLO messages sent on other MANET interfaces are not modified by this specification.
通过OLSRv2接口发送的HELLO消息按照[RFC6130]中的定义生成，然后按照本节中的描述进行修改。本规范不修改在其他MANET接口上发送的HELLO消息。
HELLO messages sent over OLSRv2 interfaces are extended by adding the following elements:
通过添加以下元素扩展通过OLSRv2接口发送的HELLO消息：
o A message originator address, recording this router's originator address. This MUST use a <msg-orig-addr> element, unless:
o 消息发起人地址，记录此路由器的发起人地址。这必须使用<msg orig addr>元素，除非：
* The message specifies only a single local interface address (i.e., contains only one address object that is associated with an Address Block TLV with Type = LOCAL_IF and that has no prefix length or a maximum prefix length) that will then be used as the message originator address; OR
* 该消息仅指定一个本地接口地址（即，仅包含一个地址对象，该地址对象与Type=local_IF且没有前缀长度或最大前缀长度的地址块TLV关联），该地址对象随后将用作消息发起人地址；或
* The message does not include any local interface network addresses (i.e., has no address objects associated with an Address Block TLV with Type = LOCAL_IF), as permitted by the specification in [RFC6130], when the router that generated the HELLO message has only one interface address and will use that as the sending address of the IP datagram in which the HELLO message is contained. In this case, that address will be used as the message originator address.
* 该消息不包括[RFC6130]中规范允许的任何本地接口网络地址（即，没有与类型为local_IF的地址块TLV关联的地址对象），当生成HELLO消息的路由器只有一个接口地址，并将其用作包含HELLO消息的IP数据报的发送地址时。在这种情况下，该地址将用作消息发起人地址。
o A Message TLV with Type := MPR_WILLING MUST be included.
o 必须包含类型为：=MPR\U的消息TLV。
o The following cases associate Address Block TLVs with one or more addresses from a Link Tuple or a Neighbor Tuple if these are included in the HELLO message. In each case, the TLV MUST be associated with at least one address object for an address from the relevant Tuple; the TLV MAY be associated with more such addresses (including a copy of that address object, possibly not
o 以下情况将地址块TLV与链接元组或邻居元组中的一个或多个地址关联（如果这些地址包含在HELLO消息中）。在每种情况下，TLV必须与来自相关元组的地址的至少一个地址对象相关联；TLV可以与更多这样的地址相关联（包括该地址对象的副本，可能不是）
itself associated with any other indicated TLVs, in the same or a different Address Block). These additional TLVs MUST NOT be associated with any other addresses in a HELLO message that will be processed by NHDP [RFC6130].
自身与同一或不同地址块中的任何其他指示TLV关联）。这些附加TLV不得与NHDP[RFC6130]将处理的HELLO消息中的任何其他地址相关联。
* For each Link Tuple for which L_in_metric != UNKNOWN_METRIC and for which one or more addresses in its L_neighbor_iface_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS and Value = HEARD or Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an incoming link metric with value L_in_metric.
* 对于L_in_metric！=未知\度量，其L\ U邻居\ iface\ addr\ U列表中的一个或多个地址作为地址对象包含在与类型=链接\状态和值=听到或值=对称的关联地址块TLV中，这些地址中至少有一个必须与类型为：=LINK\u METRIC的地址块TLV关联，该类型指示值为L\u in\u METRIC的传入链路度量。
* For each Link Tuple for which L_out_metric != UNKNOWN_METRIC and for which one or more addresses in its L_neighbor_iface_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an outgoing link metric with value L_out_metric.
* 对于L_out_度量！=未知\度量，其L\ U邻居\ iface\ addr\ U列表中的一个或多个地址作为地址对象包含在与类型=链接\状态和值=对称的关联地址块TLV中，这些地址中必须至少有一个与地址块TLV关联，类型为：=LINK\u METRIC，表示值为L\u out\u METRIC的传出链路度量。
* For each Neighbor Tuple for which N_symmetric = true and for which one or more addresses in its N_neighbor_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an incoming neighbor metric with value N_in_metric.
* 对于N_symmetric=true且其N_nexter_addr_列表中的一个或多个地址作为地址对象包含的每个相邻元组，其关联地址块TLV的类型为LINK_STATUS或类型为OTHER_NEIGHB且值为symmetric，这些地址中至少有一个必须与类型为：=LINK_METRIC的地址块TLV相关联，该类型指示值为N_in_METRIC的传入邻居度量。
* For each Neighbor Tuple for which N_symmetric = true and for which one or more addresses in its N_neighbor_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an outgoing neighbor metric with value N_out_metric.
* 对于N_symmetric=true且其N_nexter_addr_列表中的一个或多个地址作为地址对象包含的每个相邻元组，其关联地址块TLV的类型为LINK_STATUS或类型为OTHER_NEIGHB且值为symmetric，这些地址中至少有一个必须与类型为：=LINK\u METRIC的地址块TLV关联，该类型指示值为N\u out\u METRIC的传出邻居度量。
* For each Neighbor Tuple with N_flooding_mpr = true and for which one or more network addresses in its N_neighbor_addr_list are included as address objects in the HELLO message with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := MPR and Value := FLOODING or Value := FLOOD_ROUTE.
* 对于N_flooding_mpr=true且其N_Neighbor_addr_列表中的一个或多个网络地址作为地址对象包含在HELLO消息中的每个邻居元组，其关联地址块TLV的类型=LINK_STATUS，值=SYMMETRIC，这些地址中至少有一个必须与类型为：=MPR、值为：=FLOOD或值为：=FLOOD\u ROUTE的地址块TLV相关联。
* For each Neighbor Tuple with N_routing_mpr = true and for which one or more network addresses in its N_neighbor_addr_list are included as address objects in the HELLO message with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := MPR and Value := ROUTING or Value := FLOOD_ROUTE.
* 对于N_routing_mpr=true且其N_Neighbor_addr_列表中的一个或多个网络地址作为地址对象包含在HELLO消息中的每个邻居元组，其关联地址块TLV的类型=LINK_STATUS，值=SYMMETRIC，这些地址中至少有一个必须与类型为=MPR且值为=路由或值为=泛洪路由的地址块TLV相关联。
HELLO messages are scheduled and transmitted by NHDP [RFC6130]. This protocol MAY require that an additional HELLO message be sent on each OLSRv2 interface when either of the router's sets of MPRs changes, in addition to the cases specified in [RFC6130] and subject to the constraints specified in [RFC6130] (notably on minimum HELLO message transmission intervals).
HELLO消息由NHDP[RFC6130]调度和传输。除了[RFC6130]中规定的情况外，该协议可能要求在路由器的MPR集合发生变化时，在每个OLSRv2接口上发送额外的HELLO消息，并遵守[RFC6130]中规定的约束条件（尤其是最小HELLO消息传输间隔）。
When received on an OLSRv2 interface, HELLO messages are made available to this protocol in two ways, both as permitted by [RFC6130]:
当在OLSRv2接口上接收到HELLO消息时，HELLO消息可通过两种方式供此协议使用，这两种方式都是[RFC6130]允许的：
o Such received HELLO messages MUST be made available to this protocol on reception, which allows them to be discarded before being processed by NHDP [RFC6130], for example, if the information added to the HELLO message by this specification is inconsistent.
o 此类收到的HELLO消息必须在接收时可供本协议使用，这允许在NHDP[RFC6130]处理之前丢弃这些消息，例如，如果本规范添加到HELLO消息的信息不一致。
o Such received HELLO messages MUST be made available to OLSRv2 after NHDP [RFC6130] has completed its processing thereof, unless discarded as malformed by NHDP, for processing by OLSRv2.
o 在NHDP[RFC6130]完成其处理后，必须将收到的此类HELLO消息提供给OLSRv2，除非NHDP将其丢弃为格式错误，以供OLSRv2处理。
In addition to the reasons specified in [RFC6130] for discarding a HELLO message on reception, a HELLO message received on an OLSRv2 interface MUST be discarded before processing by NHDP [RFC6130] or this specification if it:
除了[RFC6130]中规定的在接收时丢弃HELLO消息的原因外，在NHDP[RFC6130]或本规范处理之前，必须丢弃OLSRv2接口上接收的HELLO消息，前提是：
o Has more than one Message TLV with Type = MPR_WILLING.
o 具有多个类型为MPR\U的邮件TLV。
o Has a message originator address, or a network address corresponding to an address object associated with an Address Block TLV with Type = LOCAL_IF, that is partially owned by this router. (Some of these cases are already excluded by [RFC6130].)
o 具有一个消息发起人地址，或一个网络地址，该地址对应于一个地址对象，该地址对象与一个类型为LOCAL_IF的地址块TLV相关联，该地址块TLV部分归该路由器所有。（其中一些案例已被[RFC6130]排除在外。）
o Includes any address object associated with an Address Block TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB that overlaps the message's originator address.
o 包括与类型为LINK\u STATUS或类型为OTHER\u NEIGHB的地址块TLV关联的任何地址对象，该地址块TLV与邮件的原始发件人地址重叠。
o Contains any address that will be processed by NHDP [RFC6130] that is associated, using the same or different address objects, with two different values of link metric with the same kind and direction using a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE. This also applies to different addresses that are both of the OLSRv2 interface on which the HELLO message was received.
o 包含NHDP[RFC6130]将处理的任何地址，该地址使用相同或不同的地址对象，与两个不同的链接度量值相关联，具有相同的类型和方向，使用类型为link\u metric且类型扩展名为link\u metric\u Type的TLV。这也适用于接收HELLO消息的OLSRv2接口的不同地址。
o Contains any address object associated with an Address Block TLV with Type = MPR that is not also associated with an Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC (including using a different copy of that address object in the same or a different Address Block).
o 包含与类型为MPR的地址块TLV关联的任何地址对象，该地址块TLV不与类型为LINK_STATUS且值为SYMMETRIC的地址块TLV关联（包括在相同或不同的地址块中使用该地址对象的不同副本）。
HELLO messages are first processed as specified in [RFC6130]. That processing includes identifying (or creating) a Link Tuple and a Neighbor Tuple corresponding to the originator of the HELLO message (the "current Link Tuple" and the "current Neighbor Tuple"). After this, the following processing MUST also be performed if the HELLO message is received on an OLSRv2 interface and contains a TLV with Type = MPR_WILLING:
HELLO消息首先按照[RFC6130]中的规定进行处理。该处理包括识别（或创建）与HELLO消息的发起人对应的链接元组和邻居元组（“当前链接元组”和“当前邻居元组”）。在此之后，如果在OLSRv2接口上接收到HELLO消息，并且包含类型为MPR\u的TLV，则还必须执行以下处理：
1. If the HELLO message has a well-defined message originator address, i.e., has an <msg-orig-addr> element or has zero or one network addresses associated with a TLV with Type = LOCAL_IF:
1. 如果HELLO消息具有定义良好的消息发起人地址，即具有<msg orig addr>元素，或者具有零个或一个与类型为LOCAL\u的TLV相关联的网络地址，则：
1. Remove any Neighbor Tuple, other than the current Neighbor Tuple, with N_orig_addr = message originator address, taking any consequent action (including removing one or more Link Tuples) as specified in [RFC6130].
1. 按照[RFC6130]中的规定，删除N_orig_addr=消息发起者地址的任何邻居元组（当前邻居元组除外），并采取任何后续操作（包括删除一个或多个链接元组）。
2. The current Link Tuple is then updated according to:
2. 然后根据以下内容更新当前链接元组：
1. Update L_in_metric and L_out_metric as described in Section 15.3.2.1;
1. 如第15.3.2.1节所述，更新L_in_度量和L_out_度量；
2. Update L_mpr_selector as described in Section 15.3.2.3.
2. 如第15.3.2.3节所述，更新L_mpr_选择器。
3. The current Neighbor Tuple is then updated according to:
3. 然后根据以下内容更新当前邻居元组：
1. N_orig_addr := message originator address;
1. N_orig_addr:=消息发起人地址；
2. Update N_in_metric and N_out_metric as described in Section 15.3.2.1;
2. 如第15.3.2.1节所述，更新N_in_度量和N_out_度量；
3. Update N_will_flooding and N_will_routing as described in Section 15.3.2.2;
3. 更新第15.3.2.2节所述的N_将_洪水和N_将_路由；
4. Update N_mpr_selector as described in Section 15.3.2.3.
4. 如第15.3.2.3节所述，更新N_mpr_选择器。
4. All 2-Hop Tuples that were updated as described in [RFC6130] are then updated according to:
4. 然后，按照[RFC6130]中所述更新的所有2跳元组将根据以下内容进行更新：
1. Update N2_in_metric and N2_out_metric as described in Section 15.3.2.1.
1. 如第15.3.2.1节所述，更新N2_输入_度量和N2_输出_度量。
2. If there are any changes to the router's Information Bases, then perform the processing defined in Section 17.
2. 如果路由器的信息库有任何变化，则执行第17节中定义的处理。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS and Value = HEARD or Value = SYMMETRIC, an incoming (to the message originator) link metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (link) and direction (incoming) of metric, then the incoming link metric is that metric value; otherwise, the incoming link metric is defined as UNKNOWN_METRIC.
对于接收到的HELLO消息中的每个地址，以及类型=LINK_STATUS且值=hear或值=SYMMETRIC的关联TLV，定义了传入（消息发起人）链接度量值。如果HELLO消息包含类型为LINK\u METRIC且类型扩展名为LINK\u METRIC\u Type的TLV，该TLV将该地址值与适当类型（LINK）和方向（传入）的度量值相关联，则传入的链路度量就是该度量值；否则，传入链路度量被定义为未知_度量。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS and Value = SYMMETRIC, an outgoing (from the message originator) link metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (link) and direction (outgoing) of metric, then the outgoing link metric is that metric value; otherwise, the outgoing link metric is defined as UNKNOWN_METRIC.
对于接收到的HELLO消息中的每个地址，以及类型=LINK_STATUS且值=SYMMETRIC的关联TLV，定义了一个传出（来自消息发起者）链接度量值。如果HELLO消息包含一个TLV，其类型=LINK\u METRIC，类型扩展=LINK\u METRIC\u Type将该地址值与相应类型（LINK）和方向（outing）的度量值相关联，则outing LINK METRIC就是该度量值；否则，传出链路度量被定义为未知_度量。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, an incoming (to the message originator) neighbor metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (neighbor) and direction (incoming) of metric, then the incoming neighbor metric is that metric value; otherwise, the incoming neighbor metric is defined as UNKNOWN_METRIC.
对于接收到的HELLO消息中的每个地址，以及类型=LINK_STATUS或类型=OTHER_NEIGHB且值=SYMMETRIC的关联TLV，定义了传入（消息发起人）邻居度量值。如果HELLO消息包含类型为LINK\u METRIC且类型扩展为LINK\u METRIC\u Type的TLV，该TLV将该地址值与适当类型（邻居）和方向（传入）的度量值相关联，则传入邻居度量就是该度量值；否则，传入的邻居度量被定义为未知的_度量。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, an outgoing (from the message originator) neighbor metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (neighbor) and direction (outgoing) of metric, then the outgoing neighbor metric is that metric value; otherwise, the outgoing neighbor metric is defined as UNKNOWN_METRIC.
对于接收到的HELLO消息中的每个地址，以及类型=LINK_STATUS或类型=OTHER_NEIGHB且值=SYMMETRIC的关联TLV，定义了传出（来自消息发起者）邻居度量值。如果HELLO消息包含类型为LINK\u METRIC且类型扩展为LINK\u METRIC\u Type的TLV，该TLV将该地址值与适当类型（邻居）和方向（传出）的度量值相关联，则传出邻居度量就是该度量值；否则，将传出邻居度量定义为未知_度量。
The link metric elements L_in_metric and L_out_metric in a Link Tuple are updated according to the following:
链接元组中的链接度量元素L_in_metric和L_out_metric根据以下内容更新：
o For any Link Tuple, L_in_metric MAY be set to any representable value by a process outside this specification at any time. L_in_metric MUST be so set whenever L_status becomes equal to HEARD or SYMMETRIC (if no other value is available, then the value MAXIMUM_METRIC MUST be used). Setting L_in_metric MAY use information based on the receipt of a packet including a HELLO message that causes the creation or updating of the Link Tuple.
o 对于任何链接元组，L_in_度量可以通过本规范之外的过程随时设置为任何可表示的值。每当L_状态变为相等或对称时，L_in_度量必须如此设置（如果没有其他值可用，则必须使用值最大值_度量）。设置L_in_度量可以使用基于接收到包括导致创建或更新链接元组的HELLO消息的分组的信息。
o When, as specified in [RFC6130], a Link Tuple is updated (possibly immediately after being created) due to the receipt of a HELLO message, if L_status = SYMMETRIC, then L_out_metric is set equal to the incoming link metric for any included address of the interface on which the HELLO message was received. (Note that the rules for discarding HELLO messages in Section 15.3.1 make this value unambiguous.) If there is any such address, but no such link metric, then L_out_metric is set to UNKNOWN_METRIC.
o 如[RFC6130]中所述，由于收到HELLO消息而更新链接元组时（可能在创建后立即更新），如果L_status=SYMMETRIC，则L_out_度量设置为等于接收HELLO消息的接口的任何包含地址的传入链接度量。（请注意，第15.3.1节中丢弃HELLO消息的规则使该值明确无误。）如果存在任何此类地址，但没有此类链接度量，则L_out_度量设置为UNKNOWN_度量。
The neighbor metric elements N_in_metric and N_out_metric in a Neighbor Tuple are updated according to Section 17.3.
根据第17.3节更新相邻元组中的相邻度量元素N_in_度量和N_out_度量。
The metric elements N2_in_metric and N2_out_metric in any 2-Hop Tuple updated as defined in [RFC6130] are updated to equal the incoming neighbor metric and outgoing neighbor metric, respectively, associated with the corresponding N2_2hop_addr. If there are no such metrics, then these elements are set to UNKNOWN_METRIC.
按照[RFC6130]中的定义更新的任何2跳元组中的度量元素N2_in_度量和N2_out_度量被更新为分别等于与相应的N2_2hop_addr相关联的传入邻居度量和传出邻居度量。如果没有这样的度量，那么这些元素将被设置为未知的度量。
N_will_flooding and N_will_routing in the current Neighbor Tuple are updated using the Message TLV with Type = MPR_WILLING (note that this must be present) as follows:
当前邻居元组中的N_will_flooding和N_will_routing使用Type=MPR_-will的消息TLV更新，如下所示（注意，必须存在）：
o N_will_flooding := bits 0-3 of the value of that TLV; AND
o N_will_flooding:=该TLV值的0-3位；和
o N_will_routing := bits 4-7 of the value of that TLV.
o N_will_routing:=该TLV值的第4-7位。
(Each being in the range 0 to 15, i.e., WILL_NEVER to WILL_ALWAYS.)
（每个都在0到15之间，即永远不会到永远。）
L_mpr_selector is updated as follows:
L_mpr_选择器更新如下：
1. If a router finds an address object representing any of its relevant local interface network addresses (i.e., those contained in the I_local_iface_addr_list of an OLSRv2 interface) with an associated Address Block TLV with Type = MPR and Value = FLOODING or Value = FLOOD_ROUTE in the HELLO message (indicating that the originating router has selected the receiving router as a flooding MPR), then, for the current Link Tuple:
1. 如果路由器在HELLO消息中找到一个地址对象，该对象表示其任何相关的本地接口网络地址（即OLSRv2接口的i_local_iface_addr_列表中包含的地址对象），该地址对象具有类型为MPR、值为FLOODING或值为FLOOD_路由的关联地址块TLV（表示发起路由器已选择接收路由器作为泛洪MPR），然后，对于当前链路元组：
* L_mpr_selector := true.
* L\u mpr\u选择器：=真。
2. Otherwise (i.e., if no such address object and Address Block TLV was found), if a router finds an address object representing any of its relevant local interface network addresses (i.e., those contained in the I_local_iface_addr_list of an OLSRv2 interface) with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC in the HELLO message, then, for the current Link Tuple:
2. 否则（即，如果未找到此类地址对象和地址块TLV），如果路由器找到表示其任何相关本地接口网络地址的地址对象（即OLSRv2接口的i_local_iface_addr_列表中包含的地址对象）在HELLO消息中使用Type=LINK\u STATUS和Value=SYMMETRIC的关联地址块TLV，然后，对于当前链接元组：
* L_mpr_selector := false.
* L\u mpr\u选择器：=false。
N_mpr_selector is updated as follows:
N_mpr_选择器更新如下：
1. If a router finds an address object representing any of its relevant local interface network addresses (those contained in the I_local_iface_addr_list of an OLSRv2 interface) with an associated Address Block TLV with Type = MPR and Value = ROUTING or Value = FLOOD_ROUTE in the HELLO message (indicating that the originating router has selected the receiving router as a routing MPR), then, for the current Neighbor Tuple:
1. 如果路由器在HELLO消息中找到一个地址对象，该对象表示其任何相关的本地接口网络地址（包含在OLSRv2接口的I_local_iface_addr_列表中的地址），该地址对象具有类型为MPR、值为ROUTING或值为FLOOD_ROUTE的关联地址块TLV（表示发起路由器已选择接收路由器作为路由MPR），然后，对于当前邻居元组：
* N_mpr_selector := true;
* N\u mpr\u选择器：=真；
* N_advertised := true.
* N_广告：=正确。
2. Otherwise (i.e., if no such address object and Address Block TLV was found), if a router finds an address object representing any of its relevant local interface network addresses (those contained in the I_local_iface_addr_list of an OLSRv2 interface)
2. 否则（即，如果未找到此类地址对象和地址块TLV），如果路由器找到表示其任何相关本地接口网络地址的地址对象（包含在OLSRv2接口的i_local_iface_addr_列表中的地址对象）
with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC in the HELLO message, then, for the current Neighbor Tuple:
在HELLO消息中使用Type=LINK\u STATUS和Value=SYMMETRIC的关联地址块TLV，然后，对于当前邻居元组：
* N_mpr_selector := false;
* N\u mpr\u选择器：=假；
* The router MAY also set N_advertised := false.
* 路由器还可以设置N_:=false。
This protocol defines, and hence owns, the TC Message Type (see Section 24). Thus, as specified in [RFC5444], this protocol generates and transmits all TC messages, receives all TC messages, and is responsible for determining whether and how each TC message is to be processed (updating the Topology Information Base) and/or forwarded, according to this specification.
该协议定义并因此拥有TC消息类型（见第24节）。因此，如[RFC5444]中所述，该协议生成并发送所有TC消息，接收所有TC消息，并负责根据本规范确定是否以及如何处理（更新拓扑信息库）和/或转发每个TC消息。
A TC message is a message as defined in [RFC5444]. A generated TC message MUST contain the following elements as defined in [RFC5444]:
TC消息是[RFC5444]中定义的消息。生成的TC消息必须包含[RFC5444]中定义的以下元素：
o A message originator address, recording this router's originator address. This MUST use a <msg-orig-addr> element.
o 消息发起人地址，记录此路由器的发起人地址。这必须使用<msg orig addr>元素。
o <msg-seq-num> element containing the message sequence number.
o 包含消息序列号的元素。
o A <msg-hop-limit> element, containing TC_HOP_LIMIT. A router MAY use the same or different values of TC_HOP_LIMIT in its TC messages (see Section 5.4.7).
o 一个<msg hop limit>元素，包含TC\u hop\u limit。路由器可在其TC消息中使用相同或不同的TC_HOP_LIMIT值（见第5.4.7节）。
o A <msg-hop-count> element, containing zero, if the message contains a TLV with either Type = VALIDITY_TIME or Type = INTERVAL_TIME (as specified in [RFC5497]) indicating more than one time value according to distance. A TC message MAY contain such a <msg-hop-count> element even if it does not need to.
o 如果消息包含类型=有效性\时间或类型=间隔\时间（如[RFC5497]中规定）的TLV，则包含零的<msg hop count>元素，根据距离指示多个时间值。TC消息可能包含这样的<msg hop count>元素，即使它不需要。
o A single Message TLV with Type := CONT_SEQ_NUM and Value := ANSN from the Neighbor Information Base. If the TC message is complete, then this Message TLV MUST have Type Extension := COMPLETE; otherwise, it MUST have Type Extension := INCOMPLETE. (Exception: a TC message MAY omit such a Message TLV if the TC message does not include any address objects with an associated Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY.)
o 来自邻居信息库的类型为：=CONT_SEQ_NUM、值为：=ANSN的单个消息TLV。如果TC消息已完成，则此消息TLV必须具有类型扩展名：=完成；否则，它必须具有类型扩展：=不完整。（例外情况：如果TC消息不包括任何地址对象，且该地址对象具有类型为NBR\U ADDR\U Type或类型为GATEWAY的关联地址块TLV，则TC消息可能会忽略此类消息TLV。）
o A single Message TLV with Type := VALIDITY_TIME, as specified in [RFC5497]. If all TC messages are sent with the same hop limit, then this TLV MUST have a value encoding the period T_HOLD_TIME.
o [RFC5497]中指定的类型为：=有效期\时间的单个消息TLV。如果所有TC消息都以相同的跃点限制发送，则此TLV必须具有一个编码时段T_HOLD_TIME的值。
If TC messages are sent with different hop limits (more than one value of TC_HOP_LIMIT), then this TLV MUST specify times that vary with the number of hops appropriate to the chosen pattern of TC message hop limits, as specified in [RFC5497]; these times SHOULD be appropriate multiples of T_HOLD_TIME. The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
如果发送的TC消息具有不同的跃点限制（一个以上的TC_跃点限制值），则该TLV必须根据[RFC5497]中规定的适用于所选TC消息跃点限制模式的跃点数量指定时间；这些时间应为T_保持时间的适当倍数。不得使用[RFC5497]中包含的表示零次和无限次的选项。
o If the TC message is complete, all network addresses that are the N_orig_addr of a Neighbor Tuple with N_advertised = true, MUST be represented by address objects in one or more Address Blocks. If the TC message is incomplete, then any such address objects MAY be included. At least one copy of each such address object that is included MUST be associated with an Address Block TLV with Type := NBR_ADDR_TYPE and Value := ORIGINATOR or with Value := ROUTABLE_ORIG if that address object is also to be associated with Value = ROUTABLE.
o 如果TC消息已完成，则作为N_advised=true的邻居元组的N_orig_addr的所有网络地址必须由一个或多个地址块中的地址对象表示。如果TC消息不完整，则可能包括任何此类地址对象。包含的每个此类地址对象的至少一个副本必须与类型为：=NBR\U ADDR\U Type且值为：=发起者或值为：=ROUTABLE\U ORIG的地址块TLV相关联，如果该地址对象也要与值为ROUTABLE相关联。
o If the TC message is complete, all routable addresses that are in the N_neighbor_addr_list of a Neighbor Tuple with N_advertised = true MUST be represented by address objects in one or more Address Blocks. If the TC message is incomplete, then any such address objects MAY be included. At least one copy of each such address object MUST be associated with an Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE or with Value = ROUTABLE_ORIG if also to be associated with Value = ORIGINATOR. At least one copy of each such address object MUST be associated with an Address Block TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE indicating an outgoing neighbor metric with value equal to the corresponding N_out_metric.
o 如果TC消息已完成，则N_advised=true的邻居元组的N_neighbor_addr_列表中的所有可路由地址必须由一个或多个地址块中的地址对象表示。如果TC消息不完整，则可能包括任何此类地址对象。每个地址对象的至少一个副本必须与类型为NBR\U ADDR\U Type且值为ROUTABLE或值为ROUTABLE\U ORIG的地址块TLV相关联（如果还与值为发起者相关联）。每个这样的地址对象的至少一个副本必须与类型为LINK\u METRIC且类型扩展为LINK\u METRIC\u Type的地址块TLV相关联，该类型表示值等于相应N\u out\u METRIC的传出邻居度量。
o If the TC message is complete, all network addresses that are the AL_net_addr of a Local Attached Network Tuple MUST be represented by address objects in one or more Address Blocks. If the TC message is incomplete, then any such address objects MAY be included. At least one copy of each such address object MUST be associated with an Address Block TLV with Type := GATEWAY and Value := AN_dist. At least one copy of each such address object MUST be associated with an Address Block TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE indicating an outgoing neighbor metric equal to the corresponding AL_metric.
o 如果TC消息已完成，则作为本地连接网络元组的AL_net_addr的所有网络地址必须由一个或多个地址块中的地址对象表示。如果TC消息不完整，则可能包括任何此类地址对象。每个此类地址对象的至少一个副本必须与类型：=网关且值：=地址距离的地址块TLV相关联。每个此类地址对象的至少一个副本必须与类型=链接度量且类型扩展=链接度量\类型的地址块TLV相关联，指示与相应的AL_度量。
A TC message MAY contain:
TC消息可能包含：
o A single Message TLV with Type := INTERVAL_TIME, as specified in [RFC5497]. If all TC messages are sent with the same hop limit, then this TLV MUST have a value encoding the period TC_INTERVAL. If TC messages are sent with different hop limits, then this TLV
o [RFC5497]中指定的类型为：=间隔时间的单个消息TLV。如果所有TC消息都以相同的跃点限制发送，则此TLV必须具有一个编码周期TC_间隔的值。如果发送的TC消息具有不同的跃点限制，则此TLV
MUST specify times that vary with the number of hops appropriate to the chosen pattern of TC message hop limits, as specified in [RFC5497]; these times MUST be appropriate multiples of TC_INTERVAL. The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
必须根据[RFC5497]中的规定，指定与所选TC消息跳数限制模式相适应的跳数变化的时间；这些时间必须是TC_间隔的适当倍数。不得使用[RFC5497]中包含的表示零次和无限次的选项。
A router with one or more OLSRv2 interfaces, and with any Neighbor Tuples with N_advertised = true, or with a non-empty Local Attached Network Set MUST generate TC messages. A router that does not have such information to advertise MUST also generate "empty" TC messages for a period A_HOLD_TIME after it last generated a non-empty TC message.
具有一个或多个OLSRv2接口、具有N_advised=true的任何相邻元组或具有非空本地连接网络集的路由器必须生成TC消息。没有此类信息的路由器也必须在上次生成非空TC消息后的一段时间内生成“空”TC消息。
Complete TC messages are generated and transmitted periodically on all OLSRv2 interfaces, with a default interval between two consecutive TC message transmissions by the same router of TC_INTERVAL.
在所有OLSRv2接口上定期生成和传输完整的TC消息，同一路由器的两次连续TC消息传输之间的默认间隔为TC_interval。
TC messages MAY be generated in response to a change in the information that they are to advertise, indicated by a change in the ANSN in the Neighbor Information Base. In this case, a router MAY send a complete TC message and, if so, MAY restart its TC message schedule. Alternatively, a router MAY send an incomplete TC message with at least the newly advertised network addresses (i.e., not previously, but now, an N_orig_addr or in an N_neighbor_addr_list in a Neighbor Tuple with N_advertised = true or an AL_net_addr) in its Address Blocks, with associated Address Block TLV(s). Note that a router cannot report removal of advertised content using an incomplete TC message.
TC消息可响应于它们将要公布的信息中的变化而生成，该变化由邻居信息库中的ANSN中的变化指示。在这种情况下，路由器可以发送完整的TC消息，如果是，则可以重新启动其TC消息调度。或者，路由器可以在其地址块中发送至少具有新公布的网络地址（即，不是以前，而是现在，N_orig_addr或在N_advised=true或AL_net_addr的邻居元组中的N_neighbor_addr_列表中）的不完整TC消息，以及相关联的地址块TLV。请注意，路由器无法使用不完整的TC消息报告广告内容的删除。
When sending a TC message in response to a change of advertised network addresses, a router MUST respect a minimum interval of TC_MIN_INTERVAL between sending TC messages (complete or incomplete) and a maximum interval of TC_INTERVAL between sending complete TC messages. Thus, a router MUST NOT send an incomplete TC message if within TC_MIN_INTERVAL of the next scheduled time to send a complete TC message.
当发送TC消息以响应公布网络地址的变化时，路由器必须遵守发送TC消息（完整或不完整）之间的最小间隔TC_MIN_interval和发送完整TC消息之间的最大间隔TC_interval。因此，如果在发送完整TC消息的下一个预定时间的TC_MIN_间隔内，路由器不得发送不完整的TC消息。
The generation of TC messages, whether scheduled or triggered by a change of contents, MAY be jittered as described in [RFC5148]. The values of MAXJITTER used MUST be:
TC消息的生成，无论是计划的还是由内容更改触发的，都可能会如[RFC5148]中所述发生抖动。使用的MAXJITTER值必须为：
o TP_MAXJITTER for periodic TC message generation;
o TP_MAXJITTER用于周期性TC消息生成；
o TT_MAXJITTER for responsive TC message generation.
o TT_MAXJITTER用于响应TC消息生成。
On receiving a TC message on an OLSRv2 interface, the receiving router MUST then follow the processing and forwarding procedures defined in Section 14.
在OLSRv2接口上接收TC消息时，接收路由器必须遵循第14节中定义的处理和转发程序。
If the message is considered for processing (Section 14.2), then a router MUST first check if the message is invalid for processing by this router, as defined in Section 16.3.1. A router MAY make a similar check before considering a message for forwarding; it MUST check the aspects that apply to elements in the Message Header.
如果考虑处理该消息（第14.2节），则路由器必须首先检查该消息是否对该路由器的处理无效，如第16.3.1节所定义。路由器可以在考虑转发消息之前进行类似的检查；它必须检查应用于消息头中元素的方面。
If the TC message is not invalid, then the processing specific to TC Message Type, described in Section 16.3.2, MUST be applied. This will update its appropriate Interface Information Bases and its Router Information Base. Following this, if there are any changes in these Information Bases, then the processing in Section 17 MUST be performed.
如果TC消息不是无效的，则必须应用第16.3.2节中描述的特定于TC消息类型的处理。这将更新其相应的接口信息库和路由器信息库。在此之后，如果这些信息库中有任何变化，则必须执行第17节中的处理。
A received TC message is invalid for processing by this router if the message:
如果收到的TC消息：
o Has an address length specified in the Message Header that is not equal to the length of the addresses used by this router.
o 消息头中指定的地址长度不等于此路由器使用的地址长度。
o Does not include a message originator address and a message sequence number.
o 不包括消息发起人地址和消息序列号。
o Does not include a hop count and contains a multi-value TLV with Type = VALIDITY_TIME or Type = INTERVAL_TIME, as defined in [RFC5497].
o 不包括跃点计数，并包含类型=有效性\时间或类型=间隔\时间的多值TLV，如[RFC5497]中所定义。
o Does not have exactly one Message TLV with Type = VALIDITY_TIME.
o 没有一条类型为有效性\时间的消息TLV。
o Has more than one Message TLV with Type = INTERVAL_TIME.
o 具有多个类型为INTERVAL\u TIME的消息TLV。
o Does not have a Message TLV with Type = CONT_SEQ_NUM and Type Extension = COMPLETE or Type Extension = INCOMPLETE and contains at least one address object associated with an Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY.
o 没有类型为CONT_SEQ_NUM且类型扩展名为COMPLETE或类型扩展名为COMPLETE的消息TLV，并且至少包含一个与类型为NBR_ADDR_Type或类型为GATEWAY的地址块TLV关联的地址对象。
o Has more than one Message TLV with Type = CONT_SEQ_NUM and Type Extension = COMPLETE or Type Extension = INCOMPLETE.
o 具有多个类型为CONT_SEQ_NUM且类型扩展名为COMPLETE或类型扩展名为COMPLETE的消息TLV。
o Has a message originator address that is partially owned by this router.
o 具有此路由器部分拥有的消息发起人地址。
o Includes any address object with a prefix length that is not maximal (equal to the address length, in bits), associated with an Address Block TLV with Type = NBR_ADDR_TYPE and Value = ORIGINATOR or Value = ROUTABLE_ORIG.
o 包括前缀长度不是最大（等于地址长度，以位为单位）的任何地址对象，该地址对象与类型为NBR\U ADDR\U Type且值为发起者或值为可路由源的地址块TLV关联。
o Includes any address object that represents a non-routable address, associated with an Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE or Value = ROUTABLE_ORIG.
o 包括表示不可路由地址的任何地址对象，该地址对象与类型为NBR\U ADDR\U Type且值为routable或值为routable\U ORIG的地址块TLV关联。
o Includes any address object associated with an Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY that also represents the message's originator address.
o 包括与类型为NBR\U ADDR\U Type或类型为GATEWAY的地址块TLV关联的任何地址对象，该地址块TLV还表示邮件的原始发件人地址。
o Includes any address object (including different copies of an address object in the same or different Address Blocks) that is associated with an Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY that is also associated with more than one outgoing neighbor metric using a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE.
o 包括与Type=NBR\u ADDR\u Type或Type=GATEWAY的地址块TLV关联的任何地址对象（包括相同或不同地址块中地址对象的不同副本），该地址块TLV还使用Type=LINK\u metric和Type Extension=LINK\u metric\u Type的TLV与多个传出邻居度量关联。
o Associates any address object (including different copies of an address object in the same or different Address Blocks) with more than one single hop count value using one or more Address Block TLV(s) with Type = GATEWAY.
o 使用一个或多个地址块TLV将任何地址对象（包括相同或不同地址块中地址对象的不同副本）与多个单跳计数值关联，类型=网关。
o Associates any address object (including different copies of an address object in the same or different Address Blocks) with Address Block TLVs with Type = NBR_ADDR_TYPE and Type = GATEWAY.
o 将任何地址对象（包括相同或不同地址块中地址对象的不同副本）与类型为NBR\U ADDR\U Type且类型为GATEWAY的地址块TLV相关联。
A router MAY recognize additional reasons for identifying that a message is invalid. An invalid message MUST be silently discarded, without updating the router's Information Bases.
路由器可以识别识别消息无效的其他原因。无效消息必须以静默方式丢弃，而不更新路由器的信息库。
Note that a router that acts inconsistently, for example, rejecting TC messages "at random", may cause parts of the network to not be able to communicate with other parts of the network. It is RECOMMENDED that such "additional reasons for identifying that a message is invalid" be a consistent network-wide policy (e.g., as part of a security policy), implemented on all participating routers.
请注意，行为不一致的路由器（例如，“随机”拒绝TC消息）可能会导致网络部分无法与网络其他部分通信。建议在所有参与路由器上实施一致的网络范围策略（例如，作为安全策略的一部分），“确定消息无效的其他原因”。
When, according to Section 14.2, a TC message is to be "processed according to its type", this means that:
根据第14.2节，当TC报文“根据其类型进行处理”时，这意味着：
o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM and Type Extension = COMPLETE, then processing according to Section 16.3.3 and then according to Section 16.3.4 is carried out.
o 如果TC消息包含类型为CONT_SEQ_NUM且类型扩展为COMPLETE的消息TLV，则根据第16.3.3节和第16.3.4节进行处理。
o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM and Type Extension = INCOMPLETE, then only processing according to Section 16.3.3 is carried out.
o 如果TC消息包含类型为CONT_SEQ_NUM且类型扩展名为complete的消息TLV，则仅执行第16.3.3节规定的处理。
For the purposes of the TC message processing in Section 16.3.3 and Section 16.3.4:
对于第16.3.3节和第16.3.4节中的TC消息处理：
o "validity time" is calculated from a VALIDITY_TIME Message TLV in the TC message according to the specification in [RFC5497]. All information in the TC message has the same validity time.
o 根据[RFC5497]中的规范，根据TC消息中的有效时间消息TLV计算“有效时间”。TC报文中的所有信息具有相同的有效期。
o "received ANSN" is defined as being the value of a Message TLV with Type = CONT_SEQ_NUM.
o “接收到的ANSN”定义为类型为CONT_SEQ_NUM的消息TLV的值。
o "associated metric value" is defined for any address in the TC message as being either the outgoing neighbor metric value indicated by a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that is associated with any address object in the TC message that is equal to that address or as UNKNOWN_METRIC otherwise. (Note that the rules in Section 16.3.1 make this definition unambiguous.)
o 对于TC消息中的任何地址，“关联度量值”定义为TLV指示的传出邻居度量值，该TLV的类型=LINK\u metric，类型扩展=LINK\u metric\u Type与TC消息中与该地址相等的任何地址对象关联，否则定义为未知\u metric。（请注意，第16.3.1节中的规则明确了该定义。）
o Comparisons of sequence numbers are carried out as specified in Section 21.
o 按照第21节的规定对序列号进行比较。
The TC message is processed as follows:
TC消息的处理如下所示：
1. The Advertising Remote Router Set is updated according to Section 16.3.3.1. If the TC message is indicated as discarded in that processing, then the following steps are not carried out.
1. 根据第16.3.3.1节更新广告远程路由器集。如果TC消息在该处理中被指示为已丢弃，则不执行以下步骤。
2. The Router Topology Set is updated according to Section 16.3.3.2.
2. 路由器拓扑集根据第16.3.3.2节进行更新。
3. The Routable Address Topology Set is updated according to Section 16.3.3.3.
3. 可路由地址拓扑集根据第16.3.3.3节进行更新。
4. The Attached Network Set is updated according to Section 16.3.3.4.
4. 根据第16.3.3.4节更新连接的网络集。
The router MUST update its Advertising Remote Router Set as follows:
路由器必须更新其广告远程路由器集，如下所示：
1. If there is an Advertising Remote Router Tuple with:
1. 如果存在具有以下内容的广告远程路由器元组：
* AR_orig_addr = message originator address; AND
* AR_orig_addr=消息发起人地址；和
* AR_seq_number > received ANSN,
* 应收序号>收到的ANSN，
then the TC message MUST be discarded.
然后必须丢弃TC消息。
2. Otherwise:
2. 否则：
1. If there is no Advertising Remote Router Tuple such that:
1. 如果没有广告远程路由器元组，则：
+ AR_orig_addr = message originator address;
+ AR_orig_addr=消息发起人地址；
then create an Advertising Remote Router Tuple with:
然后使用以下内容创建广告远程路由器元组：
+ AR_orig_addr := message originator address.
+ AR_orig_addr:=消息发起人地址。
2. This Advertising Remote Router Tuple (existing or new) is then modified as follows:
2. 然后将此远程路由器元组（现有或新）修改如下：
+ AR_seq_number := received ANSN;
+ 应收序号：=收到的ANSN；
+ AR_time := current time + validity time.
+ 应收账款时间：=当前时间+有效期时间。
The router MUST update its Router Topology Set as follows:
路由器必须更新其路由器拓扑集，如下所示：
1. For each address (henceforth, advertised address) that corresponds to one or more address objects with an associated Address Block TLV with Type = NBR_ADDR_TYPE and Value = ORIGINATOR or Value = ROUTABLE_ORIG and that is not partially owned by this router, perform the following processing:
1. 对于与一个或多个地址对象相对应且具有类型为NBR\U ADDR\U Type且值为发起者或值为可路由\U ORIG的关联地址块TLV且不部分归此路由器所有的每个地址（此后称为播发地址），执行以下处理：
1. If the associated metric is UNKNOWN_METRIC, then remove any Router Topology Tuple such that:
1. 如果关联的度量为未知度量，则删除任何路由器拓扑元组，以便：
+ TR_from_orig_addr = message originator address; AND
+ TR_from_orig_addr=消息发起人地址；和
+ TR_to_orig_addr = advertised address.
+ TR_to_orig_addr=广告地址。
2. Otherwise, if there is no Router Topology Tuple such that:
2. 否则，如果没有路由器拓扑元组，则：
+ TR_from_orig_addr = message originator address; AND
+ TR_from_orig_addr=消息发起人地址；和
+ TR_to_orig_addr = advertised address,
+ TR_to_orig_addr=广告地址，
then create a new Router Topology Tuple with:
然后使用以下内容创建新的路由器拓扑元组：
+ TR_from_orig_addr := message originator address;
+ TR_from_orig_addr:=消息发起人地址；
+ TR_to_orig_addr := advertised address.
+ TR_to_orig_addr:=广告地址。
3. This Router Topology Tuple (existing or new) is then modified as follows:
3. 该路由器拓扑元组（现有或新）随后修改如下：
+ TR_seq_number := received ANSN;
+ TR序列号：=收到的ANSN；
+ TR_metric := associated link metric;
+ TR_度量：=关联链路度量；
+ TR_time := current time + validity time.
+ TR_时间：=当前时间+有效时间。
The router MUST update its Routable Address Topology Set as follows:
路由器必须更新其可路由地址拓扑集，如下所示：
1. For each network address (henceforth, advertised address) that corresponds to one or more address objects with an associated Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE or Value = ROUTABLE_ORIG and that is not partially owned by this router, perform the following processing:
1. 对于与一个或多个地址对象相对应的每个网络地址（此后称为播发地址），该地址对象具有类型为NBR\U ADDR\U Type且值为ROUTABLE或值为ROUTABLE\U ORIG的关联地址块TLV，且该地址不部分归该路由器所有，请执行以下处理：
1. If the associated metric is UNKNOWN_METRIC, then remove any Routable Address Topology Tuple such that:
1. 如果关联的度量为未知度量，则删除任何可路由地址拓扑元组，以便：
+ TA_from_orig_addr = message originator address; AND
+ TA_from_orig_addr=消息发起人地址；和
+ TA_dest_addr = advertised address.
+ TA_dest_addr=广告地址。
2. Otherwise, if there is no Routable Address Topology Tuple such that:
2. 否则，如果不存在可路由地址拓扑元组，则：
+ TA_from_orig_addr = message originator address; AND
+ TA_from_orig_addr=消息发起人地址；和
+ TA_dest_addr = advertised address,
+ TA_dest_addr=广告地址，
then create a new Routable Address Topology Tuple with:
然后使用以下内容创建新的可路由地址拓扑元组：
+ TA_from_orig_addr := message originator address;
+ TA_from_orig_addr:=消息发起人地址；
+ TA_dest_addr := advertised address.
+ TA_dest_addr:=广告地址。
3. This Routable Address Topology Tuple (existing or new) is then modified as follows:
3. 然后，将此可路由地址拓扑元组（现有或新）修改如下：
+ TA_seq_number := received ANSN;
+ TA序列号：=收到的ANSN；
+ TA_metric := associated link metric;
+ TA_度量：=关联链路度量；
+ TA_time := current time + validity time.
+ TA_时间：=当前时间+有效时间。
The router MUST update its Attached Network Set as follows:
路由器必须更新其连接的网络集，如下所示：
1. For each network address (henceforth, attached address) that corresponds to one or more address objects with an associated Address Block TLV with Type = GATEWAY and that is not fully owned by this router, perform the following processing:
1. 对于与一个或多个地址对象相对应的每个网络地址（此后称为附加地址），该地址对象具有类型为GATEWAY的关联地址块TLV，且不完全归该路由器所有，请执行以下处理：
1. If the associated metric is UNKNOWN_METRIC, then remove any Attached Network Tuple such that:
1. 如果关联的度量为未知度量，则删除任何附加的网络元组，以便：
+ AN_net_addr = attached address; AND
+ a_net_addr=附加地址；和
+ AN_orig_addr = message originator address.
+ a_orig_addr=消息发起人地址。
2. Otherwise, if there is no Attached Network Tuple such that:
2. 否则，如果没有连接的网络元组，则：
+ AN_net_addr = attached address; AND
+ a_net_addr=附加地址；和
+ AN_orig_addr = message originator address,
+ a_orig_addr=消息发起人地址，
then create a new Attached Network Tuple with:
然后使用以下内容创建新的连接网络元组：
+ AN_net_addr := attached address;
+ 地址：=附加地址；
+ AN_orig_addr := message originator address.
+ 原始地址：=消息发起人地址。
3. This Attached Network Tuple (existing or new) is then modified as follows:
3. 然后将此附加的网络元组（现有或新）修改如下：
+ AN_seq_number := received ANSN;
+ 序号：=接收到的ANSN；
+ AN_dist := the Value of the associated GATEWAY TLV;
+ AN_dist:=关联网关TLV的值；
+ AN_metric := associated link metric;
+ a_度量：=关联的链路度量；
+ AN_time := current time + validity time.
+ AN_时间：=当前时间+有效时间。
The TC message is processed as follows:
TC消息的处理如下所示：
1. The Router Topology Set is updated according to Section 16.3.4.1.
1. 路由器拓扑集根据第16.3.4.1节进行更新。
2. The Routable Address Topology Set is updated according to Section 16.3.4.2.
2. 可路由地址拓扑集根据第16.3.4.2节进行更新。
3. The Attached Network Set is updated according to Section 16.3.4.3.
3. 根据第16.3.4.3节更新连接的网络集。
The Router Topology Set MUST be updated as follows:
必须按如下方式更新路由器拓扑集：
1. Any Router Topology Tuples with:
1. 任何路由器拓扑元组具有：
* TR_from_orig_addr = message originator address; AND
* TR_from_orig_addr=消息发起人地址；和
* TR_seq_number < received ANSN,
* TR序列号<收到的ANSN，
MUST be removed.
必须删除。
The Routable Address Topology Set MUST be updated as follows:
必须按如下方式更新可路由地址拓扑集：
1. Any Routable Address Topology Tuples with:
1. 具有以下内容的任何可路由地址拓扑元组：
* TA_from_orig_addr = message originator address; AND
* TA_from_orig_addr=消息发起人地址；和
* TA_seq_number < received ANSN,
* TA序列号<收到的ANSN，
MUST be removed.
必须删除。
The Attached Network Set MUST be updated as follows:
必须按以下方式更新连接的网络集：
1. Any Attached Network Tuples with:
1. 任何连接的网络元组具有：
* AN_orig_addr = message originator address; AND
* a_orig_addr=消息发起人地址；和
* AN_seq_number < received ANSN,
* 序列号<接收到的ANSN，
MUST be removed.
必须删除。
The changes described in the following sections MUST be carried out when any Information Base changes as indicated.
当任何信息库发生如图所示的更改时，必须执行以下章节中描述的更改。
If the router changes its originator address, then:
如果路由器更改其发起者地址，则：
1. If there is no Originator Tuple with:
1. 如果没有具有以下内容的发起人元组：
* O_orig_addr = old originator address
* O_orig_addr=原发起人地址
then create an Originator Tuple with:
然后使用以下内容创建一个发起人元组：
* O_orig_addr := old originator address
* O_orig_addr:=原发起人地址
The Originator Tuple (existing or new) with:
具有以下内容的发起人元组（现有或新）：
* O_orig_addr = new originator address
* O_orig_addr=新的发起人地址
is then modified as follows:
然后修改如下：
* O_time := current time + O_HOLD_TIME
* O_时间：=当前时间+O_保持时间
The consistency of a Link Tuple MUST be maintained according to the following rules, in addition to those in [RFC6130]:
除了[RFC6130]中的规则外，还必须根据以下规则维护链接元组的一致性：
o If L_status = HEARD or L_status = SYMMETRIC, then L_in_metric MUST be set (by a process outside this specification).
o 如果L_status=hear或L_status=SYMMETRIC，则必须设置L_in_度量（通过本规范之外的过程）。
o If L_status != SYMMETRIC, then set L_mpr_selector := false.
o 如果L_状态！=对称，然后设置L_mpr_选择器：=false。
o If L_out_metric = UNKNOWN_METRIC, then L_status MUST NOT equal SYMMETRIC; set L_SYM_time := EXPIRED if this would otherwise be the case.
o 如果L_out_metric=未知_metric，则L_状态不得等于对称；设置L_SYM_time:=如果不是这样，则过期。
The consistency of a Neighbor Tuple MUST be maintained according to the following rules, in addition to those in [RFC6130]:
除[RFC6130]中的规则外，必须根据以下规则维护相邻元组的一致性：
1. If N_symmetric = true, then N_in_metric MUST equal the minimum value of all L_in_metric of corresponding Link Tuples with L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC. If there are no such Link Tuples, then N_in_metric MUST equal UNKNOWN_METRIC.
1. 如果N_symmetric=true，则N_in_度量必须等于具有L_status=symmetric和L_in_度量！=未知度量。如果没有这样的链接元组，那么N_in_度量必须等于UNKNOWN_度量。
2. If N_symmetric = true, then N_out_metric MUST equal the minimum value of all L_out_metric of corresponding Link Tuples with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC. If there are no such Link Tuples, then N_out_metric MUST equal UNKNOWN_METRIC.
2. 如果N_symmetric=true，则N_out_metric必须等于具有L_status=symmetric和L_out_metric！=未知度量。如果没有这样的链接元组，那么N_out_度量必须等于UNKNOWN_度量。
3. If N_symmetric = false, then N_flooding_mpr, N_routing_mpr, N_mpr_selector, and N_advertised MUST all be equal to false.
3. 如果N_symmetric=false，则N_flooding\u mpr、N_routing\u mpr、N_mpr\u selector和N_advised都必须等于false。
4. If N_mpr_selector = true, then N_advertised MUST be equal to true.
4. 如果N_mpr_selector=true，则N_advised必须等于true。
5. If N_symmetric = true, N_out_metric != UNKNOWN_METRIC and N_mpr_selector = false, then a router MAY select N_advertised = true or N_advertised = false. The more neighbors that are advertised, the larger TC messages become, but the more redundancy is available for routing. A router SHOULD consider the nature of its network in making such a decision and SHOULD avoid unnecessary changes in advertising status, which may result in unnecessary changes to routing.
5. 如果N_symmetric=true，则N_out_metric！=未知度量和N_mpr_选择器=false，则路由器可以选择N_广告=true或N_广告=false。播发的邻居越多，TC消息越大，但路由可用的冗余越多。路由器应该考虑其网络的性质来做出这样的决定，并且应该避免不必要的广告状态改变，这可能导致路由的不必要的改变。
The router MUST increment the ANSN in the Neighbor Information Base whenever:
路由器必须在以下情况下增加邻居信息库中的ANSN：
1. Any Neighbor Tuple changes its N_advertised value, or any Neighbor Tuple with N_advertised = true is removed.
1. 任何邻居元组都会更改其N_播发值，或者删除任何N_播发=true的邻居元组。
2. Any Neighbor Tuple with N_advertised = true changes its N_orig_addr or has any routable address added to or removed from N_neighbor_addr_list.
2. 任何N_advised=true的邻居元组都会更改其N_orig_addr，或者在N_Neighbor_addr_列表中添加或删除任何可路由地址。
3. Any Neighbor Tuple with N_advertised = true has N_out_metric changed.
3. N_advised=true的任何相邻元组的N_out_度量都已更改。
4. There is any change to the Local Attached Network Set.
4. 本地连接的网络集有任何更改。
The Router Topology Set, the Routable Address Topology Set, and the Attached Network Set MUST be changed when an Advertising Remote Router Tuple expires (AR_time is reached). The following changes are required before the Advertising Remote Router Tuple is removed:
当广告远程路由器元组过期（达到AR_时间）时，必须更改路由器拓扑集、可路由地址拓扑集和连接的网络集。删除播发远程路由器元组之前，需要进行以下更改：
1. All Router Topology Tuples with:
1. 所有路由器拓扑元组具有：
* TR_from_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple
* TR_from_orig_addr=广告远程路由器元组的AR_orig_addr
are removed.
被移除。
2. All Routable Address Topology Tuples with:
2. 具有以下内容的所有可路由地址拓扑元组：
* TA_from_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple
* TA_from_orig_addr=广告远程路由器元组的AR_orig_addr
are removed.
被移除。
3. All Attached Network Tuples with:
3. 所有连接的网络元组具有：
* AN_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple
* a_orig_addr=广告远程路由器元组的AR_orig_addr
are removed.
被移除。
The sets of symmetric 1-hop neighbors selected as flooding MPRs and routing MPRs MUST satisfy the conditions defined in Section 18. To ensure this:
选择作为泛洪MPR和路由MPR的对称1跳邻居集必须满足第18节中定义的条件。为确保这一点：
1. The set of flooding MPRs of a router MUST be recalculated if:
1. 在以下情况下，必须重新计算路由器的泛洪MPR集：
* A Link Tuple is added with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC; OR
* 添加一个链接元组，其中L_status=对称，L_out_metric！=未知度量；或
* A Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC is removed; OR
* L_status=对称且L_out_度量！=删除未知的_度量；或
* A Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC changes to having L_status = HEARD, L_status = LOST, or L_out_metric = UNKNOWN_METRIC; OR
* L_status=对称且L_out_度量！=未知度量更改为L_状态=听到，L_状态=丢失，或L_输出度量=未知度量；或
* A Link Tuple with L_status = HEARD or L_status = LOST changes to having L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC; OR
* L_status=hear或L_status=LOST的链接元组更改为L_status=SYMMETRIC和L_out_metric！=未知度量；或
* The flooding MPR selection process uses metric values (see Section 18.4) and the L_out_metric of any Link Tuple with L_status = SYMMETRIC changes; OR
* 泛洪MPR选择过程使用度量值（见第18.4节）和L_状态=对称更改的任何链接元组的L_out_度量；或
* The N_will_flooding of a Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC changes from WILL_NEVER to any other value; OR
* N_将对N_symmetric=true和N_out_metric！=未知度量从WILL\u NEVER更改为任何其他值；或
* The N_will_flooding of a Neighbor Tuple with N_flooding_mpr = true changes to WILL_NEVER from any other value; OR
* N_will_对相邻元组的泛洪，N_flooding_mpr=从任何其他值到will_的真实更改；或
* The N_will_flooding of a Neighbor Tuple with N_symmetric = true, N_out_metric != UNKNOWN_METRIC, and N_flooding_mpr = false changes to WILL_ALWAYS from any other value; OR
* N_将对N_symmetric=true，N_out_metric！=未知度量，N\u flooding\u mpr=从任何其他值对WILL\u的错误更改；或
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC is added or removed; OR
* 具有N2_out_度量的两跳元组！=添加或删除未知的_度量；或
* The N2_out_metric of any 2-Hop Tuple changes and either the flooding MPR selection process uses metric values (see Section 18.4) or the change is to or from UNKNOWN_METRIC.
* 任何2跳元组的N2_out_度量发生变化，泛洪MPR选择过程使用度量值（参见第18.4节），或者更改为未知_度量或来自未知_度量。
2. Otherwise, the set of flooding MPRs of a router MAY be recalculated if the N_will_flooding of a Neighbor Tuple with N_symmetric = true changes in any other way; it SHOULD be recalculated if N_flooding_mpr = false and this is an increase in N_will_flooding or if N_flooding_mpr = true and this is a decrease in N_will_flooding.
2. 否则，如果N_将以任何其他方式对N_symmetric＝true的邻居元组进行N_泛洪，则可以重新计算路由器的泛洪mpr集合；如果N_flooding_mpr=false，这是N_will_flooding的增加，或者如果N_flooding_mpr=true，这是N_will_flooding的减少，则应重新计算。
3. The set of routing MPRs of a router MUST be recalculated if:
3. 在以下情况下，必须重新计算路由器的路由MPR集：
* A Neighbor Tuple is added with N_symmetric = true and N_in_metric != UNKNOWN_METRIC; OR
* 使用N_symmetric=true和N_in_metric！=未知度量；或
* A Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC is removed; OR
* N_对称=真且N_in_度量！=删除未知的_度量；或
* A Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC changes to having N_symmetric = false; OR
* N_对称=真且N_in_度量！=未知度量更改为N_对称=false；或
* A Neighbor Tuple with N_symmetric = false changes to having N_symmetric = true and N_in_metric != UNKNOWN_METRIC; OR
* N_symmetric=false的相邻元组更改为N_symmetric=true和N_in_metric！=未知度量；或
* The N_in_metric of any Neighbor Tuple with N_symmetric = true changes; OR
* N_对称=真变化的任何相邻元组的N_in_度量；或
* The N_will_routing of a Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC changes from WILL_NEVER to any other value; OR
* N_将路由N_对称=真且N_in_度量！=未知度量从WILL\u NEVER更改为任何其他值；或
* The N_will_routing of a Neighbor Tuple with N_routing_mpr = true changes to WILL_NEVER from any other value; OR
* 相邻元组的N_will_路由，N_routing_mpr=从任何其他值更改为will_NEVER；或
* The N_will_routing of a Neighbor Tuple with N_symmetric = true, N_in_metric != UNKNOWN_METRIC and N_routing_mpr = false changes to WILL_ALWAYS from any other value; OR
* N_将对N_symmetric=true，N_in_metric！=未知度量和N\u路由\u mpr=从任何其他值对WILL\u的错误更改；或
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC is added or removed; OR
* 具有N2_in_度量的两跳元组！=添加或删除未知的_度量；或
* The N2_in_metric of any 2-Hop Tuple changes.
* 任何2跳元组的N2_in_度量都会更改。
4. Otherwise, the set of routing MPRs of a router MAY be recalculated if the N_will_routing of a Neighbor Tuple with N_symmetric = true changes in any other way; it SHOULD be recalculated if N_routing_mpr = false and this is an increase in N_will_routing or if N_routing_mpr = true and this is a decrease in N_will_routing.
4. 否则，如果N_将以任何其他方式改变N_symmetric＝true的邻居元组的N_路由，则可以重新计算路由器的路由mpr集合；如果N_routing_mpr=false，这是N_will_routing的增加，或者如果N_routing_mpr=true，这是N_will_routing的减少，则应重新计算。
If either set of MPRs of a router is recalculated, this MUST be as described in Section 18.
如果重新计算路由器的任一组MPR，则必须如第18节所述。
The Routing Set MUST be updated, as described in Section 19, when changes in the Local Information Base, the Neighborhood Information Base, or the Topology Information Base indicate a change (including of any potentially used outgoing neighbor metric values) of the known symmetric links and/or attached networks in the MANET, hence changing the Topology Graph. It is sufficient to consider only changes that affect at least one of:
如第19节所述，当本地信息库、邻域信息库或拓扑信息库中的更改指示MANET中已知对称链路和/或连接网络的更改（包括任何潜在使用的传出邻居度量值）时，必须更新路由集，因此更改拓扑图。仅考虑影响至少一个的变化是足够的：
o The Local Interface Set for an OLSRv2 interface, if the change removes any network address in an I_local_iface_addr_list. In this case, unless the OLSRv2 interface is removed, it may not be necessary to do more than replace such network addresses, if used, by an alternative network address from the same I_local_iface_addr_list.
o 如果更改删除了I_Local_iface_addr_列表中的任何网络地址，则为OLSRv2接口设置的本地接口。在这种情况下，除非移除OLSRv2接口，否则可能只需将这些网络地址（如果使用）替换为同一I_local_iface_addr_列表中的替代网络地址即可。
o The Local Attached Set, if the change removes any AL_net_addr that is also an AN_net_addr. In this case, it may not be necessary to do more than add Routing Tuples with R_dest_addr equal to that AN_net_addr.
o 本地附加集，如果更改删除了任何也是an_net_addr的AL_net_addr。在这种情况下，可能只需要添加路由元组，其中R_dest_addr等于a_net_addr。
o The Link Set of any OLSRv2 interface, considering only Link Tuples that have, or just had, L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC (including removal of such Link Tuples).
o 任何OLSRv2接口的链接集，仅考虑具有或刚刚具有L_status=对称和L_out_度量的链接元组！=未知_度量（包括删除此类链接元组）。
o The Neighbor Set of the router, considering only Neighbor Tuples that have, or just had, N_symmetric = true and N_out_metric != UNKNOWN_METRIC and do not have N_orig_addr = unknown.
o 路由器的邻居集，仅考虑具有或刚刚具有N_symmetric=true和N_out_metric！=未知度量，并且没有N\u orig\u addr=未知。
o The 2-Hop Set of any OLSRv2 interface, if used in the creation of the Routing Set and if the change affects any 2-Hop Tuples with N2_out_metric != UNKNOWN_METRIC.
o 任何OLSRv2接口的2跳集，如果在创建路由集时使用，并且如果更改影响具有N2_out_度量的任何2跳元组！=未知度量。
o The Router Topology Set of the router.
o 路由器的路由器拓扑集。
o The Routable Address Topology Set of the router.
o 路由器的可路由地址拓扑集。
o The Attached Network Set of the router.
o 路由器的连接网络集。
Each router MUST select, from among its willing symmetric 1-hop neighbors, two subsets of these routers, as flooding and routing MPRs. This selection is recorded in the router's Neighbor Set and reported in the router's HELLO messages. Routers MAY select their MPRs by any process that satisfies the conditions that follow, which may, but need not, use the organization of the data described. Routers can freely interoperate whether they use the same or different MPR selection algorithms.
每个路由器必须从其自愿的对称1跳邻居中选择这些路由器的两个子集，作为泛洪和路由MPR。此选择记录在路由器的邻居集中，并在路由器的HELLO消息中报告。路由器可以通过满足以下条件的任何过程来选择其mpr，该过程可以但不必使用所描述的数据组织。路由器可以自由地进行互操作，无论它们使用相同或不同的MPR选择算法。
Only flooding MPRs forward control messages flooded through the MANET, thus effecting a flooding reduction, an optimization of the flooding mechanism, known as MPR flooding. Routing MPRs are used to effect a topology reduction in the MANET. (If no such reduction is required, then a router can select all of its relevant neighbors as routing MPRs.) Consequently, while it is not essential that these two sets of MPRs are minimal, keeping the numbers of MPRs small ensures that the overhead of this protocol is kept to a minimum.
只有泛洪MPR前向控制消息通过MANET泛洪，从而实现泛洪减少，这是对泛洪机制的优化，称为MPR泛洪。路由MPR用于减少MANET中的拓扑结构。（如果不需要这样的减少，那么路由器可以选择其所有相关的邻居作为路由mpr。）因此，虽然这两组mpr不一定是最小的，但保持mpr的数量小可以确保将该协议的开销保持在最小。
MPRs are selected according to the following steps, defined in the following sections:
MPR根据以下章节中定义的以下步骤进行选择：
o A data structure known as a Neighbor Graph is defined.
o 定义了称为邻居图的数据结构。
o The properties of an MPR Set derived from a Neighbor Graph are defined. Any algorithm that creates an MPR Set that satisfies these properties is a valid MPR selection algorithm. An example algorithm that creates such an MPR Set is given in Appendix B.
o 定义了由邻域图导出的MPR集的性质。任何创建满足这些属性的MPR集的算法都是有效的MPR选择算法。附录B中给出了创建此类MPR集的示例算法。
o How to create a Neighbor Graph for each interface based on the corresponding Interface Information Base is defined, and how to combine the resulting MPR Sets to determine the router's flooding MPRs and record those in the router's Neighbor Set are described.
o 定义了如何基于相应的接口信息库为每个接口创建一个邻居图，并描述了如何组合生成的MPR集来确定路由器的泛洪MPR并将其记录在路由器的邻居集中。
o How to create a single Neighbor Graph based on all Interface Information Bases and the Neighbor Information Base is defined, and how to record the resulting MPR Set as the router's routing MPRs in the router's Neighbor Set is described.
o 描述了如何基于所有接口信息库和邻居信息库创建单个邻居图，以及如何将生成的MPR集作为路由器的路由MPR记录在路由器的邻居集中。
o A specification as to when MPRs MUST be calculated is given.
o 给出了何时必须计算MPR的规范。
When a router selects its MPRs, it MAY consider any characteristics of its neighbors that it is aware of. In particular, it SHOULD consider the willingness of the neighbor, as recorded by the corresponding N_will_flooding or N_will_routing value, as appropriate, preferring neighbors with higher values. (Note that willingness values equal to WILL_NEVER and WILL_ALWAYS are always considered, as described.) However, a router MAY consider other characteristics to have a greater significance.
当路由器选择它的MPR时，它可以考虑它所知道的邻居的任何特性。特别是，它应该考虑邻居的意愿，如相应的N-WyRay-Pur淹y或N-Wyl路由选择值所记录的，适当地，优选具有较高值的邻居。（注意，意愿值总是等于Wray-No.and Wele-总是被考虑，如所描述的）然而，路由器可以考虑其他特征具有更大的意义。
Each router MAY select its flooding and routing MPRs independently of each other or coordinate its selections. A router MAY make its MPR selections independently of the MPR selection by other routers, or it MAY, for example, give preference to routers that either are, or are not, already selected as MPRs by other routers.
每个路由器可以彼此独立地选择其泛洪和路由mpr，或者协调其选择。路由器可以独立于其他路由器的MPR选择而进行其MPR选择，或者例如，它可以优先选择已经或没有被其他路由器选择为MPR的路由器。
A Neighbor Graph is a structure defined here as consisting of sets N1 and N2 and some associated metric and willingness values. Elements of set N1 represent willing symmetric 1-hop neighbors, and elements of set N2 represent addresses of a symmetric 2-hop neighbor.
邻域图是这里定义的一种结构，由集合N1和N2以及一些相关的度量值和意愿值组成。集合N1的元素表示对称1跳邻居，集合N2的元素表示对称2跳邻居的地址。
A Neighbor Graph has the following properties:
邻居图具有以下属性：
o It contains two disjoint sets N1 and N2.
o 它包含两个不相交的集合N1和N2。
o For each element x in N1, there is an associated willingness value W(x) such that WILL_NEVER < W(x) <= WILL_ALWAYS.
o 对于N1中的每个元素x，都有一个相关的意愿值W（x），使得永远不会<W（x）<=永远。
o For each element x in N1, there is an associated metric d1(x) > 0.
o 对于N1中的每个元素x，有一个相关的度量d1（x）>0。
o For some elements y in N2, there is an associated metric d1(y) > 0. (Other elements y in N2 have undefined d1(y); this may be considered to be infinite.)
o 对于N2中的某些元素y，有一个相关的度量d1（y）>0。（N2中的其他元素y具有未定义的d1（y）；这可能被认为是无限的。）
o For each element x in N1, there is a subset N2(x) of elements of N2; this subset may be empty. For each x in N1 and each y in N2(x), there is an associated metric d2(x,y) > 0. (For other x in N1 and y in N2, d2(x,y) is undefined and may be considered infinite.)
o 对于N1中的每个元素x，存在N2元素的子集N2（x）；此子集可能为空。对于N1中的每个x和N2（x）中的每个y，有一个关联的度量d2（x，y）>0。（对于N1中的其他x和N2中的y，d2（x，y）未定义，可以认为是无限的。）
o N2 is equal to the union of all the N2(x) for all x in N1, i.e., for each y in N2, there is at least one x in N1 such that y is in N2(x).
o N2等于N1中所有x的所有N2（x）的并集，即，对于N2中的每个y，N1中至少有一个x，使得y在N2（x）中。
It is convenient to also define:
还可以方便地定义：
o For each y in N2, the set N1(y) that contains x in N1 if and only if y is in N2(x). From the final property above, N1(y) is not empty.
o 对于N2中的每个y，当且仅当y在N2（x）中时，集合N1（y）中包含x。从上面的最后一个属性来看，N1（y）不是空的。
o For each x in N1 and y in N2, if d2(x,y) is defined, then d(x,y) := d1(x)+d2(x,y); otherwise, d(x,y) is not defined. (Thus, d(x,y) is defined if y is in N2(x) or, equivalently, if x is in N1(y).)
o 对于N1中的每个x和N2中的每个y，如果定义了d2（x，y），那么d（x，y）：=d1（x）+d2（x，y）；否则，不定义d（x，y）。（因此，如果y在N2（x）中或等效地，如果x在N1（y）中，则定义d（x，y）。）
o For any subset S of N1 and for each y in N2, the metric d(y,S) is the minimum value of d1(y), if defined, and of all d(x,y) for x in N1(y) and in S. If there are no such metrics to take the minimum value of, then d(y,S) is undefined (may be considered to be infinite). From the final property above, d(y,N1) is defined for all y.
o 对于N1的任何子集S和N2中的每个y，度量d（y，S）是d1（y）的最小值（如果定义），并且是N1（y）和S中x的所有d（x，y）的最小值。如果没有此类度量取最小值，则d（y，S）未定义（可以认为是无限的）。根据上面的最后一个属性，为所有y定义了d（y，N1）。
Given a Neighbor Graph as defined in Section 18.2, an MPR Set for that Neighbor Graph is a subset M of the set N1 that satisfies the following properties:
给定第18.2节中定义的相邻图，该相邻图的MPR集是满足以下属性的集合N1的子集M：
o If x in N1 has W(x) = WILL_ALWAYS, then x is in M.
o 如果N1中的x有W（x）=WILL_，那么x在M中。
o For any y in N2 that does not have a defined d1(y), there is at least one element in M that is also in N1(y). This is equivalent to the requirement that d(y,M) is defined.
o 对于N2中未定义d1（y）的任何y，M中至少有一个元素也位于N1（y）中。这相当于定义d（y，M）的要求。
o For any y in N2, d(y,M) = d(y,N1).
o 对于N2中的任何y，d（y，M）=d（y，N1）。
These properties reflect that the MPR Set consists of a set of symmetric 1-hop neighbors that cover all the symmetric 2-hop neighbors and that they do so retaining a minimum distance route (1-hop, if present, or 2-hop) to each symmetric 2-hop neighbor.
这些属性反映了MPR集由一组对称的1-hop邻居组成，这些邻居覆盖所有对称的2-hop邻居，并且它们保留到每个对称的2-hop邻居的最小距离路由（1-hop，如果存在，或2-hop）。
Note that if M is an MPR Set, then so is any subset of N1 that contains M; also note that N1 is always an MPR Set. An MPR Set may be empty but cannot be empty if N2 contains any elements y that do not have a defined d1(y).
注意，如果M是MPR集，那么包含M的N1的任何子集也是MPR集；还要注意，N1始终是MPR集。如果N2包含任何未定义d1（y）的元素y，则MPR集合可以为空，但不能为空。
Whenever flooding MPRs are to be calculated, an implementation MUST determine and record a set of flooding MPRs that is equivalent to one calculated as described in this section.
每当要计算泛洪MPR时，实施必须确定并记录一组泛洪MPR，该组泛洪MPR相当于按照本节所述计算的一组泛洪MPR。
The calculation of flooding MPRs need not use link metrics or, equivalently, may use link metrics with a fixed value, here taken to be 1. However, links with unknown metric (L_out_metric = UNKNOWN_METRIC) MUST NOT be used even if link metrics are otherwise not used.
泛洪MPR的计算不需要使用链路度量，或者等效地，可以使用具有固定值的链路度量，这里取为1。但是，即使未使用链路度量，也不得使用具有未知度量（L_out_metric=未知_metric）的链路。
Routers MAY make individual decisions as to whether to use link metrics for the calculation of flooding MPRs. A router MUST use the same approach to the choice of whether to use link metrics for all links, i.e., in the cases indicated by A or B, the same choice MUST be made in each case.
路由器可以单独决定是否使用链路度量来计算泛洪MPR。路由器必须使用相同的方法来选择是否对所有链路使用链路度量，即，在A或B指示的情况下，必须在每种情况下做出相同的选择。
For each OLSRv2 interface (the "current interface"), define a Neighbor Graph as defined in Section 18.2 according to the following:
对于每个OLSRv2接口（“当前接口”），根据以下内容定义第18.2节中定义的相邻图：
o Define a reachable Link Tuple to be a Link Tuple in the Link Set for the current interface with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC.
o 将可访问链接元组定义为当前接口的链接集中的链接元组，L_status=SYMMETRIC，L_out_metric！=未知度量。
o Define an allowed Link Tuple to be a reachable Link Tuple whose corresponding Neighbor Tuple has N_will_flooding > WILL_NEVER.
o 将允许的链接元组定义为其对应的邻居元组具有N_will_flooding>will_NEVER的可到达链接元组。
o Define an allowed 2-Hop Tuple to be a 2-Hop Tuple in the 2-Hop Set for the current interface for which N2_out_metric != UNKNOWN_METRIC and there is an allowed Link Tuple with L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.
o 将允许的2-Hop元组定义为当前接口的2-Hop集中的2-Hop元组，该接口的N2_out_metric！=未知度量，并且存在一个允许的链接元组，该元组的L\u neighbor\u iface\u addr\u list=N2\u neighbor\u iface\u addr\u list。
o Define an element of N1 for each allowed Link Tuple. This then defines the corresponding Link Tuple for each element of N1 and the corresponding Neighbor Tuple for each element of N1, being the Neighbor Tuple corresponding to that Link Tuple.
o 为每个允许的链接元组定义一个N1元素。然后，为N1的每个元素定义对应的链接元组，并为N1的每个元素定义对应的邻居元组，即对应于该链接元组的邻居元组。
o For each element x in N1, define W(x) := N_will_flooding of the corresponding Neighbor Tuple.
o 对于N1中的每个元素x，定义W（x）：=N\u将\u对应相邻元组的泛洪。
o For each element x in N1, define d1(x) as either:
o 对于N1中的每个元素x，将d1（x）定义为：
A. L_out_metric of the corresponding Link Tuple; OR
A.对应链接元组的L_out_度量；或
B. 1.
B.1。
o Define an element of N2 for each network address that is the N2_2hop_addr of one or more allowed 2-Hop Tuples. This then defines the corresponding address for each element of N2.
o 为每个网络地址定义一个N2元素，该地址是一个或多个允许的2跳元组的N2跳地址。然后为N2的每个元素定义相应的地址。
o For each element y in N2, if the corresponding address is in the N_neighbor_addr_list of a Neighbor Tuple that corresponds to one or more reachable Link Tuples, then define d1(y) as either:
o 对于N2中的每个元素y，如果对应的地址在对应于一个或多个可到达链路元组的邻居元组的N_neighbor_addr_列表中，则将d1（y）定义为：
A. the minimum value of the L_out_metric of those Link Tuples; OR
A.这些链接元组的L_out_度量的最小值；或
B. 1.
B.1。
Otherwise, d1(y) is not defined. In the latter case, where d1(y) := 1, all such y in N2 may instead be removed from N2.
否则，不定义d1（y）。在后一种情况下，其中d1（y）：=1，可以从N2中移除N2中的所有这样的y。
o For each element x in N1, define N2(x) as the set of elements y in N2 whose corresponding address is the N2_2hop_addr of an allowed 2-Hop Tuple that has N2_neighbor_iface_addr_list = L_neighbor_iface_addr_list of the Link Tuple corresponding to x. For all such x and y, define d2(x,y) as either:
o 对于N1中的每个元素x，将N2（x）定义为N2中的元素y的集合，其对应地址是允许的2跳元组的N2_2hop_addr，该元组具有与x对应的链接元组的N2_neighbor_iface_addr_list=L_neighbor_iface_addr_list。对于所有这些x和y，将d2（x，y）定义为：
A. N2_out_metric of that 2-Hop Tuple; OR
A.该2跳元组的N2_out_度量；或
B. 1.
B.1。
It is up to an implementation to decide how to label each element of N1 or N2. For example, an element of N1 may be labeled with one or more addresses from the corresponding L_neighbor_iface_addr_list or with a pointer or reference to the corresponding Link Tuple.
由实现决定如何标记N1或N2的每个元素。例如，N1的元素可以用来自相应的L_neighbor_iface_addr_列表的一个或多个地址或者用指向相应链接元组的指针或引用来标记。
Using these Neighbor Graphs, flooding MPRs are selected and recorded by:
使用这些相邻图，通过以下方式选择和记录泛洪MPR：
o For each OLSRv2 interface, determine an MPR Set as specified in Section 18.3.
o 对于每个OLSRv2接口，确定第18.3节中规定的MPR集。
o A Neighbor Tuple represents a flooding MPR and has N_flooding_mpr := true (otherwise, N_flooding_mpr := false) if and only if that Neighbor Tuple corresponds to an element in an MPR Set created for any interface as described above. That is, the overall set of flooding MPRs is the union of the sets of flooding MPRs for all OLSRv2 interfaces.
o 邻居元组表示泛洪MPR，并且当且仅当该邻居元组对应于为上述任何接口创建的MPR集中的元素时，其N_flooding_MPR:=true（否则，N_flooding_MPR:=false）。也就是说，整个泛洪MPR集是所有OLSRv2接口的泛洪MPR集的联合。
A router MAY select its flooding MPRs for each OLSRv2 interface independently, or it MAY coordinate its MPR selections across its OLSRv2 interfaces, as long as the required condition is satisfied for each OLSRv2 interface. One such coordinated approach is to process the OLSRv2 interfaces sequentially and, for each OLSRv2 interface, start with flooding MPRs selected (and not removable) if the neighbor has been already selected as an MPR for an OLSRv2 interface that has already been processed. The algorithm specified in Appendix B can be used in this way.
路由器可以独立地为每个OLSRv2接口选择其泛洪MPR，也可以跨其OLSRv2接口协调其MPR选择，只要每个OLSRv2接口满足所需条件。一种这样的协调方法是顺序处理OLSRv2接口，并且对于每个OLSRv2接口，如果邻居已经被选择为已经处理的OLSRv2接口的MPR，则从选择的泛洪MPR（且不可移动）开始。附录B中规定的算法可以这样使用。
Whenever routing MPRs are to be calculated, an implementation MUST determine and record a set of routing MPRs that is equivalent to one calculated as described in this section.
每当要计算路由MPR时，实现必须确定并记录一组路由MPR，该路由MPR相当于本节中所述的一组路由MPR。
Define a single Neighbor Graph as defined in Section 18.2 according to the following:
根据以下内容定义第18.2节中定义的单个相邻图：
o Define a reachable Neighbor Tuple to be a Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC.
o 将可到达的邻居元组定义为N_symmetric=true且N_in_metric！=未知度量。
o Define an allowed Neighbor Tuple to be a reachable Neighbor Tuple with N_will_routing > WILL_NEVER.
o 将允许的邻居元组定义为N_will_routing>will_NEVER的可访问邻居元组。
o Define an allowed 2-Hop Tuple to be a 2-Hop Tuple in the 2-Hop Set for any OLSRv2 interface with N2_in_metric != UNKNOWN_METRIC and for which there is an allowed Neighbor Tuple with N_neighbor_addr_list containing N2_neighbor_iface_addr_list.
o 对于任何具有N2_in_度量的OLSRv2接口，将允许的2-Hop元组定义为2-Hop集中的2-Hop元组！=未知的\度量，其允许的邻居元组具有包含N2\邻居\地址\列表的N\邻居\地址\列表。
o Define an element of N1 for each allowed Neighbor Tuple. This then defines the corresponding Neighbor Tuple for each element of N1.
o 为每个允许的邻居元组定义一个N1元素。然后为N1的每个元素定义相应的邻居元组。
o For each element x in N1, define W(x) := N_will_routing of the corresponding Neighbor Tuple.
o 对于N1中的每个元素x，定义W（x）：=N\u将\u路由对应的相邻元组。
o For each element x in N1, define d1(x) := N_in_metric of the corresponding Neighbor Tuple.
o 对于N1中的每个元素x，定义d1（x）：=N_in_度量对应的相邻元组。
o Define an element of N2 for each network address that is the N2_2hop_addr of one or more allowed 2-Hop Tuples. This then defines the corresponding address for each element of N2.
o 为每个网络地址定义一个N2元素，该地址是一个或多个允许的2跳元组的N2跳地址。然后为N2的每个元素定义相应的地址。
o For each element y in N2, if the corresponding address is in the N_neighbor_addr_list of a reachable Neighbor Tuple, then define d1(y) to be the N_in_metric of that Neighbor Tuple; otherwise, d1(y) is not defined.
o 对于N2中的每个元素y，如果对应的地址在可到达邻居元组的N_neighbor_addr_列表中，则将d1（y）定义为该邻居元组的N_in_度量；否则，不定义d1（y）。
o For each element x in N1, define N2(x) as the set of elements y in N2 whose corresponding address is the N2_2hop_addr of an allowed 2-Hop Tuple that has N2_neighbor_iface_addr_list contained in N_neighbor_addr_list of the Neighbor Tuple corresponding to x. For all such x and y, define d2(x,y) := N2_out_metric of that 2-Hop Tuple.
o 对于N1中的每个元素x，将N2（x）定义为N2中的元素y的集合，其对应地址是允许的2跳元组的N2_2hop_addr，该2跳元组的N2_neighbor_iface_addr_列表包含在对应于x的相邻元组的N_neighbor_addr_列表中。对于所有这样的x和y，定义d2（x，y）：=N2\u out\u该2跳元组的度量。
It is up to an implementation to decide how to label each element of N1 or N2. For example, an element of N1 may be labeled with one or more addresses from the corresponding N_neighbor_addr_list or with a pointer or reference to the corresponding Neighbor Tuple.
由实现决定如何标记N1或N2的每个元素。例如，N1的元素可以用来自相应的N_neighbor_addr_列表的一个或多个地址或者用指向相应的邻居元组的指针或引用来标记。
Using these Neighbor Graphs, routing MPRs are selected and recorded according to the following:
使用这些相邻图，根据以下内容选择并记录路由MPR：
o Determine an MPR Set as specified in Section 18.3.
o 确定第18.3节规定的MPR集。
o A Neighbor Tuple represents a routing MPR and has N_routing_mpr := true (otherwise, N_routing_mpr := false) if and only if that Neighbor Tuple corresponds to an element in the MPR Set created as described above.
o 当且仅当邻居元组对应于如上所述创建的MPR集中的元素时，邻居元组表示路由MPR，且具有N_routing_MPR:=true（否则，N_routing_MPR:=false）。
A router MUST recalculate each of its sets of MPRs whenever the currently selected set of MPRs does not still satisfy the required conditions. It MAY recalculate its MPRs if the current set of MPRs is still valid but could be more efficient. Sufficient conditions to recalculate a router's sets of MPRs are given in Section 17.6.
当当前选择的MPR集仍不满足要求的条件时，路由器必须重新计算其MPR集。如果当前MPR集仍然有效，但效率可能更高，则可以重新计算其MPR。第17.6节给出了重新计算路由器MPR集的充分条件。
The Routing Set of a router is populated with Routing Tuples that represent paths from that router to all destinations in the network. These paths are calculated based on the Network Topology Graph, which is constructed from information in the Information Bases, obtained via HELLO and TC message exchange.
路由器的路由集由表示从该路由器到网络中所有目的地的路径的路由元组填充。这些路径是基于网络拓扑图计算的，网络拓扑图是根据通过HELLO和TC消息交换获得的信息库中的信息构建的。
Changes to the Routing Set do not require any messages to be transmitted. The state of the Routing Set SHOULD, however, be reflected in the IP routing table by adding and removing entries from that routing table as appropriate. Only appropriate Routing Tuples (in particular only those that represent local links or paths to routable addresses) need be reflected in the IP routing table.
对路由集的更改不需要传输任何消息。但是，路由集的状态应该通过适当地从该路由表中添加和删除条目来反映在IP路由表中。IP路由表中只需要反映适当的路由元组（尤其是那些表示本地链接或可路由地址路径的元组）。
The Network Topology Graph is formed from information from the router's Local Interface Set, Link Sets for OLSRv2 interfaces, Neighbor Set, Router Topology Set, Routable Address Topology Set, and Attached Network Set. The Network Topology Graph MAY also use information from the router's 2-Hop Sets for OLSRv2 interfaces. The Network Topology Graph forms the router's topological view of the network in the form of a directed graph. Each edge in that graph has a metric value. The Network Topology Graph has a "backbone" (within which minimum total metric routes will be constructed) containing the following edges:
网络拓扑图由来自路由器的本地接口集、OLSRv2接口的链路集、邻居集、路由器拓扑集、可路由地址拓扑集和连接的网络集的信息构成。网络拓扑图还可以使用来自路由器的OLSRv2接口的2跳集的信息。网络拓扑图以有向图的形式形成路由器的网络拓扑视图。该图中的每条边都有一个度量值。网络拓扑图有一个“主干”（其中将构建最小总度量路由），包含以下边：
o Edges X -> Y for all possible Y, and one X per Y, such that:
o 所有可能Y的边X->Y，每个Y一个X，这样：
* Y is the N_orig_addr of a Neighbor Tuple; AND
* Y是相邻元组的N_orig_addr；和
* N_orig_addr is not unknown; AND
* N_orig_addr并非未知；和
* X is in the I_local_iface_addr_list of a Local Interface Tuple; AND
* X在本地接口元组的I_local_iface_addr_列表中；和
* There is a Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple and this Local Interface Tuple correspond to it. A network address from L_neighbor_iface_addr_list will be denoted R in this case.
* 有一个链接元组的L_status=对称，L_out_metric！=未知的_度量，使得此邻居元组和此本地接口元组对应于它。在这种情况下，来自L_neighbor_iface_addr_列表的网络地址将表示为R。
It SHOULD be preferred, where possible, to select R = Y and to select X from the Local Interface Tuple corresponding to the Link Tuple from which R was selected. The metric for such an edge is the corresponding N_out_metric.
在可能的情况下，最好选择R=Y，并从与从中选择R的链接元组对应的本地接口元组中选择X。此边的度量是相应的N_out_度量。
o All edges W -> U such that:
o 所有边W->U，以便：
* W is the TR_from_orig_addr of a Router Topology Tuple; AND
* W是路由器拓扑元组的TR_from_orig_addr；和
* U is the TR_to_orig_addr of the same Router Topology Tuple.
* U是同一路由器拓扑元组的TR_to_orig_addr。
The metric of such an edge is the corresponding TR_metric.
这样一条边的度量是对应的tru度量。
The Network Topology Graph is further "decorated" with the following edges. If a network address S, V, Z, or T equals a network address Y or W, then the edge terminating in the network address S, V, Z, or T MUST NOT be used in any path.
网络拓扑图进一步用以下边“修饰”。如果网络地址S、V、Z或T等于网络地址Y或W，则终止于网络地址S、V、Z或T的边缘不得用于任何路径。
o Edges X -> S for all possible S, and one X per S, such that:
o 所有可能的S的边X->S，每个S一个X，这样：
* S is in the N_neighbor_addr_list of a Neighbor Tuple; AND
* S在邻居元组的N_neighbor_addr_列表中；和
* X is in the I_local_iface_addr_list of a Local Interface Tuple; AND
* X在本地接口元组的I_local_iface_addr_列表中；和
* There is a Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple and this Local Interface Tuple correspond to it. A network address from L_neighbor_iface_addr_list will be denoted R in this case.
* 有一个链接元组的L_status=对称，L_out_metric！=未知的_度量，使得此邻居元组和此本地接口元组对应于它。在这种情况下，来自L_neighbor_iface_addr_列表的网络地址将表示为R。
It SHOULD be preferred, where possible, to select R = S and to select X from the Local Interface Tuple corresponding to the Link Tuple from which R was selected. The metric for such an edge is the corresponding N_out_metric.
在可能的情况下，最好选择R=S，并从与从中选择R的链接元组对应的本地接口元组中选择X。此边的度量是相应的N_out_度量。
o All edges W -> V such that:
o 所有边W->V，以便：
* W is the TA_from_orig_addr of a Routable Address Topology Tuple; AND
* W是可路由地址拓扑元组的TA_from_orig_addr；和
* V is the TA_dest_addr of the same Routable Address Topology Tuple.
* V是相同可路由地址拓扑元组的TA_dest_addr。
The metric for such an edge is the corresponding TA_metric.
此类边的度量是相应的TA_度量。
o All edges W -> T such that:
o 所有边W->T，以便：
* W is the AN_orig_addr of an Attached Network Tuple; AND
* W是附加网络元组的原始地址；和
* T is the AN_net_addr of the same Attached Network Tuple.
* T是同一连接网络元组的AN_net_addr。
The metric for such an edge is the corresponding AN_metric.
这种边的度量是对应的an_度量。
o (OPTIONAL) All edges Y -> Z such that:
o （可选）所有边Y->Z，以便：
* Z is a routable address and is the N2_2hop_addr of a 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC; AND
* Z是一个可路由地址，是一个2跳元组的N2跳地址，具有N2跳出度量！=未知度量；和
* Y is the N_orig_addr of the corresponding Neighbor Tuple; AND
* Y是对应的相邻元组的N_orig_addr；和
* This Neighbor Tuple has N_will_routing not equal to WILL_NEVER.
* 此邻居元组的N_will_路由不等于will_NEVER。
A path terminating with such an edge MUST NOT be used in preference to any other path. The metric for such an edge is the corresponding N2_out_metric.
以这样一条边终止的路径不得优先于任何其他路径使用。此边的度量是相应的N2_out_度量。
Any part of the Topology Graph that is not connected to a local network address X is not used. Only one selection X SHOULD be made from each I_local_iface_addr_list, and only one selection R SHOULD be made from any L_neighbor_iface_addr_list. All edges have a hop count of 1, except edges W -> T that have a hop count of the corresponding value of AN_dist.
不使用未连接到本地网络地址X的拓扑图的任何部分。每个I_local_iface_addr_列表只能选择一个X，任何L_neighbor_iface_addr_列表只能选择一个R。所有边的跃点计数均为1，但边W->T的跃点计数为对应的距离值。
The Routing Set MUST contain the shortest paths for all destinations from all local OLSRv2 interfaces using the Network Topology Graph. This calculation MAY use any algorithm, including any means of choosing between paths of equal total metric. (In the case of two paths of equal total metric but differing hop counts, the path with the lower hop count SHOULD be used.)
路由集必须包含使用网络拓扑图的所有本地OLSRv2接口的所有目的地的最短路径。该计算可以使用任何算法，包括在总度量相等的路径之间进行选择的任何方法。（如果两条路径的总度量相等，但跳数不同，则应使用跳数较低的路径。）
Using the notation of Section 19.1, initially "backbone" paths using only edges X -> Y and W -> U need be constructed (using a minimum distance algorithm). Then paths using only a final edge of the other types may be added. These MUST NOT replace backbone paths with the same destination (and paths terminating in an edge Y -> Z SHOULD NOT replace paths with any other form of terminating edge).
使用第19.1节的符号，最初只需要使用边X->Y和W->U构建“主干”路径（使用最小距离算法）。然后，可以添加仅使用其他类型的最终边的路径。这些路径不能用相同的目标替换主干路径（并且以Y->Z边终止的路径不应该用任何其他形式的终止边替换路径）。
Each path will correspond to a Routing Tuple. These will be of two types. The first type will represent single edge paths, of type X -> S or X -> Y, by:
每个路径将对应一个路由元组。这将有两种类型。第一种类型通过以下方式表示X->S或X->Y类型的单边路径：
o R_local_iface_addr := X;
o R_local_iface_addr:=X；
o R_next_iface_addr := R;
o R\u next\u iface\u addr:=R；
o R_dest_addr := S or Y;
o R_dest_addr:=S或Y；
o R_dist := 1;
o R_dist:=1；
o R_metric := edge metric,
o R_度量：=边度量，
where R is as defined in Section 19.1 for these types of edge.
其中R如第19.1节中对这些类型边缘的定义。
The second type will represent a multiple edge path, which will always have first edge of type X -> Y, and will have final edge of type W -> U, W -> V, W -> T, or Y -> Z. The Routing Tuple will be:
第二种类型将表示多条边路径，其第一条边的类型始终为X->Y，最后一条边的类型为W->U、W->V、W->T或Y->Z。路由元组将为：
o R_local_iface_addr := X;
o R_local_iface_addr:=X；
o R_next_iface_addr := Y;
o 下一个地址：=Y；
o R_dest_addr := U, V, T or Z;
o R_dest_addr:=U、V、T或Z；
o R_dist := the total hop count of all edges in the path;
o R_dist:=路径中所有边的总跳数；
o R_metric := the total metric of all edges in the path.
o R_metric:=路径中所有边的总度量。
Finally, Routing Tuples of the second type whose R_dest_addr is not routable MAY be discarded.
最后，第二种类型的路由元组（其R_dest_addr不可路由）可能会被丢弃。
An example algorithm for calculating the Routing Set of a router is given in Appendix C.
附录C给出了计算路由器路由集的示例算法。
This protocol uses all parameters defined in [RFC6130] and additional parameters defined in this specification. All but one (RX_HOLD_TIME) of these additional parameters are router parameters as defined in [RFC6130]. The proposed values of the additional parameters defined in the following sections are appropriate to the case where all parameters (including those defined in [RFC6130]) have a single value. Proposed values for parameters defined in [RFC6130] are given in that specification.
本协议使用[RFC6130]中定义的所有参数以及本规范中定义的其他参数。除一个（RX_保持时间）外，所有这些附加参数都是[RFC6130]中定义的路由器参数。以下章节中定义的附加参数的建议值适用于所有参数（包括[RFC6130]中定义的参数）具有单一值的情况。[RFC6130]中定义的参数的建议值在该规范中给出。
The following proposed values are based on experience with [RFC3626] deployments (such as documented in [McCabe]) and are considered typical. They can be changed to accommodate different deployment requirements -- for example, a network with capacity-limited network interfaces would be expected to use greater values for message intervals, whereas a highly mobile network would be expected to use lower values for message intervals. When determining these values, the constraints specified in Section 5 MUST be respected.
以下建议值基于[RFC3626]部署的经验（如[McCabe]中所述），被视为典型值。可以更改它们以适应不同的部署要求——例如，具有容量有限的网络接口的网络预期会使用更大的消息间隔值，而高度移动的网络预期会使用更低的消息间隔值。确定这些值时，必须遵守第5节中规定的约束条件。
Note that routers in a MANET need not all use the same set of parameters, and those parameters that are indicated as interface parameters need not be the same on all OLSRv2 interfaces of a single router.
注意，MANET中的路由器不需要全部使用相同的参数集，并且在单个路由器的所有OLSRv2接口上指示为接口参数的那些参数不需要相同。
o O_HOLD_TIME := 30 seconds
o O_保持时间：=30秒
o TC_INTERVAL := 5 seconds
o TC_间隔：=5秒
o TC_MIN_INTERVAL := TC_INTERVAL/4
o TC\U最小间隔：=TC\U间隔/4
o T_HOLD_TIME := 3 x TC_INTERVAL
o T\u保持时间：=3 x TC\u间隔
o A_HOLD_TIME := T_HOLD_TIME
o 保持时间：=保持时间
o RX_HOLD_TIME := 30 seconds
o 接收保持时间：=30秒
o P_HOLD_TIME := 30 seconds
o 保压时间：=30秒
o F_HOLD_TIME := 30 seconds
o F_保持时间：=30秒
o TP_MAXJITTER := HP_MAXJITTER
o TP_MAXJITTER:=HP_MAXJITTER
o TT_MAXJITTER := HT_MAXJITTER
o TT_MAXJITTER:=HT_MAXJITTER
o F_MAXJITTER := TT_MAXJITTER
o F_MAXJITTER:=TT_MAXJITTER
o TC_HOP_LIMIT := 255
o TC_跃点限制：=255
o WILL_FLOODING := WILL_DEFAULT
o WILL\u泛洪：=WILL\u默认值
o WILL_ROUTING := WILL_DEFAULT
o WILL\u路由：=WILL\u默认值
Sequence numbers are used in this specification for the purpose of discarding "old" information, i.e., messages received out of order. However, with a limited number of bits for representing sequence numbers, wraparound (in which the sequence number is incremented from the maximum possible value to zero) will occur. To prevent this from interfering with the operation of this protocol, the following MUST be observed when determining the ordering of sequence numbers.
在本规范中，序列号用于丢弃“旧”信息，即无序接收的消息。然而，对于表示序列号的有限位数，将发生换行（其中序列号从最大可能值增加到零）。为防止干扰本协议的操作，在确定序列号顺序时必须遵守以下规定。
The term MAXVALUE designates in the following one more than the largest possible value for a sequence number. For a 16-bit sequence number (like those defined in this specification), MAXVALUE is 65536.
术语MAXVALUE在下面一个中指定的值大于序列号的最大可能值。对于16位序列号（如本规范中定义的序列号），MAXVALUE为65536。
The sequence number S1 is said to be "greater than" the sequence number S2 if:
如果：
o S1 > S2 AND S1 - S2 < MAXVALUE/2, OR
o S1>S2和S1-S2<MAXVALUE/2，或
o S2 > S1 AND S2 - S1 > MAXVALUE/2
o S2>S1和S2-S1>MAXVALUE/2
When sequence numbers S1 and S2 differ by MAXVALUE/2, their ordering cannot be determined. In this case, which should not occur, either ordering may be assumed.
当序列号S1和S2相差MAXVALUE/2时，无法确定其顺序。在这种情况下，不应出现这种情况，可以假定这两种顺序。
Thus, when comparing two messages, it is possible -- even in the presence of wraparound -- to determine which message contains the most recent information.
因此，在比较两条消息时，甚至在存在wrapparound的情况下，也可以确定哪个消息包含最新的信息。
An extension to this protocol will need to interact with this specification and possibly also with [RFC6130]. This protocol is designed to permit such interactions, in particular:
本协议的扩展需要与本规范交互，也可能与[RFC6130]交互。本协议旨在允许此类交互，特别是：
o Through accessing, and possibly extending, the information in the Information Bases. All updates to the elements specified in this specification are subject to the normative constraints specified in [RFC6130] and Appendix A. Note that the processing specified in this document ensures that these constraints are satisfied.
o 通过访问并可能扩展信息库中的信息。本规范中规定的所有元素更新均受[RFC6130]和附录A中规定的规范约束。注意，本文件中规定的处理确保满足这些约束。
o Through accessing an outgoing message prior to it being transmitted over any OLSRv2 interface and adding information to it as specified in [RFC5444]. This MAY include Message TLVs and/or network addresses with associated Address Block TLVs. (Network addresses without new associated TLVs SHOULD NOT be added to
o 通过在通过任何OLSRv2接口传输前访问传出消息，并按照[RFC5444]中的规定向其添加信息。这可能包括消息tlv和/或具有相关地址块tlv的网络地址。（不应将没有新关联TLV的网络地址添加到
messages.) This may, for example, be to allow a security protocol, as suggested in Section 23, to add a TLV containing a cryptographic signature to the message.
例如，这可能是允许安全协议（如第23节所建议）向消息添加包含加密签名的TLV。
o Through accessing an incoming message and potentially discarding it prior to processing by this protocol. This may, for example, allow a security protocol, as suggested in Section 23, to perform verification of message signatures and prevent processing and/or forwarding of unverifiable messages by this protocol.
o 通过访问传入消息并在使用此协议进行处理之前可能将其丢弃。例如，这可以允许第23节中建议的安全协议执行消息签名的验证，并防止通过该协议处理和/或转发无法验证的消息。
o Through accessing an incoming message after it has been completely processed by this protocol. In particular, this may allow a protocol that has added information, by way of inclusion of appropriate TLVs or of network addresses associated with new TLVs, access to such information after appropriate updates have been recorded in the Information Bases in this protocol.
o 通过在此协议完全处理后访问传入消息。特别地，这可以允许通过包括适当的tlv或与新tlv相关联的网络地址而添加了信息的协议在该协议的信息库中记录了适当的更新之后访问此类信息。
o Through requesting that a message be generated at a specific time. In that case, message generation MUST still respect the constraints in [RFC6130] and Section 5.4.3.
o 通过请求在特定时间生成消息。在这种情况下，消息生成仍必须遵守[RFC6130]和第5.4.3节中的约束。
As a proactive routing protocol, OLSRv2 is a potential target for various attacks. This section presents the envisioned security architecture for OLSRv2 and gives guidelines on how to provide integrity, confidentiality, and integration into external routing domains. Separately specified mandatory security mechanisms are summarized, and some observations on key management are given.
作为一种主动路由协议，OLSRv2是各种攻击的潜在目标。本节介绍了OLSRv2设想的安全体系结构，并给出了如何提供完整性、机密性和集成到外部路由域的指导原则。总结了单独指定的强制安全机制，并给出了一些关于密钥管理的意见。
OLSRv2 integrates into the architecture specified in Appendix A of [RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter by using and extending its messages and Information Bases.
OLSRv2通过使用和扩展其消息和信息库，集成到[RFC5444]附录A、[RFC5498]和[RFC6130]第16节中规定的体系结构中。
As part of this architecture, OLSRv2 and NHDP [RFC6130] recognize that there may be external reasons for rejecting messages that would be considered "badly formed" or "insecure", e.g., if an Integrity Check Value (ICV) included in a message by an external mechanism cannot be verified. This architecture allows options as to whether and how to implement security features, reflecting the situation that MANET routing protocol deployment domains have varying security requirements, ranging from "practically unbreakable" to "virtually none". This approach allows MANET routing protocol specifications to remain generic, with extensions to them and/or extensions to the
作为该体系结构的一部分，OLSRv2和NHDP[RFC6130]认识到拒绝被视为“格式错误”或“不安全”的消息可能有外部原因，例如，如果无法验证外部机制包含在消息中的完整性检查值（ICV）。该体系结构允许选择是否以及如何实现安全功能，反映了MANET路由协议部署域具有不同的安全需求的情况，从“几乎无法破解”到“几乎没有”。这种方法允许MANET路由协议规范保持通用性，并对其进行扩展和/或对
multiplexing and demultiplexing process described in Appendix A of [RFC5444], providing security mechanisms appropriate to a given deployment domain.
[RFC5444]附录A中描述的多路复用和解多路复用过程，提供适用于给定部署域的安全机制。
The following sections provide guidelines on how to provide integrity, confidentiality, and integration with external routing domains in such extensions.
以下各节提供了有关如何在此类扩展中提供完整性、机密性以及与外部路由域集成的指南。
Each router injects topological information into the network by transmitting HELLO messages and, for some routers, also TC messages. If some routers for some reason (malice or malfunction) inject invalid control traffic, network integrity may be compromised. Therefore, message, or packet, authentication is strongly advised.
每个路由器通过传输HELLO消息，以及对于某些路由器，还传输TC消息，将拓扑信息注入网络。如果某些路由器出于某种原因（恶意或故障）注入无效的控制流量，网络完整性可能会受到损害。因此，强烈建议使用消息或数据包身份验证。
Different such situations may occur, for example:
可能出现不同的此类情况，例如：
1. A router generates TC messages, advertising links to non-neighbor routers;
1. 路由器生成TC消息，向非邻居路由器发送广告链接；
2. A router generates TC messages, pretending to be another router;
2. 一个路由器生成TC消息，假装是另一个路由器；
3. A router generates HELLO messages, advertising non-neighbor routers;
3. 路由器生成HELLO消息，向非邻居路由器发送广告；
4. A router generates HELLO messages, pretending to be another router;
4. 路由器生成HELLO消息，假装是另一个路由器；
5. A router forwards altered control messages;
5. 路由器转发改变的控制消息；
6. A router does not forward control messages;
6. 路由器不转发控制消息；
7. A router does not select multipoint relays correctly;
7. 路由器没有正确选择多点中继；
8. A router forwards broadcast control messages unaltered but does not forward unicast data traffic;
8. 路由器转发未改变的广播控制消息，但不转发单播数据业务；
9. A router "replays" previously recorded control traffic from another router.
9. 路由器“重放”先前从另一个路由器记录的控制流量。
Authentication of the originator router for control messages (for situations 2, 4, and 5) and of the individual links announced in the control messages (for situations 1 and 3) may be used as a countermeasure. However, to prevent routers from repeating old (and correctly authenticated) information (situation 9), additional information is required (e.g., a timestamp or sequence number), allowing a router to positively identify such replayed messages.
控制消息的发起者路由器的认证（对于情况2、4和5）和控制消息中宣布的单个链路的认证（对于情况1和3）可以用作对策。然而，为了防止路由器重复旧的（正确认证的）信息（情况9），需要额外的信息（例如，时间戳或序列号），从而允许路由器积极识别此类重播消息。
In general, ICVs (e.g., digital signatures) and other required security information can be transmitted within the HELLO and TC messages or within a packet header using the TLV mechanism. Either option permits different levels of protection to coexist in the same network, if desired.
通常，ICV（例如，数字签名）和其他所需的安全信息可以使用TLV机制在HELLO和TC消息内或在分组报头内传输。如果需要，任一选项都允许不同级别的保护在同一网络中共存。
An important consideration is that all control messages (HELLO messages and TC messages) are transmitted to all routers in the 1-hop neighborhood and some control messages (TC messages) are flooded to all routers in the network. This is done in a packet that is transmitted to all routers in the 1-hop neighborhood, the current set of which may not be known. Thus, a control message or packet used by this protocol is always contained in a transmission destined for multiple destinations, and it is important that the authentication mechanism employed permits any receiving router to validate the authenticity of a message or packet.
一个重要的考虑因素是，所有控制消息（HELLO消息和TC消息）被传输到1跳邻居中的所有路由器，并且一些控制消息（TC消息）被淹没到网络中的所有路由器。这是在一个数据包中完成的，该数据包被传输到1-hop邻居中的所有路由器，其中的当前组可能未知。因此，由该协议使用的控制消息或分组总是包含在目的地为多个目的地的传输中，并且所采用的认证机制允许任何接收路由器验证消息或分组的真实性是重要的。
[RFC7182] specifies a common exchange format for cryptographic information in the form of Packet TLVs, Message TLVs, and Address Block TLVs, as specified in [RFC5444]. These may be used (and shared) among MANET routing protocol security extensions. In particular, [RFC7182] specifies the format of TLVs for containing Integrity Check Values (ICVs), i.e., signatures, for providing integrity, as well as TLVs for containing temporal information for preventing replay attacks. [RFC7182] specifies registries for using different ciphers and formats of temporal information. When using ICV TLVs in an OLSRv2 deployment, failure to verify an included ICV mandates rejection of an incoming message or packet as "invalid", according to Section 12.1 of [RFC6130] and according to Section 16.3.1 of this specification when using the multiplexing and demultiplexing process described in Appendix A of [RFC5444].
[RFC7182]按照[RFC5444]中的规定，以数据包TLV、消息TLV和地址块TLV的形式指定加密信息的通用交换格式。这些可在MANET路由协议安全扩展之间使用（和共享）。具体而言，[RFC7182]指定了用于包含完整性检查值（ICV）的TLV格式，即用于提供完整性的签名，以及用于包含时间信息以防止重播攻击的TLV。[RFC7182]指定使用不同密码和时间信息格式的注册表。当在OLSRv2部署中使用ICV TLV时，根据[RFC6130]第12.1节和本规范第16.3.1节，当使用[RFC5444]附录A中描述的多路复用和解多路复用过程时，如果未能验证包含的ICV，则要求拒绝传入消息或数据包为“无效”。
[RFC7182] specifies how to insert ICVs into generated messages, how to verify incoming messages, and to reject "insecure" messages (i.e., messages without an ICV or with an ICV that cannot be verified). Different MANET deployments may, as a result of the purpose for which they are used and the possibility and nature of their configuration, require different ICV algorithms and timestamps or multiple keys, and thus, a security extension may use any of the different options provided in [RFC7182].
[RFC7182]指定如何在生成的消息中插入ICV，如何验证传入消息，以及拒绝“不安全”消息（即，没有ICV或ICV无法验证的消息）。不同的MANET部署可能由于其使用目的及其配置的可能性和性质而需要不同的ICV算法和时间戳或多个密钥，因此，安全扩展可能使用[RFC7182]中提供的任何不同选项。
OLSRv2 periodically MPR floods topological information to all routers in the network. Hence, if used in an unprotected network, in particular, an unprotected wireless network, the network topology is revealed to anyone who successfully listens to the control messages. This information may serve an attacker to acquire details about the
OLSRv2定期MPR将拓扑信息洪泛到网络中的所有路由器。因此，如果在未受保护的网络中使用，特别是在未受保护的无线网络中，则网络拓扑将向成功侦听控制消息的任何人公开。此信息可能有助于攻击者获取有关
topology and therefore to initiate more effective attacks against routers in the routing domain, e.g., by spoofing addresses of routers in the network and attracting traffic for these addresses. Note that this is independent of the data traffic and purely protects the control traffic, i.e., information about the network topology.
拓扑，从而对路由域中的路由器发起更有效的攻击，例如，通过欺骗网络中路由器的地址并吸引这些地址的流量。注意，这独立于数据通信量，并且纯粹保护控制通信量，即关于网络拓扑的信息。
In situations where the confidentiality of the network topology is of importance, regular cryptographic techniques, such as use of OLSRv2 multicast control packets encrypted using IPsec (e.g., with a shared secret key), can be applied to ensure that control traffic can be read and interpreted by only those authorized to do so. Alternatively, a security extension may specify a mechanism to provide confidentiality for control messages and/or packets. However, unless the information about the network topology itself is confidential, integrity of control messages (as specified in Section 23.2) is sufficient to admit only trusted routers (i.e., routers with valid credentials) to the network.
在网络拓扑的机密性非常重要的情况下，可以应用常规加密技术，例如使用使用IPsec加密的OLSRv2多播控制分组（例如，使用共享密钥），以确保控制流量只能由授权的人读取和解释。或者，安全扩展可以指定为控制消息和/或分组提供机密性的机制。但是，除非有关网络拓扑结构本身的信息是保密的，否则控制消息的完整性（如第23.2节所规定）足以允许仅受信任的路由器（即具有有效凭据的路由器）进入网络。
This protocol provides a basic mechanism for injecting external routing information into this protocol's routing domain. Routing information can also be extracted from this protocol's Information Bases, in particular the Routing Set, and injected into an external routing domain, if the routing protocol governing that routing domain permits this.
该协议提供了一种基本机制，用于将外部路由信息注入该协议的路由域。如果管理该路由域的路由协议允许，还可以从该协议的信息库（特别是路由集）提取路由信息，并将其注入外部路由域。
When operating routers connecting a routing domain using this protocol to an external routing domain, care MUST be taken not to allow potentially insecure and untrustworthy information to be injected from this routing domain to an external routing domain. Care MUST also be taken to validate the correctness of information prior to it being injected, so as to avoid polluting routing tables with invalid information.
当操作使用此协议将路由域连接到外部路由域的路由器时，必须小心不要允许潜在的不安全和不可信信息从此路由域注入到外部路由域。在注入信息之前，还必须注意验证信息的正确性，以避免使用无效信息污染路由表。
A recommended way of extending connectivity from an external routing domain to this routing domain, which is routed using this protocol, is to assign an IP prefix (under the authority of the routers/ gateways connecting this routing domain with the external routing domain) exclusively to this routing domain and to configure the gateways to advertise routes for that IP prefix into the external routing domain.
将连接从外部路由域扩展到此路由域（使用此协议路由）的推荐方法是分配IP前缀（在连接此路由域和外部路由域的路由器/网关的权限下）专用于此路由域，并将网关配置为将该IP前缀的路由播发到外部路由域。
A conformant implementation of OLSRv2 MUST, at minimum, implement the security mechanisms specified in [RFC7183], providing integrity and replay protection of OLSRv2 control messages, including of HELLO
OLSRv2的一致性实现必须至少实现[RFC7183]中规定的安全机制，提供OLSRv2控制消息的完整性和重播保护，包括HELLO
messages specified by [RFC6130] and used by OLSRv2, by inclusion of a timestamp TLV and an Integrity Check Value (ICV) TLV. This ICV TLV uses a SHA-256-based HMAC and one or more manually managed shared secret keys. The timestamp TLV is based on Portable Operating System Interface (POSIX) time, assuming router time synchronization.
[RFC6130]指定并由OLSRv2使用的消息，包括时间戳TLV和完整性检查值（ICV）TLV。此ICV TLV使用基于SHA-256的HMAC和一个或多个手动管理的共享密钥。时间戳TLV基于便携式操作系统接口（POSIX）时间，假设路由器时间同步。
The baseline use case, for which this security mechanism provides adequate integrity protection without rekeying, is for short-lived (for example, up to a couple of months) OLSRv2 deployments.
此安全机制在不重新设置密钥的情况下提供足够的完整性保护的基线用例适用于短期（例如，最多几个月）OLSRv2部署。
Any deployment of OLSRv2 SHOULD use the security mechanism specified in [RFC7183] but MAY use another mechanism if more appropriate in an OLSRv2 deployment. For example, for longer-term OLSRv2 deployments, alternative security mechanisms (e.g., rekeying) SHOULD be considered.
OLSRv2的任何部署都应使用[RFC7183]中指定的安全机制，但如果在OLSRv2部署中更合适，可以使用另一种机制。例如，对于长期的OLSRv2部署，应考虑替代安全机制（例如，密钥更新）。
This specification, as well as [RFC7183], does not mandate automated key management (AKM) as part of the security architecture for OLSRv2. While some use cases for OLSRv2 may require AKM, the baseline assumption is that many use cases do not, for the reasons detailed below.
本规范以及[RFC7183]并未强制要求将自动密钥管理（AKM）作为OLSRv2安全体系结构的一部分。尽管OLSRv2的一些用例可能需要AKM，但基线假设是许多用例不需要AKM，原因如下所述。
Bootstrapping a key is hard in a radio network, where it is, in general, not possible to determine from where a received signal was transmitted or if two transmissions come from the same or from different sources.
在无线网络中，自举密钥是很困难的，一般来说，无法确定从何处发送接收到的信号，或者两次传输是来自同一来源还是来自不同来源。
The widespread use of radio networks and mobile phone networks works under the assumptions that (i) secret information is embedded in mobile phones at manufacture, and (ii) a centralized database of this is accessible during the network lifetime.
无线网络和移动电话网络的广泛使用是在以下假设下进行的：（i）机密信息在制造时嵌入移动电话中，以及（ii）在网络生命周期内可访问该信息的集中数据库。
As a primary use case of a MANET is to provide connectivity without centralized entities and with minimal management, a solution such as described in the previous paragraph is not feasible. In many instances, a cryptographic authority may not be present in the MANET at all, since such a cryptographic authority would be too vulnerable. Due to the potentially dynamic topology of a MANET, a cryptographic authority may also become unreachable (to some or all of the MANET routers) without prior warning.
由于移动自组网的一个主要用例是在没有集中实体的情况下提供连接，并且管理最少，因此如前一段所述的解决方案是不可行的。在许多情况下，MANET中可能根本不存在密码授权，因为这样的密码授权太容易受到攻击。由于MANET的潜在动态拓扑结构，在没有事先警告的情况下（对于部分或所有MANET路由器），也可能无法访问加密授权。
[BCP107] provides guidelines for cryptographic key management. Specifically, Section 2.1 sets forth requirements for when AKM is required, and Section 2.2 sets forth conditions under which manual key management is acceptable.
[BCP107]提供加密密钥管理指南。具体而言，第2.1节规定了何时需要AKM的要求，第2.2节规定了可接受手动钥匙管理的条件。
Section 2.1 of [BCP107] stipulates that "Automated key management MUST be used if any of [a set of given] conditions hold". These conditions are listed below, and arguments for each are provided in regard to their applicability for the baseline use case of OLSRv2.
[BCP107]第2.1节规定，“如果[一组给定]条件中的任何一个条件成立，则必须使用自动密钥管理”。下面列出了这些条件，并就它们对OLSRv2基线用例的适用性提供了每个条件的参数。
o A party will have to manage n^2 static keys, where n may become large.
o 一方必须管理n^2个静态密钥，其中n可能会变大。
The baseline use case of OLSRv2 uses only one or a small set of manually managed shared secrets in the whole MANET.
OLSRv2的基线用例在整个MANET中仅使用一个或一小部分手动管理的共享机密。
o Any stream cipher (such as RC4 [RFC6229][RC4], AES-CTR [RFC3610][NIST-SP-800-38A], or AES-CCM [RFC3686][NIST-SP-800-38C]) is used.
o 使用任何流密码（如RC4[RFC6229][RC4]、AES-CTR[RFC3610][NIST-SP-800-38A]或AES-CCM[RFC3686][NIST-SP-800-38C]）。
A stream cipher is not envisioned for use to generate ICVs for OLSRv2 control messages.
不设想使用流密码为OLSRv2控制消息生成ICV。
o An initialization vector (IV) might be reused, especially an implicit IV. Note that random or pseudo-random explicit IVs are not a problem unless the probability of repetition is high.
o 可以重用初始化向量（IV），尤其是隐式IV。请注意，除非重复的概率很高，否则随机或伪随机显式IV不是问题。
An IV is not envisioned for use to generate ICVs for OLSRv2 control messages.
IV不用于生成OLSRv2控制消息的ICV。
o Large amounts of data might need to be encrypted in a short time, causing frequent change of the short-term session key.
o 可能需要在短时间内对大量数据进行加密，从而导致短期会话密钥的频繁更改。
Integrity Check Values (ICVs) are required only for OLSRv2 control messages, which are low-volume messages.
完整性检查值（ICV）仅适用于OLSRv2控制消息，该消息为低容量消息。
o Long-term session keys are used by more than two parties. Multicast is a necessary exception, but multicast key management standards are emerging in order to avoid this in the future. Sharing long-term session keys should generally be discouraged.
o 长期会话密钥由两个以上的参与方使用。多播是一个必要的例外，但是多播密钥管理标准正在兴起以避免将来出现这种情况。通常不鼓励共享长期会话密钥。
OLSRv2 control messages are all sent using link-local multicast.
OLSRv2控制消息均使用链路本地多播发送。
o The likely operational environment is one where personnel (or device) turnover is frequent, causing frequent change of the short-term session key.
o 可能的操作环境是人员（或设备）频繁更换，导致短期会话密钥频繁更改。
This is not an intended deployment of OLSRv2. For longer-term OLSRv2 deployments, alternative security mechanisms (e.g., including rekeying) SHOULD be considered.
这不是OLSRv2的预期部署。对于长期OLSRv2部署，应考虑替代安全机制（例如，包括密钥更新）。
Section 2.2 of [BCP107] stipulates that "Manual key management may be a reasonable approach in any of [a given set of] situations". These situations are listed below, and arguments for each are provided in regard to their applicability for the baseline use case of OLSRv2.
[BCP107]第2.2节规定，“手动密钥管理可能是[给定的一组]情况下的合理方法”。下面列出了这些情况，并就它们对OLSRv2基线用例的适用性提供了每种情况的参数。
o The environment has very limited available bandwidth or very high round-trip times. Public key systems tend to require long messages and lots of computation; symmetric key alternatives, such as Kerberos, often require several round trips and interaction with third parties.
o 该环境的可用带宽非常有限，或者往返时间非常长。公钥系统往往需要长消息和大量计算；对称密钥替代方案（如Kerberos）通常需要多次往返以及与第三方的交互。
As previously noted, there may not be the required infrastructure (cryptographic authority) present (or, if present, may not be reachable) in the MANET. Bandwidth in a MANET is commonly limited, both by being a radio environment and by the need for any signaling to consume a minimal proportion thereof, and round trip times may also be significant.
如前所述，MANET中可能不存在所需的基础设施（加密机构）（或者，如果存在，可能无法访问）。MANET中的带宽通常是有限的，这既受无线电环境的限制，也受任何信令消耗其最小部分的需要的限制，并且往返时间也可能是重要的。
o The information being protected has low value.
o 受保护的信息的价值较低。
This depends on the OLSRv2 use case, but the information being protected is OLSRv2 control traffic, which is of at least moderate value; thus, this case does not apply.
这取决于OLSRv2用例，但被保护的信息是OLSRv2控制流量，至少具有中等价值；因此，本案不适用。
o The total volume of traffic over the entire lifetime of the long-term session key will be very low.
o 长期会话密钥的整个生命周期内的总通信量将非常低。
Integrity Check Values (ICVs) are required only for OLSRv2 control messages, which are low-volume messages.
完整性检查值（ICV）仅适用于OLSRv2控制消息，该消息为低容量消息。
o The scale of each deployment is very limited.
o 每次部署的规模非常有限。
A typical use case for OLSRv2 may involve only tens of devices -- with even the largest use cases for OLSRv2 being small by Internet standards.
OLSRv2的一个典型用例可能只涉及数十个设备——按照互联网标准，即使是OLSRv2最大的用例也很小。
This specification defines one Message Type, which has been allocated from the "Message Types" registry of [RFC5444], two Message TLV Types, which have been allocated from the "Message TLV Types" registry of [RFC5444], and four Address Block TLV Types, which have been allocated from the "Address Block TLV Types" registry of [RFC5444].
本规范定义了一种消息类型（已从[RFC5444]的“消息类型”注册表分配）、两种消息TLV类型（已从[RFC5444]的“消息TLV类型”注册表分配）和四种地址块TLV类型（已从[RFC5444]的“地址块TLV类型”注册表分配）。
For the registries where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444].
对于需要专家审查的登记处，指定专家应考虑[RFC5444]规定的一般性建议。
This specification defines one Message Type, allocated from the 0-223 range of the "Message Types" namespace defined in [RFC5444], as specified in Table 8.
本规范定义了一种消息类型，从[RFC5444]中定义的“消息类型”命名空间的0-223范围中分配，如表8所示。
+------+----------------------------------------------+
| Type | Description |
+------+----------------------------------------------+
| 1 | TC : Topology Control (MANET-wide signaling) |
+------+----------------------------------------------+
+------+----------------------------------------------+
| Type | Description |
+------+----------------------------------------------+
| 1 | TC : Topology Control (MANET-wide signaling) |
+------+----------------------------------------------+
Table 8: Message Type Assignment
表8：消息类型分配
IANA has created a registry for Message-Type-specific Message TLVs for TC messages, in accordance with Section 6.2.1 of [RFC5444] and with initial assignments and allocation policies as specified in Table 9.
IANA已根据[RFC5444]第6.2.1节以及表9中规定的初始分配和分配策略，为TC报文的报文类型特定报文TLV创建了一个注册表。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 9: TC Message-Type-Specific Message TLV Types
表9:TC消息类型特定的消息TLV类型
IANA has created a registry for Message-Type-specific Address Block TLVs for TC messages, in accordance with Section 6.2.1 of [RFC5444] and with initial assignments and allocation policies as specified in Table 10.
IANA已根据[RFC5444]第6.2.1节以及表10中规定的初始分配和分配策略，为TC消息的消息类型特定地址块TLV创建了一个注册表。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 10: TC Message-Type-Specific Address Block TLV Types
表10:TC消息类型特定的地址块TLV类型
This specification defines two Message TLV Types, which have been allocated from the "Message TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 0-127 range for these types. Two new Type Extension registries have been created with assignments as specified in Table 11 and Table 12. Specifications of these TLVs are in Section 13.3.1. Each of these TLVs MUST NOT be included more than once in a Message TLV Block.
本规范定义了两种消息TLV类型，它们是从[RFC5444]中定义的“消息TLV类型”命名空间中分配的。IANA为这些类型进行了0-127范围的分配。创建了两个新的类型扩展注册表，其分配如表11和表12所示。这些TLV的规范见第13.3.1节。在消息TLV块中，每个TLV不得包含一次以上。
+-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+---------------------+------------+
| MPR_WILLING | 7 | 0 | Bits 0-3 specify | |
| | | | the originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a flooding MPR; | |
| | | | bits 4-7 specify | |
| | | | the originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a routing MPR. | |
| MPR_WILLING | 7 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
+-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+---------------------+------------+
| MPR_WILLING | 7 | 0 | Bits 0-3 specify | |
| | | | the originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a flooding MPR; | |
| | | | bits 4-7 specify | |
| | | | the originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a routing MPR. | |
| MPR_WILLING | 7 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
Table 11: Message TLV Type Assignment: MPR_WILLING
表11：消息TLV类型分配：MPR\U
+--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+--------------+------+-----------+--------------------+------------+
| CONT_SEQ_NUM | 8 | 0 | COMPLETE: | |
| | | | Specifies a | |
| | | | content sequence | |
| | | | number for this | |
| | | | complete message. | |
| CONT_SEQ_NUM | 8 | 1 | INCOMPLETE: | |
| | | | Specifies a | |
| | | | content sequence | |
| | | | number for this | |
| | | | incomplete | |
| | | | message. | |
| CONT_SEQ_NUM | 8 | 2-255 | Unassigned. | Expert |
| | | | | Review |
+--------------+------+-----------+--------------------+------------+
+--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+--------------+------+-----------+--------------------+------------+
| CONT_SEQ_NUM | 8 | 0 | COMPLETE: | |
| | | | Specifies a | |
| | | | content sequence | |
| | | | number for this | |
| | | | complete message. | |
| CONT_SEQ_NUM | 8 | 1 | INCOMPLETE: | |
| | | | Specifies a | |
| | | | content sequence | |
| | | | number for this | |
| | | | incomplete | |
| | | | message. | |
| CONT_SEQ_NUM | 8 | 2-255 | Unassigned. | Expert |
| | | | | Review |
+--------------+------+-----------+--------------------+------------+
Table 12: Message TLV Type Assignment: CONT_SEQ_NUM
表12：消息TLV类型分配：CONT_SEQ_NUM
Type extensions indicated as Expert Review SHOULD be allocated as described in [RFC5444], based on Expert Review as defined in [RFC5226].
应根据[RFC5226]中定义的专家评审，按照[RFC5444]中的说明分配表示为专家评审的类型扩展。
This specification defines four Address Block TLV Types, which have been allocated from the "Address Block TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 8-127 range for these types. Four new Type Extension registries have been created with assignments as specified in Tables 13, 14, 15, and 16. Specifications of these TLVs are in Section 13.3.2.
本规范定义了四种地址块TLV类型，它们是从[RFC5444]中定义的“地址块TLV类型”命名空间中分配的。IANA已为这些类型进行了8-127范围的分配。创建了四个新的类型扩展注册中心，其分配如表13、14、15和16所示。这些TLV的规范见第13.3.2节。
The registration procedure for the "LINK_METRIC Address Block TLV Type Extensions" registry is Expert Review.
“链接\度量地址块TLV类型扩展”注册表的注册程序由专家审查。
+-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-------------+------+-----------+----------------------------------+
| LINK_METRIC | 7 | 0 | Link metric meaning assigned by |
| | | | administrative action. |
| LINK_METRIC | 7 | 1-223 | Unassigned. |
| LINK_METRIC | 7 | 224-255 | Reserved for Experimental Use |
+-------------+------+-----------+----------------------------------+
+-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-------------+------+-----------+----------------------------------+
| LINK_METRIC | 7 | 0 | Link metric meaning assigned by |
| | | | administrative action. |
| LINK_METRIC | 7 | 1-223 | Unassigned. |
| LINK_METRIC | 7 | 224-255 | Reserved for Experimental Use |
+-------------+------+-----------+----------------------------------+
Table 13: Address Block TLV Type Assignment: LINK_METRIC
表13：地址块TLV类型分配：链路度量
All LINK_METRIC TLVs, whatever their type extension, MUST use their value field to encode the kind and value (in the interval MINIMUM_METRIC to MAXIMUM_METRIC, inclusive) of a link metric as specified in Sections 6 and 13.3.2. An assignment of a LINK_METRIC TLV type extension MUST specify the physical meaning of the link metric and the mapping of that physical meaning to the representable values in the indicated interval.
所有链路度量TLV，无论其类型扩展如何，都必须使用其值字段来编码第6节和第13.3.2节中规定的链路度量的种类和值（在最小值度量到最大值度量的区间内，包括在内）。链路度量TLV类型扩展的赋值必须指定链路度量的物理意义，以及该物理意义到指定间隔内可表示值的映射。
+------+------+-----------+----------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+------+------+-----------+----------------------------+------------+
| MPR | 8 | 0 | Specifies that a given | |
| | | | network address is of a | |
| | | | router selected as a | |
| | | | flooding MPR (FLOODING = | |
| | | | 1), that a given network | |
| | | | address is of a router | |
| | | | selected as a routing MPR | |
| | | | (ROUTING = 2), or both | |
| | | | (FLOOD_ROUTE = 3). | |
| MPR | 8 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+------+------+-----------+----------------------------+------------+
+------+------+-----------+----------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+------+------+-----------+----------------------------+------------+
| MPR | 8 | 0 | Specifies that a given | |
| | | | network address is of a | |
| | | | router selected as a | |
| | | | flooding MPR (FLOODING = | |
| | | | 1), that a given network | |
| | | | address is of a router | |
| | | | selected as a routing MPR | |
| | | | (ROUTING = 2), or both | |
| | | | (FLOOD_ROUTE = 3). | |
| MPR | 8 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+------+------+-----------+----------------------------+------------+
Table 14: Address Block TLV Type Assignment: MPR
表14：地址块TLV类型分配：MPR
+---------------+------+-----------+-------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+---------------+------+-----------+-------------------+------------+
| NBR_ADDR_TYPE | 9 | 0 | Specifies that a | |
| | | | given network | |
| | | | address is of a | |
| | | | neighbor reached | |
| | | | via the | |
| | | | originating | |
| | | | router, if it is | |
| | | | an originator | |
| | | | address | |
| | | | (ORIGINATOR = 1), | |
| | | | is a routable | |
| | | | address (ROUTABLE | |
| | | | = 2), or if it is | |
| | | | both | |
| | | | (ROUTABLE_ORIG = | |
| | | | 3). | |
| NBR_ADDR_TYPE | 9 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+---------------+------+-----------+-------------------+------------+
+---------------+------+-----------+-------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+---------------+------+-----------+-------------------+------------+
| NBR_ADDR_TYPE | 9 | 0 | Specifies that a | |
| | | | given network | |
| | | | address is of a | |
| | | | neighbor reached | |
| | | | via the | |
| | | | originating | |
| | | | router, if it is | |
| | | | an originator | |
| | | | address | |
| | | | (ORIGINATOR = 1), | |
| | | | is a routable | |
| | | | address (ROUTABLE | |
| | | | = 2), or if it is | |
| | | | both | |
| | | | (ROUTABLE_ORIG = | |
| | | | 3). | |
| NBR_ADDR_TYPE | 9 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+---------------+------+-----------+-------------------+------------+
Table 15: Address Block TLV Type Assignment: NBR_ADDR_TYPE
表15：地址块TLV类型分配：NBR\U地址类型
+---------+------+-----------+-------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | Policy |
+---------+------+-----------+-------------------------+------------+
| GATEWAY | 10 | 0 | Specifies that a given | |
| | | | network address is | |
| | | | reached via a gateway | |
| | | | on the originating | |
| | | | router, with value | |
| | | | equal to the number of | |
| | | | hops. | |
| GATEWAY | 10 | 1-255 | | Expert |
| | | | | Review |
+---------+------+-----------+-------------------------+------------+
+---------+------+-----------+-------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | Policy |
+---------+------+-----------+-------------------------+------------+
| GATEWAY | 10 | 0 | Specifies that a given | |
| | | | network address is | |
| | | | reached via a gateway | |
| | | | on the originating | |
| | | | router, with value | |
| | | | equal to the number of | |
| | | | hops. | |
| GATEWAY | 10 | 1-255 | | Expert |
| | | | | Review |
+---------+------+-----------+-------------------------+------------+
Table 16: Address Block TLV Type Assignment: GATEWAY
表16：地址块TLV类型分配：网关
Type extensions indicated as Expert Review SHOULD be allocated as described in [RFC5444], based on Expert Review as defined in [RFC5226].
应根据[RFC5226]中定义的专家评审，按照[RFC5444]中的说明分配表示为专家评审的类型扩展。
Note: This section does not require any IANA action, as the required information is included in the descriptions of the MPR and NBR_ADDR_TYPE Address Block TLVs allocated in Section 24.5. This information is recorded here for clarity and for use elsewhere in this specification.
注：本节不要求IANA采取任何行动，因为所需信息包含在第24.5节中分配的MPR和NBR_ADDR_类型地址块TLV的说明中。为了清晰起见，并在本规范其他地方使用，在此记录此信息。
The Values that the MPR Address Block TLV can use are as follows:
MPR地址块TLV可以使用的值如下：
o FLOODING := 1;
o 水浸：=1；
o ROUTING := 2;
o 路由：=2；
o FLOOD_ROUTE := 3.
o 洪水路径：=3。
The Values that the NBR_ADDR_TYPE Address Block TLV can use are follows:
NBR_ADDR_类型地址块TLV可以使用的值如下：
o ORIGINATOR := 1;
o 发起人：=1；
o ROUTABLE := 2;
o 可路由：=2；
o ROUTABLE_ORIG := 3.
o 可路由来源：=3。
This specification is the result of the joint efforts of the following contributors, listed alphabetically.
本规范是以下贡献者共同努力的结果，按字母顺序列出。
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o 塞德里克·阿吉，法国因里亚，<塞德里克。Adjih@inria.fr>
o Emmanuel Baccelli, INRIA , France, <Emmanuel.Baccelli@inria.fr>
o 伊曼纽尔·巴切利，法国因里亚，<伊曼纽尔。Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
o 托马斯·海德·克劳森，法国利克斯，<T。Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o 贾斯汀·迪恩，美国北爱尔兰共和国<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, <chris.dearlove@baesystems.com>
o Christopher Dearlove，英国BAE系统公司，<chris。dearlove@baesystems.com>
o Ulrich Herberg, Fujitsu Laboratories of America, USA, <ulrich@herberg.name>
o 美国富士通实验室Ulrich Herberg<ulrich@herberg.name>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o 佐藤广木，日立SDL，日本，<Hiroki.Satoh。yj@hitachi.com>
o Philippe Jacquet, Alcatel Lucent Bell Labs, France, <philippe.jacquet@alcatel-lucent.fr>
o Philippe Jacquet，阿尔卡特朗讯贝尔实验室，法国，<Philippe。jacquet@alcatel-朗讯.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
o Monden Kazuya，日立SDL，日本，<Kazuya.Monden。vw@hitachi.com>
o Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp>
o 日本新泻大学Kenichi Mase<mase@ie.niigata-u、 ac.jp>
o Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp>
o 日本，丰田，Wakikawa Ryuji<ryuji@sfc.wide.ad.jp>
The authors would like to acknowledge the team behind OLSRv1, as listed in RFC 3626, including Anis Laouiti (INT), Pascale Minet (INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah University), and Laurent Viennot (INRIA) for their contributions.
作者要感谢RFC 3626中列出的OLSRv1背后的团队，包括Anis Laouiti（INT）、Pascale Minet（INRIA）、Paul Muhlethaler（INRIA）、Amir Qayyum（Jinnah大学硕士）和Laurent Vienno（INRIA），感谢他们的贡献。
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification and its components (listed alphabetically): Khaldoun Al Agha (LRI), Teco Boot (Infinity Networks), Ross Callon (Juniper), Song-Yean Cho (Samsung), Alan Cullen (BAE Systems), Louise Lamont (CRC), Li Li (CRC), Joseph Macker (NRL), Richard Ogier (SRI), Charles E. Perkins (Futurewei), Henning Rogge (Frauenhofer FKIE), and the entire IETF MANET Working Group.
作者衷心感谢以下人士对规范及其组件（按字母顺序列出）进行了深入的技术讨论、早期审查和评论：Khaldoun Al-Agha（LRI）、Teco Boot（Infinity Networks）、Ross Callon（Juniper）、Song Yean Cho（三星）、Alan Cullen（BAE Systems）、Louise Lamont（CRC），李莉（CRC）、约瑟夫·麦克尔（NRL）、理查德·奥吉尔（SRI）、查尔斯·E·珀金斯（Futurewei）、汉宁·罗格（Frauenhofer FKIE）以及整个IETF MANET工作组。
Finally, the authors would like to express their gratitude to the Area Directors for providing valuable review comments during the IESG evaluation, in particular (listed alphabetically) Benoit Claise, Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Stiemerling.
最后，作者要感谢区域主管在IESG评估期间提供了宝贵的审查意见，特别是（按字母顺序列出）Benoit Claise、Adrian Farrel、Stephen Farrell、Barry Leiba、Pete Resnick和Martin Stiemering。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008.
[RFC5148]Clausen，T.，Dearlove，C.，和B.Adamson，“移动自组网（MANET）中的抖动考虑”，RFC 5148，2008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444]Clausen，T.，Dearlove，C.，Dean，J.，和C.Adjih，“通用移动自组网（MANET）数据包/消息格式”，RFC 54442009年2月。
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009.
[RFC5497]Clausen，T.和C.Dearlove，“移动自组织网络（MANET）中代表多值时间”，RFC 54972009年3月。
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, March 2009.
[RFC5498]Chakeres，I.“移动自组网（MANET）协议的IANA分配”，RFC 5498，2009年3月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130]Clausen，T.，Dearlove，C.，和J.Dean，“移动自组织网络（MANET）邻域发现协议（NHDP）”，RFC6130，2011年4月。
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7182]Herberg，U.，Clausen，T.，和C.Dearlove，“移动自组网（MANET）的完整性检查值和时间戳TLV定义”，RFC 7182，2014年4月。
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014.
[RFC7183]Herberg，U.，Dearlove，C.，和T.Clausen，“邻域发现协议（NHDP）和优化链路状态路由协议版本2（OLSRv2）的完整性保护”，RFC 7183，2014年4月。
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[BCP107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis, "Making Link-State Routing Scale for Ad Hoc Networks", MobiHoc '01, Proceedings of the 2nd ACM International Symposium on Mobile Ad Hoc Networking & Computing, 2001.
[FSLS]Santivanez，C.，Ramanathan，R.，和I.Stavrakakikis，“为adhoc网络建立链路状态路由规模”，MobiHoc'01，第二届ACM移动adhoc网络与计算国际研讨会论文集，2001年。
[FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye State Routing in Mobile Ad Hoc Networks", ICDCS Workshop on Wireless Networks and Mobile Computing, 2000.
[FSR]Pei，G.，Gerla，M.，和T.Chen，“移动自组织网络中的鱼眼状态路由”，ICDCS无线网络和移动计算研讨会，2000年。
[HIPERLAN] ETSI, "Radio Equipment and Systems (RES); HIgh PErformance Radio Local Area Network (HIPERLAN) Type 1; Functional Specification", ETSI 300-652, June 1996.
[HIPERLAN]ETSI，“无线电设备和系统（RES）；高性能无线电局域网（HIPERLAN）类型1；功能规范”，ETSI 300-652，1996年6月。
[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. Rivierre, "Increasing Reliability in Cable-Free Radio LANs: Low Level Forwarding in HIPERLAN", Wireless Personal Communications, Volume 4, Issue 1, 1997.
[HIPERLAN 2]Jacquet，P.，Minet，P.，Muhlethaler，P.，和N.Rivierre，“增加无电缆无线局域网的可靠性：HIPERLAN中的低层转发”，无线个人通信，第4卷，1997年第1期。
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint relaying: An efficient technique for flooding in mobile wireless Networks", INRIA, No. 3898, March 2000.
[MPR]Qayyum，A.，Vienno，L.，和A.Laouiti，“多点中继：移动无线网络中洪水泛滥的有效技术”，INRIA，第3898号，2000年3月。
[McCabe] McCabe, A., Dearlove, C., Fredin, M., and L. Axelsson, "Scalability modelling of ad hoc routing protocols - a comparison of OLSR and DSR", Scandinavian Wireless Adhoc Networks '04, 2004.
[McCabe]McCabe，A.，Dearlove，C.，Fredin，M.，和L.Axelson，“自组织路由协议的可伸缩性建模-OLSR和DSR的比较”，斯堪的纳维亚无线自组织网络2004年4月。
[NIST-SP-800-38A] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", Special Publication 800-38A, December 2001.
[NIST-SP-800-38A]国家标准与技术研究所，“分组密码操作模式的建议：方法和技术”，特别出版物800-38A，2001年12月。
[NIST-SP-800-38C] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", Special Publication 800-38C, May 2004.
[NIST-SP-800-38C]国家标准与技术研究所，“分组密码操作模式的建议：认证和保密的CCM模式”，特别出版物800-38C，2004年5月。
[RC4] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", Second Edition, John Wiley and Sons, New York, 1996.
[RC4]Schneier，B.，“应用密码学：C语言中的协议、算法和源代码”，第二版，John Wiley and Sons，纽约，1996年。
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC2501]Corson，M.和J.Macker，“移动自组网（MANET）：路由协议性能问题和评估考虑”，RFC 2501，1999年1月。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3610]Whiting，D.，Housley，R.，和N.Ferguson，“CBC-MAC（CCM）计数器”，RFC 36102003年9月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626]Clausen，T.和P.Jacquet，“优化链路状态路由协议（OLSR）”，RFC 3626，2003年10月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC6229] Strombergson, J. and S. Josefsson, "Test Vectors for the Stream Cipher RC4", RFC 6229, May 2011.
[RFC6229]Strombergson，J.和S.Josefsson，“流密码RC4的测试向量”，RFC 6229，2011年5月。
Updates to the Local Information Base, the Neighborhood Information Base, or the Topology Information Base MUST ensure that all constraints specified in this appendix are maintained, as well as those specified in [RFC6130]. This is the case for the processing, specified in this document. Any protocol extension or outside process, which updates the Neighborhood Information Base or the Topology Information Base, MUST also ensure that these constraints are maintained.
对本地信息库、邻域信息库或拓扑信息库的更新必须确保维护本附录中规定的所有约束以及[RFC6130]中规定的约束。本文件中规定的处理就是这种情况。更新邻域信息库或拓扑信息库的任何协议扩展或外部进程也必须确保保持这些约束。
In each Originator Tuple:
在每个发起人元组中：
o O_orig_addr MUST NOT equal any other O_orig_addr.
o O_orig_addr不得等于任何其他O_orig_addr。
o O_orig_addr MUST NOT equal this router's originator address.
o O_orig_addr不能等于此路由器的发起者地址。
In each Local Attached Network Tuple:
在每个本地连接的网络元组中：
o AL_net_addr MUST NOT equal any other AL_net_addr.
o 所有净地址不得等于任何其他所有净地址。
o AL_net_addr MUST NOT equal or be a sub-range of any network address in the I_local_iface_addr_list of any Local Interface Tuple.
o AL_net_addr不得等于或是任何本地接口元组的I_local_iface_addr_列表中任何网络地址的子范围。
o AL_net_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o AL_net_addr不得等于此路由器的发起者地址或任何发起者元组中的O_orig_addr。
o AL_dist MUST NOT be less than zero.
o AL_dist不得小于零。
In each Link Tuple:
在每个链接元组中：
o L_neighbor_iface_addr_list MUST NOT contain any network address that AL_net_addr of any Local Attached Network Tuple equals or is a sub-range of.
o L_neighbor_iface_addr_列表不得包含任何本地连接网络元组的AL_net_addr等于或是其子范围的任何网络地址。
o If L_in_metric != UNKNOWN_METRIC, then L_in_metric MUST be representable in the defined compressed form.
o 如果L_单位为公制！=未知的度量，那么L_in_度量必须以定义的压缩形式表示。
o If L_out_metric != UNKNOWN_METRIC, then L_out_metric MUST be representable in the defined compressed form.
o 如果L_out_公制！=未知度量，则L_out_度量必须以定义的压缩形式表示。
o If L_mpr_selector = true, then L_status = SYMMETRIC.
o 如果L_mpr_选择器=真，则L_状态=对称。
In each Neighbor Tuple:
在每个相邻元组中：
o N_orig_addr MUST NOT be changed to unknown.
o N_orig_addr不能更改为未知。
o N_orig_addr MUST NOT equal this router's originator address or equal O_orig_addr in any Originator Tuple.
o N_orig_addr不能等于此路由器的发起者地址，也不能等于任何发起者元组中的O_orig_addr。
o N_orig_addr MUST NOT equal the AL_net_addr in any Local Attached Network Tuple.
o N_orig_addr不能等于任何本地连接网络元组中的AL_net_addr。
o If N_orig_addr != unknown, then N_orig_addr MUST NOT equal the N_orig_addr in any other Neighbor Tuple.
o 如果N_orig_addr！=未知，则N_orig_addr不能等于任何其他相邻元组中的N_orig_addr。
o N_neighbor_addr_list MUST NOT contain any network address that includes this router's originator address, the O_orig_addr in any Originator Tuple, or equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o N_neighbor_addr_列表不得包含任何网络地址，其中包括此路由器的发起者地址、任何发起者元组中的O_orig_addr、或任何本地连接网络元组中的AL_net_addr，或将其作为子范围。
o If N_orig_addr = unknown, then N_will_flooding = WILL_NEVER, N_will_routing = WILL_NEVER, N_flooding_mpr = false, N_routing_mpr = false, N_mpr_selector = false, and N_advertised = false.
o 如果N\u orig\u addr=unknown，那么N\u will\u flooding=will\u NEVER，N\u will\u routing=will\u NEVER，N\u flooding\u mpr=false，N\u routing\u mpr=false，N\u mpr\u selector=false，N\u advised=false。
o N_in_metric MUST equal the minimum value of the L_in_metric values of all corresponding Link Tuples with L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC, if any; otherwise, N_in_metric = UNKNOWN_METRIC.
o N_in_度量必须等于L_status=对称且L_in_度量！=的所有对应链接元组的L_in_度量值的最小值未知_度量（如有）；否则，N_in_度量=未知的_度量。
o N_out_metric MUST equal the minimum value of the L_out_metric values of all corresponding Link Tuples with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC, if any; otherwise, N_out_metric = UNKNOWN_METRIC.
o N_out_metric必须等于L_status=对称且L_out_metric！=未知_度量（如有）；否则，N_out_metric=未知_metric。
o N_will_flooding and N_will_routing MUST be in the range from WILL_NEVER to WILL_ALWAYS, inclusive.
o N_will_泛洪和N_will_路由必须在will_NEVER到will_ALWAYS（包括）的范围内。
o If N_flooding_mpr = true, then N_symmetric MUST be true, N_out_metric MUST NOT equal UNKNOWN_METRIC, and N_will_flooding MUST NOT equal WILL_NEVER.
o 如果N_flooding_mpr=true，则N_symmetric必须为true，N_out_度量不得等于UNKNOWN_度量，N_will_flooding不得等于will_NEVER。
o If N_routing_mpr = true, then N_symmetric MUST be true, N_in_metric MUST NOT equal UNKNOWN_METRIC, and N_will_routing MUST NOT equal WILL_NEVER.
o 如果N_routing_mpr=true，则N_symmetric必须为true，N_in_度量不得等于UNKNOWN_度量，N_will_routing不得等于will_NEVER。
o If N_symmetric = true and N_flooding_mpr = false, then N_will_flooding MUST NOT equal WILL_ALWAYS.
o 如果N_symmetric=true和N_flooding_mpr=false，则N_will_flooding不得始终等于will_。
o If N_symmetric = true and N_routing_mpr = false, then N_will_routing MUST NOT equal WILL_ALWAYS.
o 如果N_symmetric=true和N_routing_mpr=false，则N_will_routing不能始终等于will_。
o If N_mpr_selector = true, then N_advertised MUST be true.
o 如果N_mpr_selector=true，则N_广告必须为true。
o If N_advertised = true, then N_symmetric MUST be true and N_out_metric MUST NOT equal UNKNOWN_METRIC.
o 如果N_advised=true，则N_symmetric必须为true，N_out_度量不能等于UNKNOWN_度量。
In each Lost Neighbor Tuple:
在每个丢失的邻居元组中：
o NL_neighbor_addr MUST NOT include this router's originator address, the O_orig_addr in any Originator Tuple, or equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o NL_neighbor_addr不得在任何发起人元组中包含此路由器的发起人地址、O_orig_addr，或在任何本地连接的网络元组中包含相等的或作为子范围的AL_net_addr。
In each 2-Hop Tuple:
在每个2跳元组中：
o N2_2hop_addr MUST NOT equal this router's originator address, equal the O_orig_addr in any Originator Tuple, or equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o N2_2; hop_addr不得等于此路由器的发起者地址，不得等于任何发起者元组中的O_orig_addr，也不得等于或将任何本地连接网络元组中的AL_net_addr作为子范围。
o If N2_in_metric != UNKNOWN_METRIC, then N2_in_metric MUST be representable in the defined compressed form.
o 如果N2单位为公制！=未知度量，则N2度量中的度量必须以定义的压缩形式表示。
o If N2_out_metric != UNKNOWN_METRIC, then N2_out_metric MUST be representable in the defined compressed form.
o 如果N2_out_公制！=未知度量，则N2\u out\u度量必须以定义的压缩形式表示。
In each Advertising Remote Router Tuple:
在每个远程路由器元组中：
o AR_orig_addr MUST NOT be in any network address in the I_local_iface_addr_list in any Local Interface Tuple or be in the IR_local_iface_addr in any Removed Interface Address Tuple.
o AR_orig_addr不得位于任何本地接口元组的I_local_iface_addr_列表中的任何网络地址中，或位于任何删除的接口地址元组中的IR_local_iface_addr中。
o AR_orig_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o AR_orig_addr不能等于此路由器的发端地址，也不能等于任何发端元组中的O_orig_addr。
o AR_orig_addr MUST NOT be in the AL_net_addr in any Local Attached Network Tuple.
o AR_orig_addr不得位于任何本地连接网络元组的AL_net_addr中。
o AR_orig_addr MUST NOT equal the AR_orig_addr in any other Advertising Remote Router Tuple.
o AR_orig_addr不得等于任何其他广告远程路由器元组中的AR_orig_addr。
In each Router Topology Tuple:
在每个路由器拓扑元组中：
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr = TR_from_orig_addr.
o 必须有一个广告远程路由器元组，其AR_orig_addr=TR_from_orig_addr。
o TR_to_orig_addr MUST NOT be in any network address in the I_local_iface_addr_list in any Local Interface Tuple or be in the IR_local_iface_addr in any Removed Interface Address Tuple.
o TR_to_orig_addr不得位于任何本地接口元组的I_local_iface_addr_列表中的任何网络地址中，或位于任何删除的接口地址元组的IR_local_iface_addr中。
o TR_to_orig_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o TR_to_orig_addr不能等于此路由器的发起者地址，也不能等于任何发起者元组中的O_orig_addr。
o TR_to_orig_addr MUST NOT be in the AL_net_addr in any Local Attached Network Tuple.
o TR_to_orig_addr不得位于任何本地连接网络元组的AL_net_addr中。
o The ordered pair (TR_from_orig_addr, TR_to_orig_addr) MUST NOT equal the corresponding pair for any other Router Topology Tuple.
o 有序对（TR_from_orig_addr，TR_to_orig_addr）不得等于任何其他路由器拓扑元组的对应对。
o TR_seq_number MUST NOT be greater than AR_seq_number in the Advertising Remote Router Tuple with AR_orig_addr = TR_from_orig_addr.
o TR_seq_number不得大于广告远程路由器元组中的AR_seq_number，AR_orig_addr=TR_from_orig_addr。
o TR_metric MUST be representable in the defined compressed form.
o TR_度量必须以定义的压缩形式表示。
In each Routable Address Topology Tuple:
在每个可路由地址拓扑元组中：
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr = TA_from_orig_addr.
o 必须有一个广告远程路由器元组，其AR_orig_addr=TA_from_orig_addr。
o TA_dest_addr MUST be routable.
o TA_dest_addr必须是可路由的。
o TA_dest_addr MUST NOT overlap any network address in the I_local_iface_addr_list in any Local Interface Tuple or overlap the IR_local_iface_addr in any Removed Interface Address Tuple.
o TA_dest_addr不得与任何本地接口元组中I_local_iface_addr_列表中的任何网络地址重叠，也不得与任何删除的接口地址元组中的IR_local_iface_addr重叠。
o TA_dest_addr MUST NOT include this router's originator address or include the O_orig_addr in any Originator Tuple.
o TA_dest_addr不得包含此路由器的发起者地址或在任何发起者元组中包含O_orig_addr。
o TA_dest_addr MUST NOT equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o TA_dest_addr不得等于任何本地连接网络元组中的AL_net_addr或将其作为子范围。
o The ordered pair (TA_from_orig_addr, TA_dest_addr) MUST NOT equal the corresponding pair for any other Attached Network Tuple.
o 有序对（TA_from_orig_addr，TA_dest_addr）不得等于任何其他连接的网络元组的对应对。
o TA_seq_number MUST NOT be greater than AR_seq_number in the Advertising Remote Router Tuple with AR_orig_addr = TA_from_orig_addr.
o TA_seq_number不得大于广告远程路由器元组中的AR_seq_number，AR_orig_addr=TA_from_orig_addr。
o TA_metric MUST be representable in the defined compressed form.
o TA_度量必须以定义的压缩形式表示。
In each Attached Network Tuple:
在每个连接的网络元组中：
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
o 必须存在AR_orig_addr=an_orig_addr的广告远程路由器元组。
o AN_net_addr MUST NOT equal or be a sub-range of any network address in the I_local_iface_addr_list in any Local Interface Tuple or equal or be a sub-range of the IR_local_iface_addr in any Removed Interface Address Tuple.
o _net_addr不得等于或是任何本地接口元组中I_local_iface_addr_列表中任何网络地址的子范围，或等于或是任何删除的接口地址元组中IR_local_iface_addr的子范围。
o AN_net_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o “网络地址”不能等于此路由器的发起者地址，也不能等于任何发起者元组中的“源地址”。
o The ordered pair (AN_orig_addr, AN_net_addr) MUST NOT equal the corresponding pair for any other Attached Network Tuple.
o 有序对（源地址、网络地址）不得等于任何其他连接的网络元组的对应对。
o AN_seq_number MUST NOT be greater than AR_seq_number in the Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
o 在AR_orig_addr=AN_orig_addr的广告远程路由器元组中，一个_seq_编号不得大于AR_seq_编号。
o AN_dist MUST NOT be less than zero.
o _dist不得小于零。
o AN_metric MUST be representable in the defined compressed form.
o _度量必须以定义的压缩形式表示。
The following specifies an algorithm that MAY be used to select an MPR Set given a Neighbor Graph, as defined in Section 18.2 and Section 18.3.
以下规定了一种算法，该算法可用于根据第18.2节和第18.3节中的定义，选择给定相邻图的MPR集。
This algorithm selects an MPR Set M that is a subset of the set N1 that is part of the Neighbor Graph. This algorithm assumes that a subset I of N1 is pre-selected as MPRs, i.e., that M will contain I.
该算法选择MPR集合M，该集合M是作为相邻图一部分的集合N1的子集。该算法假设N1的子集I被预先选择为mpr，即M将包含I。
The following additional notation, in addition to that in Section 18.2, will be used by this algorithm:
除了第18.2节中的符号外，该算法还将使用以下附加符号：
N: A subset of N2, consisting of those elements y in N2 such that either d1(y) is not defined, or there is at least one x in N1 such that d(x,y) is defined and d(x,y) < d1(y).
N：N2的子集，由N2中的元素y组成，其中d1（y）未定义，或者N1中至少有一个x定义为d（x，y），且d（x，y）<d1（y）。
D(x): For an element x in N1, the number of elements y in N for which d(x,y) is defined and has minimal value among the d(z,y) for all z in N1.
D（x）：对于N1中的元素x，定义了D（x，y）的元素y在N中的数量，并且在N1中所有z的D（z，y）中具有最小值。
R(x,M): For an element x in N1, the number of elements y in N for which d(x,y) is defined has minimal value among the d(z,y) for all z in N1 and no such minimal values have z in M. (Note that, denoting the empty set by 0, D(x) = R(x,0).)
R（x，M）：对于N1中的元素x，定义了d（x，y）的N中元素y的数量在N1中所有z的d（z，y）中具有最小值，并且没有这样的最小值具有M中的z。（注意，用0表示空集，d（x）=R（x，0）。）
To create the MPR Set M, starting with M := I:
要创建MPR集M，请从M:=I开始：
1. Add all elements x in N1 that have W(x) = WILL_ALWAYS to M.
1. 将N1中W（x）=WILL_始终等于M的所有元素x相加。
2. For each element y in N for which there is only one element x in N1 such that d2(x,y) is defined, add that element x to M.
2. 对于N中的每个元素y，其中N1中只有一个元素x，因此定义了d2（x，y），将该元素x添加到M中。
3. While there exists any element x in N1 with R(x,M) > 0:
3. 当N1中存在R（x，M）>0的任何元素x时：
1. Select an element x in N1 with R(x,M) > 0 in the following order of priority, and then add to M:
1. 按以下优先级顺序选择N1中R（x，M）>0的元素x，然后添加到M：
+ greatest W(x), THEN
+ 最大W（x），那么
+ greatest R(x,M), THEN
+ 最大R（x，M），那么
+ greatest D(x), THEN
+ 最大的D（x），那么
+ any choice, which MAY be based on other criteria (for example, a router MAY choose to prefer a neighbor as an MPR if that neighbor has already selected the router as an MPR of the same type, MAY prefer a neighbor based on information freshness, or MAY prefer a neighbor based on length of time previously selected as an MPR) or MAY be random.
+ 任何选择可以基于其他标准（例如，如果邻居已经选择路由器作为相同类型的MPR，则路由器可以选择偏好邻居作为MPR），可以基于信息新鲜度偏好邻居，或者可以基于先前选择为MPR的时间长度偏好邻居），或者可以是随机的。
4. OPTIONAL: consider each element x in M, but not in I, in turn and if x can be removed from M while still leaving it satisfying the definition of an MPR Set, then remove that element x from M. Elements MAY be considered in any order, e.g., in order of increasing W(x).
4. 可选的：考虑M中的每个元素X，但不考虑I，反过来，如果X可以从M中移除，同时仍然使其满足MPR集合的定义，那么从M元素中移除元素X可以按任意顺序考虑，例如，按照W（x）的增加顺序。
The following procedure is given as an example for calculating the Routing Set using a variation of Dijkstra's algorithm. First, all Routing Tuples are removed, and then, using the selections and definitions in Appendix C.1, the procedures in the following sections (each considered a "stage" of the processing) are applied in turn.
下面给出了使用Dijkstra算法变体计算路由集的示例。首先，删除所有路由元组，然后使用附录C.1中的选择和定义，依次应用以下各节中的程序（每个程序都被视为处理的“阶段”）。
The following selections and definitions are made:
进行了以下选择和定义：
1. For each Local Interface Tuple, select a network address from its I_local_iface_addr_list. This is defined as the selected address for this Local Interface Tuple.
1. 对于每个本地接口元组，从其I_Local_iface_addr_列表中选择一个网络地址。这被定义为此本地接口元组的选定地址。
2. For each Link Tuple, the selected address of its corresponding Local Interface Tuple is defined as the selected local address for this Link Tuple.
2. 对于每个链接元组，其相应本地接口元组的选定地址被定义为该链接元组的选定本地地址。
3. For each Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC, select a Link Tuple with L_status = SYMMETRIC for which this is the corresponding Neighbor Tuple and has L_out_metric = N_out_metric. This is defined as the selected Link Tuple for this Neighbor Tuple.
3. 对于N_symmetric=true且N_out_度量！=未知\u度量，选择L\u status=SYMMETRIC的链接元组，这是对应的相邻元组，并且L\u out\u度量=N\u out\u度量。这被定义为该相邻元组的选定链接元组。
4. For each network address (N_orig_addr or in N_neighbor_addr_list, the "neighbor address") from a Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC, select a Link Tuple (the "selected Link Tuple") from those for which this is the corresponding Neighbor Tuple, have L_status = SYMMETRIC, and have L_out_metric = N_out_metric, by:
4. 对于每个网络地址（N_orig_addr或N_neighbor_addr_列表中的“邻居地址”），从N_symmetric=true和N_out_metric！=未知_度量，通过以下方式从对应的相邻元组中选择一个链接元组（“所选链接元组”），其中L_状态=对称，L_out_度量=N_out_度量：
1. If there is such a Link Tuple whose L_neighbor_iface_addr_list contains the neighbor address, select that Link Tuple.
1. 如果存在这样一个链接元组，其L_neighbor_iface_addr_列表包含邻居地址，请选择该链接元组。
2. Otherwise, select the selected Link Tuple for this Neighbor Tuple.
2. 否则，请为此邻居元组选择所选链接元组。
Then for this neighbor address:
然后，对于该邻居地址：
3. The selected local address is defined as the selected local address for the selected Link Tuple.
3. 所选本地地址定义为所选链接元组的所选本地地址。
4. The selected link address is defined as an address from the L_neighbor_iface_addr_list of the selected Link Tuple, if possible equal to this neighbor address.
4. 所选链路地址定义为所选链路元组的L_neighbor_iface_addr_列表中的地址，如果可能，该地址等于该邻居地址。
5. Routing Tuple preference is decided by preference for minimum R_metric, then for minimum R_dist, and then for preference for corresponding Neighbor Tuples in this order:
5. 路由元组偏好由对最小R_度量的偏好决定，然后是对最小R_距离的偏好，然后是对相应相邻元组的偏好，顺序如下：
* For greater N_will_routing.
* 对于更大的N_，将选择N_路由。
* For N_mpr_selector = true over N_mpr_selector = false.
* 对于N\u mpr\u选择器=真，对于N\u mpr\u选择器=假。
Note that preferred Routing Tuples SHOULD be used. Routing Tuples with minimum R_metric MUST be used; this is specified outside the definition of preference. An implementation MAY modify this definition of preference (including for minimum R_dist) without otherwise affecting this algorithm.
请注意，应使用首选路由元组。必须使用具有最小R_度量的路由元组；这是在首选项定义之外指定的。在不影响该算法的情况下，实现可以修改该偏好定义（包括最小R_dist）。
The following procedure is executed once.
以下过程执行一次。
1. For each Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC, add a Routing Tuple with:
1. 对于N_symmetric=true且N_out_度量！=未知_度量，添加具有以下内容的路由元组：
* R_dest_addr := N_orig_addr;
* R_dest_addr:=N_orig_addr；
* R_next_iface_addr := selected link address for N_orig_addr;
* R_next_iface_addr:=为N_orig_addr选择的链接地址；
* R_local_iface_addr := selected local address for N_orig_addr;
* R_local_iface_addr:=为N_orig_addr选择的本地地址；
* R_metric := N_out_metric;
* R_度量：=N_out_度量；
* R_dist := 1.
* R_dist:=1。
The following procedure is executed once.
以下过程执行一次。
1. Add a label that may be "used" or "unused" to each Routing Tuple, with all initial values equal to unused. (Note that this label is only required during this algorithm.)
1. 向每个路由元组添加一个可能“已使用”或“未使用”的标签，所有初始值都等于未使用。（请注意，此标签仅在此算法期间需要。）
2. If there are no unused Routing Tuples, then this stage is complete; otherwise, repeat the following until that is the case.
2. 如果没有未使用的路由元组，则此阶段完成；否则，重复以下步骤，直到情况属实。
1. Find the unused Routing Tuple with minimum R_metric (if more than one, pick any) and denote it the "current Routing Tuple".
1. 找到具有最小R_度量的未使用路由元组（如果多个，则选择任意），并将其表示为“当前路由元组”。
2. Mark the current Routing Tuple as used.
2. 将当前路由元组标记为已使用。
3. For each Router Topology Tuple, with TR_from_orig_addr = R_dest_addr of the current Routing Tuple:
3. 对于每个路由器拓扑元组，当前路由元组的TR_from_orig_addr=R_dest_addr：
1. Define:
1. 定义：
- new_metric := R_metric of the current Routing Tuple + TR_metric;
- 新的_度量：=当前路由元组的R_度量+TR_度量；
- new_dist := R_dist of the current Routing Tuple + 1.
- new_dist:=当前路由元组的R_dist+1。
2. If there is no Routing Tuple with R_dest_addr = TR_to_orig_addr, then create an unused Routing Tuple with:
2. 如果没有R_dest_addr=TR_to_orig_addr的路由元组，则使用以下内容创建未使用的路由元组：
- R_dest_addr := TR_to_orig_addr;
- R_dest_addr:=TR_to_orig_addr；
- R_next_iface_addr := R_next_iface_addr of the current Routing Tuple;
- R_next_iface_addr:=当前路由元组的R_next_iface_addr；
- R_local_iface_addr := R_local_iface_addr of the current Routing Tuple;
- R_local_iface_addr:=当前路由元组的R_local_iface_addr；
- R_metric := new_metric;
- R_度量：=新的_度量；
- R_dist := new_dist.
- R\u区：=新区。
3. Otherwise, if there is an unused Routing Tuple with R_dest_addr = TR_to_orig_addr, and either new_metric < R_metric or (new_metric = R_metric and the updated Routing Tuple would be preferred), then update this Routing Tuple to have:
3. 否则，如果存在一个未使用的路由元组，其R_dest_addr=TR_to_orig_addr，且新的_度量<R_度量或（新的_度量=R_度量和更新的路由元组将是首选），则更新此路由元组以具有：
- R_next_iface_addr := R_next_iface_addr of the current Routing Tuple;
- R_next_iface_addr:=当前路由元组的R_next_iface_addr；
- R_local_iface_addr := R_local_iface_addr of the current Routing Tuple;
- R_local_iface_addr:=当前路由元组的R_local_iface_addr；
- R_metric := new_metric;
- R_度量：=新的_度量；
- R_dist := new_dist.
- R\u区：=新区。
The following procedure is executed once.
以下过程执行一次。
1. For each Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC:
1. 对于N_symmetric=true且N_out_度量！=未知度量：
1. For each network address (the "neighbor address") in N_neighbor_addr_list, if the neighbor address is not equal to the R_dest_addr of any Routing Tuple, then add a new Routing Tuple, with:
1. 对于N_neighbor_addr_列表中的每个网络地址（“邻居地址”），如果邻居地址不等于任何路由元组的R_dest_addr，则添加一个新的路由元组，包括：
+ R_dest_addr := neighbor address;
+ R_dest_addr:=邻居地址；
+ R_next_iface_addr := selected link address for the neighbor address;
+ R_next_iface_addr:=为邻居地址选择的链路地址；
+ R_local_iface_addr := selected local address for the neighbor address;
+ R_local_iface_addr:=为邻居地址选择的本地地址；
+ R_metric := N_out_metric;
+ R_度量：=N_out_度量；
+ R_dist := 1.
+ R_dist:=1。
The following procedure is executed once.
以下过程执行一次。
1. For each Routable Address Topology Tuple, if:
1. 对于每个可路由地址拓扑元组，如果：
* TA_dest_addr is not equal to the R_dest_addr of any Routing Tuple added in an earlier stage; AND
* TA_dest_addr不等于在早期阶段添加的任何路由元组的R_dest_addr；和
* TA_from_orig_addr is equal to the R_dest_addr of a Routing Tuple (the "previous Routing Tuple"),
* TA_from_orig_addr等于路由元组（“上一个路由元组”）的R_dest_addr，
then add a new Routing Tuple, with:
然后添加一个新的路由元组，包括：
* R_dest_addr := TA_dest_addr;
* R_dest_addr:=TA_dest_addr；
* R_next_iface_addr := R_next_iface_addr of the previous Routing Tuple;
* R_next_iface_addr:=上一路由元组的R_next_iface_addr；
* R_local_iface_addr := R_local_iface_addr of the previous Routing Tuple;
* R_local_iface_addr:=上一个路由元组的R_local_iface_addr；
* R_metric := R_metric of the previous Routing Tuple + TA_metric;
* R_度量：=上一路由元组的R_度量+TA_度量；
* R_dist := R_dist of the previous Routing Tuple + 1.
* R_dist:=上一个路由元组的R_dist+1。
There may be more than one Routing Tuple that may be added for an R_dest_addr in this stage. If so, then for each such R_dest_addr, a Routing Tuple with minimum R_metric MUST be added; otherwise, a Routing Tuple that is preferred SHOULD be added.
在此阶段，可能会为R_dest_addr添加多个路由元组。如果是这样，那么对于每个这样的R_dest_addr，必须添加具有最小R_度量的路由元组；否则，应添加首选的路由元组。
The following procedure is executed once.
以下过程执行一次。
1. For each Attached Network Tuple, if:
1. 对于每个连接的网络元组，如果：
* AN_net_addr is not equal to the R_dest_addr of any Routing Tuple added in an earlier stage; AND
* a_net_addr不等于在早期阶段添加的任何路由元组的R_dest_addr；和
* AN_orig_addr is equal to the R_dest_addr of a Routing Tuple (the "previous Routing Tuple"),
* 原始地址等于路由元组（“上一个路由元组”）的目的地址，
then add a new Routing Tuple, with:
然后添加一个新的路由元组，包括：
* R_dest_addr := AN_net_addr;
* R_dest_addr:=一个网络地址；
* R_next_iface_addr := R_next_iface_addr of the previous Routing Tuple;
* R_next_iface_addr:=上一路由元组的R_next_iface_addr；
* R_local_iface_addr := R_local_iface_addr of the previous Routing Tuple;
* R_local_iface_addr:=上一个路由元组的R_local_iface_addr；
* R_metric := R_metric of the previous Routing Tuple + AN_metric;
* R_度量：=上一路由元组的R_度量+一个R_度量；
* R_dist := R_dist of the previous Routing Tuple + AN_dist.
* R_dist:=上一个路由元组的R_dist+AN_dist。
There may be more than one Routing Tuple that may be added for an R_dest_addr in this stage. If so, then for each such R_dest_addr, a Routing Tuple with minimum R_metric MUST be added; otherwise, a Routing Tuple that is preferred SHOULD be added.
在此阶段，可能会为R_dest_addr添加多个路由元组。如果是这样，那么对于每个这样的R_dest_addr，必须添加具有最小R_度量的路由元组；否则，应添加首选的路由元组。
The following procedure is OPTIONAL according to Section 19.1 and MAY be executed once.
根据第19.1节，以下程序为可选程序，可执行一次。
1. For each 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC, if:
1. 对于每个具有N2_out_度量的2跳元组！=未知度量，如果：
* N2_2hop_addr is a routable address; AND
* N2跃点地址是一个可路由地址；和
* N2_2hop_addr is not equal to the R_dest_addr of any Routing Tuple added in an earlier stage; AND
* N2_2; hop_addr不等于在早期阶段添加的任何路由元组的R_dest_addr；和
* the Routing Tuple with R_dest_addr = N_orig_addr of the corresponding Neighbor Tuple (the "previous Routing Tuple") has R_dist = 1,
* 对应相邻元组（前一个路由元组）的R_dest_addr=N_orig_addr的路由元组的R_dist=1，
then add a new Routing Tuple, with:
然后添加一个新的路由元组，包括：
* R_dest_addr := N2_2hop_addr;
* R_dest_addr:=N2_2hop_addr；
* R_next_iface_addr := R_next_iface_addr of the previous Routing Tuple;
* R_next_iface_addr:=上一路由元组的R_next_iface_addr；
* R_local_iface_addr := R_local_iface_addr of the previous Routing Tuple;
* R_local_iface_addr:=上一个路由元组的R_local_iface_addr；
* R_metric := R_metric of the previous Routing Tuple + N_out_metric of the corresponding Neighbor Tuple;
* R_度量：=上一路由元组的R_度量+N_out_度量；
* R_dist := 2.
* R_dist:=2。
There may be more than one Routing Tuple that may be added for an R_dest_addr in this stage. If so, then for each such R_dest_addr, a Routing Tuple with minimum R_metric MUST be added; otherwise, a Routing Tuple that is preferred SHOULD be added.
在此阶段，可能会为R_dest_addr添加多个路由元组。如果是这样，那么对于每个这样的R_dest_addr，必须添加具有最小R_度量的路由元组；否则，应添加首选的路由元组。
TC messages are instances of [RFC5444] messages. This specification requires that TC messages contain <msg-hop-limit> and <msg-orig-addr> fields. It supports TC messages with any combination of remaining message header options and address encodings enabled by [RFC5444] that convey the required information. As a consequence, there is no single way to represent how all TC messages look. This appendix illustrates a TC message; the exact values and content included are explained in the following text.
TC消息是[RFC5444]消息的实例。本规范要求TC消息包含<msg hop limit>和<msg orig addr>字段。它支持TC消息以及[RFC5444]启用的剩余消息头选项和地址编码的任意组合，以传递所需信息。因此，没有单一的方法来表示所有TC消息的外观。本附录说明了TC信息；下文将解释包含的确切值和内容。
The TC message's four-bit Message Flags (MF) field has a value of 15, indicating that the message header contains originator address, hop limit, hop count, and message sequence number fields. Its four-bit Message Address Length (MAL) field has value 3, indicating addresses in the message have a length of four octets, here being IPv4 addresses. The overall message length is 75 octets.
TC消息的四位消息标志（MF）字段的值为15，表示消息头包含发起者地址、跃点限制、跃点计数和消息序列号字段。其四位消息地址长度（MAL）字段的值为3，表示消息中的地址长度为四个八位字节，这里是IPv4地址。消息的总长度为75个八位字节。
The message has a Message TLV Block with a content length of 17 octets containing four TLVs. The first two TLVs are validity and interval times for the message. The third TLV is the content sequence number TLV used to carry the 2-octet ANSN and (with default type extension zero, i.e., COMPLETE) indicates that the TC message is complete. The fourth TLV contains forwarding and routing willingness values for the originating router (FWILL and RWILL, respectively). Each TLV uses a TLV with Flags octet (MTLVF) value 16, indicating
该消息有一个消息TLV块，其内容长度为17个八位字节，包含四个TLV。前两个TLV是消息的有效性和间隔时间。第三个TLV是用于承载2-octet ANSN的内容序列号TLV（默认类型扩展名为零，即COMPLETE），表示TC消息已完成。第四个TLV包含发起路由器的转发和路由意愿值（分别为FWILL和RWILL）。每个TLV使用一个TLV，其标志八位字节（MTLVF）值为16，表示
that it has a Value, but no type extension or start and stop indexes. The first two TLVs have a Value Length of 1 octet; the last has a Value Length of 2 octets.
它有一个值，但没有类型扩展或开始和停止索引。前两个TLV的值长度为1个八位组；最后一个值的长度为2个八位字节。
The message has two Address Blocks. (This is not necessary. The information could be conveyed using a single Address Block; the use of two Address Blocks, which is also allowed, is illustrative only.) The first Address Block contains 3 addresses, with Flags octet (ABF) value 128, hence with a Head section (with length 2 octets) but no Tail section and with Mid sections with length two octets. The following TLV Block (content length 13 octets) contains two TLVs. The first TLV is a NBR_ADDR_TYPE TLV with Flags octet (ATLVF) value 16, indicating a single Value but no indexes. Thus, all these addresses are associated with the Value (with Value Length 1 octet) ROUTABLE_ORIG, i.e., they are originator addresses of advertised neighbors that are also routable addresses. The second TLV is a LINK_METRIC TLV with Flags octet (ATLVF) value 20, indicating a Value for each address, i.e., as the total Value Length is 6 octets, each address is associated with a Value with length two octets. These Value fields are each shown as having four bits indicating that they are outgoing neighbor metric values and as having twelve bits that represent the metric value (the first four bits being the exponent, the remaining eight bits the mantissa).
该消息有两个地址块。（这是不必要的。可以使用单个地址块来传输信息；也允许使用两个地址块，这只是说明性的。）第一个地址块包含3个地址，标志八位字节（ABF）值128，因此具有一个头部部分（长度为2个八位字节）但没有尾部，中部有两个八位组。以下TLV块（内容长度为13个八位字节）包含两个TLV。第一个TLV是一个NBR_ADDR_类型的TLV，其标志八位字节（ATLVF）值为16，表示一个值，但没有索引。因此，所有这些地址都与值（值长度为1个八位字节）可路由源相关联，即，它们是播发的邻居的发起者地址，也是可路由地址。第二个TLV是具有标志八位字节（ATLVF）值20的链路度量TLV，指示每个地址的值，即，由于总值长度为6个八位字节，每个地址与长度为两个八位字节的值相关联。这些值字段分别显示为具有四位，表示它们是传出的相邻度量值，以及具有十二位，表示度量值（前四位为指数，其余八位为尾数）。
The second Address Block contains 1 address, with Flags octet (ATLVF) 176, indicating that there is a Head section (with length 2 octets), that the Tail section (with length 2 octets) consists of zero valued octets (not included), and that there is a single prefix length, which is 16. The network address is thus Head.0.0/16. The following TLV Block (content length 9 octets) includes two TLVs. The first has a Flags octet (ATLVF) of 16, again indicating that no indexes are needed, but that a Value (with Value Length 1 octet) is present, indicating the address distance as a number of hops. The second TLV is another LINK_METRIC TLV, as in the first Address TLV Block except with a Flags octet (ATLVF) value 16, indicating that a single Value is present.
第二个地址块包含1个地址，其标志为八位字节（ATLVF）176，表示有一个头段（长度为2个八位字节），尾段（长度为2个八位字节）由零值八位字节组成（不包括），并且有一个前缀长度为16。因此，网络地址为Head.0.0/16。以下TLV块（内容长度为9个八位字节）包括两个TLV。第一个具有16个标志八位字节（ATLVF），再次表明不需要索引，但存在一个值（值长度为1个八位字节），以跳数表示地址距离。第二个TLV是另一个链路度量TLV，与第一个地址TLV块中的TLV相同，但带有标志八位字节（ATLVF）值16，表示存在单个值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MF=15 | MAL=3 | Message Length = 75 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 17 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | CONT_SEQ_NUM | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 2 | Value (ANSN) | MPR_WILLING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTLVF = 16 | Value Len = 1 | FWILL | RWILL | Num Addrs = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ABF = 128 | Head Len = 2 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Address TLV Block Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBR_ADDR_TYPE | ATLVF = 16 | Value Len = 1 | ROUTABLE_ORIG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_METRIC | ATLVF = 20 | Value Len = 6 |0|0|0|1|Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (cont) |0|0|0|1| Metric |0|0|0|1|Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (cont) | Num Addrs = 1 | ABF = 176 | Head Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | Tail Len = 2 | Pref Len = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address TLV Block Length = 9 | GATEWAY | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Hops) | LINK_METRIC | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 2 |0|0|0|1| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MF=15 | MAL=3 | Message Length = 75 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 17 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | CONT_SEQ_NUM | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 2 | Value (ANSN) | MPR_WILLING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTLVF = 16 | Value Len = 1 | FWILL | RWILL | Num Addrs = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ABF = 128 | Head Len = 2 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Address TLV Block Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBR_ADDR_TYPE | ATLVF = 16 | Value Len = 1 | ROUTABLE_ORIG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_METRIC | ATLVF = 20 | Value Len = 6 |0|0|0|1|Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (cont) |0|0|0|1| Metric |0|0|0|1|Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (cont) | Num Addrs = 1 | ABF = 176 | Head Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | Tail Len = 2 | Pref Len = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address TLV Block Length = 9 | GATEWAY | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Hops) | LINK_METRIC | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 2 |0|0|0|1| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Due to its proactive nature, this protocol has a natural control over the flow of its control traffic. Routers transmit control messages at predetermined rates specified and bounded by message intervals.
由于其主动性，该协议对其控制流量具有自然控制。路由器以预定的速率发送控制消息，该速率由消息间隔指定并限定。
This protocol employs [RFC6130] for local signaling, embedding MPR selection advertisement through a simple Address Block TLV and router willingness advertisement (if any) as a single Message TLV. Local signaling, therefore, shares the characteristics and constraints of [RFC6130].
该协议使用[RFC6130]进行本地信令，通过简单的地址块TLV嵌入MPR选择广告，并将路由器意愿广告（如果有）作为单个消息TLV。因此，本地信令共享[RFC6130]的特征和约束。
Furthermore, the use of MPRs can greatly reduce the signaling overhead from link state information dissemination in two ways, attaining both flooding reduction and topology reduction. First, using MPR flooding, the cost of distributing link state information throughout the network is reduced, as compared to when using blind flooding, since only MPRs need to forward link state declaration messages. Second, the amount of link state information for a router to declare is reduced; it only needs to contain that router's MPR selectors. This reduces the size of a link state declaration as compared to declaring full link state information. In particular, some routers may not need to declare any such information. In dense networks, the reduction of control traffic can be of several orders of magnitude compared to routing protocols using blind flooding [MPR]. This feature naturally provides more bandwidth for useful data traffic and further pushes the frontier of congestion.
此外，MPR的使用可以通过两种方式大大减少链路状态信息传播的信令开销，实现洪泛减少和拓扑减少。首先，与使用盲泛洪时相比，使用MPR泛洪时，在整个网络中分发链路状态信息的成本降低，因为只有MPR需要转发链路状态声明消息。第二，减少路由器要声明的链路状态信息量；它只需要包含路由器的MPR选择器。与声明完整的链接状态信息相比，这减少了链接状态声明的大小。特别是，一些路由器可能不需要声明任何此类信息。在密集网络中，与使用盲泛洪[MPR]的路由协议相比，控制流量的减少可以达到几个数量级。这一特性自然为有用的数据流量提供了更多的带宽，并进一步推动了拥塞的前沿。
Since the control traffic is continuous and periodic, it keeps the quality of the links used in routing more stable. However, using some options, some control messages (HELLO messages or TC messages) may be intentionally sent in advance of their deadline in order to increase the responsiveness of the protocol to topology changes. This may cause a small, temporary, and local increase of control traffic; however, this is at all times bounded by the use of minimum message intervals.
由于控制流量是连续的和周期性的，它使路由中使用的链路的质量更加稳定。然而，使用一些选项，一些控制消息（HELLO消息或TC消息）可以在其截止日期之前被有意地发送，以便增加协议对拓扑更改的响应。这可能会导致控制流量的小型、临时和局部增加；但是，这始终受到使用最小消息间隔的限制。
A router that recognizes that the network is suffering from congestion can increase its message interval parameters. If this is done by most or all routers in the network, then the overall control traffic in the network will be reduced. When using this capability, routers will have to take care not to increase message interval parameters such that they cannot cope with network topology changes. Note that routers can make such decisions independently; it is not necessary for all routers to be using the same parameter values, nor is it necessary that all routers decide to change their intervals at the same time.
识别网络拥塞的路由器可以增加其消息间隔参数。如果这是由网络中的大多数或所有路由器完成的，那么网络中的总体控制流量将减少。在使用此功能时，路由器必须注意不要增加消息间隔参数，以免无法应对网络拓扑变化。注意，路由器可以独立地做出这样的决定；并非所有路由器都必须使用相同的参数值，也不是所有路由器都必须同时决定更改其间隔。
Authors' Addresses
作者地址
Thomas Heide Clausen LIX, Ecole Polytechnique
托马斯·海德·克劳森·利克斯，理工学院
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
克里斯托弗·迪尔洛夫英国切姆斯福德大巴德西汉宁菲尔德路BAE系统先进技术中心
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Philippe Jacquet Alcatel-Lucent Bell Labs
菲利普雅克阿尔卡特朗讯贝尔实验室
Phone: +33 6 7337 1880
EMail: philippe.jacquet@alcatel-lucent.com
Phone: +33 6 7337 1880
EMail: philippe.jacquet@alcatel-lucent.com
Ulrich Herberg Fujitsu Laboratories of America 1240 E. Arques Ave. Sunnyvale, CA 94085 USA
美国加利福尼亚州桑尼维尔阿克斯大道东1240号乌尔里希·赫伯格富士通实验室，邮编94085
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
EMail: ulrich@herberg.name
URI: http://www.herberg.name/