implement MLDv1 #574
The Travis tests all pass now. My patch had a slight problem with datatype definitions (it used uN_t, which doesn't seem to exist everywhere), those are now fixed. The one test that fails passed in earlier runs, now it seems to fail because of a faulty buildenv setup.
Strongly disagree with merging this as-is. More when I'm not typing on a phone :)
As per my previous post, here are my concerns:
To sum it up, as I said already, MLD is a great feature to have - we definitely want it! However, this pull uses MLD to advertise a multicast functionality which we don't have yet. I think this is a little too early / we are not ready for MLD. The way forward would be to wait for #364 and then rebase this again, taking into account multicast forwarding tables, RPL MOP3 and also making sure we report (with MLD) to the outside world (which is what we should be primarily using MLD for, IMHO).
Somewhat less importantly:
As ever, many thanks for your efforts, but I'm afraid at this stage I'd rather see this put on hold.
It's been a month now since my last message, and #364 has been merged, making MLD even more useful, if not required for a network to function properly once nodes want to receive multicast packet. Is there still interest in MLD support? I understand that the code needs some changes now, but I'd rather not spend time on those changes and have the pull request rejected for other reasons afterwards.
I've meant to reply to your post but I need to find an opportunity when I'll have enough time to reply to it properly.
In short: Yes, we still want MLD. Contiki multicast support will be (at least IMHO) incomplete without MLD.
However, I want to properly articulate my understanding of what it is we need MLD for and how I'd visualise it playing nicely and complementing everything else.
Thus, as I say, I'll definitely champion MLD as a feature. However, the decision whether it will get merged or not is not one which will be taken by myself exclusively. Additionally, the decision whether it will get merged or rejected does not depend only on what the feature is, but it also depends on how well the feature is implemented. To put this in different words, I can't promise that the pull will get accepted or rejected before I've seen the pull :)
Nevertheless, thanks for your efforts to contribute to Contiki, and this is irrespective of whether you decide to throw more time into this.
For the rest of the discussion, let's consider this very simple topology, with nodes A, B, C and the LBR forming a 6LoWPAN mesh.
It's slightly more complicated than that, I'm afraid:
Thus, we currently have two options for multicast inside the 6LoWPAN:
My interpretation of the specs is that RPL MOP3 and MLD serve the same purpose: Notify about the presence of multicast listeners. In a MOP3 deployment, MLD won't add any value that I can think of.
Thus, in summary:
You are of course right
Now that we have MOP3 / TM in place, you say that MLD is even more useful if not required. You seem to be suggesting that MLD requires MOP3 or TM/MPL in the case of a multi-hop network (at the link layer). But assuming the presence of either TM/MPL or MOP3, I can't see what additional purpose MLD would serve.
Please, can you provide a use-case / scenario whereby MLD would be necessary or at least useful? By use-case I mean one that includes a description of the sender's location, multicast datagram destination, number and location of subscribers, protocols in place, DODAG depth, and the reasons why things would fail without MLD.
I've had some discussions with people active in the ROLL WG recently, and I might be able to think of a single corner case where MLD could be useful in the 6LoWPAN side. However, this corner case is not currently supported by Contiki (and would take a lot of effort to do so) and ideally I'd prefer to see your own use-case, rather than lead the discussion towards something you may or may not have thought of originally.
If I were to implement MLD support for Contiki, here's the premise / assumptions I'd work with (think the above topology):
Multicast datagrams originating within the 6LoWPAN and with a destination scope higher than realm-local are forwarded over the
Thanks for your reply. I've taken another look at RFC 6550, and it seems that in my first go I read it wrong. I agree with your summary that MOP3 and MLDv1 serve the same purpose inside a 6LoWPAN network, rendering MLDv1 inside such a network effectively useless if MOP3 is in place. I also agree with most of your premises for MLD on a LBR, but as you already said, whether and how a LBR would forward multicasts or propagate reports is another discussion. In our application, we've made it easy for ourselves by running mrd6 on the LBR and MLD withing the lowpan, so multicast routing just works. Without MLD, we'll just have to get the multicast listener information from RPL into the non-15.4 system by some means, but I'm not sure right now how that would look like. It would almost certainly require an extension to mrd6 or a partial reimplementation, but I might be wrong.
For TM/MPL, the situation as I see it is similar, but more awkward. To my understanding, a forwarded message in MPL will almost always be an IP-in-IP packet, necessitating decapsulation at each receiver. Is this correct? If so, border routers that want to process multicasts correctly will have to do that somehow. But again, MLDv1 does seem to be of little value in an MPL network, when a LBR never prunes its seed set.
Either way, yes, MLDv1 carries little extra values if the LBR implements MOP3/MPL and does not intend to act as a multicast router. I have no idea how often that would happen, for us multicast routing is the default.
We want to create a scalable, stable system for home and building automation based on 802.15.4 radios, running 6lowpan and RPL, and on top of that our multicast-based dissemination and control protocol. We haven't yet had deployments large enough to require actual multicast forwarding within a radio domain (since the version of Contiki we're using does not do that, and we don't want to reimplement that wheel), but we do have deployments with multiple lowpan border routers that are also multicast routers. To keep the entire thing simple, these LBRs run a single instance of mrd6, thus our need for MLDv1 in the lowpan. In MOP3 or MPL, that would no longer be an option because mrd6 just doesn't support those protocols (and I doubt it ever will).
From what I understand, it seems that a LBR that also has to support multicast correctly must either be contain full multicast routing component with specific support for MOP3/MPL, or a smart bridge that snoops MOP3/MPL messages and synthesizes MLD reports at appropriate times. The former seems unlikely to happen anytime soon, while the latter is something that Contiki can implement as you have mentioned.
For our case, neither would help a lot, simply because we're moving to Linux to run the LBR and leave Contiki out of that part of the network for a number of reasons. While MOP3 and MPL do provide methods to limit and direct multicast traffic in radio networks, they don't provide as much interoperability with the rest of the world as one would wish for. In our case, we've just added MLD with ridiculously long query intervals (on the order of one query per 12 hours) to keep redundant traffic low. That way, a border router that properly implements MOP3 or MPL will discard multicasts it needn't forward, but at any point in time we can be reasonably sure that in a given site, all multicast addresses of interest to lowpan nodes are also forwarded to the LBR in question (and thus the lowpan nodes, via the LBR) through traditional mechanisms.
I guess this pull request has been superseded by other technologies after all. Consider it void from my side and close it if you want to.