draft-ietf-roll-trickle-04.txt		draft-ietf-roll-trickle-05.txt
	Networking Working Group P. Levis		Networking Working Group P. Levis
	Internet-Draft Stanford University		Internet-Draft Stanford University
	Intended status: Standards Track T. Clausen		Intended status: Standards Track T. Clausen
	Expires: February 20, 2011 LIX, Ecole Polytechnique		Expires: May 14, 2011 LIX, Ecole Polytechnique
	J. Hui		J. Hui
	Arch Rock Corporation		Arch Rock Corporation
	O. Gnawali		O. Gnawali
	Stanford University		Stanford University
	J. Ko		J. Ko
	Johns Hopkins University		Johns Hopkins University
	August 19, 2010		November 10, 2010
	The Trickle Algorithm		The Trickle Algorithm
	draft-ietf-roll-trickle-04		draft-ietf-roll-trickle-05
	Abstract		Abstract
	The Trickle algorithm allows nodes in a lossy shared medium (e.g.,		The Trickle algorithm allows nodes in a lossy shared medium (e.g.,
	low power and lossy networks) to exchange information in a highly		low power and lossy networks) to exchange information in a highly
	robust, energy efficient, simple, and scalable manner. Dynamically		robust, energy efficient, simple, and scalable manner. Dynamically
	adjusting transmission windows allows Trickle to spread new		adjusting transmission windows allows Trickle to spread new
	information on the scale of link-layer transmission times while		information on the scale of link-layer transmission times while
	sending only a few messages per hour when information does not		sending only a few messages per hour when information does not
	change. A simple suppression mechanism and transmission point		change. A simple suppression mechanism and transmission point
	selection allows Trickle's communication rate to scale		selection allows Trickle's communication rate to scale
	logarithmically with density. This document describes the Trickle		logarithmically with density. This document describes the Trickle
	algorithm and considerations in its use.		algorithm and considerations in its use.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF 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.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on May 14, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 2, line 21		skipping to change at page 2, line 15
	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
	described in the BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Trickle Algorithm Overview . . . . . . . . . . . . . . . . . . 4		3. Trickle Algorithm Overview . . . . . . . . . . . . . . . . . . 4
	4. Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . 5		4. Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Parameters and Variables . . . . . . . . . . . . . . . . . 5		4.1. Parameters and Variables . . . . . . . . . . . . . . . . . 5
	4.2. Algorithm Description . . . . . . . . . . . . . . . . . . 6		4.2. Algorithm Description . . . . . . . . . . . . . . . . . . 6
	5. Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Operational Considerations . . . . . . . . . . . . . . . . . . 7		6. Operational Considerations . . . . . . . . . . . . . . . . . . 7
	6.1. Mismatched redundancy constants . . . . . . . . . . . . . 7		6.1. Mismatched redundancy constants . . . . . . . . . . . . . 7
	6.2. Mismatched Imin . . . . . . . . . . . . . . . . . . . . . 7		6.2. Mismatched Imin . . . . . . . . . . . . . . . . . . . . . 7
	6.3. Mismatched Imax . . . . . . . . . . . . . . . . . . . . . 7		6.3. Mismatched Imax . . . . . . . . . . . . . . . . . . . . . 7
	6.4. Mismatched definitions . . . . . . . . . . . . . . . . . . 8		6.4. Mismatched definitions . . . . . . . . . . . . . . . . . . 8
	6.5. Specifying the constant k . . . . . . . . . . . . . . . . 8		6.5. Specifying the constant k . . . . . . . . . . . . . . . . 8
	6.6. Relationship between k and Imin . . . . . . . . . . . . . 8		6.6. Relationship between k and Imin . . . . . . . . . . . . . 8
	6.7. Tweaks and improvements to Trickle . . . . . . . . . . . . 8		6.7. Tweaks and improvements to Trickle . . . . . . . . . . . . 9
	6.8. Uses of Trickle . . . . . . . . . . . . . . . . . . . . . 9		6.8. Uses of Trickle . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Trickle algorithm establishes a density-aware local communication		The Trickle algorithm establishes a density-aware local communication
	primitive with an underlying consistency model that guides when a		primitive with an underlying consistency model that guides when a
	node transmits. When a node's data does not agree with its		node transmits. When a node's data does not agree with its
	neighbors, that node communicates quickly to resolve the		neighbors, that node communicates quickly to resolve the
	inconsistency (e.g., in milliseconds). When nodes agree, they slow		inconsistency (e.g., in milliseconds). When nodes agree, they slow
	their communication rate exponentially, such that nodes send packets		their communication rate exponentially, such that nodes send packets
	very infrequently (e.g., a few packets per hour). Instead of		very infrequently (e.g., a few packets per hour). Instead of
	skipping to change at page 5, line 5		skipping to change at page 4, line 5
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	Additionally, this document introduces the following terminology:		Additionally, this document introduces the following terminology:
	Trickle communication rate: the sum of the number of messages sent		Trickle communication rate: the sum of the number of messages sent
	or received by the Trickle algorithm in an interval.		or received by the Trickle algorithm in an interval.
			Trickle transmission rate: the sum of the number of messages sent by
			the Trickle algorithm in an interval.
	3. Trickle Algorithm Overview		3. Trickle Algorithm Overview
	Trickle's basic primitive is simple: every so often, a node transmits		Trickle's basic primitive is simple: every so often, a node transmits
	data unless it hears a few other transmissions whose data suggest its		data unless it hears a few other transmissions whose data suggest its
	own transmission is redundant. Examples of such data include routing		own transmission is redundant. Examples of such data include routing
	state, software update versions, and the last heard multicast packet.		state, software update versions, and the last heard multicast packet.
	This primitive allows Trickle to scale to thousand-fold variations in		This primitive allows Trickle to scale to thousand-fold variations in
	network density, quickly propagate updates, distribute transmission		network density, quickly propagate updates, distribute transmission
	load evenly, be robust to transient disconnections, handle network		load evenly, be robust to transient disconnections, handle network
	repopulations, and impose a very low maintenance overhead: one		repopulations, and impose a very low maintenance overhead: one
	skipping to change at page 6, line 9		skipping to change at page 5, line 13
	consistency.		consistency.
	The fact that Trickle communication can be either transmission or		The fact that Trickle communication can be either transmission or
	reception enables the Trickle algorithm to operate in sparse as well		reception enables the Trickle algorithm to operate in sparse as well
	as dense networks. A single, disconnected node must transmit at the		as dense networks. A single, disconnected node must transmit at the
	Trickle communication rate. In a lossless, single-hop network of		Trickle communication rate. In a lossless, single-hop network of
	size n, the Trickle communication rate at each node equals the sum of		size n, the Trickle communication rate at each node equals the sum of
	the Trickle transmission rates across all nodes. The Trickle		the Trickle transmission rates across all nodes. The Trickle
	algorithm balances the load in such a scenario, as each node's		algorithm balances the load in such a scenario, as each node's
	Trickle transmission rate is 1/nth of the Trickle communication rate.		Trickle transmission rate is 1/nth of the Trickle communication rate.
	Sparser networks require more transmissions per node, but utilization		Sparser networks require more transmissions per node, but the
	of the radio channel over space will not increase. This is an		utilization of a given broadcast domain (e.g., radio channel over
	important property in wireless networks and other shared media, where		space, shared medium) will not increase. This is an important
	the channel is a valuable shared resource. Additionally, reducing		property in wireless networks and other shared media, where the
			channel is a valuable shared resource. Additionally, reducing
	transmissions in dense networks conserves system energy.		transmissions in dense networks conserves system energy.
	4. Trickle Algorithm		4. Trickle Algorithm
	This section describes the Trickle algorithm.		This section describes the Trickle algorithm.
	4.1. Parameters and Variables		4.1. Parameters and Variables
	A Trickle timer has three configuration parameters: the minimum		A Trickle timer has three configuration parameters: the minimum
	interval size Imin, the maximum interval size Imax, and a redundancy		interval size Imin, the maximum interval size Imax, and a redundancy
	constant k:		constant k:
	o The minimum interval size is defined in units of time (e.g.,		o The minimum interval size, Imin, is defined in units of time
	milliseconds, seconds). For example, a protocol might define the		(e.g., milliseconds, seconds). For example, a protocol might
	minimum interval as 100 milliseconds.		define the minimum interval as 100 milliseconds.
	o The maximum interval size is described as a number of doublings of		o The maximum interval size, Imax, is described as a number of
	the minimum interval size (the base-2 log(max/min)). For example,		doublings of the minimum interval size (the base-2 log(max/min)).
	a protocol might define the maximum interval as 16. If the		For example, a protocol might define Imax as 16. If the minimum
	minimum interval is 100ms, then the maximum interval is 100ms *		interval is 100ms, then the amount of time specified by Imax is
	65536, 6,553.6 seconds, or approximately 109 minutes.		100ms * 65536, 6,553.6 seconds, or approximately 109 minutes.
	o The redundancy constant is a natural number (an integer greater		o The redundancy constant is a natural number (an integer greater
	than zero).		than zero).
	In addition to these three parameters, Trickle maintains three		In addition to these three parameters, Trickle maintains three
	variables:		variables:
	o I, the current interval size		o I, the current interval size
	o t, a time within the current interval, and		o t, a time within the current interval, and
	skipping to change at page 7, line 21		skipping to change at page 6, line 21
	is, values greater than or equal to I/2 and less than I. The		is, values greater than or equal to I/2 and less than I. The
	interval ends at I.		interval ends at I.
	2. Whenever Trickle hears a transmission that is "consistent," it		2. Whenever Trickle hears a transmission that is "consistent," it
	increments the counter c.		increments the counter c.
	3. At time t, Trickle transmits if and only if the counter c is less		3. At time t, Trickle transmits if and only if the counter c is less
	than the redundancy constant k.		than the redundancy constant k.
	4. When the interval I expires, Trickle doubles the interval length.		4. When the interval I expires, Trickle doubles the interval length.
	If this new interval length would be longer than Imax, Trickle		If this new interval length would be longer than the time
	sets the interval length I to be Imax.		specified by Imax, Trickle sets the interval length I to be the
			time specified by Imax.
	5. If Trickle hears a transmission that is "inconsistent," the		5. If Trickle hears a transmission that is "inconsistent," the
	Trickle timer resets. If I is greater than Imin, resetting a		Trickle timer resets. If I is greater than Imin when a Trickle
	Trickle timer sets I to Imin and begins a new interval. If I is		timer resets, Trickle sets I to Imin, resets c to 0, and sets t
	equal to Imin, resetting a Trickle timer does nothing. Trickle		to random point in the interval, taken from the range [I/2, I),
	can also reset the timer in response to external "events."		that is, values greater than or equal to I/2 and less than I. If
			I is equal to Imin, resetting a Trickle timer does nothing.
			Trickle can also reset the timer in response to external
			"events."
	The terms consistent, inconsistent and event are in quotes because		The terms consistent, inconsistent and event are in quotes because
	their meaning depends on how a protocol uses Trickle.		their meaning depends on how a protocol uses Trickle.
	5. Using Trickle		5. Using Trickle
	A protocol specification that uses Trickle MUST specify:		A protocol specification that uses Trickle MUST specify:
	o Default values for Imin, Imax, and k. Because link layers can		o Default values for Imin, Imax, and k. Because link layers can
	vary widely in their properties, the default value of Imin SHOULD		vary widely in their properties, the default value of Imin SHOULD
	skipping to change at page 8, line 27		skipping to change at page 7, line 31
	6.1. Mismatched redundancy constants		6.1. Mismatched redundancy constants
	If nodes do not agree on the redundancy constant k, then nodes with		If nodes do not agree on the redundancy constant k, then nodes with
	higher values of k will transmit more often than nodes with lower		higher values of k will transmit more often than nodes with lower
	values of k. In some cases, this increased load can be independent		values of k. In some cases, this increased load can be independent
	of the density. For example, consider a network where all nodes but		of the density. For example, consider a network where all nodes but
	one have k=1, and this one node has k=2. The different node can end		one have k=1, and this one node has k=2. The different node can end
	up transmitting on every interval: it is maintaining a Trickle		up transmitting on every interval: it is maintaining a Trickle
	communication rate of 2 with only itself. Hence, the danger of		communication rate of 2 with only itself. Hence, the danger of
	mismatched k values is uneven transmission load that can deplete the		mismatched k values is uneven transmission load that can deplete the
	energy of some nodes.		energy of some nodes in a low power network.
	6.2. Mismatched Imin		6.2. Mismatched Imin
	If nodes do not agree on Imin, then some nodes, on hearing		If nodes do not agree on Imin, then some nodes, on hearing
	inconsistent messages, will transmit sooner than others. These		inconsistent messages, will transmit sooner than others. These
	faster nodes will have their intervals grow to similar size as the		faster nodes will have their intervals grow to similar size as the
	slower nodes within a single slow interval time, but in that period		slower nodes within a single slow interval time, but in that period
	may suppress the slower nodes. However, such suppression will end		may suppress the slower nodes. However, such suppression will end
	after the first slow interval, when the nodes generally agree on the		after the first slow interval, when the nodes generally agree on the
	interval size. Hence, mismatched Imin values are usually not a		interval size. Hence, mismatched Imin values are usually not a
	significant concern. Note that mismatched Imin values and matching		significant concern. Note that mismatched Imin values and matching
	Imax doubling constants will lead to mismatched Imax values.		Imax doubling constants will lead to mismatched maximum interval
			lengths.
	6.3. Mismatched Imax		6.3. Mismatched Imax
	If nodes do not agree on Imax, then this can cause long-term problems		If nodes do not agree on Imax, then this can cause long-term problems
	with transmission load. Nodes with small Imax values will transmit		with transmission load. Nodes with small Imax values will transmit
	faster, suppressing those with larger Imax values. The nodes with		faster, suppressing those with larger Imax values. The nodes with
	larger Imax values, always suppressed, will never transmit. In the		larger Imax values, always suppressed, will never transmit. In the
	base case, when the network is consistent, this can cause long-term		base case, when the network is consistent, this can cause long-term
	inequities in energy cost.		inequities in energy cost.
	skipping to change at page 9, line 34		skipping to change at page 8, line 36
	approach is especially dangerous if many nodes reset their intervals		approach is especially dangerous if many nodes reset their intervals
	at the same time. In general, it is much more desirable to set k to		at the same time. In general, it is much more desirable to set k to
	a high value (e.g., 5 or 10) than infinity. Typical values for k are		a high value (e.g., 5 or 10) than infinity. Typical values for k are
	1-5: these achieve a good balance between redundancy and low		1-5: these achieve a good balance between redundancy and low
	cost[Levis08].		cost[Levis08].
	Nevertheless, there are situations where a protocol may wish to turn		Nevertheless, there are situations where a protocol may wish to turn
	off Trickle suppression. Because k is a natural number		off Trickle suppression. Because k is a natural number
	(Section 4.1), k=0 has no useful meaning. If a protocol allows k to		(Section 4.1), k=0 has no useful meaning. If a protocol allows k to
	be dynamically configured, a value of 0 remains unused. For ease of		be dynamically configured, a value of 0 remains unused. For ease of
	debugging and packet inspection, having the parameter describe (k-1)		debugging and packet inspection, having the parameter describe k-1
	can be confusing. Instead, it is RECOMMENDED that protocols which		rather than k can be confusing. Instead, it is RECOMMENDED that
	require turning off suppression reserve k=0 to mean k=infinity.		protocols which require turning off suppression reserve k=0 to mean
			k=infinity.
	6.6. Relationship between k and Imin		6.6. Relationship between k and Imin
	Finally, a protocol SHOULD set k and Imin such that Imin is at least		Finally, a protocol SHOULD set k and Imin such that Imin is at least
	two to three as long as it takes to transmit k packets. Otherwise,		two to three times as long as it takes to transmit k packets.
	if more than k nodes reset their intervals to Imin, the resulting		Otherwise, if more than k nodes reset their intervals to Imin, the
	communication will lead to congestion and significant packet loss.		resulting communication will lead to congestion and significant
	Experimental results have shown that packet losses from congestion		packet loss. Experimental results have shown that packet losses from
	reduce Trickle's efficiency [Levis04].		congestion reduce Trickle's efficiency [Levis04].
	6.7. Tweaks and improvements to Trickle		6.7. Tweaks and improvements to Trickle
	Trickle is based on a small number of simple, tightly integrated		Trickle is based on a small number of simple, tightly integrated
	mechanisms that are highly robust to challenging network		mechanisms that are highly robust to challenging network
	environments. In our experiences using Trickle, attempts to tweak		environments. In our experiences using Trickle, attempts to tweak
	its behavior are typically not worth the cost. As written, the		its behavior are typically not worth the cost. As written, the
	algorithm is already highly efficient: further reductions in		algorithm is already highly efficient: further reductions in
	transmissions or response time come at the cost of failures in edge		transmissions or response time come at the cost of failures in edge
	cases. Based on our experiences, we urge protocol designers to		cases. Based on our experiences, we urge protocol designers to
	skipping to change at page 11, line 21		skipping to change at page 10, line 27
	The authors would also like to acknowledge the helpful comments of		The authors would also like to acknowledge the helpful comments of
	Yoav Ben-Yehezkel, Alexandru Petrescu, and Urlich Herberg, which		Yoav Ben-Yehezkel, Alexandru Petrescu, and Urlich Herberg, which
	greatly improved the document.		greatly improved the document.
	8. IANA Considerations		8. IANA Considerations
	This document has no IANA considerations.		This document has no IANA considerations.
	9. Security Considerations		9. Security Considerations
	This document has no security considerations.		As it is an algorithm, Trickle itself does not have any specific
			security considerations. However, two security concerns can arise
			when Trickle is used in a protocol. The first is that an adversary
			can force nodes to send many more packets than needed by forcing
			Trickle timer resets. In low power networks this increase in traffic
			can harm system lifetime. The second concern is that an adversary
			can prevent nodes from reaching consistency.
			Protocols can prevent adversarial Trickle resets by carefully
			selecting what can cause a reset and protecting these events and
			messages with proper security mechanisms. For example, if a node can
			reset nearby Trickle timers by sending a certain packet, this packet
			should be authenticated such that an adversary cannot forge one.
			An adversary can possibly prevent nodes from reaching consistency by
			suppressing transmissions with "consistent" messages. For example,
			imagine node A detects an inconsistency and resets its Trickle timer.
			If an adversary can prevent A from sending messages that inform
			nearby nodes of the inconsistency in order to repair it, then A may
			remain inconsistent indefinitely. Depending on the security model of
			the network, authenticated messages, or a transitive notion of
			consistency can prevent this problem. E.g., if messages that are
			consistent with A and so suppress its transmissions are by definition
			inconsistent with what A heard, then an adversary cannot
			simultaneously prevent A from notifying neighbors and not notify the
			neighbors itself (recall Trickle operates on shared, broadcast
			media). Note that this means Trickle should filter unicast messages.
	10. References		10. References
	10.1. Normative References		10.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", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	10.2. Informative References		10.2. Informative References
	[Dang09] Dang, T., Bulusu, N., Feng, W., and S. Park, "DHV: A Code		[Dang09] Dang, T., Bulusu, N., Feng, W., and S. Park, "DHV: A Code
	Consistency Maintenance Protocol for Multi-hop Wireless		Consistency Maintenance Protocol for Multi-hop Wireless
	Networks", Wireless Sensor Networks: 6th European		Networks", Wireless Sensor Networks: 6th European
	Conference Proceedings EWSN 2009 Cork, February 2009, <htt		Conference Proceedings EWSN 2009 Cork, February 2009,
	p://books.google.com/		<http://books.google.com/books?id=3fb5eePdkBg>.
	books?id=3fb5eePdkBgC&pg=PA327&lpg=PA327>.
	[Gnawali09]		[Gnawali09]
	Gnawali, O., Fonseca, R., Jamieson, K., Moss, D., and P.		Gnawali, O., Fonseca, R., Jamieson, K., Moss, D., and P.
	Levis, "Collection Tree Protocol", Proceedings of the 7th		Levis, "Collection Tree Protocol", Proceedings of the 7th
	ACM Conference on Embedded Networked Systems SenSys 2009,		ACM Conference on Embedded Networked Systems SenSys 2009,
	November 2009,		November 2009,
	<http://portal.acm.org/citation.cfm?id=1644038.1644040>.		<http://portal.acm.org/citation.cfm?id=1644038.1644040>.
	[Hui04] Hui, J. and D. Culler, "The dynamic behavior of a data		[Hui04] Hui, J. and D. Culler, "The dynamic behavior of a data
	dissemination protocol for network programming at scale",		dissemination protocol for network programming at scale",
	skipping to change at page 12, line 20		skipping to change at page 11, line 50
	Conference on Embedded Networked Systems SenSys 2008,		Conference on Embedded Networked Systems SenSys 2008,
	November 2008,		November 2008,
	<http://portal.acm.org/citation.cfm?id=1460412.1460415>.		<http://portal.acm.org/citation.cfm?id=1460412.1460415>.
	[I-D.hui-6man-trickle-mcast]		[I-D.hui-6man-trickle-mcast]
	Hui, J. and R. Kelsey, "Multicast Forwarding Using		Hui, J. and R. Kelsey, "Multicast Forwarding Using
	Trickle", draft-hui-6man-trickle-mcast-00 (work in		Trickle", draft-hui-6man-trickle-mcast-00 (work in
	progress), July 2010.		progress), July 2010.
	[I-D.ietf-roll-rpl]		[I-D.ietf-roll-rpl]
	Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing		Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
	Protocol for Low power and Lossy Networks",		Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
	draft-ietf-roll-rpl-11 (work in progress), July 2010.		Vasseur, "RPL: IPv6 Routing Protocol for Low power and
			Lossy Networks", draft-ietf-roll-rpl-15 (work in
			progress), November 2010.
	[Levis04] Levis, P., Patel, N., Culler, D., and S. Shenker,		[Levis04] Levis, P., Patel, N., Culler, D., and S. Shenker,
	"Trickle: A Self-Regulating Algorithm for Code Propagation		"Trickle: A Self-Regulating Algorithm for Code Propagation
	and Maintenance in Wireless Sensor Networks"", Proceedings		and Maintenance in Wireless Sensor Networks"", Proceedings
	of the First USENIX/ACM Symposium on Networked Systems		of the First USENIX/ACM Symposium on Networked Systems
	Design and Implementation NSDI 2004, March 2004,		Design and Implementation NSDI 2004, March 2004,
	<http://portal.acm.org/citation.cfm?id=1251177>.		<http://portal.acm.org/citation.cfm?id=1251177>.
	[Levis08] Levis, P., Brewer, E., Culler, D., Gay, D., Madden, S.,		[Levis08] Levis, P., Brewer, E., Culler, D., Gay, D., Madden, S.,
	Patel, N., Polastre, J., Shenker, S., Szewczyk, R., and A.		Patel, N., Polastre, J., Shenker, S., Szewczyk, R., and A.
End of changes. 23 change blocks.
	56 lines changed or deleted		86 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/