draft-ietf-manet-olsrv2-dat-metric-02.txt   draft-ietf-manet-olsrv2-dat-metric-03.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: February 9, 2015 INRIA Expires: May 28, 2015 INRIA
August 8, 2014 November 24, 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-02 draft-ietf-manet-olsrv2-dat-metric-03
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 February 9, 2015. This Internet-Draft will expire on May 28, 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 21 skipping to change at page 2, line 21
5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 5 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 5
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6
6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7
8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 8 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 9
9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 9 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10
9.3.1. Packet Sequence based link loss . . . . . . . . . . . 10 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 10
9.3.2. HELLO based Link Loss . . . . . . . . . . . . . . . . 11 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11
9.3.3. Other Measurement of Link Loss . . . . . . . . . . . 11 10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 11
10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . 17 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
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 9, line 15 skipping to change at page 9, line 15
o L_DAT_last_pkt_seqno := UNDEFINED (no earlier packet received). o L_DAT_last_pkt_seqno := UNDEFINED (no earlier packet received).
o L_DAT_hello_time := EXPIRED (no earlier NHDP HELLO received). o L_DAT_hello_time := EXPIRED (no earlier NHDP HELLO received).
o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO
received). received).
o L_DAT_lost_hello_messages := 0 (no HELLO interval without o L_DAT_lost_hello_messages := 0 (no HELLO interval without
packets). packets).
o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet with
received). sequence number received).
9. Packets and Messages 9. Packets and Messages
This section describes the necessary changes of [RFC7181] This section describes the necessary changes of [RFC7181]
implementations with DAT metric for the processing and modification implementations with DAT metric for the processing and modification
of incoming and outgoing [RFC5444] data. of incoming and outgoing [RFC5444] data.
9.1. Definitions 9.1. Definitions
For the purpose of this section, note the following definitions: For the purpose of this section, note the following definitions:
skipping to change at page 9, line 46 skipping to change at page 9, line 46
9.2. Requirements for using DAT metric in OLSRv2 implementations 9.2. Requirements for using DAT metric in OLSRv2 implementations
An implementation of OLSRv2 using the metric specified by this An implementation of OLSRv2 using the metric specified by this
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.
9.3. Link Loss Data Gathering
While this metric was designed for measuring the packet loss based on
the [RFC5444] packet sequence number, some implementations might not
be able to add the packet sequence number to their output. Because
of this the following section contains multiple alternatives to
calculate the packet loss.
9.3.1. Packet Sequence based link loss
An implementation of OLSRv2, using the metric specified by this
document with packet sequence based link loss, MUST include the
following element into its [RFC5444] output:
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.
For each incoming [RFC5444] packet, additional processing MUST be 9.3. Link Loss Data Gathering
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].
[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 this way by this metric.
The router MUST update the Link Set Tuple corresponding to the The router updates the Link Set Tuple corresponding to the originator
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.
skipping to change at page 11, line 5 skipping to change at page 10, line 44
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:
1. L_DAT_hello_time := current time + (L_DAT_hello_interval * 1. L_DAT_hello_time := current time + (L_DAT_hello_interval *
DAT_HELLO_TIMEOUT_FACTOR). DAT_HELLO_TIMEOUT_FACTOR).
5. L_DAT_lost_hello_messages := 0. 5. L_DAT_lost_hello_messages := 0.
9.3.2. HELLO based Link Loss
A metric might just use the incoming NHDP HELLO messages of a
neighbor to calculate the link loss. Because this method uses fewer
events to calculate the metric, the variance of the output will
increase. It might be necessary to increase the value of
DAT_MEMORY_LENGTH to compensate for this.
For each incoming HELLO message, after it has been processed as
defined in [RFC6130] section 12, the Link Set Tuple as defined in
section 7.1 corresponding to the incoming HELLO message must be
updated.
1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1.
2. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1.
3. L_DAT_lost_hello_messages := 0.
9.3.3. Other Measurement of Link Loss
Instead of using incoming [RFC5444] packets or [RFC6130] messages,
the routing daemon can also use other sources to measure the link
layer lossrate (e.g. [DLEP]).
To use a source like this with the DAT metric, the routing daemon has
to add incoming total traffic (or the sum of received and lost
traffic) and lost traffic to the queued elements in the extension of
the Link Set Tuple defined in Section 8 corresponding to originator
of the traffic.
The routing daemon should also set L_DAT_lost_hello_messages to zero
every times new packages arrive.
9.4. HELLO Message Processing 9.4. HELLO Message Processing
For each incoming HELLO Message, after it has been processed as For each incoming HELLO Message, after it has been processed as
defined in [RFC6130] section 12, the Link Set Tuple corresponding to defined in [RFC6130] section 12, the Link Set Tuple corresponding to
the incoming HELLO message must be updated. the incoming HELLO message MUST be updated.
1. If the HELLO message contains an INTERVAL_TIME message TLV, then: 1. If the HELLO message contains an INTERVAL_TIME message TLV, then:
1. L_DAT_hello_interval := interval_time. 1. L_DAT_hello_interval := interval_time.
2. Otherwise: 2. Otherwise:
1. L_DAT_hello_interval := validity_time. 1. L_DAT_hello_interval := validity_time.
3. If L_DAT_last_pkt_seqno = UNDEFINED, then:
1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1.
2. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1.
3. L_DAT_hello_time := current time + (L_DAT_hello_interval *
DAT_HELLO_TIMEOUT_FACTOR).
10. Timer Event Handling 10. Timer Event Handling
In addition to changes in the [RFC5444] processing/generation code, In addition to changes in the [RFC5444] processing/generation code,
the DAT metric also uses two timer events. the DAT metric also uses two timer events.
10.1. HELLO Timeout Processing 10.1. HELLO Timeout Processing
When L_DAT_hello_time has timed out, the following step MUST be done: When L_DAT_hello_time has timed out, the following step MUST be done:
1. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1. 1. If L_DAT_last_pkt_seqno = UNDEFINED, then:
2. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. 1. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1.
2. Otherwise:
1. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1.
3. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval.
10.2. Metric Update 10.2. Metric Update
Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link
Set entries MUST be recalculated: Set entries MUST be recalculated:
1. sum_received := sum(L_DAT_total). 1. sum_received := sum(L_DAT_total).
2. sum_total := sum(L_DAT_received). 2. sum_total := sum(L_DAT_received).
 End of changes. 15 change blocks. 
74 lines changed or deleted 40 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/