draft-ietf-manet-olsrv2-dat-metric-00.txt   draft-ietf-manet-olsrv2-dat-metric-01.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: September 27, 2014 INRIA Expires: January 23, 2015 INRIA
March 26, 2014 July 22, 2014
Packet Sequence Number based directional airtime metric for OLSRv2 Packet Sequence Number based directional airtime metric for OLSRv2
draft-ietf-manet-olsrv2-dat-metric-00 draft-ietf-manet-olsrv2-dat-metric-01
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 September 27, 2014. This Internet-Draft will expire on January 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 34 skipping to change at page 2, line 34
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11
10. HELLO Timeout Processing . . . . . . . . . . . . . . . . . . 11 10. HELLO Timeout Processing . . . . . . . . . . . . . . . . . . 11
11. Metric Update . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Metric Update . . . . . . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 14 Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
One of the major shortcomings of OLSR [RFC3626] is the missing of a One of the major shortcomings of OLSR [RFC3626] is the missing of a
link cost metric between mesh nodes. Operational experience with link cost metric between mesh nodes. Operational experience with
mesh networks gathered since the standardization of OLSR has revealed mesh networks gathered since the standardization of OLSR has revealed
that wireless networks links can have highly variable and that wireless networks links can have highly variable and
heterogeneous properties. This makes a hopcount metric insufficient heterogeneous properties. This makes a hopcount metric insufficient
for effective mesh routing. for effective mesh routing.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
like packet-pair. like packet-pair.
If [RFC5444] control traffic is used to determine the link packet If [RFC5444] control traffic is used to determine the link packet
loss, the administrator should take care that link layer multicast loss, the administrator should take care that link layer multicast
transmission do not not have a higher reception probability than the transmission do not not have a higher reception probability than the
slowest unicast transmission. It might be necessary to increase the slowest unicast transmission. It might be necessary to increase the
data-rate of the multicast transmissions, e.g. set the multicast data-rate of the multicast transmissions, e.g. set the multicast
data-rate to 6 MBit/s if you use IEEE 802.11g only. data-rate to 6 MBit/s if you use IEEE 802.11g only.
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. Maximum packet loss is "ETX 4" (1 of 4 packets is data-rate. Maximum packet loss is "ETX 8" (1 of 8 packets is
successfully sent to the receiver, without link layer successfully sent to the receiver, without link layer
retransmissions), the unicast data-rate can be between 1024 Bit/s and retransmissions), the unicast data-rate can be between 1 kBit/s and 2
4 GBit/s. The metric has been designed for data-rates of 1 MBit/s and GBit/s. The metric has been designed for data-rates of 1 MBit/s and
hundreds of MBit/s. hundreds of MBit/s.
4. Directional Airtime Metric Rational 4. Directional Airtime Metric Rational
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 has several on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but has several
key differences. key differences.
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 30 skipping to change at page 7, line 30
DAT_SEQNO_RESTART_DETECTION := 256 DAT_SEQNO_RESTART_DETECTION := 256
7. Protocol Constants 7. Protocol Constants
This specification defines the following constants, which cannot be This specification defines the following constants, which cannot be
changed without making the metric outputs incomparable: changed without making the metric outputs incomparable:
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: 4. (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS: 8.
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: 1024. metric: 1000.
8. Data Structures 8. Data Structures
This specification extends the Link Set Tuples of the Interface This specification extends the Link Set Tuples of the Interface
Information Base, as defined in [RFC6130] section 7.1, by the Information Base, as defined in [RFC6130] section 7.1, by the
following additional elements for each link tuple when being used following additional elements for each link tuple when being used
with this metric: with this metric:
L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements. L_DAT_received is 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
skipping to change at page 15, line 40 skipping to change at page 15, line 40
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 mesh links. capabilities of mesh links.
Appendix B. Linkspeed stabilization
The DAT metric describes how to generate a reasonable stable packet
loss value from incoming packet reception/loss events, the source of
the linkspeed used in this document is considered an external
process.
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
useful for the DAT metric.
The amount of stabilization necessary for the linkspeed depends on
the implementation of the mac-layer, especially the rate control
algorithm.
Experiments with the Linux 802.11 wifi stack have shown that a simple
Median filter over a series of raw linkspeed measurements can smooth
the calculated value without introducing intermediate linkspeed
values you would get by using averaging or an exponential weighted
moving average.
Authors' Addresses Authors' Addresses
Henning Rogge Henning Rogge
Fraunhofer FKIE Fraunhofer FKIE
Email: henning.rogge@fkie.fraunhofer.de Email: henning.rogge@fkie.fraunhofer.de
URI: http://www.fkie.fraunhofer.de URI: http://www.fkie.fraunhofer.de
Emmanuel Baccelli Emmanuel Baccelli
INRIA INRIA
Email: Emmanuel.Baccelli@inria.fr Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/ URI: http://www.emmanuelbaccelli.org/
 End of changes. 10 change blocks. 
10 lines changed or deleted 33 lines changed or added

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