Internet Engineering Task Force (IETF) H. Rogge
Request for Comments: 7779 Fraunhofer FKIE
Category: Experimental E. Baccelli
ISSN: 2070-1721 INRIA
April 2016
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.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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
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]的主要缺点之一是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]实现将估计传输计数（ETX）度量[MOBICOM04]作为专有扩展。虽然这个指标并不完美，但对于社区网状网络来说，它在很长一段时间内都是足够的（见附录B）。但是，IEEE 802.11不断增加的最大数据速率使得ETX指标的效率低于过去，这是转向不同指标的原因之一。
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.
本文档描述了OLSRv2的定向广播时间路由度量，它是OLSR.org ETX派生的OLSR路由度量的继承者。它将丢失率和链路速度都考虑在内，以提供网络内链路的更准确图片。
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.
本规范允许OLSRv2部署具有IETF移动自组织网络（MANET）工作组定义的指标。它使实现和目标之间的互操作性测试变得更容易，从而为使用此指标以及其他指标进行的实验提供了一个有用的比较基准。附录A包含了一些改进定向广播时间度量的可能步骤。未来的实验还应确定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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
队列[TAIL]-队列中最近的元素。
add(QUEUE, value) - Adds a new element to the TAIL of the queue.
添加（队列，值）-将新元素添加到队列尾部。
remove(QUEUE) - Removes the HEAD element of the queue.
移除（队列）-移除队列的头元素。
sum(QUEUE) - An operation that returns the sum of all elements in a QUEUE.
sum（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（新、旧）-返回[RFC5444]第5.1节中定义的循环序列号空间的两个元素之间的正距离的操作。如果此结果为正，则其值为（new-old），否则其值为（new-old+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.
未定义-不在变量正常值范围内的值。
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-估计旅行时间。一种链路度量，与通过链路成功传输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.
在无线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]).
类似于守护进程的动态链路交换协议[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，可能需要增加多播传输的数据速率，例如，将多播数据速率设置为6mbit/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.
定向广播时间度量的灵感来源于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:
定向广播时间度量不是测量在两个方向上通过链路的分组的双向传输的组合丢失概率，而是测量传入丢失率并将传入链路速度集成到度量成本中。这一决定有多种原因：
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，并且将延迟度量计算多达一个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.
定向广播时间度量没有将数据包大小集成到链路成本中。这样做在大多数链路状态路由协议实现中是不可行的。大多数操作系统的路由决策不考虑数据包大小。
Multiplying all link costs of a topology with the size of a data-plane packet would never change the Dijkstra result in any way.
将拓扑的所有链路成本乘以数据平面数据包的大小永远不会改变Dijkstra结果。
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.
该度量将两种数据处理为度量值，即丢包率和链路速度。链接速度取自本文档中未定义的外部进程。本文件通过跟踪数据包接收和数据包丢失事件来定义当前数据包丢失率。它也可以由具有兼容输出的外部进程来计算。
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）的实验会导致高度波动或缓慢收敛的度量（或两者兼而有之）。为了获得更平滑和更可控的度量结果，该度量使用两个固定长度的队列来测量和平均传入的数据包事件，一个队列用于接收数据包，另一个队列用于估计链路另一端发送的数据包数量。
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_度量（如[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 messages[RFC7181]添加新的[RFC5444]元素，但在HELLO messages中存在间隔时间消息TLV以及每个[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_最大损失和（DAT_最大损失-1）/DAT_最大损失之间。
DAT_MINIMUM_BITRATE - Minimal bitrate in Bit/s used by this routing
metric.
+---------------------+-------+
| Name | Value |
+---------------------+-------+
| DAT_MAXIMUM_LOSS | 8 |
| | |
| DAT_MINIMUM_BITRATE | 1000 |
+---------------------+-------+
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节所述两次度量重新计算之间的间隔（以秒为单位）。此值应小于典型的HELLO间隔。间隔可以是几分之一秒。
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_因子-相对于HELLO_间隔的乘数（参见[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_最大损失。
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_MEMORY_LENGTH := 64
数据存储长度：=64
DAT_REFRESH_INTERVAL := 1
数据刷新间隔：=1
DAT_HELLO_TIMEOUT_FACTOR := 1.2
DAT_HELLO_超时系数：=1.2
DAT_SEQNO_RESTART_DETECTION := 256
数据顺序否重新启动检测：=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_长度整数元素的队列。每个条目包含在DAT_REFRESH_间隔内成功接收的数据包数。
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_内存长度整数元素的队列。每个条目包含邻居根据在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]的间隔时间TLV[RFC5497]发出信号的链路邻居的两条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_Interval-该度量尚未从中接收到单个数据包的邻居的HELLO间隔估计数。
L_DAT_rx_bitrate - The current bitrate of incoming unicast traffic for this neighbor.
L_DAT_rx_比特率-此邻居的传入单播流量的当前比特率。
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_比特率值的方法不在本规范的范围内。此类方法可包括通过配置文件的静态配置或通过单独规范（例如，[DLEP]）中描述的机制的动态测量。任何L_status=hear或L_status=SYMMETRIC的链路元组必须具有指定的L_DAT_rx_比特率值，如果它要被此路由度量使用。
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_度量字段。属于[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 收到的数据：=0，…，0。队列始终具有DAT_MEMORY_LENGTH元素。
o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH elements.
o L_DAT_总计：=0，…，0。队列始终具有DAT_MEMORY_LENGTH元素。
o L_DAT_packet_time := EXPIRED (no earlier [RFC5444] packet received).
o L_DAT_packet_time:=过期（未收到较早的[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_loss_packet_interval:=0（没有数据包的HELLO interval）。
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.
本节描述了[RFC7181]实现中使用DAT度量对传入和传出[RFC5444]数据进行处理和修改的必要更改。
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]输出中包括以下部分：
o An INTERVAL_TIME message TLV in each HELLO message, as defined in [RFC6130], Section 4.3.2.
o 如[RFC6130]第4.3.2节所定义，每个HELLO消息中的间隔时间消息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
OLSRv2的实现使用本文件规定的度量，在一些（而不是全部）传出[RFC5444]数据包中插入数据包序列号，将使该度量忽略所有没有序列号的数据包。将间隔时间TLV设置为
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.
有些（但不是全部）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]中的规定处理数据包消息后，应执行附加处理。
[RFC5444] packets without packet sequence numbers MUST NOT be processed in the way described in this section.
[RFC5444]没有数据包序列号的数据包不得以本节所述的方式进行处理。
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=未定义，则：
* 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).
* 差异：=差异序号（包装序号，最后一次包装序号）。
* If diff > DAT_SEQNO_RESTART_DETECTION, then:
* 如果差异>数据顺序否重新启动检测，则：
diff := 1.
差异：=1。
* L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff.
* L_DAT_总计[尾]：=L_DAT_总计[尾]+差异。
3. L_DAT_last_pkt_seqno := pkt_seqno.
3. L_DAT_last_pkt_seqno:=pkt_seqno。
4. If L_DAT_hello_interval != UNDEFINED, then:
4. 如果L_DAT_hello_interval！=未定义，则：
* L_DAT_packet_time := current time + (L_DAT_hello_interval * DAT_HELLO_TIMEOUT_FACTOR).
* L_DAT_数据包时间：=当前时间+（L_DAT_hello_间隔*DAT_hello_超时系数）。
5. L_DAT_lost_packet_intervals := 0.
5. 数据包丢失间隔：=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消息包含间隔时间消息TLV，则：
L_DAT_hello_interval := interval_time.
L_DAT_hello_interval:=间隔时间。
2. Otherwise:
2. 否则：
L_DAT_hello_interval := validity_time.
L_DAT_hello_间隔：=有效时间。
3. If L_DAT_last_pkt_seqno = UNDEFINED, then:
3. 如果L_DAT_last_pkt_seqno=未定义，则：
* 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_数据包时间：=当前时间+（L_DAT_hello_间隔*DAT_hello_超时系数）。
In addition to changes in the [RFC5444] processing/generation code, the DAT metric also uses two timer events.
除了[RFC5444]处理/生成代码中的更改外，DAT度量还使用两个计时器事件。
When L_DAT_packet_time has timed out, the following step MUST be done:
当L_DAT_数据包时间超时时，必须执行以下步骤：
1. If L_DAT_last_pkt_seqno = UNDEFINED, then:
1. 如果L_DAT_last_pkt_seqno=未定义，则：
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_数据包丢失间隔：=L_数据包丢失间隔+1。
3. L_DAT_packet_time := L_DAT_packet_time + L_DAT_hello_interval.
3. L_数据包时间：=L_数据包时间+L_数据包你好时间间隔。
Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link Set entries MUST be recalculated:
在每个DAT_刷新_间隔后，必须重新计算所有链接集条目中的所有L_in_度量值：
1. sum_received := sum(L_DAT_received).
1. 收到的金额：=收到的金额（L金额）。
2. sum_total := sum(L_DAT_total).
2. 总和：=总和（L数据总和）。
3. If L_DAT_hello_interval != UNDEFINED and L_DAT_lost_packet_intervals > 0, then:
3. 如果L_DAT_hello_interval！=未定义且L_数据丢失_数据包间隔>0，则：
* lost_time_proportion := L_DAT_hello_interval * L_DAT_lost_packet_intervals / DAT_MEMORY_LENGTH.
* 丢失时间比例：=L_数据\u你好\u间隔*L_数据\u丢失数据包\u间隔/DAT内存\u长度。
* sum_received := sum_received * MAX(0, 1 - lost_time_proportion);
* 接收的总时间：=接收的总时间*最大值（0，1-损失的总时间比例）；
4. If sum_received < 1, then:
4. 如果收到的和小于1，则：
L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181], Section 5.6.1.
L_in_度量：=最大_度量，如[RFC7181]第5.6.1节所定义。
5. Otherwise:
5. 否则：
* loss := MIN(sum_total / sum_received, DAT_MAXIMUM_LOSS).
* 损耗：=最小值（总损耗/总损耗，最大损耗）。
* bitrate := MAX(L_DAT_rx_bitrate, DAT_MINIMUM_BITRATE).
* 比特率：=最大值（L_DAT_rx_比特率，DAT_最小比特率）。
* L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate / DAT_MINIMUM_BITRATE).
* L_in_度量：=（2^24/DAT_最大损失）*损失/（比特率/DAT_最小比特率）。
6. remove(L_DAT_total)
6. 移除（L_DAT_总计）
7. add(L_DAT_total, 0)
7. 加（L_DAT_总计，0）
8. remove(L_DAT_received)
8. 移除（收到L_数据）
9. add(L_DAT_received, 0)
9. 添加（已收到的数据，0）
The calculated L_in_metric value should be stabilized by a hysteresis function. See Appendix D for an example.
计算的L_in_度量值应通过滞后函数稳定。示例见附录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_度量值可能会减少传入流量，而广告较低的L_In_度量值可能会增加传入流量。
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被动监控以测量链路质量的控制流量完整性的潜在攻击。例如，攻击者可能假冒他人并使用错误的序列号注入数据包。[RFC5444]数据包的真正发起人可以通过向每个数据包添加ICV数据包TLV和时间戳数据包TLV[RFC7182]来防止这种攻击。这允许接收方丢弃所有具有伪造数据包源的传入数据包，包括攻击者生成的数据包或重播的数据包。但是，[RFC7183]中描述的安全机制不保护DAT度量使用的序列号，因为它只对[RFC5444]消息进行签名，而不是[RFC5444]数据包头（其中包含[RFC5444]数据包序列号）。
[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，“通用移动自组网（MANET）数据包/消息格式”，RFC 5444，DOI 10.17487/RFC54442009年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，“在移动自组网（MANET）中表示多值时间”，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，“移动自组织网络（MANET）邻域发现协议（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，“优化链路状态路由协议版本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]Clausen，T.，Ed.和P.Jacquet，Ed.，“优化链路状态路由协议（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.，Clausen，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，“邻域发现协议（NHDP）和优化链路状态路由协议版本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：使用带有外部无线电的定向广播时间度量”，爱思唯尔计算机网络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，“动态链路交换协议（DLEP）”，正在进行的工作，草案-ietf-manet-DLEP-22，2016年4月。
[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，“移动自组网的更好方法（B.A.T.M.A.N.）”，正在进行的工作，草稿-Wunderlich-openmesh-manet-routing-00，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，“多无线电多跳无线网状网络中的路由”，MOBICOM会议记录，DOI 10.1145/1023720.1023732，2004年。
[OLSR.org] "OLSR.org Wiki", <http://www.olsr.org/>.
[OLSR.org]“OLSR.org维基”<http://www.olsr.org/>.
[FREIFUNK] "Freifunk Wireless Community Networks", <http://www.freifunk.net>.
[FREIFUNK]“FREIFUNK无线社区网络”<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分钟的丢包统计间隔可能是一个很好的折衷方案，但对于其他移动自组网来说，间隔可能太大或太小。需要更多数据来验证或改进当前参数选择。
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。[蝙蝠侠]无线社区网络，数百个路由器永久运行。例如，奥地利的维也纳Funkfeuer网络由400个路由器组成，覆盖整个维也纳市及其以外地区，直径约40公里。自2003年以来，它一直为用户提供互联网接入。维也纳Funkfeuer网络的一个特殊性是，它通过一个城市范围内的大规模Wi-Fi移动自组网提供互联网接入，只需一个互联网上行链路。
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]在这些网络上的运行经验表明，使用跳数作为路由度量会导致网络性能不理想。因此，2004年在柏林Freifunk网络和维也纳Funkfeuer网络中并行进行了ETX度量[MOBICOM03]的实验，结果令人满意，即非常容易实施，并提供了足够好的性能。这一指标已经在这些网络中使用了几年。
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度量使用滑动窗口来计算合理稳定的帧丢失，但实现可能会选择集成额外的滞后，以防止两个值之间出现不希望出现的振荡（即度量摆动）。
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计算部分损失率。“损失：=sum_total/sum_received”的分数可能会由于sum_total或sum_received的最小变化而导致公布的L_in_度量的微小波动，这可能会导致不良的协议搅动。
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 Gbit/s之间。
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 |
+---------------------------+-----------+
+---------------------------+-----------+
| 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:DAT链路成本示例
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 |
+---------+------+---------------+
+---------+------+---------------+
| Metric | hops | average bit/s |
+---------+------+---------------+
| 4 | 2 | 1 Gbit/s |
| | | |
| 4000000 | 6 | 3 kbit/s |
+---------+------+---------------+
Table 3: DAT Link Cost Examples
表3:DAT链路成本示例
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.
作者要感谢来自柏林Freifunk[Freifunk]和维也纳Funkfeuer[Funkfeuer]的网络管理员，感谢他们为改进OLSR.org路由守护程序原始ETX度量的质量而进行了长时间的测试并提出了建议。
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.
这项工作/活动得到了欧洲共同体框架计划7（未来互联网研究和实验计划（FIRE））的支持，该计划是未来互联网社区网络试验台（[CONMICT]），合同FP7-288535。
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（无限网络）、Juliusz Chroboczek（PPS，巴黎第七大学）、Thomas Clausen、Christopher Dearlove（BAE系统高级技术中心）、Ulrich Herberg（美国富士通实验室）、Markus Kittenberger（维也纳Funkfeuer）、Joseph Macker（海军研究实验室）、Fabian Nack（柏林弗雷大学）和Stan Ratliff（思科系统）。
Authors' Addresses
作者地址
Henning Rogge Fraunhofer FKIE
亨宁·罗格·弗劳恩霍夫
Email: henning.rogge@fkie.fraunhofer.de
URI: http://www.fkie.fraunhofer.de
Email: henning.rogge@fkie.fraunhofer.de
URI: http://www.fkie.fraunhofer.de
Emmanuel Baccelli INRIA
伊曼纽尔杆菌
Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/