draft-ietf-roll-trickle-mcast-01.txt		draft-ietf-roll-trickle-mcast-02.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: January 14, 2013 Silicon Labs		Expires: April 22, 2013 Silicon Labs
	July 13, 2012		October 19, 2012
	Multicast Forwarding Using Trickle		Multicast Protocol for Low power and Lossy Networks (MPL)
	draft-ietf-roll-trickle-mcast-01		draft-ietf-roll-trickle-mcast-02
	Abstract		Abstract
	Low power and Lossy Networks (LLNs) are typically composed of		This document specifies the Multicast Protocol for Low power and
	resource constrained nodes communicating over links that have dynamic		Lossy Networks (MPL) that provides IPv6 multicast forwarding in
	characteristics. Memory constraints coupled with temporal variations		constrained networks. MPL avoids the need to construct or maintain
	in link connectivity makes the use of topology maintenance to support		any multicast forwarding topology, disseminating messages to all MPL
	IPv6 multicast challenging. This document describes the use of		forwarders in an MPL domain. MPL uses the Trickle algorithm to drive
	Trickle to efficiently forward multicast messages without the need		packet transmissions for both control and data-plane packets.
	for topology maintenance.		Specific Trickle parameter configurations allow MPL to trade between
			dissemination latency and transmission efficiency.
	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.
	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 14, 2013.		This Internet-Draft will expire on April 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Trickle Multicast Parameters . . . . . . . . . . . . . . . . . 7		4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Trickle Multicast Option . . . . . . . . . . . . . . . . . 9		4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8
	5.2. Trickle ICMPv6 Message . . . . . . . . . . . . . . . . . . 10		4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9
	5.2.1. Sequence List . . . . . . . . . . . . . . . . . . . . 11		5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11
	6. Trickle Multicast Forwarder Behavior . . . . . . . . . . . . . 12		5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11
	6.1. Managing Sliding Windows . . . . . . . . . . . . . . . . . 12		5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12
	6.2. Trickle Timers . . . . . . . . . . . . . . . . . . . . . . 12		5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12
	6.3. Trickle Multicast Option Processing . . . . . . . . . . . 13		5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13
	6.4. Trickle ICMP Processing . . . . . . . . . . . . . . . . . 13		5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 18		6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . . 18		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
			9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
			10.2. Informative References . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	The resource constraints of Low power and Lossy Networks (LLNs) may		Low power and Lossy Networks typically operate with strict resource
	preclude the use of existing IPv6 multicast forwarding mechanisms.		constraints in communication, computation, memory, and energy. Such
	Such networks are typically constrained in resources (limited channel		resource constraints may preclude the use of existing IPv6 multicast
	capacity, processing power, energy capacity, memory). In particular		topology and forwarding mechanisms. Traditional IP multicast
	memory constraints may limit nodes to maintaining state for only a		forwarding typically relies on topology maintenance mechanisms to
	small subset of neighbors. Limited channel and energy capacity		forward multicast messages to all subscribers of a multicast group.
	require protocols to remain efficient and robust even in dense		However, maintaining such topologies in LLNs is costly and may not be
	topologies.		feasible given the available resources.
	Traditional IP multicast forwarding typically relies on topology		Memory constraints may limit devices to maintaining links/routes to
	maintenance mechanisms to efficiently forward multicast messages to		one or a few neighbors. For this reason, the Routing Protocol for
	the intended destinations. In some cases, topology maintenance		LLNs (RPL) specifies both storing and non-storing modes [RFC6550].
	involves maintaining multicast trees to reach all subscribers of a		The latter allows RPL routers to maintain only one or a few default
	multicast group. Maintaining such topologies is difficult especially		routes towards a LLN Border Router (LBR) and use source routing to
	when memory constraints are such that nodes can only maintain a		forward packets away from the LBR. For the same reasons, a LLN
	default route. Dynamic properties of wireless networks can make		device may not be able to maintain a multicast forwarding topology
	control traffic prohibitively expensive. In wireless environments,		when operating with limited memory.
	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		Furthermore, the dynamic properties of wireless networks can make the
	forwarding in LLNs. Trickle provides a mechanism for controlled,		cost of maintaining a multicast forwarding topology prohibitively
	density-aware flooding without the need to maintain a forwarding		expensive. In wireless environments, topology maintenance may
	topology [RFC6206].		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 and the cost of maintaining such information grows
			polynomially with network density.
	1.1. Requirements Language		This document specifies the Multicast Protocol for Low power and
			Lossy Networks (MPL), which provides IPv6 multicast forwarding in
			constrained networks. MPL avoids the need to construct or maintain
			any multicast forwarding topology, disseminating multicast messages
			to all MPL forwarders in an MPL domain. By using the Trickle
			algorithm [RFC6206], MPL requires only small, constant state for each
			MPL device that initiates disseminations. The Trickle algorithm also
			allows MPL to be density-aware, allowing the communication rate to
			scale logarithmically with density.
			2. Terminology
	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		The following terms are used throughout this document:
	Trickle Multicast Message A IPv6 multicast datagram that includes a
	Trickle Multicast option in the IPv6 Hop-by-Hop
	Options header.
	Trickle Multicast Forwarder A IPv6 router that can process a Trickle
	Multicast option and follows the forwarding rules
	specified in this document.
	Trickle Multicast Domain An administrative domain that defines the
	scope of Trickle dissemination. All routers
	within a Trickle Multicast Domain participate in
	the same dissemination process.
	Seed The router that starts the dissemination process
	for a Trickle multicast message. The Seed may be
	different than the node identified by the IPv6
	Source address of the multicast message.
	3. Overview
	Trickle multicast forwarding implements a controlled, density-aware
	flood to disseminate a IPv6 multicast message to all nodes within a
	Trickle Multicast Domain. The basic process is similar to
	traditional flooding - nodes forward newly received multicast
	messages using link-layer broadcasts. Nodes maintain state of
	recently received multicast messages to detect duplicates and ensure
	that each node receives at most one copy of each multicast message.
	Each Trickle multicast message carries a Trickle Multicast option
	that includes a SeedID and Sequence value. The SeedID uniquely
	identifies the Seed that initiated the message's dissemination
	process within the Trickle Multicast Domain. Note that the Seed does
	not have to be the same node as the message's source. It is possible
	to tunnel a multicast message to a Seed node and start the
	dissemination process from a different node within the Trickle
	Multicast Domain.
	The Sequence value establishes a total ordering of multicast messages
	disseminated by SeedID. Nodes maintain a sliding window of recently
	received multicast messages for each SeedID. The sliding window
	establishes what messages can be received and ensure at most one copy
	of each multicast message is received. Messages with sequence values
	lower than the lower bound of the window MUST be ignored. Messages
	with sequence values stored within the sliding window MUST be
	ignored. All other messages MUST be received, advancing the sliding
	window if necessary. Larger sequence values always take precedence.
	The sliding window can be of variable size, trading memory
	requirements for reliability of disseminating multiple messages
	simultaneously.
	Trickle's density-aware properties come from its suppression
	mechanism. When suppression is enabled, nodes periodically advertise
	a summary of recently received multicast messages. These
	advertisements allow nodes to determine if they have any additional
	multicasts to offer to neighboring nodes. A multicast message is
	only retransmitted upon receiving positive indication that a neighbor
	has not yet received that multicast message.
	Nodes suppress advertisement transmissions and multicast
	retransmissions after recently receiving "consistent" advertisements.
	A node determines that a neighbor's advertisement is "consistent"
	when neither node has new multicast messages to offer to the other.
	The suppression reduces the number of redundant transmissions and is
	what allows Trickle to maintain low channel utilization in dense
	environments. However, suppression trades low control overhead for
	longer propagation times. When using suppression, Trickle's
	propagation times often have a long-tail distribution.
	Trickle provides an adaptive timer, called the Trickle timer. When		MPL forwarder An IPv6 router that subscribes to the MPL
	receiving an "inconsistent" advertisement, nodes reset the Trickle		multicast group and participates in disseminating
	timer period to a small period so that dissemination happens quickly.		MPL multicast packets.
	The Trickle timer period doubles when the period expires and no
	"inconsistent" advertisements have been received, reducing control
	overhead when the network is in a consistent state.
	This document does allow configurations that disable the suppression		MPL multicast scope The multicast scope that MPL uses when forwarding
	mechanism, reducing Trickle Multicast Forwarding to simple flooding.		MPL multicast packets. In other words, the
	This can be done by setting the suppression threshold for received		multicast scope of the IPv6 Destination Address
	"consistent" advertisements to infinity. In this mode, Trickle		of an MPL multicast packet.
	advertisements are not sent since consistency checks are not
	performed. Instead, nodes simply retransmit multicast messages they
	are trying to forward.
	4. Trickle Multicast Parameters		MPL domain A connected set of MPL forwarders that define the
			extent of the MPL dissemination process. As a
			form of flood, all MPL forwarders in an MPL
			domain will receive MPL multicast packets. The
			MPL domain MUST be composed of at least one MPL
			multicast scope and MAY be composed of multiple
			MPL multicast scopes.
	All Trickle multicast forwarders within a Trickle multicast domain		MPL seed A MPL forwarder that begins the dissemination
	MUST be configured with two sets of configurations (one for each		process for an MPL multicast packet. The MPL
	value of the M flag). Each configuration has five parameters:		seed may be different than the source of the
			original multicast packet.
	Imin The minimum Trickle timer interval as defined in		MPL seed identifier An identifier that uniquely identifies an MPL
	[RFC6206].		forwarder within its MPL domain.
	Imax The maximum Trickle timer interval as defined in		original multicast packet An IPv6 multicast packet that is
	[RFC6206].		disseminated using MPL.
	k The redundancy constant as defined in [RFC6206].		MPL multicast packet An IPv6 multicast packet that contains an MPL
			Hop-by-Hop Option. When either source or
			destinations are beyond the MPL multicast scope,
			the MPL multicast packet is an IPv6-in-IPv6
			packet that contains an MPL Hop-by-Hop Option in
			the outer IPv6 header and encapsulates an
			original multicast packet. When both source and
			destinations are within the MPL multicast scope,
			the MPL Hop-by-Hop Option may be included
			directly within the original multicast packet.
	Tactive The duration that a multicast forwarder can		3. Overview
	attempt to forward a multicast message.
	Specified in units of Imax.
	Tdwell The duration that a multicast forwarder must		MPL delivers IPv6 multicast packets by disseminating them to all MPL
	maintain sliding window state for SeedID after		forwarders within an MPL domain. MPL dissemination is a form of
	receiving the last multicast message from SeedID.		flood. An MPL forwarder may broadcast/multicast an MPL multicast
	Specified in units of Imax.		packet out of the same physical interface on which it was received.
			Using link-layer broadcast/multicast allows MPL to forward multicast
			packets without explicitly identifying next-hop destinations. An MPL
			forwarder may also broadcast/multicast MPL multicast packets out
			other interfaces to disseminate the message across different links.
			MPL does not build or maintain a multicast forwarding topology to
			forward multicast packets.
	Tactive specifies the time duration that a node may retransmit a		Any MPL forwarder may initiate the dissemination process by serving
	multicast message in attempt to forward it to neighboring nodes.		as an MPL seed for an original multicast packet. The MPL seed may or
	Larger values of Tactive increases the number of retransmissions and		may not be the same device as the source of the original multicast
	overall dissemination reliability.		packet. When the original multicast packet's source is outside the
			LLN, the MPL seed may be the ingress router. Even if an original
			multicast packet source is within the LLN, the source may first
			forward the multicast packet to the MPL seed using IPv6-in-IPv6
			tunneling. Because MPL state requirements grows with the number of
			active MPL seeds, limiting the number of MPL seeds reduces the amount
			of state that MPL forwarders must maintain.
	Tdwell specifies the time duration for maintaining sliding window		Because MPL typically broadcasts/multicasts MPL packets out of the
	state to ensure that a multicast message from SeedID is received at		same interface on which they were received, MPL forwarders are likely
	most once. Larger values of Tdwell decreases the likelihood that a		to receive an MPL multicast packet more than once. The MPL seed tags
	node will receive a multicast message more than once.		each original multicast packet with an MPL seed identifier and a
			sequence number. The sequence number provides a total ordering of
			MPL multicast packets disseminated by the MPL seed.
	The specific values are left out of scope of this document as they		MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include
	are dependent on link-specific properties. How those parameters are		MPL-specific information along with the original multicast packet.
	configured are also left out of scope.		Each IPv6 multicast packet that MPL disseminates includes the MPL
			Option. Because the original multicast packet's source and the MPL
			seed may not be the same device, the MPL Option may be added to the
			original multicast packet en-route. To allow Path MTU discovery to
			work properly, MPL encapsulates the original multicast packet in
			another IPv6 header that includes the MPL Option.
	The Trickle multicast parameters allow both aggressive and		Upon receiving a new MPL multicast packet for forwarding, the MPL
	conservative multicast forwarding strategies. For example, an		forwarder may proactively transmit the MPL multicast packet packet a
	aggressive strategy may specify each multicast forwarder to		limited number of times and then falls back into an optional reactive
	retransmit any newly received message 3 times on a short fixed period		mode. In maintenance mode, an MPL forwarder buffers recently
	and maintain state for 12 retransmission periods to avoid receiving		received MPL multicast packets and advertises a summary of recently
	duplicate messages. This aggressive policy can be specified using a		received MPL multicast packets from time to time, allowing
	Trickle parameter set of Imin = Imax = 100ms, k = infinity, Tactive =		neighboring MPL forwarders to determine if they have any new
	3, and Tdwell = 12. Setting k to infinity disables the Trickle		multicast packets to offer or receive.
	suppression mechanism.
	A conservative multicast forwarding strategy utilizes Trickle		MPL forwarders schedule their packet (control and data) transmissions
	suppression and a larger Imax value to minimize redundant		using the Trickle algorithm [RFC6206]. Trickle's adaptive
	transmissions. One such conservative policy is a Trickle parameter		transmission interval allows MPL to quickly disseminate messages when
	set of Imin = 100ms, Imax = 30min, k = 1, Tactive = 3, and Tdwell =		there are new MPL multicast packets, but reduces transmission
	12.		overhead as the dissemination process completes. Trickle's
			suppression mechanism and transmission time selection allow MPL's
			communication rate to scale logarithmically with density.
	5. Message Formats		4. Message Formats
	5.1. Trickle Multicast Option		4.1. MPL Option
	The Trickle Multicast option is carried in an IPv6 Hop-by-Hop Options		The MPL Option is carried in an IPv6 Hop-by-Hop Options header,
	header, immediately following the IPv6 header. The Trickle Multicast		immediately following the IPv6 header. The MPL Option has the
	option has the following format:		following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Opt Data Len |		| Option Type | Opt Data Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SeedID (optional) |M| Sequence |		| S |M| rsv | sequence | seed-id (optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Option Type XX (to be confirmed by IANA).		Option Type XX (to be confirmed by IANA).
	Opt Data Len Length of the Option Data field in octets. MUST		Opt Data Len Length of the Option Data field in octets. MUST
	be set to either 2 or 4.		be set to either 2 or 4.
	SeedID Uniquely identifies a Trickle multicast seed that		S 2-bit unsigned integer. Identifies the length of
	initiated the dissemination process. The SeedID		seed-id. 0 indicates that the seed-id is 0 and
	field is optional and only appears when Opt Data		not included in the MPL Option. 1 indicates that
	Len is set to 4. When Opt Data Len is set to 2,		the seed-id is a 16-bit unsigned integer. 2
	the SeedID is equivalent to the IPv6 Source		indicates that the seed-id is a 64-bit unsigned
	address.		integer. 3 indicates that the seed-id is a 128-
			bit unsigned integer.
	M Mode flag. Identifies one of two Trickle		M 1-bit flag. 0 indicates that the value in
	parameters to use when forwarding this multicast		sequence is not the greatest sequence number that
	message.		was received from the MPL seed.
	Sequence Identifies relative ordering of multicast		rsv 5-bit reserved field. MUST be set to zero and
	messages from the source identified by SeedID.		incoming MPL multicast packets in which they are
			not zero MUST be dropped.
	The Option Data of the Trickle Multicast option MUST NOT change en-		sequence 8-bit unsigned integer. Identifies relative
	route. Nodes that do not understand the Trickle Multicast option		ordering of MPL multicast packets from the source
	MUST skip over this option and continue processing the header. Thus,		identified by seed-id.
			seed-id Uniquely identifies the MPL seed that initiated
			dissemination of the MPL multicast packet. The
			size of seed-id is indicated by the S field.
			The Option Data of the Trickle Multicast option MUST NOT change as
			the MPL multicast packet is forwarded. Nodes that do not understand
			the Trickle Multicast option MUST discard the packet. Thus,
	according to [RFC2460] the three high order bits of the Option Type		according to [RFC2460] the three high order bits of the Option Type
	must be equal set to zero. The Option Data length is variable.		must be set to '010'. The Option Data length is variable.
	The SeedID uniquely identifies a Trickle multicast seed within the		The seed-id uniquely identifies an MPL seed within the MPL domain.
	Trickle multicast domain. The SeedID field may either be an IPv6		When seed-id is 128 bits (S=3), the MPL seed MAY use an IPv6 address
	address assigned to the seed node or a managed 16-bit value. In		assigned to one of its interfaces that is unique within the MPL
	either case, the SeedID MUST be unique within the Trickle multicast		domain. Managing MPL seed identifiers is not within scope of this
	domain. Managing the SeedID namespace is left out of scope.		document.
	The M flag identifies one of two Trickle parameters to use when		The sequence field establishes a total ordering of MPL multicast
	forwarding the message. This capability allows a Trickle Multicast		packets from the same MPL seed. The MPL seed MUST increment the
	Domain to support two different Trickle parameter sets that make		sequence field's value on each new MPL multicast packet that it
	different propagation time vs. control overhead trade-offs.		disseminates. Implementations MUST follow the Serial Number
			Arithmetic as defined in [RFC1982] when incrementing a sequence value
			or comparing two sequence values.
	Sequence establishes a relative ordering of multicast messages from		Future updates to this specification may define additional fields
	the same SeedID. The source MUST increment the Sequence value when		following the seed-id field.
	sourcing a new Trickle multicast message. Implementations MUST
	follow the Serial Number Arithmetic as defined in [RFC1982].
	5.2. Trickle ICMPv6 Message		4.2. ICMPv6 MPL Message
	The Trickle ICMP message is used to advertise metadata for recently		The MPL forwarder uses ICMPv6 MPL messages to advertise information
	received Trickle multicast messages. The Trickle ICMP message has		about recently received MPL multicast packets. The ICMPv6 MPL
	the following format:		message has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. Sequence List[1..n] .		. MPL Window[1..n] .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IP Fields:		IP Fields:
	Source Address A link-local address assigned to the sending		Source Address A link-local address assigned to the sending
	interface.		interface.
	Destination Address The link-local all-nodes (FF02::1) or link-local		Destination Address The link-local all-nodes MPL forwarders multicast
	all-routers (FF02::2) multicast address.		address (FF02::TBD).
	Hop Limit 255		Hop Limit 255
	ICMP Fields:		ICMPv6 Fields:
	Type XX (to be confirmed by IANA).		Type XX (to be confirmed by IANA).
	Code 0		Code 0
	Checksum The ICMP checksum. See [RFC4443].		Checksum The ICMP checksum. See [RFC4443].
	Sequence List[1..n] List of zero, one, or more Sequence Lists		MPL Window[1..n] List of one or more MPL Windows (defined in
	(defined in Section 5.2.1).		Section 4.2.1).
	The Trickle ICMP message advertises sliding windows maintained by the		An MPL forwarder transmits an ICMPv6 MPL message to advertise
	multicast forwarder. The advertisement serves to notify neighbors of		information about buffered MPL multicast packets. More explicitly,
	newer messages that it can propagate or has yet to receive. Only		the ICMPv6 MPL message encodes the sliding window state (described in
	entries for messages where Tactive has not expired are included in		Section 5.2) that the MPL forwarder maintains for each MPL seed. The
	the ICMP message. The sliding windows are encoded using a Sequence		advertisement serves to indicate to neighboring MPL forwarders
	List, defined in Section 5.2.1.		regarding newer messages that it may send or the neighboring MPL
			forwarders have yet to receive.
	5.2.1. Sequence List		4.2.1. MPL Window
	A Sequence List contains a list of Sequence values for a SeedID.		An MPL Window encodes the sliding window state (described in
	Each Sequence List has the following format:		Section 5.2 that the MPL forwarder maintains for an MPL seed. Each
			MPL Window has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S|M| rsv | SeqLen | SeedID (2 or 16 octets) |		| w-min | w-len | S | seed-id (0, 2 or 16 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. Sequence[1..SeqLen] .		. buffered-mpl-packets (0 to 8 octets) .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	S Indicates length of SeedID. When set to 0,		w-min 8-bit unsigned integer. Indicates the first
	SeedID is 16 octets. When set to 1, SeedID is 2		sequence number associated with the first bit in
	octets.		buffered-mpl-packets.
	M Indicates one of two Trickle parameter sets used		w-len 6-bit unsigned integer. Indicates the size of
	for disseminating multicast messages.		the sliding window and the number of valid bits
			in buffered-mpl-packets. The sliding window's
			upper bound is the sum of w-min and w-len.
	SeqLen Number of 2-octet Sequence entries.		S 2-bit unsigned integer. Identifies the length of
			seed-id. 0 indicates that the seed-id value is 0
			and not included in the MPL Option. 1 indicates
			that the seed-id value is a 16-bit unsigned
			integer. 2 indicates that the seed-id value is a
			128-bit unsigned integer. 3 is reserved.
	SeedID Copied from a recently received Trickle Multicast		seed-id Indicates the MPL seed associated with this
	option.		sliding window.
	Sequence[1..SeqLen] List of recently received Sequence values from		buffered-mpl-packets Variable-length bit vector. Identifies the
	SeedID. Note that the Sequence value is only 15		sequence numbers of MPL multicast packets that
	bits and the highest order bit MUST be set to 0.		the MPL forwarder has buffered. The sequence
			number is determined by w-min + i, where i is the
			offset within buffered-mpl-packets.
	6. Trickle Multicast Forwarder Behavior		The MPL Window does not have any octet alignment requirement.
	A Trickle Multicast Forwarder implementation needs to manage sliding		5. MPL Forwarder Behavior
	windows and Trickle timers. These mechanisms are used to determine
	when received messages should be accepted, when ICMP messages are
	transmitted, and when multicast messages are retransmitted.
	6.1. Managing Sliding Windows		An MPL forwarder implementation needs to manage sliding windows for
			each active MPL seed. The sliding window allows the MPL forwarder to
			determine what multicast packets to accept and what multicast packets
			are buffered. An MPL forwarder must also manage MPL packet
			transmissions.
	Every Trickle multicast forwarder MUST maintain a sliding window of		5.1. Multicast Packet Dissemination
	Sequence values for each SeedID that generated recently received
	multicast messages.
	When receiving a Trickle multicast message, if no existing sliding		MPL uses the Trickle algorithm to control packet transmissions when
	window exists for the SeedID, a new sliding window MUST be created		disseminating MPL multicast packets [RFC6206]. MPL provides two
	before accepting the message. If memory constraints are such that a		propagation mechanisms for disseminating MPL multicast packets.
	new sliding window cannot be created, then the message must be
	ignored.
	If a sliding window exists for the SeedID, the message must be		1. With proactive propagation, an MPL forwarder transmits buffered
	ignored if the message's Sequence value falls below the lower bound		MPL multicast packets using the Trickle algorithm. This method
	of the window or appears in the list of stored Sequence values within		is called proactive propagation since an MPL forwarder actively
	the window. All other messages MUST be received.		transmits MPL multicast packets without discovering that a
			neighboring MPL forwarder has yet to receive the message.
	When receiving a message, the sliding window MUST be updated with the		2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL
	message's Sequence value. If the Sequence value is larger than the		messages using the Trickle algorithm. An MPL forwarder only
	upper bound of the window, the new message establishes the new upper		transmits buffered MPL multicast packets upon discovering that
	bound.		neighboring devices have not yet to receive the corresponding MPL
			multicast packets.
	Memory constraints may limit the total number of Sequence values that		When receiving a new multicast packet, an MPL forwarder first
	can be stored. An entry may be reclaimed before the dwell time		utilizes proactive propagation to forward the MPL multicast packet.
	expires if it serves as the lower bound of the window and the window		Proactive propagation reduces dissemination latency since it does not
	has more than one entry. Note that entries can be reclaimed from		require discovering that neighboring devices have not yet received
	sliding windows for other SeedIDs.		the MPL multicast packet. MPL forwarders utilize proactive
			propagation for newly received MPL multicast packets since they can
			assume that some neighboring MPL forwarders have yet to receive the
			MPL multicast packet. After a limited number of MPL multicast packet
			transmissions, the MPL forwarder may terminate proactive propagation
			for the MPL multicast packet.
	When only one entry for a sliding window remains, that entry MUST NOT		An MPL forwarder may optionally use reactive propagation to continue
	be reclaimed until its dwell timer expires. Maintaining the largest		the dissemination process with lower communication overhead. With
	sequence value received from a SeedID ensures that earlier messages		reactive propagation, neighboring MPL forwarders use ICMPv6 MPL
	are received at most once.		messages to discover new MPL multicast messages that have not yet
			been received. When discovering that a neighboring MPL forwarder has
			not yet received a new MPL multicast packet, the MPL forwarder
			enables proactive propagation again.
	6.2. Trickle Timers		5.1.1. Trickle Parameters and Variables
	A Trickle multicast forwarder maintains two Trickle timers		As specified in RFC 6206 [RFC6206], a Trickle timer runs for a
	parameterized on the S flag. The Trickle timer is maintained as		defined interval and has three configuration parameters: the minimum
	described in [RFC6206].		interval size Imin, the maximum interval size Imax, and a redundancy
			constant k.
	When suppression is enabled (i.e. k is finite), a Trickle		MPL defines a fourth configuration parameter, TimerExpirations, which
	transmission event consists of transmitting a Trickle ICMP message.		indicates the number of Trickle timer expiration events that occur
			before terminating the Trickle algorithm.
	If an "inconsistent" advertisement was received during that period,		Each MPL forwarder maintains a separate Trickle parameter set for the
	multicast messages that caused the inconsistency are also		proactive and reactive propagation methods. TimerExpirations MUST be
	retransmitted.		greater than 0 for proactive propagation. TimerExpirations MAY be
			set to 0 for reactive propagation, which effectively disables
			reactive propagation.
	When suppression is disabled (i.e. k is infinite), a Trickle		As specified in RFC 6206 [RFC6206], a Trickle timer has three
	transmission event consists of transmitting multicast messages that		variables: the current interval size I, a time within the current
	have been received within the Tactive time window.		interval t, and a counter c.
	This document defines receiving a "consistent" transmission as		MPL defines a fourth variable, e, which counts the number of Trickle
	receiving a Trickle ICMP message that indicates neither the receiving		timer expiration events since the Trickle timer was last reset.
	nor transmitting node has new multicast messages to offer.
	This document defines receiving an "inconsistent" transmission as		5.1.2. Proactive Propagation
	receiving a Trickle ICMP message that indicates either receiving or
	transmitting node has a new multicast message to offer. An
	"inconsistent" transmission also includes receiving a new multicast
	message.
	6.3. Trickle Multicast Option Processing		With proactive propagation, the MPL forwarder transmits buffered MPL
			multicast packets using the Trickle algorithm. Each buffered MPL
			multicast packet that is proactively being disseminated with
			proactive propagation has an associated Trickle timer. Adhering to
			Section 5 of RFC 6206 [RFC6206], this document defines the following:
	All IPv6 datagrams containing a Trickle Multicast option MUST have a		o This document defines a "consistent" transmission for proactive
	multicast IPv6 Destination address. If the IPv6 Destination is not a		propagation as receiving an MPL multicast packet that has the same
	multicast address, the multicast forwarder MUST drop the datagram.		MPL seed identifier and sequence number as a buffered MPL packet.
	A multicast forwarder MUST drop the multicast message if it cannot		o This document defines an "inconsistent" transmission for proactive
	ensure that the message has never been received before. This occurs		propagation as receiving an MPL multicast packet that has the same
	when the Sequence value is below the lower bound of the sliding		MPL seed identifier, the M flag set, and has a sequence number
	window for SeedID or when an entry already exists for the Sequence		less than the buffered MPL multicast packet's sequence number.
	value.
	If no sliding window state for SeedID exists, the multicast forwarder		o This document does not define any external "events".
	MUST allocate a new sliding window for the SeedID before accepting
	the message. If a sliding window cannot be allocated, the forwarder
	MUST drop the message.
	Upon accepting the message, the forwarder MUST enter the sequence		o This document defines both MPL multicast packets and ICMPv6 MPL
	value in the sliding window and decrement the IPv6 Hop Limit. If the		multicast packets as Trickle messages. These messages are defined
	IPv6 Hop Limit is non-zero, the forwarder MUST buffer the message for		in the sections below.
	retransmission for the duration specified by Tactive.
	6.4. Trickle ICMP Processing		o The actions outside the Trickle algorithm that the protocol takes
			involve managing sliding window state, and is specified in
			Section 5.2.
	Processing a Trickle ICMP message involves determining if either the		5.1.3. Reactive Propagation
	receiver or transmitter has new multicast messages to offer.
	The transmitter has new multicast messages to offer if any (SeedID,		With reactive propagation, the MPL forwarder transmits ICMPv6 MPL
	Sequence) pair falls within an existing sliding window for SeedID but		messages using the Trickle algorithm. A MPL forwarder maintains a
	does not have an associated entry.		single Trickle timer for reactive propagation with each MPL domain.
			When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not
			execute the Trickle algorithm for reactive propagation and reactive
			propagation is disabled. Adhering to Section 5 of RFC 6206
			[RFC6206], this document defines the following:
	The transmitter has new multicast messages to offer if the (SeedID,		o This document defines a "consistent" transmission for reactive
	Sequence) pair is great than the upper bound of an existing sliding		propagation as receiving an ICMPv6 MPL message that indicates
	window for SeedID.		neither the receiving nor transmitting node has new MPL multicast
			packets to offer.
	The receiver has new multicast messages to offer if any buffered		o This document defines an "inconsistent" transmission for reactive
	messages are not listed in the Trickle ICMP message and the Trickle		propagation as receiving an ICMPv6 MPL message that indicates
	ICMP message contains a (SeedID, Sequence) pair for a prior multicast		either the receiving or transmitting node has at least one new MPL
	message.		multicast packet to offer.
	The receiver has a new multicast message to offer if any buffered		o This document defines an "event" for reactive propagation as
	messages does not have an associated SeedID entry in the Trickle ICMP		updating any sliding window (i.e. changing the value of WindowMin,
	message.		WindowMax, or the set of buffered MPL multicast packets) in
			response to receiving an MPL multicast packet.
	If neither receiver nor transmitter has new multicast messages to		o This document defines both MPL multicast packets and ICMPv6 MPL
	offer, the multicast forwarder logs a consistent event by		multicast packets as Trickle messages. These messages are defined
	incrementing c, as described in [RFC6206].		in the sections below.
	If either receiver or transmitter has new multicast messages to		o The actions outside the Trickle algorithm that the protocol takes
	offer, the multicast forwarder logs an inconsistent event by		involve managing sliding window state, and is specified in
	resetting Trickle timer T[M], as described in [RFC6206]. All new		Section 5.2.
	messages that the receiver can offer MUST be scheduled for
	transmission at the next transmission event. Note that these		5.2. Sliding Windows
	transmissions may be suppressed if the transmission event is
	suppressed.		Every MPL forwarder MUST maintain a sliding window of sequence
			numbers for each MPL seed of recently received MPL packets. The
			sliding window performs two functions:
			1. Indicate what MPL multicast packets the MPL forwarder should
			accept.
			2. Indicate what MPL multicast packets are buffered and may be
			transmitted to neighboring MPL forwarders.
			Each sliding window logically consists of:
			1. A lower-bound sequence number, WindowMin, that represents the
			sequence number of the oldest MPL multicast packet the MPL
			forwarder is willing to receive or has buffered. An MPL
			forwarder MUST ignore any MPL multicast packet that has sequence
			value less than than WindowMin.
			2. An upper-bound sequence value, WindowMax, that represents the
			sequence number of the next MPL multicast packet that the MPL
			forwarder expects to receive. An MPL forwarder MUST accept any
			MPL multicast packet that has sequence number greater than or
			equal to WindowMax.
			3. A list of MPL multicast packets, BufferedPackets, buffered by the
			MPL forwarder. Each entry in BufferedPackets MUST have a
			sequence number in the range [WindowMin, WindowMax).
			4. A timer, HoldTimer, that indicates the minimum lifetime of the
			sliding window. The MPL forwarder MUST NOT free a sliding window
			before HoldTimer expires.
			When receiving an MPL multicast packet, if no existing sliding window
			exists for the MPL seed, the MPL forwarder MUST create a new sliding
			window before accepting the MPL multicast packet. The MPL forwarder
			may reclaim memory resources by freeing a sliding window for another
			MPL seed if its HoldTimer has expired. If, for any reason, the MPL
			forwarder cannot create a new sliding window, it MUST discard the
			packet.
			If a sliding window exists for the MPL seed, the MPL forwarder MUST
			ignore the MPL multicast packet if the packet's sequence number is
			less than WindowMin or appears in BufferedPackets. Otherwise, the
			MPL forwarder MUST accept the packet and determine whether or not to
			forward the packet and/or pass the packet to the next higher layer.
			When accepting an MPL multicast packet, the MPL forwarder MUST update
			the sliding window based on the packet's sequence number. If the
			sequence number is not less than WindowMax, the MPL forwarder MUST
			set WindowMax to 1 greater than the packet's sequence number. If
			WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MUST
			increment WindowMin such that WindowMax - WindowMin <=
			MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST free
			any entries in BufferedPackets that have a sequence number less than
			WindowMin.
			If the MPL forwarder has available memory resources, it MUST buffer
			the MPL multicast packet for proactive propagation. If not enough
			memory resources are available to buffer the packet, the MPL
			forwarder MUST increment WindowMin and free entries in
			BufferedPackets that have a sequence number less than WindowMin until
			enough memory resources are available. Incrementing WindowMin will
			ensure that the MPL forwarder does not accept previously received
			packets.
			An MPL forwarder MAY reclaim memory resources from sliding windows
			for other MPL seeds. If a sliding window for another MPL seed is
			actively disseminating messages and has more than one entry in its
			BufferedPackets, the MPL forwarder may free entries for that MPL seed
			by incrementing WindowMin as described above.
			If the MPL forwarder cannot free enough memory resources to buffer
			the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1
			greater than the packet's sequence number.
			When memory resources are available, an MPL forwarder SHOULD buffer a
			MPL multicast packet until the proactive propagation completes (i.e.
			the Trickle algorithm stops execution) and MAY buffer for longer.
			After proactive propagation completes, the MPL forwarder may advance
			WindowMin to the packet's sequence number to reclaim memory
			resources. When the MPL forwarder no longer buffers any packets, it
			MAY set WindowMin equal to WindowMax. When setting WindowMin equal
			to WindowMax, the MPL forwarder MUST initialize HoldTimer to
			WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, the
			MPL forwarder MAY free the sliding window to reclaim memory
			resources.
			5.3. Transmission of MPL Multicast Packets
			The MPL forwarder manages buffered MPL multicast packet transmissions
			using the Trickle algorithm. When adding a packet to
			BufferedPackets, the MPL forwarder MUST create a Trickle timer for
			the packet and start execution of the Trickle algorithm.
			After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL
			forwarder MUST stop executing the Trickle algorithm. When a buffered
			MPL multicast packet does not have an active Trickle timer, the MPL
			forwarder MAY free the buffered packet by advancing WindowMin to 1
			greater than the packet's sequence number.
			Each interface that supports MPL is configured with exactly one MPL
			multicast scope. The MPL multicast scope MUST be site-local or
			smaller and defaults to link-local. A scope larger than link-local
			MAY be used only when that scope corresponds exactly to the MPL
			domain.
			An MPL domain may therefore be composed of one or more MPL multicast
			scopes. For example, the MPL domain may be composed of a single MPL
			multicast scope when using a site-local scope. Alternatively, the
			MPL domain may be composed of multiple MPL multicast scopes when
			using a link-local scope.
			IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an
			original multicast packet whose source or destination address is
			outside the MPL multicast scope. IPv6-in-IPv6 encapsulation is
			necessary to support Path MTU discovery when the MPL forwarder is not
			the source of the original multicast packet. IPv6-in-IPv6
			encapsulation also allows an MPL forwarder to remove the MPL Option
			when forwarding the original multicast packet over a link that does
			not support MPL. The destination address scope for the outer IPv6
			header MUST be the MPL multicast scope.
			When an MPL domain is composed of multiple MPL multicast scopes (e.g.
			when the MPL multicast scope is link-local), an MPL forwarder MUST
			decapsulate and encapsulate the original multicast packet when
			crossing between different MPL multicast scopes. In doing so, the
			MPL forwarder MUST duplicate the MPL Option, unmodified, in the new
			outer IPv6 header.
			The IPv6 destination address of the MPL multicast packet is the all-
			MPL-forwarders multicast address (TBD). The scope of the IPv6
			destination address is set to the MPL multicast scope.
			5.4. Reception of MPL Multicast Packets
			Upon receiving an MPL multicast packet, the MPL forwarder first
			determines whether or not to accept and buffer the MPL multicast
			packet based on its MPL seed and sequence value, as specified in
			Section 5.2.
			If the MPL forwarder accepts the MPL multicast packet, the MPL
			forwarder determines whether or not to deliver the original multicast
			packet to the next higher layer. For example, if the MPL multicast
			packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the
			outer IPv6 header, which also removes MPL Option.
			5.5. Transmission of ICMPv6 MPL Messages
			The MPL forwarder generates and transmits a new ICMPv6 MPL message
			whenever Trickle requests a transmission. The MPL forwarder includes
			an encoding of each sliding window in the ICMPv6 MPL message.
			Each sliding window is encoded using an MPL Window entry, defined in
			Section 5.2. The MPL forwarder sets the MPL Window fields as
			follows:
			S If the MPL seed identifier is 0, set S to 0. If the MPL seed
			identifier is within the range [1, 65535], set S to 2. Otherwise,
			set S to 3.
			w-min Set to the lower bound of the sliding window (i.e.
			WindowMin).
			w-len Set to the length of the window (i.e. WindowMax - WindowMin).
			seed-id If S is non-zero, set to the MPL seed identifier.
			buffered-mpl-packets Set each bit that represents a sequence number
			of a packet in BufferedPackets to 1. Set all other bits to 0.
			The i'th bit in buffered-mpl-packets represents a sequence number
			of w-min + i.
			5.6. Reception of ICMPv6 MPL Messages
			An MPL forwarder processes each ICMPv6 MPL message that it receives
			to determine if it has any new MPL multicast packets to receive or
			offer.
			An MPL forwarder determines if a new MPL multicast packet has not
			been received from a neighboring node if any of the following
			conditions hold true:
			1. The ICMPv6 MPL message includes an MPL Window for an MPL seed
			that does not have a corresponding sliding window entry on the
			MPL forwarder.
			2. The neighbor has a packet in its BufferedPackets that has
			sequence value greater than or equal to WindowMax (i.e. w-min +
			w-len >= WindowMax).
			3. The neighbor has a packet in its BufferedPackets that has
			sequence number within range of the sliding window but is not
			included in BufferedPackets (i.e. the i'th bit in buffered-mpl-
			packets is set to 1, where the sequence number is w-min + i).
			When an MPL forwarder determines that it has not yet received a new
			MPL multicast packet buffered by a neighboring device, the MPL
			forwarder resets the Trickle timer associated with reactive
			propagation.
			An MPL forwarder determines if an entry in BufferedPackets has not
			been received by a neighboring MPL forwarder if any of the following
			conditions hold true:
			1. The ICMPv6 MPL message does not include an MPL Window for the
			packet's MPL seed.
			2. The packet's sequence number is greater than or equal to the
			neighbor's WindowMax value (i.e. the packet's sequence number is
			greater than or equal to w-min + w-len).
			3. The packet's sequence number is within the range of the
			neighbor's sliding window [WindowMin, WindowMax), but not
			included in the neighbor's BufferedPacket (i.e. the packet's
			sequence number is greater than or equal to w-min, strictly less
			than w-min + w-len, and the corresponding bit in buffered-mpl-
			packets is set to 0.
			When an MPL forwarder determines that it has at least one buffered
			MPL multicast packet that has not yet been received by a neighbor,
			the MPL forwarder resets the Trickle timer associated with reactive
			propagation. Additionally, for each buffered MPL multicast packet
			that should be transferred, the MPL forwarder MUST reset the Trickle
			timer and reset e to 0 for proactive propagation. If the Trickle
			timer for proactive propagation has already stopped execution, the
			MPL forwarder MUST initialize a new Trickle timer and start execution
			of the Trickle algorithm.
			6. MPL Parameters
			An MPL forwarder maintains two sets of Trickle parameters for the
			proactive and reactive methods. The Trickle parameters are listed
			below:
			PROACTIVE_IMIN The minimum Trickle timer interval, as defined in
			[RFC6206] for proactive propagation.
			PROACTIVE_IMAX The maximum Trickle timer interval, as defined in
			[RFC6206] for proactive propagation.
			PROACTIVE_K The redundancy constant, as defined in [RFC6206] for
			proactive propagation.
			PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations
			that occur before terminating the Trickle algorithm. MUST be set
			to a value greater than 0.
			REACTIVE_IMIN The minimum Trickle timer interval, as defined in
			[RFC6206] for reactive propagation.
			REACTIVE_IMAX The maximum Trickle timer interval, as defined in
			[RFC6206] for reactive propagation.
			REACTIVE_K The redundancy constant, as defined in [RFC6206] for
			reactive propagation.
			REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations
			that occur before terminating the Trickle algorithm. MAY be set
			to 0, which disables reactive propagation.
			WINDOW_HOLD_TIME The minimum lifetime for sliding window state.
	7. Acknowledgements		7. Acknowledgements
	TODO.		The authors would like to acknowledge the helpful comments of Robert
			Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy,
			Dario Tedeschi, and Peter van der Stok, which greatly improved the
			document.
	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
	--- --- --- -----		--- --- --- -----
	C 00 0 01100		C 01 0 TBD
	The first two bits indicate that the IPv6 node may skip over this		The first two bits indicate that the IPv6 node MUST discard the
	option and continue processing the header if it doesn't recognize the		packet if it doesn't recognize the option type, and the third bit
	option type, and the third bit indicates that the Option Data MUST		indicates that the Option Data MUST 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
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	skipping to change at page 18, line 30		skipping to change at page 23, line 30
	[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,		[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
	"The Trickle Algorithm", RFC 6206, March 2011.		"The Trickle Algorithm", RFC 6206, March 2011.
			[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
			Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
			Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
			Lossy Networks", RFC 6550, March 2012.
	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-06 (work in		Networks", draft-ietf-roll-terminology-06 (work in
	progress), September 2011.		progress), September 2011.
	Authors' Addresses		Authors' Addresses
	Jonathan W. Hui		Jonathan W. Hui
End of changes. 86 change blocks.
	345 lines changed or deleted		619 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/