Subject: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Thu, 25 Oct 2012 06:55:33 +0000

Dear all,

draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing list and during WG meeting a number of time; the document is stable and 
has been implemented. Thus this starts a 2-week WG Last call ending on Nov 9 at noon ET. Please send your comments to the authors 
and copy the mailing list and the co-chairs.

Thanks.

JP.

---

From: peter van der Stok <[email-masked]>
Date: Thu, 25 Oct 2012 13:27:56 +0200

Dear Richard and Jonathan,

We are quite happy with this new draft but I should like to comment on 
two aspects which need improvement according to me. (next to my earlier 
remark about implementation of MC domain)

Multicast message encapsulation:
For our applications it is important that the MC control message fits 
into one link-layer frame. Simulations show that with fragmented 6LoWPAN 
packets the MPL behavior becomes quite unpredictable unless specific 
measures are taken in all transmitting nodes. Knowing that the payload 
of a MPL packet is around 60 bytes, and may be further reduced by 
security overhead (see draft-keoh-tls-multicast-security-00), every byte 
of payload counts. Therefore I suggest that the original MC message can 
be distributed inside the LLN network without the encapsulation by the 
MPL message. I can very well imagine that encapsulation is needed to 
send the message to the seed (from inside the LLN network or from 
outside), but once it reaches the seed within the LLN, transmission of 
the original MC message inside the LLN is recommended without the 
encapsulation but including the MPL option in the header of the original 
MC packet. The MPL-2 draft suggests that when the MPL domain is composed 
of multiple MPL link-local scopes (even when contained within the LLN) 
each MPL forwarder encapsulates and decapsulates. I suggest that the 
wording is changed such that this is not necessary as long as the MC 
packet travels within the LLN.

Forwarder behavior:
The draft describes that sending of ICMP messages can be suppressed by 
setting REACTIVE_TIMER_EXPIRATIONS to zero. I like to suggest the same 
possibility for PROACTIVE_TIMER_EXPIRATIONS. The motivation is the 
following: In rather dense networks, it would be beneficial to reduce 
the number of forwarders. However, the non-forwarders may not receive 
some messages in spite of the density. By allowing these nodes to use 
the sending of ICMP messages, the forwarding nodes can be informed of 
the missing message to trigger a retransmission

Peter van der Stok

JP Vasseur (jvasseur) schreef op 2012-10-25 08:55:
> Dear all,
>
> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing
> list and during WG meeting a number of time; the document is stable
> and
> has been implemented. Thus this starts a 2-week WG Last call ending
> on Nov 9 at noon ET. Please send your comments to the authors
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 26 Oct 2012 08:24:21 +0200

Dear JP, Michael, All,

I have only just flipped through this latest version of this I-D; a more detailed review will follow.

However, I already have one major comment.....

I wonder why a WGLC is issued for a protocol specification, wherein the "Security Considerations" section is entirely empty? (Well, fair be fair, it does explicitly say "TODO"...)

Knowing the IESG and the SEC ADs, they tend to (rightfully) not be lenient on such matters, and I think that it behoves the WG to be very attentive to security also.

In my opinion, it is not prudent for the WG to consider a protocol specification as "mature enough to take forward" until such time that also the security implications and considerations are carefully addressed.

As it is, they are not - and, for that reason alone I'd like to go on record with strong opposition to progressing this document.

Note, I have not reviewed the document in detail - that will come. However lack of _any_ security considerations whatsoever is, alone, a showstopper. 

Best,

Thomas

ps: FWIW, the 2119-boilerplate used doesn't capture the errata.

Sent from my iPad

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 26 Oct 2012 20:33:09 -0700

Hi,

below is my review.

My major comment is that the IANA section needs to be fixed and a
security considerations section needs to be written. Without that
section, the document should not go forward in my opinion.
Then I have multiple questions for clarity (see the detailed review).
Also, as a standards track document, I think it should give some
guidelines about which values for the parameters to use, as well as
some indications about the state requirements of the protocol.
Are there any implementations and/or deployments of the protocol out there?

Best regards
Ulrich

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)

UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks"

    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)

UH> I did not find LBR in the terminology section.

   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.

UH> I am not sure I understand the last sentence. What does it mean?
How is that achieved?

UH> By the way, since this is a standards track document, is there any
deployment experience? Implementations?

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].

UH> "NOT RECOMMENDED" is missing as per the errata of 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.

UH> An RFC reference to "scope" could be helpful.

   MPL domain          A connected set of MPL forwarders that define the
                       extent of the MPL dissemination process.

UH> What does connected mean? What if a the network is split in two parts?

                       As a
                       form of flood, all MPL forwarders in an MPL
                       domain will receive MPL multicast packets.

UH> Probably not *all* forwards will receive it (assuming packets can
be lost)

                       The
                       MPL domain MUST be composed of at least one MPL
                       multicast scope and MAY be composed of multiple
                       MPL multicast scopes.

UH> Why is that? Anyway, I am unsure whether one can say that a
routing domain "consists" of multicast scopes. If I understand that
correctly, the multicast scope just determines how far a message
propagates.

   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.

UH> How is the uniqueness guaranteed? What kind of identifier is that?
An IP address? I see it's defined later, but maybe it would be helpful
to mention it here, too.

   original multicast packet  An IPv6 multicast packet that is
                       disseminated using MPL.

UH> That terminology sounds a bit confusing; I would have imagined
that the above description matches the following term "MPL multicast
packet". What's the difference between an "original multicast packet"
and an "MPL multicast packet"? I assume the one is the inner packet
when using IPv6-in-IPv6 tunnels, the other one is the outer packet
with the options header.

   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,

UH> Above it was said there may be multiple scopes in a domain. Here
you talk about "the" scope. Which one?

                       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,

UH> LLN or MPL domain? How can a router determine if an incoming
packet is inside our outside the MPL domain?

   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.

UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section with a
title not related to "IPv6 tunneling". I suggest to make an own
section.

   Because MPL state requirements grows with the number of
   active MPL seeds,

UH> In section 1 it was written that the state is constant. Here you
say it grows. Which one is it?

    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,

UH> Why typically? Doesn't that depend on the scenario that this
specification is used in?

   MPL forwarders are likely
   to receive an MPL multicast packet more than once.

UH> I am not sure if that is the only reason. Isn't the reason that it
may be received from multiple neighbors?

   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.

UH> I think the whole introduction is not very easy to read. There is
a lot of text about some details (IPv6-in-IPv6 tunnels, multiple
interfaces), but the essential mechanism is hard to identify from the
text. Also, there is nothing mentioned about what kind of state is
required to be stored on each router (which information sets etc).

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,

UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options header"

UH> More importantly,  RFC6564 specifies:

      New options for the existing Hop-by-Hop Header SHOULD NOT be
      created or specified unless no alternative solution is feasible.
      Any proposal to create a new option for the existing Hop-by-Hop
      Header MUST include a detailed explanation of why the hop-by-hop
      behavior is absolutely essential in the document proposing the new
      option with hop-by-hop behavior.

UH> I did not see such an explanation.

   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)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UH> It could help to mention that this is formatted in network byte order

   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.

UH> 2 or 4 depending on what?

   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.

UH> missing ")"

   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.

UH> There is not a lot of RFC2119 language in the above. Or is that
defined later? Is this above section more like an introduction?

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.

UH> This sentence starts confusing, as it looks very similar to the
first paragraph in this section. "a Trickle timer has three variables"
How about using the same language as in RFC6206:
"In addition to these three parameters, Trickle maintains three
   variables:
   o  I, the current interval size,
   o  t, a time within the current interval, and
   o  c, a counter."

   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.

UH> I think that somewhere the state requirements need to be
mentioned. How does that affect scalability of the algorithm etc.
Density is mentioned somewhere in the beginning, but not explained how
that would affect scalability and state requirements.

    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.

UH> I don't see the term Trickle message used anywhere else.

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.

UH> I don't see the term "Trickle message" anywhere else  (other than
in 5.1.2)

   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.

UH> Why is this written in a section called "Transmission of MPL
Multicast Packets"? Seems more like an initial configuration. Same for
the below IPv6.. I would have expected that in a dedicated section
about IPv6 tunneling
UH> How would the router now that the 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.

UH> I am not quite sure how the scope works in this specification. Is
that used somewhere when deciding whether to forward packets?

   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.

UH> The source address is a unicast address, right? How can that be
outside a multicast scope? How would you know?

    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.

UH> That should be specified more clearly. What does "remove" mean? I
suppose you mean decapsulate the inner IPv6 packet.

    The destination address scope for the outer IPv6
   header MUST be the MPL multicast scope.

UH> Again, which one? I thought there can be several scopes?

   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.

UH> When would you know when to cross a multicast scope? Do you mean
routing domain?

    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).

UH> The TBD will be hard to spot by the RFC editor / IANA. I suggest
to define the variable and use the value only in the IANA section.

    The scope of the IPv6
   destination address is set to the MPL multicast scope.

UH> which one?

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.

UH> How would it determine that?

    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.

UH> For example? What exactly needs to be done?

5.5.  Transmission of ICMPv6 MPL Messages

   The MPL forwarder generates and transmits a new ICMPv6 MPL message
   whenever Trickle requests a transmission.

UH> So for each data packet there would be a new ICMPv6 message?
Wouldn't that create a lot of overhead?

UH> To which address is the ICMP message sent? On which interface?

   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,

 UH> Which timer? I thought there is one timer per packet in the
proactive mode?

   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.

UH> I don't see any recommendations for these values. That is
typically requested in the IESG evaluation for standards track
documents (either default values and/or guideslines on the values).

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.

UH> That does not look like a valid IANA section. RFC 5226 give some
good guidelines.

Hui & Kelsey             Expires April 22, 2013                [Page 21]
Internet-Draft                     MPL                      October 2012

9.  Security Considerations

   TODO.

UH> This document needs a security considerations section. Refer to RFC 3552.

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.

UH> That document is never actually cited. Also, it has not been
updated in over a year.

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: [email-masked]

   Richard Kelsey
   Silicon Labs
   25 Thomson Place
   Boston, Massachusetts  02210
   USA

   Phone: +617 951 1225
   Email: [email-masked]

Hui & Kelsey             Expires April 22, 2013                [Page 24]

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 29 Oct 2012 09:38:12 -0700

Hi Don,

thanks, that's good to know. To your knowledge, are there any public
results about delivery ratio of packets, overhead, delay, state
requirements and/or a comparison to other flooding mechanisms such as
classic flooding?

Best
Ulrich

On Oct 26, 2012, at 20:50, Don Sturek <[email-masked]> wrote:

> Hi Ulrich,
>
> For ZigBee IP, we are using the trickle multicast draft.  We have 7
> platforms interoperating using the draft.
>
> Don
>
>
> On 10/26/12 8:33 PM, "Ulrich Herberg" <[email-masked]> wrote:
>
>> Hi,
>>
>> below is my review.
>>

---

From: Don Sturek <[email-masked]>
Date: Mon, 29 Oct 2012 11:06:51 -0700

Hi Ulrich,

We did quite a lot of testing using 30 nodes (our messaging profile) and
using specific multicast parameter settings as follows:
1.   iMin = 128ms, iMax=128ms, k=infinity, TAct=3, TDwell=16s
2.   iMin = 128ms, iMax=128ms, k=infinity, TAct=1, TDwell=3s
3.   iMin = 512ms, iMax=512ms, k=infinity, TAct=1, TDwell=3s
4.   iMin = 512ms, iMax=512ms, k=infinity, TAct=3, TDwell=3s

First thing to note is we always set k=infinity since we could not
identify anything in our multicast streams to suppress (basically, we just
wanted every device to see each multicast message at least once and
hopefully only once)

Next, the main purpose of our multicast traffic was for resource discovery
using mDNS so there is no driving requirement around low latency
applications (eg, other applications would be more sensitive to the iMin
and iMax settings than we were).

We ended up using parameter settings (4) above.

I think something like trickle multicast is a MUST for mesh routing
solutions like ROLL.  The issue you get into using multicast is how the
messages are propagated.  If every device that sees a multicast simply
forwards, then you end up with broadcast storms where nothing is heard.
The randomization of re-broadcast is essential.

I think our results are being incorporated into the ROLL deployment
experience draft 
(http://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deployment/).

By the way, someone noted the lack of a Security Considerations section.
We force Link Layer security on so did not plan any additional security
than that.....

Don

On 10/29/12 9:38 AM, "Ulrich Herberg" <[email-masked]> wrote:

>>> ROLL                                                              J.
>>>Hui
>>> Internet-Draft

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 29 Oct 2012 11:18:07 -0700

Hi Don,

thanks for this information. See below

> wanted every device to see each multicast message at least once and

My understanding is that if you set k to infinity, you would probably see
each message many more times than just once.
RFC6206 states:
  "In general, this approach [setting k to infinity] is highly dangerous
and it is NOT RECOMMENDED. Disabling suppression means that every node will
always send on every interval; this can lead to congestion in dense
networks. This approach is especially dangerous if many nodes reset their
intervals at the same time. In general, it is much more desirable to set k
to a high value (e.g., 5 or 10) than infinity. Typical values for k are
1-5: these achieve a good balance between redundancy and low
cost[Levis08<http://tools.ietf.org/html/rfc6206#ref-Levis08>
]."

I assume that with k = infinity, the performance would be much worse
than classic flooding and you would have a lot of bandwidth
consumption in the LLN. Did you observe that?

> and iMax settings than we were).

I think this is important to point out in the draft. I agree that there are
certain applications where delay is less important than others. For mDNS,
whether it is delay-critical may also depend on the application that uses
mDNS to discover the service.

> The randomization of re-broadcast is essential.

But since you don't use suppression, the overhead is likely more
substantial than in classic flooding. Using a decent jitter value in
classic flooding, or more advanced flooding mechanisms such as MPR flooding
would likely lead to much lower channel use. Have you compared to MPR
flooding or classic flooding with jitter ?

> We force Link Layer security on so did not plan any additional security

That may work in some deployments, but will not suffice for the draft to
only rely on link-layer security, and to not even have a security
considerations section.

Best
Ulrich

---

From: Don Sturek <[email-masked]>
Date: Mon, 29 Oct 2012 11:24:46 -0700

Hi Ulrich,

A few notesŠ..
1)  We did the testing sometime ago and you are exactly correct on setting
k=infinity.  I believe that each node resends the message for each interval
(so you do get many more transmissions that I said below)
2)  We did not try just using jitter so don't have any results to
share/compare

What would have been interesting to test is using suppression but measuring
to ensure that suppression never denied access to multicast messages missed
by downstream devices (where the upstream device already saw the message and
was using suppression).   I think we may have taken the more "brute force"
approach in ensuring all devices got their message.  There is not much
penalty to that in a network of 30 but with many more, that approach would
not work.

Don

From:  Ulrich Herberg <[email-masked]>
Date:  Monday, October 29, 2012 11:18 AM
To:  Don Sturek <[email-masked]>
Cc:  "JP Vasseur (jvasseur)" <[email-masked]>,
"<[email-masked]>" <[email-masked]>, "[email-masked]
WG" <[email-masked]>, Michael Richardson <[email-masked]>
Subject:  Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

Hi Don,

My understanding is that if you set k to infinity, you would probably see
each message many more times than just once.
RFC6206 states:
  "In general, this approach [setting k to infinity] is highly dangerous and
it is NOT RECOMMENDED. Disabling suppression means that every node will
always send on every interval; this can lead to congestion in dense
networks.  This approach is especially dangerous if many nodes reset their
intervals at the same time.  In general, it is much more desirable to set k
to a high value (e.g., 5 or 10) than infinity.  Typical values for k are
1-5: these achieve a good balance between redundancy and low cost[Levis08
<http://tools.ietf.org/html/rfc6206#ref-Levis08> ]."

I assume that with k = infinity, the performance would be much worse than
classic flooding and you would have a lot of bandwidth consumption in the
LLN. Did you observe that?

> The randomization of re-broadcast is essential.

But since you don't use suppression, the overhead is likely more substantial
than in classic flooding. Using a decent jitter value in classic flooding,
or more advanced flooding mechanisms such as MPR flooding would likely lead
to much lower channel use. Have you compared to MPR flooding or classic
flooding with jitter ?

Best
Ulrich

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 29 Oct 2012 12:07:18 -0700

I think others have covered most of what I wanted to say, but there is 
one point I want to highlight.

The issue relates to the following text:

    A scope larger than link-local MAY be used only when that scope 
corresponds exactly to the MPL
    domain.

There's no explanation on how a node would determine what scope 
corresponds to a MPL domain. How would it do that without being given 
some additional information from the edge-router/s. I think what is 
needed, here, is some multicast routing information from the edge-router/s.

One solution might be for a RPL root to advertise RIOs (in its DIOs), 
that give the multicast prefixes reachable outside of the RPL/MPL 
Domain. For example, a RPL root could advertise FF05::/16 to effectively 
indicate that site-local scope is wider than just the RPL Domain and 
that a router should encapsulate site-local multicasts, whether 
forwarding or sourcing them. Other multicasts could be sent 
un-encapsulated, however an implementation may still choose to 
encapsulate all non-link-local multicasts.

Of course, all this would be greatly simplified if IPv6-in-IPv6 
encapsulation of non-link-local multicasts was made mandatory within a 
"non-storing RPL domain" (MPL domain). Then there would be only one way 
to forward multicasts within such a domain and there would be no need 
for additional routing information.

- Dario

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Tue, 30 Oct 2012 16:56:22 +0000

Ulrich,

Thanks for your detailed review.  Responses below.

On Oct 26, 2012, at 8:33 PM, Ulrich Herberg <[email-masked]> wrote:

[snip]

> UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and

Ack.

> UH> I did not find LBR in the terminology section.

Ack.

> UH> I am not sure I understand the last sentence. What does it mean?

This is borrowing the wording out of RFC 6206.  I can reference the RFC here (again) and reference the academic papers (NSDI'04, CACM'08) that present this result.

> deployment experience? Implementations?

As Don mentioned, there are a number of implementations on different platforms.  Peter van der Stok has also presented his implementation to the WG.  Cisco also has an implementation.

The use of Trickle to disseminate messages has been implemented, deployed, and published numerous times in the past.  These implementations include small message, medium message, and large message dissemination.  Including NSDI'04, SenSys'04, SenSys'06, CACM'08, SenSys'08, and TOSN'10.

> UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119

Ack.

> UH> An RFC reference to "scope" could be helpful.

I assume you mean RFC 4007.

> UH> What does connected mean? What if a the network is split in two parts?

"MPL forwarding domain    A MPL forwarding domain is a collection of forwarders that operate MPL and are under the control of a single administration."

> UH> Probably not *all* forwards will receive it (assuming packets can

How about:

"As a form of flood, MPL strives to deliver MPL multicast packets to all MPL forwarders."

> correctly, the multicast scope just determines how far a message

I think it would help to define "MPL multicast scope zone" in addition to "MPL multicast scope".  Then the correct wording for the text above is "MAY be composed of multiple MPL multicast scope zones."  Does that help?

> An IP address? I see it's defined later, but maybe it would be helpful

Ack.

> when using IPv6-in-IPv6 tunnels, the other one is the outer packet

The one subtlety here is that the original multicast packet does not necessarily have to be encapsulated using IPv6-in-IPv6.  How about:

"An IPv6 multicast packet that is transported by MPL.  In other words, it is an MPL multicast packet with the MPL Hop-by-Hop Option removed.  When the MPL multicast packet uses IPv6-in-IPv6 encapsulation to include the MPL Hop-by-Hop Option, the original multicast packet is the inner packet."

> you talk about "the" scope. Which one?

Having "MPL multicast scope zones", as addressed above, should help here too.

> packet is inside our outside the MPL domain?

MPL forwarding domain.  Generally, the packet is outside when received on an interface not used for MPL forwarding or when the original multicast packet does not contain an MPL Option.

> title not related to "IPv6 tunneling". I suggest to make an own

Ack.

> say it grows. Which one is it?

Section 1 states: "MPL requires only small, constant state for each MPL device that initiates disseminations."  That is consistent with the wording above.  I can make the text the same in both locations.

> may be received from multiple neighbors?

How about:

"As a form of flood, MPL forwarders are likely to receive an MPL multicast packet more than once."

> required to be stored on each router (which information sets etc).

A lot of this is combined with text in Section 5.  Would you prefer to see that pulled up here?

> UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options header"

I was following the text of RFC 2675.

> UH> I did not see such an explanation.

How about:

"The MPL option is needed because the IPv6 header does not provide unique identification of IPv6 packets from the source."

>   immediately following the IPv6 header.  The MPL Option has the

Depending on the size of seed-id.

>                       size of seed-id is indicated by the S field.

[snip]

>   Section 5.2 that the MPL forwarder maintains for an MPL seed.

Ack.

[snip]

> defined later? Is this above section more like an introduction?

This is more like an intro.  Would you prefer to see this moved to the overview section?

>   o  t, a time within the current interval, and

Ack.

> that would affect scalability and state requirements.

Ack.

> UH> I don't see the term Trickle message used anywhere else.

Used in RFC 6206.

> UH> I don't see the term "Trickle message" anywhere else  (other than

Used in RFC 6206.

[snip]

> the below IPv6.. I would have expected that in a dedicated section

Ack.

> UH> How would the router now that the scope corresponds exactly to the

The intent is to have this configured, not dynamically determined.  Will make this clearer in the next revision.

> that used somewhere when deciding whether to forward packets?

Should be "multiple MPL multicast scope zones".

> outside a multicast scope? How would you know?

Source address should not be included in the text above.  Instead, there should be text requiring a border router to encapsulate using IPv6-in-IPv6 when forwarding into an MPL forwarding domain.

> suppose you mean decapsulate the inner IPv6 packet.

How about:

"Decapsulating the original multicast packet also serves to remove the MPL Option contained in the outer header."

> UH> Again, which one? I thought there can be several scopes?

Again, only a single scope, but multiple scope zones.

> UH> When would you know when to cross a multicast scope? Do you mean

Crossing between different MPL multicast scope zones.  An MPL forwarder should know by virtue of attempting to forward the packet beyond the current zone.  When the MPL multicast scope is link-local, then the MPL forwarder must decapsulate and encapsulate when forwarding each packet.

> to define the variable and use the value only in the IANA section.

Ack.

>   destination address is set to the MPL multicast scope.

Only one MPL multicast scope - multiple MPL multicast scope zones.

> UH> How would it determine that?

That text doesn't seem quite right.  How about:

"If the MPL forwarder accepts the MPL multicast packet, the MPL forwarder processes the original multicast packet."

> UH> For example? What exactly needs to be done?

This sentence is no longer required with the proposed text above.

> Wouldn't that create a lot of overhead?

Nope.  The ICMPv6 message is a list of sliding windows.

> UH> To which address is the ICMP message sent? On which interface?

Destination Address is specified in Section 4.2.  Sent on all interfaces that are used for forwarding MPL multicast packets.

>   an encoding of each sliding window in the ICMPv6 MPL message.

[snip]

> UH> Which timer? I thought there is one timer per packet in the

How about:

"the Trickle timer(s) associated with the buffered packet(s) and reset e associated with the buffered packet(s) to 0 for proactive propagation".

>   of the Trickle algorithm.

[snip]

> documents (either default values and/or guideslines on the values).

Ack.

[snip]

>   The Trickle Multicast option requires an IPv6 Option Number.

Ack.

--
Jonathan Hui

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 30 Oct 2012 13:46:13 -0700

Jonathan,

thanks for addressing my comments. See below:

On Tue, Oct 30, 2012 at 9:56 AM, Jonathan Hui (johui) <[email-masked]>wrote:

> [...]
> This is borrowing the wording out of RFC 6206.  I can reference the RFC
> here (again) and reference the academic papers (NSDI'04, CACM'08) that
> present this result.
>

Yes, I think that would  be a good idea.

> As Don mentioned, there are a number of implementations on different
> platforms.  Peter van der Stok has also presented his implementation to the
> WG.  Cisco also has an implementation.
>
> The use of Trickle to disseminate messages has been implemented, deployed,
> and published numerous times in the past.  These implementations include
> small message, medium message, and large message dissemination.  Including
> NSDI'04, SenSys'04, SenSys'06, CACM'08, SenSys'08, and TOSN'10.
>

Thanks!

 [...]

> I assume you mean RFC 4007.

Yes, could be helpful to cite.

> [...]

> I think it would help to define "MPL multicast scope zone" in addition to
> "MPL multicast scope".  Then the correct wording for the text above is "MAY
> be composed of multiple MPL multicast scope zones."  Does that help?
>

I need to read the new revision to see if that is clearer.

> [...]
> MPL forwarding domain.  Generally, the packet is outside when received on
> an interface not used for MPL forwarding or when the original multicast
> packet does not contain an MPL Option.
>

I think that should be spelled out in the draft.

 [...]

> A lot of this is combined with text in Section 5.  Would you prefer to see

Yes, I think so. It could help to split the introduction section in
subsections that illustrate the core mechanism (1.1), the required state
(1.2), the message exchange (1.3) etc. in different subsections each. This
would allow for easily understanding the core mechanism, before diving into
IPv6 encapsulation etc.

> I was following the text of RFC 2675.

Okay, you may be right. According to RFC2460, it is an IPv6 Extension
header called "Hop-by-hop options header" ;-)

> "The MPL option is needed because the IPv6 header does not provide unique
> identification of IPv6 packets from the source."
>

Could you reuse a similar header, e.g., from RFC6621? It seems that
multiple RFCs intend to define a header for identifying IPv6 packets with a
sequence number.
In addition, I think it could be helpful to argue why you cannot use a
Destination Options header; the keyword from RFC6564 is "detailed
explanation", so one sentence may not be enough.

> > [...]

Maybe you can add that in this sentence to make that clearer.

> [...]

Yes.

> [...]

A citation would help.

> [...]

Okay, I guess I am not quite clear yet on how much bandwidth the ICMPv6
messages would consume (how often they are sent etc) in relation to the
data traffic.

> Destination Address is specified in Section 4.2.  Sent on all interfaces
> that are used for forwarding MPL multicast packets.
>

Could be helpful to point to that section here.
 [...]

> "the Trickle timer(s) associated with the buffered packet(s) and reset e
> associated with the buffered packet(s) to 0 for proactive propagation".
>

Okay. That brings me to a point you mentioned above, the constant state
requirement. It seems there is a timer for each packet in proactive mode.
Wouldn't that mean the state requirement for these timers is O(n) for n
packets? Or are the timers bound by the size of the sliding window?

What is your plan regarding the security considerations section? Will that
be added in the next revision?

Best
Ulrich