draft-ietf-manet-olsrv2-dat-metric-04.txt   draft-ietf-manet-olsrv2-dat-metric-05.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: June 15, 2015 INRIA Expires: October 24, 2015 INRIA
December 12, 2014 April 22, 2015
Packet Sequence Number based directional airtime metric for OLSRv2 Packet Sequence Number based directional airtime metric for OLSRv2
draft-ietf-manet-olsrv2-dat-metric-04 draft-ietf-manet-olsrv2-dat-metric-05
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 June 15, 2015. This Internet-Draft will expire on October 24, 2015.
Copyright Notice 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. 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8
8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 10 implementations . . . . . . . . . . . . . . . . . . . . . 10
9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11
10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11
10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11 10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 11
10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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 As specified in [RFC7181] the metric calculates only the incoming
link cost. It does neither calculate the outgoing metric, nor does link cost. It does neither calculate the outgoing metric, nor does
it decide the link status (heard, symmetric, lost). it decide the link status (heard, symmetric, lost).
The metric works both for nodes which can send/receive [RFC5444] The metric works both for nodes which can send/receive [RFC5444]
packet sequence numbers and such which do not have this capability. packet sequence numbers and such which do not have this capability.
In the absence of such sequence numbers the metric calculates the 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- 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.
The metric uses [RFC5444] multicast control traffic to determine the The metric uses [RFC5444] multicast control traffic to determine the
link packet loss. The administrator should take care that link layer link packet loss. The administrator should take care that link layer
skipping to change at page 5, line 52 skipping to change at page 5, line 52
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 The metric normally measures the loss of a link by tracking the
incoming [RFC5444] packet sequence numbers. Without these packet incoming [RFC5444] packet sequence numbers. Without these packet
sequence numbers, the metric does calculate the loss of the link sequence numbers, the metric does calculate the loss of the link
based of received and lost Hello messages. It uses the incoming based of received and lost [RFC5444] HELLO messages. It uses the
Hello interval time (or if not present, the validity time) to decide incoming HELLO interval time (or if not present, the validity time)
when a Hello is lost. to decide when a HELLO is lost.
When a neighbor router resets, its packet sequence number might jump When a neighbor router resets, its packet sequence number might jump
to a random value. The metric tries to detect jumps in the packet to a random value. The metric tries to detect jumps in the packet
sequence number and removes them from the data set, because the sequence number and removes them from the data set, because the
already gathered link loss data should still be valid. The link loss 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 data is only removed from memory when a Link times out completely and
its Link Set tuple is removed from the database. its Link Set tuple is removed from the database.
5. Metric Functioning & Overview 5. Metric Functioning & Overview
skipping to change at page 6, line 40 skipping to change at page 6, line 40
packets and one for the estimated number of packets sent by the other packets and one for the estimated number of packets sent by the other
side of the link. side of the link.
Because the rate of incoming packets is not uniform over time, the Because the rate of incoming packets is not uniform over time, the
queue contains a number of counters, each representing a fixed time queue contains a number of counters, each representing a fixed time
interval. Incoming packet loss and packet reception event are interval. Incoming packet loss and packet reception event are
accumulated in the current queue element until a timer adds a new accumulated in the current queue element until a timer adds a new
empty counter to both queues and remove the oldest counter from both. 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 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 a timer to detect a total link-loss. For every [RFC5444] HELLO
in which the metric received no packet from a neighbor, it scales the interval in which the metric received no packet from a neighbor, it
number of received packets in the queue based on the total time scales the number of received packets in the queue based on the total
interval the queue represents compared to the total time of the lost time interval the queue represents compared to the total time of the
HELLO intervals. lost HELLO intervals.
The average packet loss ratio is calculated as the sum of the 'total The average packet loss ratio is calculated as the sum of the 'total
packets' counters divided by the sum of the 'packets received' packets' counters divided by the sum of the 'packets received'
counters. This value is then divided through the current link-speed counters. This value is then divided through the current link-speed
and then scaled into the range of metrics allowed for OLSRv2. 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 The metric value is then used as L_in_metric of the Link Set (as
defined in section 8.1. of [RFC7181]). defined in section 8.1. of [RFC7181]).
6. Protocol Parameters 6. Protocol Parameters
skipping to change at page 8, line 35 skipping to change at page 8, line 35
L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements. L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements.
Each entry contains the number of successfully received packets Each entry contains the number of successfully received packets
within an interval of DAT_REFRESH_INTERVAL. within an interval of DAT_REFRESH_INTERVAL.
L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements. L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements.
Each entry contains the estimated number of packets transmitted by Each entry contains the estimated number of packets transmitted by
the neighbor, based on the received packet sequence numbers within the neighbor, based on the received packet sequence numbers within
an interval of DAT_REFRESH_INTERVAL. 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 L_DAT_hello_interval is the interval between two hello messages of
the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497]
of NHDP messages [RFC6130]. of NHDP messages [RFC6130].
L_DAT_lost_hello_messages is the estimated number of lost hello L_DAT_lost_packet_intervals is the estimated number of HELLO
messages from this neighbor, based on the value of the hello intervals from this neighbor the metric has not received a single
interval. packet.
L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic
for this neighbor. for this neighbor.
L_DAT_last_pkt_seqno is the last received packet sequence number L_DAT_last_pkt_seqno is the last received packet sequence number
received from this link. received from this link.
Methods to obtain the value of L_DAT_rx_bitrate are out of the scope Methods to obtain the value of L_DAT_rx_bitrate are out of the scope
of this specification. Such methods may include static configuration of this specification. Such methods may include static configuration
via a configuration file or dynamic measurement through mechanisms via a configuration file or dynamic measurement through mechanisms
skipping to change at page 9, line 25 skipping to change at page 9, line 28
When generating a new tuple in the Link Set, as defined in [RFC6130] 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 12.5 bullet 3, the values of the elements specified in
Section 8 are set as follows: Section 8 are set as follows:
o L_DAT_received := 0, ..., 0. The queue always has o L_DAT_received := 0, ..., 0. The queue always has
DAT_MEMORY_LENGTH elements. DAT_MEMORY_LENGTH elements.
o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH
elements. elements.
o L_DAT_last_pkt_seqno := UNDEFINED (no earlier packet received). o L_DAT_packet_time := EXPIRED (no earlier RFC5444 packet 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_packet_intervals := 0 (no HELLO interval without
packets). packets).
o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet with o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet with
sequence number 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.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
3. If diff > DAT_SEQNO_RESTART_DETECTION, then: 3. If diff > DAT_SEQNO_RESTART_DETECTION, then:
1. diff := 1. 1. diff := 1.
4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff. 4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff.
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_packet_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_packet_intervals := 0.
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.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
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: 3. If L_DAT_last_pkt_seqno = UNDEFINED, then:
1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1.
2. L_DAT_total[TAIL] := L_DAT_total[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). 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. 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. If L_DAT_last_pkt_seqno = UNDEFINED, then:
1. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. 1. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1.
2. Otherwise: 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 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_received).
2. sum_total := sum(L_DAT_received). 2. sum_total := sum(L_DAT_total).
3. If L_DAT_hello_interval != UNDEFINED and 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 * 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 - 2. sum_received := sum_received * MAX ( 0, 1 -
lost_time_proportion); lost_time_proportion);
4. If sum_received < 1, then: 4. If sum_received < 1, then:
1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181] 1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181]
section 5.6.1. section 5.6.1.
5. Otherwise: 5. Otherwise:
 End of changes. 23 change blocks. 
34 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/