draft-ietf-manet-olsrv2-dat-metric-05.txt   draft-ietf-manet-olsrv2-dat-metric-06.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: October 24, 2015 INRIA Expires: January 30, 2016 INRIA
April 22, 2015 July 29, 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-05 draft-ietf-manet-olsrv2-dat-metric-06
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 October 24, 2015. This Internet-Draft will expire on January 30, 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 17 skipping to change at page 2, line 17
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 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 . . . . . . . . . . . . . . . . . . . . 9 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10
9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . 10
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11
10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12
10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15 Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15
Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16 Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Packet loss hysteresis . . . . . . . . . . . . . . . 17
Appendix D. Example DAT values . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 the publication of OLSR
has revealed that wireless networks links can have highly variable has revealed that wireless networks links can have highly variable
and heterogeneous properties. This makes a hopcount metric and heterogeneous properties. This makes a hopcount metric
insufficient for effective OLSR routing. insufficient for effective OLSR routing.
skipping to change at page 6, line 20 skipping to change at page 6, line 25
already gathered link loss data should still be valid. The link loss already gathered link loss data should still be valid. The link loss
data is only removed from memory when a Link times out completely and data is only removed from memory when a Link times out completely and
its Link Set tuple is removed from the database. 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. While the link-speed is taken from packet loss rate and link-speed. The link-speed is taken from an
an external process, the current packet loss rate is calculated by external process not defined in this document. The current packet
keeping track of packet reception and packet loss events. 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 Multiple incoming packet loss/reception events must be combined into
a loss rate to get a smooth metric. Experiments with exponential a loss rate to get a smooth metric. Experiments with exponential
weighted moving average (EWMA) lead to a highly fluctuating or a slow weighted moving average (EWMA) lead to a highly fluctuating or a slow
converging metric (or both). To get a smoother and more controllable converging metric (or both). To get a smoother and more controllable
metric result, this metric uses two fixed length queues to measure metric result, this metric uses two fixed length queues to measure
and average the incoming packet events, one queue for received and average the incoming packet events, one queue for received
packets and one for the estimated number of packets sent by the other packets and one for the estimated number of packets sent by the other
side of the link. side of the link.
skipping to change at page 8, line 8 skipping to change at page 8, line 8
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 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. They range of metric values that can be encoded by the DAT metric (see
cannot be changed without making the metric outputs incomparable and Table 1). They cannot be changed without making the metric outputs
should only be changed for MANET's with a very slow or very fast incomparable and should only be changed for MANET's with a very slow
linklayer. or very fast linklayer.
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: 8. (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: 1000. 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 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
within an interval of DAT_REFRESH_INTERVAL. within an interval of DAT_REFRESH_INTERVAL.
skipping to change at page 14, line 6 skipping to change at page 14, line 24
Initiative (FIRE), Community Networks Testbed for the Future Internet Initiative (FIRE), Community Networks Testbed for the Future Internet
([CONFINE]), contract FP7-288535. ([CONFINE]), contract FP7-288535.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically): Teco Boot specification and its components (listed alphabetically): Teco Boot
(Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7),
Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology
Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus
Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research
Laboratory) 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 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
skipping to change at page 16, line 45 skipping to change at page 17, line 15
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
While the DAT metric use a sliding window to calculate a reasonable
stable frame loss, the implementation might choose to integrate an
additional hysteresis to prevent the metric flapping between two
values.
In Section Section 10.2 DAT caluclates 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.
A hysteresis function applied to the fraction could reduce the amount
of changes in the loss rate and help to stabilize the metric output.
Appendix D. Example DAT values
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 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
meaning as a link speed:
+---------------------------+-----------+
| 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
A path metric value could also be expressed as a link speed, but this
would be unintuitive and difficult to understand. An easier way to
transform a path metric value into a textual representation is to
divide it by the hopcount of the path and express the path cost as
average link speed together with the hopcount (see Table 3).
+---------+------+---------------+
| Metric | hops | average bit/s |
+---------+------+---------------+
| 4 | 2 | 1 Gbit/s |
| | | |
| 4000000 | 6 | 3 kbit/s |
+---------+------+---------------+
Table 3: DAT link cost examples
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. 15 change blocks. 
21 lines changed or deleted 88 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/