ROLL J. Hui
Internet-Draft Cisco
Intended status: Standards Track R. Kelsey
Expires: April 22, 2013 Silicon Labs
October 19, 2012
Multicast Protocol for Low power and Lossy Networks (MPL)
draft-ietf-roll-trickle-mcast-02
Abstract
This document specifies the Multicast Protocol for Low power and
Lossy Networks (MPL) that provides IPv6 multicast forwarding in
constrained networks. MPL avoids the need to construct or maintain
any multicast forwarding topology, disseminating messages to all MPL
forwarders in an MPL domain. MPL uses the Trickle algorithm to drive
packet transmissions for both control and data-plane packets.
Specific Trickle parameter configurations allow MPL to trade between
dissemination latency and transmission efficiency.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 April 22, 2013.
Copyright Notice
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
Hui & Kelsey Expires April 22, 2013 [Page 1]
Internet-Draft MPL October 2012
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
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8
4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9
5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11
5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11
5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12
5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12
5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13
5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13
5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15
5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16
5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16
5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17
6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Hui & Kelsey Expires April 22, 2013 [Page 2]
Internet-Draft MPL October 2012
1. Introduction
Low power and Lossy Networks typically operate with strict resource
constraints in communication, computation, memory, and energy. Such
resource constraints may preclude the use of existing IPv6 multicast
topology and forwarding mechanisms. Traditional IP multicast
forwarding typically relies on topology maintenance mechanisms to
forward multicast messages to all subscribers of a multicast group.
However, maintaining such topologies in LLNs is costly and may not be
feasible given the available resources.
Memory constraints may limit devices to maintaining links/routes to
one or a few neighbors. For this reason, the Routing Protocol for
LLNs (RPL) specifies both storing and non-storing modes [RFC6550].
The latter allows RPL routers to maintain only one or a few default
routes towards a LLN Border Router (LBR) and use source routing to
forward packets away from the LBR. For the same reasons, a LLN
device may not be able to maintain a multicast forwarding topology
when operating with limited memory.
Furthermore, the dynamic properties of wireless networks can make the
cost of maintaining a multicast forwarding topology 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 and the cost of maintaining such information grows
polynomially with network density.
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.
Hui & Kelsey Expires April 22, 2013 [Page 3]
Internet-Draft MPL October 2012
2. Terminology
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].
The following terms are used throughout this document:
MPL forwarder An IPv6 router that subscribes to the MPL
multicast group and participates in disseminating
MPL multicast packets.
MPL multicast scope The multicast scope that MPL uses when forwarding
MPL multicast packets. In other words, the
multicast scope of the IPv6 Destination Address
of an MPL multicast packet.
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.
MPL seed A MPL forwarder that begins the dissemination
process for an MPL multicast packet. The MPL
seed may be different than the source of the
original multicast packet.
MPL seed identifier An identifier that uniquely identifies an MPL
forwarder within its MPL domain.
original multicast packet An IPv6 multicast packet that is
disseminated using MPL.
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.
Hui & Kelsey Expires April 22, 2013 [Page 4]
Internet-Draft MPL October 2012
3. Overview
MPL delivers IPv6 multicast packets by disseminating them to all MPL
forwarders within an MPL domain. MPL dissemination is a form of
flood. An MPL forwarder may broadcast/multicast an MPL multicast
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.
Any MPL forwarder may initiate the dissemination process by serving
as an MPL seed for an original multicast packet. The MPL seed may or
may not be the same device as the source of the original multicast
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.
Because MPL typically broadcasts/multicasts MPL packets out of the
same interface on which they were received, MPL forwarders are likely
to receive an MPL multicast packet more than once. The MPL seed tags
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.
MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include
MPL-specific information along with the original multicast packet.
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.
Upon receiving a new MPL multicast packet for forwarding, the MPL
forwarder may proactively transmit the MPL multicast packet packet a
limited number of times and then falls back into an optional reactive
mode. In maintenance mode, an MPL forwarder buffers recently
received MPL multicast packets and advertises a summary of recently
received MPL multicast packets from time to time, allowing
neighboring MPL forwarders to determine if they have any new
multicast packets to offer or receive.
Hui & Kelsey Expires April 22, 2013 [Page 5]
Internet-Draft MPL October 2012
MPL forwarders schedule their packet (control and data) transmissions
using the Trickle algorithm [RFC6206]. Trickle's adaptive
transmission interval allows MPL to quickly disseminate messages when
there are new MPL multicast packets, but reduces transmission
overhead as the dissemination process completes. Trickle's
suppression mechanism and transmission time selection allow MPL's
communication rate to scale logarithmically with density.
Hui & Kelsey Expires April 22, 2013 [Page 6]
Internet-Draft MPL October 2012
4. Message Formats
4.1. MPL Option
The MPL Option is carried in an IPv6 Hop-by-Hop Options header,
immediately following the IPv6 header. The MPL Option has the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S |M| rsv | sequence | seed-id (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type XX (to be confirmed by IANA).
Opt Data Len Length of the Option Data field in octets. MUST
be set to either 2 or 4.
S 2-bit unsigned integer. Identifies the length of
seed-id. 0 indicates that the seed-id is 0 and
not included in the MPL Option. 1 indicates that
the seed-id is a 16-bit unsigned integer. 2
indicates that the seed-id is a 64-bit unsigned
integer. 3 indicates that the seed-id is a 128-
bit unsigned integer.
M 1-bit flag. 0 indicates that the value in
sequence is not the greatest sequence number that
was received from the MPL seed.
rsv 5-bit reserved field. MUST be set to zero and
incoming MPL multicast packets in which they are
not zero MUST be dropped.
sequence 8-bit unsigned integer. Identifies relative
ordering of MPL multicast packets from the source
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
Hui & Kelsey Expires April 22, 2013 [Page 7]
Internet-Draft MPL October 2012
the Trickle Multicast option MUST discard the packet. Thus,
according to [RFC2460] the three high order bits of the Option Type
must be set to '010'. The Option Data length is variable.
The seed-id uniquely identifies an MPL seed within the MPL domain.
When seed-id is 128 bits (S=3), the MPL seed MAY use an IPv6 address
assigned to one of its interfaces that is unique within the MPL
domain. Managing MPL seed identifiers is not within scope of this
document.
The sequence field establishes a total ordering of MPL multicast
packets from the same MPL seed. The MPL seed MUST increment the
sequence field's value on each new MPL multicast packet that it
disseminates. Implementations MUST follow the Serial Number
Arithmetic as defined in [RFC1982] when incrementing a sequence value
or comparing two sequence values.
Future updates to this specification may define additional fields
following the seed-id field.
4.2. ICMPv6 MPL Message
The MPL forwarder uses ICMPv6 MPL messages to advertise information
about recently received MPL multicast packets. The ICMPv6 MPL
message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. MPL Window[1..n] .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address A link-local address assigned to the sending
interface.
Destination Address The link-local all-nodes MPL forwarders multicast
address (FF02::TBD).
Hui & Kelsey Expires April 22, 2013 [Page 8]
Internet-Draft MPL October 2012
Hop Limit 255
ICMPv6 Fields:
Type XX (to be confirmed by IANA).
Code 0
Checksum The ICMP checksum. See [RFC4443].
MPL Window[1..n] List of one or more MPL Windows (defined in
Section 4.2.1).
An MPL forwarder transmits an ICMPv6 MPL message to advertise
information about buffered MPL multicast packets. More explicitly,
the ICMPv6 MPL message encodes the sliding window state (described in
Section 5.2) that the MPL forwarder maintains for each MPL seed. The
advertisement serves to indicate to neighboring MPL forwarders
regarding newer messages that it may send or the neighboring MPL
forwarders have yet to receive.
4.2.1. MPL Window
An MPL Window encodes the sliding window state (described in
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| w-min | w-len | S | seed-id (0, 2 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. buffered-mpl-packets (0 to 8 octets) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
w-min 8-bit unsigned integer. Indicates the first
sequence number associated with the first bit in
buffered-mpl-packets.
w-len 6-bit unsigned integer. Indicates the size of
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.
Hui & Kelsey Expires April 22, 2013 [Page 9]
Internet-Draft MPL October 2012
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.
seed-id Indicates the MPL seed associated with this
sliding window.
buffered-mpl-packets Variable-length bit vector. Identifies the
sequence numbers of MPL multicast packets that
the MPL forwarder has buffered. The sequence
number is determined by w-min + i, where i is the
offset within buffered-mpl-packets.
The MPL Window does not have any octet alignment requirement.
Hui & Kelsey Expires April 22, 2013 [Page 10]
Internet-Draft MPL October 2012
5. MPL Forwarder Behavior
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.
5.1. Multicast Packet Dissemination
MPL uses the Trickle algorithm to control packet transmissions when
disseminating MPL multicast packets [RFC6206]. MPL provides two
propagation mechanisms for disseminating MPL multicast packets.
1. With proactive propagation, an MPL forwarder transmits buffered
MPL multicast packets using the Trickle algorithm. This method
is called proactive propagation since an MPL forwarder actively
transmits MPL multicast packets without discovering that a
neighboring MPL forwarder has yet to receive the message.
2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL
messages using the Trickle algorithm. An MPL forwarder only
transmits buffered MPL multicast packets upon discovering that
neighboring devices have not yet to receive the corresponding MPL
multicast packets.
When receiving a new multicast packet, an MPL forwarder first
utilizes proactive propagation to forward the MPL multicast packet.
Proactive propagation reduces dissemination latency since it does not
require discovering that neighboring devices have not yet received
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.
An MPL forwarder may optionally use reactive propagation to continue
the dissemination process with lower communication overhead. With
reactive propagation, neighboring MPL forwarders use ICMPv6 MPL
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.
Hui & Kelsey Expires April 22, 2013 [Page 11]
Internet-Draft MPL October 2012
5.1.1. Trickle Parameters and Variables
As specified in RFC 6206 [RFC6206], a Trickle timer runs for a
defined interval and has three configuration parameters: the minimum
interval size Imin, the maximum interval size Imax, and a redundancy
constant k.
MPL defines a fourth configuration parameter, TimerExpirations, which
indicates the number of Trickle timer expiration events that occur
before terminating the Trickle algorithm.
Each MPL forwarder maintains a separate Trickle parameter set for the
proactive and reactive propagation methods. TimerExpirations MUST be
greater than 0 for proactive propagation. TimerExpirations MAY be
set to 0 for reactive propagation, which effectively disables
reactive propagation.
As specified in RFC 6206 [RFC6206], a Trickle timer has three
variables: the current interval size I, a time within the current
interval t, and a counter c.
MPL defines a fourth variable, e, which counts the number of Trickle
timer expiration events since the Trickle timer was last reset.
5.1.2. Proactive Propagation
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:
o This document defines a "consistent" transmission for proactive
propagation as receiving an MPL multicast packet that has the same
MPL seed identifier and sequence number as a buffered MPL packet.
o This document defines an "inconsistent" transmission for proactive
propagation as receiving an MPL multicast packet that has the same
MPL seed identifier, the M flag set, and has a sequence number
less than the buffered MPL multicast packet's sequence number.
o This document does not define any external "events".
o This document defines both MPL multicast packets and ICMPv6 MPL
multicast packets as Trickle messages. These messages are defined
in the sections below.
Hui & Kelsey Expires April 22, 2013 [Page 12]
Internet-Draft MPL October 2012
o The actions outside the Trickle algorithm that the protocol takes
involve managing sliding window state, and is specified in
Section 5.2.
5.1.3. Reactive Propagation
With reactive propagation, the MPL forwarder transmits ICMPv6 MPL
messages using the Trickle algorithm. A MPL forwarder maintains a
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:
o This document defines a "consistent" transmission for reactive
propagation as receiving an ICMPv6 MPL message that indicates
neither the receiving nor transmitting node has new MPL multicast
packets to offer.
o This document defines an "inconsistent" transmission for reactive
propagation as receiving an ICMPv6 MPL message that indicates
either the receiving or transmitting node has at least one new MPL
multicast packet to offer.
o This document defines an "event" for reactive propagation as
updating any sliding window (i.e. changing the value of WindowMin,
WindowMax, or the set of buffered MPL multicast packets) in
response to receiving an MPL multicast packet.
o This document defines both MPL multicast packets and ICMPv6 MPL
multicast packets as Trickle messages. These messages are defined
in the sections below.
o The actions outside the Trickle algorithm that the protocol takes
involve managing sliding window state, and is specified in
Section 5.2.
5.2. Sliding Windows
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.
Hui & Kelsey Expires April 22, 2013 [Page 13]
Internet-Draft MPL October 2012
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
Hui & Kelsey Expires April 22, 2013 [Page 14]
Internet-Draft MPL October 2012
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.
Hui & Kelsey Expires April 22, 2013 [Page 15]
Internet-Draft MPL October 2012
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
Hui & Kelsey Expires April 22, 2013 [Page 16]
Internet-Draft MPL October 2012
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
Hui & Kelsey Expires April 22, 2013 [Page 17]
Internet-Draft MPL October 2012
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.
Hui & Kelsey Expires April 22, 2013 [Page 18]
Internet-Draft MPL October 2012
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.
Hui & Kelsey Expires April 22, 2013 [Page 19]
Internet-Draft MPL October 2012
7. Acknowledgements
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.
Hui & Kelsey Expires April 22, 2013 [Page 20]
Internet-Draft MPL October 2012
8. IANA Considerations
The Trickle Multicast option requires an IPv6 Option Number.
HEX act chg rest
--- --- --- -----
C 01 0 TBD
The first two bits indicate that the IPv6 node MUST discard the
packet if it doesn't recognize the option type, and the third bit
indicates that the Option Data MUST NOT change en-route.
Hui & Kelsey Expires April 22, 2013 [Page 21]
Internet-Draft MPL October 2012
9. Security Considerations
TODO.
Hui & Kelsey Expires April 22, 2013 [Page 22]
Internet-Draft MPL October 2012
10. References
10.1. Normative References
[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.
[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
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-06 (work in
progress), September 2011.
Hui & Kelsey Expires April 22, 2013 [Page 23]
Internet-Draft MPL October 2012
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
Silicon Labs
25 Thomson Place
Boston, Massachusetts 02210
USA
Phone: +617 951 1225
Email: richard.kelsey@silabs.com
Hui & Kelsey Expires April 22, 2013 [Page 24]