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/