[要約] RFC 8218は、OLSRv2におけるマルチパス拡張の要約と目的を提供します。この拡張は、ネットワークの冗長性とパフォーマンスを向上させるために設計されています。
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.
このドキュメントでは、モバイルアドホックネットワーク（MANET）の複数のばらばらのパスを検出するために、最適化リンクステートルーティングプロトコルバージョン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.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]の拡張を指定しています。 MANET [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）は、デフォルトでマルチパスダイクストラアルゴリズムを使用して、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 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.
oこの拡張機能のアプリケーションは、パケット全体に適用される前方誤り訂正（FEC）コーディング（消失符号化）[WPMC11]と組み合わせて使用されます。パケットドロップは通常、パスでバースト性があるため（たとえば、ルートの障害が原因）、イレージャーコーディングはシングルパスルーティングプロトコルでは効果が低くなります。複数のばらばらのパスを提供することにより、マルチパスプロトコルを使用した消失符号化のアプリケーションは、ルーティング障害に対してより回復力があります。
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のマルチパス拡張機能は、十分な運用経験が得られた時点で改訂され、Standards Track 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 使用する複数のパスの数（NUMBER_OF_PATHS、セクション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 さまざまな指標タイプの使用。このマルチパス拡張は、[RFC7779]など、OLSRv2の要件を満たすメトリックタイプで使用できます。使用されるメトリックタイプは、前の箇条書きで示したように、メトリック関数の選択にも影響を与えます。
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で導入されたデフォルトのマルチパスダイクストラアルゴリズム以外の、複数のパスを取得するためのさまざまなアルゴリズム。
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 @ ietf.orgの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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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が適用されるMANETに適用されます（[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 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.
MP-OLSRv2は、プロアクティブとリアクティブの2つの異なるが相互運用可能なマルチパス計算アプローチをサポートしています。プロアクティブな計算では、すべての宛先へのパスが必要になる前に計算されます。リアクティブ計算では、必要な宛先へのパスのみがオンデマンドで計算されます。プロアクティブなアプローチには、リアクティブなものよりも多くの計算リソースが必要です。リアクティブアプローチでは、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では、MP-OLSRv2で定義されたパススケジューラに基づいて、IP転送プレーンがソースルーティングヘッダーに入れるソースルートを選択できる必要があります。 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。リアクティブ操作はルーターに対してローカルであり、ルーティング制御メッセージをさらに交換する必要はありません。パスが計算されているとき、ルーターに十分なメモリがない場合を除いて、データグラムはバッファリングされるべきです（SHOULD）。
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.
同じネットワーク内のルーターは、その計算リソースに応じて、プロアクティブまたはリアクティブのマルチパス計算を個別に選択できます。送信元から宛先への複数のばらばらのパスを生成するデフォルトのアルゴリズムとして、マルチパスダイクストラアルゴリズム（セクション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.
NUMBER_OF_PATHS：ルーターが必要とするパスの数。
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ネットワークでは、[RFC6554]は厳密なソースルーティングのみをサポートするため、0に設定する必要があります。すべての中間ルーターは、さまざまなホップ数のソースルーティングヘッダーに含める必要があります。 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.
CUTOFF_RATIO：OLSRv2ルーティングセットに保持されている最短パスと比較した、パスの最大メトリックを定義する比率。たとえば、宛先へのメトリックは、ルーティングセットに基づくR_metricです。その場合、パスに許可される最大メトリックはCUTOFF_RATIO * R_metricです。 CUTOFF_RATIOは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ルーティングプロセスによる2つの連続した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：SR_TC_INTERVALに基づいて生成されたTCメッセージに含まれるType = VALIDITY_TIMEのTLVの最小値。
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]で定義されているものと同じ形式を使用します。さらに、ソースルート転送をサポートするHELLOまたはTCメッセージの発信者を識別するために、新しいメッセージTLVタイプが定義されています。 OLSRv2の拡張としてMP-OLSRv2を有効にするための新しいメッセージTLVタイプが導入されました。ソースルーティングヘッダーを理解しないルーターを追加すると、データグラムのソースルーティングヘッダーで使用できるのは、ソースルート転送をサポートするルーターのみです。ルーティングが失敗します。
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.
SOURCE_ROUTE 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メッセージは、値のない正確に1つのSOURCE_ROUTE 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メッセージにSOURCE_ROUTE TLVが1つだけ必要です。 SOURCE_ROUTE TLVの存在は、特定のOLSRv2ルーティングプロセスで一貫している必要があります。つまり、SOURCE_ROUTE TLVをすべてのHELLO / TCメッセージに追加するか、またはSOURCE_ROUTE 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)
（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_metric、PT_address [1]、PT_address [2]、...、PT_address [n]）
where:
ただし：
PT_metric is the metric of the path to the destination, measured in LINK_METRIC_TYPE defined in [RFC7181].
PT_metricは、[RFC7181]で定義されているLINK_METRIC_TYPEで測定された、宛先へのパスのメトリックです。
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に従って生成され、さらにType：= SOURCE_ROUTEが含まれる単一のメッセージ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に従って生成され、さらにType：= SOURCE_ROUTEを含む単一のメッセージ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_INTERVAL（セクション5）中にMP-OLSRv2ルーティングプロセスによって少なくとも1つのTCメッセージを生成する必要があり、TC_INTERVAL以上でなければなりません（MUST）。これらのTCメッセージは、アドバタイズされたネイバーアドレスを伝送してはなりません（MUST NOT）。これは、これらのルーターがSOURCE_ROUTE TLVをアドバタイズして、マルチパスルーティングの宛先として使用されるようにソースルートが有効になっているルーターを認識できるようにするために役立ちます。このようなTCメッセージのVALIDITY_TIME TLVに関連付けられている有効期間は、SR_HOLD_TIMEと等しく、SR_TC_INTERVALより大きくなければなりません。 TCメッセージにオプションのINTERVAL_TIME TLVが含まれている場合は、SR_TC_INTERVALをエンコードする値が必要です。
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メッセージを受信時に破棄する理由に加えて、Type = SOURCE_ROUTEのメッセージTLVが複数ある場合は、HELLOまたはTCメッセージを破棄する必要があります。
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メッセージについて、Type：= 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_time：= current_time + [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ルーティングプロセスを実行するルーティングMPRの数は、十分なMP-OLSRv2対称ネイバーがある場合、NUMBER_OF_PATHS以上である必要があります。それ以外の場合は、意欲がWILL_NEVERのルーターを除き、すべての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_address [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サイズが異なる場合、Path MTU Discoveryなどのテクノロジーを使用することにより、ルーターはパスに沿った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ルーティングドメインと残りのインターネット間のゲートウェイにソースルーティングされる必要があります。ゲートウェイは、データグラムを残りのインターネットに転送する前に、ソースルーティングヘッダーを削除する必要があります。
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_metricと比較されます。メトリックc_iがR_metric * CUTOFF_RATIO（セクション5）より大きい場合、対応するパスiは使用すべきではありません（SHOULD NOT）。 R_metric * CUTOFF_RATIO未満のメトリックを持つ2つ未満のパスが見つかった場合、ルーターはマルチパスルーティングを使用せずにOLSRv2ルーティングプロセスにフォールバックする必要があります（SHOULD）。これは、ネットワーク内の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:
マルチパスアルゴリズムを呼び出すことにより、以下を使用してマルチパスルーティングタプルを作成することにより、最大NUMBER_OF_PATHS個のパスが取得され、マルチパスルーティングセットに追加されます。
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_path_set。各パスタプルは、マルチパスダイクストラアルゴリズムで取得されたパスに対応し、PT_metric：=計算されたパスのメトリックとPT_address [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.
このセクションでは、デフォルトのアルゴリズムとしてマルチパスダイクストラアルゴリズムを紹介します。必要に応じてばらばらのパスを取得しようとしますが、厳密なばらばらのパスは保証されません。セクション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: 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.
マルチパスダイクストラアルゴリズム[ADHOC11]の一般的な原理は、複数の反復にダイクストラアルゴリズムを使用し、反復iで宛先dへの最短経路P [i]を探すことです。各反復の後、使用されたリンクのメトリックは増加します。元のダイクストラのアルゴリズムと比較して、主要な変更は、次のステップが同様のパスをもたらすことを防ぐために、メトリック関数fpおよびfeという名前の2つの増分関数を追加することです：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は以前のメトリックの値です。 「につながる」とは、円弧の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の簡単な例を考えてみます。パスP [i] S--A--Dは、ステップiで取得されます。次のステップでは、リンクS--AおよびA--Dのメトリックは、パスP [i]に属しているため、fp（c）を使用して増加します。 A--Bはfe（c）を使用して増加されます。これは、AがパスP [i]の中間頂点であり、BがP [i]の一部ではないためです。 B--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を選択して、必要に応じてリンク分離パスまたはノード分離パスを取得することができます。 fpおよびfeの構成に関する推奨事項は、セクション9に記載されています。
To get NUMBER_OF_PATHS different paths, for each path P[i] (i = 1, ..., NUMBER_OF_PATHS):
パスP [i]（i = 1、...、NUMBER_OF_PATHS）ごとにNUMBER_OF_PATHS個の異なるパスを取得するには：
1. Run Dijkstra's algorithm to get the shortest path P[i] for the destination d.
1. ダイクストラのアルゴリズムを実行して、宛先dの最短経路P [i]を取得します。
2. Apply metric function fp to the metric of links (in both directions) in P[i].
2. P [i]のリンクのメトリック（両方向）にメトリック関数fpを適用します。
3. Apply metric function fe to the metric of links (in both directions) that lead to routers used in P[i].
3. P [i]で使用されるルーターにつながるリンクのメトリック（両方向）にメトリック関数feを適用します。
A simple example of the Multipath Dijkstra Algorithm is illustrated in Appendix A.
マルチパスダイクストラアルゴリズムの簡単な例を付録Aに示します。
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で指定されている厳密なソースルーティングを使用して転送されます。ただし、適用されるルーターはRPLルーターではなくMP-OLSRv2ルーターです。ソースルートの最後のホップは、ソースルーティングヘッダーを削除する必要があります。
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 NUMBER_OF_PATHS：= 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 MAX_SRC_HOPS：= 10、IPv4ネットワークの場合。 IPv6ネットワークの場合、0に設定する必要があります。つまり、最大ホップ数に制約はありません。
o CUTOFF_RATIO := 1.5. It MUST be greater than or equal to 1.
o CUTOFF_RATIO：= 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_TC_INTERVAL：= 10 x TC_INTERVAL。 TC_INTERVAL以上でなければなりません。 TC_INTERVALよりも大幅に大きくして、不要なTCメッセージの生成を減らす必要があります（SHOULD）。
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_HOLD_TIME：= 3 x SR_TC_INTERVAL。これはSR_TC_INTERVALより大きくなければならず（MUST）、少数の失われたメッセージを許容する必要があります（SHOULD）。
If the Multipath Dijkstra Algorithm is applied:
マルチパスダイクストラアルゴリズムが適用される場合：
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の場合、3つのケースが考えられます。
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メッセージにSOURCE_ROUTE 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]のセクション5と[RFC5095 ]。ソースルーティングヘッダーは現在のルーティングドメインでのみ使用されるため、影響は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.
複数のパスが事後的に計算される場合、パスが計算されている間、データグラムはバッファリングされるべきです（SHOULD）。パス計算はローカルであり、制御メッセージは交換されないため、バッファリング時間は取るに足らないものでなければなりません。ただし、ルータのCPUパワーとメモリに応じて、最大バッファサイズを設定して、ルータのメモリを使いすぎないようにする必要があります。バッファがいっぱいになると、最も古いデータグラムが削除されます。悪意のあるアプリケーションが起動する可能性のある攻撃は、ネットワーク内の他のすべてのルーターに対して大量のデータグラムを開始し、他のすべてのルーターへのパス計算をトリガーし、その間にデータグラムがバッファリングされる攻撃です。これにより、他の正当なデータグラムがフラッシュされる可能性があります。ただし、攻撃の影響は一時的なものです。パスの計算が完了すると、データグラムが転送され、バッファは空に戻ります。
This section adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV.
このセクションでは、新しいタイプ拡張として割り当てられた1つの新しいメッセージ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.
この仕様は、表1に示すように、新しいタイプ拡張SOURCE_ROUTEを追加することにより、「タイプ7メッセージTLVタイプ拡張」レジストリ[RFC7181]を更新します。
+-----------+--------------+------------------------+---------------+
| 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タイプ拡張のSOURCE_ROUTEタイプ
[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 / RFC0791、1981年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、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、DOI 10.17487 / RFC5444、2009年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、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（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.、and V. Manral、 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Routing-Power and Lossy Networks（RPL）"、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、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、DOI 10.17487 / RFC7181、2014年4月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、「Integrity Protection for the Neighborhood Discovery Protocol（NHDP）and Optimized Link State Routing Protocol Version 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、「VANETでのシングルパスおよびマルチパスルーティングの実験的パフォーマンス比較」、グローバル情報インフラストラクチャおよびネットワークシンポジウム（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.、and R. Raszuk、 "IPv6 Segment Routing Header（SRH）"、Work in進捗状況、draft-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ヘッダーのDiffServフィールド（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、「Deprecation of Type 0 Routing Headers in IPv6」、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ワイヤレス通信およびネットワーク会議の議事録（ WCNC）、DOI 10.1109 / WCNC.2008.395、2008。
[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.
この付録では、マルチパスダイクストラアルゴリズムの2つの例を示します。
A network topology is depicted in Figure 2.
ネットワークトポロジを図2に示します。
.-----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への2つのパスが要求されます。
On the first run of the Dijkstra Algorithm, the shortest path S->A->D with metric 3 is obtained.
ダイクストラアルゴリズムの最初の実行時に、メトリック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
Figure 3
図3
On the second run of the Dijkstra Algorithm, the second path S->B->C->D with metric 6 is obtained.
ダイクストラアルゴリズムの2回目の実行では、メトリック6の2番目のパスS-> B-> C-> Dが取得されます。
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で述べたように、マルチパスダイクストラアルゴリズムは、下位パスの選択を回避するために、厳密なばらばらのパスを保証しません。たとえば、図4のトポロジでは、ノードSからDへの2つのパスが必要です。図の上部には、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.
アルゴリズムが厳密なばらばらのパスを取得しようとすると、取得される2つのパスはS--B--DとS-（高コストパス）-Dとなり、非常に不均衡になります。パス間で大きな遅延変動が発生するため、これは望ましくありません。罰則スキームに基づくマルチパスダイクストラアルゴリズムを使用することにより、S--B--DおよびS--B--C--Dが取得されます。
--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に感謝します。著者らはまた、ワーキンググループの最後の電話での彼の複数回のレビューについて、Thomas Clausen、Ulrich Herberg、Justin Dean、Geoff Ladwig、Henning Rogge、Marcus Barkowsky、特にChristopher Dearloveとの貴重な議論に感謝しています。
Authors' Addresses
著者のアドレス
Jiazi Yi Ecole Polytechnique 91128 Palaiseau Cedex France
Jiazi Yi Ecole Polytechnique 91128パレゾーセデックスフランス
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
ブノワパレインナント大学IRCCyNラボ-IVCチームポリテックナント、rue Christian Pauc、BP50609 44306ナントセデックス3フランス
Phone: +33 (0) 2 40 68 30 50
Email: Benoit.Parrein@polytech.univ-nantes.fr
URI: http://www.irccyn.ec-nantes.fr/~parrein