Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add Support for IPv6 Multicast #364
This Pull Request adds multicast support, with an example and some regression tests. It introduces a NETSTACK-style multicast engine driver, with two such engines already implemented.
In a nutshell, this pull does the following:
I must start with the big gotcha. Currently, we only support multicast traffic originating and destined within the same 6LoWPAN. In other words, traffic can not cross 6LoWPAN boundaries in either direction. In order to support this, we'd need the following additions to border routers or other gateway devices:
These are in the ToDo list
I am intentionally calling the Trickle Multicast engine TM and not MPL, since it was implemented when the draft was still at version 1 (i.e. before the name MPL came along). As I've discussed in the mailing list in the past, my personal take on things is that to implement MPL one would benefit by starting from scratch, since the differences are quite significant. During discussions it was agreed that it's better to have support for the old draft soon and implement the new version in due course, rather than have nothing while working on implementing MPL.
SMRF was originally written when we had support for neither the RPL HBHO nor multiple instances. I'm currently working on SMRFv2, which will take advantage of both techniques.
As some of you already know, this implementation has been around for circa 2 years now. I recently modified it to use the new neighbour tables and uip-ds6-route-style forwarding tables.
Looking forward to feedback
With suppression enabled (K=1) and Tactive < consistent timer < Tdwell for all the members of the domain. Should the addition of a new node cause the forwarding of all the messages in the window? or should the fact that Tactive was reached cause the multicast messages to be suppressed?
The behavior I am currently observing is such that the multicast messages get re-broadcast as long as the consistency timer < Tdwell. In my interpretation this is incorrect. Could you confirm?
Melvin, that's a very very nice catch. This is a combination of what happens in three different locations of the code (see various inline comments).
You made me read the draft again: Even though it 'suppresses', it is unclear to me whether Tactive is part of the mechanism referred to as 'suppression'. My understanding/interpretation of the draft is that 'suppression' only refers to K and that a forwarder may only transmit a datagram with age < Tactive regardless of whether K is infinity or not. See my comment under L623.
So here is what happens in your situation:
Upon reception of the new node's Trickle ICMP message, the older node will flag an inconsistency on the expired datagram. This is because its Seed ID will not be listed in the received ICMP (which was empty). This happens under the checks for "we have new" (the block starting in L1256).
In section 6.4. Trickle ICMP Processing, the draft says:
"The receiver has a new multicast message to offer if any buffered messages does not have an associated SeedID entry in the Trickle ICMP message."
In the next round of transmissions, because of what happens near L623, the expired message gets sent. Bingo
TM works but it has a couple of non-critical bugs (those discussed above).
It would be great if we could start looking at the integration into the core (uIP hooks, the code that puts RPL in MOP3 and sends multicast DAO advertisements) while I'm fixing those. Now that we have cooja PCAPs back it won't take long at all.
I'm re-opening this: