mqtt-sn, multicast and riot

Hi,

as probably some of you are aware, I'm working in my spare time on a mqtt-sn client for RIOT. The mqtt-sn specification [1] doesn't make any assumptions about the network stack, which is good and bad at the same time.

The "problem" is that MQTT-SN has "broadcast messages" such as the SEARCHGW message for example and also defines for some message types a "broadcast radius". While the latter is probably easy to "fix" using the hop limit field in IPv6, I'm not entirely sure how to tackle the broadcast issue.

The first thing which comes to mind is "simply" to use multicast, but the question is which scope? Something like "ff0n::1" (all nodes) seems a bit aggressive. Also RIOT doesn't seem to have a MLD implementation. Maybe it would be better to create a designated multicast group for MQTT-SN?

I'm wondering if somebody was stumbling upon a similar issue? There seems to be a proposal within the MQTT-SN community [2] which is probably worthwhile to consider? Thanks in advance!

Best, Michael

[1] http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf [2] https://github.com/mqtt/mqtt.github.io/wiki/MQTT-SN-Multicast-Addresses

Hi Michael,

Hi,

as probably some of you are aware, I'm working in my spare time on a mqtt-sn client for RIOT. The mqtt-sn specification [1] doesn't make any assumptions about the network stack, which is good and bad at the same time.

The "problem" is that MQTT-SN has "broadcast messages" such as the SEARCHGW message for example and also defines for some message types a "broadcast radius". While the latter is probably easy to "fix" using the hop limit field in IPv6, I'm not entirely sure how to tackle the broadcast issue.

The first thing which comes to mind is "simply" to use multicast, but the question is which scope? Something like "ff0n::1" (all nodes) seems a bit aggressive. Also RIOT doesn't seem to have a MLD implementation. Maybe it would be better to create a designated multicast group for MQTT-SN?

don't know if I can help you with this information. OpenThread which use some kind of forked MLE protocol [0]. MLE itself use a lot of multicast messages, quoting:

"This requires some form of multi-hop multicast forwarding; these messages are sent infrequently, so forwarding with simple flooding is sufficient."

Is this the same what you are looking for? If yes then MLE has similar issues like you.

So far I know the OpenThread people use MPL for that [1], so no MLD. But for constrained networks, so far I know there is also no implementation for MPL in RIOT. :-/

I'm wondering if somebody was stumbling upon a similar issue? There seems to be a proposal within the MQTT-SN community [2] which is probably worthwhile to consider? Thanks in advance!

Best, Michael

[1] http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf [2] MQTT SN Multicast Addresses · mqtt/mqtt.org Wiki · GitHub

- Alex

[0] draft-ietf-6lo-mesh-link-establishment-00 [1] RFC 7731 - Multicast Protocol for Low-Power and Lossy Networks (MPL)

Alexander Aring wrote:

But for constrained networks, so far I know there is also no implementation for MPL in RIOT. :-/

Indeed, if somebody has some time to spare, implementing MPL would be a very good way to make use of that (and probably a much better one than trying to beat a dead horse like MQTT-SN). (And, of course, there is also draft-bergmann-bier-ccast waiting for a non-Contiki implementation.)

Grüße, Carsten