draft-ietf-manet-olsrv2-dat-metric-01.txt		draft-ietf-manet-olsrv2-dat-metric-02.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: January 23, 2015 INRIA		Expires: February 9, 2015 INRIA
	July 22, 2014		August 8, 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-01		draft-ietf-manet-olsrv2-dat-metric-02
	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 January 23, 2015.		This Internet-Draft will expire on February 9, 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 10		skipping to change at page 2, line 10
	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
	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 Rational . . . . . . . . . . . . . 4		4. Directional Airtime Metric Rationale . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . . 8		9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 9
	9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9		9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
	9.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 9		9.2. Requirements for using DAT metric in OLSRv2
			implementations . . . . . . . . . . . . . . . . . . . . . 9
	9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 9		9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 9
	9.3.1. Packet Sequence based link loss . . . . . . . . . . . 9		9.3.1. Packet Sequence based link loss . . . . . . . . . . . 10
	9.3.2. HELLO based Link Loss . . . . . . . . . . . . . . . . 10		9.3.2. HELLO based Link Loss . . . . . . . . . . . . . . . . 11
	9.3.3. Other Measurement of Link Loss . . . . . . . . . . . 10		9.3.3. Other Measurement of Link Loss . . . . . . . . . . . 11
	9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11		9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11
	10. HELLO Timeout Processing . . . . . . . . . . . . . . . . . . 11		10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12
	11. Metric Update . . . . . . . . . . . . . . . . . . . . . . . . 11		10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 12
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 12		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	15.1. Normative References . . . . . . . . . . . . . . . . . . 13		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	15.2. Informative References . . . . . . . . . . . . . . . . . 14		14.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 14		14.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 15		Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	One of the major shortcomings of OLSR [RFC3626] is the missing of a		One of the major shortcomings of OLSR [RFC3626] is the lack of a
	link cost metric between mesh nodes. Operational experience with		granular link cost metric between OLSR routers. Operational
	mesh networks gathered since the standardization of OLSR has revealed		experience with OLSR networks gathered since the publication of OLSR
	that wireless networks links can have highly variable and		has revealed that wireless networks links can have highly variable
	heterogeneous properties. This makes a hopcount metric insufficient		and heterogeneous properties. This makes a hopcount metric
	for effective mesh routing.		insufficient for effective OLSR routing.
	Based on this experience, OLSRv2 [OLSRV2] integrates the concept of		Based on this experience, OLSRv2 [RFC7181] integrates the concept of
	link metrics directly into the core specification of the routing		link metrics directly into the core specification of the routing
	protocol. The OLSRv2 routing metric is an external process, it can		protocol. The OLSRv2 routing metric is an external process, it can
	be any kind of dimensionless additive cost function which reports to		be any kind of dimensionless additive cost function which reports to
	the OLSRv2 protocol.		the OLSRv2 protocol.
	Since 2004 the OLSR.org [OLSR.org] implementation of OLSR included an		Since 2004 the OLSR.org [OLSR.org] implementation of OLSR included an
	Estimated Transmission Count (ETX) metric [MOBICOM04] as a		Estimated Transmission Count (ETX) metric [MOBICOM04] as a
	proprietary extension. While this metric is not perfect, it proved		proprietary extension. While this metric is not perfect, it proved
	to be sufficient for a long time for Community Mesh Networks		to be sufficient for a long time for Community Mesh Networks
	(Appendix A). But the increasing maximum data rate of IEEE 802.11		(Appendix A). But the increasing maximum data rate of IEEE 802.11
	made the ETX metric less efficient than in the past, which is one		made the ETX metric less efficient than in the past, which is one
	reason to move to a different metric.		reason to move to a different metric.
	This document describes a Directional Airtime routing metric for		This document describes a Directional Airtime routing metric for
	OLSRv2, a successor of the OLSR.org routing metric for [RFC3626]. It		OLSRv2, a successor of the ETX-derived OLSR.org routing metric for
	takes both the loss rate and the link speed into account to provide a		OLSR. It takes both the loss rate and the link speed into account to
	more accurate picture of the mesh network links.		provide a more accurate picture of the links within the network.
			This experimental draft will allow OLSRv2 deployments with a metric
			defined by the IETF Manet group. It enables easier interoperability
			tests between implementations and will also deliver an useful
			baseline to compare other metrics to.
	2. Terminology		2. Terminology
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY',		NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY',
	and 'OPTIONAL' in this document are to be interpreted as described in		and 'OPTIONAL' in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	The terminology introduced in [RFC5444], [OLSRV2] and [RFC6130],		The terminology introduced in [RFC5444], [RFC7181] and [RFC6130],
	including the terms "packet", "message" and "TLV" are to be		including the terms "packet", "message" and "TLV" are to be
	interpreted as described therein.		interpreted as described therein.
	Additionally, this document uses the following terminology and		Additionally, this document uses the following terminology and
	notational conventions:		notational conventions:
	QUEUE - a first in, first out queue of integers.		QUEUE - a first in, first out queue of integers.
	QUEUE[TAIL] - the most recent element in the queue.		QUEUE[TAIL] - the most recent element in the queue.
	skipping to change at page 3, line 52		skipping to change at page 4, line 8
	diff_seqno(new, old) - an operation which returns the positive		diff_seqno(new, old) - an operation which returns the positive
	distance between two elements of the circular sequence number		distance between two elements of the circular sequence number
	space defined in section 5.1 of [RFC5444]. Its value is either		space defined in section 5.1 of [RFC5444]. Its value is either
	(new - old) if this result is positive, or else its value is (new		(new - old) if this result is positive, or else its value is (new
	- old + 65536).		- old + 65536).
	MAX(a,b) - the maximum of a and b.		MAX(a,b) - the maximum of a and b.
	UNDEFINED - a value not in the normal value range of a variable.		UNDEFINED - a value not in the normal value range of a variable.
	Might be -1 for this protocol.
	airtime - the time a transmitted packet blocks the link layer, e.g.,		airtime - the time a transmitted packet blocks the link layer, e.g.,
	a wireless link.		a wireless link.
	ETX - Expected Transmission Count, a link metric proportional to the		ETX - Expected Transmission Count, a link metric proportional to the
	number of transmissions to successfully send an IP packet over a		number of transmissions to successfully send an IP packet over a
	link.		link.
	ETT - Estimated Travel Time, a link metric proportional to the		ETT - Estimated Travel Time, a link metric proportional to the
	amount of airtime needed to transmit an IP packet over a link, not		amount of airtime needed to transmit an IP packet over a link, not
	considering layer-2 overhead created by preamble, backoff time and		considering layer-2 overhead created by preamble, backoff time and
	queuing.		queuing.
	DAT - Directional Airtime Metric, the link metric described in this		DAT - Directional Airtime Metric, the link metric described in this
	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 mesh 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.
	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		If [RFC5444] control traffic is used to determine the link packet
	loss, the administrator should take care that link layer multicast		loss, the administrator should take care that link layer multicast
	transmission do not not have a higher reception probability than the		transmission do not not have a higher reception probability than the
	slowest unicast transmission. It might be necessary to increase the		slowest unicast transmission. It might, for example in 802.11g, be
	data-rate of the multicast transmissions, e.g. set the multicast		necessary to increase the data-rate of the multicast transmissions,
	data-rate to 6 MBit/s if you use IEEE 802.11g only.		e.g. set the multicast data-rate to 6 MBit/s.
	The metric can only handle a certain range of packet loss and unicast		The Directional Airtime metric can only handle a certain range of
	data-rate. Maximum packet loss is "ETX 8" (1 of 8 packets is		packet loss and unicast data-rate. The maximum packet loss that can
	successfully sent to the receiver, without link layer		be encoded into the metric a loss of 7 of 8 packets, without link
	retransmissions), the unicast data-rate can be between 1 kBit/s and 2		layer retransmissions. The unicast data-rate that can be encoded by
	GBit/s. The metric has been designed for data-rates of 1 MBit/s and		this metric can be between 1 kBit/s and 2 GBit/s. This metric has
	hundreds of MBit/s.		been designed for data-rates of 1 MBit/s and hundreds of MBit/s.
			4. Directional Airtime Metric Rationale
	4. Directional Airtime Metric Rational
	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 has several		on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from
	key differences.		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
	integrates the incoming linkspeed into the metric cost. There are		integrates the incoming linkspeed into the metric cost. There are
	multiple reasons for this decision:		multiple reasons for this decision:
	o OLSRv2 [OLSRV2] defines the link metric as directional costs		o OLSRv2 [RFC7181] defines the link metric as directional costs
	between nodes.		between routers.
	o Not all link layer implementations use acknowledgement mechanisms.		o Not all link layer implementations use acknowledgement mechanisms.
	Most link layer implementations who do use them use less airtime		Most link layer implementations who do use them use less airtime
	and a more robust modulation for the acknowledgement than the data		and a more robust modulation for the acknowledgement than the data
	transmission, which makes it more likely for the data transmission		transmission, which makes it more likely for the data transmission
	to be disrupted compared to the acknowledgement.		to be disrupted compared to the acknowledgement.
	o Incoming packet loss and linkspeed can be measured locally,		o Incoming packet loss and linkspeed can be measured locally,
	symmetric link loss would need an additional signaling TLV in the		symmetric link loss would need an additional signaling TLV in the
	[RFC6130] HELLO and would delay metric calculation by up to one		[RFC6130] HELLO and would delay metric calculation by up to one
	HELLO interval.		HELLO interval.
	The Directional Airtime Metric does not integrate the packet size		The Directional Airtime Metric does not integrate the packet size
	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.
	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
	skipping to change at page 6, line 29		skipping to change at page 6, line 33
	number of received packets in the queue based on the total time		number of received packets in the queue based on the total time
	interval the queue represents compared to the total time of the lost		interval the queue represents compared to the total time of the lost
	HELLO intervals.		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 [OLSRV2]).		defined in section 8.1. of [RFC7181]).
	6. Protocol Parameters		6. Protocol Parameters
	This specification defines the following parameters, which can be		This specification defines two constants, agreement on which is
	changed without making the metric outputs incomparable with each		required, from all the OLSRv2 routers participating in the same
	other:		deployment. Two routers which use different values for these
			constants will not be able to generate metric values which can be
			correctly interpreted by both. These constants are:
	DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All		DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All
	received and lost packets within the queue are used to calculate		received and lost packets within the queue are used to calculate
	the cost of the link.		the cost of the link.
	DAT_REFRESH_INTERVAL - interval in seconds between two metric		DAT_REFRESH_INTERVAL - interval in seconds between two metric
	recalculations as described in Section 11. This value SHOULD be		recalculations as described in Section 10.2. This value SHOULD be
	smaller than a typical HELLO interval.		smaller than a typical HELLO interval.
	DAT_HELLO_TIMEOUT_FACTOR - timeout factor for HELLO interval at		DAT_HELLO_TIMEOUT_FACTOR - multiplier relative to the HELLO_INTERVAL
	which point a HELLO is definitely considered lost. The value must		(see [RFC6130] Section 5.3.1) after which the DAT metric considers
	be a floating point number between 1.0 and 2.0, large enough to		a HELLO as lost.
	take the delay and jitter for message aggregation into account.
	DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets		DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets
	(based on received packet sequence numbers) at which point the		(based on received packet sequence numbers) at which point the
	router considers the neighbor has restarted. This parameter is		router considers the neighbor has restarted. This parameter is
	only used for packet sequence number based loss estimation. This		only used for packet sequence number based loss estimation. This
	number MUST be larger than DAT_MAXIMUM_LOSS.		number MUST be larger than DAT_MAXIMUM_LOSS.
	6.1. Recommended Values		6.1. Recommended Values
	The proposed values of the protocol parameters are for Community Mesh		The proposed values of the protocol parameters are for Community Mesh
	Networks, which mostly use immobile mesh nodes. Using this metric		Networks, which mostly use immobile routers. Using this metric for
	for mobile networks might require shorter DAT_REFRESH_INTERVAL and/or		mobile networks might require shorter DAT_REFRESH_INTERVAL and/or
	DAT_MEMORY_LENGTH.		DAT_MEMORY_LENGTH.
	DAT_MEMORY_LENGTH := 64		DAT_MEMORY_LENGTH := 64
	DAT_REFRESH_INTERVAL := 1		DAT_REFRESH_INTERVAL := 1
	DAT_HELLO_TIMEOUT_FACTOR := 1.2		DAT_HELLO_TIMEOUT_FACTOR := 1.2
	DAT_SEQNO_RESTART_DETECTION := 256		DAT_SEQNO_RESTART_DETECTION := 256
	7. Protocol Constants		7. Protocol Constants
	This specification defines the following constants, which cannot be		This specification defines the following constants, which define the
	changed without making the metric outputs incomparable:		range of metric values that can be encoded by the DAT metric. They
			cannot be changed without making the metric outputs incomparable and
			should only be changed for MANET's with a very slow or very fast
			linklayer.
	DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing		DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing
	metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and		metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and
	(DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS: 8.		(DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS: 8.
	DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing		DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing
	metric: 1000.		metric: 1000.
	8. Data Structures		8. Data Structures
	This specification extends the Link Set Tuples of the Interface		This specification extends the Link Set of the Interface Information
	Information Base, as defined in [RFC6130] section 7.1, by the		Base, as defined in [RFC6130] section 7.1, by the adding the
	following additional elements for each link tuple when being used		following elements to each link tuple:
	with this metric:
	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.
	skipping to change at page 8, line 16		skipping to change at page 8, line 27
	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_hello_messages is the estimated number of lost hello
	messages from this neighbor, based on the value of the hello		messages from this neighbor, based on the value of the hello
	interval.		interval.
	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
			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
	described in a separate specification (e.g. [DLEP]). Any Link tuple		described in a separate specification (e.g. [DLEP]). Any Link tuple
	with L_status = HEARD or L_status = SYMMETRIC MUST have a specified		with L_status = HEARD or L_status = SYMMETRIC MUST have a specified
	value of L_DAT_rx_bitrate if it is to be used by this routing metric.		value of L_DAT_rx_bitrate if it is to be used by this routing metric.
	When using packet sequence numbers to estimate the loss rate, the		This specification updates the L_in_metric field of the Link Set of
	Link Set Tuples get another field:		the Interface Information Base, as defined in section 8.1. of
			[RFC7181])
	L_DAT_last_pkt_seqno is the last received packet sequence number
	received from this link.
	8.1. Initial Values		8.1. Initial Values
	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.
	skipping to change at page 8, line 51		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
			received).
	9. Packets and Messages		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		9.1. Definitions
	For the purpose of this section, note the following definitions:		For the purpose of this section, note the following definitions:
	o "pkt_seqno" is defined as the [RFC5444] packet sequence number of		o "pkt_seqno" is defined as the [RFC5444] packet sequence number of
	the received packet.		the received packet.
	o "interval_time" is the time encoded in the INTERVAL_TIME message		o "interval_time" is the time encoded in the INTERVAL_TIME message
	TLV of a received [RFC6130] HELLO message.		TLV of a received [RFC6130] HELLO message.
	9.2. Requirements		o "validity_time" is the time encoded in the VALIDITY_TIME message
			TLV of a received [RFC6130] HELLO message.
			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 MUST include the following parts into its [RFC5444] output:		document SHOULD include the following parts into its [RFC5444]
			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		9.3. Link Loss Data Gathering
	While this metric was designed for measuring the packet loss based on		While this metric was designed for measuring the packet loss based on
	the [RFC5444] packet sequence number, some implementations might not		the [RFC5444] packet sequence number, some implementations might not
	be able to add the packet sequence number to their output.		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		9.3.1. Packet Sequence based link loss
	An implementation of OLSRv2, using the metric specified by this		An implementation of OLSRv2, using the metric specified by this
	document with packet sequence based link loss, MUST include the		document with packet sequence based link loss, MUST include the
	following element into its [RFC5444] output:		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		For each incoming [RFC5444] packet, additional processing MUST 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 [OLSRV2].		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 MUST update the Link Set Tuple corresponding to the
	originator of the packet:		originator 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.
	skipping to change at page 10, line 51		skipping to change at page 11, line 28
	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_lost_hello_messages := 0.		3. L_DAT_lost_hello_messages := 0.
	9.3.3. Other Measurement of Link Loss		9.3.3. Other Measurement of Link Loss
	Instead of using incoming [RFC5444] packets or [RFC6130] messages,		Instead of using incoming [RFC5444] packets or [RFC6130] messages,
	the routing daemon can also use other sources to measure the link		the routing daemon can also use other sources to measure the link
	layer lossrate (e.g. [DLEP]).		layer lossrate (e.g. [DLEP]).
	To use a source like this with the DAT metric, the routing daemon has		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		to add incoming total traffic (or the sum of received and lost
	traffic) and lost traffic to the queued elements in the extension of		traffic) and lost traffic to the queued elements in the extension of
	the Link Set Tuple defined in Section 8 corresponding to originator		the Link Set Tuple defined in Section 8 corresponding to originator
	of the traffic.		of the traffic.
	The routing daemon should also set L_DAT_lost_hello_messages to zero		The routing daemon should also set L_DAT_lost_hello_messages to zero
	every times new packages arrive.		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.
	Only HELLO messages with an INTERVAL_TIME message TLVs must be		1. If the HELLO message contains an INTERVAL_TIME message TLV, then:
	processed.
	1. L_DAT_hello_interval := interval_time.		1. L_DAT_hello_interval := interval_time.
	10. HELLO Timeout Processing		2. Otherwise:
			1. L_DAT_hello_interval := validity_time.
			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:		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. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1.
	2. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval.		2. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval.
	11. 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).
	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_hello_messages > 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_hello_messages / 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 [OLSRV2] section		1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181]
	5.6.1.		section 5.6.1.
	5. Otherwise:		5. Otherwise:
	1. loss := sum_total / sum_received.		1. loss := sum_total / sum_received.
	2. If loss > DAT_MAXIMUM_LOSS, then:		2. If loss > DAT_MAXIMUM_LOSS, then:
	1. loss := DAT_MAXIMUM_LOSS.		1. loss := DAT_MAXIMUM_LOSS.
	3. bitrate := L_DAT_rx_bitrate.		3. bitrate := L_DAT_rx_bitrate.
	skipping to change at page 12, line 33		skipping to change at page 13, line 18
	DAT_MINIMUM_BITRATE).		DAT_MINIMUM_BITRATE).
	6. remove(L_DAT_total)		6. remove(L_DAT_total)
	7. add(L_DAT_total, 0)		7. add(L_DAT_total, 0)
	8. remove(L_DAT_received)		8. remove(L_DAT_received)
	9. add(L_DAT_received, 0)		9. add(L_DAT_received, 0)
	12. IANA Considerations		11. IANA Considerations
	This document contains no actions for IANA.		This document contains no actions for IANA.
	13. Security Considerations		12. Security Considerations
	Artificial manipulation of metrics values can drastically alter		Artificial manipulation of metrics values can drastically alter
	network performance. In particular, advertising a higher L_in_metric		network performance. In particular, advertising a higher L_in_metric
	value may decrease the amount of incoming traffic, while advertising		value may decrease the amount of incoming traffic, while advertising
	lower L_in_metric may increase the amount of incoming traffic. By		lower L_in_metric may increase the amount of incoming traffic. By
	artificially increasing or decreasing the L_in_metric values it		artificially increasing or decreasing the L_in_metric values it
	advertises, a rogue router may thus attract or repulse data traffic.		advertises, a rogue router may thus attract or repulse data traffic.
	A rogue router may then potentially degrade data throughput by not		A rogue router may then potentially degrade data throughput by not
	forwarding data as it should or redirecting traffic into routing		forwarding data as it should or redirecting traffic into routing
	loops or bad links.		loops or bad links.
	An attacker might also inject packets with incorrect packet level		An attacker might also inject packets with incorrect packet level
	sequence numbers, pretending to be somebody else. This attack could		sequence numbers, pretending to be somebody else. This attack can be
	be prevented by the true originator of the RFC5444 packets by adding		prevented by the true originator of the RFC5444 packets by adding a
	a [RFC6622] ICV Packet TLV and TIMESTAMP Packet TLV to each packet.		[RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet.
	This allows the receiver to drop all incoming packets which have a		This allows the receiver to drop all incoming packets which have a
	forged packet source, both packets generated by the attacker or		forged packet source, both packets generated by the attacker or
	replayed packets.		replayed packets. The signature scheme described in [RFC7183] does
			not protect the additional sequence number of the DAT metric because
			it does only sign the RFC5444 messages, not the RFC5444 packet
			header.
	14. Acknowledgements		13. Acknowledgements
	The authors would like to acknowledge the network administrators from		The authors would like to acknowledge the network administrators from
	Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for		Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for
	endless hours of testing and suggestions to improve the quality of		endless hours of testing and suggestions to improve the quality of
	the original ETX metric for the OLSR.org routing daemon.		the original ETX metric for the OLSR.org routing daemon.
	This effort/activity is supported by the European Community Framework		This effort/activity is supported by the European Community Framework
	Program 7 within the Future Internet Research and Experimentation		Program 7 within the Future Internet Research and Experimentation
	Initiative (FIRE), Community Networks Testbed for the Future Internet		Initiative (FIRE), Community Networks Testbed for the Future Internet
	([CONFINE]), contract FP7-288535.		([CONFINE]), contract FP7-288535.
	The authors would like to gratefully acknowledge the following people		The authors would like to gratefully acknowledge the following people
	for intense technical discussions, early reviews and comments on the		for intense technical discussions, early reviews and comments on the
	specification and its components (listed alphabetically): Teco Boot		specification and its components (listed alphabetically): Teco Boot
	(Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7),		(Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7),
	Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology		Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology
	Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus		Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus
	Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research		Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research
	Laboratory) and Stan Ratliff (Cisco Systems).		Laboratory) and Stan Ratliff (Cisco Systems).
	15. References		14. References
	15.1. Normative References		14.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing		[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
	Protocol", RFC 3626, October 2003.		Protocol", RFC 3626, October 2003.
	[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,		[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
	"Generalized Mobile Ad Hoc Network (MANET) Packet/Message		"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
	Format", RFC 5444, February 2009.		Format", RFC 5444, February 2009.
	[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value		[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
	Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March		Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March
	2009.		2009.
	[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc		[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
	Network (MANET) Neighborhood Discovery Protocol (NHDP)",		Network (MANET) Neighborhood Discovery Protocol (NHDP)",
	RFC 6130, April 2011.		RFC 6130, April 2011.
	[RFC6622] Ulrich, U. and T. Clausen, "Integrity Check Value and		[RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized
	Timestamp TLV Definitions for Mobile Ad Hoc Networks		Link State Routing Protocol version 2", RFC 7181, April
	(MANETs)", RFC 6622, May 2012.		2014.
	[OLSRV2] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized		[RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check
	Link State Routing Protocol version 2", draft-ietf-manet-		Value and Timestamp TLV Definitions for Mobile Ad Hoc
	olsrv2-19 , March 2013.		Networks (MANETs)", RFC 7182, April 2014.
	15.2. Informative References		[RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity
			Protection for the Neighborhood Discovery Protocol (NHDP)
			and Optimized Link State Routing Protocol Version 2
			(OLSRv2)", RFC 7183, April 2014.
	[CONFINE] , "Community Networks Testbed for the Future Internet		14.2. Informative References
			[CONFINE] "Community Networks Testbed for the Future Internet
	(CONFINE)", 2013, <http://www.confine-project.eu>.		(CONFINE)", 2013, <http://www.confine-project.eu>.
	[DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D.		[DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D.
	Satterwhite, "Dynamic Link Exchange Protocol (DLEP)",		Satterwhite, "Dynamic Link Exchange Protocol (DLEP)",
	draft-ietf-manet-dlep-04 , March 2013.		draft-ietf-manet-dlep-04 , March 2013.
	[MOBICOM03]		[MOBICOM03]
	De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A		De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A
	High-Throughput Path Metric for Multi-Hop Wireless		High-Throughput Path Metric for Multi-Hop Wireless
	Routing", Proceedings of the MOBICOM Conference , 2003.		Routing", Proceedings of the MOBICOM Conference , 2003.
	[MOBICOM04]		[MOBICOM04]
	Richard, D., Jitendra, P., and Z. Brian, "Routing in		Richard, D., Jitendra, P., and Z. Brian, "Routing in
	Multi-Radio, Multi-Hop Wireless Mesh Networks",		Multi-Radio, Multi-Hop Wireless Mesh Networks",
	Proceedings of the MOBICOM Conference , 2004.		Proceedings of the MOBICOM Conference , 2004.
	[OLSR.org]		[OLSR.org]
	, "The OLSR.org OLSR routing daemon", 2013,		"The OLSR.org OLSR routing daemon", 2013,
	<http://www.olsr.org/>.		<http://www.olsr.org/>.
	[FREIFUNK]		[FREIFUNK]
	, "Freifunk Wireless Community Networks", 2013,		"Freifunk Wireless Community Networks", 2013,
	<http://www.freifunk.net>.		<http://www.freifunk.net>.
	[FUNKFEUER]		[FUNKFEUER]
	, "Austria Wireless Community Network", 2013,		"Austria Wireless Community Network", 2013,
	<http://www.funkfeuer.at>.		<http://www.funkfeuer.at>.
	Appendix A. OLSR.org metric history		Appendix A. OLSR.org metric history
	The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR-		The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR-
	based [RFC3626] or B.A.T.M.A.N. based wireless community networks		based [RFC3626] or B.A.T.M.A.N. based wireless community networks
	with hundreds of routers in permanent operation. The Vienna		with hundreds of routers in permanent operation. The Vienna
	Funkfeuer network in Austria, for instance, consists of 400 routers		Funkfeuer network in Austria, for instance, consists of 400 routers
	(around 600 routes) covering the whole city of Vienna and beyond,		(around 600 routes) covering the whole city of Vienna and beyond,
	spanning roughly 40km in diameter. It has been in operation since		spanning roughly 40km in diameter. It has been in operation since
	2003 and supplies its users with Internet access. A particularity of		2003 and supplies its users with Internet access. A particularity of
	the Vienna Funkfeuer network is that it manages to provide Internet		the Vienna Funkfeuer network is that it manages to provide Internet
	access through a city wide, large scale Wi-Fi mesh network, with just		access through a city wide, large scale Wi-Fi MANET, with just a
	a single Internet uplink.		single Internet uplink.
	Operational experience of the OLSR project [OLSR.org] with these		Operational experience of the OLSR project [OLSR.org] with these
	networks have revealed that the use of hop-count as routing metric		networks have revealed that the use of hop-count as routing metric
	leads to unsatisfactory network performance. Experiments with the		leads to unsatisfactory network performance. Experiments with the
	ETX metric [MOBICOM03] were therefore undertaken in parallel in the		ETX metric [MOBICOM03] were therefore undertaken in parallel in the
	Berlin Freifunk network as well as in the Vienna Funkfeuer network in		Berlin Freifunk network as well as in the Vienna Funkfeuer network in
	2004, and found satisfactory, i.e., sufficiently easy to implement		2004, and found satisfactory, i.e., sufficiently easy to implement
	and providing sufficiently good performance. This metric has now		and providing sufficiently good performance. This metric has now
	been in operational use in these networks for several years.		been in operational use in these networks for several years.
	skipping to change at page 15, line 38		skipping to change at page 16, line 30
	ranged links with high bitrate (with higher but reasonable loss		ranged links with high bitrate (with higher but reasonable loss
	ratios). Such conditions, when they occur, can degrade the		ratios). Such conditions, when they occur, can degrade the
	performance of a network considerably by not taking advantage of		performance of a network considerably by not taking advantage of
	higher capacity links.		higher capacity links.
	Because of this the OLSR.org project has implemented the Directional		Because of this the OLSR.org project has implemented the Directional
	Airtime Metric for OLSRv2, which has been inspired by the Estimated		Airtime Metric for OLSRv2, which has been inspired by the Estimated
	Travel Time (ETT) metric [MOBICOM04]. This metric uses an		Travel Time (ETT) metric [MOBICOM04]. This metric uses an
	unidirectional packet loss, but also takes the bitrate into account		unidirectional packet loss, but also takes the bitrate into account
	to create a more accurate description of the relative costs or		to create a more accurate description of the relative costs or
	capabilities of mesh links.		capabilities of OLSRv2 links.
	Appendix B. Linkspeed stabilization		Appendix B. Linkspeed stabilization
	The DAT metric describes how to generate a reasonable stable packet		The DAT metric describes how to generate a reasonable stable packet
	loss value from incoming packet reception/loss events, the source of		loss value from incoming packet reception/loss events, the source of
	the linkspeed used in this document is considered an external		the linkspeed used in this document is considered an external
	process.		process.
	In the presence of a layer-2 technology with variable linkspeed it is		In the presence of a layer-2 technology with variable linkspeed it is
	likely that the raw linkspeed will be fluctuating too fast to be		likely that the raw linkspeed will be fluctuating too fast to be
End of changes. 58 change blocks.
	108 lines changed or deleted		148 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/