[要約] RFC 7722は、OLSRv2におけるマルチトポロジー拡張の要約と目的を提供します。この拡張は、異なるトポロジーをサポートするためにOLSRv2プロトコルを拡張することを目的としています。
Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7722 BAE Systems
Updates: 7188, 7631 T. Clausen
Category: Experimental LIX, Ecole Polytechnique
ISSN: 2070-1721 December 2015
Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
最適化リンクステートルーティングプロトコルバージョン2（OLSRv2）のマルチトポロジ拡張
Abstract
概要
This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
この仕様は、この拡張を実装しないOLSRv2ルーターとの相互運用性を維持しながら、複数のルーティングトポロジをサポートするためのOptimized Link State Routing Protocolバージョン2（OLSRv2）の拡張について説明しています。
This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.
この仕様は、TLVレジストリと説明を変更および拡張することにより、RFC 7188および7631を更新します。
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 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7722.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7722で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 Experimentation .............................4
2. Terminology and Notation ........................................5
3. Applicability Statement .........................................6
4. Protocol Overview and Functioning ...............................6
5. Parameters ......................................................8
6. Information Bases ...............................................9
6.1. Local Attached Network Set .................................9
6.2. Link Sets ..................................................9
6.3. 2-Hop Sets .................................................9
6.4. Neighbor Set ...............................................9
6.5. Router Topology Set .......................................10
6.6. Routable Address Topology Set .............................10
6.7. Attached Network Set ......................................10
6.8. Routing Sets ..............................................11
7. TLVs ...........................................................11
7.1. Message TLVs ..............................................11
7.1.1. MPR_TYPES TLV ......................................11
7.1.2. MPR_WILLING TLV ....................................11
7.2. Address Block TLVs ........................................12
7.2.1. LINK_METRIC TLV ....................................12
7.2.2. MPR TLV ............................................13
7.2.3. GATEWAY TLV ........................................13
8. HELLO Messages .................................................14
8.1. HELLO Message Generation ..................................14
8.2. HELLO Message Processing ..................................15
9. TC Messages ....................................................15
9.1. TC Message Generation .....................................15
9.2. TC Message Processing .....................................16
10. MPR Calculation ...............................................16
11. Routing Set Calculation .......................................17
12. Management Considerations .....................................17
13. IANA Considerations ...........................................18
13.1. Expert Review: Evaluation Guidelines .....................18
13.2. Message TLV Types ........................................18
13.3. Address Block TLV Types ..................................20
14. Security Considerations .......................................21
15. References ....................................................22
15.1. Normative References .....................................22
15.2. Informative References ...................................22
Acknowledgments ...................................................23
Authors' Addresses ................................................23
The Optimized Link State Routing Protocol version 2 [RFC7181] (OLSRv2) is a proactive link state routing protocol designed for use in Mobile Ad Hoc Networks (MANETs) [RFC2501]. One of the significant improvements of OLSRv2 over its Experimental precursor [RFC3626] is the ability of OLSRv2 to use link metrics to select routes other than minimum hop routes.
最適化リンクステートルーティングプロトコルバージョン2 [RFC7181]（OLSRv2）は、モバイルアドホックネットワーク（MANET）[RFC2501]で使用するために設計されたプロアクティブリンクステートルーティングプロトコルです。 OLSRv2の実験的前駆体[RFC3626]に対するOLSRv2の重要な改善点の1つは、OLSRv2がリンクメトリックを使用して最小ホップルート以外のルートを選択できることです。
A limitation that remains in OLSRv2 is that it uses a single link metric type for all routes. However, in some MANETs it would be desirable to be able to route packets using more than one link metric type. This specification describes an extension to OLSRv2 that is designed to permit this, while maintaining maximal interoperability with OLSRv2 routers not implementing this extension.
OLSRv2に残っている制限は、すべてのルートに単一のリンクメトリックタイプを使用することです。ただし、一部のMANETでは、複数のリンクメトリックタイプを使用してパケットをルーティングできることが望ましい場合があります。この仕様では、これを許可するように設計されたOLSRv2の拡張について説明しますが、この拡張を実装していないOLSRv2ルーターとの相互運用性を最大限に維持します。
The purpose of OLSRv2 can be described as to create and maintain a Routing Set, which contains all the necessary information to populate an IP routing table. In a similar way, the role of this extension can be described as to create and maintain multiple Routing Sets, one for each link metric type supported by the router maintaining the sets.
OLSRv2の目的は、ルーティングセットを作成および維持することであり、ルーティングセットには、IPルーティングテーブルに入力するために必要なすべての情報が含まれています。同様に、この拡張機能の役割は、複数のルーティングセットを作成および維持することで説明できます。1つは、セットを維持するルーターがサポートするリンクメトリックタイプごとに1つです。
Multi-topology routing is a natural extension to a link state routing protocol, such as OSPF (see [RFC4915]). However multi-topology routing for OLSRv2 does not yet benefit from extensive operational, or even experimental, experience. This specification is published to facilitate collecting such experience, with the intent that once suitable experimental evidence has been collected, an OLSRv2 Multi-Topology Routing Extension will be proposed for advancement onto the Standards Track.
マルチトポロジルーティングは、OSPFなどのリンクステートルーティングプロトコルへの自然な拡張です（[RFC4915]を参照）。ただし、OLSRv2のマルチトポロジルーティングは、広範な運用経験や実験的経験からはまだメリットを得ていません。この仕様は、このような経験の収集を容易にするために公開されており、適切な実験的証拠が収集されたら、OLSRv2マルチトポロジルーティング拡張機能を標準トラックへの進化のために提案します。
Any experiments using this protocol extension are encouraged. Reports from such experiments planned with pre-specified objectives and scenarios (including link, position, and mobility information) are particularly encouraged. Results from such experiments, documenting the following, are of particular importance:
このプロトコル拡張を使用した実験は推奨されます。事前に指定された目的とシナリオ（リンク、位置、および移動情報を含む）で計画されたそのような実験からのレポートは、特に推奨されます。そのような実験の結果は、次のように文書化されており、特に重要です。
o Operation in networks that contain both routers implementing this extension and routers implementing only [RFC7181]. In particular, are there any unexpected interactions that can break the network?
o この拡張機能を実装するルーターと[RFC7181]のみを実装するルーターの両方を含むネットワークでの操作。特に、ネットワークを破壊する可能性のある予期しない相互作用はありますか？
o Operation in networks with dynamic topologies, both due to mobility and due to link metric changes for reasons other than mobility.
o モビリティと、モビリティ以外の理由によるリンクメトリックの変更による、動的トポロジのあるネットワークでの動作。
o Operation in realistic deployments, and details thereof, including how many concurrent topologies were required.
o 必要な同時トポロジの数など、現実的な展開での操作とその詳細。
o Behavior of Routing Sets, including measures of successful route establishment.
o 正常なルート確立の測定を含むルーティングセットの動作。
In addition, reports from experiments covering the following are also of value:
さらに、以下をカバーする実験からのレポートも価値があります。
o Which link metric types were useful, and how the metrics to associate with a given link were established.
o どのリンクメトリックタイプが有用であり、特定のリンクに関連付けるメトリックがどのように確立されたか。
o How packet types were associated with link metric types (whether using Diffserv or an alternative mechanism).
o パケットタイプがリンクメトリックタイプにどのように関連付けられたか（Diffservまたは代替メカニズムを使用しているかどうか）。
o Any data link-layer issues, and any cross-layer issues, including whether and how Neighborhood Discovery Protocol (NHDP) link quality was used.
o Neighborhood Discovery Protocol（NHDP）リンク品質が使用されたかどうか、およびその使用方法を含む、データリンク層の問題、およびクロスレイヤーの問題。
o Transport- and higher-layer issues observed, if any.
o 観察されたトランスポート層および上位層の問題（存在する場合）。
o Resource requirements observed from running the protocol, including processing, storage, and bandwidth.
o プロトコルの実行から観察された、処理、ストレージ、帯域幅などのリソース要件。
o Network performance, including packet delivery results.
o パケット配信結果を含むネットワークパフォーマンス。
o Any other implementation issues.
o その他の実装の問題。
The first bullet in the list directly above applies to unextended OLSRv2 [RFC7181] as well as with this extension, and potentially to other MANET routing protocols. This specification also allows experimentation with link metric types that are not compromises for handling multiple traffic types.
すぐ上のリストの最初の箇条書きは、拡張されていないOLSRv2 [RFC7181]とこの拡張に適用され、場合によっては他のMANETルーティングプロトコルにも適用されます。この仕様では、複数のトラフィックタイプを処理するための妥協のないリンクメトリックタイプを試すこともできます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This specification uses the terminology of [RFC5444], [RFC6130], and [RFC7181], which is to be interpreted as described in those specifications.
この仕様では、[RFC5444]、[RFC6130]、および[RFC7181]の用語を使用します。これらは、これらの仕様で説明されているように解釈されます。
Additionally, this specification uses the following terminology:
さらに、この仕様では次の用語を使用しています。
Router - A MANET router that implements [RFC7181].
ルーター-[RFC7181]を実装するMANETルーター。
MT-OLSRv2 - The protocol defined in this specification as an extension to OLSRv2 [RFC7181].
MT-OLSRv2-この仕様でOLSRv2 [RFC7181]の拡張として定義されたプロトコル。
This specification introduces the notation map[A -> B] to represent an associative mapping. The domain of this mapping (A) is, in this specification, always a set of link metric types that the router supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as defined in Section 5. The codomain of this mapping (B) is a set of all possible values of an appropriate type. In this specification, this type is always one of:
この仕様では、連想マッピングを表すmap [A-> B]という表記を導入しています。このマッピングのドメイン（A）は、この仕様では常に、セクション5で定義されているように、ルーターがサポートするリンクメトリックタイプのセット（IFACE_METRIC_TYPESまたはROUTER_METRIC_TYPES）です。このマッピングのコドメイン（B）は、すべてのセットです。適切なタイプの可能な値。この仕様では、このタイプは常に次のいずれかです。
o boolean (true or false),
o ブール値（trueまたはfalse）、
o willingness (a 4-bit unsigned integer from 0 to 15),
o 意欲（0〜15の4ビット符号なし整数）、
o number of hops (an 8-bit unsigned integer from 0 to 255), or
o ホップ数（0〜255の8ビット符号なし整数）、または
o link metric (either a representable link metric value, as described in [RFC7181], or UNKNOWN_METRIC).
o リンクメトリック（[RFC7181]で説明されている表現可能なリンクメトリック値、またはUNKNOWN_METRIC）。
The protocol described in this specification is applicable to a MANET for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), but in which multiple topologies are maintained, each characterized by a different choice of link metric type. It is assumed, but outside the scope of this specification, that the network layer is able to choose which topology to use for each packet, for example, using the Diffserv Code Point (DSCP) defined in [RFC2474]. This selection of topology MUST be consistent; that is, each router receiving a packet must make the same choice of link metric type, in order that each packet uses a single topology. This is necessary to avoid the possibility of a packet "looping" in the network.
この仕様で説明されているプロトコルは、OLSRv2が適用されるMANET（[RFC7181]、セクション3を参照）に適用できますが、複数のトポロジが維持され、それぞれが異なるリンクメトリックタイプの選択によって特徴付けられます。 [RFC2474]で定義されているDiffservコードポイント（DSCP）を使用するなど、ネットワークレイヤーが各パケットに使用するトポロジを選択できることが想定されていますが、この仕様の範囲外です。このトポロジの選択は一貫している必要があります。つまり、各パケットが単一のトポロジを使用するためには、パケットを受信する各ルーターは、リンクメトリックタイプを同じように選択する必要があります。これは、ネットワークでパケットが「ループ」する可能性を回避するために必要です。
The purpose of this specification is to extend OLSRv2 [RFC7181] so as to enable a router to establish and maintain multiple routing topologies in a MANET, each topology associated with a link metric type. Routers in the MANET may each form part of some or all of these topologies, and each router will maintain a Routing Set for each topology that it forms part of, allowing separate routing of packets for each topology.
この仕様の目的は、OLSRv2 [RFC7181]を拡張して、ルーターがMANET内の複数のルーティングトポロジを確立および維持できるようにすることです。各トポロジは、リンクメトリックタイプに関連付けられています。 MANET内のルーターはそれぞれ、これらのトポロジの一部またはすべての一部を形成する可能性があり、各ルーターは、それが形成する各トポロジのルーティングセットを維持し、各トポロジのパケットの個別ルーティングを可能にします。
MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 routers) and routers that do not implement MT-OLSRv2 and may be unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be created that are known to contain only MT-OLSRv2 routers. In both cases, but especially where a MANET contains both MT-OLSRv2 routers and non-MT-OLSRv2 routers, management may be required to ensure that the MANET will function as required, and will not, for example, unnecessarily fragment. (Such issues already arise in an OLSRv2-based MANET using multiple interfaces.)
MT-OLSRv2は、OLSRv2と相互運用するように設計されています。 MT-OLSRv2を実装するルーター（MT-OLSRv2ルーター）と、MT-OLSRv2を実装せず、その存在を認識していないルーター（非MT-OLSRv2ルーター）の両方を含むMANETを作成できます。 MT-OLSRv2ルーターのみを含むことがわかっているMANETも作成できます。どちらの場合でも、特にMANETにMT-OLSRv2ルーターとMT-OLSRv2以外のルーターの両方が含まれている場合、MANETが必要に応じて機能し、不必要に断片化しないなどの管理が必要になる場合があります。 （このような問題は、複数のインターフェイスを使用するOLSRv2ベースのMANETですでに発生しています。）
OLSRv2 is an extension of NHDP [RFC6130]. However, the extension in this specification does not modify NHDP, it only modifies Protocol Sets that are specific to OLSRv2, or elements in Protocol Tuples that were added by OLSRv2 and that are neither included in nor used by NHDP. In addition it does not use or modify the link quality mechanism in [RFC6130].
OLSRv2はNHDP [RFC6130]の拡張です。ただし、この仕様の拡張はNHDPを変更せず、OLSRv2に固有のプロトコルセット、またはOLSRv2によって追加され、NHDPに含まれていない、またはNHDPによって使用されていないプロトコルタプルの要素のみを変更します。さらに、[RFC6130]のリンク品質メカニズムを使用または変更しません。
Each router implementing this specification selects a set of link metric types for each of its OLSRv2 interfaces. If all routers in the MANET implement MT-OLSRv2, then there are no restrictions within this specification on how these sets of link metrics are selected. (However, the issues described in the preceding paragraph still apply.) On the other hand, in MANETs containing non-MT-OLSRv2 routers, the single link metric used by these non-MT-OLSRv2 routers must be included in the set of link metrics for each OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non-MT-OLSRv2 router in the MANET.
この仕様を実装する各ルーターは、各OLSRv2インターフェイスのリンクメトリックタイプのセットを選択します。 MANETのすべてのルーターがMT-OLSRv2を実装している場合、この仕様内では、これらのリンクメトリックのセットの選択方法に関する制限はありません。 （ただし、前の段落で説明した問題が引き続き適用されます。）一方、非MT-OLSRv2ルーターを含むMANETでは、これらの非MT-OLSRv2ルーターが使用する単一のリンクメトリックをリンクのセットに含める必要があります。 MANETの非MT-OLSRv2ルーターのOLSRv2インターフェイスで聞こえる可能性があるMT-OLSRv2ルーターの各OLSRv2インターフェイスのメトリック。
Each router then determines an incoming link metric for each link metric type selected for each of its OLSRv2 interfaces. These link metrics are distributed using link metric TLVs contained in all HELLO messages sent on OLSRv2 interfaces and in all TC messages. Unless using only the single metric type used by non-MT-OLSRv2 routers, both HELLO and TC messages generated by an MT-OLSRv2 router include an MPR_TYPES Message TLV that indicates that this is an MT-OLSRv2 router and which metric types it supports (on the sending OLSRv2 interface for a HELLO message).
次に、各ルーターは、各OLSRv2インターフェイスに対して選択された各リンクメトリックタイプの着信リンクメトリックを決定します。これらのリンクメトリックは、OLSRv2インターフェイスで送信されるすべてのHELLOメッセージとすべてのTCメッセージに含まれるリンクメトリックTLVを使用して配布されます。非MT-OLSRv2ルーターが使用する単一のメトリックタイプのみを使用しない限り、MT-OLSRv2ルーターが生成するHELLOメッセージとTCメッセージの両方に、これがMT-OLSRv2ルーターであることと、サポートするメトリックタイプを示すMPR_TYPESメッセージTLVが含まれます（ HELLOメッセージの送信OLSRv2インターフェイス上）。
An MT-OLSRv2 router maintains, for each supported neighbour metric type and for each symmetric 1-hop neighbor, the following:
MT-OLSRv2ルータは、サポートされるネイバーメトリックタイプごと、および対称1ホップネイバーごとに、次のものを維持します。
o link and neighbour metric values,
o リンクとネイバーのメトリック値、
o routing MPR status,
o MPRステータスのルーティング
o routing MPR selector status, and
o MPRセレクタステータスのルーティング、および
o advertised neighbour status.
o アドバタイズされたネイバーステータス。
Each router may choose a different willingness to be a routing MPR for each link metric type that it supports.
各ルーターは、サポートする各リンクメトリックタイプのルーティングMPRとして異なる意欲を選択できます。
A network using MT-OLSRv2 will usually require greater management than one using unmodified OLSRv2. In particular, the use of multiple metric types across the MANET must be managed, by administrative configuration or otherwise. As also for other decisions that may be made when using OLSRv2, a bad collective choice of metric type use will make the MANET anywhere from inefficient to nonfunctional, so care will be needed in selecting supported link metric types across the MANET.
MT-OLSRv2を使用するネットワークは、通常、変更されていないOLSRv2を使用するネットワークよりも大きな管理が必要になります。特に、MANET全体での複数のメトリックタイプの使用は、管理構成などによって管理する必要があります。 OLSRv2の使用時に行われる可能性のある他の決定についても、メトリックタイプの使用を集合的に選択しないと、MANETが非効率から機能しなくなるため、MANET全体でサポートされるリンクメトリックタイプを選択する際に注意が必要になります。
The meanings of link metric types are at the discretion of the MANET operator. They could be used, for example, to represent packets of different types, packets in streams of different rates, or packets with different trust requirements. Note that packets will generally not be delivered to routers that do not support that link metric type, and the MANET, and the packets sent in it, will need to be managed accordingly (especially if the MANET contains any non-MT-OLSRv2 routers).
リンクメトリックタイプの意味は、MANETオペレーターの裁量にあります。たとえば、異なるタイプのパケット、異なるレートのストリーム内のパケット、または異なる信頼要件を持つパケットを表すために使用できます。パケットは通常、そのリンクメトリックタイプをサポートしないルーターに配信されず、MANETとその中で送信されるパケットは、それに応じて管理する必要があることに注意してください（特にMANETに非MT-OLSRv2ルーターが含まれている場合） 。
The parameters used in [RFC7181], and in its normative references, are used in this specification with the following changes.
[RFC7181]とその規範的参照で使用されているパラメータは、次の変更を加えてこの仕様で使用されています。
Each OLSRv2 interface will support a number of link metric types, corresponding to Type Extensions of the LINK_METRIC TLV defined in [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers that do not implement MT-OLSRv2, and used with that definition in this specification, is replaced in routers implementing MT-OLSRv2 by an interface parameter array IFACE_METRIC_TYPES and a router parameter array ROUTER_METRIC_TYPES. Each element in these arrays is a link metric type (i.e., a type extension used by the LINK_METRIC TLV [RFC7181]).
各OLSRv2インターフェイスは、[RFC7181]で定義されているLINK_METRIC TLVのタイプ拡張に対応する、いくつかのリンクメトリックタイプをサポートします。 MT-OLSRv2を実装しないルーターで使用され、この仕様でその定義で使用されるルーターパラメーターLINK_METRIC_TYPEは、MT-OLSRv2を実装するルーターで、インターフェイスパラメーター配列IFACE_METRIC_TYPESおよびルーターパラメーター配列ROUTER_METRIC_TYPESに置き換えられます。これらの配列の各要素は、リンクメトリックタイプ（つまり、LINK_METRIC TLV [RFC7181]で使用されるタイプ拡張）です。
The interface parameter array IFACE_METRIC_TYPES contains the link metric types supported on that OLSRv2 interface. The router parameter array ROUTER_METRIC_TYPES is the union of all of the IFACE_METRIC_TYPES. Both arrays MUST be without repetitions.
インターフェイスパラメータ配列IFACE_METRIC_TYPESには、そのOLSRv2インターフェイスでサポートされているリンクメトリックタイプが含まれています。ルーターパラメータ配列ROUTER_METRIC_TYPESは、すべてのIFACE_METRIC_TYPESの和集合です。両方の配列は、繰り返しがない必要があります。
If in a given deployment there might be routers that do not implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE as its first element, so that the OLSRv2 interface can communicate with those routers. In that case, ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE as its first element.
所定の展開でMT-OLSRv2を実装しないルーターが存在する可能性がある場合、OLSRv2インターフェイスがこれらのルーターと通信できるように、IFACE_METRIC_TYPESに最初の要素としてLINK_METRIC_TYPEを含める必要があります。その場合、ROUTER_METRIC_TYPESには、最初の要素としてLINK_METRIC_TYPEも含める必要があります。
In addition, the router parameter WILL_ROUTING is extended to an array of values, one each for each link metric type in the router parameter list ROUTER_METRIC_TYPES.
さらに、ルーターパラメーターWILL_ROUTINGは、ルーターパラメーターリストROUTER_METRIC_TYPESのリンクメトリックタイプごとに1つずつ、値の配列に拡張されます。
The Information Bases specified in [RFC7181], which extend those specified in [RFC6130], are further extended in this specification. With the exception of the Routing Set, the extensions in this specification are the replacement of single values (boolean, willingness, number of hops, or link metric) from [RFC7181] with elements representing multiple values (associative mappings from a set of metric types to their corresponding values). The following subsections detail these extensions.
[RFC6130]で指定されたものを拡張する[RFC7181]で指定された情報ベースは、この仕様でさらに拡張されています。ルーティングセットを除いて、この仕様の拡張は、[RFC7181]の単一の値（ブール値、意欲、ホップ数、またはリンクメトリック）を、複数の値（メトリックタイプのセットからの関連マッピング）を表す要素に置き換えたものです。対応する値に）。以下のサブセクションでは、これらの拡張について詳しく説明します。
Note that, as in [RFC7181], an implementation is free to organize its internal data in any manner it chooses; it needs only to behave as if it were organized as described in [RFC7181] and this specification.
[RFC7181]のように、実装は内部データを選択する方法で自由に編成できることに注意してください。 [RFC7181]とこの仕様で説明されているように構成されているかのように動作する必要があるだけです。
Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops].
各要素AL_distはマップになります[ROUTER_METRIC_TYPES->ホップ数]。
Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素AL_metricは、マップ[ROUTER_METRIC_TYPES->リンクメトリック]になります。
Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link metric].
各要素L_in_metricはマップ[IFACE_METRIC_TYPES-> link metric]になります。
Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link metric].
各要素L_out_metricはマップ[IFACE_METRIC_TYPES-> link metric]になります。
The elements of L_in_metric MUST be set following the same rules that apply to the setting of the single element L_in_metric in [RFC7181].
L_in_metricの要素は、[RFC7181]の単一要素L_in_metricの設定に適用されるのと同じ規則に従って設定されなければなりません（MUST）。
Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素N2_in_metricは、マップ[ROUTER_METRIC_TYPES->リンクメトリック]になります。
Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素N2_out_metricは、マップ[ROUTER_METRIC_TYPES-> link metric]になります。
Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素N_in_metricはマップ[ROUTER_METRIC_TYPES->リンクメトリック]になります。
Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素N_out_metricはマップ[ROUTER_METRIC_TYPES-> link metric]になります。
Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> willingness].
各要素N_will_routingはマップ[ROUTER_METRIC_TYPES->意欲]になります。
Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> boolean].
各要素N_routing_mprはマップ[ROUTER_METRIC_TYPES-> boolean]になります。
Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> boolean].
各要素N_mpr_selectorはマップ[ROUTER_METRIC_TYPES->ブール値]になります。
Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> boolean].
各要素N_advertisedはマップ[ROUTER_METRIC_TYPES-> boolean]になります。
Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素TR_metricは、マップ[ROUTER_METRIC_TYPES->リンクメトリック]になります。
Note that some values of TR_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Router Topology Tuples whose corresponding value from TR_metric is UNKNOWN_METRIC are ignored.
TR_metricの一部の値がUNKNOWN_METRICの値を取る場合があることに注意してください。このマッピングからの対応するリンクメトリック値のみが使用されるルーティングセットの構築に使用される場合、TR_metricからの対応する値がUNKNOWN_METRICであるルータートポロジタプルは無視されます。
Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素TA_metricは、マップ[ROUTER_METRIC_TYPES->リンクメトリック]になります。
Note that some values of TA_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Routable Address Topology Tuples whose corresponding value from TA_metric is UNKNOWN_METRIC are ignored.
TA_metricの一部の値がUNKNOWN_METRICの値を取る場合があることに注意してください。このマッピングからの対応するリンクメトリック値のみが使用されるルーティングセットの構築に使用される場合、TA_metricからの対応する値がUNKNOWN_METRICであるルーティング可能なアドレストポロジタプルは無視されます。
Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops].
各要素AN_distはマップ[ROUTER_METRIC_TYPES->ホップ数]になります。
Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].
各要素AN_metricは、マップ[ROUTER_METRIC_TYPES->リンクメトリック]になります。
Note that some values of AN_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Attached Network Tuples whose corresponding value from AN_metric is UNKNOWN_METRIC are ignored.
AN_metricの一部の値がUNKNOWN_METRICの値を取る場合があることに注意してください。このマッピングからの対応するリンクメトリック値のみが使用されるルーティングセットの構築に使用される場合、AN_metricからの対応する値がUNKNOWN_METRICである接続ネットワークタプルは無視されます。
There is a separate Routing Set for each link metric type in ROUTER_METRIC_TYPES.
ROUTER_METRIC_TYPESには、リンクメトリックタイプごとに個別のルーティングセットがあります。
This specification makes the following additions and extensions to the TLVs defined in [RFC7181].
この仕様は、[RFC7181]で定義されているTLVに以下の追加と拡張を行います。
One new Message TLV is defined in this specification, and one existing Message TLV is extended by this specification.
この仕様では1つの新しいメッセージTLVが定義されており、1つの既存のメッセージTLVがこの仕様によって拡張されています。
The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 interfaces and TC messages. A message MUST NOT contain more than one MPR_TYPES TLV.
MPR_TYPES TLVは、OLSRv2インターフェイスを介して送信されるHELLOメッセージとTCメッセージの両方で使用されます。メッセージには、複数のMPR_TYPES TLVを含めることはできません。
The presence of this TLV in a message is used to indicate that the router supports MT-OLSRv2, in the same way that the presence of the MPR_WILLING TLV is used to indicate that the router supports OLSRv2, as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has been defined with the same Type as the MPR_WILLING TLV, but with Type Extension = 1.
[RFC7181]で指定されているように、MPR_WILLING TLVの存在がルーターがOLSRv2をサポートすることを示すのと同じように、メッセージにこのTLVが存在することは、ルーターがMT-OLSRv2をサポートすることを示します。このため、MPR_TYPES TLVはMPR_WILLING TLVと同じタイプで定義されていますが、タイプ拡張= 1です。
This TLV may take a Value field of any size. Each octet in its Value field will contain a link metric type that is supported, either on any OLSRv2 interface, when included in a TC message, or on the OLSRv2 interface on which a HELLO message including this TLV is sent. These octets MAY be in any order, but if there might be routers in the MANET that do not implement MT-OLSRv2, then the first octet MUST be LINK_METRIC_TYPE.
このTLVは、任意のサイズの値フィールドを取ることができます。 Valueフィールドの各オクテットには、TCメッセージに含まれている場合は、OLSRv2インターフェイス、またはこのTLVを含むHELLOメッセージが送信されるOLSRv2インターフェイスのいずれかでサポートされるリンクメトリックタイプが含まれます。これらのオクテットはどのような順序でもかまいませんが、MT-OLSRv2を実装しないルーターがMANETにある場合、最初のオクテットはLINK_METRIC_TYPEでなければなりません。
The MPR_WILLING TLV, which is used in HELLO messages, is specified in [RFC7181], and extended in this specification as enabled by [RFC7188].
HELLOメッセージで使用されるMPR_WILLING TLVは、[RFC7181]で指定されており、[RFC7188]によって有効にされるようにこの仕様で拡張されています。
The interpretation of this TLV, which is specified by [RFC7181] and uses all of its single-octet Value field, is unchanged. That interpretation uses bits 0-3 of its Value field to specify its willingness to be a flooding TLV, and bits 4-7 of its Value field to be a routing TLV. Those latter bits are, when using this specification, interpreted as its willingness to be a routing TLV using the link metric type LINK_METRIC_TYPE.
[RFC7181]で指定され、すべての単一オクテット値フィールドを使用するこのTLVの解釈は変更されていません。その解釈では、Valueフィールドのビット0〜3を使用して、フラッディングTLVになる意思を指定し、Valueフィールドのビット4〜7をルーティングTLVとして指定します。後者のビットは、この仕様を使用する場合、リンクメトリックタイプLINK_METRIC_TYPEを使用したルーティングTLVであると解釈されます。
The extended use of this message TLV, as defined by this specification, defines additional 4-bit sub-fields of the Value field, starting with bits 4-7 of the first octet and continuing with bits 0-3 of the second octet, to represent willingness to be a routing MPR using the link metric types specified in this OLSRv2 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the included MPR_TYPES Message TLV. Note that this means that, if there might be any non-MT-OLSRv2 routers, then the link metric type LINK_METRIC_TYPE will continue to occupy bits 4-7 of the first octet. (If there is no such TLV included, then the router does not support MT-OLSRv2, and only the first octet of the Value field will be used.)
この仕様で定義されているこのメッセージTLVの拡張使用では、最初のオクテットのビット4〜7から始まり、2番目のオクテットのビット0〜3まで続く、値フィールドの追加の4ビットサブフィールドを定義します。このOLSRv2インターフェイスのIFACE_METRIC_TYPESパラメータで指定されたリンクメトリックタイプを使用してルーティングMPRになる意思を表します。これは、含まれているMPR_TYPESメッセージTLVで報告されているとおりに順序付けされます。これは、MT-OLSRv2以外のルーターが存在する場合、リンクメトリックタイプLINK_METRIC_TYPEが引き続き最初のオクテットのビット4〜7を占めることを意味することに注意してください。 （そのようなTLVが含まれていない場合、ルーターはMT-OLSRv2をサポートせず、値フィールドの最初のオクテットのみが使用されます。）
If the number of link metric types in this OLSRv2 interface's IFACE_METRIC_TYPES parameter is even, then there will be an unused 4-bit sub-field in bits 4-7 of the last octet of a full-sized Value field. These bits will not be used; they SHOULD all be cleared ('0') on transmission and MUST be ignored on receipt.
このOLSRv2インターフェイスのIFACE_METRIC_TYPESパラメータのリンクメトリックタイプの数が偶数の場合、フルサイズの値フィールドの最後のオクテットのビット4〜7に未使用の4ビットサブフィールドがあります。これらのビットは使用されません。それらは送信時にすべてクリア（ '0'）し、受信時には無視する必要があります。
If the Value field in an MPR_WILLING TLV is shorter than its full length, then, as specified in [RFC7188], missing Value octets, i.e., missing willingness values, are considered as zero (WILL_NEVER). This is the correct behavior. (In particular, it means that an OLSRv2 router that is not implementing MT-OLSRv2 will not act as a routing MPR for any link metric that it does not recognize.)
MPR_WILLING TLVの値フィールドがその全長より短い場合、[RFC7188]で指定されているように、欠落している値オクテット、つまり欠落している意欲値はゼロ（WILL_NEVER）と見なされます。これは正しい動作です。 （特に、MT-OLSRv2を実装していないOLSRv2ルーターは、認識しないリンクメトリックのルーティングMPRとして機能しないことを意味します。）
New Type Extensions are defined for the LINK_METRIC TLV defined in [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, both defined in [RFC7181], are extended, as enabled by [RFC7188].
[RFC7181]で定義されているLINK_METRIC TLVに対して新しいタイプ拡張が定義され、[RFC7181]で定義されているMPR TLVとGATEWAY TLVの値フィールドが、[RFC7188]で有効になっているように拡張されています。
The LINK_METRIC TLV is used in HELLO messages and TC messages. This TLV is unchanged from the definition in [RFC7181].
LINK_METRIC TLVは、HELLOメッセージとTCメッセージで使用されます。このTLVは[RFC7181]の定義から変更されていません。
Only a single Type Extension was specified by [RFC7181] -- 0 for "Link metric meaning as assigned by administrative action". This specification extends it to the range 0-7. This specification will work with any combination of Type Extensions both within and outside that range (assuming that the latter are defined as specified in [RFC7181]).
[RFC7181]で指定されたタイプ拡張は1つだけでした。「管理アクションによって割り当てられたリンクメトリックの意味」は0です。この仕様は、それを0から7の範囲に拡張します。この仕様は、その範囲内と範囲外の両方のタイプ拡張の任意の組み合わせで機能します（後者は[RFC7181]で指定されているように定義されていると仮定します）。
The MPR TLV is used in HELLO messages and indicates that an address with which it is associated is of a symmetric 1-hop neighbor that has been selected as an MPR.
MPR TLVはHELLOメッセージで使用され、それが関連付けられているアドレスが、MPRとして選択された対称1ホップネイバーのものであることを示します。
The Value field of this address block TLV is, in [RFC7181], defined to be one octet long, with the values 1, 2, and 3 defined. [RFC7188] redefines this Value field to be a bitfield where bit 7 (the least significant bit) denotes flooding status, bit 6 denotes routing MPR status, and bits 5-0 are unallocated (respecting the semantics of the bits/values 1, 2, and 3 from [RFC7181]).
このアドレスブロックTLVの値フィールドは、[RFC7181]では、1オクテット長であると定義されており、値1、2、および3が定義されています。 [RFC7188]この値フィールドをビットフィールドに再定義します。ビット7（最下位ビット）はフラッディングステータスを示し、ビット6はルーティングMPRステータスを示し、ビット5〜0は割り当てられていません（ビット/値1、2のセマンティクスに関して） 、および[RFC7181]の3）。
This specification, as enabled by [RFC7188], extends the MPR TLV to have a variable-length Value field. Bits are allocated in increasing significance within as many octets as are required. These bits specify, in order, that:
[RFC7188]によって有効にされるこの仕様は、可変長の値フィールドを持つようにMPR TLVを拡張します。ビットは、必要な数のオクテット内で重要度が高くなるように割り当てられます。これらのビットは、次のことを順番に指定します。
o The neighbor with that network address has been selected as flooding MPR (1 bit).
o そのネットワークアドレスを持つネイバーは、フラッディングMPR（1ビット）として選択されています。
o The neighbor with that network address has been selected as routing MPR for each link metric type (1 bit each), in the same order as indicated in the Value field of an MPR_TYPES Message TLV.
o そのネットワークアドレスを持つネイバーは、MPR_TYPESメッセージTLVの値フィールドに示されているのと同じ順序で、各リンクメトリックタイプ（各1ビット）のルーティングMPRとして選択されています。
For interoperability with a router not implementing MT-OLSRv2, the two least significant bits of the first octet in the Value field of this TLV is as the TLV Value of an MPR TLV generated according to [RFC7181], as updated by [RFC7188].
MT-OLSRv2を実装していないルーターとの相互運用性のために、このTLVの値フィールドの最初のオクテットの最下位2ビットは、[RFC7181]に従って生成されたMPR TLVのTLV値であり、[RFC7188]によって更新されます。
The GATEWAY TLV is used in TC messages to indicate that a network address is of an attached network.
GATEWAY TLVはTCメッセージで使用され、ネットワークアドレスが接続されたネットワークのものであることを示します。
The Value field of this address block TLV is defined by [RFC7181] to be one octet long, containing the number of hops to that attached network.
このアドレスブロックTLVの値フィールドは、[RFC7181]によって1オクテットの長さと定義され、その接続されたネットワークへのホップ数が含まれます。
This specification, as enabled by [RFC7188], allows the extension of the GATEWAY TLV to have a variable-length Value field when the number of hops to each attached network is different for different link metric types. For interoperability with a router not implementing MT-OLSRv2, the first octet in the Value field of this TLV MUST be the TLV Value of the GATEWAY TLV generated according to [RFC7181].
[RFC7188]によって有効にされるこの仕様により、各接続ネットワークへのホップ数が異なるリンクメトリックタイプに対して異なる場合、GATEWAY TLVの拡張に可変長の値フィールドを含めることができます。 MT-OLSRv2を実装していないルーターとの相互運用性のために、このTLVの値フィールドの最初のオクテットは、[RFC7181]に従って生成されたゲートウェイTLVのTLV値でなければなりません（MUST）。
Any subsequent octets in the TLV Value field indicate the number of hops to the attached network for each other link metric type. Link metric types (including the first) are ordered as indicated in the Value field of an MPR_TYPES Message TLV.
TLV値フィールドの後続のオクテットは、他の各リンクメトリックタイプについて、接続されたネットワークへのホップ数を示します。リンクメトリックタイプ（最初のものを含む）は、MPR_TYPESメッセージTLVの値フィールドに示されているように順序付けられます。
+---------+---------------------------------------------------------+
| Type | Value |
+---------+---------------------------------------------------------+
| GATEWAY | Number of hops to attached network for each link metric |
| | type. |
+---------+---------------------------------------------------------+
Table 1: GATEWAY TLV Definition
表1：ゲートウェイTLV定義
The following changes are made to the generation and processing of HELLO messages compared to the description in [RFC7181] for routers that implement MT-OLSRv2.
MT-OLSRv2を実装するルーターの[RFC7181]の説明と比較して、HELLOメッセージの生成と処理に次の変更が加えられています。
A generated HELLO message to be sent on an OLSRv2 interface (whose IFACE_METRIC_TYPES parameter will be that used) is extended by:
OLSRv2インターフェイスで送信される生成されたHELLOメッセージ（IFACE_METRIC_TYPESパラメーターは使用されるものになります）は、次のように拡張されます。
o Adding an MPR_TYPES Message TLV. The Value octets will be the link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE.
o MPR_TYPESメッセージTLVの追加。 Valueオクテットは、IFACE_METRIC_TYPESのリンクメトリックタイプになります。含まれるリンクメトリックタイプがLINK_METRIC_TYPEのみの場合、このTLVは省略できます。
o Extending the MPR_WILLING Message TLV Value field to report the willingness values from the WILL_ROUTING parameter list that correspond to the link metric types in IFACE_METRIC_LIST, in the same order as reported in the MPR_TYPES TLV, each value (also including one representing WILL_FLOODING) occupying 4 bits.
o MPR_TYPES TLVで報告されているのと同じ順序で、IFACE_METRIC_LISTのリンクメトリックタイプに対応するWILL_ROUTINGパラメータリストからの意欲値を報告するMPR_WILLINGメッセージのTLV値フィールドを拡張し、各値（WILL_FLOODINGを表すものも含む）が4ビットを占める。
o Including LINK_METRIC Address Block TLVs that report all values in L_in_metric, L_out_metric, N_in_metric, and N_out_metric elements that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [RFC7181].
o L_in_metric、L_out_metric、N_in_metric、およびN_out_metric要素のすべての値を報告するLINK_METRICアドレスブロックTLVを含みます。これらは、UNKNOWN_METRICと等しくなく、TLV Type Extensionはリンクメトリックタイプです。 。
o Including MPR Address Block TLVs such that for each link metric type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, the indicated addresses MUST be of the MPRs in an MPR set as specified for a single link metric type in [RFC7181].
o IFACE_METRIC_TYPESの各リンクメトリックタイプ、およびフラッディングMPRの選択に対して、[RFC7181]で単一のリンクメトリックタイプに指定されたMPRセットのMPRのMPRアドレスブロックTLVを含める必要があります。
On receipt of a HELLO message on an OLSRv2 interface, a router implementing MT-OLSRv2 MUST do the following, in addition to the processing described in [RFC7181]:
OLSRv2インターフェイスでHELLOメッセージを受信すると、MT-OLSRv2を実装するルーターは、[RFC7181]で説明されている処理に加えて、次のことを実行する必要があります。
1. If in this deployment there might be routers that do not implement MT-OLSRv2, the HELLO message contains an MPR_TYPES Message TLV, and the first link metric type that it reports is not LINK_METRIC_TYPE, then the HELLO message MUST be silently discarded.
1. この展開で、MT-OLSRv2を実装しないルーターが存在する可能性があり、HELLOメッセージにMPR_TYPESメッセージTLVが含まれ、それが報告する最初のリンクメトリックタイプがLINK_METRIC_TYPEではない場合、HELLOメッセージは暗黙的に破棄される必要があります。
2. Determine the list of link metric types supported by the sending router on its corresponding OLSRv2 interface, either from an MPR_TYPES Message TLV (if present) or from the single link metric type LINK_METRIC_TYPE.
2. MPR_TYPESメッセージTLV（存在する場合）または単一のリンクメトリックタイプLINK_METRIC_TYPEのいずれかから、対応するOLSRv2インターフェイスの送信ルーターがサポートするリンクメトリックタイプのリストを決定します。
3. For all link metric types reported and supported by the receiving router, set the appropriate L_out_metric, N_in_metric, N_out_metric, N_will_routing, N_mpr_selector, N_advertised, N2_in_metric, and N2_out_metric elements using the rules for setting the single elements of those types specified in [RFC7181].
3. 受信ルーターによって報告およびサポートされるすべてのリンクメトリックタイプについて、[RFC7181]で指定されているタイプの単一要素を設定するためのルールを使用して、適切なL_out_metric、N_in_metric、N_out_metric、N_will_routing、N_mpr_selector、N_advertised、N2_in_metric、およびN2_out_metric要素を設定します。
4. For any other metric types supported by the receiving router only (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set the elements listed in the previous point to their default values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or false.
4. 受信ルーターでのみサポートされているその他のメトリックタイプの場合（つまり、受信OLSRv2インターフェイスのIFACE_METRICで）、前のポイントにリストされている要素をデフォルト値、つまりUNKNOWN_METRIC、WILL_NEVER（WILL_DEFAULTではない）、またはfalseに設定します。
The following changes are made to the generation and processing of TC messages compared to that described in [RFC7181] by routers that implement MT-OLSRv2.
MT-OLSRv2を実装するルーターによって、[RFC7181]で説明されているものと比較して、TCメッセージの生成と処理に次の変更が加えられています。
A generated TC message is extended by:
生成されたTCメッセージは、以下によって拡張されます。
o Adding an MPR_TYPES TLV. The Value octets will be the link metric types in ROUTER_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE.
o MPR_TYPES TLVを追加します。 Valueオクテットは、ROUTER_METRIC_TYPESのリンクメトリックタイプになります。含まれるリンクメトリックタイプがLINK_METRIC_TYPEのみの場合、このTLVは省略できます。
o Including LINK_METRIC TLVs that report all values of N_out_metric that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [RFC7181].
o UNKNOWN_METRICと等しくないN_out_metricのすべての値を報告するLINK_METRIC TLVを含み、TLV Type Extensionはリンクメトリックタイプであり、それ以外の場合は[RFC7181]で指定されているそのような包含のルールに従います。
o Including a number of hops per reported (in an MPR_TYPES Message TLV) link metric type in the Value field of each GATEWAY TLV included, in the same order as reported in the MPR_TYPES TLV.
o MPR_TYPES TLVで報告されたのと同じ順序で、含まれる各GATEWAY TLVの値フィールドに、報告された（MPR_TYPESメッセージTLVの）リンクメトリックタイプごとのホップ数を含めます。
On receipt of a TC message, a router implementing this extension MUST do the following, in addition to the processing specified in [RFC7181]:
TCメッセージを受信すると、この拡張機能を実装するルーターは、[RFC7181]で指定されている処理に加えて、次のことを実行する必要があります。
o If in this deployment there might be routers that do not implement MT-OLSRv2, the TC message contains an MPR_TYPES Message TLV, and the first link metric type that it reports is not LINK_METRIC_TYPE, then the TC message MUST be silently discarded.
o この展開でMT-OLSRv2を実装していないルーターが存在する可能性があり、TCメッセージにMPR_TYPESメッセージTLVが含まれ、それが報告する最初のリンクメトリックタイプがLINK_METRIC_TYPEではない場合、TCメッセージは暗黙的に破棄する必要があります。
o For all link metric types reported and supported by the receiving router, set the appropriate TR_metric, TA_metric, AN_dist, and AN_metric elements using the rules for setting the single elements of those types specified in [RFC7181].
o 受信ルーターによって報告およびサポートされるすべてのリンクメトリックタイプについて、[RFC7181]で指定されているタイプの単一要素を設定するためのルールを使用して、適切なTR_metric、TA_metric、AN_dist、およびAN_metric要素を設定します。
o For any other metric types supported by the receiving router that do not have an advertised outgoing neighbor metric of that type, set the corresponding elements of TR_metric, TA_metric, and AN_metric to UNKNOWN_METRIC. (The corresponding element of AN_dist may be set to any value.)
o そのタイプのアドバタイズされた発信ネイバーメトリックを持たない、受信ルータによってサポートされる他のメトリックタイプの場合、TR_metric、TA_metric、およびAN_metricの対応する要素をUNKNOWN_METRICに設定します。 （AN_distの対応する要素は任意の値に設定できます。）
Routing MPRs are calculated for each link metric type in ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 interfaces that do not support that link metric type are not considered. The determined status (routing MPR or not routing MPR) for each link metric type is recorded in the relevant element of N_routing_mpr.
ルーティングMPRは、ROUTER_METRIC_TYPESのリンクメトリックタイプごとに計算されます。そのリンクメトリックタイプをサポートしないOLSRv2インターフェイスを介した対称1ホップネイバーへのリンクは考慮されません。各リンクメトリックタイプの決定されたステータス（ルーティングMPRまたはルーティングMPR以外）は、N_routing_mprの関連する要素に記録されます。
Each router may make its own decision as to whether or not to use a link metric, or link metrics, for flooding MPR calculation. If using link metric(s), each router decides which one(s) and how they are used. These decisions MUST be made in a manner that ensures that flooded messages will reach the same symmetric 2-hop neighbors as would be the case for a router not supporting MT-OLSRv2.
各ルーターは、フラッディングMPR計算に1つまたは複数のリンクメトリックを使用するかどうかについて独自の決定を行う場合があります。リンクメトリックを使用している場合、各ルーターは、どのメトリックをどのように使用するかを決定します。これらの決定は、ルータがMT-OLSRv2をサポートしていない場合と同様に、フラッディングメッセージが同じ対称2ホップネイバーに確実に到達するように行う必要があります。
Note that it is possible that a 2-Hop Tuple in the Information Base for a given OLSRv2 interface does not support any of the link metric types that are in the router's corresponding IFACE_METRIC_TYPES; nevertheless, that 2-Hop Tuple MUST be considered when determining flooding MPRs.
特定のOLSRv2インターフェイスの情報ベースの2ホップタプルが、ルーターの対応するIFACE_METRIC_TYPESにあるリンクメトリックタイプをサポートしていない可能性があることに注意してください。それにもかかわらず、フラッディングMPRを決定するときは、その2ホップタプルを考慮する必要があります。
A Routing Set is calculated for each link metric type in ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except that where an element is now represented by a map, the value from the map for the selected link metric type is used. Where this is a link metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for the calculation.
ルーティングセットは、ROUTER_METRIC_TYPESのリンクメトリックタイプごとに計算されます。計算は[RFC7181]の場合と同じですが、要素がマップで表される場合を除き、選択したリンクメトリックタイプのマップの値が使用されます。これが値UNKNOWN_METRICのリンクメトリックである場合、そのプロトコルタプルは計算では無視されます。
MT-OLSRv2 may require greater management than unextended OLSRv2. In particular, a MANET using MT-OLSRv2 requires the following management considerations:
MT-OLSRv2は、拡張されていないOLSRv2よりも管理が必要になる場合があります。特に、MT-OLSRv2を使用するMANETでは、次の管理上の考慮事項が必要です。
o Deciding which link metric, and hence which Routing Set to use, for received packets, hence how to use the Routing Sets to configure the network layer (IP). All routers MUST make the same decision for the same packet. An obvious approach is to map each DSCP [RFC2474] to a single link metric. (This may be a many-to-one mapping.)
o 受信パケットに対してどのリンクメトリック、したがってどのルーティングセットを使用するかを決定し、ルーティングセットを使用してネットワークレイヤー（IP）を構成する方法。すべてのルーターは、同じパケットに対して同じ決定を行う必要があります。明白なアプローチは、各DSCP [RFC2474]を単一のリンクメトリックにマッピングすることです。 （これは多対1のマッピングになる場合があります。）
o Selecting which link metrics to support on each OLSRv2 interface and implementing that decision. (Different interfaces may have different physical and data link-layer properties, and this may inform the selection of link metrics to support, and their values.) If the MANET might contain non-MT-OLSRv2 routers, which are also subject to management, then the rules in this specification for link metric assignment to OLSRv2 interfaces for that case MUST be followed.
o 各OLSRv2インターフェイスでサポートするリンクメトリックを選択し、その決定を実装します。 （インターフェイスによって物理層とデータリンク層のプロパティが異なる場合があり、これにより、サポートするリンクメトリックの選択とその値が通知される場合があります。MANETに管理対象の非MT-OLSRv2ルーターが含まれている可能性がある場合は、その場合、その場合のOLSRv2インターフェイスへのリンクメトリック割り当てに関するこの仕様のルールに従う必要があります。
o Ensuring that the MANET is sufficiently connected, by ensuring that, for example, sufficiently many routers implement each metric type required. (This is easier in, for example, a denser network.) Note that if there is any possibility that there are routers not implementing MT-OLSRv2, then the MANET will be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE, but this will only serve to deliver packets that use that link metric type.
o たとえば、十分に多くのルーターが必要な各メトリックタイプを実装するようにすることで、MANETが十分に接続されていることを確認します。 （これは、たとえば、より密度の高いネットワークではより簡単です。）MT-OLSRv2を実装していないルーターがある可能性がある場合、リンクメトリックタイプLINK_METRIC_TYPEを使用して、可能な限りMANETが接続されます。ただし、これは、そのリンクメトリックタイプを使用するパケットを配信するためにのみ機能します。
o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets that will be routed by a topology that they are not part of. However, if that were to happen, then such packets will be routed until either they reach their destination or they reach an MT-OLSRv2 router. In the latter case, the packet then either will be dropped (if that MT-OLSRv2 router is not part of that topology, or is not aware of the destination within that topology) or will be routed by that topology to the destination. Such a packet will not loop.
o非MT-OLSRv2ルーターは、その一部ではないトポロジーによってルーティングされるパケットを生成しないように管理する必要があります（SHOULD）。ただし、それが発生した場合、そのようなパケットは、宛先に到達するか、MT-OLSRv2ルーターに到達するまでルーティングされます。後者の場合、パケットはドロップされるか（MT-OLSRv2ルーターがそのトポロジの一部でない場合、またはそのトポロジ内の宛先を認識していない場合）、またはそのトポロジによって宛先にルーティングされます。このようなパケットはループしません。
o If a packet is created for a destination that is not part of the corresponding topology, then it may or may not be delivered (if the originating router is a non-MT-OLSRv2 router) or will not be sent (if the originating router is an MT-OLSRv2 router). Routers SHOULD be managed so that topologies are as complete as possible and that packets are not sent if they may not be delivered. In particular, non-MT-OLSRv2 routers SHOULD only send packets that will be routed using the topology using the link metric type LINK_METRIC_TYPE.
o 対応するトポロジの一部ではない宛先に対してパケットが作成された場合、そのパケットは配信される場合と配信されない場合（送信元ルーターが非MT-OLSRv2ルーターの場合）または送信されない（送信元ルーターがMT-OLSRv2ルーター）。トポロジーが可能な限り完全であり、パケットが配信されない場合にパケットが送信されないように、ルーターを管理する必要があります（SHOULD）。特に、非MT-OLSRv2ルーターは、リンクメトリックタイプLINK_METRIC_TYPEを使用するトポロジを使用してルーティングされるパケットのみを送信する必要があります（SHOULD）。
This specification adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV, using a new name. It also modifies the Value field of an existing Message TLV and that of an existing Address Block TLV. Finally, this specification makes additional allocations from the LINK_METRIC Address Block TLV Type registry.
この仕様は、新しいタイプ拡張として割り当てられた1つの新しいメッセージTLVを、新しい名前を使用して既存のメッセージTLVに追加します。また、既存のメッセージTLVの値フィールドと既存のアドレスブロックTLVの値フィールドを変更します。最後に、この仕様は、LINK_METRICアドレスブロックTLVタイプレジストリから追加の割り当てを行います。
For the registry where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444] and [RFC7631].
専門家レビューが必要なレジストリでは、指定された専門家は、[RFC5444]と[RFC7631]で指定されているものと同じ一般的な推奨事項を考慮に入れる必要があります（SHOULD）。
This specification modifies the Message TLV Type 7, replacing Table 4 of [RFC7631] by Table 2, changing the description of the Type Extension MPR_WILLING, and adding the Type Extension TLV_TYPES. Each of these TLVs MUST NOT be included more than once in a Message TLV Block.
この仕様は、メッセージTLVタイプ7を変更して、[RFC7631]の表4を表2に置き換え、タイプ拡張MPR_WILLINGの説明を変更し、タイプ拡張TLV_TYPESを追加します。これらの各TLVは、メッセージTLVブロックに2回以上含めることはできません。
+-----------+-------------+-------------------------+---------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+-------------+-------------------------+---------------+
| 0 | MPR_WILLING | First (most | [RFC7181] |
| | | significant) half-octet | [RFC7631] |
| | | of Value field | RFC 7722 |
| | | specifies the | |
| | | originating router's | |
| | | willingness to act as a | |
| | | flooding MPR; | |
| | | subsequent half-octets | |
| | | specify the originating | |
| | | router's willingness to | |
| | | act as a routing MPR, | |
| | | either for the link | |
| | | metric types reported | |
| | | in an MPR_TYPES TLV (in | |
| | | the same order), or (if | |
| | | no MPR_TYPES TLV is | |
| | | present) for the single | |
| | | administratively agreed | |
| | | link metric type | |
| 1 | MPR_TYPES | The link metric types | RFC 7722 |
| | | supported on this | |
| | | OLSRv2 interface of | |
| | | this router (one octet | |
| | | each). | |
| 2-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC7181] |
| | | Experimental Use | |
+-----------+-------------+-------------------------+---------------+
Table 2: Type 7 Message TLV Type Extensions
表2：タイプ7メッセージTLVタイプ拡張
Table 7 of [RFC7188] is replaced by Table 3.
[RFC7188]の表7は、表3に置き換えられました。
+-------+-------+----------+----------------------------------------+
| Bit | Value | Name | Description |
+-------+-------+----------+----------------------------------------+
| First | First | Flooding | If set, then the neighbor with that |
| octet | octet | | network address has been selected as |
| bit 7 | 0x01 | | flooding MPR |
| From | From | Routing | If set, then the neighbor with that |
| first | first | | network address has been selected as |
| octet | octet | | routing MPR, either for the link |
| bit 6 | 0x02 | | metric types reported in an MPR_TYPES |
| | | | TLV (in the same order), or (if no |
| | | | MPR_TYPES TLV is present) then (first |
| | | | octet bit 6, value 0x02) for the |
| | | | single administratively agreed link |
| | | | metric type |
+-------+-------+----------+----------------------------------------+
Table 3: MPR TLV Bit Values
表3：MPR TLVビット値
Table 14 of [RFC7631] is replaced by Table 4. The only changes are to the Description and the References for the GATEWAY TLV.
[RFC7631]の表14は、表4に置き換えられました。変更点は、ゲートウェイTLVの説明と参照のみです。
+-----------+---------+-----------------------------+---------------+
| Type | Name | Description | References |
| Extension | | | |
+-----------+---------+-----------------------------+---------------+
| 0 | GATEWAY | Specifies that a given | [RFC7181] |
| | | network address is reached | RFC 7722 |
| | | via a gateway on the | |
| | | originating router. The | |
| | | number of hops is indicated | |
| | | by the Value field, one | |
| | | octet per link metric type | |
| | | reported in an MPR_TYPES | |
| | | Message TLV (in the same | |
| | | order) or (if no MPR_TYPES | |
| | | Message TLV is present) | |
| | | using a single octet | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [RFC7631] |
| | | Use | |
+-----------+---------+-----------------------------+---------------+
Table 4: Type 10 Address Block TLV Type Extensions
表4：タイプ10アドレスブロックTLVタイプ拡張
Table 13 of [RFC7181] is replaced by Table 5. The only change is that 8 Type Extensions are allocated as assigned by administrative action, in order to support administratively determined multi-topologies.
[RFC7181]の表13は表5に置き換えられます。唯一の変更点は、管理的に決定されたマルチトポロジをサポートするために、管理アクションによって割り当てられた8つのタイプ拡張が割り当てられることです。
+-------------+------+-----------+-------------------+--------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+-------------------+--------------+
| LINK_METRIC | 7 | 0-7 | Link metric | |
| | | | meaning assigned | |
| | | | by administrative | |
| | | | action. | |
| LINK_METRIC | 7 | 8-223 | Unassigned. | Expert |
| | | | | Review |
| LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental |
| | | | | Use |
+-------------+------+-----------+-------------------+--------------+
Table 5: Address Block TLV Type assignment: LINK_METRIC
表5：アドレスブロックTLVタイプの割り当て：LINK_METRIC
This extension to OLSRv2 allows a router to support more than one link metric type for each link advertised in HELLO and TC messages, and for routers to support different sets of types. Link metric values of additional types are reported by the inclusion of additional TLVs in the messages sent by a router, which will report known values of all supported types.
このOLSRv2の拡張により、ルーターはHELLOおよびTCメッセージで通知される各リンクに対して複数のリンクメトリックタイプをサポートし、ルーターは異なるタイプのセットをサポートすることができます。追加のタイプのリンクメトリック値は、サポートされているすべてのタイプの既知の値を報告するルーターによって送信されるメッセージに追加のTLVを含めることによって報告されます。
HELLO and TC message processing is then extended simply to record, for each supported type, all of the received link metric values for each link. Protocol-internal processing (specifically, MPR set and shortest path calculations) then operates as specified in [RFC7181] for each link metric type that the router supports.
次に、HELLOおよびTCメッセージ処理が拡張され、サポートされているタイプごとに、各リンクで受信したすべてのリンクメトリック値が記録されます。プロトコル内部処理（具体的には、MPRセットと最短パスの計算）は、ルーターがサポートする各リンクメトリックタイプに対して[RFC7181]で指定されたとおりに動作します。
Consequently, the security considerations, including the security architecture and the mandatory security mechanisms, from [RFC7181] are directly applicable to MT-OLSRv2.
したがって、[RFC7181]のセキュリティアーキテクチャや必須のセキュリティメカニズムなどのセキュリティに関する考慮事項は、MT-OLSRv2に直接適用できます。
Furthermore, this extension does not introduce any additional vulnerabilities beyond those of [RFC7181], because each link metric type is used independently, and each one could have been the single link metric type supported by an implementation of [RFC7181] receiving the same information, as received information of an unsupported type is ignored by all routers.
さらに、この拡張は[RFC7181]の脆弱性を超える追加の脆弱性をもたらしません。これは、各リンクメトリックタイプが独立して使用され、それぞれが同じ情報を受信する[RFC7181]の実装によってサポートされる単一のリンクメトリックタイプである可能性があるためです。サポートされていないタイプの受信情報はすべてのルーターで無視されるためです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <http://www.rfc-editor.org/info/rfc5444>.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、DOI 10.17487 / RFC5444、2009年2月、< http://www.rfc-editor.org/info/rfc5444>。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、DOI 10.17487 / RFC6130、2011年4月、<http：// www.rfc-editor.org/info/rfc6130>。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>.
[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P。、およびU. Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、DOI 10.17487 / RFC7181、2014年4月、<http：// www.rfc-editor.org/info/rfc7181>。
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs", RFC 7188, DOI 10.17487/RFC7188, April 2014, <http://www.rfc-editor.org/info/rfc7188>.
[RFC7188] Dearlove、C。およびT. Clausen、「Optimized Link State Routing Protocol Version 2（OLSRv2）and MANET Neighborhood Discovery Protocol（NHDP）Extension TLVs」、RFC 7188、DOI 10.17487 / RFC7188、2014年4月、<http：/ /www.rfc-editor.org/info/rfc7188>。
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format", RFC 7631, DOI 10.17487/RFC7631, September 2015, <http://www.rfc-editor.org/info/rfc7631>.
[RFC7631] Dearlove、C。およびT. Clausen、「モバイルアドホックネットワーク（MANET）の一般化されたパケット/メッセージ形式でのTLV命名」、RFC 7631、DOI 10.17487 / RFC7631、2015年9月、<http：//www.rfc -editor.org/info/rfc7631>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<http://www.rfc-editor.org/info/rfc2474>。
[RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, DOI 10.17487/RFC2501, January 1999, <http://www.rfc-editor.org/info/rfc2501>.
[RFC2501] Corson、S。およびJ. Macker、「モバイルアドホックネットワーキング（MANET）：ルーティングプロトコルのパフォーマンスの問題と評価に関する考慮事項」、RFC 2501、DOI 10.17487 / RFC2501、1999年1月、<http：//www.rfc- editor.org/info/rfc2501>。
[RFC3626] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, <http://www.rfc-editor.org/info/rfc3626>.
[RFC3626] Clausen、T.、Ed。、and P. Jacquet、Ed。、 "Optimized Link State Routing Protocol（OLSR）"、RFC 3626、DOI 10.17487 / RFC3626、October 2003、<http：//www.rfc- editor.org/info/rfc3626>。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>.
[RFC4915] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「OSPFでのマルチトポロジ（MT）ルーティング」、RFC 4915、DOI 10.17487 / RFC4915、 2007年6月、<http://www.rfc-editor.org/info/rfc4915>。
Acknowledgments
謝辞
The authors would like to thank (in alphabetical order): Juliusz Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems), Susan Hares (Huawei), and Henning Rogge (FGAN) for discussions and suggestions.
著者は、（アルファベット順で）Juliusz Chroboczek（パリ大学ディドロ）、Alan Cullen（BAE Systems）、Susan Hares（Huawei）、およびHenning Rogge（FGAN）にディスカッションと提案に感謝します。
Authors' Addresses
著者のアドレス
Christopher Dearlove BAE Systems Applied Intelligence Laboratories West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems Applied Intelligence Laboratoriesウェストハニングフィールドロードイギリス、チェルムズフォード、グレートバッドウ
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen LIX, Ecole Polytechnique
トーマスハイデクラウセンLIX、エコールポリテクニック
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/