Internet Engineering Task Force (IETF) J. Yi
Request for Comments: 8218 Ecole Polytechnique
Category: Experimental B. Parrein
ISSN: 2070-1721 University of Nantes
August 2017
Internet Engineering Task Force (IETF) J. Yi
Request for Comments: 8218 Ecole Polytechnique
Category: Experimental B. Parrein
ISSN: 2070-1721 University of Nantes
August 2017
Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
优化链路状态路由协议版本2（OLSRv2）的多路径扩展
Abstract
摘要
This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained.
本文档为优化链路状态路由协议版本2（OLSRv2）指定了多路径扩展，以发现移动自组织网络（MANET）的多条不相交路径。考虑到移动自组网的特点，特别是网络拓扑结构的动态性，使用多条路径可以避免单路由故障，从而提高聚合吞吐量和可靠性。保留与OLSRv2的互操作性。
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 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8218.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8218.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 Experiments to Be Conducted . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8
5. Parameters and Constants . . . . . . . . . . . . . . . . . . 9
5.1. Router Parameters . . . . . . . . . . . . . . . . . . . . 9
6. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10
6.1. HELLO and TC messages . . . . . . . . . . . . . . . . . . 10
6.1.1. SOURCE_ROUTE TLV . . . . . . . . . . . . . . . . . . 10
6.2. Datagram . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Source Routing Header in IPv4 . . . . . . . . . . . . 11
6.2.2. Source Routing Header in IPv6 . . . . . . . . . . . . 11
7. Information Bases . . . . . . . . . . . . . . . . . . . . . . 11
7.1. SR-OLSRv2 Router Set . . . . . . . . . . . . . . . . . . 11
7.2. Multipath Routing Set . . . . . . . . . . . . . . . . . . 12
8. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 12
8.1. HELLO and TC Message Generation . . . . . . . . . . . . . 12
8.2. HELLO and TC Message Processing . . . . . . . . . . . . . 13
8.3. MPR Selection . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Datagram Processing at the MP-OLSRv2 Originator . . . . . 14
8.5. Multipath Calculation . . . . . . . . . . . . . . . . . . 15
8.5.1. Requirements of Multipath Calculation . . . . . . . . 15
8.5.2. Multipath Dijkstra Algorithm . . . . . . . . . . . . 16
8.6. Multipath Routing Set Updates . . . . . . . . . . . . . . 18
8.7. Datagram Forwarding . . . . . . . . . . . . . . . . . . . 18
9. Configuration Parameters . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.1. Message TLV Types . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Multipath Dijkstra Algorithm . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Experiments to Be Conducted . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8
5. Parameters and Constants . . . . . . . . . . . . . . . . . . 9
5.1. Router Parameters . . . . . . . . . . . . . . . . . . . . 9
6. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10
6.1. HELLO and TC messages . . . . . . . . . . . . . . . . . . 10
6.1.1. SOURCE_ROUTE TLV . . . . . . . . . . . . . . . . . . 10
6.2. Datagram . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Source Routing Header in IPv4 . . . . . . . . . . . . 11
6.2.2. Source Routing Header in IPv6 . . . . . . . . . . . . 11
7. Information Bases . . . . . . . . . . . . . . . . . . . . . . 11
7.1. SR-OLSRv2 Router Set . . . . . . . . . . . . . . . . . . 11
7.2. Multipath Routing Set . . . . . . . . . . . . . . . . . . 12
8. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 12
8.1. HELLO and TC Message Generation . . . . . . . . . . . . . 12
8.2. HELLO and TC Message Processing . . . . . . . . . . . . . 13
8.3. MPR Selection . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Datagram Processing at the MP-OLSRv2 Originator . . . . . 14
8.5. Multipath Calculation . . . . . . . . . . . . . . . . . . 15
8.5.1. Requirements of Multipath Calculation . . . . . . . . 15
8.5.2. Multipath Dijkstra Algorithm . . . . . . . . . . . . 16
8.6. Multipath Routing Set Updates . . . . . . . . . . . . . . 18
8.7. Datagram Forwarding . . . . . . . . . . . . . . . . . . . 18
9. Configuration Parameters . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.1. Message TLV Types . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Multipath Dijkstra Algorithm . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
The Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] is a proactive link state protocol designed for use in Mobile Ad Hoc Networks (MANETs). It generates routing messages periodically to create and maintain a Routing Set, which contains routing information to all the possible destinations in the routing domain. For each destination, there exists a unique Routing Tuple, which indicates the next hop to reach the destination.
优化链路状态路由协议版本2（OLSRv2）[RFC7181]是一种设计用于移动自组织网络（MANET）的主动链路状态协议。它定期生成路由消息以创建和维护路由集，其中包含到路由域中所有可能目的地的路由信息。对于每个目的地，都存在一个唯一的路由元组，它指示到达目的地的下一跳。
This document specifies an extension of the OLSRv2 protocol [RFC7181] to provide multiple disjoint paths when appropriate for a source-destination pair. Because of the characteristics of MANETs [RFC2501], especially the dynamic topology, having multiple paths is helpful for increasing network throughput, improving forwarding reliability, and load-balancing.
本文档指定了OLSRv2协议[RFC7181]的扩展，以在适用于源-目的地对时提供多条不相交路径。由于移动自组网[RFC2501]的特点，特别是动态拓扑结构，具有多条路径有助于提高网络吞吐量、提高转发可靠性和负载平衡。
Multipath OLSRv2 (MP-OLSRv2), specified in this document, uses the Multipath Dijkstra Algorithm by default to explore multiple disjoint paths from a source router to a destination router based on the topology information obtained through OLSRv2 and to forward the datagrams in a load-balancing manner using source routing. MP-OLSRv2 is designed to be interoperable with OLSRv2.
本文档中指定的多路径OLSRv2（MP-OLSRv2）默认使用多路径Dijkstra算法，根据通过OLSRv2获得的拓扑信息探索从源路由器到目标路由器的多条不相交路径，并使用源路由以负载平衡方式转发数据报。MP-OLSRv2旨在与OLSRv2互操作。
This document is an experimental extension of OLSRv2 that can increase the data forwarding reliability in dynamic and high-load MANET scenarios by transmitting datagrams over multiple disjoint paths using source routing. This mechanism is used because:
本文档是OLSRv2的一个实验性扩展，它可以通过使用源路由在多条不相交路径上传输数据报来提高动态和高负载MANET场景中的数据转发可靠性。使用此机制是因为：
o Disjoint paths can avoid single route failures.
o 不相交的路径可以避免单路由故障。
o Transmitting datagrams through parallel paths can increase aggregated throughput.
o 通过并行路径传输数据报可以提高聚合吞吐量。
o Some scenarios may require that some routers must (or must not) be used.
o 某些场景可能要求必须（或不得）使用某些路由器。
o Having control of the paths at the source benefits the load-balancing and traffic engineering.
o 在源位置控制路径有利于负载平衡和流量工程。
o An application of this extension is in combination with Forward Error Correction (FEC) coding applied across packets (erasure coding) [WPMC11]. Because the packet drops are normally bursty in a path (for example, due to route failure), erasure coding is less
o 该扩展的应用与跨分组应用的前向纠错（FEC）编码（擦除编码）[WPMC11]相结合。因为数据包丢弃通常在路径中是突发的（例如，由于路由失败），所以擦除编码更少
effective in single path routing protocols. By providing multiple disjoint paths, the application of erasure coding with multipath protocol is more resilient to routing failures.
在单路径路由协议中有效。通过提供多条不相交的路径，使用多径协议的擦除编码的应用对路由故障具有更大的弹性。
In existing deployments, while running code and simulations have proven the interest of multipath extension for OLSRv2 in certain networks [GIIS14][WCNC08][ADHOC11], more experiments and experiences are still needed to understand the effects of the protocol specified in this Experimental RFC. The multipath extension for OLSRv2 is expected to be revised and documented as a Standards Track RFC once sufficient operational experience is obtained. Other than general experiences, including the protocol specification and interoperability with base OLSRv2 implementations, experiences in the following aspects are highly appreciated:
在现有部署中，虽然运行代码和模拟已证明在某些网络[GIIS14][WCNC08][ADHOC11]中对OLSRv2的多路径扩展感兴趣，但仍需要更多的实验和经验来理解本实验RFC中指定的协议的影响。一旦获得足够的运行经验，OLSRv2的多路径扩展预计将作为标准轨道RFC进行修订和记录。除了一般经验（包括协议规范和与基本OLSRv2实现的互操作性）外，以下方面的经验值得高度赞赏：
o Optimal values for the number of multiple paths (NUMBER_OF_PATHS, see Section 5) to be used. This depends on the network topology and router density.
o 要使用的多条路径数（路径数，见第5节）的最佳值。这取决于网络拓扑和路由器密度。
o Optimal values used in the metric functions. Metric functions are applied to increase the metric of used links and nodes so as to obtain disjoint paths. What kind of disjointness is desired (node disjoint or link disjoint) may depend on the Layer 2 protocol used and can be achieved by applying different sets of metric functions.
o 度量函数中使用的最佳值。度量函数用于增加所用链路和节点的度量，以获得不相交路径。需要什么样的不相交（节点不相交或链路不相交）可能取决于所使用的第2层协议，并且可以通过应用不同的度量函数集来实现。
o Use of different metric types. This multipath extension can be used with metric types that meet the requirement of OLSRv2, such as [RFC7779]. The metric type used also has an impact on the choice of metric functions as indicated in the previous bullet point.
o 使用不同的度量类型。此多路径扩展可用于满足OLSRv2要求的度量类型，如[RFC7779]。所使用的度量类型也会影响前面要点中所述的度量函数的选择。
o The impact of partial topology information to multipath calculation. OLSRv2 maintains a partial topology information base to reduce protocol overhead. Experience has shown that multiple paths can be obtained even with such partial information; however, depending on the Multipoint Relay (MPR) selection algorithm used, the disjointness of the multiple paths might be impacted depending on the Multipoint Relay (MPR) selection algorithm used.
o 部分拓扑信息对多径计算的影响。OLSRv2维护部分拓扑信息库以减少协议开销。经验表明，即使有这样的部分信息，也可以获得多条路径；然而，根据所使用的多点中继（MPR）选择算法，多条路径的不相交性可能会受到所使用的多点中继（MPR）选择算法的影响。
o Use of IPv6 loose source routing. In the current specification, only strict source routing is used for IPv6 based on [RFC6554]. In [IPv6-SRH], the use of the loose source routing is also proposed in IPv6. In scenarios where the length of the source routing header is critical, the loose source routing can be considered.
o 使用IPv6松散源路由。在当前规范中，基于[RFC6554]的IPv6仅使用严格的源路由。在[IPv6 SRH]中，也建议在IPv6中使用松散源路由。在源路由头的长度至关重要的场景中，可以考虑松散源路由。
o Optimal choice of "key" routers for loose source routing. In some cases, loose source routing is used to reduce overhead or for interoperability with OLSRv2 routers. Other than the basic rules defined in the following parts of this document, optimal choices of routers to put in the loose source routing header can be further studied.
o 松散源路由的“关键”路由器的最佳选择。在某些情况下，松散源路由用于减少开销或用于与OLSRv2路由器的互操作性。除了本文档以下部分中定义的基本规则外，还可以进一步研究放在松散源路由报头中的路由器的最佳选择。
o Different path-selection schedulers. Depending on the application type and transport layer type, either a per-flow scheduler or per-datagram scheduler is applied. By default, the traffic load should be equally distributed in multiple paths. In some scenarios, weighted scheduling can be considered: for example, the paths with lower metrics (i.e., higher quality) can transfer more datagrams or flows compared to paths with higher metrics.
o 不同的路径选择调度器。根据应用程序类型和传输层类型，应用每流调度器或每数据报调度器。默认情况下，流量负载应均匀分布在多条路径中。在某些场景中，可以考虑加权调度：例如，与具有较高度量的路径相比，具有较低度量（即，较高质量）的路径可以传输更多的数据报或流。
o The impacts of the delay variation due to multipath routing. [RFC2991] brings out some concerns of multipath routing, especially variable latencies when per-datagram scheduling is applied. Although current experiment results show that multipath routing can reduce the jitter in dynamic scenarios, some transport protocols or applications may be sensitive to the datagram reordering.
o 多径路由引起的延迟变化的影响。[RFC2991]提出了多路径路由的一些问题，特别是应用每数据报调度时的可变延迟。虽然目前的实验结果表明，多径路由可以减少动态场景中的抖动，但一些传输协议或应用程序可能对数据报的重新排序非常敏感。
o The disjoint multipath protocol has an interesting application with erasure coding, especially for services like video/audio streaming [WPMC11]. The combination of erasure coding mechanisms and this extension is thus encouraged.
o 不相交多路径协议在擦除编码方面有一个有趣的应用，特别是对于视频/音频流[WPMC11]等服务。因此，鼓励将擦除编码机制与该扩展相结合。
o Different algorithms to obtain multiple paths, other than the default Multipath Dijkstra Algorithm introduced in Section 8.5.2 of this specification.
o 获得多条路径的不同算法，本规范第8.5.2节中介绍的默认多路径Dijkstra算法除外。
o The use of multitopology information. By using [RFC7722], multiple topologies using different metric types can be obtained. Although there is no work defining how this extension can make use of the multitopology information base yet, experimentation with the use of multiple metrics for building multiple paths is encouraged.
o 多拓扑信息的使用。通过使用[RFC7722]，可以获得使用不同度量类型的多个拓扑。尽管目前还没有工作定义此扩展如何利用多拓扑信息库，但鼓励尝试使用多个度量构建多条路径。
Comments are solicited and should be addressed to the MANET working group's mailing list at manet@ietf.org and/or the authors.
征求意见，并应发送至MANET工作组的邮件列表，地址为manet@ietf.org和/或作者。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document uses the terminology and notation defined in [RFC5444], [RFC6130], and [RFC7181]. Additionally, it defines the following terminology:
本文件使用[RFC5444]、[RFC6130]和[RFC7181]中定义的术语和符号。此外，它还定义了以下术语：
OLSRv2 Routing Process: A routing process based on [RFC7181], without multipath extension specified in this document.
OLSRv2路由进程：基于[RFC7181]的路由进程，本文档中未指定多路径扩展。
MP-OLSRv2 Routing Process: A Multipath Routing Process based on this specification as an extension to [RFC7181].
MP-OLSRv2路由过程：基于本规范的多路径路由过程，作为[RFC7181]的扩展。
SR-OLSRv2 Routing Process: An OLSRv2 Routing Process that supports Source Routing (SR) or an MP-OLSRv2 Routing Process.
SR-OLSRv2路由进程：支持源路由（SR）或MP-OLSRv2路由进程的OLSRv2路由进程。
As an extension of OLSRv2, this specification is applicable to MANETs for which OLSRv2 is applicable (see [RFC7181]). It can operate on single or multiple interfaces to discover multiple disjoint paths from a source router to a destination router. MP-OLSRv2 is designed for networks with dynamic topology to avoid single route failure. It can also provide higher aggregated throughput and load-balancing.
作为OLSRv2的扩展，本规范适用于OLSRv2适用的移动自组网（见[RFC7181]）。它可以在单个或多个接口上运行，以发现从源路由器到目标路由器的多条不相交路径。MP-OLSRv2设计用于具有动态拓扑的网络，以避免单路由故障。它还可以提供更高的聚合吞吐量和负载平衡。
In a router supporting MP-OLSRv2, MP-OLSRv2 does not necessarily replace OLSRv2 completely. The extension can be applied for certain applications that are suitable for multipath routing (mainly video or audio streams) based on information such as a Diffserv codepoint [RFC2474].
在支持MP-OLSRv2的路由器中，MP-OLSRv2不一定完全取代OLSRv2。该扩展可应用于基于诸如Diffserv码点[RFC2474]等信息的适合于多路径路由（主要是视频或音频流）的特定应用。
Compared to OLSRv2, this extension does not introduce any new message type. A new Message TLV Type is introduced to identify the routers that support forwarding based on the source routing header. It is interoperable with OLSRv2 implementations that do not have this extension: as the MP-OLSRv2 uses source routing, in IPv4 networks the interoperability is achieved using loose source routing headers; in IPv6 networks, it is achieved by eliminating routers that do not support IPv6 strict source routing.
与OLSRv2相比，此扩展没有引入任何新的消息类型。引入了一种新的消息TLV类型，用于根据源路由报头识别支持转发的路由器。它可以与没有此扩展的OLSRv2实现互操作：由于MP-OLSRv2使用源路由，在IPv4网络中，互操作性是通过使用松散的源路由头实现的；在IPv6网络中，它是通过消除不支持IPv6严格源路由的路由器来实现的。
MP-OLSRv2 supports two different but interoperable multipath calculation approaches: proactive and reactive. In the proactive calculation, the paths to all the destinations are calculated before
MP-OLSRv2支持两种不同但可互操作的多路径计算方法：主动式和反应式。在主动计算中，到所有目的地的路径都是在之前计算的
they are needed. In the reactive calculation, only the paths to desired destination(s) are calculated on demand. The proactive approach requires more computational resources than the reactive one. The reactive approach requires the IP forwarding plane to trigger the multipath calculation.
它们是需要的。在无功计算中，仅根据需要计算到所需目的地的路径。主动式方法比被动式方法需要更多的计算资源。被动方法要求IP转发平面触发多路径计算。
MP-OLSRv2 forwards datagrams using the source routing header. As there are multiple paths to each destination, MP-OLSRv2 requires the IP forwarding plane to be able to choose which source route to be put in the source routing header based on the path scheduler defined by MP-OLSRv2. For IPv4 networks, implementation of loose source routing is required following [RFC791]. For IPv6 networks, implementation of strict source routing is required following the source routing header generation and processing defined in [RFC6554].
MP-OLSRv2使用源路由报头转发数据报。由于每个目的地都有多条路径，MP-OLSRv2要求IP转发平面能够根据MP-OLSRv2定义的路径调度器选择要放入源路由报头中的源路由。对于IPv4网络，需要按照[RFC791]实现松散源路由。对于IPv6网络，在[RFC6554]中定义的源路由头生成和处理之后，需要实现严格的源路由。
This specification uses OLSRv2 [RFC7181] to:
本规范使用OLSRv2[RFC7181]来：
o Identify all the reachable routers in the network.
o 识别网络中所有可到达的路由器。
o Identify a sufficient subset of links in the networks so that routes can be calculated to all reachable destinations.
o 确定网络中链路的足够子集，以便可以计算到所有可到达目的地的路由。
o Provide a Routing Set containing the shortest routes from this router to all destinations.
o 提供包含从该路由器到所有目的地的最短路由的路由集。
In addition, the MP-OLSRv2 Routing Process identifies the routers that support source routing by adding a new Message TLV in HELLO and Topology Control (TC) messages. Based on the above information acquired, every MP-OLSRv2 Routing Process is aware of a reduced topology map of the network and the routers supporting source routing.
此外，MP-OLSRv2路由过程通过在HELLO和拓扑控制（TC）消息中添加新消息TLV来识别支持源路由的路由器。基于获得的上述信息，每个MP-OLSRv2路由过程都知道网络和支持源路由的路由器的简化拓扑图。
A Multipath Routing Set containing the multipath information is maintained. It may be either proactively calculated or reactively calculated:
将维护包含多路径信息的多路径路由集。它可以是主动计算的，也可以是反应计算的：
o In the proactive approach, multiple paths to all possible destinations are calculated and updated based on control message exchange. The routes are thus available before they are actually needed.
o 在主动式方法中，基于控制消息交换计算并更新到所有可能目的地的多条路径。因此，这些路线在实际需要之前就已经可用。
o In the reactive approach, a multipath algorithm is invoked on demand, i.e., only when there is a datagram to be sent from the source to the destination and there is no available Routing Tuple in the Multipath Routing Set. This requires the IP forwarding information base to trigger the multipath calculation specified in
o 在反应式方法中，仅当有数据报要从源发送到目的地且多路径路由集中没有可用的路由元组时，才会按需调用多路径算法。这需要IP转发信息库触发中指定的多路径计算
Section 8.5 when no Multipath Routing Tuple is available. The reactive operation is local to the router and no additional exchange of routing control messages is required. When the paths are being calculated, the datagrams SHOULD be buffered unless the router does not have enough memory.
第8.5节当没有多路径路由元组可用时。反应式操作是路由器的本地操作，不需要额外交换路由控制消息。在计算路径时，除非路由器没有足够的内存，否则应该缓冲数据报。
Routers in the same network may choose either proactive or reactive multipath calculation independently according to their computation resources. The Multipath Dijkstra Algorithm (defined in Section 8.5) is introduced as the default algorithm to generate multiple disjoint paths from a source to a destination, and such information is kept in the Multipath Routing Set.
同一网络中的路由器可以根据其计算资源独立地选择主动或被动多径计算。多径Dijkstra算法（定义见第8.5节）被引入作为默认算法，以生成从源到目的地的多条不相交路径，并且此类信息保存在多径路由集中。
The datagram is forwarded based on source routing. When there is a datagram to be sent to a destination, the source router acquires a path from the Multipath Routing Set. The path information is stored in the datagram header using the source routing header.
数据报根据源路由转发。当有数据报要发送到目的地时，源路由器从多路径路由集中获取路径。使用源路由报头将路径信息存储在数据报报头中。
In addition to the parameters and constants defined in [RFC7181], this specification uses the parameters and constants described in this section.
除了[RFC7181]中定义的参数和常量外，本规范还使用本节中描述的参数和常量。
NUMBER_OF_PATHS: The number of paths desired by the router.
路径数：路由器所需的路径数。
MAX_SRC_HOPS: The maximum number of hops allowed to be put in the source routing header. A value set to 0 means there is no limitation on the maximum number of hops. In an IPv6 network, it MUST be set to 0 because [RFC6554] supports only strict source routing. All the intermediate routers MUST be included in the source routing header, which is a various number of hops. In an IPv4 network, it MUST be strictly less than 11 and greater than 0 due to the length limit of the IPv4 header.
MAX_SRC_HOPS：允许放入源路由头中的最大跳数。值设置为0表示对最大跳数没有限制。在IPv6网络中，它必须设置为0，因为[RFC6554]只支持严格的源路由。所有中间路由器都必须包含在源路由报头中，该报头是不同数量的跃点。在IPv4网络中，由于IPv4标头的长度限制，它必须严格小于11且大于0。
CUTOFF_RATIO: The ratio that defines the maximum metric of a path compared to the shortest path kept in the OLSRv2 Routing Set. For example, the metric to a destination is R_metric based on the Routing Set. Then, the maximum metric allowed for a path is CUTOFF_RATIO * R_metric. CUTOFF_RATIO MUST be greater than or equal to 1. Setting the number low makes it less likely that additional paths will be found -- for example, setting it to 1 will mean only equal length paths are considered.
截止比：定义路径的最大度量与OLSRv2路由集中保留的最短路径相比的比率。例如，到目的地的度量是基于路由集的R_度量。然后，路径允许的最大度量是截止比*R\u度量。截止比必须大于或等于1。将数字设置为低会降低找到其他路径的可能性——例如，将其设置为1意味着只考虑等长路径。
SR_TC_INTERVAL: The maximum time between the transmission of two successive TC messages by an MP-OLSRv2 Routing Process.
SR_TC_INTERVAL：MP-OLSRv2路由过程传输两个连续TC消息之间的最长时间。
SR_HOLD_TIME: The minimum value in the TLV with Type = VALIDITY_TIME included in TC messages generated based on SR_TC_INTERVAL.
SR_HOLD_TIME：TLV中的最小值，Type=VALIDITY_TIME，包含在基于SR_TC_间隔生成的TC消息中。
This extension employs the routing control messages HELLO and TC as defined in OLSRv2 [RFC7181] to obtain network topology information. For the datagram to support source routing, a source routing header is added to each datagram routed by this extension. Depending on the IP version used, the source routing header is defined in this section.
此扩展使用OLSRv2[RFC7181]中定义的路由控制消息HELLO和TC来获取网络拓扑信息。对于支持源路由的数据报，将向该扩展路由的每个数据报添加一个源路由报头。根据使用的IP版本，本节定义了源路由标头。
HELLO and TC messages used by the MP-OLSRv2 Routing Process use the same format as defined in [RFC7181]. In addition, a new Message TLV Type is defined to identify the originator of the HELLO or TC message that supports source-route forwarding. The new Message TLV Type is introduced for enabling MP-OLSRv2 as an extension of OLSRv2: only the routers supporting source-route forwarding can be used in the source routing header of a datagram because adding a router that does not understand the source routing header will cause routing failure.
MP-OLSRv2路由过程使用的HELLO和TC消息使用与[RFC7181]中定义的格式相同的格式。此外，还定义了新的消息TLV类型，以标识支持源路由转发的HELLO或TC消息的发起人。引入新的消息TLV类型是为了启用MP-OLSRv2作为OLSRv2的扩展：数据报的源路由报头中只能使用支持源路由转发的路由器，因为添加不理解源路由报头的路由器将导致路由失败。
The SOURCE_ROUTE TLV is a Message TLV signaling that the message is generated by a router that supports source-route forwarding. It can be an MP-OLSRv2 Routing Process or an OLSRv2 Routing Process that supports source-route forwarding.
源路由TLV是一种消息TLV，表示该消息由支持源路由转发的路由器生成。它可以是MP-OLSRv2路由进程，也可以是支持源路由转发的OLSRv2路由进程。
Every HELLO or TC message generated by a MP-OLSRv2 Routing Process MUST have exactly one SOURCE_ROUTE TLV without value.
MP-OLSRv2路由过程生成的每个HELLO或TC消息必须只有一个源路由TLV（无值）。
Every HELLO or TC message generated by an OLSRv2 Routing Process MUST have exactly one SOURCE_ROUTE TLV, if the OLSRv2 Routing Process supports source-route forwarding, and be willing to join the source route generated by other MP-OLSRv2 Routing Processes. The existence of SOURCE_ROUTE TLV MUST be consistent for a specific OLSRv2 Routing Process, i.e., either it adds SOURCE_ROUTE TLV to all its HELLO/TC messages or it does not add SOURCE_ROUTE TLV to any HELLO/TC messages.
如果OLSRv2路由进程支持源路由转发，并且愿意加入其他MP-OLSRv2路由进程生成的源路由，则OLSRv2路由进程生成的每个HELLO或TC消息必须恰好有一个源路由TLV。对于特定的OLSRv2路由过程，源路由TLV的存在必须一致，即，它将源路由TLV添加到其所有HELLO/TC消息中，或者不将源路由TLV添加到任何HELLO/TC消息中。
In IPv4 [RFC791] networks, the MP-OLSRv2 Routing Process employs the loose source routing header, as defined in [RFC791]. It exists as an option header with option class 0 and option number 3.
在IPv4[RFC791]网络中，MP-OLSRv2路由过程采用松散源路由报头，如[RFC791]中所定义。它作为选项标题存在，选项类别为0，选项编号为3。
The source route information is kept in the "route data" field of the loose source routing header.
源路由信息保存在松散源路由标头的“路由数据”字段中。
In IPv6 [RFC8200] networks, the MP-OLSRv2 Routing Process employs the source routing header, as defined in Section 3 of [RFC6554], with IPv6 Routing Type 3.
在IPv6[RFC8200]网络中，MP-OLSRv2路由过程使用源路由头，如[RFC6554]第3节中所定义，IPv6路由类型为3。
The source route information is kept in the "Addresses" field of the routing header.
源路由信息保存在路由标头的“地址”字段中。
Each MP-OLSRv2 Routing Process maintains the information bases as defined in [RFC7181]. Additionally, a Multipath Information Base is used for this specification. It includes the protocol sets as defined below.
每个MP-OLSRv2路由过程维护[RFC7181]中定义的信息库。此外，本规范还使用了多路径信息库。它包括如下定义的协议集。
The SR-OLSRv2 Router Set records the routers that support source-route forwarding. This includes routers that run the MP-OLSRv2 Routing Process or the OLSRv2 Routing Process with source-route forwarding support. The set consists of SR-OLSRv2 Routing Tuple:
SR-OLSRv2路由器集记录支持源路由转发的路由器。这包括运行MP-OLSRv2路由过程或具有源路由转发支持的OLSRv2路由过程的路由器。该集合由SR-OLSRv2路由元组组成：
(SR_addr, SR_time)
（高级地址，高级时间）
where:
哪里：
SR_addr is the originator address of the router that supports source-route forwarding.
SR_addr是支持源路由转发的路由器的发起者地址。
SR_time is the time until which the SR-OLSRv2 Routing Tuple is considered valid.
SR_time是SR-OLSRv2路由元组被视为有效的时间。
The Multipath Routing Set records the full path information of different paths to the destination. It consists of Multipath Routing Tuple:
多路径路由集记录到目标的不同路径的完整路径信息。它由多路径路由元组组成：
(MR_dest_addr, MR_path_set)
（MR_dest_addr，MR_path_set）
where:
哪里：
MR_dest_addr is the network address of the destination; it is either the network address of an interface of a destination router or the network address of an attached network.
MR_dest_addr是目的地的网络地址；它是目标路由器接口的网络地址或连接网络的网络地址。
MP_path_set contains the multiple paths to the destination and it consists of a set of Path Tuples.
MP_path_set包含指向目标的多条路径，它由一组路径元组组成。
Each Path Tuple is defined as:
每个路径元组定义为：
(PT_metric, PT_address[1], PT_address[2], ..., PT_address[n])
（PT_度量，PT_地址[1]，PT_地址[2]，…，PT_地址[n]）
where:
哪里：
PT_metric is the metric of the path to the destination, measured in LINK_METRIC_TYPE defined in [RFC7181].
PT_metric是到目的地的路径的度量，在[RFC7181]中定义的链路_metric_类型中测量。
PT_address[1, ..., n-1] are the addresses of intermediate routers to be visited, numbered from 1 to n-1, where n is the number of routers in the path, i.e., the hop count.
PT_address[1，…，n-1]是要访问的中间路由器的地址，编号从1到n-1，其中n是路径中路由器的数量，即跳数。
This protocol is based on OLSRv2 and is extended to discover multiple disjoint paths from a source router to a destination router. It retains the formats of the basic routing control packets and the processing of OLSRv2 to obtain the topology information of the network. The main differences from the OLSRv2 Routing Process are the datagram processing at the source router and datagram forwarding.
该协议基于OLSRv2，并扩展为发现从源路由器到目标路由器的多条不相交路径。它保留基本路由控制包的格式和OLSRv2的处理，以获取网络的拓扑信息。与OLSRv2路由过程的主要区别在于源路由器上的数据报处理和数据报转发。
HELLO messages are generated according to Section 15.1 of [RFC7181], plus a single message TLV with Type := SOURCE_ROUTE included.
HELLO消息是根据[RFC7181]的第15.1节生成的，加上一条消息TLV，类型为：=包括源路由。
TC messages are generated according to Section 16.1 of [RFC7181], plus a single message TLV with Type := SOURCE_ROUTE included.
TC消息是根据[RFC7181]第16.1节生成的，外加一条类型为：=包括源路由的消息TLV。
For the routers that do not generate TC messages according to [RFC7181], at least one TC message MUST be generated by an MP-OLSRv2 Routing Process during the SR_TC_INTERVAL (Section 5), which MUST be greater than or equal to TC_INTERVAL. Those TC messages MUST NOT carry any advertised neighbor addresses. This serves for those routers to advertise the SOURCE_ROUTE TLV so that the other routers can be aware of the routers that are source-route enabled so as to be used as destinations of multipath routing. The validity time associated with the VALIDITY_TIME TLV in such TC messages equals SR_HOLD_TIME, which MUST be greater than the SR_TC_INTERVAL. If the TC message carries an optional INTERVAL_TIME TLV, it MUST have a value encoding the SR_TC_INTERVAL.
对于未根据[RFC7181]生成TC消息的路由器，在SR_TC_间隔（第5节）期间，MP-OLSRv2路由过程必须至少生成一条TC消息，该间隔必须大于或等于TC_间隔。这些TC消息不得携带任何播发的邻居地址。这用于那些路由器通告源路由TLV，以便其他路由器可以知道启用了源路由以便用作多路径路由的目的地的路由器。与此类TC消息中的validity_time TLV关联的有效时间等于SR_HOLD_time，该时间必须大于SR_TC_间隔。如果TC消息包含可选的间隔时间TLV，则它必须具有编码SR\U TC\U间隔的值。
HELLO and TC messages are processed according to Sections 15.3 and 16.3 of [RFC7181].
HELLO和TC消息根据[RFC7181]第15.3节和第16.3节进行处理。
In addition to the reasons specified in [RFC7181] for discarding a HELLO message or a TC message on reception, a HELLO or TC message received MUST be discarded if it has more than one Message TLV with Type = SOURCE_ROUTE.
除了[RFC7181]中规定的在接收时丢弃HELLO消息或TC消息的原因外，如果收到的HELLO或TC消息具有多个类型为SOURCE_ROUTE的消息TLV，则必须丢弃该消息。
For every HELLO or TC message received, if there is a Message TLV with Type := SOURCE_ROUTE, create or update (if the Tuple exists already) the SR-OLSR Routing Tuple with:
对于收到的每个HELLO或TC消息，如果存在类型为：=SOURCE_ROUTE的消息TLV，则创建或更新（如果元组已存在）SR-OLSR路由元组，并使用：
o SR_addr := originator address of the HELLO or TC message
o SR_addr:=HELLO或TC消息的发起人地址
o SR_time := current_time + validity time of the TC or HELLO message defined in [RFC7181].
o SR_时间：=当前_时间+在[RFC7181]中定义的TC或HELLO消息的有效时间。
Each MP-OLSRv2 Routing Process selects routing MPRs and flooding MPRs following Section 18 of [RFC7181]. In a mixed network with OLSRv2-only routers, the following considerations apply when calculating MPRs:
每个MP-OLSRv2路由过程根据[RFC7181]第18节选择路由MPR和泛洪MPR。在仅使用OLSRv2路由器的混合网络中，计算MPR时应考虑以下因素：
o MP-OLSRv2 routers SHOULD be preferred as routing MPRs to increase the possibility of finding disjoint paths using MP-OLSRv2 routers.
o 应首选MP-OLSRv2路由器作为路由MPR，以增加使用MP-OLSRv2路由器查找不相交路径的可能性。
o The number of routing MPRs that run the MP-OLSRv2 Routing Process MUST be equal to or greater than NUMBER_OF_PATHS if there are enough MP-OLSRv2 symmetric neighbors. Otherwise, all the MP-OLSRv2 routers are selected as routing MPRs, except the routers with willingness WILL_NEVER.
o 如果有足够的MP-OLSRv2对称邻居，则运行MP-OLSRv2路由进程的路由MPR数必须等于或大于\u路径数。否则，所有MP-OLSRv2路由器都被选为路由MPR，除非愿意的路由器永远不会。
If datagrams without a source routing header need to be forwarded using multiple paths (for example, based on the information of a Diffserv codepoint [RFC2474]), the MP-OLSRv2 Routing Process will try to find the Multipath Routing Tuple where:
如果无源路由报头的数据报需要使用多条路径转发（例如，基于Diffserv代码点[RFC2474]的信息），MP-OLSRv2路由过程将尝试查找多路径路由元组，其中：
o MR_dest_addr = destination of the datagram
o MR_dest_addr=数据报的目的地
If no matching Multipath Routing Tuple is found and the Multipath Routing Set is maintained proactively, it indicates that there is no multipath route available to the desired destination. The datagram is forwarded following the OLSRv2 Routing Process.
如果未找到匹配的多路径路由元组，并且主动维护多路径路由集，则表示没有可用于所需目的地的多路径路由。数据报在OLSRv2路由过程之后转发。
If no matching Multipath Routing Tuple is found and the Multipath Routing Set is maintained reactively, the multipath algorithm defined in Section 8.5 is invoked to calculate the Multipath Routing Tuple to the destination. If the calculation does not return any Multipath Routing Tuple, the following steps are aborted and the datagram is forwarded following the OLSRv2 Routing Process.
如果未找到匹配的多路径路由元组，且多路径路由集以反应方式维护，则调用第8.5节中定义的多路径算法来计算到目的地的多路径路由元组。如果计算未返回任何多路径路由元组，则中止以下步骤，并在OLSRv2路由过程后转发数据报。
If a matching Multipath Routing Tuple is obtained, the Path Tuples of the Multipath Routing Tuple are applied to the datagrams using either per-flow or per-datagram scheduling, depending on the transport layer protocol and the application used. By default, per-flow scheduling is used, especially for the transport protocols that are sensitive to reordering, such as TCP. The path-selection decision is made on the first datagram and all subsequent datagrams of the same flow use the same path. If the path breaks before the flow is closed, another path with the most similar metric is used. Per-datagram scheduling is recommended if the traffic is insensitive to reordering such as unreliable transmission of media traffic or when erasure coding is applied. In such a case, each datagram selects its paths independently.
如果获得匹配的多路径路由元组，则多路径路由元组的路径元组将使用每流或每数据报调度应用于数据报，具体取决于传输层协议和所使用的应用程序。默认情况下，使用每流调度，特别是对于对重新排序敏感的传输协议，如TCP。在第一个数据报上做出路径选择决策，并且相同流的所有后续数据报使用相同的路径。如果在关闭流之前路径中断，则使用具有最相似度量的另一条路径。如果流量对重新排序不敏感，例如媒体流量的不可靠传输或应用擦除编码时，建议按数据报调度。在这种情况下，每个数据报独立地选择其路径。
By default, the traffic load should be equally distributed in multiple paths. Other path-scheduling mechanisms (e.g., assigning more traffic over better paths) are also possible and will not impact the interoperability of different implementations.
默认情况下，流量负载应均匀分布在多条路径中。其他路径调度机制（例如，在更好的路径上分配更多流量）也是可能的，并且不会影响不同实现的互操作性。
The addresses in PT_address[1, ..., n-1] of the chosen Path Tuple are thus added to the datagram header as the source routing header. For IPv6 networks, strict source routing is used; thus, all the intermediate routers in the path are stored in the source routing header following the format defined in Section 3 of [RFC6554] with the Routing Type set to 3.
因此，所选路径元组的PT_地址[1，…，n-1]中的地址被添加到数据报报头，作为源路由报头。对于IPv6网络，使用严格的源路由；因此，路径中的所有中间路由器按照[RFC6554]第3节中定义的格式存储在源路由报头中，路由类型设置为3。
For IPv4 networks, loose source routing is used with the following rules:
对于IPv4网络，松散源路由与以下规则一起使用：
o Only the addresses that exist in the SR-OLSR Router Set can be added to the source routing header.
o 只有SR-OLSR路由器集中存在的地址才能添加到源路由标头。
o If the length of the path (n) is greater than MAX_SRC_HOPS (Section 5) or if adding the whole path information exceeds the MTU, only the "key" routers in the path are kept. By default, the key routers are uniformly chosen in the path. If further information, such as the capacity of the routers (e.g., battery life) or the routers' willingness in forwarding data, is available, the routers with higher capacity and willingness are preferred.
o 如果路径长度（n）大于MAX_SRC_HOPS（第5节），或者如果添加的整个路径信息超过MTU，则仅保留路径中的“密钥”路由器。默认情况下，在路径中统一选择关键路由器。如果进一步的信息可用，例如路由器的容量（例如，电池寿命）或路由器转发数据的意愿，则优选具有更高容量和意愿的路由器。
o The routers that are considered not appropriate for forwarding indicated by external policies should be avoided.
o 应避免使用外部策略指示的不适合转发的路由器。
It is not recommended to fragment the IP packet if the packet with the source routing header would exceed the minimum MTU along the path. Depending on the size of the routing domain, the MTU should be at least 1280 + 40 (for the outer IP header) + 16 * diameter of the network in number of hops (for the source routing header). If the links in the network have different MTU sizes, by using technologies like Path MTU Discovery, the routers are able to be aware of the MTU along the path. The size of the datagram plus the size of IP headers (including the source routing header) should not exceed the minimum MTU along the path; otherwise, the source routing should not be used.
如果带有源路由报头的数据包将超过路径上的最小MTU，则不建议对IP数据包进行分段。根据路由域的大小，MTU应至少为1280+40（对于外部IP报头）+16*网络直径（以跳数计）（对于源路由报头）。如果网络中的链路具有不同的MTU大小，则通过使用路径MTU发现等技术，路由器能够感知路径上的MTU。数据报的大小加上IP报头（包括源路由报头）的大小不应超过路径上的最小MTU；否则，不应使用源路由。
If the destination of the datagrams is out of the MP-OLSRv2 routing domain, the datagram must be source routed to the gateway between the MP-OLSRv2 routing domain and the rest of the Internet. The gateway MUST remove the source routing header before forwarding the datagram to the rest of the Internet.
如果数据报的目的地不在MP-OLSRv2路由域中，则必须将数据报源路由到MP-OLSRv2路由域与Internet其余部分之间的网关。在将数据报转发到Internet的其余部分之前，网关必须删除源路由报头。
The Multipath Routing Set maintains the information of multiple paths to the destination. The Path Tuples of the Multipath Routing Set (Section 7.2) are generated based on a multipath algorithm.
多路径路由集维护到目标的多条路径的信息。多路径路由集（第7.2节）的路径元组是基于多路径算法生成的。
For each path to a destination, the algorithm must provide:
对于到达目的地的每条路径，算法必须提供：
o The metric of the path to the destination,
o 目标路径的度量，
o The list of intermediate routers on the path.
o 路径上的中间路由器列表。
For IPv6 networks, as strict source routing is used, only the routers that exist in the SR-OLSRv2 Router Set are considered in the path calculation, i.e., only the source-routing-supported routers can exist in the path.
对于IPv6网络，由于使用严格的源路由，因此在路径计算中仅考虑SR-OLSRv2路由器集中存在的路由器，即，路径中只能存在源路由支持的路由器。
After the calculation of multiple paths, the metric of paths (denoted c_i for path i) to the destination is compared to the R_metric of the OLSRv2 Routing Tuple ([RFC7181]) to the same destination. If the metric c_i is greater than R_metric * CUTOFF_RATIO (Section 5), the corresponding path i SHOULD NOT be used. If less than two paths are found with metrics less than R_metric * CUTOFF_RATIO, the router SHOULD fall back to OLSRv2 Routing Process without using multipath routing. This can happen if there are too many OLSRv2-only routers in the network, and requiring multipath routing may result in inferior paths.
在计算多条路径之后，将到目的地的路径度量（表示为路径i的c_i）与到相同目的地的OLSRv2路由元组（[RFC7181]）的R_度量进行比较。如果度量c_i大于R_度量*截止比（第5节），则不应使用相应的路径i。如果发现少于两条路径的度量值小于R_metric*CUTOFF_比率，则路由器应退回到OLSRv2路由过程，而不使用多路径路由。如果网络中有太多仅OLSRv2的路由器，并且需要多路径路由可能会导致较差的路径，则可能会发生这种情况。
By invoking the multipath algorithm, up to NUMBER_OF_PATHS paths are obtained and added to the Multipath Routing Set by creating a Multipath Routing Tuple with:
通过调用多路径算法，通过创建具有以下内容的多路径路由元组，可获得最多数量的多路径，并将其添加到多路径路由集中：
o MR_dest_addr := destination of the datagram.
o MR_dest_addr:=数据报的目的地。
o An MP_path_set with calculated Path Tuples. Each Path Tuple corresponds to a path obtained in the Multipath Dijkstra Algorithm, with PT_metric := metric of the calculated path and PT_address[1, ..., n-1] := list of intermediate routers.
o 具有计算路径元组的MP_路径集。每个路径元组对应于在多路径Dijkstra算法中获得的路径，其中PT_度量：=计算路径的度量，PT_地址[1，…，n-1]：=中间路由器的列表。
This section introduces the Multipath Dijkstra Algorithm as a default algorithm. It tries to obtain disjoint paths when appropriate, but it does not guarantee strict disjoint paths. The use of other algorithms is not prohibited, as long as the requirements described in Section 8.5.1 are met. Using different multipath algorithms will not impact the interoperability.
本节介绍作为默认算法的多路径Dijkstra算法。它试图在适当的时候获得不相交的路径，但不能保证严格的不相交路径。只要满足第8.5.1节所述要求，不禁止使用其他算法。使用不同的多路径算法不会影响互操作性。
The general principle of the Multipath Dijkstra Algorithm [ADHOC11] is to use the Dijkstra Algorithm for multiple iterations and to look for the shortest path P[i] to the destination d at iteration i. After each iteration, the metric of used links is increased. Compared to the original Dijkstra's algorithm, the main modification consists in adding two incremental functions, named metric functions fp and fe, in order to prevent the next steps resulting in similar paths:
多径Dijkstra算法[ADHOC11]的一般原理是使用Dijkstra算法进行多次迭代，并在迭代i时寻找到目的地d的最短路径P[i]。在每次迭代之后，已使用链接的度量都会增加。与原来的Dijkstra算法相比，主要修改在于添加两个增量函数，即度量函数fp和fe，以防止后续步骤导致类似路径：
o fp(c) is used to increase metrics of arcs belonging to the previous path P[i-1] (with i>1), where c is the value of the previous metric. This encourages future paths to use different arcs but not different vertices.
o fp（c）用于增加属于先前路径P[i-1]（i>1）的弧的度量，其中c是先前度量的值。这鼓励将来的路径使用不同的圆弧，而不是不同的顶点。
o fe(c) is used to increase metrics of the arcs that lead to intermediate vertices of the previous path P[i-1] (with i>1), where c is the value of the previous metric. The "lead to" means that only one vertex of the arc belongs to the previous path P[i-1] while the other vertex does not. The "intermediate" means that the source and destination vertices are not considered.
o fe（c）用于增加通向前一路径P[i-1]（i>1）中间顶点的弧的度量，其中c是前一度量的值。“引线到”表示弧的一个顶点只属于前一路径P[i-1]，而另一个顶点不属于前一路径P[i-1]。“中间”表示不考虑源顶点和目标顶点。
Consider the simple example in Figure 1: a path P[i] S--A--D is obtained at step i. For the next step, the metric of link S--A and A--D are to be increased using fp(c) because they belong to the path P[i]. A--B is to be increased using fe(c) because A is an intermediate vertex of path P[i], and B is not part of P[i]. B--D is unchanged.
考虑图1中的简单示例：在步骤i中获得路径P[i] s -A -D。对于下一步，将使用fp（c）增加链路S--A和A--D的度量，因为它们属于路径P[i]。因为A是路径P[i]的中间顶点，而B不是路径P[i]的一部分，所以A--B要用fe（c）来增加。B--D不变。
B
/ \
/ \
/ \
S---------A-----------D
B
/ \
/ \
/ \
S---------A-----------D
Figure 1
图1
It is possible to choose a different fp and fe to get link-disjoint paths or node-disjoint paths as desired. A recommendation for configuration of fp and fe is given in Section 9.
可以根据需要选择不同的fp和fe以获得链路不相交路径或节点不相交路径。第9节给出了fp和fe配置的建议。
To get NUMBER_OF_PATHS different paths, for each path P[i] (i = 1, ..., NUMBER_OF_PATHS):
要获取不同路径的路径数，对于每个路径P[i]（i=1，…，路径数）：
1. Run Dijkstra's algorithm to get the shortest path P[i] for the destination d.
1. 运行Dijkstra算法获得目的地d的最短路径P[i]。
2. Apply metric function fp to the metric of links (in both directions) in P[i].
2. 将度量函数fp应用于P[i]中链路（两个方向）的度量。
3. Apply metric function fe to the metric of links (in both directions) that lead to routers used in P[i].
3. 将度量函数fe应用于导致P[i]中使用的路由器的链路（在两个方向）的度量。
A simple example of the Multipath Dijkstra Algorithm is illustrated in Appendix A.
附录A中给出了多径Dijkstra算法的一个简单示例。
The Multipath Routing Set MUST be updated when the Local Information Base, the Neighborhood Information Base, or the Topology Information Base indicate a change (including a change 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 as described in Section 17.7 of [RFC7181]. How the Multipath Routing Set is updated depends on whether the set is maintained reactively or proactively:
当本地信息库、邻域信息库或拓扑信息库指示MANET中已知对称链路和/或连接网络的变化（包括任何潜在使用的传出邻居度量值的变化）时，必须更新多路径路由集，因此，按照[RFC7181]第17.7节所述更改拓扑图。多路径路由集的更新方式取决于该集是被动维护还是主动维护：
o In reactive mode, all the Tuples in the Multipath Routing Set are removed. The new arriving datagrams will be processed as specified in Section 8.4.
o 在反应模式下，将删除多路径路由集中的所有元组。新到达的数据报将按照第8.4节的规定进行处理。
o In proactive mode, the routes to all the destinations are updated according to Section 8.5.
o 在主动模式下，根据第8.5节更新到所有目的地的路线。
In IPv4 networks, datagrams are forwarded using loose source routing as specified in Section 3.1 of [RFC791].
在IPv4网络中，按照[RFC791]第3.1节的规定，使用松散源路由转发数据报。
In IPv6 networks, datagrams are forwarded using strict source routing as specified in Section 4.2 of [RFC6554], except the applied routers are MP-OLSRv2 routers rather than RPL routers. The last hop of the source route MUST remove the source routing header.
在IPv6网络中，使用[RFC6554]第4.2节中规定的严格源路由转发数据报，但应用的路由器是MP-OLSRv2路由器而不是RPL路由器。源路由的最后一个跃点必须删除源路由标头。
This section gives default values and guidelines for setting parameters defined in Section 5. Network administrators may wish to change certain or all the parameters for different network scenarios. As an experimental protocol, the users of this protocol are also encouraged to explore different parameter settings in various network environments and provide feedback.
本节给出了第5节中定义的设置参数的默认值和指南。网络管理员可能希望更改不同网络场景的某些或所有参数。作为一个实验协议，我们还鼓励该协议的用户探索各种网络环境中的不同参数设置并提供反馈。
o NUMBER_OF_PATHS := 3. This parameter defines the number of parallel paths used in datagram forwarding. Setting it to 1 makes the specification identical to OLSRv2. Setting it to too large of a value may lead to unnecessary computational overhead and inferior paths.
o 路径数：=3。此参数定义数据报转发中使用的并行路径数。将其设置为1将使规范与OLSRv2相同。将其设置为太大的值可能会导致不必要的计算开销和较差的路径。
o MAX_SRC_HOPS := 10, for IPv4 networks. For IPv6 networks, it MUST be set to 0, i.e., no constraint on the maximum number of hops.
o 对于IPv4网络，最大跳数：=10。对于IPv6网络，它必须设置为0，即对最大跳数没有限制。
o CUTOFF_RATIO := 1.5. It MUST be greater than or equal to 1.
o 截止比：=1.5。它必须大于或等于1。
o SR_TC_INTERVAL := 10 x TC_INTERVAL. It MUST be greater than or equal to TC_INTERVAL. It SHOULD be significantly greater than TC_INTERVAL to reduce unnecessary TC message generations.
o SR\u TC\u间隔：=10 x TC\u间隔。它必须大于或等于TC_间隔。它应该显著大于TC_间隔，以减少不必要的TC消息生成。
o SR_HOLD_TIME := 3 x SR_TC_INTERVAL. It MUST be greater than SR_TC_INTERVAL and SHOULD allow for a small number of lost messages.
o SR\U保持时间：=3 x SR\U TC\U间隔。它必须大于SR_TC_INTERVAL，并应允许少量丢失的消息。
If the Multipath Dijkstra Algorithm is applied:
如果采用多路径Dijkstra算法：
o fp(c) := 4*c, where c is the original metric of the link.
o fp（c）：=4*c，其中c是链路的原始度量。
o fe(c) := 2*c, where c is the original metric of the link.
o fe（c）：=2*c，其中c是链路的原始度量。
The setting of metric functions fp and fc defines the preference of obtained multiple disjoint paths. If id is the identity function, i.e., fp(c)=c, three cases are possible:
度量函数fp和fc的设置定义了获得的多条不相交路径的偏好。如果id是标识函数，即fp（c）=c，则有三种情况：
o if id=fe<fp, only increase the metric of related links;
o 如果id=fe<fp，只增加相关链接的度量；
o if id<fe=fp, apply equal increase to the metric of related nodes and links;
o 如果id<fe=fp，则对相关节点和链路的度量应用相等的增量；
o if id<fe<fp, apply greater increase to the metric of related links.
o 如果id<fe<fp，则对相关链接的度量应用更大的增加。
Increasing the metric of related links or nodes means avoiding the use of such links or nodes in the next path to be calculated.
增加相关链接或节点的度量意味着避免在下一个要计算的路径中使用此类链接或节点。
As an extension of [RFC7181], the security considerations and security architecture illustrated in [RFC7181] are applicable to this MP-OLSRv2 specification. The implementations without security mechanisms are vulnerable to threats discussed in [RFC8116].
作为[RFC7181]的扩展，[RFC7181]中说明的安全注意事项和安全体系结构适用于本MP-OLSRv2规范。没有安全机制的实现容易受到[RFC8116]中讨论的威胁。
In a mixed network with OLSRv2-only routers, a compromised router can add SOURCE_ROUTE TLVs in its TC and HELLO messages, which will make other MP-OLSRv2 Routing Processes believe that it supports source routing. This will increase the possibility of being chosen as MPRs and put into the source routing header. The former will make it possible to manipulate the flooding of TC messages and the latter will make the datagram pass through the compromised router.
在只有OLSRv2路由器的混合网络中，受损路由器可以在其TC和HELLO消息中添加源路由TLV，这将使其他MP-OLSRv2路由进程相信它支持源路由。这将增加被选择为MPR并放入源路由报头的可能性。前者可以操纵TC消息的泛滥，后者可以使数据报通过受损的路由器。
As with [RFC7181], a conformant implementation of MP-OLSRv2 MUST, at minimum, implement the security mechanisms specified in [RFC7183] to provide integrity and replay protection of routing control messages.
与[RFC7181]一样，MP-OLSRv2的一致性实现必须至少实现[RFC7183]中规定的安全机制，以提供路由控制消息的完整性和重播保护。
The MP-OLSRv2 Routing Process MUST drop datagrams entering or exiting an OLSRv2/MP-OLSRv2 routing domain that contain a source routing header. Compared to OLSRv2, the use of the source routing header in this specification introduces vulnerabilities related to source routing attacks, which include bypassing filtering devices, bandwidth exhaustion of certain routers, etc. Those attacks are discussed in Section 5 of [RFC6554] and [RFC5095]. The influence is limited to the OLSRv2/MP-OLSRv2 routing domain because the source routing header is used only in the current routing domain.
MP-OLSRv2路由进程必须丢弃进入或退出包含源路由头的OLSRv2/MP-OLSRv2路由域的数据报。与OLSRv2相比，本规范中使用源路由报头引入了与源路由攻击相关的漏洞，包括绕过过滤设备、某些路由器的带宽耗尽等。这些攻击在[RFC6554]和[RFC5095]的第5节中讨论。影响仅限于OLSRv2/MP-OLSRv2路由域，因为源路由头仅在当前路由域中使用。
If the multiple paths are calculated reactively, the datagrams SHOULD be buffered while the paths are being calculated. Because the path calculation is local and no control message is exchanged, the buffering time should be trivial. However, depending on the CPU power and memory of the router, a maximum buffer size SHOULD be set to avoid occupying too much memory of the router. When the buffer is full, the oldest datagrams are dropped. A possible attack that a malicious application could launch would be one in which it initiates a large amount of datagrams to all the other routers in the network, thus triggering path calculation to all the other routers and during which the datagrams are buffered. This might flush other legitimate datagrams. But the impact of the attack is transient: once the path calculation is finished, the datagrams are forwarded and the buffer goes back to empty.
如果以反应方式计算多条路径，则应在计算路径时缓冲数据报。因为路径计算是本地的，并且没有交换控制消息，所以缓冲时间应该很短。但是，根据路由器的CPU功率和内存，应设置最大缓冲区大小，以避免占用太多路由器内存。当缓冲区已满时，最早的数据报将被丢弃。恶意应用程序可能发起的一种攻击是，它向网络中的所有其他路由器发起大量数据报，从而触发到所有其他路由器的路径计算，并在此期间缓冲数据报。这可能会刷新其他合法数据报。但攻击的影响是暂时的：一旦路径计算完成，数据报将被转发，缓冲区将变为空。
This section adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV.
本节添加一个新消息TLV，作为新类型扩展分配给现有消息TLV。
This specification updates the "Type 7 Message TLV Type Extensions" registry [RFC7181] by adding the new Type Extension SOURCE_ROUTE, as illustrated in Table 1.
本规范通过添加新的类型扩展源路由来更新“类型7消息TLV类型扩展”注册表[RFC7181]，如表1所示。
+-----------+--------------+------------------------+---------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+--------------+------------------------+---------------+
| 2 | SOURCE_ROUTE | Indicates that the | This |
| | | originator of the | specification |
| | | message supports | |
| | | source-route | |
| | | forwarding. No value. | |
+-----------+--------------+------------------------+---------------+
+-----------+--------------+------------------------+---------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+--------------+------------------------+---------------+
| 2 | SOURCE_ROUTE | Indicates that the | This |
| | | originator of the | specification |
| | | message supports | |
| | | source-route | |
| | | forwarding. No value. | |
+-----------+--------------+------------------------+---------------+
Table 1: SOURCE_ROUTE Type for Type 7 Message TLV Type Extensions
表1:7类消息TLV类型扩展的源路由类型
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://www.rfc-editor.org/info/rfc5444>.
[RFC5444]Clausen，T.，Dearlove，C.，Dean，J.，和C.Adjih，“通用移动自组网（MANET）数据包/消息格式”，RFC 5444，DOI 10.17487/RFC54442009年2月<https://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, <https://www.rfc-editor.org/info/rfc6130>.
[RFC6130]Clausen，T.，Dearlove，C.，和J.Dean，“移动自组织网络（MANET）邻域发现协议（NHDP）”，RFC 6130，DOI 10.17487/RFC6130，2011年4月<https://www.rfc-editor.org/info/rfc6130>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <https://www.rfc-editor.org/info/rfc6554>.
[RFC6554]Hui，J.，Vasseur，JP.，Culler，D.，和V.Manral，“低功耗和有损网络（RPL）路由协议源路由的IPv6路由头”，RFC 6554，DOI 10.17487/RFC6554，2012年3月<https://www.rfc-editor.org/info/rfc6554>.
[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, <https://www.rfc-editor.org/info/rfc7181>.
[RFC7181]Clausen，T.，Dearlove，C.，Jacquet，P.，和U.Herberg，“优化链路状态路由协议版本2”，RFC 7181，DOI 10.17487/RFC7181，2014年4月<https://www.rfc-editor.org/info/rfc7181>.
[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, DOI 10.17487/RFC7183, April 2014, <https://www.rfc-editor.org/info/rfc7183>.
[RFC7183]Herberg，U.，Dearlove，C.，和T.Clausen，“邻域发现协议（NHDP）和优化链路状态路由协议版本2（OLSRv2）的完整性保护”，RFC 7183，DOI 10.17487/RFC7183，2014年4月<https://www.rfc-editor.org/info/rfc7183>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[ADHOC11] Yi, J., Adnane, A., David, S., and B. Parrein, "Multipath optimized link state routing for mobile ad hoc networks", Elsevier Ad Hoc Networks, Volume 9, Number 1, pp 28-47, DOI 10.1016/j.adhoc.2010.04.007, January 2011.
[ADHOC11]Yi，J.，Adnane，A.，David，S.，和B.Parrein，“移动自组织网络的多路径优化链路状态路由”，爱思唯尔自组织网络，第9卷，第1号，第28-47页，DOI 10.1016/J.adhoc.2010.04.007，2011年1月。
[GIIS14] Macedo, R., Melo, R., Santos, A., and M. Nogueria, "Experimental performance comparison of single-path and multipath routing in VANETs", In the Global Information Infrastructure and Networking Symposium (GIIS), Volume 1, Number 6, pp 15-19, DOI 10.1109/GIIS.2014.6934283, September 2014.
[GIIS14]Macedo，R.，Melo，R.，Santos，A.，和M.Nogueria，“VANETs中单路径和多路径路由的实验性能比较”，载于全球信息基础设施和网络研讨会（GIIS），第1卷，第6号，第15-19页，DOI 10.1109/GIIS.2014.6934283，2014年9月。
[IPv6-SRH] Previdi, S., Ed., Filsfils, C., Raza, K., Leddy, J., Field, B., Voyer, D., Bernier, S., Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-07, July 2017.
[IPv6 SRH]Previdi，S.，Ed.，Filsfils，C.，Raza，K.，Leddy，J.，Field，B.，Voyer，D.，Bernier，S.，Matsushima，S.，Leung，I.，Linkova，J.，Aries，E.，Kosugi，T.，Vyncke，E.，Lebrun，D.，Steinberg，D.，和R.Raszuk，“IPv6段路由头（SRH）”，正在进行中，草案-ietf-6man-Segment-Routing-Header-07，2017年7月。
[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, <https://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月<https://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, <https://www.rfc-editor.org/info/rfc2501>.
[RFC2501]Corson，S.和J.Macker，“移动自组网（MANET）：路由协议性能问题和评估考虑”，RFC 2501，DOI 10.17487/RFC2501，1999年1月<https://www.rfc-editor.org/info/rfc2501>.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <https://www.rfc-editor.org/info/rfc2991>.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 2991，DOI 10.17487/RFC2991，2000年11月<https://www.rfc-editor.org/info/rfc2991>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，DOI 10.17487/RFC5095，2007年12月<https://www.rfc-editor.org/info/rfc5095>.
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7722, DOI 10.17487/RFC7722, December 2015, <https://www.rfc-editor.org/info/rfc7722>.
[RFC7722]Dearlove，C.和T.Clausen，“优化链路状态路由协议版本2（OLSRv2）的多拓扑扩展”，RFC 7722，DOI 10.17487/RFC7722，2015年12月<https://www.rfc-editor.org/info/rfc7722>.
[RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)", RFC 7779, DOI 10.17487/RFC7779, April 2016, <https://www.rfc-editor.org/info/rfc7779>.
[RFC7779]Rogge，H.和E.Baccelli，“基于优化链路状态路由版本2（OLSRv2）的分组序列号的定向广播时间度量”，RFC 7779，DOI 10.17487/RFC7779，2016年4月<https://www.rfc-editor.org/info/rfc7779>.
[RFC8116] Clausen, T., Herberg, U., and J. Yi, "Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 8116, DOI 10.17487/RFC8116, May 2017, <https://www.rfc-editor.org/info/rfc8116>.
[RFC8116]Clausen，T.，Herberg，U.，和J.Yi，“优化链路状态路由协议版本2（OLSRv2）的安全威胁”，RFC 8116，DOI 10.17487/RFC8116，2017年5月<https://www.rfc-editor.org/info/rfc8116>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[WCNC08] Yi, J., Cizeron, E., Hamma, S., and B. Parrein, "Simulation and Performance Analysis of MP-OLSR for Mobile Ad hoc Networks", In Proceedings of the IEEE Wireless Communications and Networking Conference (WCNC), DOI 10.1109/WCNC.2008.395, 2008.
[WCNC08]Yi，J.，Cizeron，E.，Hamma，S.，和B.Parrein，“移动自组织网络MP-OLSR的模拟和性能分析”，载于IEEE无线通信和网络会议记录，DOI 10.1109/WCNC.2008.3952008。
[WPMC11] Yi, J., Parrein, B., and D. Radu, "Multipath Routing Protocol for MANET: Application to H.264/SVC Video Content Delivery", Proceedings of the 14th International Symposium on Wireless Personal Multimedia Communications, 2011.
[WPMC11]Yi，J.，Parrein，B.，和D.Radu，“MANET的多路径路由协议：应用于H.264/SVC视频内容交付”，第14届无线个人多媒体通信国际研讨会论文集，2011年。
This appendix gives two examples of the Multipath Dijkstra Algorithm.
本附录给出了多径Dijkstra算法的两个示例。
A network topology is depicted in Figure 2.
网络拓扑如图2所示。
.-----A-----(2)
(1) / \ \
/ / \ \
S (2) (1) D
\ / \ /
(1) / \ / (2)
B----(3)----C
.-----A-----(2)
(1) / \ \
/ / \ \
S (2) (1) D
\ / \ /
(1) / \ / (2)
B----(3)----C
Figure 2
图2
The capital letters are the names of routers. An arbitrary metric with value between 1 and 3 is used. The initial metrics of all the links are indicated in the parentheses. The incremental functions fp(c)=4c and fe(c)=2c are used in this example. Two paths from router S to router D are demanded.
大写字母是路由器的名称。使用值介于1和3之间的任意度量。括号中显示了所有链接的初始度量。本例中使用了增量函数fp（c）=4c和fe（c）=2c。需要从路由器S到路由器D的两条路径。
On the first run of the Dijkstra Algorithm, the shortest path S->A->D with metric 3 is obtained.
在Dijkstra算法的第一次运行中，得到了度量为3的最短路径S->A->D。
The incremental function fp is applied to increase the metric of the link S-A and A-D, and fe is applied to increase the metric of the link A-B and A-C. Figure 3 shows the link metrics after the increment.
增量函数fp用于增加链路S-A和A-D的度量，fe用于增加链路A-B和A-C的度量。图3显示了增量后的链路度量。
.-----A-----(8)
(4) / \ \
/ / \ \
S (4) (2) D
\ / \ /
(1) / \ / (2)
B----(3)----C
.-----A-----(8)
(4) / \ \
/ / \ \
S (4) (2) D
\ / \ /
(1) / \ / (2)
B----(3)----C
Figure 3
图3
On the second run of the Dijkstra Algorithm, the second path S->B->C->D with metric 6 is obtained.
在Dijkstra算法的第二次运行中，第二条路径S->B->C->D的度量为6。
As mentioned in Section 8.5, the Multipath Dijkstra Algorithm does not guarantee strict disjoint paths in order to avoid choosing inferior paths. For example, given the topology in Figure 4, two paths from node S to D are desired. On the top of the figure, there is a high cost path between S and D.
如第8.5节所述，多径Dijkstra算法不保证严格的不相交路径，以避免选择劣质路径。例如，给定图4中的拓扑，需要从节点S到D的两条路径。在图的顶部，S和D之间有一条高成本路径。
If an algorithm tries to obtain strict disjoint paths, the two paths obtained will be S--B--D and S--(high cost path)--D, which are extremely unbalanced. It is undesirable because it will cause huge delay variance between the paths. By using the Multipath Dijkstra Algorithm, which is based on the punishing scheme, S--B--D and S--B--C--D will be obtained.
如果一个算法试图获得严格不相交的路径，那么得到的两条路径将是S--B--D和S--（高代价路径）--D，这两条路径极不平衡。这是不可取的，因为它将导致路径之间的巨大延迟差异。通过使用基于惩罚方案的多径Dijkstra算法，可以得到S--B--D和S--B--C--D。
--high cost path-
/ \
/ \
S----B--------------D
\ /
\---C-----/
--high cost path-
/ \
/ \
S----B--------------D
\ /
\---C-----/
Figure 4
图4
Acknowledgments
致谢
The authors would like to thank Sylvain David, Asmaa Adnane, Eddy Cizeron, Salima Hamma, Pascal Lesage, and Xavier Lecourtier for their efforts in developing, implementing, and testing the specification. The authors also appreciate valuable discussions with Thomas Clausen, Ulrich Herberg, Justin Dean, Geoff Ladwig, Henning Rogge, Marcus Barkowsky, and especially Christopher Dearlove for his multiple rounds of reviews during the working group last calls.
作者要感谢Sylvain David、Asmaa Adnane、Eddy Cizeron、Salima Hamma、Pascal Lesage和Xavier Lecourtier在开发、实施和测试规范方面所做的努力。作者还感谢与托马斯·克劳森、乌尔里希·赫伯格、贾斯汀·迪安、杰夫·拉德维格、亨宁·罗格、马库斯·巴考斯基，特别是克里斯托弗·迪尔洛夫进行的宝贵讨论，感谢他在工作组最后一次电话会议期间进行了多轮审查。
Authors' Addresses
作者地址
Jiazi Yi Ecole Polytechnique 91128 Palaiseau Cedex France
家子伊理工学院91128法国塞德克斯宫
Phone: +33 (0) 1 77 57 80 85
Email: jiazi@jiaziyi.com
URI: http://www.jiaziyi.com/
Phone: +33 (0) 1 77 57 80 85
Email: jiazi@jiaziyi.com
URI: http://www.jiaziyi.com/
Benoit Parrein University of Nantes IRCCyN Lab - IVC team Polytech Nantes, rue Christian Pauc, BP50609 44306 Nantes cedex 3 France
班诺特PARRIN大学南特IrCyn实验室-IVC团队PultTeaCo南特，RouthChina PaUC，BP50609 44306南特CEDEX 3法国
Phone: +33 (0) 2 40 68 30 50
Email: Benoit.Parrein@polytech.univ-nantes.fr
URI: http://www.irccyn.ec-nantes.fr/~parrein
Phone: +33 (0) 2 40 68 30 50
Email: Benoit.Parrein@polytech.univ-nantes.fr
URI: http://www.irccyn.ec-nantes.fr/~parrein