draft-ietf-manet-olsrv2-dat-metric-09.txt   draft-ietf-manet-olsrv2-dat-metric-10.txt 
MANET H. Rogge MANET H. Rogge
Internet-Draft Fraunhofer FKIE Internet-Draft Fraunhofer FKIE
Intended status: Experimental E. Baccelli Intended status: Experimental E. Baccelli
Expires: May 16, 2016 INRIA Expires: May 27, 2016 INRIA
November 13, 2015 November 24, 2015
Packet Sequence Number based directional airtime metric for OLSRv2 Packet Sequence Number based directional airtime metric for OLSRv2
draft-ietf-manet-olsrv2-dat-metric-09 draft-ietf-manet-olsrv2-dat-metric-10
Abstract Abstract
This document specifies an directional airtime link metric for usage This document specifies an Directional Airtime (DAT) link metric for
in OLSRv2. usage in OLSRv2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2016. This Internet-Draft will expire on May 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Directional Airtime Metric Rationale . . . . . . . . . . . . 5 4. Directional Airtime Metric Rationale . . . . . . . . . . . . 5
5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7
6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 8
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8 7.1. Recommended Values . . . . . . . . . . . . . . . . . . . 8
8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9
9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10
9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Requirements for using DAT metric in OLSRv2 9.2. Requirements for using DAT metric in OLSRv2
implementations . . . . . . . . . . . . . . . . . . . . . 10 implementations . . . . . . . . . . . . . . . . . . . . . 10
9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 11 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 11
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11
10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12
10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 12 10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 12
skipping to change at page 2, line 40 skipping to change at page 2, line 40
13.2. Informative References . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Future work . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Future work . . . . . . . . . . . . . . . . . . . . 16
Appendix B. OLSR.org metric history . . . . . . . . . . . . . . 17 Appendix B. OLSR.org metric history . . . . . . . . . . . . . . 17
Appendix C. Linkspeed stabilization . . . . . . . . . . . . . . 18 Appendix C. Linkspeed stabilization . . . . . . . . . . . . . . 18
Appendix D. Packet loss hysteresis . . . . . . . . . . . . . . . 18 Appendix D. Packet loss hysteresis . . . . . . . . . . . . . . . 18
Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 18 Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
One of the major shortcomings of OLSR [RFC3626] is the lack of a One of the major shortcomings of Optimized Link State Routing (OLSR)
granular link cost metric between OLSR routers. Operational [RFC3626] is the lack of a granular link cost metric between OLSR
experience with OLSR networks gathered since its publication has routers. Operational experience with OLSR networks gathered since
revealed that wireless networks links can have highly variable and its publication has revealed that wireless networks links can have
heterogeneous properties. This makes a hopcount metric insufficient highly variable and heterogeneous properties. This makes a hopcount
for effective OLSR routing. metric insufficient for effective OLSR routing.
Based on this experience, OLSRv2 [RFC7181] integrates the concept of Based on this experience, OLSRv2 [RFC7181] integrates the concept of
link metrics directly into the core specification of the routing link metrics directly into the core specification of the routing
protocol. The OLSRv2 routing metric is an external process, it can protocol. The OLSRv2 routing metric is an external process, it can
be any kind of dimensionless additive cost function which reports to be any kind of dimensionless additive cost function which reports to
the OLSRv2 protocol. the OLSRv2 protocol.
Since 2004 the OLSR.org [OLSR.org] implementation of OLSR included an Since 2004 the OLSR.org [OLSR.org] implementation of OLSR included an
Estimated Transmission Count (ETX) metric [MOBICOM04] as a Estimated Transmission Count (ETX) metric [MOBICOM04] as a
proprietary extension. While this metric is not perfect, it proved proprietary extension. While this metric is not perfect, it proved
to be sufficient for a long time for Community Mesh Networks to be sufficient for a long time for Community Mesh Networks
(Appendix B). But the increasing maximum data rate of IEEE 802.11 (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 made the ETX metric less efficient than in the past, which is one
reason to move to a different metric. reason to move to a different metric.
This document describes a Directional Airtime routing metric for This document describes a Directional Airtime routing metric for
OLSRv2, a successor of the ETX-derived OLSR.org 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 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. provide a more accurate picture of the links within the network.
This experimental draft will allow OLSRv2 deployments with a metric This experimental draft will allow OLSRv2 deployments with a metric
defined by the IETF Manet group. It enables easier interoperability defined by the IETF Manet group. It enables easier interoperability
tests between implementations and will also deliver an useful tests between implementations and will also deliver a useful baseline
baseline to compare other metrics to. Appendix A contains a few to compare other metrics to. Appendix A contains a few possible
possible steps to improve the DAT metric. steps to improve the Directional Airtime Metric.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The terminology introduced in [RFC5444], [RFC7181] and [RFC6130], The terminology introduced in [RFC5444], [RFC7181] and [RFC6130],
including the terms "packet", "message" and "TLV" are to be including the terms "packet", "message" and "TLV" are to be
interpreted as described therein. interpreted as described therein.
Additionally, this document uses the following terminology and Additionally, this document uses the following terminology and
notational conventions: notational conventions:
DAT - Directional Airtime (Metric), the link metric described in
this document, which is a directional variant of ETT. It does not
take reverse path loss into account.
QUEUE - a first in, first out queue of integers. QUEUE - a first in, first out queue of integers.
QUEUE[TAIL] - the most recent element in the queue. QUEUE[TAIL] - the most recent element in the queue.
add(QUEUE, value) - adds a new element to the TAIL of the queue. add(QUEUE, value) - adds a new element to the TAIL of the queue.
remove(QUEUE) - removes the HEAD element of the queue remove(QUEUE) - removes the HEAD element of the queue
sum(QUEUE) - an operation which returns the sum of all elements in a sum(QUEUE) - an operation which returns the sum of all elements in a
QUEUE. QUEUE.
diff_seqno(new, old) - an operation which returns the positive diff_seqno(new, old) - an operation which returns the positive
distance between two elements of the circular sequence number distance between two elements of the circular sequence number
space defined in section 5.1 of [RFC5444]. Its value is either 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 (new - old) if this result is positive, or else its value is (new
- old + 65536). - old + 65536).
MAX(a,b) - the maximum of a and b. MAX(a, b) - the maximum of a and b.
MIN(a, b) - the minimum of a and b.
UNDEFINED - a value not in the normal value range of a variable. UNDEFINED - a value not in the normal value range of a variable.
airtime - the time a transmitted packet blocks the link layer, e.g., airtime - the time a transmitted packet blocks the link layer, e.g.,
a wireless link. a wireless link.
ETX - Expected Transmission Count, a link metric proportional to the ETX - Expected Transmission Count, a link metric proportional to the
number of transmissions to successfully send an IP packet over a number of transmissions to successfully send an IP packet over a
link. link.
ETT - Estimated Travel Time, a link metric proportional to the ETT - Estimated Travel Time, a link metric proportional to the
amount of airtime needed to transmit an IP packet over a link, not amount of airtime needed to successfully transmit an IP packet
considering layer-2 overhead created by preamble, backoff time and over a link, not considering layer-2 overhead created by preamble,
queuing. backoff time and queuing.
DAT - Directional Airtime Metric, the link metric described in this
document, which is a directional variant of ETT. It does not take
reverse path loss into account.
3. Applicability Statement 3. Applicability Statement
The Directional Airtime Metric was designed and tested (see The Directional Airtime Metric was designed and tested (see
[olsrv2_paper]) in wireless IEEE 802.11 OLSRv2 [RFC7181] networks. [olsrv2_paper]) in wireless IEEE 802.11 OLSRv2 [RFC7181] networks.
These networks employ link layer retransmission to increase the These networks employ link layer retransmission to increase the
delivery probability and multiple unicast data rates. delivery probability. A dynamic rate selection algorithm selects the
unicast data rate independently for each neighbor.
As specified in OLSRv2 the metric calculates only the incoming link As specified in OLSRv2, the metric calculates only the incoming link
cost. It does neither calculate the outgoing metric, nor does it cost. It does neither calculate the outgoing metric, nor does it
decide the link status (heard, symmetric, lost). decide the link status (heard, symmetric, lost).
The metric works both for nodes which can send/receive [RFC5444] The metric works both for nodes which can send/receive [RFC5444]
packet sequence numbers and such which do not have this capability. packet sequence numbers and those which do not have this capability.
In the absence of such sequence numbers the metric calculates the In the absence of such sequence numbers the metric calculates the
packet loss based on [RFC6130] HELLO message timeouts. packet loss based on [RFC6130] HELLO message timeouts.
The metric must learn about the unicast data rate towards each one- The metric must learn about the unicast data rate towards each one-
hop neighbor from an external process, either by configuration or by hop neighbor from an external process, either by configuration or by
an external measurement process. This measurement could be done by an external measurement process. This measurement could be done by
gathering cross-layer data from the operating system or an external gathering cross-layer data from the operating system or an external
daemon like DLEP [DLEP], but also by indirect layer-3 measurements daemon like DLEP [DLEP], but also by indirect layer-3 measurements
like packet-pair. like packet-pair (see [MOBICOM04]).
The metric uses RFC5444 multicast control traffic to determine the The metric uses [RFC5444] multicast control traffic to determine the
link packet loss. The administrator should take care that link layer link packet loss. The administrator should take care that link layer
multicast transmission do not not have a higher reception probability multicast transmission do not have a higher reception probability
than the slowest unicast transmission. It might, for example in than the slowest unicast transmission without retransmission. It
802.11g, be necessary to increase the data-rate of the multicast might, for example in 802.11g, be necessary to increase the data-rate
transmissions, e.g. set the multicast data-rate to 6 MBit/s. of the multicast transmissions, e.g. set the multicast data-rate to 6
MBit/s.
The metric can only handle a certain range of packet loss and unicast 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 data-rate. The maximum packet loss that can be encoded into the
metric a loss of 7 of 8 packets, without link layer retransmissions. metric a loss of 7 of 8 packets (87.5%), without link layer
The unicast data-rate that can be encoded by this metric can be retransmissions. The unicast data-rate that can be encoded by this
between 1 kBit/s and 2 GBit/s. This metric has been designed for metric can be between 1 kBit/s and 2 GBit/s. This metric has been
data-rates of 1 MBit/s and hundreds of MBit/s. designed for data-rates of 1 MBit/s and hundreds of MBit/s.
4. Directional Airtime Metric Rationale 4. Directional Airtime Metric Rationale
The Directional Airtime Metric has been inspired by the publications The Directional Airtime Metric has been inspired by the publications
on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from
both of these in several ways. both of these in several ways.
Instead of measuring the combined loss probability of a bidirectional Instead of measuring the combined loss probability of a bidirectional
transmission of a packet over a link in both directions, the transmission of a packet over a link in both directions, the
Directional Airtime Metric measures the incoming loss rate and Directional Airtime Metric measures the incoming loss rate and
skipping to change at page 7, line 20 skipping to change at page 7, line 24
The metric value is then used as L_in_metric of the Link Set (as The metric value is then used as L_in_metric of the Link Set (as
defined in section 8.1. of [RFC7181]). defined in section 8.1. of [RFC7181]).
While this document does not add new RFC5444 elements to the RFC6130 While this document does not add new RFC5444 elements to the RFC6130
HELLO or RFC7181 TC messages, it works best when both the HELLO or RFC7181 TC messages, it works best when both the
INTERVAL_TIME message TLV is present in the HELLO messages and when INTERVAL_TIME message TLV is present in the HELLO messages and when
each RFC5444 packet contains an interface specific sequence number. each RFC5444 packet contains an interface specific sequence number.
It also adds a number of new data entries to be stored for each It also adds a number of new data entries to be stored for each
RFC6130 Link. RFC6130 Link.
6. Protocol Parameters 6. Protocol Constants
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 MANET's with a very slow
or very fast link layer. See Appendix D Appendix E for example
metric values.
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_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing
metric.
+---------------------+-------+
| Name | Value |
+---------------------+-------+
| DAT_MAXIMUM_LOSS | 8 |
| | |
| DAT_MINIMUM_BITRATE | 1000 |
+---------------------+-------+
Table 1: DAT Protocol Constants
7. Protocol Parameters
This specification defines the following parameters for this routing This specification defines the following parameters for this routing
metric. These parameters are: metric. These parameters are:
DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All
received and lost packets within the queue length are used to received and lost packets within the queue length are used to
calculate the cost of the link. calculate the cost of the link.
DAT_REFRESH_INTERVAL - interval in seconds between two metric DAT_REFRESH_INTERVAL - interval in seconds between two metric
recalculations as described in Section 10.2. This value SHOULD be recalculations as described in Section 10.2. This value SHOULD be
skipping to change at page 7, line 44 skipping to change at page 8, line 29
DAT_HELLO_TIMEOUT_FACTOR - multiplier relative to the HELLO_INTERVAL DAT_HELLO_TIMEOUT_FACTOR - multiplier relative to the HELLO_INTERVAL
(see [RFC6130] Section 5.3.1) after which the DAT metric considers (see [RFC6130] Section 5.3.1) after which the DAT metric considers
a HELLO as lost. a HELLO as lost.
DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets
(based on received packet sequence numbers) at which point the (based on received packet sequence numbers) at which point the
router considers the neighbor has restarted. This parameter is router considers the neighbor has restarted. This parameter is
only used for packet sequence number based loss estimation. This only used for packet sequence number based loss estimation. This
number MUST be larger than DAT_MAXIMUM_LOSS. number MUST be larger than DAT_MAXIMUM_LOSS.
6.1. Recommended Values 7.1. Recommended Values
The proposed values of the protocol parameters are for Community Mesh The proposed values of the protocol parameters are for Community Mesh
Networks, which mostly use immobile routers. Using this metric for Networks, which mostly use immobile routers. Using this metric for
mobile networks might require shorter DAT_REFRESH_INTERVAL and/or mobile networks might require shorter DAT_REFRESH_INTERVAL and/or
DAT_MEMORY_LENGTH. 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
7. Protocol Constants
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 MANET's with a very slow
or very fast linklayer. See Appendix D Appendix E for example metric
values.
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_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing
metric.
+---------------------+-------+
| Name | Value |
+---------------------+-------+
| DAT_MAXIMUM_LOSS | 8 |
| | |
| DAT_MINIMUM_BITRATE | 1000 |
+---------------------+-------+
Table 1: DAT Protocol Constants
8. Data Structures 8. Data Structures
This specification extends the Link Set of the Interface Information This specification extends the Link Set of the Interface Information
Base, as defined in [RFC6130] section 7.1, by the adding the Base, as defined in [RFC6130] section 7.1, by the adding the
following elements to each link tuple: following elements to each link tuple:
L_DAT_received - a QUEUE with DAT_MEMORY_LENGTH integer elements. L_DAT_received - a QUEUE with DAT_MEMORY_LENGTH integer elements.
Each entry contains the number of successfully received packets Each entry contains the number of successfully received packets
within an interval of DAT_REFRESH_INTERVAL. within an interval of DAT_REFRESH_INTERVAL.
skipping to change at page 13, line 15 skipping to change at page 13, line 21
2. sum_received := sum_received * MAX ( 0, 1 - 2. sum_received := sum_received * MAX ( 0, 1 -
lost_time_proportion); lost_time_proportion);
4. If sum_received < 1, then: 4. If sum_received < 1, then:
1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181] 1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181]
section 5.6.1. section 5.6.1.
5. Otherwise: 5. Otherwise:
1. loss := sum_total / sum_received. 1. loss := MIN(sum_total / sum_received, DAT_MAXIMUM_LOSS).
2. If loss > DAT_MAXIMUM_LOSS, then:
1. loss := DAT_MAXIMUM_LOSS.
3. bitrate := L_DAT_rx_bitrate.
4. If bitrate < DAT_MINIMUM_BITRATE, then:
1. bitrate := DAT_MINIMUM_BITRATE. 2. bitrate := MAX(L_DAT_rx_bitrate, DAT_MINIMUM_BITRATE).
5. L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate / 3. L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate /
DAT_MINIMUM_BITRATE). DAT_MINIMUM_BITRATE).
6. remove(L_DAT_total) 6. remove(L_DAT_total)
7. add(L_DAT_total, 0) 7. add(L_DAT_total, 0)
8. remove(L_DAT_received) 8. remove(L_DAT_received)
9. add(L_DAT_received, 0) 9. add(L_DAT_received, 0)
skipping to change at page 13, line 51 skipping to change at page 13, line 49
11. Security Considerations 11. Security Considerations
Artificial manipulation of metrics values can drastically alter Artificial manipulation of metrics values can drastically alter
network performance. In particular, advertising a higher L_in_metric network performance. In particular, advertising a higher L_in_metric
value may decrease the amount of incoming traffic, while advertising value may decrease the amount of incoming traffic, while advertising
lower L_in_metric may increase the amount of incoming traffic. By lower L_in_metric may increase the amount of incoming traffic. By
artificially increasing or decreasing the L_in_metric values it artificially increasing or decreasing the L_in_metric values it
advertises, a rogue router may thus attract or repulse data traffic. advertises, a rogue router may thus attract or repulse data traffic.
A rogue router may then potentially degrade data throughput by not A rogue router may then potentially degrade data throughput by not
forwarding data as it should or redirecting traffic into routing forwarding data as it should or redirecting traffic into routing
loops or bad links. loops or bad links. It might also attract traffic for "Man in the
Middle" attacks or traffic analysis.
An attacker might also inject packets with incorrect packet level An attacker might also inject packets with incorrect packet level
sequence numbers, pretending to be somebody else. This attack can be sequence numbers, pretending to be somebody else. This attack can be
prevented by the true originator of the RFC5444 packets by adding a prevented by the true originator of the RFC5444 packets by adding a
[RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet.
This allows the receiver to drop all incoming packets which have a This allows the receiver to drop all incoming packets which have a
forged packet source, both packets generated by the attacker or forged packet source, both packets generated by the attacker or
replayed packets. The signature scheme described in [RFC7183] does replayed packets. The security mechanism described in [RFC7183] does
not protect the additional sequence number of the DAT metric because not protect the additional sequence number of the DAT metric because
it does only sign the RFC5444 messages, not the RFC5444 packet it does only sign the RFC5444 messages, not the RFC5444 packet
header. header.
Protection against "Man in the Middle" attacks are out of scope of
this document.
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the network administrators from The authors would like to acknowledge the network administrators from
Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for
endless hours of testing and suggestions to improve the quality of endless hours of testing and suggestions to improve the quality of
the original ETX metric for the OLSR.org routing daemon. the original ETX metric for the OLSR.org routing daemon.
This effort/activity is supported by the European Community Framework This effort/activity is supported by the European Community Framework
Program 7 within the Future Internet Research and Experimentation Program 7 within the Future Internet Research and Experimentation
Initiative (FIRE), Community Networks Testbed for the Future Internet Initiative (FIRE), Community Networks Testbed for the Future Internet
skipping to change at page 18, line 45 skipping to change at page 18, line 49
fluctuations in the advertised L_in_metric due to minimal changes in fluctuations in the advertised L_in_metric due to minimal changes in
sum_total or sum_received which can cause undesirable protocol churn. sum_total or sum_received which can cause undesirable protocol churn.
A hysteresis function applied to the fraction could reduce the amount A hysteresis function applied to the fraction could reduce the amount
of changes in the loss rate and help to stabilize the metric output. of changes in the loss rate and help to stabilize the metric output.
Appendix E. Example DAT values Appendix E. Example DAT values
The DAT metric value can be expressed in terms of link speed (bit/s) 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 or used airtime (s). When using the default protocol constants (see
Section 7), DAT encodes link speeds between 119 bit/s and 2 Gbit/s. Section 6), DAT encodes link speeds between 119 bit/s and 2 Gbit/s.
Table Table 2 contains a few examples for metric values and their Table Table 2 contains a few examples for metric values and their
meaning as a link speed: meaning as a link speed:
+---------------------------+-----------+ +---------------------------+-----------+
| Metric | bit/s | | Metric | bit/s |
+---------------------------+-----------+ +---------------------------+-----------+
| MINIMUM_METRIC (1) | 2 Gbit/s | | MINIMUM_METRIC (1) | 2 Gbit/s |
| | | | | |
| MAXIMUM_METRIC (16776960) | 119 bit/s | | MAXIMUM_METRIC (16776960) | 119 bit/s |
 End of changes. 29 change blocks. 
82 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/