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

[Ulrich Herberg <[e-mail]>]

Hi Don,

thanks for this information. See below

On Mon, Oct 29, 2012 at 11:06 AM, Don Sturek <[e-mail]> wrote:

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

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?




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


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.



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


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 ?



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


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



> On 10/29/12 9:38 AM, "Ulrich Herberg" <[e-mail]> wrote:
>
> >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 <[e-mail]> 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" <[e-mail]> wrote:
> >>
> >>> 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: [phone]
> >>>  Email: [e-mail]
> >>>
> >>>
> >>>  Richard Kelsey
> >>>  Silicon Labs
> >>>  25 Thomson Place
> >>>  Boston, Massachusetts  02210
> >>>  USA
> >>>
> >>>  Phone: [phone]
> >>>  Email: [e-mail]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Hui & Kelsey             Expires April 22, 2013                [Page
> >>>24]
> >>> _______________________________________________
> >>> Roll mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/roll
> >>
> >>
>
>
>