--- 1/draft-ietf-manet-olsrv2-dat-metric-04.txt 2015-04-22 00:16:12.402576256 -0700 +++ 2/draft-ietf-manet-olsrv2-dat-metric-05.txt 2015-04-22 00:16:12.442577242 -0700 @@ -1,19 +1,19 @@ MANET H. Rogge Internet-Draft Fraunhofer FKIE Intended status: Experimental E. Baccelli -Expires: June 15, 2015 INRIA - December 12, 2014 +Expires: October 24, 2015 INRIA + April 22, 2015 Packet Sequence Number based directional airtime metric for OLSRv2 - draft-ietf-manet-olsrv2-dat-metric-04 + draft-ietf-manet-olsrv2-dat-metric-05 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,25 +21,25 @@ 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 June 15, 2015. + This Internet-Draft will expire on October 24, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -57,21 +57,21 @@ 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 9 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 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. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11 + 10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 11 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15 Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 @@ -167,21 +167,21 @@ retransmission to increase the delivery probability and multiple 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. + packet loss based on [RFC6130] HELLO message timeouts. The metric must learn about the unicast data rate towards each one- hop neighbor from an external process, either by configuration or by an external measurement process. This measurement could be done by gathering cross-layer data from the operating system or an external daemon like DLEP [DLEP], but also by indirect layer-3 measurements like packet-pair. The metric uses [RFC5444] multicast control traffic to determine the link packet loss. The administrator should take care that link layer @@ -230,23 +230,23 @@ all link costs of a topology with the size of a data-plane packet would never change the dijkstra result anyways. The queue based packet loss estimator has been tested extensively in the OLSR.org ETX implementation, see Appendix A. The output is the 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. + based of received and lost [RFC5444] 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 @@ -267,25 +267,25 @@ packets and one for the estimated number of packets sent by the other side of the link. Because the rate of incoming packets is not uniform over time, the queue contains a number of counters, each representing a fixed time interval. Incoming packet loss and packet reception event are accumulated in the current queue element until a timer adds a new empty counter to both queues and remove the oldest counter from both. In addition to the packet loss stored in the queue, this metric uses - a timer to detect a total link-loss. For every NHDP HELLO interval - in which the metric received no packet from a neighbor, it scales the - number of received packets in the queue based on the total time - interval the queue represents compared to the total time of the lost - HELLO intervals. + a timer to detect a total link-loss. For every [RFC5444] HELLO + interval in which the metric received no packet from a neighbor, it + scales the number of received packets in the queue based on the total + time interval the queue represents compared to the total time of the + lost HELLO intervals. The average packet loss ratio is calculated as the sum of the 'total packets' counters divided by the sum of the 'packets received' counters. This value is then divided through the current link-speed and then scaled into the range of metrics allowed for OLSRv2. The metric value is then used as L_in_metric of the Link Set (as defined in section 8.1. of [RFC7181]). 6. Protocol Parameters @@ -352,29 +352,30 @@ 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. L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements. Each entry contains the estimated number of packets transmitted by the neighbor, based on the received packet sequence numbers within an interval of DAT_REFRESH_INTERVAL. - L_DAT_hello_time is the time when the next hello will be expected. + L_DAT_packet_time is the time when the next RFC5444 packet should + have arrived. L_DAT_hello_interval is the interval between two hello messages of the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] of NHDP messages [RFC6130]. - L_DAT_lost_hello_messages is the estimated number of lost hello - messages from this neighbor, based on the value of the hello - interval. + L_DAT_lost_packet_intervals is the estimated number of HELLO + intervals from this neighbor the metric has not received a single + packet. L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic for this neighbor. L_DAT_last_pkt_seqno is the last received packet sequence number received from this link. Methods to obtain the value of L_DAT_rx_bitrate are out of the scope of this specification. Such methods may include static configuration via a configuration file or dynamic measurement through mechanisms @@ -391,28 +392,26 @@ When generating a new tuple in the Link Set, as defined in [RFC6130] section 12.5 bullet 3, the values of the elements specified in Section 8 are set as follows: o L_DAT_received := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH elements. o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH elements. - 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_packet_time := EXPIRED (no earlier RFC5444 packet received). o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO received). - o L_DAT_lost_hello_messages := 0 (no HELLO interval without + o L_DAT_lost_packet_intervals := 0 (no HELLO interval without packets). 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. @@ -470,24 +469,24 @@ 3. If diff > DAT_SEQNO_RESTART_DETECTION, then: 1. diff := 1. 4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff. 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 * + 1. L_DAT_packet_time := current time + (L_DAT_hello_interval * DAT_HELLO_TIMEOUT_FACTOR). - 5. L_DAT_lost_hello_messages := 0. + 5. L_DAT_lost_packet_intervals := 0. 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. 1. If the HELLO message contains an INTERVAL_TIME message TLV, then: 1. L_DAT_hello_interval := interval_time. @@ -495,56 +494,58 @@ 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 * + 3. L_DAT_packet_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 +10.1. Packet Timeout Processing - When L_DAT_hello_time has timed out, the following step MUST be done: + When L_DAT_packet_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. + 1. L_DAT_lost_packet_intervals := L_DAT_lost_packet_intervals + + 1. - 3. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. + 3. L_DAT_packet_time := L_DAT_packet_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). + 1. sum_received := sum(L_DAT_received). - 2. sum_total := sum(L_DAT_received). + 2. sum_total := sum(L_DAT_total). 3. If L_DAT_hello_interval != UNDEFINED and - L_DAT_lost_hello_messages > 0, then: + L_DAT_lost_packet_intervals > 0, then: 1. lost_time_proportion := L_DAT_hello_interval * - L_DAT_lost_hello_messages / DAT_MEMORY_LENGTH. + L_DAT_lost_packet_intervals / DAT_MEMORY_LENGTH. 2. sum_received := sum_received * MAX ( 0, 1 - lost_time_proportion); 4. If sum_received < 1, then: 1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181] section 5.6.1. 5. Otherwise: