draft-ietf-manet-olsrv2-dat-metric-03.txt   draft-ietf-manet-olsrv2-dat-metric-04.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 28, 2015 INRIA Expires: June 15, 2015 INRIA
November 24, 2014 December 12, 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-03 draft-ietf-manet-olsrv2-dat-metric-04
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 May 28, 2015. This Internet-Draft will expire on June 15, 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 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . 5 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7
6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8
8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 8 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9
9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 9 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 9
9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Requirements for using DAT metric in OLSRv2 9.2. Requirements for using DAT metric in OLSRv2
implementations . . . . . . . . . . . . . . . . . . . . . 9 implementations . . . . . . . . . . . . . . . . . . . . . 10
9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 10 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11
10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11
10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11 10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11
10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 11 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 13 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 14
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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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 in wireless
IEEE 802.11 [RFC7181] networks. These networks employ link layer IEEE 802.11 [RFC7181] networks. These networks employ link layer
retransmission to increase the delivery probability and multiple retransmission to increase the delivery probability and multiple
unicast data rates. unicast data rates.
As specified in [RFC7181] the metric calculates only the incoming
link cost. It does neither calculate the outgoing metric, nor does
it decide the link status (heard, symmetric, lost).
The metric works both for nodes which can send/receive [RFC5444]
packet sequence numbers and such which do not have this capability.
In the absence of such sequence numbers the metric calculates the
packet loss based on 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.
If [RFC5444] control traffic is used to determine the link packet The metric uses [RFC5444] multicast control traffic to determine the
loss, the administrator should take care that link layer multicast link packet loss. The administrator should take care that link layer
transmission do not not have a higher reception probability than the multicast transmission do not not have a higher reception probability
slowest unicast transmission. It might, for example in 802.11g, be than the slowest unicast transmission. It might, for example in
necessary to increase the data-rate of the multicast transmissions, 802.11g, be necessary to increase the data-rate of the multicast
e.g. set the multicast data-rate to 6 MBit/s. transmissions, e.g. set the multicast data-rate to 6 MBit/s.
The Directional Airtime metric can only handle a certain range of The metric can only handle a certain range of packet loss and unicast
packet loss and unicast data-rate. The maximum packet loss that can data-rate. The maximum packet loss that can be encoded into the
be encoded into the metric a loss of 7 of 8 packets, without link metric a loss of 7 of 8 packets, without link layer retransmissions.
layer retransmissions. The unicast data-rate that can be encoded by The unicast data-rate that can be encoded by this metric can be
this metric can be between 1 kBit/s and 2 GBit/s. This metric has between 1 kBit/s and 2 GBit/s. This metric has been designed for
been designed for data-rates of 1 MBit/s and hundreds of MBit/s. 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 5, line 42 skipping to change at page 5, line 49
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 A. 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
incoming [RFC5444] packet sequence numbers. Without these packet
sequence numbers, the metric does calculate the loss of the link
based of received and lost Hello messages. It uses the incoming
Hello interval time (or if not present, the validity time) to decide
when a Hello is lost.
When a neighbor router resets, its packet sequence number might jump
to a random value. The metric tries to detect jumps in the packet
sequence number and removes them from the data set, because the
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 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. While the link-speed is taken from
an external process, the current packet loss rate is calculated by an external process, the current packet loss rate is calculated by
keeping track of packet reception and packet loss events. keeping track of packet reception and packet loss events.
 End of changes. 13 change blocks. 
28 lines changed or deleted 51 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/