Subject: [Roll] multicast & MLD on LLN

From: "Turner, Randy" <[email-masked]>
Date: Fri, 10 Oct 2014 19:03:57 +0000

I know there's a section on multicast in RFC 6550, which essentially states that the equivalent of a multicast "join" would be a DAO packet specifying multicast, rather than unicast addresses. It says that this method is not to be relied on in a non-storing network - however, I'm assuming we can still use this if we implement just a "lightweight storing mode", keeping track of only multicast addresses.  In this case a multicast "leave" would be when the DAO entry "times out"  - does this behavior obviate the need for MLD operation on this "quasi" storing mode LLN ?

Thanks!
Randy

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 11 Oct 2014 06:22:09 +0000

Hello Randy...

Great point!

I think we need a draft, even if informational, to produce a clear explanation of how that could work, extending the work I started on unicast with 6775reqs.

The way I see it, MLD would make sense between a host that is not even a RPL leaf and the 6LR. Arguably, we could probably extend NS ARO to get a similar outcome to reduce the code footprint. Then the 6LR would turn that into DAO.

This is collapsed, as you point out, for RPL leaves and routers. We already extended DAO to get a similar outcome as a recursive MLD proxy along a tree. The goal was to avoid MLD there; but then an I-D reviewed by multicast specialists would validate that we missed no important point.

I dug a bit and found some IPR that we need to sort out. Cisco has some that mostly covers the BBR that turns the DAOs into MLD again, and for that much we can RAND if work starts.

Finally I'm looking at BIER see how their ideas could apply to LLNs...

Cheers,

Pascal

Le 10 oct. 2014 à 21:22, Turner, Randy <[email-masked]<mailto:[email-masked]>> a écrit :

I know there’s a section on multicast in RFC 6550, which essentially states that the equivalent of a multicast “join” would be a DAO packet specifying multicast, rather than unicast addresses. It says that this method is not to be relied on in a non-storing network – however, I’m assuming we can still use this if we implement just a “lightweight storing mode”, keeping track of only multicast addresses.  In this case a multicast “leave” would be when the DAO entry “times out”  - does this behavior obviate the need for MLD operation on this “quasi” storing mode LLN ?

Thanks!
Randy

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 11 Oct 2014 08:39:41 +0200

Right, MLD is a host-router protocol.
Routers among them speak a routing protocol, so they wouldn’t exchange MLD.
(A RPL “leaf” is a router.)

> Finally I'm looking at BIER see how their ideas could apply to LLNs…

Yep.  
We (TZI) have done (specified, implemented, analyzed) an efficient BIER-like multicast forwarding protocol for non-storing mode a while ago.
Need to write that up in an I-D and submit it somewhere.
BIER or ROLL or both?

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Oct 2014 14:54:25 +0000

Hello again Randy:

We had a talk with Greg and Ice, and it seems to me that the BIER approach could be perfectly applicable to a RPL LLN, mostly for small multicast packets or on a PHY that is not too sensitive to the encapsulation such as 15.4G.

Basically for us, the method would leverage the backbone router to assign a bitmap that represents the listeners in a DODAG. If we encode the BIER bitmap in an IPv6 address, that would mean at most about 100 listeners per DODAG. And then we can build multiple RPL instances if we need more than that.

Do you have a use case that would require multicast? If so, would you care to tell us a bit more, or, better, contribute some text to the use case document?

If you are in Hawaii, BIER will be on the first PM slot on Monday, right before DETNET.
Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: samedi 11 octobre 2014 08:22
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

Hello Randy...

Great point!

Cheers,

Pascal

Thanks!
Randy

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 15 Oct 2014 15:01:51 +0000

I will be in Hawaii

Thanks Pascal!!

Randy

Sent from my iPhone

On Oct 15, 2014, at 4:55 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello again Randy:

Pascal

Hello Randy...

Great point!

Cheers,

Pascal

Le 10 oct. 2014 ? 21:22, Turner, Randy <[email-masked]<mailto:[email-masked]>> a ?crit :
I know there's a section on multicast in RFC 6550, which essentially states that the equivalent of a multicast "join" would be a DAO packet specifying multicast, rather than unicast addresses. It says that this method is not to be relied on in a non-storing network - however, I'm assuming we can still use this if we implement just a "lightweight storing mode", keeping track of only multicast addresses.  In this case a multicast "leave" would be when the DAO entry "times out"  - does this behavior obviate the need for MLD operation on this "quasi" storing mode LLN ?

Thanks!
Randy

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 15 Oct 2014 11:51:33 -0400

Pascal, Carsten, et al.

On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann <[email-masked]> wrote:

> We (TZI) have done (specified, implemented, analyzed) an efficient
> BIER-like multicast forwarding protocol for non-storing mode a while ago.
>

I admit to some confusion here.  Is (topology-free) MPL no longer the
default
multicast forwarding protocol for LLN?

> I thought the goal was to shut down (or is it re-charter) ROLL?  If we're
considering
new approaches to multicast forwarding, that may be reason enough to
re-charter
ROLL.

-K-

> [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Oct 2014 16:00:42 +0000

Or form a new group ☺

What about Routing Over Complete Kaos?

More seriously, it’s probably a good idea to goto through the BoF sequence again to analyze what’s left to be done.
I can certainly see an analog of what the 6lo is to 6LoWPAN, but for ROLL.

Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: mercredi 15 octobre 2014 17:52
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

Pascal, Carsten, et al.

On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:
Right, MLD is a host-router protocol.
Routers among them speak a routing protocol, so they wouldn’t exchange MLD.
(A RPL “leaf” is a router.)

Yep.

I admit to some confusion here.  Is (topology-free) MPL no longer the default
multicast forwarding protocol for LLN?

Need to write that up in an I-D and submit it somewhere.
BIER or ROLL or both?
I thought the goal was to shut down (or is it re-charter) ROLL?  If we're considering
new approaches to multicast forwarding, that may be reason enough to re-charter
ROLL.

-K-

Grüße, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 15 Oct 2014 12:24:35 -0400

On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Or form a new group J
For me the first question is whether multicast in the LLN would be RPL-
dependent, or have RPL-like features (e.g. dependence on a DODAG).
That could argue for doing the work in ROLL or a follow on group
(ROLLMAN?)

At least some of the 6lo proposals (MS/TP comes to mind) are not mesh
networks, but still constrained from a host and bandwidth perspective.

I like the topology-independence of MPL, but I think work still needs to be
done to see how far it is from optimal (in terms of energy and bandwidth
usage) under different operating conditions and parameter settings.

-K-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Oct 2014 16:38:47 +0000

Hello Kerry:

Or Roll Multicast Operations ( : ROLLMOps? : )

Basically, BIER needs a preexisting tree structure and RPL is designed to build and maintain one. They need a root node and we have one.
On paper it is a perfect match. Now the question is whether there is enough need for that work, and then we’ll find a place to make it happen.

To start with, would you have a specific use case of multicast in LLNs where MPL is less applicable than the classical tree-based forwarding?

With that, we could connect into the BIER effort.

Strong points:
- very limited state in the nodes, could even be used for unicast, independent on the number of groups and the size of the network
- bit aggregation easy to advertise in existing DAOs, low cost there too
- transparent support for v4 and v6 (since it is an overlay)

Weak points:
- extra encapsulation (since it is an overlay)
- new routing and forwarding operation to implement in the nodes (bitwise)
- limited number of nodes per DODAG (roughly 100).

Cheers,

Pascal

Sent: mercredi 15 octobre 2014 18:25

On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Or form a new group ☺

-K-

Cheers,

Pascal

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 15 Oct 2014 16:39:45 +0000

There has been a lot of experience and learning around 6lowpans and mesh/LLN scenarios, and it's spread around a bunch of documents across multiple working groups, not all of these groups being active anymore. A portion of these documents contain multiple solutions for multiple overlapping problem spaces, with no "roadmap" to show to navigate through the LLN solution domain.

It might be nice to have a document that "rolls up" the best ideas from these documents into a guide for developers. For instance, "cherry picking" mechanisms across RFCs 6775, 6550, etc to produce a definitive way to deliver a solution that can scale to thousands of nodes, or gracefully backdown its capabilities to address smaller home environments

There are great ideas in these documents, I would just like to see this information coalesced, or at a minimum a roadmap to know how to navigate through it all

Thanks!
Randy

On Oct 15, 2014, at 6:00 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Or form a new group :)

More seriously, it's probably a good idea to goto through the BoF sequence again to analyze what's left to be done.
I can certainly see an analog of what the 6lo is to 6LoWPAN, but for ROLL.

Cheers,

Pascal

Pascal, Carsten, et al.

On Sat, Oct 11, 2014 at 2:39 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:
Right, MLD is a host-router protocol.
Routers among them speak a routing protocol, so they wouldn't exchange MLD.
(A RPL "leaf" is a router.)

Yep.

-K-

Gr??e, Carsten

---

From: Don Sturek <[email-masked]>
Date: Wed, 15 Oct 2014 09:58:07 -0700

Hi Pascal,

Let me try to provide a use case.

The network is a Neighborhood Area Network.  The application can be
something like street lights or a smart metering AMI (really any collection
of devices that are networked centrally with a non-trivial number of devices
in the network)

Here are some details:
1)   Around 5000 devices in the network total.  There can be as many as 15
hops from the DODAG to the furthest leaf node in the network.
2)  One border router that supports ROLL RPL.  All devices in the network
are ROLL RPL aware (some as routers, some end devices).  What would be
really nice is if we could have non-RPL aware end devices also in the
network but I think that is another topic :-)
3)  We support all of the mandatory multicast groups (eg all routers) in our
networked devices
4)  From an application point of view, we want to use special
application-defined multicast groups for things like:
       A.    Control a geographic collection of street lights (like all the
ones in an area where there is to be a festival this evening)
       B.    Control a geographically  diverse collection of devices that
are not the entire population (for example, I want a message sent to all of
my pre-pay customers which are mainly focused in some neighborhoods, less in
others)
5)  I don't want to incur the MPL overhead of all multicast traffic flooding
all 5000 devices/forwarded up to 15 hops in my network when I send these
special multicast group messages.

What would be great in the above scenario is if the multicast traffic only
traversed the portions of the network where members of the multicast group
exist (eg, don't forward down portions of the tree where there are no
multicast members).  MPL as a flooding mechanism fails this goal (which is
fine with relatively few devices but not so when talking about 5000
devices/24 hops!

Is the above good enough to start a discussion on how to solve the problem?

Don

From:  "Pascal Thubert (pthubert)" <[email-masked]>
Reply-To:  Routing Over Low power and Lossy networks <[email-masked]>
Date:  Wednesday, October 15, 2014 9:38 AM
To:  Routing Over Low power and Lossy networks <[email-masked]>
Cc:  "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Subject:  Re: [Roll] multicast & MLD on LLN

Hello Kerry:

Basically, BIER needs a preexisting tree structure and RPL is designed to
build and maintain one. They need a root node and we have one.
On paper it is a perfect match. Now the question is whether there is enough
need for that work, and then we¹ll find a place to make it happen.
 
To start with, would you have a specific use case of multicast in LLNs where
MPL is less applicable than the classical tree-based forwarding?

Strong points:
- very limited state in the nodes, could even be used for unicast,
independent on the number of groups and the size of the network
- bit aggregation easy to advertise in existing DAOs, low cost there too
- transparent support for v4 and v6 (since it is an overlay)
 
Weak points:
 
Cheers,
 
Pascal

On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert)
<[email-masked]> wrote:

Or form a new group J

More seriously, it¹s probably a good idea to goto through the BoF sequence
again to analyze what¹s left to be done.
I can certainly see an analog of what the 6lo is to 6LoWPAN, but for ROLL.

(ROLLMAN?)

-K-

> Pascal
_______________________________________________ Roll mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Oct 2014 17:11:11 +0000

Thanks a bunch, Don!

Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Don Sturek
Sent: mercredi 15 octobre 2014 18:58
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

Hi Pascal,

The network is a Neighborhood Area Network.  The application can be something like street lights or a smart metering AMI (really any collection of devices that are networked centrally with a non-trivial number of devices in the network)

Here are some details:
1)   Around 5000 devices in the network total.  There can be as many as 15 hops from the DODAG to the furthest leaf node in the network.
2)  One border router that supports ROLL RPL.  All devices in the network are ROLL RPL aware (some as routers, some end devices).  What would be really nice is if we could have non-RPL aware end devices also in the network but I think that is another topic :-)
3)  We support all of the mandatory multicast groups (eg all routers) in our networked devices
4)  From an application point of view, we want to use special application-defined multicast groups for things like:
       A.    Control a geographic collection of street lights (like all the ones in an area where there is to be a festival this evening)
       B.    Control a geographically  diverse collection of devices that are not the entire population (for example, I want a message sent to all of my pre-pay customers which are mainly focused in some neighborhoods, less in others)
5)  I don't want to incur the MPL overhead of all multicast traffic flooding all 5000 devices/forwarded up to 15 hops in my network when I send these special multicast group messages.

What would be great in the above scenario is if the multicast traffic only traversed the portions of the network where members of the multicast group exist (eg, don't forward down portions of the tree where there are no multicast members).  MPL as a flooding mechanism fails this goal (which is fine with relatively few devices but not so when talking about 5000 devices/24 hops!

Don

From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Reply-To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 15, 2014 9:38 AM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Cc: "IJsbrand Wijnands (iwijnand)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] multicast & MLD on LLN

Hello Kerry:

Basically, BIER needs a preexisting tree structure and RPL is designed to build and maintain one. They need a root node and we have one.
On paper it is a perfect match. Now the question is whether there is enough need for that work, and then we'll find a place to make it happen.

Strong points:

Weak points:

Cheers,

Pascal

-K-

Cheers,

Pascal

_______________________________________________ Roll mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/roll

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Oct 2014 22:08:53 +0200

Hi Don,

this sounds exactly like a use case our multicasting approach can solve.

Two questions:

1) Are you using storing or non-storing mode for RPL?

2) For the kinds of groups below, was is the likely distribution of group sizes?

Grüße, Carsten

---

From: Don Sturek <[email-masked]>
Date: Wed, 15 Oct 2014 13:23:56 -0700

Hi Carsten,

On your questions posed below:
1)  We are using non-storing
2)  Distribution of group sizes.   This is a tough question.  I think some
groups may be nearly the size of the entire network (say I want to send a
message to all of my smart meters but don't need the relays or AP's to get
the message).   Some may be regionally focused and therefore small (eg, I
have an outage and I want the smart meters in one location to report on
the quality of the electric service they are seeing).   Some may be
geographically focused (like the example for the street light application
wanting to manage street lights around a festival).  I think the right
answer here is we want applications to opt in/opt out of application
multicast groups and we want the network forwarding to be smart enough to
not flood the entire network if that is not needed.  I know that is not
the answer you are particularly looking for but I think that is the right
answer.  By the way, if I have an application multicast group that is
nearly the entire population of the network, it would be really great if
the network operator knew this and reduced those types of multicast
transmissions.   The biggest savings would be where we really only want to
hit devices in a certain georgraphy and now we don't need every device in
the network to see that traffic.....

If we do this right, then we will arm the application developers with the
ability to create their own groups (with some knowledge/understanding from
the network operator) and the ability for the forwarding of the multicast
traffic to avoid saturating the network with broadcast traffic that is not
needed for that application multicast group.

Don

On 10/15/14 1:08 PM, "Carsten Bormann" <[email-masked]> wrote:

>>        A.    Control a geographic collection of street lights (like all
>>the ones in an area where there is to be a festival this evening)
>>        B.    Control a geographically  diverse collection of devices
>>that are not the entire population (for example, I want a message sent
>>to all of my pre-pay customers which are mainly focused in some
>>neighborhoods, less in others)
>

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 15 Oct 2014 20:27:14 +0000

Hi Pascal,

This multicast use-case is similar to the street light group use-case,
except aimed at the AMI grid network:

There is of course a need to multicast firmware updates to devices in the
smart grid. In that example (and in other AMR use-cases) all devices in
the network subscribe to a common multicast address ‹ it¹s really a
broadcast, if all devices need to be updated at the same time, with the
same firmware.

Then there is a multicast group scenario where, say, only 500 of 5000
nodes need to be updated (possibly associated with a geographic region of
the grid)

THere¹s also a region-oriented multicast group address that could be used
to send control/management information to a particular set of smart meters
in the field. For instance if there is problem with a substation
controlling a particular geographic region of homes, the grid head-end
systems may elect to send a particular command to this region of home
meters to adjust their operation in light of upstream grid issues.

There may be some mapping of multicast address to geographic region so
that meters can use their GPS location to automatically derive what
multicast address to subscribe to.

Hope this helps
Randy

---

From: Don Sturek <[email-masked]>
Date: Wed, 15 Oct 2014 13:33:16 -0700

.... By the way, I worked on an  application using IPv4 multicast that
worked nicely as defined below.  My previous company did the original
IP-enabling for NASDAQ.   There were tiers of service that mapped to IPv4
multicast groups.
Of course with the topological nature of IPv4, this was a much simpler
problem (plus not having an LLN in the middle).

The key feature was the ability to opt-in/opt-out of the multicast groups
and the ability for the network to route traffic appropriately depending
on membership of the multicast group.  Hopefully we can come up with
something similar.....

Don

On 10/15/14 1:23 PM, "Don Sturek" <[email-masked]> wrote:

>>2) For the kinds of groups below, was is the likely distribution of
>>group 
>>sizes?
>>
>>Grüße, Carsten
>>

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 15 Oct 2014 16:38:40 -0400

On Wed, Oct 15, 2014 at 4:27 PM, Turner, Randy <[email-masked]>
wrote:

> Surely you'd want to do OTA updates in a secure fashion?  Does this
highlight
a need for secure multicast?

> Is the GPS position manually configured in the meter?  If so, perhaps
manual
configuration of multicast group address is just marginally more expensive.

It could also be the case that multicast group addresses are named objects.
For example, one could assign DNS names to groups and resolve this to a
AAAA record (just as with unicast addresses) or use DNS-SD to find a
multicast service binding.

-K-

> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized
> representative of an intended recipient, you are prohibited from using,
> copying or distributing the information in this e-mail or its attachments.
> If you have received this e-mail in error, please notify the sender
> immediately by return e-mail and delete all copies of this message and any
> attachments. Thank you.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Oct 2014 23:16:53 +0200

On 15 Oct 2014, at 22:38, Kerry Lynn <[email-masked]> wrote:

> Surely you'd want to do OTA updates in a secure fashion?  Does this highlight

What is the security objective here?
If it is integrity/authenticity, this is best done with object security on the OTA image, which also can provide confidentiality for the bits in the OTA image.
(I don’t think there is a need [or even a way] to keep the fact that an OTA update is occurring confidential.)

Grüße, Carsten

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 15 Oct 2014 21:48:40 +0000

I¹m not saying confidentiality isn¹t an issue with updates, but I think
it¹s more important that the integrity of the image be correct, and that
the image is appropriate for the target ‹- both of these concerns can be
handled at the application layer ‹ multicast is just the transport.

Randy

On 10/15/14, 5:16 PM, "Carsten Bormann" <[email-masked]> wrote:

>If it is integrity/authenticity, this is best done with object security
>on the OTA image, which also can provide confidentiality for the bits in
>the OTA image.
>(I don¹t think there is a need [or even a way] to keep the fact that an
>OTA update is occurring confidential.)
>
>Grüße, Carsten
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Oct 2014 17:56:59 -0400

>> Right, MLD is a host-router protocol.  Routers among them speak a
    >> routing protocol, so they wouldn’t exchange MLD.  (A RPL “leaf” is a
    >> router.)
    >>
    >> Yep.  We (TZI) have done (specified, implemented, analyzed) an
    >> efficient BIER-like multicast forwarding protocol for non-storing mode
    >> a while ago.
    >>

    > default multicast forwarding protocol for LLN?

I don't know anything about BIER really... MPL is still the default at this point.
(proceedural delays getting trickle-mcast out, not-with-standing)
My take on the conversation is that BIER has some kind of helper node that
unicasts everything out as appropriate.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Oct 2014 18:00:18 -0400

> Let me try to provide a use case.

Thank you.

    > something like street lights or a smart metering AMI (really any
    > collection of devices that are networked centrally with a non-trivial
    > number of devices in the network)

...

    > What would be great in the above scenario is if the multicast traffic
    > only traversed the portions of the network where members of the
    > multicast group exist (eg, don't forward down portions of the tree
    > where there are no multicast members).  MPL as a flooding mechanism
    > fails this goal (which is fine with relatively few devices but not so
    > when talking about 5000 devices/24 hops!

    > Is the above good enough to start a discussion on how to solve the

could you write this in the form of a requirements draft?
Even if it just has the above three paragraphs... :-)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Oct 2014 18:02:27 -0400

Turner, Randy <[email-masked]> wrote:
    > It might be nice to have a document that "rolls up" the best ideas from
    > these documents into a guide for developers. For instance, "cherry
    > picking" mechanisms across RFCs 6775, 6550, etc to produce a definitive
    > way to deliver a solution that can scale to thousands of nodes, or
    > gracefully backdown its capabilities to address smaller home
    > environments

This is called an applicability statement.   Getting this out the door is the
last thing this WG has to done, and why we are still alive.

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 15 Oct 2014 18:05:54 -0400

On Wed, Oct 15, 2014 at 5:16 PM, Carsten Bormann <[email-masked]> wrote:

> If it is integrity/authenticity, this is best done with object security on
> the OTA image, which also can provide confidentiality for the bits in the
> OTA image.
>

Yes, and also authorization (although perhaps this is implied by
authentication).

-K-

---

From: peter van der Stok <[email-masked]>
Date: Thu, 16 Oct 2014 09:17:10 +0200

Hi Don,

> 5) I don't want to incur the MPL overhead of all multicast traffic
> flooding all 5000 devices/forwarded up to 15 hops in my network when I
> send these special multicast group messages.

I think this is possible with current MPL by managing which nodes are 
MPL forwarders.
First requirement is to select a multicast address per group of 
destination nodes.
Second, enable the interfaces for a selection of nodes which are 
supposed to forward and which are supposed to receive only messages with 
this particular MC address.

Today, this must be done by hand.
Automating it is an option.

Peter

Don Sturek schreef op 2014-10-15 18:58:
> 1) Around 5000 devices in the network total. There can be as many as
> 15 hops from the DODAG to the furthest leaf node in the network.
> 2) One border router that supports ROLL RPL. All devices in the
> network are ROLL RPL aware (some as routers, some end devices). What
> would be really nice is if we could have non-RPL aware end devices
> also in the network but I think that is another topic :-)
>  B. Control a geographically diverse collection of devices that are
> not the entire population (for example, I want a message sent to all
> of my pre-pay customers which are mainly focused in some
> 5) I don't want to incur the MPL overhead of all multicast traffic
> flooding all 5000 devices/forwarded up to 15 hops in my network when I
> send these special multicast group messages.
> 
> Basically, BIER needs a preexisting tree structure and RPL is designed
> to build and maintain one. They need a root node and we have one.
> 
> On paper it is a perfect match. Now the question is whether there is
> enough need for that work, and then we'll find a place to make it
> happen.
> 
> To start with, would you have a specific use case of multicast in LLNs
> where MPL is less applicable than the classical tree-based forwarding?
> 
> FROM: Roll [mailto:[email-masked]] ON BEHALF OF Kerry Lynn
> SENT: mercredi 15 octobre 2014 18:25
> TO: Routing Over Low power and Lossy networks
> CC: IJsbrand Wijnands (iwijnand)
> SUBJECT: Re: [Roll] multicast & MLD on LLN
> 
> More seriously, it's probably a good idea to goto through the BoF
> sequence again to analyze what's left to be done.
> 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll [1]
> 
> Links:
> ------
> [1] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Don Sturek <[email-masked]>
Date: Thu, 16 Oct 2014 05:39:00 -0700

Hi Peter,

I really don't see how in MPL we could configure routers which may not be
multicast group members to forward unless they are somehow provided
information that the forwarding path has multicast group members that need
the message.

Even if we somehow hand configured them to forward certain multicast group
packet streams, that would fail if the device changes rank.  In addition,
we could not create new multicast groups and have the device understand
whether or not forwarding was needed.

One thing I saw when using application multicast groups in IPv4:   Once
the application developers realized how the multicast groups worked, they
created more of them as time went on.   For the AMI/smart city
applications we are working on, I really think most of the application
multicast group definition will occur after the system is deployed and
developers realize (hopefully!) how efficient it is to use targeted
application multicast groups.

Don

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Oct 2014 12:54:24 +0000

Hello Michael

I think that saying that MPL is the default is quite exaggerated. 

RPL has a classical multicast built in, which is a simple extension to storing mode ( https://tools.ietf.org/html/rfc6550#section-12). 
The trouble is that this hardly fits with non-storing.

BIER (draft-wijnands-bier-architecture-00.txt) seems an appropriate approach for non-storing devices, considering that it makes the same tradeoff of bytes in packets vs. state in the nodes. BIER could be used for both unicast and multicast, unicast being seen as an extreme form of multicast. Each address, or group, or (source, group),  the node registers unicast to the root in pretty much the same way as we do today in non-storing. There is a bit offset associated to each node. When a packet comes in, the root looks up the list of interested nodes, sets a bit map at all the relevant bit offsets, and encapsulates the packet adding that bitmap, e.g. in an address or an option header. Each node maintains a bitmap per child down the RPL preferred tree, which has the bits set for the end nodes that are reachable via this child. These bitmaps could be built and re-advertised over classical storing-mode DAO messages whereby a node just advertises the AND of all its bitmaps to its preferred parent.

It would seem to be the right approach for Don's problem if it were not for the sheer size of " Around 5000 devices in the network total ".

BIER needs one bit per device in the routing bitmap. We cannot have a 5K bitmap in every packet. If we steal one bit in the ff1 (RFC 7371) to indicate a BIER routing, we could fit up to 112 hosts in a multicast IPv6 address.  To reach 5K, we'll need to subnet. For instance, by using 8 bits as a prefix, we could carve out 256 sets of 104 devices. For 5000 nodes, this means roughly 50 groups, and could multiply the state in every node by 50, though the numbers are probably a lot less if the sets are formed based on geography. But then, the root may have to send multiple copies of a packet, as many as there are groups with at least one listener for that packet.

Don: are these nodes all in a same DODAG? Or are they partitioned in smaller groups through multiple roots, or multiple instances?

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: mercredi 15 octobre 2014 23:57
> (proceedural delays getting trickle-mcast out, not-with-standing) My take on
> the conversation is that BIER has some kind of helper node that unicasts
> everything out as appropriate.
> 
> --

---

From: Don Sturek <[email-masked]>
Date: Thu, 16 Oct 2014 06:09:06 -0700

Hi Pascal,

Currently, all 5000 devices are members of the same DODAG.

Don

On 10/16/14 5:54 AM, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

>RPL has a classical multicast built in, which is a simple extension to
>storing mode ( https://tools.ietf.org/html/rfc6550#section-12).
>BIER (draft-wijnands-bier-architecture-00.txt) seems an appropriate
>approach for non-storing devices, considering that it makes the same
>tradeoff of bytes in packets vs. state in the nodes. BIER could be used
>for both unicast and multicast, unicast being seen as an extreme form of
>multicast. Each address, or group, or (source, group),  the node
>registers unicast to the root in pretty much the same way as we do today
>in non-storing. There is a bit offset associated to each node. When a
>packet comes in, the root looks up the list of interested nodes, sets a
>bit map at all the relevant bit offsets, and encapsulates the packet
>adding that bitmap, e.g. in an address or an option header. Each node
>maintains a bitmap per child down the RPL preferred tree, which has the
>bits set for the end nodes that are reachable via this child. These
>bitmaps could be built and re-advertised over classical storing-mode DAO
>messages whereby a node just advertises the AND of all its bitmaps to its
>preferred parent.
>
>It would seem to be the right approach for Don's problem if it were not
>for the sheer size of " Around 5000 devices in the network total ".
>
>BIER needs one bit per device in the routing bitmap. We cannot have a 5K
>bitmap in every packet. If we steal one bit in the ff1 (RFC 7371) to
>indicate a BIER routing, we could fit up to 112 hosts in a multicast IPv6
>address.  To reach 5K, we'll need to subnet. For instance, by using 8
>bits as a prefix, we could carve out 256 sets of 104 devices. For 5000
>nodes, this means roughly 50 groups, and could multiply the state in
>every node by 50, though the numbers are probably a lot less if the sets
>are formed based on geography. But then, the root may have to send
>multiple copies of a packet, as many as there are groups with at least
>one listener for that packet.
>
>Don: are these nodes all in a same DODAG? Or are they partitioned in
>smaller groups through multiple roots, or multiple instances?
>
>Pascal
>
>
>>     >> routing protocol, so they wouldn¹t exchange MLD.  (A RPL ³leaf²
>>is a
>>     >> router.)
>>     >>
>>     >> > Finally I'm looking at BIER see how their ideas could apply to
>>LLNsŠ
>>     >>
>> I don't know anything about BIER really... MPL is still the default at
>>this
>> point.