Re: [Roll] multicast & MLD on LLN

["Pascal Thubert (pthubert)" <[e-mail]>]

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

From: Roll [mailto:[e-mail]] 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

On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
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.

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-

Cheers,

Pascal