--- 1/draft-ietf-roll-trickle-mcast-00.txt 2012-07-13 19:14:10.945426045 +0200 +++ 2/draft-ietf-roll-trickle-mcast-01.txt 2012-07-13 19:14:10.973425713 +0200 @@ -1,19 +1,19 @@ ROLL J. Hui Internet-Draft Cisco Intended status: Standards Track R. Kelsey -Expires: October 13, 2011 Ember Corporation - April 11, 2011 +Expires: January 14, 2013 Silicon Labs + July 13, 2012 Multicast Forwarding Using Trickle - draft-ietf-roll-trickle-mcast-00 + draft-ietf-roll-trickle-mcast-01 Abstract Low power and Lossy Networks (LLNs) are typically composed of resource constrained nodes communicating over links that have dynamic characteristics. Memory constraints coupled with temporal variations in link connectivity makes the use of topology maintenance to support IPv6 multicast challenging. This document describes the use of Trickle to efficiently forward multicast messages without the need for topology maintenance. @@ -26,25 +26,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -95,21 +95,21 @@ control traffic prohibitively expensive. In wireless environments, topology maintenance may involve selecting a connected dominating set used to forward multicast messages to all nodes in an administrative domain. However, existing mechanisms often require two-hop topology information, which is more state than a LLN node may be able to handle. This document describes the use of Trickle for IPv6 multicast forwarding in LLNs. Trickle provides a mechanism for controlled, density-aware flooding without the need to maintain a forwarding - topology [I-D.levis-roll-trickle]. + topology [RFC6206]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology Trickle Multicast Message A IPv6 multicast datagram that includes a @@ -195,27 +195,26 @@ performed. Instead, nodes simply retransmit multicast messages they are trying to forward. 4. Trickle Multicast Parameters All Trickle multicast forwarders within a Trickle multicast domain MUST be configured with two sets of configurations (one for each value of the M flag). Each configuration has five parameters: Imin The minimum Trickle timer interval as defined in - [I-D.levis-roll-trickle]. + [RFC6206]. Imax The maximum Trickle timer interval as defined in - [I-D.levis-roll-trickle]. + [RFC6206]. - k The redundancy constant as defined in - [I-D.levis-roll-trickle]. + k The redundancy constant as defined in [RFC6206]. Tactive The duration that a multicast forwarder can attempt to forward a multicast message. Specified in units of Imax. Tdwell The duration that a multicast forwarder must maintain sliding window state for SeedID after receiving the last multicast message from SeedID. Specified in units of Imax. @@ -418,21 +417,21 @@ When only one entry for a sliding window remains, that entry MUST NOT be reclaimed until its dwell timer expires. Maintaining the largest sequence value received from a SeedID ensures that earlier messages are received at most once. 6.2. Trickle Timers A Trickle multicast forwarder maintains two Trickle timers 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 transmission event consists of transmitting a Trickle ICMP message. If an "inconsistent" advertisement was received during that period, multicast messages that caused the inconsistency are also retransmitted. When suppression is disabled (i.e. k is infinite), a Trickle transmission event consists of transmitting multicast messages that @@ -487,29 +486,29 @@ messages are not listed in the Trickle ICMP message and the Trickle ICMP message contains a (SeedID, Sequence) pair for a prior multicast message. The receiver has a new multicast message to offer if any buffered messages does not have an associated SeedID entry in the Trickle ICMP message. If neither receiver nor transmitter has new multicast messages to 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 offer, the multicast forwarder logs an inconsistent event by - resetting Trickle timer T[M], as described in - [I-D.levis-roll-trickle]. All new messages that the receiver can - offer MUST be scheduled for transmission at the next transmission - event. Note that these transmissions may be suppressed if the - transmission event is suppressed. + resetting Trickle timer T[M], as described in [RFC6206]. All new + messages that the receiver can offer MUST be scheduled for + transmission at the next transmission event. Note that these + transmissions may be suppressed if the transmission event is + suppressed. 7. Acknowledgements TODO. 8. IANA Considerations The Trickle Multicast option requires an IPv6 Option Number. HEX act chg rest @@ -522,66 +521,57 @@ NOT change en-route. 9. Security Considerations TODO. 10. 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, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol 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 [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy - Networks", draft-ietf-roll-terminology-05 (work in - progress), March 2011. + Networks", draft-ietf-roll-terminology-06 (work in + progress), September 2011. Authors' Addresses Jonathan W. Hui Cisco 170 West Tasman Drive San Jose, California 95134 USA Phone: +408 424 1547 Email: jonhui@cisco.com Richard Kelsey - Ember Corporation - 47 Farnsworth Street + Silicon Labs + 25 Thomson Place Boston, Massachusetts 02210 USA Phone: +617 951 1225 - Email: kelsey@ember.com + Email: richard.kelsey@silabs.com