draft-ietf-roll-trickle-mcast-00.txt   draft-ietf-roll-trickle-mcast-01.txt 
ROLL J. Hui ROLL J. Hui
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track R. Kelsey Intended status: Standards Track R. Kelsey
Expires: October 13, 2011 Ember Corporation Expires: January 14, 2013 Silicon Labs
April 11, 2011 July 13, 2012
Multicast Forwarding Using Trickle Multicast Forwarding Using Trickle
draft-ietf-roll-trickle-mcast-00 draft-ietf-roll-trickle-mcast-01
Abstract Abstract
Low power and Lossy Networks (LLNs) are typically composed of Low power and Lossy Networks (LLNs) are typically composed of
resource constrained nodes communicating over links that have dynamic resource constrained nodes communicating over links that have dynamic
characteristics. Memory constraints coupled with temporal variations characteristics. Memory constraints coupled with temporal variations
in link connectivity makes the use of topology maintenance to support in link connectivity makes the use of topology maintenance to support
IPv6 multicast challenging. This document describes the use of IPv6 multicast challenging. This document describes the use of
Trickle to efficiently forward multicast messages without the need Trickle to efficiently forward multicast messages without the need
for topology maintenance. for topology maintenance.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 October 13, 2011. This Internet-Draft will expire on January 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 33 skipping to change at page 3, line 33
control traffic prohibitively expensive. In wireless environments, control traffic prohibitively expensive. In wireless environments,
topology maintenance may involve selecting a connected dominating set topology maintenance may involve selecting a connected dominating set
used to forward multicast messages to all nodes in an administrative used to forward multicast messages to all nodes in an administrative
domain. However, existing mechanisms often require two-hop topology domain. However, existing mechanisms often require two-hop topology
information, which is more state than a LLN node may be able to information, which is more state than a LLN node may be able to
handle. handle.
This document describes the use of Trickle for IPv6 multicast This document describes the use of Trickle for IPv6 multicast
forwarding in LLNs. Trickle provides a mechanism for controlled, forwarding in LLNs. Trickle provides a mechanism for controlled,
density-aware flooding without the need to maintain a forwarding density-aware flooding without the need to maintain a forwarding
topology [I-D.levis-roll-trickle]. topology [RFC6206].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
Trickle Multicast Message A IPv6 multicast datagram that includes a Trickle Multicast Message A IPv6 multicast datagram that includes a
skipping to change at page 7, line 12 skipping to change at page 7, line 12
performed. Instead, nodes simply retransmit multicast messages they performed. Instead, nodes simply retransmit multicast messages they
are trying to forward. are trying to forward.
4. Trickle Multicast Parameters 4. Trickle Multicast Parameters
All Trickle multicast forwarders within a Trickle multicast domain All Trickle multicast forwarders within a Trickle multicast domain
MUST be configured with two sets of configurations (one for each MUST be configured with two sets of configurations (one for each
value of the M flag). Each configuration has five parameters: value of the M flag). Each configuration has five parameters:
Imin The minimum Trickle timer interval as defined in Imin The minimum Trickle timer interval as defined in
[I-D.levis-roll-trickle]. [RFC6206].
Imax The maximum Trickle timer interval as defined in Imax The maximum Trickle timer interval as defined in
[I-D.levis-roll-trickle]. [RFC6206].
k The redundancy constant as defined in k The redundancy constant as defined in [RFC6206].
[I-D.levis-roll-trickle].
Tactive The duration that a multicast forwarder can Tactive The duration that a multicast forwarder can
attempt to forward a multicast message. attempt to forward a multicast message.
Specified in units of Imax. Specified in units of Imax.
Tdwell The duration that a multicast forwarder must Tdwell The duration that a multicast forwarder must
maintain sliding window state for SeedID after maintain sliding window state for SeedID after
receiving the last multicast message from SeedID. receiving the last multicast message from SeedID.
Specified in units of Imax. Specified in units of Imax.
skipping to change at page 12, line 49 skipping to change at page 12, line 49
When only one entry for a sliding window remains, that entry MUST NOT When only one entry for a sliding window remains, that entry MUST NOT
be reclaimed until its dwell timer expires. Maintaining the largest be reclaimed until its dwell timer expires. Maintaining the largest
sequence value received from a SeedID ensures that earlier messages sequence value received from a SeedID ensures that earlier messages
are received at most once. are received at most once.
6.2. Trickle Timers 6.2. Trickle Timers
A Trickle multicast forwarder maintains two Trickle timers A Trickle multicast forwarder maintains two Trickle timers
parameterized on the S flag. The Trickle timer is maintained as parameterized on the S flag. The Trickle timer is maintained as
described in [I-D.levis-roll-trickle]. described in [RFC6206].
When suppression is enabled (i.e. k is finite), a Trickle When suppression is enabled (i.e. k is finite), a Trickle
transmission event consists of transmitting a Trickle ICMP message. transmission event consists of transmitting a Trickle ICMP message.
If an "inconsistent" advertisement was received during that period, If an "inconsistent" advertisement was received during that period,
multicast messages that caused the inconsistency are also multicast messages that caused the inconsistency are also
retransmitted. retransmitted.
When suppression is disabled (i.e. k is infinite), a Trickle When suppression is disabled (i.e. k is infinite), a Trickle
transmission event consists of transmitting multicast messages that transmission event consists of transmitting multicast messages that
skipping to change at page 14, line 20 skipping to change at page 14, line 20
messages are not listed in the Trickle ICMP message and the Trickle messages are not listed in the Trickle ICMP message and the Trickle
ICMP message contains a (SeedID, Sequence) pair for a prior multicast ICMP message contains a (SeedID, Sequence) pair for a prior multicast
message. message.
The receiver has a new multicast message to offer if any buffered The receiver has a new multicast message to offer if any buffered
messages does not have an associated SeedID entry in the Trickle ICMP messages does not have an associated SeedID entry in the Trickle ICMP
message. message.
If neither receiver nor transmitter has new multicast messages to If neither receiver nor transmitter has new multicast messages to
offer, the multicast forwarder logs a consistent event by offer, the multicast forwarder logs a consistent event by
incrementing c, as described in [I-D.levis-roll-trickle]. incrementing c, as described in [RFC6206].
If either receiver or transmitter has new multicast messages to If either receiver or transmitter has new multicast messages to
offer, the multicast forwarder logs an inconsistent event by offer, the multicast forwarder logs an inconsistent event by
resetting Trickle timer T[M], as described in resetting Trickle timer T[M], as described in [RFC6206]. All new
[I-D.levis-roll-trickle]. All new messages that the receiver can messages that the receiver can offer MUST be scheduled for
offer MUST be scheduled for transmission at the next transmission transmission at the next transmission event. Note that these
event. Note that these transmissions may be suppressed if the transmissions may be suppressed if the transmission event is
transmission event is suppressed. suppressed.
7. Acknowledgements 7. Acknowledgements
TODO. TODO.
8. IANA Considerations 8. IANA Considerations
The Trickle Multicast option requires an IPv6 Option Number. The Trickle Multicast option requires an IPv6 Option Number.
HEX act chg rest HEX act chg rest
skipping to change at page 18, line 9 skipping to change at page 18, line 9
NOT change en-route. NOT change en-route.
9. Security Considerations 9. Security Considerations
TODO. TODO.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[I-D.levis-roll-trickle]
Levis, P. and T. Clausen, "The Trickle Algorithm",
draft-levis-roll-trickle-00 (work in progress),
February 2010.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[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.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011.
10.2. Informative References 10.2. Informative References
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-06 (work in
progress), March 2011. progress), September 2011.
Authors' Addresses Authors' Addresses
Jonathan W. Hui Jonathan W. Hui
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Phone: +408 424 1547 Phone: +408 424 1547
Email: jonhui@cisco.com Email: jonhui@cisco.com
Richard Kelsey Richard Kelsey
Ember Corporation Silicon Labs
47 Farnsworth Street 25 Thomson Place
Boston, Massachusetts 02210 Boston, Massachusetts 02210
USA USA
Phone: +617 951 1225 Phone: +617 951 1225
Email: kelsey@ember.com Email: richard.kelsey@silabs.com
 End of changes. 16 change blocks. 
33 lines changed or deleted 23 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/