[要約] RFC 7185は、OLSRv2のためのリンクメトリックに関する情報を提供するものであり、MANETルーティングプロトコルの改善を目的としています。このRFCの目的は、OLSRv2の性能向上とネットワークの信頼性の向上を促進することです。
Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7185 BAE Systems ATC
Category: Informational T. Clausen
ISSN: 2070-1721 LIX, Ecole Polytechnique
P. Jacquet
Alcatel-Lucent Bell Labs
April 2014
Rationale for the Use of Link Metrics in the Optimized Link State Routing Protocol Version 2 (OLSRv2)
最適化されたリンク状態ルーティングプロトコルバージョン2（OLSRv2）でのリンクメトリックの使用の根拠
Abstract
概要
The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.
最適化リンク状態ルーティングプロトコルバージョン2（OLSRv2）には、リンクにメトリックを割り当て、それらのメトリックを使用して最小ホップカウントルート以外のルーティングを許可する機能が含まれています。このドキュメントは、リンクメトリックがOLSRv2にどのように含まれていたか、およびその背後にある設計上の考慮事項の歴史的記録を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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/rfc7185.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7185で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Applicability ...................................................5
4. Motivational Scenarios ..........................................5
5. Link Metrics ....................................................7
5.1. Link Metric Properties .....................................7
5.2. Link Metric Types ..........................................8
5.3. Directional Link Metrics ..................................10
5.4. Reporting Link and Neighbor Metrics .......................10
5.5. Defining Incoming Link Metrics ............................12
5.6. Link Metric Values ........................................12
6. MPRs with Link Metrics .........................................14
6.1. Flooding MPRs .............................................14
6.2. Routing MPRs ..............................................16
6.3. Relationship between MPR Sets .............................19
7. Security Considerations ........................................21
8. Acknowledgements ...............................................21
9. Informative References .........................................21
Appendix A. MPR Routing Property .................................23
The Optimized Link State Routing Protocol version 1 (OLSRv1) [RFC3626] is a proactive routing protocol for mobile ad hoc networks (MANETs) [RFC2501]. OLSRv1 finds the shortest, defined as minimum number of hops, routes from a router to all possible destinations.
最適化リンクステートルーティングプロトコルバージョン1（OLSRv1）[RFC3626]は、モバイルアドホックネットワーク（MANET）[RFC2501]向けのプロアクティブルーティングプロトコルです。 OLSRv1は、ルーターから可能なすべての宛先への最短ルート（最小ホップ数として定義）を検出します。
Using only minimum hop routes may result in what are, in practice, inferior routes. Some examples are given in Section 4. Thus, one of the distinguishing features of the Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] is the introduction of the ability to select routes using link metrics other than the number of hops.
最小ホップルートのみを使用すると、実際には下位ルートになる可能性があります。いくつかの例をセクション4に示します。したがって、最適化リンクステートルーティングプロトコルバージョン2（OLSRv2）[RFC7181]の特徴の1つは、ホップ数以外のリンクメトリックを使用してルートを選択する機能の導入です。
During the development of OLSRv2, the working group and authors repeatedly discussed how and why some choices were made in the protocol specification, particularly at the metric integration level. Some of the issues may be non-intuitive, and this document is presented as a record of the considerations and decisions to provide informational discussion about motivation and historic design choices. This document is intended to be useful as a reference if those questions arise again.
OLSRv2の開発中に、ワーキンググループと作成者は、プロトコル仕様で、特にメトリック統合レベルで、いくつかの選択がどのようにそしてなぜ行われたかについて繰り返し議論しました。一部の問題は直感的でない可能性があり、このドキュメントは、動機と歴史的な設計の選択についての情報的な議論を提供するための考慮事項と決定の記録として提示されています。このドキュメントは、これらの質問が再度発生した場合の参考資料として役立ちます。
Use of the extensible message format [RFC5444] by OLSRv2 has allowed the addition, by OLSRv2, of link metric information to the HELLO messages defined in the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] as well as inclusion in the Topology Control (TC) messages defined in [RFC7181].
OLSRv2による拡張可能なメッセージフォーマット[RFC5444]の使用により、OLSRv2によって、MANET Neighborhood Discovery Protocol（NHDP）[RFC6130]で定義されたHELLOメッセージへのリンクメトリック情報の追加、およびトポロジーコントロール（TC ）[RFC7181]で定義されているメッセージ。
OLSRv2 essentially first determines local link metrics from 1-hop neighbors, these being defined by a process outside OLSRv2, then distributes required link metric values in HELLO messages and TC messages, and then finally forms routes with minimum total link metric. Using a definition of route metric other than number of hops is a natural extension that is commonly used in link state protocols.
OLSRv2は基本的に、最初に1ホップネイバーからローカルリンクメトリックを決定します。これらはOLSRv2の外部のプロセスによって定義され、次にHELLOメッセージとTCメッセージで必要なリンクメトリック値を配布し、最後に最小合計リンクメトリックを持つルートを形成します。ホップ数以外のルートメトリックの定義を使用することは、リンク状態プロトコルで一般的に使用される自然な拡張です。
A metric-based route selection process for OLSRv2 could have been handled as an extension to OLSRv2. However, were this to have been done, OLSRv2 routers that did not implement this extension would not recognize any link metric information and would attempt to use minimum hop-count routes. This would have meant that, in effect, routers that did implement and routers that did not implement this extension would differ over their valuation of links and routes. This would have led to the fundamental routing problem of "looping". Thus, if metric-based route selection were to have been considered only as an extension to OLSRv2, then routers that did implement and routers that did not implement this extension would not have been able to interoperate. This would have been a significant limitation of such an extension. Link metrics were therefore included as standard in OLSRv2.
OLSRv2のメトリックベースのルート選択プロセスは、OLSRv2の拡張機能として処理できました。ただし、これが行われた場合、この拡張機能を実装していないOLSRv2ルーターはリンクメトリック情報を認識せず、最小ホップカウントルートを使用しようとします。つまり、実際には、この拡張機能を実装したルーターと実装していないルーターでは、リンクとルートの評価が異なることになります。これは、「ループ」という根本的なルーティングの問題を引き起こしていたでしょう。したがって、メトリックベースのルート選択がOLSRv2の拡張機能としてのみ考慮されている場合、この拡張機能を実装したルーターと実装していないルーターは相互運用できませんでした。これは、そのような拡張の重要な制限でした。したがって、リンクメトリックはOLSRv2に標準で含まれていました。
This document discusses the motivation and design rationale behind how link metrics were included in OLSRv2. The principal issues involved when including link metrics in OLSRv2 were:
このドキュメントでは、OLSRv2にリンクメトリックがどのように含まれていたかについての動機と設計の根拠について説明します。リンクメトリックをOLSRv2に含めるときに伴う主な問題は次のとおりです。
o Assigning metrics to links involved considering separate metrics for the two directions of a link, with the receiving router determining the metric from transmitter to receiver. A metric used by OLSRv2 may be either of:
o リンクへのメトリックの割り当てには、リンクの2つの方向の個別のメトリックを考慮し、受信側のルーターがトランスミッターからレシーバーへのメトリックを決定します。 OLSRv2で使用されるメトリックは、次のいずれかです。
* A link metric, the metric of a specific link from an OLSRv2 interface of the transmitting router to an OLSRv2 interface of the receiving router.
* リンクメトリック。送信ルーターのOLSRv2インターフェイスから受信ルーターのOLSRv2インターフェイスへの特定のリンクのメトリック。
* A neighbor metric, the minimum of the link metrics between two OLSRv2 routers, in the indicated direction.
* 指定された方向の2つのOLSRv2ルーター間のリンクメトリックの最小値であるネイバーメトリック。
These metrics are necessarily the same when these routers each have a single OLSRv2 interface but may differ when either has more. HELLO messages may include both link metrics and neighbor metrics. TC messages include only neighbor metrics.
これらのメトリックは、これらのルーターがそれぞれ単一のOLSRv2インターフェースを備えている場合は必ず同じですが、どちらかが多い場合は異なる場合があります。 HELLOメッセージには、リンクメトリックとネイバーメトリックの両方が含まれる場合があります。 TCメッセージには、ネイバーメトリックのみが含まれます。
o Metrics as used in OLSRv2 are defined to be dimensionless and additive. The assignment of metrics, including their relationship to real parameters such as data rate, loss rate, and delay, and the management of the choice of metric, is outside the scope of [RFC7181], which simply uses these metrics in a consistent manner. Within a single MANET, including all components of a temporarily fragmented MANET, a single choice of link metric is used. By use of a registry of metric types (employing extended types of a single Address Block TLV type), routers can be configured to use only a subset of the available metric types.
o OLSRv2で使用されるメトリックは、無次元で付加的であると定義されています。データレート、損失率、遅延などの実際のパラメータとの関係を含むメトリックの割り当て、およびメトリックの選択の管理は、これらのメトリックを一貫した方法で使用する[RFC7181]の範囲外です。一時的に断片化されたMANETのすべてのコンポーネントを含む単一のMANET内では、リンクメトリックの単一の選択が使用されます。メトリックタイプのレジストリ（単一のアドレスブロックTLVタイプの拡張タイプを使用）を使用することにより、使用可能なメトリックタイプのサブセットのみを使用するようにルーターを構成できます。
o Node metrics were not included in OLSRv2. Node metrics can be implemented by the addition of the corresponding value to all incoming link metrics by the corresponding router.
o ノードメトリックはOLSRv2に含まれていませんでした。ノードメトリックは、対応するルーターによってすべての着信リンクメトリックに対応する値を追加することで実装できます。
o The separation of the two functions performed by multipoint relays (MPRs) in OLSRv1, optimized flooding and reduced topology advertisement for routing, into separate sets of MPRs in OLSRv2 [RFC7181], denoted "flooding MPRs" and "routing MPRs". Flooding MPRs can be calculated as in [RFC3626], but the use of link metrics in OLSRv2 can improve the MPR selection. Routing MPRs need a metric-aware selection algorithm. The selection of routing MPRs guarantees the use of minimum distance routes using the chosen metric, while using only symmetric 2-hop neighborhood information from HELLO messages and routing MPR selector information from TC messages.
o OLSRv1のマルチポイントリレー（MPR）によって実行される2つの機能の分離。フラッディングを最適化し、ルーティングのトポロジアドバタイズを削減して、「フラッディングMPR」と「ルーティングMPR」と呼ばれるOLSRv2 [RFC7181]の個別のMPRセットに分割します。フラッディングMPRは[RFC3626]のように計算できますが、OLSRv2でリンクメトリックを使用すると、MPR選択を改善できます。ルーティングMPRには、メトリック対応の選択アルゴリズムが必要です。ルーティングMPRを選択すると、HELLOメッセージからの対称2ホップ近隣情報とTCメッセージからのルーティングMPRセレクター情報のみを使用しながら、選択したメトリックを使用した最小距離ルートの使用が保証されます。
o The protocol Information Bases defined in OLSRv2 include required metric values. This has included additions to the protocol Information Bases defined in NHDP [RFC6130] when used by OLSRv2.
o OLSRv2で定義されているプロトコル情報ベースには、必要なメトリック値が含まれています。これには、OLSRv2で使用される場合、NHDP [RFC6130]で定義されたプロトコル情報ベースへの追加が含まれています。
All terms introduced in [RFC5444], including "message" and "TLV" (type-length-value), are to be interpreted as described there.
[message]や[TLV]（type-length-value）など、[RFC5444]で導入されたすべての用語は、そこで説明されているとおりに解釈されます。
All terms introduced in [RFC6130], including "MANET interface", "HELLO message", "heard", "link", "symmetric link", "1-hop neighbor", "symmetric 1-hop neighbor", "2-hop neighbor", "symmetric 2-hop neighbor", "symmetric 2-hop neighborhood", and the symbolic constants SYMMETRIC and HEARD, are to be interpreted as described there.
[RFC6130]で導入されたすべての用語。「MANETインターフェース」、「HELLOメッセージ」、「聞こえた」、「リンク」、「対称リンク」、「1ホップネイバー」、「対称1ホップネイバー」、「2-ホップネイバー」、「対称2ホップネイバー」、「対称2ホップネイバーフッド」、およびシンボリック定数SYMMETRICおよびHEARDは、そこで説明されているように解釈されます。
All terms introduced in [RFC7181], including "router", "OLSRv2 interface", "willingness", "multipoint relay (MPR)", "MPR selector", "MPR flooding", and the TLV type LINK_METRIC, are to be interpreted as described there.
[ルーター]、[OLSRv2インターフェース]、[意欲]、[マルチポイントリレー（MPR）]、[MPRセレクター]、[MPRフラッディング]、TLVタイプLINK_METRICなど、[RFC7181]で導入されたすべての用語は解釈されますそこに記載されています。
The objective of this document is to retain the design considerations behind how link metrics were included in [RFC7181]. This document does not prescribe any behavior but explains some aspects of the operation of OLSRv2.
このドキュメントの目的は、リンクメトリックが[RFC7181]にどのように含まれているかの背後にある設計上の考慮事項を保持することです。このドキュメントでは動作を規定していませんが、OLSRv2の操作のいくつかの側面について説明しています。
The basic situation that suggests the desirability of use of routes other than minimum hop routes is shown in Figure 1.
最小ホップルート以外のルートの使用が望ましいことを示唆する基本的な状況を図1に示します。
A ----- X ----- B
\ /
\ /
Y ------- Z
Figure 1
図1
The minimum hop route from A to B is via X. However, if the links A to X and X to B are poor (e.g., have low data rate or are unreliable) but the links A to Y, Y to Z, and Z to B are better (e.g., have reliable high data rate), then the route A to B via Y and Z may be preferred to that via X.
AからBへの最小ホップルートはXを経由します。ただし、リンクAからXおよびXからBが貧弱である（たとえば、データレートが低い、または信頼性が低い）場合、リンクAからY、YからZ、およびZからBへの経路の方が良い（たとえば、信頼性の高い高いデータレートを持っている）場合、YおよびZを経由する経路AからBは、Xを経由する経路よりも優先される場合があります。
There are other situations where the use of some links should be discouraged, even if the avoidance of them does not show immediately obvious benefits to users. Consider a network with many short-range links and a few long-range links. Use of minimum hop routes will immediately lead to heavy use of the long-range links. This will be particularly undesirable if those links achieve their longer range through reduced data rate or through being less reliable. However, even if the long-range links have the same characteristics as the short-range links, it may be better to reserve usage of the long-range links for when this usage is particularly valuable -- for example, when the use of one long-range link saves several short-range links, rather than the single link saving that is needed for a minimum hop route.
他の状況では、リンクを回避してもすぐにユーザーに明らかなメリットが得られない場合でも、一部のリンクの使用は推奨されません。多数の短距離リンクと少数の長距離リンクのあるネットワークを考えてみましょう。最小ホップルートを使用すると、すぐに長距離リンクが大量に使用されます。これらのリンクがデータレートの低下または信頼性の低下により長距離を達成する場合、これは特に望ましくありません。ただし、長距離リンクが短距離リンクと同じ特性を持っている場合でも、長距離リンクの使用が特に価値がある場合（たとえば、1つの長距離リンクは、最小ホップルートに必要な単一のリンクを節約するのではなく、いくつかの短距離リンクを節約します。
A related case is that of a privileged relay. An example is an aerial router in an otherwise ground-based network. The aerial router may have a link to many, or even all, other routers. That would lead to all routers attempting to send all their traffic (other than to symmetric 1-hop neighbors and some symmetric 2-hop neighbors) via the aerial router. It may, however, be important to reserve that capacity for cases where the aerial router is actually essential, such as if the ground-based portion of the network is not connected.
関連するケースは、特権リレーのケースです。例としては、地上ベースのネットワークの空中ルーターがあります。空中ルーターは、他の多くのルーターまたはすべてのルーターにリンクしている場合があります。これにより、すべてのルーターが（対称1ホップネイバーと一部の対称2ホップネイバー以外の）すべてのトラフィックを空中ルーター経由で送信しようとします。ただし、ネットワークの地上部分が接続されていない場合など、空中ルーターが実際に不可欠な場合のためにその容量を予約することが重要な場合があります。
Link metrics provide a possible solution to these scenarios. For example, in Figure 1, the route A to Y to Z to B could be preferred to A to X to B by making the metrics on the former path 1 and those on the latter path 2. The aerial privileged relay could be used only when necessary by giving its links maximal metric values, with much smaller other metric values or, if the aerial link is to be preferred to N ground links, by giving the ground links metric values of 1 while making the sum of the aerial node uplink and downlink metrics equal to N.
リンクメトリックは、これらのシナリオに対する可能な解決策を提供します。たとえば、図1では、前のパス1のメトリックと後者のパス2のメトリックを作成することにより、AからYからZからBへのルートがAからXからBよりも優先される可能性があります。必要に応じて、リンクに最大のメトリック値を与え、他のメトリック値をはるかに小さくするか、空中リンクをN個の地上リンクよりも優先する場合は、地上ノードのメトリック値を1にして空中ノードのアップリンクとNに等しいダウンリンクメトリック
Other cases may involve attempts to avoid areas of congestion, attempts to route around insecure routers, and attempts by routers to discourage being used as relays due to, for example, limited battery power. OLSRv2 does have another mechanism to aid in this: a router's willingness to act as an MPR. However, there are cases where that cannot help but where use of non-minimum hop routes could.
他のケースには、輻輳の領域を回避する試み、安全でないルーターを迂回する試み、およびバッテリーの電力制限などにより、ルーターがリレーとして使用されないようにする試みが含まれる場合があります。 OLSRv2には、これを支援する別のメカニズムがあります。それは、MPRとして機能するルーターの意思です。ただし、それが役に立たない場合がありますが、非最小ホップルートの使用が役立つ場合があります。
Similarly, note that OLSRv2's optional use of link quality (through its use of [RFC6130]) is not a solution to these problems. Use of link quality as specified in [RFC6130] allows a router to decline to use a link, not only on its own, but on all routers' behalf. It does not, for example, allow the use of a link otherwise determined to be too low quality to be generally useful as part of a route where no better links exist. These mechanisms (link quality and link metrics) solve distinctly different problems.
同様に、OLSRv2のオプションのリンク品質の使用（[RFC6130]の使用による）は、これらの問題の解決策ではないことに注意してください。 [RFC6130]で指定されているリンク品質を使用すると、ルーターは、それ自体だけでなく、すべてのルーターに代わってリンクの使用を拒否できます。たとえば、品質が低すぎると判断されたリンクを使用して、より良いリンクが存在しないルートの一部として一般的に使用することはできません。これらのメカニズム（リンク品質とリンクメトリック）は、明らかに異なる問題を解決します。
It should also be noted that the loop-free property of OLSRv2 applies strictly only in the static state. When the network topology is changing and when messages can be lost, it is possible for transient loops to form. However, with update rates appropriate to the rate of topology change, such loops will be sufficiently rare. Changing link metrics is a form of network topology change and should be limited to a rate slower than the message information update rate (defined by the parameters HELLO_INTERVAL, HELLO_MIN_INTERVAL, REFRESH_INTERVAL, TC_INTERVAL, and TC_MIN_INTERVAL).
OLSRv2のループフリープロパティは、静的な状態でのみ厳密に適用されることにも注意してください。ネットワークトポロジが変化し、メッセージが失われる可能性がある場合、一時的なループが形成される可能性があります。ただし、トポロジ変更の速度に適した更新速度では、このようなループは十分にまれです。リンクメトリックの変更は、ネットワークトポロジの変更の一種であり、メッセージ情報の更新レートよりも遅いレートに制限する必要があります（パラメータHELLO_INTERVAL、HELLO_MIN_INTERVAL、REFRESH_INTERVAL、TC_INTERVAL、およびTC_MIN_INTERVALで定義）。
This section describes the required and selected properties of the link metrics used in OLSRv2, followed by implementation details achieving those properties.
このセクションでは、OLSRv2で使用されるリンクメトリックの必須のプロパティと選択されたプロパティについて説明し、それらのプロパティを実現する実装の詳細を示します。
Link metrics in OLSRv2 are:
OLSRv2のリンクメトリックは次のとおりです。
o Dimensionless. While they may, directly or indirectly, correspond to specific physical information (such as delay, loss rate, or data rate), this knowledge is not used by OLSRv2. Instead, generating the metric value is the responsibility of a mechanism external to OLSRv2.
o 無次元。それらは直接的または間接的に特定の物理情報（遅延、損失率、データレートなど）に対応する場合がありますが、この知識はOLSRv2では使用されません。代わりに、メトリック値の生成は、OLSRv2の外部のメカニズムの責任です。
o Additive, so that the metric of a route is the sum of the metrics of the links forming that route. Note that this requires a metric where a low value of a link metric indicates a "good" link and a high value of a link metric indicates a "bad" link, and the former will be preferred to the latter.
o ルートのメトリックがそのルートを形成するリンクのメトリックの合計になるように、加算的。これには、リンクメトリックの低い値が「良い」リンクを示し、リンクメトリックの高い値が「悪い」リンクを示すメトリックが必要であり、前者が後者よりも優先されることに注意してください。
o Directional, the metric from router A to router B need not be the same as the metric from router B to router A, even when using the same OLSRv2 interfaces. At router A, a link metric from router B to router A is referred to as an incoming link metric, while a link metric from router A to router B is referred to as an outgoing link metric. (These are, of course, reversed at router B.)
o 方向性として、同じOLSRv2インターフェイスを使用している場合でも、ルータAからルータBへのメトリックは、ルータBからルータAへのメトリックと同じである必要はありません。ルータAでは、ルータBからルータAへのリンクメトリックは着信リンクメトリックと呼ばれ、ルータAからルータBへのリンクメトリックは発信リンクメトリックと呼ばれます。 （もちろん、これらはルーターBで反転されます。）
o Specific to a pair of OLSRv2 interfaces, so that if there is more than one link from router A to router B, each has its own link metric in that direction. There is also an overall metric, a "neighbor metric", from router A to router B (its 1-hop neighbor). This is the minimum value of the link metrics from router A to router B, considering symmetric links only; it is undefined if there are no such symmetric links. A neighbor metric from one router to another is always equal to a link metric in the same direction between OLSRv2 interfaces of those routers. When referring to a specific OLSRv2 interface (for example, in a Link Tuple or a HELLO message sent on that OLSRv2 interface), a link metric always refers to a link on that OLSRv2 interface to or from the indicated 1-hop neighbor OLSRv2 interface, while a neighbor metric may be equal to a link metric to and/or from another OLSRv2 interface.
o OLSRv2インターフェイスのペアに固有。これにより、ルーターAからルーターBへのリンクが複数ある場合、それぞれにその方向に独自のリンクメトリックがあります。ルーターAからルーターB（その1ホップのネイバー）までの全体的なメトリック、「ネイバーメトリック」もあります。これは、対称リンクのみを考慮した、ルーターAからルーターBへのリンクメトリックの最小値です。そのような対称リンクがない場合は未定義です。あるルーターから別のルーターへのネイバーメトリックは、それらのルーターのOLSRv2インターフェイス間の同じ方向のリンクメトリックに常に等しくなります。特定のOLSRv2インターフェイスを参照する場合（たとえば、リンクタプルまたはそのOLSRv2インターフェイスで送信されたHELLOメッセージで）、リンクメトリックは常に、指定された1ホップネイバーOLSRv2インターフェイスとの間のOLSRv2インターフェイス上のリンクを参照します。一方、ネイバーメトリックは、別のOLSRv2インターフェイスとの間のリンクメトリックに等しい場合があります。
There are various physical characteristics that may be used to define a link metric. Some examples, which also illustrate some characteristics of metrics that result, are:
リンクメトリックを定義するために使用できるさまざまな物理的特性があります。結果となるメトリックのいくつかの特性も示すいくつかの例は次のとおりです。
o Delay is a straightforward metric; as it is naturally additive, the delay of a multi-link route is the sum of the delays of the links. This does not directly take into account delays due to routers (such as due to router queues or transition of packets between router interfaces) rather than links, but these delays can be divided among incoming and outgoing links.
o 遅延は簡単なメトリックです。本来付加的であるため、マルチリンクルートの遅延はリンクの遅延の合計です。これは、リンクではなく、ルーターによる遅延（ルーターキューやルーターインターフェイス間のパケットの遷移など）による遅延を直接考慮していませんが、これらの遅延は着信リンクと発信リンクに分割できます。
o Probability of loss on a link is, as long as probabilities of loss are small and independent, approximately additive. (A slightly more accurate approach is using a negatively scaled logarithm of the probability of not losing a packet.) If losses are not independent, then this will be pessimistic.
o リンクの損失の確率は、損失の確率が小さく、独立している限り、ほぼ加算されます。 （少し正確なアプローチは、パケットを失わない確率の負のスケールの対数を使用しています。）損失が独立していない場合、これは悲観的です。
o Data rates are not additive. They even have the wrong characteristic of being good when high and bad when low; thus, a mapping that inverts the ordering must be applied. Such a mapping can, at best, only produce a metric that is acceptable to treat as additive. Consider, for example, a preference for a route that maximizes the minimum data rate link on the route and then prefers a route with the fewest links of each data rate from the lowest. If links may be of three discrete data rates, "high", "medium", and "low", then this preference can be achieved, on the assumption that no route will have more than 10 links, with metric values of 1, 10, and 100 for the three data rates.
o データレートは加算されません。彼らは、高いときは良く、低いときは悪いという間違った特徴さえ持っています。したがって、順序を逆にするマッピングを適用する必要があります。そのようなマッピングは、せいぜい、加法的として扱うのに受け入れられるメトリックのみを生成できます。たとえば、ルートの最小データレートリンクを最大化し、各データレートのリンクが最も少ないルートを最も低いルートを優先するルートの優先度を検討してください。リンクのデータレートが「高」、「中」、「低」の3つの場合、メトリック値が1、10のリンクが10を超えるルートはないという前提で、この設定を実現できます。 、および3つのデータレートの場合は100。
If routes can have more than 10 links, the range of metrics must be increased; this was one reason for a preference for a wide "dynamic range" of link metric values. Depending on the ratios of the numerical values of the three data rates, the same effect may be achieved by using a scaling of an inverse power of the numerical values of the data rates. For example, if the three data rates were 2, 5, and 10 Mbit/s, then a possible mapping would be the fourth power of 10 Mbit/s divided by the data rate, giving metric values of 625, 16, and 1 (good for up to 16 links in a route). This mapping can be extended to a system with more data rate values, for example, giving a 4 Mbit/s data rate a metric value of about 39. This may lose the capability to produce an absolutely maximal minimum data rate route but will usually produce either that, or something close (and at times maybe better, is a route of three 5 Mbit/s links really better than one of a single 4 Mbit/s link?). Specific metrics will need to define the mapping.
ルートに10を超えるリンクを含めることができる場合は、メトリックの範囲を増やす必要があります。これが、リンクメトリック値の広い「ダイナミックレンジ」を好む理由の1つでした。 3つのデータレートの数値の比率に応じて、データレートの数値の逆指数のスケーリングを使用することによって同じ効果を達成できます。たとえば、3つのデータレートが2、5、および10メガビット/秒の場合、可能なマッピングは、データレートで割った10メガビット/秒の4乗であり、メトリック値は625、16、および1（ルート内の最大16リンクに適しています）。このマッピングは、より多くのデータレート値を持つシステムに拡張できます。たとえば、4 Mbit / sデータレートに約39のメトリック値を与えます。これにより、絶対最大の最小データレートルートを生成する機能が失われる可能性がありますが、通常はそれか、近いもののどちらかです（場合によっては、3つの5 Mbit / sリンクのルートは、1つの4 Mbit / sリンクのルートよりも本当に優れていますか？）特定のメトリックは、マッピングを定義する必要があります。
There are also many other possible metrics, including using physical-layer information (such as signal-to-noise ratio and error-control statistics) and information such as packet-queuing statistics.
物理層情報（信号対雑音比やエラー制御統計など）やパケットキュー統計などの情報の使用を含む、他にも多くの可能なメトリックがあります。
In a well-designed network, all routers will use the same metric type. It will not produce good routes if, for example, some link metrics are based on data rate and some on path loss (except to the extent that these may be correlated). How to achieve this is an administrative matter, outside the scope of OLSRv2. In fact, even the actual physical meanings of the metrics is outside the scope of OLSRv2. This is because new metrics may be added in the future, for example, as data rates increase, and may be based on new, possibly non-physical, considerations, for example, financial cost. Each such type will have a metric type number. Initially, a single link metric type zero is defined as indicating a dimensionless metric with no predefined physical meaning.
適切に設計されたネットワークでは、すべてのルーターが同じメトリックタイプを使用します。たとえば、一部のリンクメトリックがデータレートに基づいており、一部がパス損失に基づいている場合（これらが相関している可能性がある範囲を除く）、適切なルートは生成されません。これを達成する方法は、OLSRv2の範囲外の管理上の問題です。実際、メトリックの実際の物理的な意味でさえ、OLSRv2の範囲外です。これは、たとえばデータレートの増加に伴い、新しいメトリックが将来追加される可能性があり、新しい、場合によっては非物理的な考慮事項、たとえば財務コストに基づく可能性があるためです。このような各タイプには、メトリックタイプ番号があります。最初は、単一のリンクメトリックタイプ0は、事前定義された物理的な意味のない無次元メトリックを示すものとして定義されています。
An OLSRv2 router is instructed which single link metric type to use and recognize, without knowing whether it represents delay, probability of loss, data rate, cost, or any other quantity. This recognized link metric type number is a router parameter and subject to change in case of reconfiguration or possibly the use of a protocol (outside the scope of OLSRv2) permitting a process of link metric type agreement between routers.
OLSRv2ルーターは、遅延、損失の確率、データレート、コスト、またはその他の数量を表すかどうかを知らなくても、どの単一リンクメトリックタイプを使用および認識するかを指示されます。この認識されたリンクメトリックタイプ番号はルーターのパラメーターであり、再構成の場合、またはルーター間でリンクメトリックタイプの合意のプロセスを許可するプロトコル（OLSRv2の範囲外）を使用する場合に変更される可能性があります。
The use of link metric type numbers also suggests the possibility of use of multiple link metric types and multiple network topologies. This is a possible future extension to OLSRv2. To allow for that future possibility, the sending of more than one metric of different physical types, which should otherwise not be done for reasons of efficiency, is not prohibited, but types other than that configured will be ignored.
リンクメトリックタイプ番号の使用は、複数のリンクメトリックタイプおよび複数のネットワークトポロジの使用の可能性も示唆しています。これは、OLSRv2の将来の拡張となる可能性があります。その将来の可能性に対応するために、効率の理由でそうでなければ実行されるべきではない、異なる物理タイプの複数のメトリックの送信は禁止されていませんが、構成されたタイプ以外のタイプは無視されます。
The following three sections assume a chosen single link metric type, of unspecified physical nature.
次の3つのセクションでは、物理的性質が指定されていない単一のリンクメトリックタイプが選択されていると想定しています。
OLSRv2 uses only "symmetric" (bidirectional) links, which may carry traffic in either direction. A key decision was whether these links should each be assigned a single metric, used in both directions, or a metric in each direction, noting that:
OLSRv2は「対称」（双方向）リンクのみを使用し、どちらの方向にもトラフィックを運ぶことができます。重要な決定は、これらのリンクのそれぞれに、両方向で使用される単一のメトリックを割り当てるか、または各方向のメトリックを割り当てるかどうかでした。
o Links can have different characteristics in each direction. Use of directional link metrics recognizes this.
o リンクは、方向ごとに異なる特性を持つことができます。方向性リンクメトリックの使用はこれを認識します。
o In many (possibly most) cases, the two ends of a link will naturally form different views as to what the link metric should be. To use a single link metric requires a coordination between the two that can be avoided if using directional metrics. Note that if using a single metric, it would be essential that the two ends agree as to its value; otherwise, it is possible for looping to occur. This problem does not occur for directional metrics.
o 多くの場合（ほとんどの場合）、リンクの両端は、リンクメトリックがどうあるべきかに関して異なるビューを自然に形成します。単一のリンクメトリックを使用するには、2つのリンクの調整が必要です。これは、方向性メトリックを使用する場合に回避できます。単一のメトリックを使用する場合は、その値について両端が一致することが重要です。そうしないと、ループが発生する可能性があります。この問題は、方向性メトリックでは発生しません。
Based on these considerations, directional metrics are used in OLSRv2. Each router must thus be responsible for defining the metric in one direction only. This could have been in either direction, i.e., a router is responsible for either incoming or outgoing link metrics, as long as the choice is universal. The former (incoming) case is used in OLSRv2 because, in general, receiving routers have more information available to determine link metrics (for example, received signal strength, interference levels, and error-control coding statistics).
これらの考慮事項に基づいて、方向性メトリックがOLSRv2で使用されます。したがって、各ルーターは、一方向にのみメトリックを定義する必要があります。これはどちらの方向でも可能でした。つまり、選択が普遍的である限り、ルータは着信または発信リンクメトリックのいずれかを担当します。前者の（受信）ケースはOLSRv2で使用されます。これは、一般に、受信ルーターがリンクメトリック（たとえば、受信信号強度、干渉レベル、エラー制御コーディング統計）を決定するために利用できる情報が多いためです。
Note that, using directional metrics, if router A defines the metric of the link from router B to router A, then router B must use router A's definition of that metric on that link in that direction. (Router B could, if appropriate, use a bad mismatch between directional metrics as a reason to discontinue use of this link, using the link quality mechanism defined in [RFC6130]; note that this is a distinct mechanism from the use of link metrics.)
方向メトリックを使用して、ルーターAがルーターBからルーターAへのリンクのメトリックを定義している場合、ルーターBは、その方向のリンクでルーターAのそのメトリックの定義を使用する必要があることに注意してください。 （ルーターBは、必要に応じて、[RFC6130]で定義されているリンク品質メカニズムを使用して、このリンクの使用を中止する理由として、方向メトリック間の悪い不一致を使用する可能性があります。これは、リンクメトリックの使用とは異なるメカニズムであることに注意してください。 ）
Links, and hence link metrics, are reported in HELLO messages. A router must report incoming link metrics in its HELLO messages in order for these link metrics to be available at the other end of the link. This means that, for a symmetric link, both ends of the link will know both of the incoming and outgoing link metrics.
リンク、つまりリンクメトリックは、HELLOメッセージで報告されます。ルーターは、これらのリンクメトリックをリンクの反対側で利用できるようにするために、HELLOメッセージで着信リンクメトリックを報告する必要があります。これは、対称リンクの場合、リンクの両端が着信リンクと発信リンクの両方のメトリックを認識することを意味します。
As well as advertising incoming link metrics, HELLO messages also advertise incoming neighbor metrics. These are used for routing MPR selection (see Section 6.2), which requires use of the lowest metric
着信リンクメトリックをアドバタイズするだけでなく、HELLOメッセージは着信ネイバーメトリックもアドバタイズします。これらは、MPR選択のルーティング（セクション6.2を参照）に使用され、最低のメトリックを使用する必要があります。
link between two routers when more than one link exists. This neighbor metric may be using another OLSRv2 interface, and hence, the link metric alone is insufficient.
複数のリンクが存在する場合の2つのルーター間のリンク。このネイバーメトリックは別のOLSRv2インターフェイスを使用している可能性があるため、リンクメトリックだけでは不十分です。
Metrics are also reported in TC messages. It can be shown that these need to be outgoing metrics:
指標はTCメッセージでも報告されます。これらは発信メトリックである必要があることを示すことができます。
o Router A must be responsible for advertising a metric from router A to router B in TC messages. This can be seen by considering a route connecting single OLSRv2 interface routers P to Q to R to S. Router P receives its only information about the link from R to S in the TC messages transmitted by router R, which is an MPR of router S (assuming that only MPR selectors are reported in TC messages). Router S may not even transmit TC messages (if no routers have selected it as an MPR and it has no attached networks to report). So any information about the metric of the link from R to S must also be included in the TC messages sent by router R; hence, router R is responsible for reporting the metric for the link from R to S.
o ルータAは、TCメッセージでルータAからルータBにメトリックをアドバタイズする必要があります。これは、単一のOLSRv2インターフェイスルーターPからQからRからSに接続するルートを検討することで確認できます。ルーターPは、ルーターSのMPRであるルーターRによって送信されたTCメッセージで、RからSへのリンクに関する唯一の情報を受信します。 （MPRセレクターのみがTCメッセージで報告されると仮定）。ルーターSはTCメッセージを送信しないこともあります（ルーターがMPRとして選択しておらず、レポートするネットワークが接続されていない場合）。したがって、RからSへのリンクのメトリックに関する情報も、ルーターRが送信するTCメッセージに含める必要があります。したがって、ルータRは、RからSへのリンクのメトリックを報告する責任があります。
o In a more general case, where there may be more than one link from R to S, the TC message must, so that minimum metric routes can be constructed (e.g., by router P), report the minimum of these outgoing link metrics, i.e., the outgoing neighbor metric from R to S.
o RからSへのリンクが複数存在する可能性があるより一般的なケースでは、TCメッセージは、最小メトリックルートを構築できるように（たとえば、ルーターPによって）、これらの発信リンクメトリックの最小値を報告する必要があります。 、RからSへの発信ネイバーメトリック。
In this example, router P also receives information about the existence of a link between Q and R in the HELLO messages sent by router Q. Without the use of metrics, this link could be used by OLSRv2 for 2-hop routing to router R, using just HELLO messages sent by router Q. For this property (which accelerates local route formation) to be retained (from OLSRv1), router P must receive the metric from Q to R in HELLO messages sent by router Q. This indicates that router Q must be responsible for reporting the metric for the outgoing link from Q to R. This is in addition to the incoming link metric information that a HELLO message must report. Again, in general, this must be the outgoing neighbor metric, rather than the outgoing link metric.
この例では、ルーターPは、ルーターQによって送信されたHELLOメッセージでQとRの間のリンクの存在に関する情報も受信します。メトリックを使用せずに、このリンクをOLSRv2がルーターRへの2ホップルーティングに使用できます。ルーターQから送信されたHELLOメッセージのみを使用します。このプロパティ（ローカルルートの形成を加速する）を（OLSRv1から）保持するには、ルーターPがルーターQから送信されたHELLOメッセージでQからRまでのメトリックを受信する必要があります。これは、ルーターQ QからRへの発信リンクのメトリックを報告する責任があります。これは、HELLOメッセージが報告する必要がある着信リンクメトリック情報に追加されます。繰り返しますが、これは一般に、発信リンクメトリックではなく、発信ネイバーメトリックである必要があります。
In addition, Section 6.1 offers an additional reason for reporting outgoing neighbor metrics in HELLO messages, without which metrics can properly affect only routing, not flooding.
さらに、セクション6.1は、HELLOメッセージで発信ネイバーメトリックを報告する追加の理由を提供します。これらのメトリックがないと、メトリックはルーティングのみに影響し、フラッディングには影響しません。
Note that there is no need to report an outgoing link metric in a HELLO message. The corresponding 1-hop neighbor knows that value; it specified it. Furthermore, for 2-hop neighborhood use, neighbor metrics are required (as these will, in general, not use the same OLSRv2 interface).
HELLOメッセージで発信リンクメトリックを報告する必要がないことに注意してください。対応する1ホップのネイバーはその値を知っています。それを指定しました。さらに、2ホップネイバーフッドを使用するには、ネイバーメトリックが必要です（これらは通常、同じOLSRv2インターフェイスを使用しないため）。
When a router reports a 1-hop neighbor in a HELLO message, it may do so for the first time with link status HEARD. As the router is responsible for defining and reporting incoming link metrics, it must evaluate that metric and attach that link metric to the appropriate address (which will have link status HEARD) in the next HELLO message reporting that address on that OLSRv2 interface. There will, at this time, be no outgoing link metric available to report, but a router must be able to immediately decide on an incoming link metric once it has heard a 1-hop neighbor on an OLSRv2 interface for the first time.
ルーターがHELLOメッセージで1ホップのネイバーを報告するとき、リンクステータスHEARDで初めてそれを行うことがあります。ルーターは着信リンクメトリックの定義と報告を担当するため、そのメトリックを評価し、そのOLSRv2インターフェイスでそのアドレスを報告する次のHELLOメッセージで、そのリンクメトリックを適切なアドレス（リンクステータスはHEARDになります）にアタッチする必要があります。現時点では、レポートに使用できる発信リンクメトリックはありませんが、ルータは、OLSRv2インターフェイスで1ホップネイバーを初めて聞いた後、着信リンクメトリックをすぐに決定できる必要があります。
This is because, when receiving a HELLO message from this router, the 1-hop neighbor seeing its own address listed with link status HEARD will (unless the separate link quality mechanism indicates otherwise) immediately consider that link to be SYMMETRIC, advertise it with that link status in future HELLO messages, and use it (for MPR selection and data traffic forwarding).
これは、このルーターからHELLOメッセージを受信すると、リンクステータスがHEARDでリストされた自身のアドレスを確認する1ホップネイバーは、（別のリンク品質メカニズムが別の方法で示していない限り）リンクがSYMMETRICであるとすぐに見なし、それをアドバタイズするためです今後のHELLOメッセージでステータスをリンクし、それを使用します（MPR選択およびデータトラフィック転送用）。
It may, depending on the physical nature of the link metric, be too early for an ideal decision as to that metric; however, a choice must be made. The metric value may later be refined based on further observation of HELLO messages, other message transmissions between the routers, or other observations of the environment. It will probably be best to over-estimate the metric if initially uncertain as to its value, to discourage, rather than over-encourage, its use. If no information other than the receipt of the HELLO message is available, then a conservative maximum link metric value, denoted MAXIMUM_METRIC in [RFC7181], should be used.
リンクメトリックの物理的な性質によっては、そのメトリックに関する理想的な決定には早すぎる場合があります。ただし、選択を行う必要があります。メトリック値は、HELLOメッセージのさらなる観察、ルーター間の他のメッセージ送信、または環境の他の観察に基づいて、後で調整される場合があります。その値について最初に不確かな場合は、その使用を過度に奨励するのではなく阻止するために、メトリックを過大に見積もるのがおそらく最善でしょう。 HELLOメッセージの受信以外の情報がない場合は、[RFC7181]でMAXIMUM_METRICと示されている控えめな最大リンクメトリック値を使用する必要があります。
Link metric values are recorded in LINK_METRIC TLVs, defined in [RFC7181], using a compressed (lossy) representation that occupies 12 bits. The use of 12 bits is convenient because, when combined with 4 flag bits of additional information, described below, this results in a 2-octet value field. However, the use of 12 bits, and thus the availability of 4 flag bits, was a consequence of a design to use a modified exponent/mantissa form with the following characteristics:
リンクメトリック値は、[RFC7181]で定義されているLINK_METRIC TLVに記録され、12ビットを占める圧縮（損失）表現を使用します。 12ビットの使用は便利です。これは、以下で説明する4フラグビットの追加情報と組み合わせると、2オクテットの値フィールドが生成されるためです。ただし、12ビットの使用、つまり4つのフラグビットを使用できるようになったのは、次の特性を持つ変更された指数/仮数形式を使用する設計の結果です。
o The values represented are to be positive integers starting 1, 2, ...
o 表示される値は、1、2、...から始まる正の整数です。
o The maximum value represented should be close to, but less than 2^24 (^ denotes exponentiation in this section). This is so that with a route limited to no more than 255 hops, the maximum route metric is less than 2^32, i.e., can be stored in 32 bits. (The link metric value can be stored in 24 bits.)
o 表示される最大値は2 ^ 24に近いが、2 ^ 24未満である必要があります（^は、このセクションでは指数を示します）。これは、ルートが255ホップ以下に制限されている場合、最大ルートメトリックが2 ^ 32未満、つまり32ビットで格納できるようにするためです。 （リンクメトリック値は24ビットで保存できます。）
A representation that is modified from an exponent/mantissa form with e bits of exponent and m bits of mantissa and that has the first of these properties is one that starts at 1, then is incremented by 1 up to 2^m, then has a further 2^m increments by 2, then a further 2^m increments by 4, and so on for 2^e sets of increments. This means that the represented value is never in error by more than a half (if rounding) or one (if truncating) part in 2^m, usually less.
指数/仮数形式からeビットの指数とmビットの仮数で変更され、これらのプロパティの最初のものは1から始まり、1ずつ2 ^ mまでインクリメントされ、次にさらに2 ^ mは2ずつ増加し、さらに2 ^ mは4ずつ増加し、2 ^ eの増分セットについても同様です。これは、表現された値が2 ^ mの半分（丸めの場合）または1（切り捨ての場合）を超えてエラーになることはないことを意味します。
The position in the increment sequence, from 0 to 2^m-1, is considered as a form of mantissa and denoted a. The increment sequence number, from 0 to 2^e-1, is considered as a form of exponent and denoted b.
0から2 ^ m-1までの増分シーケンスの位置は、仮数の形式と見なされ、aで示されます。 0から2 ^ e-1までの増分シーケンス番号は、指数の形式と見なされ、bで示されます。
The value represented by (b,a) can then be shown to be equal to (2^m+a+1)2^b-2^m. To verify this, note that:
（b、a）で表される値は、（2 ^ m + a + 1）2 ^ b-2 ^ mに等しいことを示すことができます。これを確認するには、次の点に注意してください。
o With fixed b, the difference between two values with consecutive values of a is 2^b, as expected.
o 固定bでは、期待どおり、aの連続する値を持つ2つの値の差は2 ^ bです。
o The value represented by (b,2^m-1) is (2^m+2^m)2^b-2^m. The value represented by (b+1,0) is (2^m+1)(2^(b+1))-2^m. The difference between these two values is 2^(b+1), as expected.
o （b、2 ^ m-1）で表される値は（2 ^ m + 2 ^ m）2 ^ b-2 ^ mです。 （b + 1,0）で表される値は（2 ^ m + 1）（2 ^（b + 1））-2 ^ mです。予想どおり、これら2つの値の差は2 ^（b + 1）です。
The maximum represented value has b = 2^e-1 and a = 2^m-1 and is (2^m+2^m)(2^(2^e-1))-2^m = 2^(2^e+m)-2^m. This is slightly less than 2^(2^e+m). The required 24-bit limit can be achieved if 2^e+m = 24. Of the possible (e,m) pairs that satisfy this equation, the pair e = 4, m = 8 was selected as most appropriate and is that used by OLSRv2. It uses the previously indicated e+m = 12 bits. An algorithm for converting from a 24-bit value v to a 12-bit pair (b,a) is given in Section 6.2 of [RFC7181].
表現された最大値はb = 2 ^ e-1およびa = 2 ^ m-1で、（2 ^ m + 2 ^ m）（2 ^（2 ^ e-1））-2 ^ m = 2 ^（ 2 ^ e + m）-2 ^ m。これは2 ^（2 ^ e + m）より少し少ないです。必要な24ビットの制限は、2 ^ e + m = 24の場合に達成できます。この方程式を満たす可能な（e、m）ペアのうち、e = 4、m = 8のペアが最も適切に選択され、使用されています。 OLSRv2による。前に示したe + m = 12ビットを使用します。 24ビットの値vから12ビットのペア（b、a）に変換するアルゴリズムは、[RFC7181]のセクション6.2に記載されています。
As noted above, the 12-bit representation then shares two octets with 4 flag bits. Putting the flag bits first, it is then natural to put the exponent bits in the last four bits of the first octet and to put the mantissa bits in the second octet. The 12 consecutive bits, using network byte order (most significant octet first), then represent 256b+a. Note that the ordering of these 12-bit representation values is the same as the ordering of the 24-bit metric values. In other words, two 12-bit metrics fields can be compared for equality/ordering as if they were unsigned integers.
上記のように、12ビットの表現は、2つのオクテットと4つのフラグビットを共有します。フラグビットを最初に置くと、最初のオクテットの最後の4ビットに指数ビットを置き、2番目のオクテットに仮数ビットを置くのが自然になります。次に、ネットワークバイトオーダー（最上位オクテットが最初）を使用する12ビットが連続し、256b + aを表します。これらの12ビット表現値の順序は、24ビットメトリック値の順序と同じであることに注意してください。つまり、2つの12ビットメトリックフィールドは、あたかも符号なし整数であるかのように、等価性/順序付けを比較できます。
The four flag bits each represent one kind of metric, defined by its direction (incoming or outgoing) and whether the metric is a link metric or a neighbor metric. As indicated by the flag bits set, a metric value may be of any combination of these four kinds of metric.
4つのフラグビットはそれぞれ、1種類のメトリックを表し、その方向（受信または送信）と、メトリックがリンクメトリックかネイバーメトリックかによって定義されます。設定されたフラグビットで示されるように、メトリック値はこれらの4種類のメトリックの任意の組み合わせになります。
MPRs are used for two purposes in OLSRv2. In both cases, it is MPR selectors that are actually used, MPR selectors being determined from MPRs advertised in HELLO messages.
MPRは、OLSRv2で2つの目的に使用されます。どちらの場合も、実際に使用されるのはMPRセレクターです。MPRセレクターは、HELLOメッセージでアドバタイズされるMPRから決定されます。
o Optimized Flooding. This uses the MPR selector status of symmetric 1-hop neighbor routers from which messages are received in order to determine if these messages are to be forwarded. MPR selector status is recorded in the Neighbor Set (defined in [RFC6130] and extended in [RFC7181]) and determined from received HELLO messages.
o 最適化されたフラッディング。これは、これらのメッセージが転送されるかどうかを決定するために、メッセージの受信元である対称1ホップネイバールータのMPRセレクタステータスを使用します。 MPRセレクターのステータスは（[RFC6130]で定義され、[RFC7181]で拡張された）隣接セットに記録され、受信したHELLOメッセージから判別されます。
o Routing. Non-local link information is based on information recorded in this router's Topology Information Base. That information is based on received TC messages. The neighbor information in these TC messages consists of addresses of the originating router's advertised (1-hop) neighbors, as recorded in that router's Neighbor Set (defined in [RFC6130] and extended in [RFC7181]). These advertised neighbors include all of the MPR selectors of the originating router.
o ルーティング。非ローカルリンク情報は、このルーターのトポロジ情報ベースに記録された情報に基づいています。その情報は、受信したTCメッセージに基づいています。これらのTCメッセージのネイバー情報は、そのルーターのネイバーセット（[RFC6130]で定義され、[RFC7181]で拡張）に記録されている、発信元ルーターのアドバタイズされた（1ホップ）ネイバーのアドレスで構成されます。これらのアドバタイズされたネイバーには、発信元ルータのすべてのMPRセレクタが含まれています。
Metrics interact with these two uses of MPRs differently, as described in the following two sections. This leads to the requirement for two separate sets of MPRs for these two uses when using metrics. The relationship between these two sets of MPRs is considered in Section 6.3.
次の2つのセクションで説明するように、メトリックはこれらの2つのMPRの使用とは異なる方法で相互作用します。これにより、メトリックを使用する場合、これらの2つの用途のために2つの別個のMPRセットが必要になります。これら2つのMPRセットの関係については、セクション6.3で検討します。
The essential detail of the "flooding MPR" selection specification is that a router must select a set of MPRs such that a message transmitted by a router and retransmitted by all its flooding MPRs will reach all of the selecting router's symmetric 2-hop neighbors.
「フラッディングMPR」選択仕様の本質的な詳細は、ルーターが一連のMPRを選択して、ルーターによって送信され、そのすべてのフラッディングMPRによって再送信されるメッセージが、選択ルーターの対称2ホップネイバーすべてに到達するようにすることです。
Flooding MPR selection can ignore metrics and produce a solution that meets the required specification. However, that does not mean that metrics cannot be usefully considered in selecting flooding MPRs. Consider the network in Figure 2, where numbers are metrics of links in the direction away from router A, towards router D.
フラッディングMPRの選択では、メトリックを無視して、必要な仕様を満たすソリューションを生成できます。ただし、これは、フラッディングMPRを選択するときにメトリックを有効に検討できないことを意味するものではありません。図2のネットワークについて考えてみます。ここで、数値はルーターAからルーターDに向かう方向のリンクのメトリックです。
3
A ----- B
| |
1 | | 1
| |
C ----- D
4
Figure 2
図2
Which is the better flooding MPR selection by router A: B or C? If the metric represents probability of message loss, then clearly choosing B maximizes the probability of a message sent by A reaching D. This is despite C having a lower metric in its connection to A than B does. (Similar arguments about a preference for B can be made if, for example, the metric represents data rate or delay rather than probability of loss.)
ルーターAによるフラッディングMPR選択は、B、Cのどちらが適切ですか。メトリックがメッセージ損失の確率を表す場合、Bを選択すると、Aから送信されたメッセージがDに到達する確率が最大になります。これは、CがAへの接続においてBよりも低いメトリックを持っているにもかかわらずです。 （たとえば、メトリックが損失の確率ではなくデータレートまたは遅延を表す場合、Bの設定に関する同様の議論を行うことができます。）
However, neither should only the second hop be considered. If this example is modified to that in Figure 3, where the numbers still are metrics of links in the direction away from router A, towards router D, then it is possible that, when A is selecting flooding MPRs, selecting C is preferable to selecting B.
ただし、セカンドホップだけを考慮すべきではありません。この例を図3のように変更すると、番号は依然としてルーターAからルーターDに向かう方向のリンクのメトリックであり、AがフラッディングMPRを選択しているときに、CよりもCを選択する方が望ましい場合があります。 Ｂ．
3
A ----- B
| |
1 | | 3
| |
C ----- D
4
Figure 3
図3
If the metrics represent scaled values of delay or the probability of loss, then selecting C is clearly better. This indicates that the sum of metrics is an appropriate measure to use to choose between B and C.
メトリックが遅延のスケーリングされた値または損失の確率を表す場合、Cを選択するほうが明らかに優れています。これは、メトリックの合計がBとCのどちらかを選択するために使用する適切な尺度であることを示しています。
However, this is a particularly simple example. Usually, it is not a simple choice between two routers as a flooding MPR, each only adding one router coverage. When considering which router to next add as a flooding MPR, a more general process should incorporate the metric to that router and the metric from that router to each symmetric 2-hop neighbor as well as the number of newly covered symmetric 2-hop neighbors. Other factors may also be included.
ただし、これは特に単純な例です。通常、フラッディングMPRとして2つのルーターを選択するのは簡単ではなく、それぞれが1つのルーターカバレッジを追加するだけです。次にフラッディングMPRとして追加するルーターを検討する場合、より一般的なプロセスでは、そのルーターへのメトリックと、そのルーターから各対称2ホップネイバーへのメトリック、および新しくカバーされる対称2ホップネイバーの数を組み込む必要があります。他の要因も含まれる場合があります。
The required specification for flooding MPR selection is in Section 18.4 (also using Section 18.3) of [RFC7181], which may use the example MPR selection algorithm in Appendix B of [RFC7181]. However, note that (as in [RFC3626]) each router can make its own independent choice of flooding MPRs, and flooding MPR selection algorithm, and still interoperate.
フラッディングMPR選択に必要な仕様は、[RFC7181]のセクション18.4（これもセクション18.3を使用）にあり、[RFC7181]の付録BのサンプルMPR選択アルゴリズムを使用する場合があります。ただし、（[RFC3626]のように）各ルーターは、フラッディングMPRとフラッディングMPR選択アルゴリズムを独自に選択し、相互運用できることに注意してください。
Also note that the references above to the direction of the metrics is correct: for flooding, directional metrics outward from a router are appropriate, i.e., metrics in the direction of the flooding. This is an additional reason for including outward metrics in HELLO messages, as otherwise a metric-aware MPR selection for flooding is not possible. The second-hop metrics are outgoing neighbor metrics because the OLSRv2 interface used for a second-hop transmission may not be the same as that used for the first-hop reception.
また、上記のメトリックの方向への参照は正しいことに注意してください。フラッディングの場合、ルーターから外側に向かう方向のメトリック、つまりフラッディングの方向のメトリックが適切です。これは、HELLOメッセージに外部メトリックを含める追加の理由です。それ以外の場合は、フラッディングに対してメトリック対応のMPRを選択することはできません。 2番目のホップのメトリックは、2番目のホップの送信に使用されるOLSRv2インターフェイスが1番目のホップの受信に使用されるものと同じではない場合があるため、発信ネイバーメトリックです。
The essential detail of the "routing MPR" selection specification is that a router must, per OLSRv2 interface, select a set of MPRs such that there is a 2-hop route from each symmetric 2-hop neighbor of the selecting router to the selecting router, with the intermediate router on each such route being a routing MPR of the selecting router.
「ルーティングMPR」選択仕様の本質的な詳細は、ルーターが、OLSRv2インターフェイスごとに、選択ルーターの対称2ホップネイバーから選択ルーターへの2ホップルートが存在するようにMPRのセットを選択する必要があることです。 、このような各ルートの中間ルーターは、選択ルーターのルーティングMPRです。
It is sufficient, when using an additive link metric rather than a hop count, to require that these routing MPRs provide not just a 2-hop route but a minimum distance 2-hop route. In addition, a router is a symmetric 2-hop neighbor even if it is a symmetric 1-hop neighbor, as long as there is a 2-hop route from it that is shorter than the 1-hop link from it. (The property that no routes go through routers with willingness WILL_NEVER is retained. Examples below assume that all routers are equally willing, with none having willingness WILL_NEVER.)
ホップカウントではなく追加のリンクメトリックを使用する場合、これらのルーティングMPRが2ホップルートだけでなく、最小距離の2ホップルートも提供することを要求すれば十分です。さらに、ルーターは、1ホップリンクより短い2ホップルートがある限り、対称1ホップネイバーであっても対称2ホップネイバーです。 （ルートが意欲WILL_NEVERのルーターを通過しないという特性は保持されます。以下の例では、意欲のWILL_NEVERがないルーターはすべて意欲的であると想定しています。）
For example, consider the network in Figure 4. Numbers are metrics of links in the direction towards router A, away from router D. Router A must pick router B as a routing MPR, whereas for minimum hop count routing, it could alternatively pick router C. Note that the use of incoming neighbor metrics in this case follows the same reasoning as for the directionality of metrics in TC messages, as described in Section 5.4.
たとえば、図4のネットワークについて考えてみましょう。数値は、ルーターDから離れたルーターAに向かう方向のリンクのメトリックです。ルーターAはルーターBをルーティングMPRとして選択する必要がありますが、最小ホップカウントルーティングの場合は、代わりにルーターを選択できます。 C.この場合の着信ネイバーメトリックの使用は、セクション5.4で説明されているように、TCメッセージのメトリックの方向性と同じ推論に従うことに注意してください。
2
A ----- B
| |
1 | | 1
| |
C ----- D
3
Figure 4
図4
In Figure 5, where numbers are metrics of links in the direction towards router A and away from router C, router A must pick router B as a routing MPR, but for minimum hop count routing, it would not need to pick any MPRs.
図5では、数値はルーターAに向かう方向とルーターCから離れる方向のリンクのメトリックであり、ルーターAはルーターBをルーティングMPRとして選択する必要がありますが、最小ホップカウントルーティングの場合、MPRを選択する必要はありません。
1
A - B
\ |
4 \ | 2
\|
C
Figure 5
図5
In Figure 6, where numbers are metrics of links in the direction towards router A and away from routers D and E, router A must pick both routers B and C as routing MPRs, but for minimum hop count routing, it could pick either.
図6では、数値はルーターAに向かう方向とルーターDおよびEから離れる方向のリンクのメトリックであり、ルーターAはルーターBとCの両方をルーティングMPRとして選択する必要がありますが、最小ホップカウントルーティングの場合はどちらかを選択できます。
D E
|\ /|
| \ 3 / |
| \ / |
1 | \/ | 1
| /\ |
| / \ |
| / 2 \ |
|/ \|
B C
\ |
\ /
3 \ / 2
\ /
A
Figure 6
図6
It is shown in Appendix A that selecting routing MPRs according to this definition and advertising only such links (plus knowledge of local links from HELLO messages) will result in selection of lowest total metric routes, even if all links (advertised or not) are considered in the definition of a shortest route.
付録Aに示されているように、この定義に従ってルーティングMPRを選択し、そのようなリンク（HELLOメッセージからのローカルリンクの知識）のみをアドバタイズすると、すべてのリンク（アドバタイズされているかどうかにかかわらず）が考慮されても、メトリックルートの合計が最も低く選択されます。最短ルートの定義で。
However, the definition noted above as sufficient for routing MPR selection is not necessary. For example, consider the network in Figure 7, where numbers are metrics of links in the direction towards router A, away from other routers; the metrics from B to C and C to B are both assumed to be 2.
ただし、MPR選択のルーティングに十分であると上記で定義されている定義は必要ありません。たとえば、図7のネットワークについて考えてみます。ここで、数値は、他のルーターから離れたルーターAに向かう方向のリンクのメトリックです。 BからCおよびCからBまでのメトリックは両方とも2であると想定されます。
1
A ----- B
\ /
4 \ / 2
\ /
C ----- D ----- E
3 5
Figure 7
図7
Using the above definition, A must pick both B and C as routing MPRs, in order to cover the symmetric 2-hop neighbors C and D, respectively. (C is a symmetric 2-hop neighbor because the route length via B is shorter than the 1-hop link.)
上記の定義を使用すると、対称的な2ホップのネイバーCとDをそれぞれカバーするために、AはBとCの両方をルーティングMPRとして選択する必要があります。 （B経由のルート長が1ホップリンクよりも短いため、Cは対称2ホップネイバーです。）
However, A only needs to pick B as a routing MPR, because the only reason to pick C as a routing MPR would be so that C can advertise the link to A for routing -- to be used by, for example, E. However, A knows that no other router should use the link C to A in a shortest route because routing via B is shorter. So, if there is no need to advertise the link from C to A, then there is no reason for A to select C as a routing MPR.
ただし、CをルーティングMPRとして選択する唯一の理由は、CがAへのリンクをルーティングのためにアドバタイズするため、たとえば、Eによって使用されるためです。 、Aは、B経由のルーティングが短いため、他のルーターが最短ルートでAへのリンクCを使用すべきでないことを知っています。したがって、リンクをCからAにアドバタイズする必要がない場合、AがルーティングMPRとしてCを選択する理由はありません。
This process of "thinning out" the routing MPR selection uses only local information from HELLO messages. Using any minimum distance algorithm, the router identifies shortest routes, whether one, two, or more hops, from all routers in its symmetric 2-hop neighborhood. It then selects as MPRs all symmetric 1-hop neighbors that are the last router (before the selecting router itself) on any such route. Where there is more than one shortest distance route from a router, only one such route is required. Alternative routes may be selected so as to minimize the number of last routers -- this is the equivalent to the selection of a minimal set of MPRs in the non-metric case.
ルーティングMPR選択を「間引く」このプロセスは、HELLOメッセージからのローカル情報のみを使用します。ルーターは、最小距離アルゴリズムを使用して、対称的な2ホップの近隣にあるすべてのルーターからのホップを、1ホップ、2ホップ、またはそれ以上の最短ルートで識別します。次に、そのようなルートの最後のルーター（選択ルーター自体の前）であるすべての対称1ホップネイバーをMPRとして選択します。ルーターからの最短距離の経路が複数ある場合、そのような経路は1つだけ必要です。最後のルーターの数を最小限に抑えるために代替ルートを選択できます。これは、非メトリックの場合のMPRの最小セットの選択と同等です。
Note that this only removes routing MPRs whose selection can be directly seen to be unnecessary. Consequently, if (as is shown in Appendix A) the first approach creates minimum distance routes, then so does this process.
これは、選択が直接不要であることがわかるルーティングMPRのみを削除することに注意してください。したがって、（付録Aに示すように）最初のアプローチで最小距離のルートが作成される場合、このプロセスも作成されます。
The examples in Figures 5 and 6 show that use of link metrics may require a router to select more routing MPRs than when not using metrics and even require a router to select routing MPRs when, without metrics, it would not need any routing MPRs. This may result in more, and larger, messages being generated and forwarded more often. Thus, the use of link metrics is not without cost, even excluding the cost of link metric signaling.
図5および6の例は、リンクメトリックを使用すると、ルーターがメトリックを使用しない場合よりも多くのルーティングMPRを選択する必要があり、メトリックがなければルーティングMPRが不要な場合に、ルーターがルーティングMPRを選択する必要さえあることを示しています。これにより、より多くのより大きなメッセージが生成され、より頻繁に転送される可能性があります。したがって、リンクメトリックシグナリングのコストを除外しても、リンクメトリックの使用にはコストがないわけではありません。
These examples consider only single OLSRv2 interface routers. However, if routers have more than one OLSRv2 interface, then the process is unchanged; other than that, if there is more than one known metric between two routers (on different OLSRv2 interfaces), then, considering symmetric links only (as only these are used for routing) the smallest link metric, i.e., the neighbor metric, is used. There is no need to calculate routing MPRs per OLSRv2 interface. That requirement results from the consideration of flooding and the need to avoid certain "race" conditions, which are not relevant to routing, only to flooding.
これらの例では、単一のOLSRv2インターフェイスルータのみを考慮しています。ただし、ルーターに複数のOLSRv2インターフェイスがある場合、プロセスは変更されません。それ以外の場合、（異なるOLSRv2インターフェイス上の）2つのルーター間に既知のメトリックが複数ある場合は、対称リンクのみを考慮し（ルーティングにのみ使用されるため）、最小のリンクメトリック、つまりネイバーメトリックが使用されます。 。 OLSRv2インターフェイスごとにルーティングMPRを計算する必要はありません。この要件は、フラッディングを考慮し、ルーティングに関係のない特定の「競合」状態を回避する必要があるために発生し、フラッディングにのみ関係します。
The required specification for routing MPR selection is in Section 18.5 (also using Section 18.3) of [RFC7181], which may use the example MPR selection algorithm in Appendix B of [RFC7181]. However, note that (as in [RFC3626]) each router can make its own independent choice of routing MPRs, and routing MPR selection algorithm, and still interoperate.
MPR選択のルーティングに必要な仕様は、[RFC7181]のセクション18.5（セクション18.3も使用）にあり、[RFC7181]の付録BのMPR選択アルゴリズムの例を使用する場合があります。ただし、（[RFC3626]のように）各ルーターは、ルーティングMPRとルーティングMPR選択アルゴリズムを独自に選択し、相互運用できることに注意してください。
It would be convenient if the two sets of flooding and routing MPRs were the same. This can be the case if all metrics are equal, but in general, for "good" sets of MPRs, they are not. (A reasonable definition of this is that there is no common minimal set of MPRs.) If metrics are asymmetrically valued (the two sets of MPRs use opposite direction metrics) or routers have multiple OLSRv2 interfaces (where routing MPRs can ignore this but flooding MPRs cannot), this is particularly unlikely. However, even using a symmetrically valued metric with a single OLSRv2 interface on each router, the ideal sets need not be equal, nor is one always a subset of the other. To show this, consider these examples, where all lettered routers are assumed equally willing to be MPRs, and numbers are bidirectional metrics for links.
2セットのフラッディングMPRとルーティングMPRが同じであると便利です。これは、すべてのメトリックが等しい場合に当てはまる可能性がありますが、一般的には、MPRの「良好な」セットの場合は異なります。 （これの合理的な定義は、MPRの共通の最小セットがないということです。）メトリックが非対称に評価される（MPRの2つのセットが反対方向のメトリックを使用する）か、ルーターに複数のOLSRv2インターフェイスがある場合（ルーティングMPRはこれを無視できますが、MPRをフラッディングします）できない）、これは特にありそうもない。ただし、各ルーターで単一のOLSRv2インターフェイスを使用して対称的に評価されるメトリックを使用する場合でも、理想的なセットは等しい必要はなく、常に一方が他方のサブセットである必要もありません。これを示すために、これらの例を検討してください。ここでは、すべての文字付きルーターがMPRを同等に受け入れると想定され、数値はリンクの双方向メトリックです。
In Figure 8, A does not require any flooding MPRs. However, A must select B as a routing MPR.
図8では、AはフラッディングMPRを必要としません。ただし、AはルーティングMPRとしてBを選択する必要があります。
1
A - B
\ |
4 \ | 2
\|
C
Figure 8
図8
In Figure 9, A must select C and D as routing MPRs. However, A's minimal set of flooding MPRs is just B. In this example, the set of routing MPRs serves as a set of flooding MPRs, but a non-minimal one (although one that might be better, depending on the relative importance of number of MPRs and flooding link metrics).
図9では、AはルーティングMPRとしてCとDを選択する必要があります。ただし、AのフラッディングMPRの最小セットは単なるBです。この例では、ルーティングMPRのセットはフラッディングMPRのセットとして機能しますが、非最小MPRは（数の相対的な重要性に応じて、より優れている可能性があります） MPRとフラッディングリンクメトリックの）。
2
C --- E
/ /
1 / / 1
/ 4 /
A --- B
\ \
1 \ \ 1
\ \
D --- F
2
Figure 9
図9
However, this is not always the case. In Figure 10, A's set of routing MPRs must contain B but need not contain C. A's set of flooding MPRs need not contain B but must contain C. (In this case, flooding with A selecting B rather than C as a flooding MPR will reach D but in three hops rather than the minimum two that MPR flooding guarantees.)
ただし、これは常に当てはまるわけではありません。図10では、AのルーティングMPRセットにはBが含まれている必要がありますが、Cは含まれている必要はありません。AのフラッディングMPRセットにはBが含まれている必要はなく、Cが含まれている必要があります（この場合、フラッディングMPRとして、CではなくBを選択して、Aでフラッディングします。 Dに到達するが、MPRフラッディングが保証する最小2つではなく3つのホップで）
2 1
B - C - D
| /
1 | / 4
|/
A
Figure 10
図10
An attacker can have an adverse impact on an OLSRv2 network by creating apparently valid messages that contain incorrect link metrics. This could take the form of influencing the choice of routes or, in some cases, producing routing loops. This is a more subtle, and likely to be less effective, attack than other forms of invalid message injection. These can add and remove other and more basic forms of network information, such as the existence of some routers and links.
攻撃者は、誤ったリンクメトリックを含む明らかに有効なメッセージを作成することにより、OLSRv2ネットワークに悪影響を及ぼす可能性があります。これは、ルートの選択に影響を与える、または場合によってはルーティングループを生成するという形をとることがあります。これは他の形式の無効なメッセージインジェクションよりも巧妙で効果が低い可能性が高い攻撃です。これらは、一部のルーターやリンクの存在など、ネットワーク情報の他のより基本的な形式を追加および削除できます。
As such, no significantly new security issues arose from the inclusion of metrics in OLSRv2. Defenses to the injection of invalid link metrics are the same as to other forms of invalid message injection, as discussed in the Security Considerations section of [RFC7181].
そのため、OLSRv2にメトリックを含めることにより、大幅に新しいセキュリティの問題は発生しませんでした。無効なリンクメトリックの挿入に対する防御策は、[RFC7181]のセキュリティに関する考慮事項のセクションで説明されているように、他の形式の無効なメッセージ挿入と同じです。
There are possible uses for link metrics in the creation of security countermeasures to prefer the use of links that have better security properties, including better availability, to those with poorer security properties. This, however, is beyond the scope of both this document and [RFC7181].
セキュリティ対策を作成する際にリンクメトリックを使用すると、セキュリティプロパティが低いリンクよりも、可用性が高くなるなど、セキュリティプロパティが高いリンクを優先的に使用できます。ただし、これはこのドキュメントと[RFC7181]の両方の範囲を超えています。
The authors would like to gratefully acknowledge the following people (listed alphabetically) for intense technical discussions, early reviews, and comments on the documents and its components: Brian Adamson (NRL), Alan Cullen (BAE Systems), Justin Dean (NRL), Ulrich Herberg (Fujitsu), Charles Perkins (Huawei), Stan Ratliff (Cisco), and Henning Rogge (FGAN).
執筆者は、次の人々（アルファベット順）に対して、ドキュメントとそのコンポーネントに関する激しい技術的議論、早期レビュー、コメントについて感謝の意を表します：ブライアンアダムソン（NRL）、アランカレン（BAEシステム）、ジャスティンディーン（NRL）、 Ulrich Herberg（富士通）、Charles Perkins（Huawei）、Stan Ratliff（Cisco）、Henning Rogge（FGAN）。
Finally, the authors would like to express their gratitude to (listed alphabetically) Benoit Claise, Adrian Farrel, Stephen Farrell, and Suresh Krishnan for their reviews and comments on the later draft versions of this document.
最後に、著者は、このドキュメントのドラフト版のレビューとコメントについて、Benoit Claise、Adrian Farrel、Stephen Farrell、Suresh Krishnanに（アルファベット順で）感謝の意を表したいと思います。
[RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC2501] Corson、S。およびJ. Macker、「モバイルアドホックネットワーキング（MANET）：ルーティングプロトコルのパフォーマンスの問題と評価に関する考慮事項」、RFC 2501、1999年1月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「Optimized Link State Routing Protocol（OLSR）」、RFC 3626、2003年10月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、2009年2月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、2011年4月。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.
[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P。、およびU. Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、2014年4月。
In order for routers to find and use shortest routes in a network while using the minimum reduced topology supported by OLSRv2 (that a router only advertises its MPR selectors in TC messages), routing MPR selection must result in the property that there are shortest routes with all intermediate routers being routing MPRs.
ルーターがOLSRv2でサポートされる最小削減トポロジ（ルーターがMPRセレクターをTCメッセージでアドバタイズするだけ）を使用しながら、ネットワーク内の最短ルートを見つけて使用するには、ルーティングMPR選択により、最短ルートがMPRをルーティングするすべての中間ルーター。
This appendix uses the following terminology and assumptions:
この付録では、次の用語と仮定を使用しています。
o The network is a graph of nodes connected by arcs, where nodes correspond to routers with willingness not equal to WILL_NEVER (except possibly at the ends of routes). An arc corresponds to the set of symmetric links connecting those routers; the OLSRv2 interfaces used by those links are not relevant.
o ネットワークは、アークで接続されたノードのグラフです。ノードは、意志度がWILL_NEVERに等しくないルーターに対応します（ルートの端を除く）。アークは、これらのルーターを接続する対称リンクのセットに対応します。これらのリンクで使用されるOLSRv2インターフェイスは関係ありません。
o Each arc has a metric in each direction, being the minimum of the corresponding link metrics in that direction, i.e., the corresponding neighbor metric. This metric must be positive.
o 各アークには、各方向のメトリックがあり、その方向の対応するリンクメトリック、つまり対応する隣接メトリックの最小値です。このメトリックは正でなければなりません。
o A sequence of arcs joining two nodes is referred to as a path.
o 2つのノードを結ぶ一連の弧は、パスと呼ばれます。
o Node A is an MPR of node B if corresponding router A is a routing MPR of router B.
o 対応するルーターAがルーターBのルーティングMPRである場合、ノードAはノードBのMPRです。
The required property (of using shortest routes with reduced topology) is equivalent to the following property: for any pair of distinct nodes X and Z, there is a shortest path from X to Z, X - Y1 - Y2 - ... - Ym - Z such that Y1 is an MPR of Y2, ..., Ym is an MPR of Z. Call such a path a routable path, and call this property the routable path property.
必要なプロパティ（トポロジが削減された最短ルートの使用）は、次のプロパティと同等です。異なるノードXとZのペアには、XからZへの最短パスがあり、X-Y1-Y2-...-Ym -Z（Y1はY2のMPR、...、YmはZのMPR）。このようなパスをルーティング可能なパスと呼び、このプロパティをルーティング可能なパスプロパティと呼びます。
The required definition for a node X selecting MPRs is that for each distinct node Z from which there is a two-arc path, there is a shorter, or equally short, path that is either Z - Y - X where Y is an MPR of X or is the one-arc path Z - X. Note that the existence of locally known, shorter paths that have more than two arcs, which can be used to reduce the numbers of MPRs, is not considered here. (Such reductions are only when the remaining MPRs can be seen to retain all necessary shortest paths and therefore retain the required property.)
MPRを選択するノードXに必要な定義は、2つの円弧パスが存在する個別のノードZごとに、Z-Y-Xのいずれかであるより短い、または同等に短いパスがあり、YはMPRのMPRです。 Xまたは1つの弧のパスZ-X。MPRの数を減らすために使用できる、3つ以上の弧を持つローカルで既知の短いパスの存在は、ここでは考慮されないことに注意してください。 （そのような削減は、残りのMPRがすべての必要な最短パスを保持しているために必要なプロパティを保持していると見なせる場合のみです。）
Although this appendix is concerned with paths with minimum total metric, not number of arcs (hop count), it proceeds by induction on the number of arcs in a path. Although it considers minimum metric routes with a bounded number of arcs, it then allows that number of arcs to increase so that overall minimum metric paths, regardless of the number of arcs, are considered.
この付録は、アークの数（ホップカウント）ではなく、総メトリックが最小のパスに関係していますが、パス内のアークの数の帰納法によって処理されます。制限された数のアークを持つ最小メトリックルートが考慮されますが、その場合、アークの数を増やして、アークの数に関係なく全体的な最小メトリックパスが考慮されるようにすることができます。
Specifically, the routable path property is a corollary of the property that for all positive integers n and all distinct nodes X and Z, if there is any path from X to Z of n arcs or fewer, then there is a shortest path, from among those of n arcs or fewer, that is a routable path. This may be called the n-arc routable path property.
具体的には、ルーティング可能なパスプロパティは、すべての正の整数nとすべての個別のノードXおよびZについて、nアーク以下のXからZへのパスがある場合、最短パスが存在するというプロパティの結果です。 n個以下のアーク、つまりルーティング可能なパス。これは、n-arcルーティング可能なパスプロパティと呼ばれることがあります。
The n-arc routable path property is trivial for n = 1 and directly follows from the definition of the MPRs of Z for n = 2.
n-arcルーティング可能なパスプロパティは、n = 1の場合は自明であり、n = 2の場合のZのMPRの定義から直接従います。
Proceeding by induction, assuming the n-arc routable path property is true for n = k, consider the case that n = k+1.
誘導により、n-arcルーティング可能なパスプロパティがn = kに対してtrueであると仮定して、n = k + 1の場合を考えます。
Suppose that X - V1 - V2 - ... - Vk - Z is a shortest k+1 arc path from X to Z. We construct a path that has no more than k+1 arcs, has the same or shorter length (hence has the same, shortest, length considering only paths of up to k+1 arcs, by assumption), and is a routable path.
X-V1-V2-...-Vk-ZがXからZへの最短のk + 1円弧パスであると仮定します。k+ 1円弧以下のパスを作成し、同じまたは短い長さ（したがって、仮定により、k + 1アークまでのパスのみを考慮して、同じ、最短、長さを持ち、ルーティング可能なパスです。
First, consider whether Vk is an MPR of Z. If it is not, then consider the two-arc path Vk-1 - Vk - Z. This can be replaced either by a one-arc path Vk-1 - Z or by a two-arc path Vk-1 - Wk - Z, where Wk is an MPR of Z, such that the metric from Vk-1 to Z by the replacement path is no longer. In the former case (replacement one-arc path), this now produces a path of length k, and the previous inductive step may be applied. In the latter case, we have replaced Vk by Wk, where Wk is an MPR of Z. Thus, we need only consider the case that Vk is an MPR of Z.
まず、VkがZのMPRであるかどうかを検討します。そうでない場合は、2アークパスVk-1-Vk-Zを検討します。これは、1アークパスVk-1-Zまたは2アークパスVk-1-Wk-Z。ここで、WkはZのMPRであり、置換パスによるVk-1からZへのメトリックはもうありません。前者の場合（置換1円弧経路）、これにより長さkの経路が生成され、前の誘導ステップが適用されます。後者の場合、VkをWkに置き換えました。ここで、WkはZのMPRです。したがって、VkがZのMPRである場合のみ考慮する必要があります。
We now apply the previous inductive step to the path X - V1 - ... - Vk-1 - Vk, replacing it by an equal length path X - W1 - ... Wm-1 - Vk, where m <= k, where this path is a routable path. Then, because Vk is an MPR of Z, the path X - W1 - ... - Wm-1 - Vk - Z is a routable path and demonstrates the n-arc routable path property for n = k+1.
ここで、前の帰納的ステップをパスX-V1-...-Vk-1-Vkに適用し、等長パスX-W1-... Wm-1-Vkに置き換えます。ここで、m <= k、このパスはルーティング可能なパスです。次に、VkはZのMPRであるため、パスX-W1-...-Wm-1-Vk-Zはルーティング可能なパスであり、n = k + 1のn-arcルーティング可能なパスプロパティを示します。
This thus shows that for any distinct nodes X and Z, there is a routable path using the MPR-reduced topology from X to Z, i.e., that OLSRv2 finds minimum length paths (minimum total metric routes).
したがって、これは、個別のノードXおよびZに対して、XからZへのMPR削減トポロジを使用してルーティング可能なパスがあること、つまり、OLSRv2が最小長のパス（最小合計メトリックルート）を見つけることを示しています。
Authors' Addresses
著者のアドレス
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems Advanced Technology Center West Hanningfield Roadイギリス、チェルムズフォード、グレートバッドウ
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen LIX, Ecole Polytechnique 91128 Palaiseau Cedex France
Thomas Heide Clausen LIX、Ecole Polytechnique 91128 Palaiseau Cedex France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
Philippe Jacquet Alcatel-Lucent Bell Labs
フィリップジャケアルカテルルーセントベルラボ
Phone: +33 6 7337 1880
EMail: philippe.jacquet@alcatel-lucent.com