Upstream Contiki goes multicast... More or less...

After a fair bit of patience, my 6LoWPAN multicast implementation for Contiki has now been merged upstream. This is super cool, and I must admit I'm well chuffed!

This means that now you can have a Contiki node join an IPv6 multicast group. You can then send a datagram to this multicast address from somewhere in the Internet, and the Contiki node will receive it. Right? Well, I'm afraid the answer is "No, not quite".

You see, as I documented right from the start in Contiki's Pull Request #364, we currently only support multicast for traffic originating inside a 6LoWPAN and with a destination in the same 6LoWPAN. Multicast traffic cannot traverse the network's boundary in either direction.

Within the 6LoWPAN, we currently have two options:

1. Multicast group management with RPL in MOP3. Forwarding with SMRF (pronounced "Smurf"!) [1, 2]
2. All multicast functionality with Trickle Multicast [3] (there is no group management as such). This is currently based on an old version of the MPL Internet Draft, which is why I'm intentionally using the name "Trickle Multicast" and not MPL.

Thus, things inside the 6LoWPAN are pretty much sorted out. In order to be able to extend this functionality across the 6LoWPAN's boundary, we need a couple more components:

• Some sort of mechanism to notify the outside world about group subscriptions of nodes inside the LoWPAN. This, in my humble opinion, can and should be done with MLD. As a Contiki contributor demonstrated recently, an embedded implementation of MLD won't be trouble in terms of code size and complexity.
• The network's border router should be able to forward multicast traffic from the outside world to the 6LoWPAN and vice-versa. For reasons that I'm explaining in a separate post, this is not as straightforward as it may initially sound, and it's certainly more complex than simply forwarding an IPv6 datagram.
• The network's border router should be able to conduct multicast routing on its internet-facing interfaces (in other words, outside the 6LoWPAN). The discussion of what protocols and mechanisms could be used for that is a wider topic on IPv6 multicasting and therefore out of scope of this post.

I'll try to visualise this. Everything inside the dashed 6LoWPAN box is what we already have (points 1 and 2 above). We need more functionality on the BR in order to achieve the right-hand side of the figure, plus functionality to cross the 6LoWPANs boundary.

R: A router somewhere in the Internet. BR: Our border router

Naturally, all of the above is under the assumption of an IPv6-enabled Internet. But let's not discuss this right now.

Thus, milestone achieved, but not quite there yet. Next up (in no particular order):

• MPL implementation. This will update and eventually obsolete the current "Trickle Multicast" implementation.
• Better forwarding in RPL MOP3 instances (I'm planning to publish this, so I'm not telling you how!)
• MLD support

Stay tuned

References

[1] G. Oikonomou, I. Phillips, T. Tryfonas, "IPv6 Multicast Forwarding in RPL-Based Wireless Sensor Networks", Wireless Personal Communications, Springer US, 73(3), pp. 1089-1116, 2013 [ doi ]

[2] G. Oikonomou, I. Phillips, "Stateless Multicast Forwarding with RPL in 6LoWPAN Sensor Networks", in Proc. 2012 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops), Lugano, Switzerland, pp. 272-277, 2012 [ doi ]

[3] J. Hui, R. Kelsey, "Multicast Forwarding Using Trickle", IETF Internet Draft (version 01) [ url ]