draft-ietf-manet-olsrv2-dat-metric-06.txt   draft-ietf-manet-olsrv2-dat-metric-07.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: January 30, 2016 INRIA Expires: May 5, 2016 INRIA
July 29, 2015 November 2, 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-06 draft-ietf-manet-olsrv2-dat-metric-07
Abstract Abstract
This document specifies an directional airtime link metric for usage This document specifies an directional airtime link metric for usage
in OLSRv2. 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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 January 30, 2016. This Internet-Draft will expire on May 5, 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 21 skipping to change at page 2, line 21
5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7
6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 10 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
10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15 Appendix A. Future work . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16 Appendix B. OLSR.org metric history . . . . . . . . . . . . . . 17
Appendix C. Packet loss hysteresis . . . . . . . . . . . . . . . 17 Appendix C. Linkspeed stabilization . . . . . . . . . . . . . . 18
Appendix D. Example DAT values . . . . . . . . . . . . . . . . . 17 Appendix D. Packet loss hysteresis . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 18
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 OLSR [RFC3626] is the lack of a
granular link cost metric between OLSR routers. Operational granular link cost metric between OLSR routers. Operational
experience with OLSR networks gathered since the publication of OLSR experience with OLSR networks gathered since its publication has
has revealed that wireless networks links can have highly variable revealed that wireless networks links can have highly variable and
and heterogeneous properties. This makes a hopcount metric heterogeneous properties. This makes a hopcount metric insufficient
insufficient for effective OLSR routing. 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 A). 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 ETX-derived OLSR.org 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 an useful
baseline to compare other metrics to. baseline to compare other metrics to. Appendix A contains a few
possible steps to improve the DAT metric.
2. Terminology 2. Terminology
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
and 'OPTIONAL' in this document are to be interpreted as described in document are to be interpreted as described in [RFC2119].
[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:
QUEUE - a first in, first out queue of integers. QUEUE - a first in, first out queue of integers.
skipping to change at page 4, line 27 skipping to change at page 4, line 27
amount of airtime needed to transmit an IP packet over a link, not amount of airtime needed to transmit an IP packet over a link, not
considering layer-2 overhead created by preamble, backoff time and considering layer-2 overhead created by preamble, backoff time and
queuing. queuing.
DAT - Directional Airtime Metric, the link metric described in this DAT - Directional Airtime Metric, the link metric described in this
document, which is a directional variant of ETT. It does not take document, which is a directional variant of ETT. It does not take
reverse path loss into account. reverse path loss into account.
3. Applicability Statement 3. Applicability Statement
The Directional Airtime Metric was designed and tested in wireless The Directional Airtime Metric was designed and tested (see
IEEE 802.11 [RFC7181] networks. These networks employ link layer [olsrv2_paper]) in wireless IEEE 802.11 OLSRv2 [RFC7181] networks.
retransmission to increase the delivery probability and multiple These networks employ link layer retransmission to increase the
unicast data rates. delivery probability and multiple unicast data rates.
As specified in [RFC7181] the metric calculates only the incoming As specified in OLSRv2 the metric calculates only the incoming link
link cost. It does neither calculate the outgoing metric, nor does cost. It does neither calculate the outgoing metric, nor does it
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 such 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.
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 not have a higher reception probability
than the slowest unicast transmission. It might, for example in than the slowest unicast transmission. It might, for example in
802.11g, be necessary to increase the data-rate of the multicast 802.11g, be necessary to increase the data-rate of the multicast
transmissions, e.g. set the multicast data-rate to 6 MBit/s. 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, without link layer retransmissions.
The unicast data-rate that can be encoded by this metric can be The unicast data-rate that can be encoded by this metric can be
skipping to change at page 5, line 45 skipping to change at page 5, line 45
o Incoming packet loss and linkspeed can be measured locally, o Incoming packet loss and linkspeed can be measured locally,
symmetric link loss would need an additional signaling TLV in the symmetric link loss would need an additional signaling TLV in the
[RFC6130] HELLO and would delay metric calculation by up to one [RFC6130] HELLO and would delay metric calculation by up to one
HELLO interval. HELLO interval.
The Directional Airtime Metric does not integrate the packet size The Directional Airtime Metric does not integrate the packet size
into the link cost. Doing so is not feasible in most link-state into the link cost. Doing so is not feasible in most link-state
routing protocol implementations. The routing decision of most routing protocol implementations. The routing decision of most
operation systems don't take packet size into account. Multiplying operation systems don't take packet size into account. Multiplying
all link costs of a topology with the size of a data-plane packet all link costs of a topology with the size of a data-plane packet
would never change the dijkstra result anyways. would never change the Dijkstra result anyways.
The queue based packet loss estimator has been tested extensively in The queue based packet loss estimator has been tested extensively in
the OLSR.org ETX implementation, see Appendix A. The output is the the OLSR.org ETX implementation, see Appendix B. The output is the
average of the packet loss over a configured time period. average of the packet loss over a configured time period.
The metric normally measures the loss of a link by tracking the The metric normally measures the loss of a link by tracking the
incoming [RFC5444] packet sequence numbers. Without these packet incoming [RFC5444] packet sequence numbers. Without these packet
sequence numbers, the metric does calculate the loss of the link sequence numbers, the metric does calculate the loss of the link
based of received and lost [RFC5444] HELLO messages. It uses the based of received and lost [RFC5444] HELLO messages. It uses the
incoming HELLO interval time (or if not present, the validity time) incoming HELLO interval time (or if not present, the validity time)
to decide when a HELLO is lost. to decide when a HELLO is lost.
When a neighbor router resets, its packet sequence number might jump When a neighbor router resets, its packet sequence number might jump
to a random value. The metric tries to detect jumps in the packet to a random value. The metric tries to detect jumps in the packet
sequence number and removes them from the data set, because the sequence number and removes them from the data set, because the
already gathered link loss data should still be valid. The link loss already gathered link loss data should still be valid (see
data is only removed from memory when a Link times out completely and Section 9.3. The link loss data is only removed from memory when a
its Link Set tuple is removed from the database. Link times out completely and its Link Set tuple is removed from the
database.
5. Metric Functioning & Overview 5. Metric Functioning & Overview
The Directional Airtime Metric is calculated for each link set entry, The Directional Airtime Metric is calculated for each link set entry,
as defined in [RFC6130] section 7.1. as defined in [RFC6130] section 7.1.
The metric processes two kinds of data into the metric value, namely 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 packet loss rate and link-speed. The link-speed is taken from an
external process not defined in this document. The current packet external process not defined in this document. The current packet
loss rate is defined in this document by keeping track of packet loss rate is defined in this document by keeping track of packet
skipping to change at page 7, line 13 skipping to change at page 7, line 13
lost HELLO intervals. lost HELLO intervals.
The average packet loss ratio is calculated as the sum of the 'total The average packet loss ratio is calculated as the sum of the 'total
packets' counters divided by the sum of the 'packets received' packets' counters divided by the sum of the 'packets received'
counters. This value is then divided through the current link-speed counters. This value is then divided through the current link-speed
and then scaled into the range of metrics allowed for OLSRv2. and then scaled into the range of metrics allowed for OLSRv2.
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
HELLO or RFC7181 TC messages, 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.
6. Protocol Parameters 6. Protocol Parameters
This specification defines two constants, agreement on which is This specification defines the following parameters for this routing
required, from all the OLSRv2 routers participating in the same metric. These parameters are:
deployment. Two routers which use different values for these
constants will not be able to generate metric values which can be
correctly interpreted by both. These constants 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 are used to calculate received and lost packets within the queue length are used to
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
smaller than a typical HELLO interval. smaller than a typical HELLO interval. The interval can be a
fraction of a second.
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.
skipping to change at page 8, line 11 skipping to change at page 8, line 16
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 7. Protocol Constants
This specification defines the following constants, which define the This specification defines the following constants, which define the
range of metric values that can be encoded by the DAT metric (see range of metric values that can be encoded by the DAT metric (see
Table 1). They cannot be changed without making the metric outputs Table 1). They cannot be changed without making the metric outputs
incomparable and should only be changed for MANET's with a very slow incomparable and should only be changed for MANET's with a very slow
or very fast linklayer. 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 DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing
metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and
(DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS. (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS.
DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing
metric. metric.
+---------------------+-------+ +---------------------+-------+
| Name | Value | | Name | Value |
skipping to change at page 8, line 36 skipping to change at page 8, line 42
+---------------------+-------+ +---------------------+-------+
Table 1: DAT Protocol Constants 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 is 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.
L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements. L_DAT_total - a QUEUE with DAT_MEMORY_LENGTH integer elements. Each
Each entry contains the estimated number of packets transmitted by entry contains the estimated number of packets transmitted by the
the neighbor, based on the received packet sequence numbers within neighbor, based on the received packet sequence numbers within an
an interval of DAT_REFRESH_INTERVAL. interval of DAT_REFRESH_INTERVAL.
L_DAT_packet_time is the time when the next RFC5444 packet should L_DAT_packet_time - the time when the next RFC5444 packet should
have arrived. have arrived.
L_DAT_hello_interval is the interval between two hello messages of L_DAT_hello_interval - the interval between two hello messages of
the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497]
of NHDP messages [RFC6130]. of NHDP messages [RFC6130].
L_DAT_lost_packet_intervals is the estimated number of HELLO L_DAT_lost_packet_intervals - the estimated number of HELLO
intervals from this neighbor the metric has not received a single intervals from this neighbor the metric has not received a single
packet. packet.
L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic L_DAT_rx_bitrate - the current bitrate of incoming unicast traffic
for this neighbor. for this neighbor.
L_DAT_last_pkt_seqno is the last received packet sequence number L_DAT_last_pkt_seqno - the last received packet sequence number
received from this link. received from this link.
Methods to obtain the value of L_DAT_rx_bitrate are out of the scope Methods to obtain the value of L_DAT_rx_bitrate are out of the scope
of this specification. Such methods may include static configuration of this specification. Such methods may include static configuration
via a configuration file or dynamic measurement through mechanisms via a configuration file or dynamic measurement through mechanisms
described in a separate specification (e.g. [DLEP]). Any Link tuple described in a separate specification (e.g. [DLEP]). Any Link tuple
with L_status = HEARD or L_status = SYMMETRIC MUST have a specified 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. value of L_DAT_rx_bitrate if it is to be used by this routing metric.
The incoming bitrate value should be stabilized by a hysteresis
filter to improve the stability of this metric. See Appendix B
Appendix C for an example.
This specification updates the L_in_metric field of the Link Set of This specification updates the L_in_metric field of the Link Set of
the Interface Information Base, as defined in section 8.1. of the Interface Information Base, as defined in section 8.1. of
[RFC7181]) [RFC7181])
8.1. Initial Values 8.1. Initial Values
When generating a new tuple in the Link Set, as defined in [RFC6130] When generating a new tuple in the Link Set, as defined in [RFC6130]
section 12.5 bullet 3, the values of the elements specified in section 12.5 bullet 3, the values of the elements specified in
Section 8 are set as follows: Section 8 are set as follows:
skipping to change at page 10, line 37 skipping to change at page 10, line 43
document SHOULD include the following parts into its [RFC5444] document SHOULD include the following parts into its [RFC5444]
output: output:
o an INTERVAL_TIME message TLV in each HELLO message, as defined in o an INTERVAL_TIME message TLV in each HELLO message, as defined in
[RFC6130] section 4.3.2. [RFC6130] section 4.3.2.
o an interface specific packet sequence number as defined in o an interface specific packet sequence number as defined in
[RFC5444] section 5.1 which is incremented by 1 for each outgoing [RFC5444] section 5.1 which is incremented by 1 for each outgoing
[RFC5444] packet on the interface. [RFC5444] packet on the interface.
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 ignoring 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.
9.3. Link Loss Data Gathering 9.3. Link Loss Data Gathering
For each incoming [RFC5444] packet, additional processing SHOULD be For each incoming [RFC5444] packet, additional processing SHOULD be
carried out after the packet messages have been processed as carried out after the packet messages have been processed as
specified in [RFC6130] and [RFC7181]. specified in [RFC6130] and [RFC7181] as specified in this section.
[RFC5444] packets without packet sequence number MUST NOT be [RFC5444] packets without packet sequence number MUST NOT be
processed in this way by this metric. processed in the way described in this section.
The router updates the Link Set Tuple corresponding to the originator The router updates the Link Set Tuple corresponding to the originator
of the packet: of the packet:
1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 1. If L_DAT_last_pkt_seqno = UNDEFINED, then:
1. L_DAT_received[TAIL] := 1. 1. L_DAT_received[TAIL] := 1.
2. L_DAT_total[TAIL] := 1. 2. L_DAT_total[TAIL] := 1.
2. Otherwise: 2. Otherwise:
1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1.
2. diff := seq_diff(pkt_seqno, L_DAT_last_pkt_seqno). 2. diff := diff_seqno(pkt_seqno, L_DAT_last_pkt_seqno).
3. If diff > DAT_SEQNO_RESTART_DETECTION, then: 3. If diff > DAT_SEQNO_RESTART_DETECTION, then:
1. diff := 1. 1. diff := 1.
4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff. 4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff.
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. If L_DAT_hello_interval != UNDEFINED, then:
skipping to change at page 13, line 26 skipping to change at page 13, line 38
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)
The calculated L_in_metric value should be stabilized by a hysteresis
function. See Appendix C Appendix D for an example.
11. IANA Considerations 11. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
12. Security Considerations 12. 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
skipping to change at page 14, line 33 skipping to change at page 14, line 48
Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research
Laboratory), Fabian Nack and Stan Ratliff (Cisco Systems). Laboratory), Fabian Nack and Stan Ratliff (Cisco Systems).
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", RFC 3626, October 2003.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009. Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March
2009. 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized
Link State Routing Protocol version 2", RFC 7181, April Link State Routing Protocol version 2", RFC 7181, April
2014. 2014.
14.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", RFC 3626, October 2003.
[RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check [RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check
Value and Timestamp TLV Definitions for Mobile Ad Hoc Value and Timestamp TLV Definitions for Mobile Ad Hoc
Networks (MANETs)", RFC 7182, April 2014. Networks (MANETs)", RFC 7182, April 2014.
[RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity [RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP) Protection for the Neighborhood Discovery Protocol (NHDP)
and Optimized Link State Routing Protocol Version 2 and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7183, April 2014. (OLSRv2)", RFC 7183, April 2014.
14.2. Informative References [olsrv2_paper]
C., C., C., C., J., J., J., J., and H. H., "OLSRv2 for
Community Networks: Using Directional Airtime Metric with
external radios", Elsevier Computer Networks 2015 ,
September 2015,
<http://dx.doi.org/10.1016/j.comnet.2015.09.022>.
[CONFINE] "Community Networks Testbed for the Future Internet [CONFINE] "Community Networks Testbed for the Future Internet
(CONFINE)", 2013, <http://www.confine-project.eu>. (CONFINE)", 2015, <http://www.confine-project.eu>.
[DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D.
Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", Satterwhite, "Dynamic Link Exchange Protocol (DLEP)",
draft-ietf-manet-dlep-04 , March 2013. draft-ietf-manet-dlep-17 , March 2013.
[BATMAN] Neumann, A., Aichele, C., Lindner, M., and S. Wunderlich,
"Better Approach To Mobile Ad-hoc Networking
(B.A.T.M.A.N.)", draft-wunderlich-openmesh-manet-
routing-00 , April 2008.
[MOBICOM03] [MOBICOM03]
De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A
High-Throughput Path Metric for Multi-Hop Wireless High-Throughput Path Metric for Multi-Hop Wireless
Routing", Proceedings of the MOBICOM Conference , 2003. Routing", Proceedings of the MOBICOM Conference , 2003.
[MOBICOM04] [MOBICOM04]
Richard, D., Jitendra, P., and Z. Brian, "Routing in Richard, D., Jitendra, P., and Z. Brian, "Routing in
Multi-Radio, Multi-Hop Wireless Mesh Networks", Multi-Radio, Multi-Hop Wireless Mesh Networks",
Proceedings of the MOBICOM Conference , 2004. Proceedings of the MOBICOM Conference , 2004.
[OLSR.org] [OLSR.org]
"The OLSR.org OLSR routing daemon", 2013, "The OLSR.org OLSR routing daemon", 2015,
<http://www.olsr.org/>. <http://www.olsr.org/>.
[FREIFUNK] [FREIFUNK]
"Freifunk Wireless Community Networks", 2013, "Freifunk Wireless Community Networks", 2015,
<http://www.freifunk.net>. <http://www.freifunk.net>.
[FUNKFEUER] [FUNKFEUER]
"Austria Wireless Community Network", 2013, "Austria Wireless Community Network", 2015,
<http://www.funkfeuer.at>. <http://www.funkfeuer.at>.
Appendix A. OLSR.org metric history Appendix A. Future work
As the DAT metric proved to work reasonable well for non- or slow-
moving ad hoc networks [olsrv2_paper], it should be considered as 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.
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.
The DAT metric considers only the multicast RFC5444 packet loss for
estimating the link loss, but it would be good to integrate 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.
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 not giving the recent input too much
influence, However, first experiments suggest that the algorithm
tends to be less agile 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 "quere 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.
Appendix B. OLSR.org metric history
The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR- The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR-
based [RFC3626] or B.A.T.M.A.N. based wireless community networks based [RFC3626] or B.A.T.M.A.N. [BATMAN] based wireless community
with hundreds of routers in permanent operation. The Vienna networks with hundreds of routers in permanent operation. The Vienna
Funkfeuer network in Austria, for instance, consists of 400 routers Funkfeuer network in Austria, for instance, consists of 400
(around 600 routes) covering the whole city of Vienna and beyond, routerscovering the whole city of Vienna and beyond, spanning roughly
spanning roughly 40km in diameter. It has been in operation since 40km in diameter. It has been in operation since 2003 and supplies
2003 and supplies its users with Internet access. A particularity of its users with Internet access. A particularity of the Vienna
the Vienna Funkfeuer network is that it manages to provide Internet Funkfeuer network is that it manages to provide Internet access
access through a city wide, large scale Wi-Fi MANET, with just a through a city wide, large scale Wi-Fi MANET, with just a single
single Internet uplink. Internet uplink.
Operational experience of the OLSR project [OLSR.org] with these Operational experience of the OLSR project [OLSR.org] with these
networks have revealed that the use of hop-count as routing metric networks have revealed that the use of hop-count as routing metric
leads to unsatisfactory network performance. Experiments with the leads to unsatisfactory network performance. Experiments with the
ETX metric [MOBICOM03] were therefore undertaken in parallel in the ETX metric [MOBICOM03] were therefore undertaken in parallel in the
Berlin Freifunk network as well as in the Vienna Funkfeuer network in Berlin Freifunk network as well as in the Vienna Funkfeuer network in
2004, and found satisfactory, i.e., sufficiently easy to implement 2004, and found satisfactory, i.e., sufficiently easy to implement
and providing sufficiently good performance. This metric has now and providing sufficiently good performance. This metric has now
been in operational use in these networks for several years. been in operational use in these networks for several years.
skipping to change at page 16, line 41 skipping to change at page 18, line 12
performance of a network considerably by not taking advantage of performance of a network considerably by not taking advantage of
higher capacity links. higher capacity links.
Because of this the OLSR.org project has implemented the Directional Because of this the OLSR.org project has implemented the Directional
Airtime Metric for OLSRv2, which has been inspired by the Estimated Airtime Metric for OLSRv2, which has been inspired by the Estimated
Travel Time (ETT) metric [MOBICOM04]. This metric uses an Travel Time (ETT) metric [MOBICOM04]. This metric uses an
unidirectional packet loss, but also takes the bitrate into account unidirectional packet loss, but also takes the bitrate into account
to create a more accurate description of the relative costs or to create a more accurate description of the relative costs or
capabilities of OLSRv2 links. capabilities of OLSRv2 links.
Appendix B. Linkspeed stabilization Appendix C. Linkspeed stabilization
The DAT metric describes how to generate a reasonable stable packet The DAT metric describes how to generate a reasonable stable packet
loss value from incoming packet reception/loss events, the source of loss value from incoming packet reception/loss events, the source of
the linkspeed used in this document is considered an external the linkspeed used in this document is considered an external
process. process.
In the presence of a layer-2 technology with variable linkspeed it is In the presence of a layer-2 technology with variable linkspeed it is
likely that the raw linkspeed will be fluctuating too fast to be likely that the raw linkspeed will be fluctuating too fast to be
useful for the DAT metric. useful for the DAT metric.
The amount of stabilization necessary for the linkspeed depends on The amount of stabilization necessary for the linkspeed depends on
the implementation of the mac-layer, especially the rate control the implementation of the mac-layer, especially the rate control
algorithm. algorithm.
Experiments with the Linux 802.11 wifi stack have shown that a simple Experiments with the Linux 802.11 wifi stack have shown that a simple
Median filter over a series of raw linkspeed measurements can smooth Median filter over a series of raw linkspeed measurements can smooth
the calculated value without introducing intermediate linkspeed the calculated value without introducing intermediate linkspeed
values you would get by using averaging or an exponential weighted values you would get by using averaging or an exponential weighted
moving average. moving average.
Appendix C. Packet loss hysteresis Appendix D. Packet loss hysteresis
While the DAT metric use a sliding window to calculate a reasonable While the DAT metric use a sliding window to calculate a reasonable
stable frame loss, the implementation might choose to integrate an stable frame loss, the implementation might choose to integrate an
additional hysteresis to prevent the metric flapping between two additional hysteresis to prevent the metric flapping between two
values. values.
In Section Section 10.2 DAT caluclates a fractional loss rate. The In Section Section 10.2 DAT caluclates a fractional loss rate. The
fraction of 'loss := sum_total / sum_received' may result in minor fraction of 'loss := sum_total / sum_received' may result in minor
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 D. 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 7), 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 |
 End of changes. 46 change blocks. 
77 lines changed or deleted 147 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/