--- 1/draft-ietf-manet-olsrv2-dat-metric-05.txt 2015-07-29 04:16:33.090368046 -0700 +++ 2/draft-ietf-manet-olsrv2-dat-metric-06.txt 2015-07-29 04:16:33.126368918 -0700 @@ -1,19 +1,19 @@ MANET H. Rogge Internet-Draft Fraunhofer FKIE Intended status: Experimental E. Baccelli -Expires: October 24, 2015 INRIA - April 22, 2015 +Expires: January 30, 2016 INRIA + July 29, 2015 Packet Sequence Number based directional airtime metric for OLSRv2 - draft-ietf-manet-olsrv2-dat-metric-05 + draft-ietf-manet-olsrv2-dat-metric-06 Abstract This document specifies an directional airtime link metric for usage in OLSRv2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -50,38 +50,40 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Directional Airtime Metric Rationale . . . . . . . . . . . . 5 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9 - 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 9 - 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 + 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10 + 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Requirements for using DAT metric in OLSRv2 implementations . . . . . . . . . . . . . . . . . . . . . 10 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 - 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11 - 10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 11 + 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 12 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 14. 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 B. Linkspeed stabilization . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + Appendix C. Packet loss hysteresis . . . . . . . . . . . . . . . 17 + Appendix D. Example DAT values . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction One of the major shortcomings of OLSR [RFC3626] is the lack of a granular link cost metric between OLSR routers. Operational experience with OLSR networks gathered since the publication of OLSR has revealed that wireless networks links can have highly variable and heterogeneous properties. This makes a hopcount metric insufficient for effective OLSR routing. @@ -247,23 +249,25 @@ 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 its Link Set tuple is removed from the database. 5. Metric Functioning & Overview The Directional Airtime Metric is calculated for each link set entry, as defined in [RFC6130] section 7.1. 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 - an external process, the current packet loss rate is calculated by - keeping track of packet reception and packet loss events. + packet loss rate and link-speed. The link-speed is taken from an + external process not defined in this document. The current packet + loss rate is defined in this document by keeping track of packet + reception and packet loss events. It could also be calculated by an + external process with a compatible output. Multiple incoming packet loss/reception events must be combined into a loss rate to get a smooth metric. Experiments with exponential weighted moving average (EWMA) lead to a highly fluctuating or a slow converging metric (or both). To get a smoother and more controllable metric result, this metric uses two fixed length queues to measure and average the incoming packet events, one queue for received packets and one for the estimated number of packets sent by the other side of the link. @@ -325,31 +329,41 @@ DAT_REFRESH_INTERVAL := 1 DAT_HELLO_TIMEOUT_FACTOR := 1.2 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. 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. + 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. 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: 8. + (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS. 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 This specification extends the Link Set of the Interface Information Base, as defined in [RFC6130] section 7.1, by the adding the following elements to each link tuple: L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements. Each entry contains the number of successfully received packets within an interval of DAT_REFRESH_INTERVAL. @@ -611,21 +626,21 @@ Initiative (FIRE), Community Networks Testbed for the Future Internet ([CONFINE]), contract FP7-288535. The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews and comments on the specification and its components (listed alphabetically): Teco Boot (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research - Laboratory) and Stan Ratliff (Cisco Systems). + Laboratory), Fabian Nack and Stan Ratliff (Cisco Systems). 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol", RFC 3626, October 2003. @@ -745,22 +760,75 @@ 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. +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 Henning Rogge Fraunhofer FKIE Email: henning.rogge@fkie.fraunhofer.de URI: http://www.fkie.fraunhofer.de + Emmanuel Baccelli INRIA Email: Emmanuel.Baccelli@inria.fr URI: http://www.emmanuelbaccelli.org/