--- 1/draft-ietf-manet-olsrv2-dat-metric-02.txt 2014-11-24 05:15:26.716643105 -0800 +++ 2/draft-ietf-manet-olsrv2-dat-metric-03.txt 2014-11-24 05:15:26.744643791 -0800 @@ -1,19 +1,19 @@ MANET H. Rogge Internet-Draft Fraunhofer FKIE Intended status: Experimental E. Baccelli -Expires: February 9, 2015 INRIA - August 8, 2014 +Expires: May 28, 2015 INRIA + November 24, 2014 Packet Sequence Number based directional airtime metric for OLSRv2 - draft-ietf-manet-olsrv2-dat-metric-02 + draft-ietf-manet-olsrv2-dat-metric-03 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 February 9, 2015. + This Internet-Draft will expire on May 28, 2015. Copyright Notice Copyright (c) 2014 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 @@ -54,37 +54,34 @@ 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 5 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 8 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 9 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Requirements for using DAT metric in OLSRv2 implementations . . . . . . . . . . . . . . . . . . . . . 9 - 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 9 - 9.3.1. Packet Sequence based link loss . . . . . . . . . . . 10 - 9.3.2. HELLO based Link Loss . . . . . . . . . . . . . . . . 11 - 9.3.3. Other Measurement of Link Loss . . . . . . . . . . . 11 - 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 - 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12 - 10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 12 - 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10 + 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 10 + 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11 + 10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11 + 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 11 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 14.2. Informative References . . . . . . . . . . . . . . . . . 15 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 14.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15 Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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. @@ -381,22 +378,22 @@ 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_interval := UNDEFINED (no earlier NHDP HELLO received). o L_DAT_lost_hello_messages := 0 (no HELLO interval without packets). - o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet - received). + o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet with + sequence number received). 9. Packets and Messages This section describes the necessary changes of [RFC7181] implementations with DAT metric for the processing and modification of incoming and outgoing [RFC5444] data. 9.1. Definitions For the purpose of this section, note the following definitions: @@ -412,47 +409,35 @@ 9.2. Requirements for using DAT metric in OLSRv2 implementations An implementation of OLSRv2 using the metric specified by this document SHOULD include the following parts into its [RFC5444] output: o an INTERVAL_TIME message TLV in each HELLO message, as defined in [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 [RFC5444] section 5.1 which is incremented by 1 for each outgoing [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 specified in [RFC6130] and [RFC7181]. [RFC5444] packets without packet sequence number MUST NOT be processed in this way by this metric. - The router MUST update the Link Set Tuple corresponding to the - originator of the packet: + The router updates the Link Set Tuple corresponding to the originator + of the packet: 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 1. L_DAT_received[TAIL] := 1. 2. L_DAT_total[TAIL] := 1. 2. Otherwise: 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. @@ -467,80 +452,61 @@ 3. L_DAT_last_pkt_seqno := pkt_seqno. 4. If L_DAT_hello_interval != UNDEFINED, then: 1. L_DAT_hello_time := current time + (L_DAT_hello_interval * DAT_HELLO_TIMEOUT_FACTOR). 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 For each incoming HELLO Message, after it has been processed as 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. L_DAT_hello_interval := interval_time. 2. Otherwise: 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 In addition to changes in the [RFC5444] processing/generation code, the DAT metric also uses two timer events. 10.1. HELLO Timeout Processing When L_DAT_hello_time has timed out, the following step MUST be done: + 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: + + 1. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. + + 2. Otherwise: + 1. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1. - 2. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. + 3. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. 10.2. Metric Update Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link Set entries MUST be recalculated: 1. sum_received := sum(L_DAT_total). 2. sum_total := sum(L_DAT_received).