[要約] RFC 7779は、OLSRv2に基づくパケットシーケンス番号に基づく方向性エアタイムメトリックに関するものです。その目的は、リンク状態ルーティングの最適化において、パケットの送信方向を改善することです。
Internet Engineering Task Force (IETF) H. Rogge
Request for Comments: 7779 Fraunhofer FKIE
Category: Experimental E. Baccelli
ISSN: 2070-1721 INRIA
April 2016
Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)
最適化されたリンク状態ルーティングバージョン2（OLSRv2）のパケットシーケンス番号に基づく指向性エアタイムメトリック
Abstract
概要
This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).
このドキュメントでは、最適化されたリンク状態ルーティングバージョン2（OLSRv2）で使用するための指向性エアタイム（DAT）リンクメトリックを指定します。
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/rfc7779.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7779で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Directional Airtime Metric Rationale . . . . . . . . . . . . 5
5. Metric Functioning and Overview . . . . . . . . . . . . . . . 6
6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7
7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 8
7.1. Recommended Values . . . . . . . . . . . . . . . . . . . 8
8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9
9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10
9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Requirements for Using DAT Metric in OLSRv2
Implementations . . . . . . . . . . . . . . . . . . . . . 10
9.3. Link-Loss Data Gathering . . . . . . . . . . . . . . . . 11
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 12
10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12
10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 12
10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 17
Appendix B. OLSR.org Metric History . . . . . . . . . . . . . . 17
Appendix C. Link-Speed Stabilization . . . . . . . . . . . . . . 18
Appendix D. Packet-Loss Hysteresis . . . . . . . . . . . . . . . 19
Appendix E. Example DAT Values . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
One of the major shortcomings of Optimized Link State Routing (OLSR) [RFC3626] is the lack of a granular link-cost metric between OLSR routers. Operational experience with OLSR networks gathered since its publication has revealed that wireless networks links can have highly variable and heterogeneous properties. This makes a hop-count metric insufficient for effective OLSR routing.
最適化リンクステートルーティング（OLSR）[RFC3626]の主な欠点の1つは、OLSRルーター間に詳細なリンクコストメトリックがないことです。 OLSRネットワークの運用経験は、その発表以来収集されており、ワイヤレスネットワークリンクは非常に多様で異質なプロパティを持つ可能性があることが明らかになっています。これにより、ホップカウントメトリックが効果的なOLSRルーティングには不十分になります。
Based on this experience, OLSRv2 [RFC7181] integrates the concept of link metrics directly into the core specification of the routing protocol. The OLSRv2 routing metric is an external process, and it can be any kind of dimensionless additive cost function that reports to the OLSRv2 protocol.
この経験に基づいて、OLSRv2 [RFC7181]はリンクメトリックの概念をルーティングプロトコルのコア仕様に直接統合します。 OLSRv2ルーティングメトリックは外部プロセスであり、OLSRv2プロトコルにレポートするあらゆる種類の無次元の追加コスト関数にすることができます。
Since 2004, the OLSR.org [OLSR.org] implementation of OLSR has included an Estimated Transmission Count (ETX) metric [MOBICOM04] as a proprietary extension. While this metric is not perfect, it proved to be sufficient for a long time for Community Mesh Networks (see Appendix B). But the increasing maximum data rate of IEEE 802.11 made the ETX metric less efficient than in the past, which is one reason to move to a different metric.
2004年以降、OLSRのOLSR.org [OLSR.org]実装には、独自の拡張機能としてEstimated Transmission Count（ETX）メトリック[MOBICOM04]が含まれています。このメトリックは完全ではありませんが、コミュニティメッシュネットワークにとっては十分な長さであることが証明されました（付録Bを参照）。ただし、IEEE 802.11の最大データレートの増加により、ETXメトリックは以前よりも効率が低下しました。これが、別のメトリックに移行する理由の1つです。
This document describes a Directional Airtime routing metric for OLSRv2, a successor of the OLSR.org ETX-derived routing metric for OLSR. It takes both the loss rate and the link speed into account to provide a more accurate picture of the links within the network.
このドキュメントでは、OLSR.org ETXから派生したOLSRのルーティングメトリックの後継であるOLSRv2の指向性エアタイムルーティングメトリックについて説明します。損失率とリンク速度の両方を考慮して、ネットワーク内のリンクのより正確な画像を提供します。
This specification allows OLSRv2 deployments with a metric defined by the IETF Mobile Ad Hoc Networks (MANET) working group. It enables easier interoperability testing between implementations and targets to deliver a useful baseline to compare with, for experiments with this metric as well as other metrics. Appendix A contains a few possible steps to improve the Directional Airtime metric. Future experiments should also determine whether the DAT metric can be useful for other IETF protocols, both inside and outside of the MANET working group. This could lead to either moving this document to the Standards Track or replacing it with an improved document.
この仕様では、IETFモバイルアドホックネットワーク（MANET）ワーキンググループによって定義されたメトリックを使用してOLSRv2を展開できます。これにより、実装とターゲット間の相互運用性テストが容易になり、このメトリックと他のメトリックを使用した実験で、比較するのに役立つベースラインが提供されます。付録Aには、Directional Airtimeメトリックを改善するためのいくつかの可能なステップが含まれています。今後の実験では、DATメトリックがMANETワーキンググループの内外を問わず、他のIETFプロトコルに役立つかどうかも判断する必要があります。これにより、このドキュメントを標準化トラックに移動するか、改善されたドキュメントに置き換えることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terminology introduced in [RFC5444], [RFC7181], and [RFC6130], including the terms "packet", "message" and "TLV", are to be interpreted as described therein.
[RFC5444]、[RFC7181]、および[RFC6130]で導入された用語には、「パケット」、「メッセージ」、および「TLV」という用語が含まれ、その中で説明されているように解釈されます。
Additionally, this document uses the following terminology and notational conventions:
さらに、このドキュメントでは次の用語と表記規則を使用しています。
DAT - Directional Airtime (metric). The link metric specified in this document, which is a directional variant of ETT. It does not take reverse path loss into account.
DAT-指向性通信時間（メトリック）。このドキュメントで指定されているリンクメトリックは、ETTの指向性バリアントです。リバースパス損失は考慮されません。
QUEUE - A first in, first out queue of integers.
キュー-整数の先入れ先出しキュー。
QUEUE[TAIL] - The most recent element in the queue.
QUEUE [TAIL]-キュー内の最新の要素。
add(QUEUE, value) - Adds a new element to the TAIL of the queue.
add（QUEUE、value）-キューのTAILに新しい要素を追加します。
remove(QUEUE) - Removes the HEAD element of the queue.
remove（QUEUE）-キューのHEAD要素を削除します。
sum(QUEUE) - An operation that returns the sum of all elements in a QUEUE.
sum（QUEUE）-QUEUEのすべての要素の合計を返す演算。
diff_seqno(new, old) - An operation that returns the positive distance between two elements of the circular sequence number space defined in Section 5.1 of [RFC5444]. Its value is either (new - old) if this result is positive, or else its value is (new - old + 65536).
diff_seqno（new、old）-[RFC5444]のセクション5.1で定義されている循環シーケンス番号スペースの2つの要素間の正の距離を返す演算この結果が正の場合、その値は（新-古い）か、そうでない場合、その値は（新-古い+ 65536）です。
MAX(a, b) - The maximum of a and b.
MAX（a、b）-aとbの最大値。
MIN(a, b) - The minimum of a and b.
MIN（a、b）-aとbの最小値。
UNDEFINED - A value not in the normal value range of a variable.
UNDEFINED-変数の通常の値の範囲にない値。
airtime - The time a transmitted packet blocks the link layer, e.g., a wireless link.
airtime-送信されたパケットがリンクレイヤー、たとえばワイヤレスリンクをブロックする時間。
ETX - Expected Transmission Count. A link metric proportional to the number of transmissions to successfully send an IP packet over a link.
ETX-予想される送信カウント。リンクを介してIPパケットを正常に送信するための送信数に比例するリンクメトリック。
ETT - Estimated Travel Time. A link metric proportional to the amount of airtime needed to successfully transmit an IP packet over a link, not considering Layer 2 overhead created by preamble, backoff time, and queuing.
ETT-推定移動時間。プリアンブル、バックオフ時間、およびキューイングによって作成されるレイヤー2オーバーヘッドを考慮せずに、リンクを介してIPパケットを正常に送信するために必要な通信時間に比例するリンクメトリック。
The Directional Airtime metric was designed and tested (see [COMNET15]) in wireless IEEE 802.11 OLSRv2 networks [RFC7181]. These networks employ link-layer retransmission to increase the delivery probability. A dynamic rate selection algorithm selects the unicast data rate independently for each neighbor.
Directional Airtimeメトリックは、ワイヤレスIEEE 802.11 OLSRv2ネットワーク[RFC7181]で設計およびテストされました（[COMNET15]を参照）。これらのネットワークは、リンク層の再送信を使用して配信確率を高めます。動的レート選択アルゴリズムは、各ネイバーに対して個別にユニキャストデータレートを選択します。
As specified in OLSRv2, the metric calculates only the incoming link cost. It neither calculates the outgoing metric, nor decides the link status (heard, symmetric, lost).
OLSRv2で指定されているように、メトリックは着信リンクコストのみを計算します。発信メトリックを計算することも、リンクステータス（ハード、対称、損失）を決定することもありません。
The metric works both for nodes that can send/receive [RFC5444] packet sequence numbers and those that do not have this capability. In the absence of such sequence numbers, the metric calculates the packet loss based on HELLO message [RFC6130] timeouts.
このメトリックは、[RFC5444]パケットシーケンス番号を送受信できるノードと、この機能を持たないノードの両方で機能します。このようなシーケンス番号がない場合、メトリックはHELLOメッセージ[RFC6130]のタイムアウトに基づいてパケット損失を計算します。
The metric must learn about the unicast data rate towards each one-hop neighbor from an external process, either by configuration or by an external measurement process. This measurement could be done via gathering cross-layer data from the operating system, via an external daemon like Dynamic Link Exchange Protocol [DLEP], or via indirect Layer 3 measurements like packet-pair (see [MOBICOM04]).
メトリックは、構成または外部測定プロセスのいずれかによって、外部プロセスから各1ホップネイバーへのユニキャストデータレートについて学習する必要があります。この測定は、オペレーティングシステムからのクロスレイヤーデータの収集、Dynamic Link Exchange Protocol [DLEP]などの外部デーモン、またはパケットペアなどの間接的なレイヤー3測定（[MOBICOM04]を参照）を介して行うことができます。
The metric uses [RFC5444] multicast control traffic to determine the link packet loss. The administrator should take care that link-layer multicast transmission do not have a higher reception probability than the slowest unicast transmission without retransmission. For example, with 802.11g, it might be necessary to increase the data-rate of the multicast transmissions, e.g., set the multicast data-rate to 6 Mbit/s.
このメトリックは、[RFC5444]マルチキャスト制御トラフィックを使用して、リンクパケットの損失を判断します。管理者は、リンク層マルチキャスト送信が、再送信なしの最も遅いユニキャスト送信よりも高い受信確率を持たないように注意する必要があります。たとえば、802.11gでは、マルチキャスト送信のデータレートを上げる必要がある場合があります。たとえば、マルチキャストデータレートを6 Mbit / sに設定します。
The metric can only handle a certain range of packet loss and unicast data-rate. The maximum packet loss that can be encoded into the metric is a loss of 7 of 8 packets (87.5%), without link-layer retransmissions. The unicast data-rate that can be encoded by this metric can be between 1 kbit/s and 2 Gbit/s. This metric has been designed for data-rates of 1 Mbit/s and hundreds of Mbit/s.
このメトリックは、一定範囲のパケット損失とユニキャストデータレートのみを処理できます。メトリックにエンコードできる最大パケット損失は、リンク層再送信なしで、8パケットのうち7パケットの損失（87.5％）です。このメトリックでエンコードできるユニキャストデータレートは、1 kbit / s〜2 Gbit / sです。このメトリックは、1 Mbit / sおよび数百Mbit / sのデータレート用に設計されています。
The Directional Airtime metric has been inspired by the publications on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from both of these in several ways.
Directional Airtimeメトリックは、ETX [MOBICOM03]およびETT [MOBICOM04]メトリックに関する出版物から着想を得ていますが、いくつかの点でこれらの両方とは異なります。
Instead of measuring the combined loss probability of a bidirectional transmission of a packet over a link in both directions, the Directional Airtime metric measures the incoming loss rate and integrates the incoming link speed into the metric cost. There are multiple reasons for this decision:
Directional Airtimeメトリックは、リンクを介した双方向のパケットの双方向伝送の合計損失確率を測定する代わりに、着信損失率を測定し、着信リンク速度をメトリックコストに統合します。この決定にはいくつかの理由があります。
o OLSRv2 [RFC7181] defines the link metric as directional costs between routers.
o OLSRv2 [RFC7181]は、リンクメトリックをルータ間の方向コストとして定義しています。
o Not all link-layer implementations use acknowledgement mechanisms. Most link-layer implementations that do use them use less airtime and a more robust modulation for the acknowledgement than the data transmission, which makes it more likely for the data transmission to be disrupted compared to the acknowledgement.
o すべてのリンク層の実装が確認応答メカニズムを使用するわけではありません。それらを使用するほとんどのリンク層実装では、データ送信よりも確認応答のエアタイムが少なく、より堅牢な変調が使用されるため、確認応答と比較してデータ送信が中断される可能性が高くなります。
o Incoming packet loss and link speed can be measured locally, while symmetric link loss would need an additional signaling TLV in the HELLO [RFC6130] and would delay metric calculation by up to one HELLO interval.
o 着信パケット損失とリンク速度はローカルで測定できますが、対称リンク損失はHELLO [RFC6130]で追加のシグナリングTLVを必要とし、メトリック計算を最大1つのHELLO間隔だけ遅延させます。
The Directional Airtime metric does not integrate the packet size into the link cost. Doing so is not feasible in most link-state routing protocol implementations. The routing decision of most operation systems does not take packet size into account.
Directional Airtimeメトリックは、パケットサイズをリンクコストに統合しません。これを行うことは、ほとんどのリンクステートルーティングプロトコルの実装では実現できません。ほとんどのオペレーティングシステムのルーティングの決定では、パケットサイズは考慮されません。
Multiplying all link costs of a topology with the size of a data-plane packet would never change the Dijkstra result in any way.
トポロジのすべてのリンクコストにデータプレーンパケットのサイズを掛けても、ダイクストラの結果が変わることはありません。
The queue-based packet-loss estimator specified in this document has been tested extensively in the OLSR.org ETX implementation; see Appendix B. The output is the average of the packet loss over a configured time period.
このドキュメントで指定されているキューベースのパケット損失推定量は、OLSR.org ETX実装で広範囲にわたってテストされています。付録Bを参照してください。出力は、構成された期間におけるパケット損失の平均です。
The metric normally measures the loss of a link by tracking the incoming [RFC5444] packet sequence numbers. Without these packet sequence numbers, the metric does calculate the loss of the link based on the received and lost [RFC6130] HELLO messages. It uses the incoming HELLO interval time (or if not present, the validity time) to decide when a HELLO is lost.
このメトリックは通常、着信[RFC5444]パケットシーケンス番号を追跡することにより、リンクの損失を測定します。これらのパケットシーケンス番号がない場合、メトリックは、受信および損失した[RFC6130] HELLOメッセージに基づいてリンクの損失を計算します。着信HELLOインターバル時間（または存在しない場合は有効時間）を使用して、HELLOが失われたときを判断します。
When a neighbor router resets, its packet sequence number might jump to a random value. The metric tries to detect jumps in the packet sequence number and removes them from the data set because the previously gathered link-loss data should still be valid (see Section 9.3). The link-loss data is only removed from memory when a link times out completely and its Link Set Tuple is removed from the database.
ネイバールータがリセットすると、そのパケットシーケンス番号がランダムな値にジャンプする場合があります。以前に収集されたリンク損失データはまだ有効であるため、メトリックはパケットシーケンス番号のジャンプを検出してデータセットから削除しようとします（セクション9.3を参照）。リンク損失データは、リンクが完全にタイムアウトし、そのリンクセットタプルがデータベースから削除された場合にのみメモリから削除されます。
The Directional Airtime metric is calculated for each Link Set entry, as defined in [RFC6130], Section 7.1.
[RFC6130]、セクション7.1で定義されているように、指向性エアタイムメトリックは各リンクセットエントリに対して計算されます。
The metric processes two kinds of data into the metric value, namely packet-loss rate and link speed. The link speed is taken from an external process not defined in this document. The current packet-loss rate is defined in this document by keeping track of packet reception and packet-loss events. It could also be calculated by an external process with a compatible output.
メトリックは、2種類のデータを処理してメトリック値にします。つまり、パケット損失率とリンク速度です。リンク速度は、このドキュメントで定義されていない外部プロセスから取得されます。現在のパケット損失率は、パケットの受信とパケット損失のイベントを追跡することにより、このドキュメントで定義されています。また、互換性のある出力を備えた外部プロセスで計算することもできます。
Multiple incoming packet-loss/reception events must be combined into a loss rate to get a smooth metric. Experiments with exponential weighted moving average (EWMA) lead to a highly fluctuating or a slow converging metric (or both). To get a smoother and more controllable metric result, this metric uses two fixed-length queues to measure and average the incoming packet events, one queue for received packets and one for the estimated number of packets sent by the other side of the link.
複数の着信パケット損失/受信イベントを組み合わせて損失率にし、スムーズなメトリックを取得する必要があります。指数加重移動平均（EWMA）を使用した実験では、変動の激しいメトリックまたは収束の遅いメトリック（またはその両方）が発生します。よりスムーズで制御可能なメトリック結果を取得するために、このメトリックは2つの固定長キューを使用して、受信パケットイベントを測定および平均化します。1つは受信パケット用、もう1つはリンクの反対側が送信したパケットの推定数用です。
Because the rate of incoming packets is not uniform over time, the queue contains a number of counters, each representing a fixed time interval. Incoming packet-loss and packet-reception events are accumulated in the current queue element until a timer adds a new empty counter to both queues and removes the oldest counter from both.
着信パケットのレートは時間とともに均一ではないため、キューには多数のカウンターが含まれており、それぞれが一定の時間間隔を表しています。着信パケット損失イベントとパケット受信イベントは、タイマーが両方のキューに新しい空のカウンタを追加し、両方から最も古いカウンタを削除するまで、現在のキュー要素に蓄積されます。
In addition to the packet loss stored in the queue, this metric uses a timer to detect a total link loss. For every [RFC6130] HELLO interval in which the metric received no packet from a neighbor, it scales the number of received packets in the queue based on the total time interval the queue represents compared to the total time of the lost HELLO intervals.
キューに格納されたパケット損失に加えて、このメトリックはタイマーを使用して、合計リンク損失を検出します。メトリックがネイバーからパケットを受信しなかった[RFC6130] HELLO間隔ごとに、失われたHELLO間隔の合計時間と比較した、キューが表す合計時間間隔に基づいて、キュー内の受信パケット数をスケーリングします。
The average packet-loss ratio is calculated as the sum of the 'total packets' counters divided by the sum of the 'packets received' counters. This value is then divided through the current link speed and then scaled into the range of metrics allowed for OLSRv2.
平均パケット損失率は、「合計パケット」カウンターの合計を「受信パケット」カウンターの合計で割った値として計算されます。この値は、現在のリンク速度で除算され、OLSRv2で許可されるメトリックの範囲にスケーリングされます。
The metric value is then used as L_in_metric of the Link Set (as defined in Section 8.1. of [RFC7181]).
次に、メトリック値はリンクセットのL_in_metricとして使用されます（[RFC7181]のセクション8.1で定義）。
While this document does not add new [RFC5444] elements to HELLO [RFC6130] or TC messages [RFC7181], it works best when both the INTERVAL_TIME message TLV is present in the HELLO messages and when each [RFC5444] packet contains an interface-specific sequence number. It also adds a number of new data entries to be stored for each [RFC6130] link.
このドキュメントでは、HELLO [RFC6130]またはTCメッセージ[RFC7181]に新しい[RFC5444]要素を追加していませんが、INTERLO_TIMEメッセージTLVがHELLOメッセージに存在し、各[RFC5444]パケットにインターフェイス固有のものが含まれている場合に最適に機能しますシーケンス番号。また、[RFC6130]リンクごとに保存されるいくつかの新しいデータエントリを追加します。
This specification defines the following constants, which define the range of metric values that can be encoded by the DAT metric (see Table 1). They cannot be changed without making the metric outputs incomparable and should only be changed for a MANET with a very slow or a very fast link layer. See Appendix E for example metric values.
この仕様では、DATメトリックによってエンコードできるメトリック値の範囲を定義する次の定数を定義しています（表1を参照）。これらは、メトリック出力を比類のないものにすることなく変更することはできず、非常に遅いまたは非常に速いリンク層を持つMANETに対してのみ変更する必要があります。メトリック値の例については、付録Eを参照してください。
DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS.
DAT_MAXIMUM_LOSS-このルーティングメトリックで使用される損失率の割合。損失率は0 / DAT_MAXIMUM_LOSSと（DAT_MAXIMUM_LOSS-1）/ DAT_MAXIMUM_LOSSの間になります。
DAT_MINIMUM_BITRATE - Minimal bitrate in Bit/s used by this routing
metric.
+---------------------+-------+
| Name | Value |
+---------------------+-------+
| DAT_MAXIMUM_LOSS | 8 |
| | |
| DAT_MINIMUM_BITRATE | 1000 |
+---------------------+-------+
Table 1: DAT Protocol Constants
表1：DATプロトコル定数
This specification defines the following parameters for this routing metric. These parameters are:
この仕様では、このルーティングメトリックの次のパラメータを定義しています。これらのパラメーターは次のとおりです。
DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All received and lost packets within the queue length are used to calculate the cost of the link.
DAT_MEMORY_LENGTH-パケット損失を平均化するためのキューの長さ。キューの長さ内のすべての受信および損失パケットは、リンクのコストを計算するために使用されます。
DAT_REFRESH_INTERVAL - Interval in seconds between two metric recalculations as described in Section 10.2. This value SHOULD be smaller than a typical HELLO interval. The interval can be a fraction of a second.
DAT_REFRESH_INTERVAL-セクション10.2で説明されている2つのメトリック再計算の間隔（秒）。この値は、通常のHELLO間隔よりも小さい必要があります。間隔は、1秒未満にすることができます。
DAT_HELLO_TIMEOUT_FACTOR - Multiplier relative to the HELLO_INTERVAL (see Section 5.3.1 of [RFC6130]) after which the DAT metric considers a HELLO as lost.
DAT_HELLO_TIMEOUT_FACTOR-HELLO_INTERVALに相対的な乗数（[RFC6130]のセクション5.3.1を参照）。その後、DATメトリックはHELLOが失われたと見なします。
DAT_SEQNO_RESTART_DETECTION - Threshold in the number of missing packets (based on received packet sequence numbers) at which point the router considers the neighbor has restarted. This parameter is only used for loss estimation based on packet sequence numbers. This number MUST be larger than DAT_MAXIMUM_LOSS.
DAT_SEQNO_RESTART_DETECTION-（受信したパケットのシーケンス番号に基づく）欠落したパケット数のしきい値。この時点で、ルーターは隣接ルーターが再起動したと見なします。このパラメーターは、パケットシーケンス番号に基づく損失推定にのみ使用されます。この数はDAT_MAXIMUM_LOSSより大きくなければなりません。
The proposed values of the protocol parameters are for Community Mesh Networks, which mostly use routers that are not mobile. Using this metric for mobile networks might require shorter DAT_REFRESH_INTERVAL and/or DAT_MEMORY_LENGTH.
プロトコルパラメータの推奨値は、ほとんどがモバイルではないルーターを使用するコミュニティメッシュネットワーク用です。このメトリックをモバイルネットワークに使用するには、DAT_REFRESH_INTERVALまたはDAT_MEMORY_LENGTHを短くする必要がある場合があります。
DAT_MEMORY_LENGTH := 64
DAT_MEMORY_LENGTH：= 64
DAT_REFRESH_INTERVAL := 1
DAT_REFRESH_INTERVAL：= 1
DAT_HELLO_TIMEOUT_FACTOR := 1.2
DAT_HELLO_TIMEOUT_FACTOR：= 1.2
DAT_SEQNO_RESTART_DETECTION := 256
DAT_SEQNO_RESTART_DETECTION：= 256
This specification extends the Link Set of the Interface Information Base, as defined in Section 7.1 of [RFC6130], by the adding the following elements to each Link Tuple:
この仕様は、[RFC6130]のセクション7.1で定義されているように、各リンクタプルに次の要素を追加することにより、インターフェース情報ベースのリンクセットを拡張します。
L_DAT_received - A QUEUE with DAT_MEMORY_LENGTH integer elements. Each entry contains the number of successfully received packets within an interval of DAT_REFRESH_INTERVAL.
L_DAT_received-DAT_MEMORY_LENGTH整数要素を持つQUEUE。各エントリには、DAT_REFRESH_INTERVALの間隔内で正常に受信されたパケットの数が含まれています。
L_DAT_total - A QUEUE with DAT_MEMORY_LENGTH integer elements. Each entry contains the estimated number of packets transmitted by the neighbor, based on the received packet sequence numbers within an interval of DAT_REFRESH_INTERVAL.
L_DAT_total-DAT_MEMORY_LENGTH整数要素を持つQUEUE。各エントリには、DAT_REFRESH_INTERVALの間隔内で受信したパケットシーケンス番号に基づいて、ネイバーによって送信されたパケットの推定数が含まれています。
L_DAT_packet_time - The time when the next [RFC5444] packet should have arrived.
L_DAT_packet_time-次の[RFC5444]パケットが到着するはずの時刻。
L_DAT_hello_interval - The interval between two HELLO messages of the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] of NHDP messages [RFC6130].
L_DAT_hello_interval-NHDPメッセージ[RFC6130]のINTERVAL_TIME TLV [RFC5497]によって通知される、リンクネイバーの2つのHELLOメッセージ間の間隔。
L_DAT_lost_packet_intervals - The estimated number of HELLO intervals from this neighbor from which the metric has not received a single packet.
L_DAT_lost_packet_intervals-メトリックが単一のパケットを受信していない、このネイバーからのHELLO間隔の推定数。
L_DAT_rx_bitrate - The current bitrate of incoming unicast traffic for this neighbor.
L_DAT_rx_bitrate-このネイバーの着信ユニキャストトラフィックの現在のビットレート。
L_DAT_last_pkt_seqno - The last received packet sequence number received from this link.
L_DAT_last_pkt_seqno-このリンクから最後に受信したパケットシーケンス番号。
Methods to obtain the value of L_DAT_rx_bitrate are out of the scope of this specification. Such methods may include static configuration via a configuration file or dynamic measurement through mechanisms described in a separate specification (e.g., [DLEP]). Any Link Tuple with L_status = HEARD or L_status = SYMMETRIC MUST have a specified value of L_DAT_rx_bitrate if it is to be used by this routing metric.
L_DAT_rx_bitrateの値を取得するメソッドは、この仕様の範囲外です。このような方法には、構成ファイルによる静的構成や、別の仕様（[DLEP]など）で説明されているメカニズムによる動的測定などがあります。 L_status = HEARDまたはL_status = SYMMETRICのリンクタプルは、このルーティングメトリックで使用される場合、L_DAT_rx_bitrateの指定された値を持っている必要があります。
The incoming bitrate value should be stabilized by a hysteresis filter to improve the stability of this metric. See Appendix D for an example.
このメトリックの安定性を向上させるには、入力ビットレート値をヒステリシスフィルターで安定化する必要があります。例については、付録Dを参照してください。
This specification updates the L_in_metric field of the Link Set of the Interface Information Base, as defined in Section 8.1. of [RFC7181]).
この仕様は、セクション8.1で定義されているように、インターフェース情報ベースのリンクセットのL_in_metricフィールドを更新します。 [RFC7181]の）。
When generating a new tuple in the Link Set, as defined in item 3 of Section 12.5 of [RFC6130], the values of the elements specified in Section 8 are set as follows:
[RFC6130]のセクション12.5のアイテム3で定義されているように、リンクセットで新しいタプルを生成する場合、セクション8で指定された要素の値は次のように設定されます。
o L_DAT_received := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH elements.
o L_DAT_received：= 0、...、0。キューには常にDAT_MEMORY_LENGTH要素があります。
o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH elements.
o L_DAT_total：= 0、...、0。キューには常にDAT_MEMORY_LENGTH要素があります。
o L_DAT_packet_time := EXPIRED (no earlier [RFC5444] packet received).
o L_DAT_packet_time：= EXPIRED（以前の[RFC5444]パケットは受信されていません）。
o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO received).
o L_DAT_hello_interval：=未定義（以前のNHDP HELLOは受信されていません）。
o L_DAT_lost_packet_intervals := 0 (no HELLO interval without packets).
o L_DAT_lost_packet_intervals：= 0（パケットなしのHELLO間隔なし）。
o L_DAT_last_pkt_seqno := UNDEFINED (no earlier [RFC5444] packet with sequence number received).
o L_DAT_last_pkt_seqno：=未定義（シーケンス番号付きの以前の[RFC5444]パケットは受信されていません）。
This section describes the necessary changes of [RFC7181] implementations with DAT metric for the processing and modification of the incoming and outgoing [RFC5444] data.
このセクションでは、着信および発信[RFC5444]データの処理と変更のためのDATメトリックを使用した[RFC7181]実装の必要な変更について説明します。
For the purpose of this section, note the following definitions:
このセクションでは、次の定義に注意してください。
o "pkt_seqno" is defined as the [RFC5444] packet sequence number of the received packet.
o 「pkt_seqno」は、受信したパケットの[RFC5444]パケットシーケンス番号として定義されます。
o "interval_time" is the time encoded in the INTERVAL_TIME message TLV of a received HELLO message [RFC6130].
o 「interval_time」は、受信したHELLOメッセージ[RFC6130]のINTERVAL_TIMEメッセージTLVにエンコードされた時間です。
o "validity_time" is the time encoded in the VALIDITY_TIME message TLV of a received HELLO message [RFC6130].
o 「validity_time」は、受信したHELLOメッセージ[RFC6130]のVALIDITY_TIMEメッセージTLVにエンコードされた時間です。
An implementation of OLSRv2 using the metric specified by this document SHOULD include the following parts into its [RFC5444] output:
このドキュメントで指定されているメトリックを使用したOLSRv2の実装は、[RFC5444]出力に次の部分を含める必要があります（SHOULD）。
o An INTERVAL_TIME message TLV in each HELLO message, as defined in [RFC6130], Section 4.3.2.
o [RFC6130]のセクション4.3.2で定義されている、各HELLOメッセージ内のINTERVAL_TIMEメッセージTLV。
o An interface-specific packet sequence number as defined in [RFC5444], Section 5.1 that is incremented by 1 for each outgoing [RFC5444] packet on the interface.
o [RFC5444]のセクション5.1で定義されているインターフェース固有のパケットシーケンス番号。インターフェース上の送信[RFC5444]パケットごとに1ずつ増加します。
An implementation of OLSRv2 using the metric specified by this document that inserts packet sequence numbers in some, but not all, outgoing [RFC5444] packets will make this metric ignore all packets without the sequence number. Putting the INTERVAL_TIME TLV into some, but not all, HELLO messages will make the timeout-based loss detection slower. This will only matter in the absence of packet sequence numbers.
すべてではなく一部の発信[RFC5444]パケットにパケットシーケンス番号を挿入する、このドキュメントで指定されているメトリックを使用したOLSRv2の実装は、シーケンス番号のないすべてのパケットをこのメトリックに無視させます。 INTERVAL_TIME TLVをすべてではなく一部のHELLOメッセージに入れると、タイムアウトベースの損失検出が遅くなります。これは、パケットのシーケンス番号がない場合にのみ問題になります。
For each incoming [RFC5444] packet, additional processing SHOULD be carried out after the packet messages have been processed as specified in [RFC6130] and [RFC7181] as described in this section.
着信する[RFC5444]パケットごとに、このセクションで説明されている[RFC6130]と[RFC7181]で指定されているようにパケットメッセージが処理された後に、追加の処理を実行する必要があります（SHOULD）。
[RFC5444] packets without packet sequence numbers MUST NOT be processed in the way described in this section.
[RFC5444]パケットシーケンス番号のないパケットは、このセクションで説明する方法で処理してはなりません（MUST NOT）。
The router updates the Link Set Tuple corresponding to the originator of the packet:
ルータは、パケットの発信元に対応するリンクセットタプルを更新します。
1. If L_DAT_last_pkt_seqno = UNDEFINED, then:
1. L_DAT_last_pkt_seqno = UNDEFINEDの場合：
* L_DAT_received[TAIL] := 1.
* L_DAT_received [TAIL]：= 1。
* L_DAT_total[TAIL] := 1.
* L_DAT_total [TAIL]：= 1。
2. Otherwise:
2. さもないと：
* L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1.
* L_DAT_received [TAIL]：= L_DAT_received [TAIL] + 1。
* diff := diff_seqno(pkt_seqno, L_DAT_last_pkt_seqno).
* diff：= diff_seqno（pt_seqno、L_DAT_last_pkt_seqno）。
* If diff > DAT_SEQNO_RESTART_DETECTION, then:
* diff> DAT_SEQNO_RESTART_DETECTIONの場合：
diff := 1.
diff：= 1。
* L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff.
* L_DAT_total [TAIL]：= L_DAT_total [TAIL] +差分。
3. L_DAT_last_pkt_seqno := pkt_seqno.
3. L_DAT_last_pkt_seqno：= punkt_seqno。
4. If L_DAT_hello_interval != UNDEFINED, then:
4. L_DAT_hello_interval！= UNDEFINEDの場合：
* L_DAT_packet_time := current time + (L_DAT_hello_interval * DAT_HELLO_TIMEOUT_FACTOR).
* L_DAT_packet_time：=現在時刻+（L_DAT_hello_interval * DAT_HELLO_TIMEOUT_FACTOR）。
5. L_DAT_lost_packet_intervals := 0.
5. L_DAT_lost_packet_intervals：= 0。
For each incoming HELLO Message, after it has been processed as defined in Section 12 of [RFC6130], the Link Set Tuple corresponding to the incoming HELLO message MUST be updated.
各着信HELLOメッセージについて、[RFC6130]のセクション12の定義に従って処理された後、着信HELLOメッセージに対応するリンクセットタプルを更新する必要があります。
1. If the HELLO message contains an INTERVAL_TIME message TLV, then:
1. HELLOメッセージにINTERVAL_TIMEメッセージTLVが含まれている場合：
L_DAT_hello_interval := interval_time.
L_DAT_hello_interval：= interval_time。
2. Otherwise:
2. さもないと：
L_DAT_hello_interval := validity_time.
L_DAT_hello_interval：= validation_time。
3. If L_DAT_last_pkt_seqno = UNDEFINED, then:
3. L_DAT_last_pkt_seqno = UNDEFINEDの場合：
* L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1.
* L_DAT_received [TAIL]：= L_DAT_received [TAIL] + 1。
* L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1.
* L_DAT_total [TAIL]：= L_DAT_total [TAIL] + 1。
* L_DAT_packet_time := current time + (L_DAT_hello_interval * DAT_HELLO_TIMEOUT_FACTOR).
* L_DAT_packet_time：=現在時刻+（L_DAT_hello_interval * DAT_HELLO_TIMEOUT_FACTOR）。
In addition to changes in the [RFC5444] processing/generation code, the DAT metric also uses two timer events.
[RFC5444]処理/生成コードの変更に加えて、DATメトリックは2つのタイマーイベントも使用します。
When L_DAT_packet_time has timed out, the following step MUST be done:
L_DAT_packet_timeがタイムアウトした場合、次の手順を実行する必要があります。
1. If L_DAT_last_pkt_seqno = UNDEFINED, then:
1. L_DAT_last_pkt_seqno = UNDEFINEDの場合：
L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1.
L_DAT_total [TAIL]：= L_DAT_total [TAIL] + 1。
2. Otherwise:
2. さもないと：
L_DAT_lost_packet_intervals := L_DAT_lost_packet_intervals + 1.
L_DAT_lost_packet_intervals：= L_DAT_lost_packet_intervals + 1。
3. L_DAT_packet_time := L_DAT_packet_time + L_DAT_hello_interval.
3. L_DAT_packet_time：= L_DAT_packet_time + L_DAT_hello_interval。
Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link Set entries MUST be recalculated:
DAT_REFRESH_INTERVALごとに、すべてのリンクセットエントリのすべてのL_in_metric値を再計算する必要があります。
1. sum_received := sum(L_DAT_received).
1. sum_received：= sum（L_DAT_received）。
2. sum_total := sum(L_DAT_total).
2. am_total：= am（L_DATE_total）。
3. If L_DAT_hello_interval != UNDEFINED and L_DAT_lost_packet_intervals > 0, then:
3. L_DAT_hello_interval！= UNDEFINEDおよびL_DAT_lost_packet_intervals> 0の場合：
* lost_time_proportion := L_DAT_hello_interval * L_DAT_lost_packet_intervals / DAT_MEMORY_LENGTH.
* lost_time_proportion：= L_DAT_hello_interval * L_DAT_lost_packet_intervals / DAT_MEMORY_LENGTH。
* sum_received := sum_received * MAX(0, 1 - lost_time_proportion);
* sum_received：= sum_received * MAX（0、1-lost_time_proportion）;
4. If sum_received < 1, then:
4. sum_received <1の場合：
L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181], Section 5.6.1.
L_in_metric：= MAXIMUM_METRIC、[RFC7181]、セクション5.6.1で定義
5. Otherwise:
5. さもないと：
* loss := MIN(sum_total / sum_received, DAT_MAXIMUM_LOSS).
* 損失：= MIN（合計_合計/合計_受信、DAT_MAXIMUM_LOSS）。
* bitrate := MAX(L_DAT_rx_bitrate, DAT_MINIMUM_BITRATE).
* ビットレート：= MAX（L_DAT_rx_bitrate、DAT_MINIMUM_BITRATE）。
* L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate / DAT_MINIMUM_BITRATE).
* L_in_metric：=（2 ^ 24 / DAT_MAXIMUM_LOSS）*損失/（ビットレート/ DAT_MINIMUM_BITRATE）。
6. remove(L_DAT_total)
6. 削除（L_DAT_total）
7. add(L_DAT_total, 0)
7. 追加（L_DAT_total、0）
8. remove(L_DAT_received)
8. 削除（L_DAT_received）
9. add(L_DAT_received, 0)
9. add（L_DAT_received、0）
The calculated L_in_metric value should be stabilized by a hysteresis function. See Appendix D for an example.
計算されたL_in_metric値は、ヒステリシス関数によって安定化する必要があります。例については、付録Dを参照してください。
Artificial manipulation of metrics values can drastically alter network performance. In particular, advertising a higher L_in_metric value may decrease the amount of incoming traffic, while advertising lower L_in_metric may increase the amount of incoming traffic.
メトリック値を人工的に操作すると、ネットワークのパフォーマンスが大幅に変わる可能性があります。特に、より高いL_in_metric値をアドバタイズすると着信トラフィックの量が減少する可能性がありますが、より低いL_in_metricをアドバタイズすると着信トラフィックの量が増加する可能性があります。
For example, by artificially attracting mesh routes and then dropping the incoming traffic, an attacker may achieve a Denial of Service (DoS) against other mesh nodes. Similarly, an attacker may achieve Man-in-the-Middle (MITM) attacks or traffic analysis by concentrating traffic being routed over a node the attacker controls (and end-to-end encryption is not used or somehow broken). Protection mechanisms against such MITM or DoS attacks are nevertheless out of scope of this document.
たとえば、攻撃者はメッシュルートを人工的に引き付けてから着信トラフィックをドロップすることにより、他のメッシュノードに対してサービス拒否（DoS）を実行する可能性があります。同様に、攻撃者は、攻撃者が制御するノードにルーティングされるトラフィックを集中させることで、中間者攻撃（MITM）攻撃またはトラフィック分析を実行する可能性があります（エンドツーエンドの暗号化は使用されないか、何らかの方法で破壊されます）。それでも、このようなMITMまたはDoS攻撃に対する保護メカニズムは、このドキュメントの範囲外です。
Security threats also include potential attacks on the integrity of the control traffic passively monitored by DAT to measure link quality. For example, an attacker might inject packets pretending to be somebody else and using incorrect sequence numbers. This attack can be prevented by the true originator of the [RFC5444] packets by adding an ICV Packet TLV and TIMESTAMP Packet TLV [RFC7182] to each packet. This allows the receiver to drop all incoming packets that have a forged packet source, both packets generated by the attacker, or replayed packets. However, the security mechanism described in [RFC7183] does not protect the sequence number used by the DAT metric because it only signs the [RFC5444] messages, not the [RFC5444] packet header (which contains the [RFC5444] packet sequence number).
セキュリティの脅威には、リンク品質を測定するためにDATによって受動的に監視される制御トラフィックの整合性に対する潜在的な攻撃も含まれます。たとえば、攻撃者は、誰かになりすまして不正なシーケンス番号を使用してパケットを注入する可能性があります。この攻撃は、各パケットにICVパケットTLVおよびTIMESTAMPパケットTLV [RFC7182]を追加することにより、[RFC5444]パケットの真の発信者によって防止できます。これにより、受信者は、偽造されたパケットソースを持つすべての着信パケット、攻撃者によって生成された両方のパケット、または再生されたパケットをドロップできます。ただし、[RFC7183]で説明されているセキュリティメカニズムは、[RFC5444]パケットヘッダー（[RFC5444]パケットシーケンス番号を含む）ではなく[RFC5444]メッセージに署名するだけなので、DATメトリックで使用されるシーケンス番号を保護しません。
[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>。
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 10.17487/RFC5497, March 2009, <http://www.rfc-editor.org/info/rfc5497>.
[RFC5497] Clausen、T.およびC. Dearlove、「Representing Multi-Value Time in Mobile Ad Hoc Networks（MANETs）」、RFC 5497、DOI 10.17487 / RFC5497、2009年3月、<http：//www.rfc-editor。 org / info / rfc5497>。
[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>。
[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]クラウセン、T。、エド。およびP. Jacquet編、「Optimized Link State Routing Protocol（OLSR）」、RFC 3626、DOI 10.17487 / RFC3626、2003年10月、<http://www.rfc-editor.org/info/rfc3626>。
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, <http://www.rfc-editor.org/info/rfc7182>.
[RFC7182] Herberg、U.、Clauseen、T。、およびC. Dearlove、「モバイルアドホックネットワーク（MANET）の整合性チェック値およびタイムスタンプTLV定義」、RFC 7182、DOI 10.17487 / RFC7182、2014年4月、<http： //www.rfc-editor.org/info/rfc7182>。
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, <http://www.rfc-editor.org/info/rfc7183>.
[RFC7183] Herberg、U.、Dearlove、C。、およびT. Clausen、「Integrity Protection for the Neighborhood Discovery Protocol（NHDP）and Optimized Link State Routing Protocol Version 2（OLSRv2）」、RFC 7183、DOI 10.17487 / RFC7183、 2014年4月、<http://www.rfc-editor.org/info/rfc7183>。
[COMNET15] Barz, C., Fuchs, C., Kirchhoff, J., Niewiejska, J., and H. Rogge, "OLSRv2 for Community Networks: Using Directional Airtime Metric with external radios", Elsevier Computer Networks 2015, DOI 10.1016/j.comnet.2015.09.022, September 2015, <http://dx.doi.org/10.1016/j.comnet.2015.09.022>.
[COMNET15] Barz、C.、Fuchs、C.、Kirchhoff、J.、Niewiejska、J。、およびH. Rogge、「OLSRv2 for Community Networks：Using Directional Airtime Metric with external radios」、Elsevier Computer Networks 2015、DOI 10.1016 /j.comnet.2015.09.022、2015年9月、<http://dx.doi.org/10.1016/j.comnet.2015.09.022>。
[CONFINE] "Community Networks Testbed for the Future Internet (CONFINE)", <http://www.confine-project.eu>.
[制限]「将来のインターネットのためのコミュニティネットワークテストベッド（制限）」、<http://www.confine-project.eu>。
[DLEP] Ratliff, S., Berry, B., Jury, S., Satterwhite, D., and R. Taylor, "Dynamic Link Exchange Protocol (DLEP)", Work in Progress, draft-ietf-manet-dlep-22, April 2016.
[DLEP] Ratliff、S.、Berry、B.、Jury、S.、Satterwhite、D。、およびR. Taylor、「Dynamic Link Exchange Protocol（DLEP）」、Work in Progress、draft-ietf-manet-dlep- 2016年4月22日。
[BATMAN] Neumann, A., Aichele, C., Lindner, M., and S. Wunderlich, "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Work in Progress, draft-wunderlich-openmesh-manet-routing-00, April 2008.
[BATMAN] Neumann、A.、Aichele、C.、Lindner、M。、およびS. Wunderlich、「モバイルアドホックネットワーキングへのより良いアプローチ（BATMAN）」、作業中、draft-wunderlich-openmesh-manet-routing -2008年4月。
[MOBICOM03] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", Proceedings of the MOBICOM Conference, DOI 10.1145/938985.939000, 2003.
[MOBICOM03] De Couto、D.、Aguayo、D.、Bicket、J。、およびR. Morris、「マルチホップワイヤレスルーティングのためのハイスループットパスメトリック」、MOBICOM会議の議事録、DOI 10.1145 / 938985.939000、 2003年
[MOBICOM04] Draves, R., Padhye, J., and B. Zill, "Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks", Proceedings of the MOBICOM Conference, DOI 10.1145/1023720.1023732, 2004.
[MOBICOM04] Draves、R.、Padhye、J。、およびB. Zill、「Routing in Multi-Radio、Multi-Hop Wireless Mesh Networks」、Proceedings of the MOBICOM Conference、DOI 10.1145 / 1023720.1023732、2004。
[OLSR.org] "OLSR.org Wiki", <http://www.olsr.org/>.
[OLSR.org]「OLSR.org Wiki」、<http://www.olsr.org/>。
[FREIFUNK] "Freifunk Wireless Community Networks", <http://www.freifunk.net>.
[FREIFUNK] "Freifunk Wireless Community Networks"、<http://www.freifunk.net>。
[FUNKFEUER] "Austria Wireless Community Network", <http://www.funkfeuer.at>.
[FUNKFEUER]「オーストリアワイヤレスコミュニティネットワーク」、<http://www.funkfeuer.at>。
As the DAT metric proved to work reasonably well for non- or slow-moving ad hoc networks [COMNET15], it should be considered a solid first step on a way to better MANET metrics. There are multiple parts of the DAT metric that need to be reviewed again in the context of real world deployments and can be subject to later improvements.
DATメトリックは、非移動または低速移動のアドホックネットワーク[COMNET15]で適度に機能することが判明したため、MANETメトリックを改善する方法の確実な最初のステップと見なす必要があります。 DATメトリックには複数の部分があり、実際の展開のコンテキストで再検討する必要があり、後で改善される可能性があります。
The easiest part of the DAT metric to change and test would be the timings parameters. A 1-minute interval for packet-loss statistics might be a good compromise for some MANETs, but could easily be too large or to small for others. More data is needed to verify or improve the current parameter selection.
変更およびテストするDATメトリックの最も簡単な部分は、タイミングパラメータです。パケット損失統計の1分の間隔は、一部のMANETにとっては適切な妥協案ですが、他のアプリケーションにとっては、大きすぎたり小さすぎたりする可能性があります。現在のパラメーター選択を検証または改善するには、さらにデータが必要です。
The DAT metric considers only the multicast [RFC5444] packet loss for estimating the link, but it would be good to integrate the unicast data loss into the loss estimation. This information could be provided directly from the link layer. This could increase the accuracy of the loss rate estimation in scenarios where the assumptions regarding the ratio of multicast vs. unicast loss do not hold.
DATメトリックは、リンク[RFC5444]のパケット損失のみを考慮してリンクを推定しますが、ユニキャストデータ損失を損失推定に統合することをお勧めします。この情報は、リンク層から直接提供できます。これにより、マルチキャスト損失とユニキャスト損失の比率に関する仮定が成り立たないシナリオでの損失率推定の精度が向上します。
The packet-loss averaging algorithm could also be improved. While the DAT metric provides a stable sliding time interval to average the incoming packet loss and does not give the recent input too much influence, first experiments suggest that the algorithm tends to be less agile in detecting major changes of link quality. This makes it less suited for mobile networks. A more agile algorithm is needed for detecting major changes while filtering out random fluctuations regarding frame loss. However, the current "queue of counters" algorithm suggested for DAT outperforms the binary queue algorithm and the exponential aging algorithms used for the ETX metric in the OLSR [RFC3626] codebase of OLSR.org.
パケット損失平均化アルゴリズムも改善できます。 DATメトリックは、安定したスライディング時間間隔を提供して着信パケット損失を平均化し、最近の入力にあまり影響を与えませんが、最初の実験では、アルゴリズムがリンク品質の大きな変化を検出する際の俊敏性が低下する傾向があることを示しています。このため、モバイルネットワークにはあまり適していません。フレーム損失に関するランダムな変動を除外しながら、大きな変化を検出するには、より機敏なアルゴリズムが必要です。ただし、DATに提案されている現在の「カウンターのキュー」アルゴリズムは、OLSR.orgのOLSR [RFC3626]コードベースのETXメトリックに使用されるバイナリキューアルゴリズムおよび指数的エージングアルゴリズムよりも優れています。
The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are based on OLSR [RFC3626] or B.A.T.M.A.N. [BATMAN] wireless community networks with hundreds of routers in permanent operation. The Vienna Funkfeuer network in Austria, for instance, consists of 400 routers covering the whole city of Vienna and beyond, spanning roughly 40 km in diameter. It has been supplying its users with Internet access since 2003. A particularity of the Vienna Funkfeuer network is that it manages to provide Internet access through a city-wide, large-scale Wi-Fi MANET, with just a single Internet uplink.
Funkfeuer [FUNKFEUER]およびFreifunkネットワーク[FREIFUNK]は、OLSR [RFC3626]またはB.A.T.M.A.Nに基づいています。 [BATMAN]数百台のルーターが常時稼働しているワイヤレスコミュニティネットワーク。たとえば、オーストリアのウィーンファンクフォイヤーネットワークは、直径約40 kmに及ぶ400のルーターで構成され、ウィーンの街全体をカバーしています。 2003年からユーザーにインターネットアクセスを提供しています。ViennaFunkfeuerネットワークの特徴は、単一のインターネットアップリンクだけで、市全体の大規模Wi-Fi MANETを介してインターネットアクセスを提供できることです。
Operational experience of the OLSR project [OLSR.org] with these networks has revealed that the use of hop-count as a routing metric leads to unsatisfactory network performance. Experiments with the ETX metric [MOBICOM03] were therefore undertaken in parallel in the Berlin Freifunk network as well as in the Vienna Funkfeuer network in 2004, and found satisfactory, i.e., sufficiently easy to implement and providing sufficiently good performance. This metric has now been in operational use in these networks for several years.
これらのネットワークを使用したOLSRプロジェクト[OLSR.org]の運用経験から、ルーティングメトリックとしてホップカウントを使用すると、ネットワークパフォーマンスが不十分になることがわかりました。したがって、ETXメトリック[MOBICOM03]を使用した実験は、2004年にベルリンのFreifunkネットワークとVienna Funkfeuerネットワークで並行して行われ、満足のいく、つまり実装が十分に簡単で、十分に優れたパフォーマンスを提供することがわかりました。このメトリックは、数年前からこれらのネットワークで運用されています。
The ETX metric of a link is the estimated number of transmissions required to successfully send a packet (each packet equal to or smaller than MTU) over that link, until a link-layer acknowledgement is received. The ETX metric is additive, i.e., the ETX metric of a path is the sum of the ETX metrics for each link on this path.
リンクのETXメトリックは、リンク層の確認応答が受信されるまで、そのリンクを介してパケット（各パケットがMTU以下）を正常に送信するために必要な推定送信数です。 ETXメトリックは加算的です。つまり、パスのETXメトリックは、このパス上の各リンクのETXメトリックの合計です。
While the ETX metric delivers a reasonable performance, it does not handle networks with heterogeneous links that have different bitrates well. When using the ETX metric, since every wireless link is characterized only by its packet-loss ratio, long-ranged links with low bitrate (with low loss ratios) are preferred over short-ranged links with high bitrate (with higher but reasonable loss ratios). Such conditions, when they occur, can degrade the performance of a network considerably, by not taking advantage of higher capacity links.
ETXメトリックは妥当なパフォーマンスを提供しますが、ビットレートが異なる異種のリンクを持つネットワークを処理しません。 ETXメトリックを使用する場合、すべてのワイヤレスリンクはそのパケット損失率によってのみ特徴付けられるため、ビットレートが低い（損失率が低い）長距離リンクが、ビットレートが高い（ただし、損失率が高いが妥当な損失率を持つ）短距離リンクよりも優先されます）。このような状態が発生すると、より大容量のリンクを利用できなくなるため、ネットワークのパフォーマンスが大幅に低下する可能性があります。
Because of this, the OLSR.org project has implemented the Directional Airtime metric for OLSRv2, which has been inspired by the Estimated Travel Time (ETT) metric [MOBICOM04]. This metric uses a unidirectional packet loss, but also takes the bitrate into account to create a more accurate description of the relative costs or capabilities of OLSRv2 links.
このため、OLSR.orgプロジェクトは、OLSRv2の指向性エアタイムメトリックを実装しました。これは、推定旅行時間（ETT）メトリック[MOBICOM04]に着想を得ています。このメトリックは、単方向のパケット損失を使用しますが、ビットレートも考慮して、OLSRv2リンクの相対コストまたは機能のより正確な説明を作成します。
The DAT metric specifies how to generate a reasonably stable packet-loss rate value based on incoming packet reception/loss events, but the source of the link speed used in this document is considered an external process.
DATメトリックは、着信パケットの受信/損失イベントに基づいて、かなり安定したパケット損失率の値を生成する方法を指定しますが、このドキュメントで使用されているリンク速度のソースは、外部プロセスと見なされます。
In the presence of a Layer 2 technology with variable link speed, it is likely that the raw link speed will be fluctuating too fast to be useful for the DAT metric.
リンク速度が可変のレイヤー2テクノロジーが存在する場合、生のリンク速度の変動が速すぎて、DATメトリックに役立たない可能性があります。
The amount of stabilization necessary for the link speed depends on the implementation of the MAC layer, especially the rate-control algorithm.
リンク速度に必要な安定化の量は、MAC層の実装、特にレート制御アルゴリズムによって異なります。
Experiments with the Linux 802.11 Wi-Fi stack have shown that a simple Median filter over a series of raw link-speed measurements can smooth the calculated value without introducing intermediate link-speed values one would obtain by using averaging or an exponential weighted moving average.
Linux 802.11 Wi-Fiスタックでの実験により、一連の生のリンク速度測定に対する単純な中央値フィルターが、平均化または指数加重移動平均を使用して取得する中間のリンク速度値を導入することなく、計算値を平滑化できることが示されています。
While the DAT metric uses a sliding window to compute a reasonably stable frame loss, the implementation might choose to integrate an additional hysteresis to prevent undesirable oscillations between two values (i.e., metric flapping).
DATメトリックはスライディングウィンドウを使用してかなり安定したフレーム損失を計算しますが、実装では2つの値間の望ましくない振動（メトリックフラッピングなど）を防ぐために追加のヒステリシスを統合することを選択する場合があります。
In Section 10.2, DAT calculates a fractional loss rate. The fraction of "loss := sum_total / sum_received" may result in minor fluctuations in the advertised L_in_metric due to minimal changes in sum_total or sum_received, which can cause undesirable protocol churn.
セクション10.2では、DATは部分損失率を計算します。 "loss：= sum_total / sum_received"の割合は、sum_totalまたはsum_receivedの最小限の変更により、アドバタイズされたL_in_metricにわずかな変動をもたらす可能性があり、望ましくないプロトコルチャーンを引き起こす可能性があります。
A hysteresis function applied to the fraction could reduce the amount of changes in the loss rate and help to further stabilize the metric output.
割合に適用されたヒステリシス関数は、損失率の変化量を減らし、メトリック出力をさらに安定させるのに役立ちます。
The DAT metric value can be expressed in terms of link speed (bit/s) or used airtime (s). When using the default protocol constants (see Section 6), DAT encodes link speeds between 119 bit/s and 2 Gbit/s.
DATメトリック値は、リンク速度（ビット/秒）または使用された通信時間（秒）で表すことができます。デフォルトのプロトコル定数（セクション6を参照）を使用する場合、DATは119ビット/秒と2ギガビット/秒の間のリンク速度をエンコードします。
Table 2 contains a few examples for metric values and their meaning as a link speed:
表2に、メトリック値のいくつかの例と、リンク速度としての意味を示します。
+---------------------------+-----------+
| Metric | bit/s |
+---------------------------+-----------+
| MINIMUM_METRIC (1) | 2 Gbit/s |
| | |
| MAXIMUM_METRIC (16776960) | 119 bit/s |
| | |
| 2000 | 1 Mbit/s |
+---------------------------+-----------+
Table 2: DAT Link Cost Examples
表2：データリンクコストの例
A path metric value could also be expressed as a link speed, but this would be less intuitive. An easier way to transform a path metric value into a textual representation is to divide it by the hop count of the path and express the path cost as the average link speed together with the hop count (see Table 3).
パスメトリック値はリンク速度として表すこともできますが、これは直感的ではありません。パスメトリック値をテキスト表現に変換する簡単な方法は、パスメトリックをパスのホップカウントで除算し、パスコストを平均リンク速度とホップカウントで表すことです（表3を参照）。
+---------+------+---------------+
| Metric | hops | average bit/s |
+---------+------+---------------+
| 4 | 2 | 1 Gbit/s |
| | | |
| 4000000 | 6 | 3 kbit/s |
+---------+------+---------------+
Table 3: DAT Link Cost Examples
表3：データリンクコストの例
Acknowledgements
謝辞
The authors would like to acknowledge the network administrators from Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for endless hours of testing and suggestions to improve the quality of the original ETX metric for the OLSR.org routing daemon.
著者らは、OLSR.orgルーティングデーモンの元のETXメトリックの品質を向上させるための無限のテストと提案について、Freifunk Berlin [FREIFUNK]とFunkfeuer Vienna [FUNKFEUER]のネットワーク管理者に感謝します。
This effort/activity is supported by the European Community Framework Program 7 within the Future Internet Research and Experimentation Initiative (FIRE), Community Networks Testbed for the Future Internet ([CONFINE]), contract FP7-288535.
この取り組み/活動は、Future Internet Research and Experimentation Initiative（FIRE）、Community Networks Testbed for the Future Internet（[CONFINE]）、契約FP7-288535内のEuropean Community Framework Program 7によってサポートされています。
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification and its components (listed alphabetically): Teco Boot (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research Laboratory), Fabian Nack (Freie Universitaet Berlin), and Stan Ratliff (Cisco Systems).
著者は、仕様とそのコンポーネント（アルファベット順）に関する激しい技術的な議論、初期のレビュー、コメントについて、以下の人々に感謝の意を表します：Teco Boot（Infinity Networks）、Juliusz Chroboczek（PPS、パリ大学7）、Thomasクラウセン、クリストファーディアラブ（BAEシステムアドバンストテクノロジーセンター）、ウルリッヒヘルバーグ（アメリカ富士通研究所）、マーカスキッテンバーガー（ウィーンファンクフォイヤー）、ジョセフマッカー（海軍研究所）、ファビアンナック（ベルリン自由大学）、スタンラトリフ（シスコシステムズ） ）。
Authors' Addresses
著者のアドレス
Henning Rogge Fraunhofer FKIE
ヘニングロッジフラウンホーファーFKIE
Email: henning.rogge@fkie.fraunhofer.de
URI: http://www.fkie.fraunhofer.de
Emmanuel Baccelli INRIA
エマニュエルバチェリINRIA
Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/