Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7722 BAE Systems
Updates: 7188, 7631 T. Clausen
Category: Experimental LIX, Ecole Polytechnique
ISSN: 2070-1721 December 2015
Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7722 BAE Systems
Updates: 7188, 7631 T. Clausen
Category: Experimental LIX, Ecole Polytechnique
ISSN: 2070-1721 December 2015
Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
优化链路状态路由协议版本2（OLSRv2）的多拓扑扩展
Abstract
摘要
This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
本规范描述了优化链路状态路由协议版本2（OLSRv2）的扩展，以支持多种路由拓扑，同时保留与未实现此扩展的OLSRv2路由器的互操作性。
This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.
本规范通过修改和扩展TLV注册表和说明来更新RFCs 7188和7631。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7722.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7722.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Motivation and Experimentation .............................4
2. Terminology and Notation ........................................5
3. Applicability Statement .........................................6
4. Protocol Overview and Functioning ...............................6
5. Parameters ......................................................8
6. Information Bases ...............................................9
6.1. Local Attached Network Set .................................9
6.2. Link Sets ..................................................9
6.3. 2-Hop Sets .................................................9
6.4. Neighbor Set ...............................................9
6.5. Router Topology Set .......................................10
6.6. Routable Address Topology Set .............................10
6.7. Attached Network Set ......................................10
6.8. Routing Sets ..............................................11
7. TLVs ...........................................................11
7.1. Message TLVs ..............................................11
7.1.1. MPR_TYPES TLV ......................................11
7.1.2. MPR_WILLING TLV ....................................11
7.2. Address Block TLVs ........................................12
7.2.1. LINK_METRIC TLV ....................................12
7.2.2. MPR TLV ............................................13
7.2.3. GATEWAY TLV ........................................13
8. HELLO Messages .................................................14
8.1. HELLO Message Generation ..................................14
8.2. HELLO Message Processing ..................................15
9. TC Messages ....................................................15
9.1. TC Message Generation .....................................15
9.2. TC Message Processing .....................................16
10. MPR Calculation ...............................................16
11. Routing Set Calculation .......................................17
12. Management Considerations .....................................17
13. IANA Considerations ...........................................18
13.1. Expert Review: Evaluation Guidelines .....................18
13.2. Message TLV Types ........................................18
13.3. Address Block TLV Types ..................................20
14. Security Considerations .......................................21
15. References ....................................................22
15.1. Normative References .....................................22
15.2. Informative References ...................................22
Acknowledgments ...................................................23
Authors' Addresses ................................................23
1. Introduction ....................................................4
1.1. Motivation and Experimentation .............................4
2. Terminology and Notation ........................................5
3. Applicability Statement .........................................6
4. Protocol Overview and Functioning ...............................6
5. Parameters ......................................................8
6. Information Bases ...............................................9
6.1. Local Attached Network Set .................................9
6.2. Link Sets ..................................................9
6.3. 2-Hop Sets .................................................9
6.4. Neighbor Set ...............................................9
6.5. Router Topology Set .......................................10
6.6. Routable Address Topology Set .............................10
6.7. Attached Network Set ......................................10
6.8. Routing Sets ..............................................11
7. TLVs ...........................................................11
7.1. Message TLVs ..............................................11
7.1.1. MPR_TYPES TLV ......................................11
7.1.2. MPR_WILLING TLV ....................................11
7.2. Address Block TLVs ........................................12
7.2.1. LINK_METRIC TLV ....................................12
7.2.2. MPR TLV ............................................13
7.2.3. GATEWAY TLV ........................................13
8. HELLO Messages .................................................14
8.1. HELLO Message Generation ..................................14
8.2. HELLO Message Processing ..................................15
9. TC Messages ....................................................15
9.1. TC Message Generation .....................................15
9.2. TC Message Processing .....................................16
10. MPR Calculation ...............................................16
11. Routing Set Calculation .......................................17
12. Management Considerations .....................................17
13. IANA Considerations ...........................................18
13.1. Expert Review: Evaluation Guidelines .....................18
13.2. Message TLV Types ........................................18
13.3. Address Block TLV Types ..................................20
14. Security Considerations .......................................21
15. References ....................................................22
15.1. Normative References .....................................22
15.2. Informative References ...................................22
Acknowledgments ...................................................23
Authors' Addresses ................................................23
The Optimized Link State Routing Protocol version 2 [RFC7181] (OLSRv2) is a proactive link state routing protocol designed for use in Mobile Ad Hoc Networks (MANETs) [RFC2501]. One of the significant improvements of OLSRv2 over its Experimental precursor [RFC3626] is the ability of OLSRv2 to use link metrics to select routes other than minimum hop routes.
优化链路状态路由协议版本2[RFC7181]（OLSRv2）是一种主动链路状态路由协议，设计用于移动自组织网络（MANET）[RFC2501]。OLSRv2相对于其实验前体[RFC3626]的一个显著改进是，OLSRv2能够使用链路度量选择除最小跳数路由之外的路由。
A limitation that remains in OLSRv2 is that it uses a single link metric type for all routes. However, in some MANETs it would be desirable to be able to route packets using more than one link metric type. This specification describes an extension to OLSRv2 that is designed to permit this, while maintaining maximal interoperability with OLSRv2 routers not implementing this extension.
OLSRv2中仍然存在的一个限制是，它对所有路由使用单一链路度量类型。然而，在一些MANET中，希望能够使用一种以上的链路度量类型来路由分组。本规范描述了OLSRv2的一个扩展，该扩展旨在实现这一点，同时保持与未实现此扩展的OLSRv2路由器的最大互操作性。
The purpose of OLSRv2 can be described as to create and maintain a Routing Set, which contains all the necessary information to populate an IP routing table. In a similar way, the role of this extension can be described as to create and maintain multiple Routing Sets, one for each link metric type supported by the router maintaining the sets.
OLSRv2的目的可以描述为创建和维护路由集，其中包含填充IP路由表所需的所有信息。以类似的方式，此扩展的作用可以描述为创建和维护多个路由集，每个路由集对应于维护这些路由集的路由器支持的每个链路度量类型。
Multi-topology routing is a natural extension to a link state routing protocol, such as OSPF (see [RFC4915]). However multi-topology routing for OLSRv2 does not yet benefit from extensive operational, or even experimental, experience. This specification is published to facilitate collecting such experience, with the intent that once suitable experimental evidence has been collected, an OLSRv2 Multi-Topology Routing Extension will be proposed for advancement onto the Standards Track.
多拓扑路由是链路状态路由协议（如OSPF）的自然扩展（参见[RFC4915]）。然而，OLSRv2的多拓扑路由尚未从广泛的操作或实验经验中获益。发布本规范是为了便于收集此类经验，目的是一旦收集到合适的实验证据，将提出OLSRv2多拓扑路由扩展，以推进标准轨道。
Any experiments using this protocol extension are encouraged. Reports from such experiments planned with pre-specified objectives and scenarios (including link, position, and mobility information) are particularly encouraged. Results from such experiments, documenting the following, are of particular importance:
鼓励使用此协议扩展的任何实验。特别鼓励使用预先指定的目标和场景（包括链接、位置和移动信息）计划的此类实验报告。记录以下内容的此类实验结果尤其重要：
o Operation in networks that contain both routers implementing this extension and routers implementing only [RFC7181]. In particular, are there any unexpected interactions that can break the network?
o 包含实现此扩展的路由器和仅实现[RFC7181]的路由器的网络中的操作。特别是，是否存在任何可能破坏网络的意外交互？
o Operation in networks with dynamic topologies, both due to mobility and due to link metric changes for reasons other than mobility.
o 在具有动态拓扑的网络中的操作，这是由于移动性和由于除移动性以外的原因导致的链路度量变化。
o Operation in realistic deployments, and details thereof, including how many concurrent topologies were required.
o 实际部署中的操作及其详细信息，包括需要多少并发拓扑。
o Behavior of Routing Sets, including measures of successful route establishment.
o 路由集的行为，包括成功建立路由的措施。
In addition, reports from experiments covering the following are also of value:
此外，涵盖以下内容的实验报告也很有价值：
o Which link metric types were useful, and how the metrics to associate with a given link were established.
o 哪些链接度量类型有用，以及如何建立与给定链接关联的度量。
o How packet types were associated with link metric types (whether using Diffserv or an alternative mechanism).
o 数据包类型与链路度量类型的关联方式（无论是使用Diffserv还是其他机制）。
o Any data link-layer issues, and any cross-layer issues, including whether and how Neighborhood Discovery Protocol (NHDP) link quality was used.
o 任何数据链路层问题和任何跨层问题，包括是否以及如何使用邻域发现协议（NHDP）链路质量。
o Transport- and higher-layer issues observed, if any.
o 观察到的传输层和更高层问题（如有）。
o Resource requirements observed from running the protocol, including processing, storage, and bandwidth.
o 从运行协议中观察到的资源需求，包括处理、存储和带宽。
o Network performance, including packet delivery results.
o 网络性能，包括数据包交付结果。
o Any other implementation issues.
o 任何其他实施问题。
The first bullet in the list directly above applies to unextended OLSRv2 [RFC7181] as well as with this extension, and potentially to other MANET routing protocols. This specification also allows experimentation with link metric types that are not compromises for handling multiple traffic types.
上面列表中的第一个项目符号适用于未扩展的OLSRv2[RFC7181]以及此扩展，并且可能适用于其他MANET路由协议。该规范还允许对链路度量类型进行试验，这些类型不会影响处理多个流量类型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This specification uses the terminology of [RFC5444], [RFC6130], and [RFC7181], which is to be interpreted as described in those specifications.
本规范使用[RFC5444]、[RFC6130]和[RFC7181]的术语，这些术语将按照这些规范中所述进行解释。
Additionally, this specification uses the following terminology:
此外，本规范使用以下术语：
Router - A MANET router that implements [RFC7181].
路由器-实现[RFC7181]的MANET路由器。
MT-OLSRv2 - The protocol defined in this specification as an extension to OLSRv2 [RFC7181].
MT-OLSRv2——本规范中定义的协议，作为OLSRv2[RFC7181]的扩展。
This specification introduces the notation map[A -> B] to represent an associative mapping. The domain of this mapping (A) is, in this specification, always a set of link metric types that the router supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as defined in Section 5. The codomain of this mapping (B) is a set of all possible values of an appropriate type. In this specification, this type is always one of:
本规范引入符号映射[A->B]来表示关联映射。在本规范中，该映射（A）的域始终是路由器支持的一组链路度量类型：如第5节所定义的IFACE_度量_类型或路由器_度量_类型。该映射（B）的编码域是一组适当类型的所有可能值。在本规范中，该类型始终为以下类型之一：
o boolean (true or false),
o 布尔值（真或假），
o willingness (a 4-bit unsigned integer from 0 to 15),
o （0到15之间的4位无符号整数），
o number of hops (an 8-bit unsigned integer from 0 to 255), or
o 跳数（从0到255的8位无符号整数），或
o link metric (either a representable link metric value, as described in [RFC7181], or UNKNOWN_METRIC).
o 链路度量（如[RFC7181]中所述的可表示链路度量值，或未知的_度量）。
The protocol described in this specification is applicable to a MANET for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), but in which multiple topologies are maintained, each characterized by a different choice of link metric type. It is assumed, but outside the scope of this specification, that the network layer is able to choose which topology to use for each packet, for example, using the Diffserv Code Point (DSCP) defined in [RFC2474]. This selection of topology MUST be consistent; that is, each router receiving a packet must make the same choice of link metric type, in order that each packet uses a single topology. This is necessary to avoid the possibility of a packet "looping" in the network.
本规范中描述的协议适用于OLSRv2在其他方面适用的MANET（参见[RFC7181]，第3节），但其中维护了多个拓扑，每个拓扑的特征是不同的链路度量类型选择。假设网络层能够选择每个数据包使用的拓扑，例如，使用[RFC2474]中定义的区分服务码点（DSCP），但不在本规范的范围内。这种拓扑选择必须是一致的；也就是说，每个接收数据包的路由器必须对链路度量类型进行相同的选择，以便每个数据包使用单个拓扑。这对于避免网络中数据包“循环”的可能性是必要的。
The purpose of this specification is to extend OLSRv2 [RFC7181] so as to enable a router to establish and maintain multiple routing topologies in a MANET, each topology associated with a link metric type. Routers in the MANET may each form part of some or all of these topologies, and each router will maintain a Routing Set for each topology that it forms part of, allowing separate routing of packets for each topology.
本规范的目的是扩展OLSRv2[RFC7181]，以便使路由器能够在MANET中建立和维护多个路由拓扑，每个拓扑与链路度量类型相关。MANET中的路由器可以各自构成这些拓扑中的一些或所有拓扑的一部分，并且每个路由器将为其所构成的每个拓扑维护路由集，从而允许对每个拓扑的分组进行单独路由。
MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 routers) and routers that do not implement MT-OLSRv2 and may be unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be
MT-OLSRv2设计用于与OLSRv2互操作；可以创建包含实现MT-OLSRv2的路由器（MT-OLSRv2路由器）和不实现MT-OLSRv2且可能不知道其存在的路由器（非MT-OLSRv2路由器）的MANET。移动自组网也可能是
created that are known to contain only MT-OLSRv2 routers. In both cases, but especially where a MANET contains both MT-OLSRv2 routers and non-MT-OLSRv2 routers, management may be required to ensure that the MANET will function as required, and will not, for example, unnecessarily fragment. (Such issues already arise in an OLSRv2-based MANET using multiple interfaces.)
创建了已知仅包含MT-OLSRv2路由器的。在这两种情况下，尤其是在MANET同时包含MT-OLSRv2路由器和非MT-OLSRv2路由器的情况下，可能需要进行管理，以确保MANET将根据需要工作，并且不会（例如）不必要地分割。（在使用多个接口的基于OLSRv2的MANET中已经出现了此类问题。）
OLSRv2 is an extension of NHDP [RFC6130]. However, the extension in this specification does not modify NHDP, it only modifies Protocol Sets that are specific to OLSRv2, or elements in Protocol Tuples that were added by OLSRv2 and that are neither included in nor used by NHDP. In addition it does not use or modify the link quality mechanism in [RFC6130].
OLSRv2是NHDP[RFC6130]的扩展。但是，本规范中的扩展不修改NHDP，它只修改特定于OLSRv2的协议集，或OLSRv2添加的协议元组中既不包含也不由NHDP使用的元素。此外，它不使用或修改[RFC6130]中的链路质量机制。
Each router implementing this specification selects a set of link metric types for each of its OLSRv2 interfaces. If all routers in the MANET implement MT-OLSRv2, then there are no restrictions within this specification on how these sets of link metrics are selected. (However, the issues described in the preceding paragraph still apply.) On the other hand, in MANETs containing non-MT-OLSRv2 routers, the single link metric used by these non-MT-OLSRv2 routers must be included in the set of link metrics for each OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non-MT-OLSRv2 router in the MANET.
实现此规范的每个路由器为其每个OLSRv2接口选择一组链路度量类型。如果MANET中的所有路由器都实现MT-OLSRv2，则本规范中没有关于如何选择这些链路度量集的限制。（然而，上一段中描述的问题仍然适用。）另一方面，在包含非MT-OLSRv2路由器的MANET中，这些非MT-OLSRv2路由器使用的单链路度量必须包括在MT-OLSRv2路由器的每个OLSRv2接口的链路度量集合中，该链路度量集合可以在MANET中的非MT-OLSRv2路由器的OLSRv2接口上听到。
Each router then determines an incoming link metric for each link metric type selected for each of its OLSRv2 interfaces. These link metrics are distributed using link metric TLVs contained in all HELLO messages sent on OLSRv2 interfaces and in all TC messages. Unless using only the single metric type used by non-MT-OLSRv2 routers, both HELLO and TC messages generated by an MT-OLSRv2 router include an MPR_TYPES Message TLV that indicates that this is an MT-OLSRv2 router and which metric types it supports (on the sending OLSRv2 interface for a HELLO message).
然后，每个路由器为其每个OLSRv2接口选择的每个链路度量类型确定传入链路度量。使用OLSRv2接口上发送的所有HELLO消息和所有TC消息中包含的链路度量TLV分发这些链路度量。除非仅使用非MT-OLSRv2路由器使用的单一度量类型，否则MT-OLSRv2路由器生成的HELLO和TC消息都包括MPR_类型消息TLV，指示这是一个MT-OLSRv2路由器及其支持的度量类型（在发送HELLO消息的OLSRv2接口上）。
An MT-OLSRv2 router maintains, for each supported neighbour metric type and for each symmetric 1-hop neighbor, the following:
MT-OLSRv2路由器为每个受支持的邻居度量类型和每个对称1跳邻居维护以下内容：
o link and neighbour metric values,
o 链路和相邻度量值，
o routing MPR status,
o 路由MPR状态，
o routing MPR selector status, and
o 路由MPR选择器状态，以及
o advertised neighbour status.
o 宣传邻居身份。
Each router may choose a different willingness to be a routing MPR for each link metric type that it supports.
每个路由器可以为其支持的每个链路度量类型选择不同的路由MPR。
A network using MT-OLSRv2 will usually require greater management than one using unmodified OLSRv2. In particular, the use of multiple metric types across the MANET must be managed, by administrative configuration or otherwise. As also for other decisions that may be made when using OLSRv2, a bad collective choice of metric type use will make the MANET anywhere from inefficient to nonfunctional, so care will be needed in selecting supported link metric types across the MANET.
使用MT-OLSRv2的网络通常比使用未修改的OLSRv2的网络需要更大的管理。特别是，必须通过管理配置或其他方式管理MANET中多个度量类型的使用。对于使用OLSRv2时可能做出的其他决定，度量类型使用的错误集体选择将使MANET从低效到无功能，因此在选择整个MANET中支持的链路度量类型时需要小心。
The meanings of link metric types are at the discretion of the MANET operator. They could be used, for example, to represent packets of different types, packets in streams of different rates, or packets with different trust requirements. Note that packets will generally not be delivered to routers that do not support that link metric type, and the MANET, and the packets sent in it, will need to be managed accordingly (especially if the MANET contains any non-MT-OLSRv2 routers).
链路度量类型的含义由MANET操作员决定。例如，它们可用于表示不同类型的分组、不同速率的流中的分组或具有不同信任要求的分组。注意，数据包通常不会被传送到不支持该链路度量类型的路由器，并且MANET以及在其中发送的数据包将需要相应地管理（特别是如果MANET包含任何非MT-OLSRv2路由器）。
The parameters used in [RFC7181], and in its normative references, are used in this specification with the following changes.
[RFC7181]及其规范性参考文件中使用的参数在本规范中使用，但有以下更改。
Each OLSRv2 interface will support a number of link metric types, corresponding to Type Extensions of the LINK_METRIC TLV defined in [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers that do not implement MT-OLSRv2, and used with that definition in this specification, is replaced in routers implementing MT-OLSRv2 by an interface parameter array IFACE_METRIC_TYPES and a router parameter array ROUTER_METRIC_TYPES. Each element in these arrays is a link metric type (i.e., a type extension used by the LINK_METRIC TLV [RFC7181]).
每个OLSRv2接口将支持多种链路度量类型，对应于[RFC7181]中定义的链路度量TLV的类型扩展。未实现MT-OLSRv2的路由器使用的路由器参数链路度量类型（与本规范中的定义一起使用）在实现MT-OLSRv2的路由器中被接口参数数组IFACE度量类型和路由器参数数组路由器度量类型替换。这些数组中的每个元素都是链路度量类型（即链路度量TLV[RFC7181]使用的类型扩展）。
The interface parameter array IFACE_METRIC_TYPES contains the link metric types supported on that OLSRv2 interface. The router parameter array ROUTER_METRIC_TYPES is the union of all of the IFACE_METRIC_TYPES. Both arrays MUST be without repetitions.
接口参数数组IFACE_METRIC_TYPES包含该OLSRv2接口支持的链接度量类型。路由器参数数组router_METRIC_TYPES是所有IFACE_METRIC_类型的并集。两个数组必须不重复。
If in a given deployment there might be routers that do not implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE as its first element, so that the OLSRv2 interface can communicate with those routers. In that case, ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE as its first element.
如果在给定的部署中，可能存在未实现MT-OLSRv2的路由器，则IFACE_METRIC_类型必须包括LINK_METRIC_类型作为其第一个元素，以便OLSRv2接口可以与这些路由器通信。在这种情况下，路由器度量类型还必须包括链路度量类型作为其第一个元素。
In addition, the router parameter WILL_ROUTING is extended to an array of values, one each for each link metric type in the router parameter list ROUTER_METRIC_TYPES.
此外，路由器参数WILL_ROUTING扩展为一个值数组，路由器参数列表router_metric_TYPES中的每个链路度量类型对应一个值数组。
The Information Bases specified in [RFC7181], which extend those specified in [RFC6130], are further extended in this specification. With the exception of the Routing Set, the extensions in this specification are the replacement of single values (boolean, willingness, number of hops, or link metric) from [RFC7181] with elements representing multiple values (associative mappings from a set of metric types to their corresponding values). The following subsections detail these extensions.
[RFC7181]中规定的信息库扩展了[RFC6130]中规定的信息库，并在本规范中进一步扩展。除路由集外，本规范中的扩展将[RFC7181]中的单个值（布尔值、意愿值、跳数或链路度量）替换为表示多个值的元素（从一组度量类型到其相应值的关联映射）。以下小节详细介绍了这些扩展。
Note that, as in [RFC7181], an implementation is free to organize its internal data in any manner it chooses; it needs only to behave as if it were organized as described in [RFC7181] and this specification.
注意，与[RFC7181]一样，实现可以自由地以其选择的任何方式组织其内部数据；它只需按照[RFC7181]和本规范中所述的方式进行组织。
Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops].
每个元素都成为一个映射[路由器度量类型->跳数]。
Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
每个元素的所有度量都成为一个映射[路由器度量类型->链接度量]。
Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link metric].
度量中的每个元素L\u成为一个映射[IFACE\u metric\u TYPES->link metric]。
Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link metric].
每个元素的L_out_度量都成为一个映射[IFACE_metric_TYPES->link metric]。
The elements of L_in_metric MUST be set following the same rules that apply to the setting of the single element L_in_metric in [RFC7181].
必须按照[RFC7181]中适用于单个元素L_in_度量设置的相同规则设置L_in_度量的元素。
Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
_度量中的每个元素N2_成为一个映射[路由器_度量\u类型->链路度量]。
Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
每个元素N2\u out\u度量成为一个映射[路由器\u度量\u类型->链接度量]。
Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
_度量中的每个元素N_成为一个映射[路由器_度量类型->链接度量]。
Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
每个元素N\u out\u度量成为一个映射[ROUTER\u metric\u TYPES->link metric]。
Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> willingness].
每个元素N\u将\u路由成为一个映射[路由器\u度量\u类型->意愿]。
Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> boolean].
每个元素N_routing_mpr成为一个映射[路由器度量类型->布尔]。
Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> boolean].
每个元素N\u mpr\u选择器成为一个映射[路由器\u度量\u类型->布尔]。
Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> boolean].
每个元素N_广告成为一个映射[路由器度量类型->布尔]。
Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
每个元素TR_度量成为一个映射[路由器度量类型->链路度量]。
Note that some values of TR_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Router Topology Tuples whose corresponding value from TR_metric is UNKNOWN_METRIC are ignored.
请注意，TR_度量的某些值现在可能采用未知值_度量。当用于构造路由集时，如果仅使用此映射中对应的链路度量值，则忽略TR_metric中对应值为UNKNOWN_metric的路由器拓扑元组。
Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
每个元素TA_度量成为一个映射[路由器_度量类型->链接度量]。
Note that some values of TA_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Routable Address Topology Tuples whose corresponding value from TA_metric is UNKNOWN_METRIC are ignored.
请注意，TA_度量的某些值现在可能采用未知值_度量。当用于构造路由集时，如果仅使用此映射中对应的链路度量值，则忽略其对应的TA_度量值为UNKNOWN_度量值的可路由地址拓扑元组。
Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops].
一个距离的每个元素都成为一个映射[路由器度量类型->跳数]。
Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
每个元素都成为一个映射[路由器度量类型->链接度量]。
Note that some values of AN_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Attached
请注意，某个度量的某些值现在可能采用未知的值。当用于构造路由集（其中仅使用此映射中相应的链路度量值）时，附加
Network Tuples whose corresponding value from AN_metric is UNKNOWN_METRIC are ignored.
忽略来自某个度量的对应值为未知度量的网络元组。
There is a separate Routing Set for each link metric type in ROUTER_METRIC_TYPES.
路由器度量类型中的每个链路度量类型都有一个单独的路由集。
This specification makes the following additions and extensions to the TLVs defined in [RFC7181].
本规范对[RFC7181]中定义的TLV进行了以下添加和扩展。
One new Message TLV is defined in this specification, and one existing Message TLV is extended by this specification.
本规范中定义了一个新的消息TLV，并通过本规范扩展了一个现有的消息TLV。
The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 interfaces and TC messages. A message MUST NOT contain more than one MPR_TYPES TLV.
MPR_类型TLV用于通过OLSRv2接口发送的HELLO消息和TC消息。消息不能包含多个MPR_类型TLV。
The presence of this TLV in a message is used to indicate that the router supports MT-OLSRv2, in the same way that the presence of the MPR_WILLING TLV is used to indicate that the router supports OLSRv2, as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has been defined with the same Type as the MPR_WILLING TLV, but with Type Extension = 1.
如[RFC7181]所述，消息中存在该TLV用于指示路由器支持MT-OLSRv2，与存在MPR\u TLV用于指示路由器支持OLSRv2的方式相同。因此，MPR_类型TLV已定义为与MPR_类型TLV相同的类型，但类型扩展=1。
This TLV may take a Value field of any size. Each octet in its Value field will contain a link metric type that is supported, either on any OLSRv2 interface, when included in a TC message, or on the OLSRv2 interface on which a HELLO message including this TLV is sent. These octets MAY be in any order, but if there might be routers in the MANET that do not implement MT-OLSRv2, then the first octet MUST be LINK_METRIC_TYPE.
此TLV可以采用任何大小的值字段。其值字段中的每个八位字节将包含一个链路度量类型，该类型在任何OLSRv2接口（当包含在TC消息中时）或OLSRv2接口（发送包含此TLV的HELLO消息时）上受支持。这些八位元可以是任何顺序，但如果MANET中可能存在未实现MT-OLSRv2的路由器，则第一个八位元必须是链路度量类型。
The MPR_WILLING TLV, which is used in HELLO messages, is specified in [RFC7181], and extended in this specification as enabled by [RFC7188].
在HELLO消息中使用的MPR_TLV在[RFC7181]中指定，并在本规范中通过[RFC7188]进行扩展。
The interpretation of this TLV, which is specified by [RFC7181] and uses all of its single-octet Value field, is unchanged. That interpretation uses bits 0-3 of its Value field to specify its
该TLV由[RFC7181]指定并使用其所有单八位值字段，其解释保持不变。该解释使用其值字段的0-3位指定其值
willingness to be a flooding TLV, and bits 4-7 of its Value field to be a routing TLV. Those latter bits are, when using this specification, interpreted as its willingness to be a routing TLV using the link metric type LINK_METRIC_TYPE.
愿意成为泛洪TLV，其值字段的第4-7位将成为路由TLV。当使用本规范时，这些后面的位被解释为它愿意成为使用链路度量类型link_metric_类型的路由TLV。
The extended use of this message TLV, as defined by this specification, defines additional 4-bit sub-fields of the Value field, starting with bits 4-7 of the first octet and continuing with bits 0-3 of the second octet, to represent willingness to be a routing MPR using the link metric types specified in this OLSRv2 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the included MPR_TYPES Message TLV. Note that this means that, if there might be any non-MT-OLSRv2 routers, then the link metric type LINK_METRIC_TYPE will continue to occupy bits 4-7 of the first octet. (If there is no such TLV included, then the router does not support MT-OLSRv2, and only the first octet of the Value field will be used.)
如本规范所定义，此消息TLV的扩展使用定义了值字段的附加4位子字段，从第一个八位字节的位4-7开始，继续到第二个八位字节的位0-3，使用此OLSRv2接口的IFACE_metric_types参数中指定的链路度量类型表示成为路由MPR的意愿，按照包含的MPR_types消息TLV中的报告进行排序。注意，这意味着，如果可能存在任何非MT-OLSRv2路由器，则链路度量类型link_metric_类型将继续占用第一个八位组的比特4-7。（如果不包括此类TLV，则路由器不支持MT-OLSRv2，并且仅使用值字段的第一个八位字节。）
If the number of link metric types in this OLSRv2 interface's IFACE_METRIC_TYPES parameter is even, then there will be an unused 4-bit sub-field in bits 4-7 of the last octet of a full-sized Value field. These bits will not be used; they SHOULD all be cleared ('0') on transmission and MUST be ignored on receipt.
如果此OLSRv2接口的IFACE_metric_types参数中的链路度量类型数为偶数，则在全尺寸值字段的最后八位字节的第4-7位中将有一个未使用的4位子字段。这些位将不被使用；它们在传输时应全部清除（“0”），在接收时必须忽略。
If the Value field in an MPR_WILLING TLV is shorter than its full length, then, as specified in [RFC7188], missing Value octets, i.e., missing willingness values, are considered as zero (WILL_NEVER). This is the correct behavior. (In particular, it means that an OLSRv2 router that is not implementing MT-OLSRv2 will not act as a routing MPR for any link metric that it does not recognize.)
如果MPR_意愿TLV中的值字段短于其全长，则按照[RFC7188]中的规定，缺失值八位字节，即缺失意愿值，将被视为零（永远不会）。这是正确的行为。（特别是，这意味着未实现MT-OLSRv2的OLSRv2路由器将不会作为其无法识别的任何链路度量的路由MPR。）
New Type Extensions are defined for the LINK_METRIC TLV defined in [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, both defined in [RFC7181], are extended, as enabled by [RFC7188].
为[RFC7181]中定义的链路度量TLV定义了新的类型扩展，并扩展了[RFC7181]中定义的MPR TLV和网关TLV的值字段，如[RFC7188]所启用。
The LINK_METRIC TLV is used in HELLO messages and TC messages. This TLV is unchanged from the definition in [RFC7181].
链接度量TLV用于HELLO消息和TC消息中。该TLV与[RFC7181]中的定义相同。
Only a single Type Extension was specified by [RFC7181] -- 0 for "Link metric meaning as assigned by administrative action". This specification extends it to the range 0-7. This specification will work with any combination of Type Extensions both within and outside that range (assuming that the latter are defined as specified in [RFC7181]).
[RFC7181]--0仅为“管理操作指定的链接度量含义”指定了单一类型扩展。本规范将其扩展到范围0-7。本规范将适用于该范围内和范围外的任何类型扩展组合（假设后者的定义如[RFC7181]所述）。
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跳邻居。
The Value field of this address block TLV is, in [RFC7181], defined to be one octet long, with the values 1, 2, and 3 defined. [RFC7188] redefines this Value field to be a bitfield where bit 7 (the least significant bit) denotes flooding status, bit 6 denotes routing MPR status, and bits 5-0 are unallocated (respecting the semantics of the bits/values 1, 2, and 3 from [RFC7181]).
在[RFC7181]中，该地址块TLV的值字段定义为一个八位字节长，并定义了值1、2和3。[RFC7188]将该值字段重新定义为位字段，其中位7（最低有效位）表示泛洪状态，位6表示路由MPR状态，位5-0未分配（根据[RFC7181]中位/值1、2和3的语义）。
This specification, as enabled by [RFC7188], extends the MPR TLV to have a variable-length Value field. Bits are allocated in increasing significance within as many octets as are required. These bits specify, in order, that:
[RFC7188]启用的本规范扩展了MPR TLV，使其具有可变长度值字段。根据需要，在尽可能多的八位字节内以递增的重要性分配位。这些位依次指定：
o The neighbor with that network address has been selected as flooding MPR (1 bit).
o 具有该网络地址的邻居已被选择为泛洪MPR（1位）。
o The neighbor with that network address has been selected as routing MPR for each link metric type (1 bit each), in the same order as indicated in the Value field of an MPR_TYPES Message TLV.
o 具有该网络地址的邻居已被选择为每个链路度量类型（每个1位）的路由MPR，其顺序与MPR_类型消息TLV的值字段中指示的顺序相同。
For interoperability with a router not implementing MT-OLSRv2, the two least significant bits of the first octet in the Value field of this TLV is as the TLV Value of an MPR TLV generated according to [RFC7181], as updated by [RFC7188].
对于与未实现MT-OLSRv2的路由器的互操作性，该TLV值字段中第一个八位组的两个最低有效位作为根据[RFC7181]生成的MPR TLV的TLV值，由[RFC7188]更新。
The GATEWAY TLV is used in TC messages to indicate that a network address is of an attached network.
网关TLV用于TC消息中，以指示网络地址属于连接的网络。
The Value field of this address block TLV is defined by [RFC7181] to be one octet long, containing the number of hops to that attached network.
[RFC7181]将该地址块TLV的值字段定义为一个八位字节长，包含连接到该连接网络的跳数。
This specification, as enabled by [RFC7188], allows the extension of the GATEWAY TLV to have a variable-length Value field when the number of hops to each attached network is different for different link metric types. For interoperability with a router not implementing MT-OLSRv2, the first octet in the Value field of this TLV MUST be the TLV Value of the GATEWAY TLV generated according to [RFC7181].
[RFC7188]启用的该规范允许网关TLV的扩展具有可变长度值字段，当每个连接网络的跳数对于不同的链路度量类型不同时。对于与未实现MT-OLSRv2的路由器的互操作性，此TLV值字段中的第一个八位组必须是根据[RFC7181]生成的网关TLV的TLV值。
Any subsequent octets in the TLV Value field indicate the number of hops to the attached network for each other link metric type. Link metric types (including the first) are ordered as indicated in the Value field of an MPR_TYPES Message TLV.
TLV值字段中的任何后续八位字节表示每个其他链路度量类型到连接网络的跳数。链接度量类型（包括第一个）的顺序如MPR_类型消息TLV的值字段所示。
+---------+---------------------------------------------------------+
| Type | Value |
+---------+---------------------------------------------------------+
| GATEWAY | Number of hops to attached network for each link metric |
| | type. |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+
| Type | Value |
+---------+---------------------------------------------------------+
| GATEWAY | Number of hops to attached network for each link metric |
| | type. |
+---------+---------------------------------------------------------+
Table 1: GATEWAY TLV Definition
表1：网关TLV定义
The following changes are made to the generation and processing of HELLO messages compared to the description in [RFC7181] for routers that implement MT-OLSRv2.
与[RFC7181]中对实现MT-OLSRv2的路由器的描述相比，对HELLO消息的生成和处理进行了以下更改。
A generated HELLO message to be sent on an OLSRv2 interface (whose IFACE_METRIC_TYPES parameter will be that used) is extended by:
要在OLSRv2接口上发送的生成HELLO消息（将使用其IFACE_METRIC_TYPES参数）扩展为：
o Adding an MPR_TYPES Message TLV. The Value octets will be the link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE.
o 添加MPR_类型消息TLV。值八位字节将是IFACE_metric_类型中的链接度量类型。如果包含的唯一链路度量类型为链路度量类型，则可省略该TLV。
o Extending the MPR_WILLING Message TLV Value field to report the willingness values from the WILL_ROUTING parameter list that correspond to the link metric types in IFACE_METRIC_LIST, in the same order as reported in the MPR_TYPES TLV, each value (also including one representing WILL_FLOODING) occupying 4 bits.
o 扩展MPR_意愿消息TLV值字段，以报告与IFACE_metric_列表中的链路度量类型相对应的WILL_路由参数列表中的意愿值，顺序与MPR_类型TLV中报告的顺序相同，每个值（还包括一个表示WILL_泛洪的值）占用4位。
o Including LINK_METRIC Address Block TLVs that report all values in L_in_metric, L_out_metric, N_in_metric, and N_out_metric elements that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [RFC7181].
o 包括链路度量地址块TLV，该地址块TLV报告不等于未知度量的L_in_METRIC、L_out_METRIC、N_in_METRIC和N_out_METRIC元素中的所有值，TLV类型扩展为链路度量类型，并遵循[RFC7181]中规定的此类包含规则。
o Including MPR Address Block TLVs such that for each link metric type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, the indicated addresses MUST be of the MPRs in an MPR set as specified for a single link metric type in [RFC7181].
o 包括MPR地址块TLV，以便对于IFACE_metric_类型中的每个链路度量类型，以及对于泛洪MPR的选择，指示的地址必须是[RFC7181]中为单个链路度量类型指定的MPR集中的MPR。
On receipt of a HELLO message on an OLSRv2 interface, a router implementing MT-OLSRv2 MUST do the following, in addition to the processing described in [RFC7181]:
在OLSRv2接口上收到HELLO消息后，除[RFC7181]中所述的处理外，实现MT-OLSRv2的路由器还必须执行以下操作：
1. If in this deployment there might be routers that do not implement MT-OLSRv2, the HELLO message contains an MPR_TYPES Message TLV, and the first link metric type that it reports is not LINK_METRIC_TYPE, then the HELLO message MUST be silently discarded.
1. 如果在此部署中可能存在未实现MT-OLSRv2的路由器，HELLO消息包含MPR_类型消息TLV，并且它报告的第一个链路度量类型不是链路度量类型，则必须以静默方式丢弃HELLO消息。
2. Determine the list of link metric types supported by the sending router on its corresponding OLSRv2 interface, either from an MPR_TYPES Message TLV (if present) or from the single link metric type LINK_METRIC_TYPE.
2. 通过MPR_类型消息TLV（如果存在）或单链路度量类型link_metric_类型，确定发送路由器在其相应OLSRv2接口上支持的链路度量类型列表。
3. For all link metric types reported and supported by the receiving router, set the appropriate L_out_metric, N_in_metric, N_out_metric, N_will_routing, N_mpr_selector, N_advertised, N2_in_metric, and N2_out_metric elements using the rules for setting the single elements of those types specified in [RFC7181].
3. 对于接收路由器报告和支持的所有链路度量类型，使用[RFC7181]中指定的用于设置这些类型的单个元素的规则，设置适当的L_out_度量、N_in_度量、N_out_度量、N_will_路由、N_mpr_选择器、N_广告、N2_in_度量和N2_out_度量元素。
4. For any other metric types supported by the receiving router only (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set the elements listed in the previous point to their default values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or false.
4. 对于接收路由器仅支持的任何其他度量类型（即接收OLSRv2接口的IFACE_度量），将上一点中列出的元素设置为其默认值，即未知_度量、WILL_NEVER（not WILL_default）或false。
The following changes are made to the generation and processing of TC messages compared to that described in [RFC7181] by routers that implement MT-OLSRv2.
与[RFC7181]中所述的相比，通过实现MT-OLSRv2的路由器对TC消息的生成和处理进行了以下更改。
A generated TC message is extended by:
生成的TC消息通过以下方式扩展：
o Adding an MPR_TYPES TLV. The Value octets will be the link metric types in ROUTER_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE.
o 添加MPR_类型TLV。值八位字节将是路由器度量类型中的链路度量类型。如果包含的唯一链路度量类型为链路度量类型，则可省略该TLV。
o Including LINK_METRIC TLVs that report all values of N_out_metric that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [RFC7181].
o 包括链接度量TLV，该TLV报告不等于未知度量的所有N_out_度量值，TLV类型扩展为链接度量类型，并遵循[RFC7181]中规定的此类包含规则。
o Including a number of hops per reported (in an MPR_TYPES Message TLV) link metric type in the Value field of each GATEWAY TLV included, in the same order as reported in the MPR_TYPES TLV.
o 在包含的每个网关TLV的值字段中包括每个报告（在MPR_类型消息TLV中）链路度量类型的跳数，顺序与在MPR_类型TLV中报告的顺序相同。
On receipt of a TC message, a router implementing this extension MUST do the following, in addition to the processing specified in [RFC7181]:
在收到TC消息时，除[RFC7181]中指定的处理外，实现此扩展的路由器还必须执行以下操作：
o If in this deployment there might be routers that do not implement MT-OLSRv2, the TC message contains an MPR_TYPES Message TLV, and the first link metric type that it reports is not LINK_METRIC_TYPE, then the TC message MUST be silently discarded.
o 如果在此部署中可能存在未实现MT-OLSRv2的路由器，则TC消息包含MPR_类型消息TLV，并且它报告的第一个链路度量类型不是链路度量类型，则必须以静默方式丢弃TC消息。
o For all link metric types reported and supported by the receiving router, set the appropriate TR_metric, TA_metric, AN_dist, and AN_metric elements using the rules for setting the single elements of those types specified in [RFC7181].
o 对于接收路由器报告和支持的所有链路度量类型，使用[RFC7181]中指定的设置这些类型的单个元素的规则，设置适当的TR_度量、TA_度量、AN_dist和AN_度量元素。
o For any other metric types supported by the receiving router that do not have an advertised outgoing neighbor metric of that type, set the corresponding elements of TR_metric, TA_metric, and AN_metric to UNKNOWN_METRIC. (The corresponding element of AN_dist may be set to any value.)
o 对于接收路由器支持的任何其他度量类型，如果没有该类型的播发传出邻居度量，请将TR_度量、TA_度量和an_度量的对应元素设置为UNKNOWN_度量。（可将_dist的相应元素设置为任何值。）
Routing MPRs are calculated for each link metric type in ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 interfaces that do not support that link metric type are not considered. The determined status (routing MPR or not routing MPR) for each link metric type is recorded in the relevant element of N_routing_mpr.
为路由器度量类型中的每个链路度量类型计算路由MPR。不考虑通过不支持该链路度量类型的OLSRv2接口到对称1跳邻居的链路。每个链路度量类型的确定状态（路由MPR或非路由MPR）记录在N_routing_MPR的相关元素中。
Each router may make its own decision as to whether or not to use a link metric, or link metrics, for flooding MPR calculation. If using link metric(s), each router decides which one(s) and how they are used. These decisions MUST be made in a manner that ensures that flooded messages will reach the same symmetric 2-hop neighbors as would be the case for a router not supporting MT-OLSRv2.
每个路由器可自行决定是否使用链路度量或链路度量进行泛洪MPR计算。如果使用链路度量，则每个路由器决定使用哪一个以及如何使用它们。这些决定必须以确保被淹没的消息将到达与不支持MT-OLSRv2的路由器相同的对称2跳邻居的方式作出。
Note that it is possible that a 2-Hop Tuple in the Information Base for a given OLSRv2 interface does not support any of the link metric types that are in the router's corresponding IFACE_METRIC_TYPES; nevertheless, that 2-Hop Tuple MUST be considered when determining flooding MPRs.
注意，给定OLSRv2接口的信息库中的2跳元组可能不支持路由器对应的IFACE_metric_类型中的任何链路度量类型；然而，在确定泛洪MPR时，必须考虑该2跳元组。
A Routing Set is calculated for each link metric type in ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except that where an element is now represented by a map, the value from the map for the selected link metric type is used. Where this is a link metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for the calculation.
为路由器度量类型中的每个链路度量类型计算路由集。计算可能与[RFC7181]相同，但如果元素现在由映射表示，则使用所选链接度量类型的映射中的值。如果这是值未知的链路度量_metric，则在计算时忽略该协议元组。
MT-OLSRv2 may require greater management than unextended OLSRv2. In particular, a MANET using MT-OLSRv2 requires the following management considerations:
MT-OLSRv2可能需要比未扩展的OLSRv2更大的管理。特别是，使用MT-OLSRv2的MANET需要以下管理注意事项：
o Deciding which link metric, and hence which Routing Set to use, for received packets, hence how to use the Routing Sets to configure the network layer (IP). All routers MUST make the same decision for the same packet. An obvious approach is to map each DSCP [RFC2474] to a single link metric. (This may be a many-to-one mapping.)
o 决定接收到的数据包使用哪种链路度量以及使用哪种路由集，从而决定如何使用路由集来配置网络层（IP）。所有路由器必须对同一数据包做出相同的决定。一种明显的方法是将每个DSCP[RFC2474]映射到单个链路度量。（这可能是多对一映射。）
o Selecting which link metrics to support on each OLSRv2 interface and implementing that decision. (Different interfaces may have different physical and data link-layer properties, and this may inform the selection of link metrics to support, and their values.) If the MANET might contain non-MT-OLSRv2 routers, which are also subject to management, then the rules in this specification for link metric assignment to OLSRv2 interfaces for that case MUST be followed.
o 选择在每个OLSRv2接口上支持哪些链接度量，并实施该决策。（不同的接口可能具有不同的物理和数据链路层属性，这可能会通知要支持的链路度量的选择及其值。）如果MANET可能包含非MT-OLSRv2路由器，这些路由器也受管理，然后，必须遵循本规范中关于在这种情况下将链路度量分配给OLSRv2接口的规则。
o Ensuring that the MANET is sufficiently connected, by ensuring that, for example, sufficiently many routers implement each metric type required. (This is easier in, for example, a denser network.) Note that if there is any possibility that there are routers not implementing MT-OLSRv2, then the MANET will be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE, but this will only serve to deliver packets that use that link metric type.
o 例如，通过确保足够多的路由器实现所需的每种度量类型，确保MANET充分连接。（例如，在更密集的网络中，这更容易。）注意，如果存在任何不实现MT-OLSRv2的路由器的可能性，则MANET将使用链路度量类型link_metric_类型进行最大程度的连接，但这将仅用于传送使用该链路度量类型的分组。
o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets that will be routed by a topology that they are not part of. However, if that were to happen, then such packets will be routed until either they reach their destination or they reach an MT-OLSRv2 router. In the latter case, the packet then either will be dropped (if that MT-OLSRv2 router is not part of that topology,
o 应管理非MT-OLSRv2路由器，以免产生将由其不属于的拓扑路由的数据包。但是，如果发生这种情况，则这些数据包将被路由，直到它们到达目的地或到达MT-OLSRv2路由器。在后一种情况下，数据包将被丢弃（如果MT-OLSRv2路由器不是该拓扑的一部分，
or is not aware of the destination within that topology) or will be routed by that topology to the destination. Such a packet will not loop.
或不知道该拓扑中的目标），或将由该拓扑路由到目标。这样的包不会循环。
o If a packet is created for a destination that is not part of the corresponding topology, then it may or may not be delivered (if the originating router is a non-MT-OLSRv2 router) or will not be sent (if the originating router is an MT-OLSRv2 router). Routers SHOULD be managed so that topologies are as complete as possible and that packets are not sent if they may not be delivered. In particular, non-MT-OLSRv2 routers SHOULD only send packets that will be routed using the topology using the link metric type LINK_METRIC_TYPE.
o 如果为不是相应拓扑的一部分的目的地创建数据包，则它可能被传送（如果发起路由器是非MT-OLSRv2路由器），也可能不被传送（如果发起路由器是MT-OLSRv2路由器）。路由器的管理应确保拓扑结构尽可能完整，并且如果数据包无法交付，则不会发送数据包。特别是，非MT-OLSRv2路由器应仅发送将使用链路度量类型link\ U metric\ U类型的拓扑进行路由的数据包。
This specification adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV, using a new name. It also modifies the Value field of an existing Message TLV and that of an existing Address Block TLV. Finally, this specification makes additional allocations from the LINK_METRIC Address Block TLV Type registry.
此规范使用新名称向现有消息TLV添加一个新消息TLV，并将其作为新类型扩展分配。它还修改现有消息TLV和现有地址块TLV的值字段。最后，该规范从链路度量地址块TLV类型注册表进行额外分配。
For the registry where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444] and [RFC7631].
对于需要专家审查的登记处，指定专家应考虑[RFC5444]和[RFC7631]规定的一般建议。
This specification modifies the Message TLV Type 7, replacing Table 4 of [RFC7631] by Table 2, changing the description of the Type Extension MPR_WILLING, and adding the Type Extension TLV_TYPES. Each of these TLVs MUST NOT be included more than once in a Message TLV Block.
本规范修改了消息TLV Type 7，将[RFC7631]的表4替换为表2，更改了类型扩展MPR_的描述，并添加了类型扩展TLV_类型。在消息TLV块中，每个TLV不得包含一次以上。
+-----------+-------------+-------------------------+---------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+-------------+-------------------------+---------------+
| 0 | MPR_WILLING | First (most | [RFC7181] |
| | | significant) half-octet | [RFC7631] |
| | | of Value field | RFC 7722 |
| | | specifies the | |
| | | originating router's | |
| | | willingness to act as a | |
| | | flooding MPR; | |
| | | subsequent half-octets | |
| | | specify the originating | |
| | | router's willingness to | |
| | | act as a routing MPR, | |
| | | either for the link | |
| | | metric types reported | |
| | | in an MPR_TYPES TLV (in | |
| | | the same order), or (if | |
| | | no MPR_TYPES TLV is | |
| | | present) for the single | |
| | | administratively agreed | |
| | | link metric type | |
| 1 | MPR_TYPES | The link metric types | RFC 7722 |
| | | supported on this | |
| | | OLSRv2 interface of | |
| | | this router (one octet | |
| | | each). | |
| 2-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC7181] |
| | | Experimental Use | |
+-----------+-------------+-------------------------+---------------+
+-----------+-------------+-------------------------+---------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+-------------+-------------------------+---------------+
| 0 | MPR_WILLING | First (most | [RFC7181] |
| | | significant) half-octet | [RFC7631] |
| | | of Value field | RFC 7722 |
| | | specifies the | |
| | | originating router's | |
| | | willingness to act as a | |
| | | flooding MPR; | |
| | | subsequent half-octets | |
| | | specify the originating | |
| | | router's willingness to | |
| | | act as a routing MPR, | |
| | | either for the link | |
| | | metric types reported | |
| | | in an MPR_TYPES TLV (in | |
| | | the same order), or (if | |
| | | no MPR_TYPES TLV is | |
| | | present) for the single | |
| | | administratively agreed | |
| | | link metric type | |
| 1 | MPR_TYPES | The link metric types | RFC 7722 |
| | | supported on this | |
| | | OLSRv2 interface of | |
| | | this router (one octet | |
| | | each). | |
| 2-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC7181] |
| | | Experimental Use | |
+-----------+-------------+-------------------------+---------------+
Table 2: Type 7 Message TLV Type Extensions
表2:7类消息TLV类型扩展
Table 7 of [RFC7188] is replaced by Table 3.
[RFC7188]的表7替换为表3。
+-------+-------+----------+----------------------------------------+
| Bit | Value | Name | Description |
+-------+-------+----------+----------------------------------------+
| First | First | Flooding | If set, then the neighbor with that |
| octet | octet | | network address has been selected as |
| bit 7 | 0x01 | | flooding MPR |
| From | From | Routing | If set, then the neighbor with that |
| first | first | | network address has been selected as |
| octet | octet | | routing MPR, either for the link |
| bit 6 | 0x02 | | metric types reported in an MPR_TYPES |
| | | | TLV (in the same order), or (if no |
| | | | MPR_TYPES TLV is present) then (first |
| | | | octet bit 6, value 0x02) for the |
| | | | single administratively agreed link |
| | | | metric type |
+-------+-------+----------+----------------------------------------+
+-------+-------+----------+----------------------------------------+
| Bit | Value | Name | Description |
+-------+-------+----------+----------------------------------------+
| First | First | Flooding | If set, then the neighbor with that |
| octet | octet | | network address has been selected as |
| bit 7 | 0x01 | | flooding MPR |
| From | From | Routing | If set, then the neighbor with that |
| first | first | | network address has been selected as |
| octet | octet | | routing MPR, either for the link |
| bit 6 | 0x02 | | metric types reported in an MPR_TYPES |
| | | | TLV (in the same order), or (if no |
| | | | MPR_TYPES TLV is present) then (first |
| | | | octet bit 6, value 0x02) for the |
| | | | single administratively agreed link |
| | | | metric type |
+-------+-------+----------+----------------------------------------+
Table 3: MPR TLV Bit Values
表3:MPR TLV位值
Table 14 of [RFC7631] is replaced by Table 4. The only changes are to the Description and the References for the GATEWAY TLV.
[RFC7631]的表14替换为表4。唯一的更改是对网关TLV的描述和引用。
+-----------+---------+-----------------------------+---------------+
| Type | Name | Description | References |
| Extension | | | |
+-----------+---------+-----------------------------+---------------+
| 0 | GATEWAY | Specifies that a given | [RFC7181] |
| | | network address is reached | RFC 7722 |
| | | via a gateway on the | |
| | | originating router. The | |
| | | number of hops is indicated | |
| | | by the Value field, one | |
| | | octet per link metric type | |
| | | reported in an MPR_TYPES | |
| | | Message TLV (in the same | |
| | | order) or (if no MPR_TYPES | |
| | | Message TLV is present) | |
| | | using a single octet | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC7631] |
| | | Use | |
+-----------+---------+-----------------------------+---------------+
+-----------+---------+-----------------------------+---------------+
| Type | Name | Description | References |
| Extension | | | |
+-----------+---------+-----------------------------+---------------+
| 0 | GATEWAY | Specifies that a given | [RFC7181] |
| | | network address is reached | RFC 7722 |
| | | via a gateway on the | |
| | | originating router. The | |
| | | number of hops is indicated | |
| | | by the Value field, one | |
| | | octet per link metric type | |
| | | reported in an MPR_TYPES | |
| | | Message TLV (in the same | |
| | | order) or (if no MPR_TYPES | |
| | | Message TLV is present) | |
| | | using a single octet | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC7631] |
| | | Use | |
+-----------+---------+-----------------------------+---------------+
Table 4: Type 10 Address Block TLV Type Extensions
表4:10型地址块TLV型扩展
Table 13 of [RFC7181] is replaced by Table 5. The only change is that 8 Type Extensions are allocated as assigned by administrative action, in order to support administratively determined multi-topologies.
[RFC7181]的表13替换为表5。唯一的变化是，根据管理操作分配8个类型扩展，以支持管理确定的多拓扑。
+-------------+------+-----------+-------------------+--------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+-------------------+--------------+
| LINK_METRIC | 7 | 0-7 | Link metric | |
| | | | meaning assigned | |
| | | | by administrative | |
| | | | action. | |
| LINK_METRIC | 7 | 8-223 | Unassigned. | Expert |
| | | | | Review |
| LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental |
| | | | | Use |
+-------------+------+-----------+-------------------+--------------+
+-------------+------+-----------+-------------------+--------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+-------------------+--------------+
| LINK_METRIC | 7 | 0-7 | Link metric | |
| | | | meaning assigned | |
| | | | by administrative | |
| | | | action. | |
| LINK_METRIC | 7 | 8-223 | Unassigned. | Expert |
| | | | | Review |
| LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental |
| | | | | Use |
+-------------+------+-----------+-------------------+--------------+
Table 5: Address Block TLV Type assignment: LINK_METRIC
表5：地址块TLV类型分配：链路度量
This extension to OLSRv2 allows a router to support more than one link metric type for each link advertised in HELLO and TC messages, and for routers to support different sets of types. Link metric values of additional types are reported by the inclusion of additional TLVs in the messages sent by a router, which will report known values of all supported types.
OLSRv2的此扩展允许路由器为HELLO和TC消息中公布的每个链路支持多个链路度量类型，并允许路由器支持不同的类型集。额外类型的链路度量值通过在路由器发送的消息中包含额外的TLV来报告，路由器将报告所有支持类型的已知值。
HELLO and TC message processing is then extended simply to record, for each supported type, all of the received link metric values for each link. Protocol-internal processing (specifically, MPR set and shortest path calculations) then operates as specified in [RFC7181] for each link metric type that the router supports.
然后，HELLO和TC消息处理被简单地扩展，以记录每个支持的类型的每个链接的所有接收到的链接度量值。协议内部处理（具体地说，MPR集和最短路径计算）然后按照[RFC7181]中针对路由器支持的每种链路度量类型的规定进行操作。
Consequently, the security considerations, including the security architecture and the mandatory security mechanisms, from [RFC7181] are directly applicable to MT-OLSRv2.
因此，[RFC7181]中的安全注意事项，包括安全架构和强制安全机制，直接适用于MT-OLSRv2。
Furthermore, this extension does not introduce any additional vulnerabilities beyond those of [RFC7181], because each link metric type is used independently, and each one could have been the single link metric type supported by an implementation of [RFC7181] receiving the same information, as received information of an unsupported type is ignored by all routers.
此外，此扩展不会引入[RFC7181]之外的任何其他漏洞，因为每个链路度量类型都是独立使用的，并且每个都可能是[RFC7181]接收相同信息的实现所支持的单个链路度量类型，所有路由器都会忽略接收到的不支持类型的信息。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <http://www.rfc-editor.org/info/rfc5444>.
[RFC5444]Clausen，T.，Dearlove，C.，Dean，J.，和C.Adjih，“通用移动自组网（MANET）数据包/消息格式”，RFC 5444，DOI 10.17487/RFC54442009年2月<http://www.rfc-editor.org/info/rfc5444>.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>.
[RFC6130]Clausen，T.，Dearlove，C.，和J.Dean，“移动自组织网络（MANET）邻域发现协议（NHDP）”，RFC 6130，DOI 10.17487/RFC6130，2011年4月<http://www.rfc-editor.org/info/rfc6130>.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>.
[RFC7181]Clausen，T.，Dearlove，C.，Jacquet，P.，和U.Herberg，“优化链路状态路由协议版本2”，RFC 7181，DOI 10.17487/RFC7181，2014年4月<http://www.rfc-editor.org/info/rfc7181>.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs", RFC 7188, DOI 10.17487/RFC7188, April 2014, <http://www.rfc-editor.org/info/rfc7188>.
[RFC7188]Dearlove，C.和T.Clausen，“优化链路状态路由协议版本2（OLSRv2）和MANET邻居发现协议（NHDP）扩展TLV”，RFC 7188，DOI 10.17487/RFC7188，2014年4月<http://www.rfc-editor.org/info/rfc7188>.
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format", RFC 7631, DOI 10.17487/RFC7631, September 2015, <http://www.rfc-editor.org/info/rfc7631>.
[RFC7631]Dearlove，C.和T.Clausen，“移动自组网（MANET）通用分组/消息格式中的TLV命名”，RFC 7631，DOI 10.17487/RFC76312015年9月<http://www.rfc-editor.org/info/rfc7631>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<http://www.rfc-editor.org/info/rfc2474>.
[RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, DOI 10.17487/RFC2501, January 1999, <http://www.rfc-editor.org/info/rfc2501>.
[RFC2501]Corson，S.和J.Macker，“移动自组网（MANET）：路由协议性能问题和评估考虑”，RFC 2501，DOI 10.17487/RFC2501，1999年1月<http://www.rfc-editor.org/info/rfc2501>.
[RFC3626] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, <http://www.rfc-editor.org/info/rfc3626>.
[RFC3626]Clausen，T.，Ed.，和P.Jacquet，Ed.，“优化链路状态路由协议（OLSR）”，RFC 3626，DOI 10.17487/RFC3626，2003年10月<http://www.rfc-editor.org/info/rfc3626>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>.
[RFC4915]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，DOI 10.17487/RFC4915，2007年6月<http://www.rfc-editor.org/info/rfc4915>.
Acknowledgments
致谢
The authors would like to thank (in alphabetical order): Juliusz Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems), Susan Hares (Huawei), and Henning Rogge (FGAN) for discussions and suggestions.
作者要感谢（按字母顺序排列）：朱利叶斯·科罗博切克（巴黎迪德罗大学）、艾伦·卡伦（BAE系统公司）、苏珊·哈尔斯（华为公司）和亨宁·罗格（FGAN公司）的讨论和建议。
Authors' Addresses
作者地址
Christopher Dearlove BAE Systems Applied Intelligence Laboratories West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems应用情报实验室英国切姆斯福德大巴德西汉宁菲尔德路
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/
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/