On Wednesday 13 January 2016 02:14:32 Markus Jung wrote: > Hello IoTivity community, > please find attached a proposal for extending IoTivity with several features > based on IPv6 multicasting. The possible extensions are: > - group update: simultaneously update multiple resource servers with a > single multicast request > - group synchronization: synchronize the state > among multiple resource servers to realize simple control scenarios > - group > observe: notify multiple observers with a single multicast message This > could improve the communication efficiency of IoTivity and reduce the > latency. > The IoTivity extensions could be done with reasonable effort, > since it would rely on the IPv6 stacks of the underlying platform which are > out of scope for IoTivity. Therefore, the extension could be part of the > next major IoTivity release (~ summer 2016). I am looking forward to your > feedback!
Hello Markus Thank you for publishing this, it looks very interesting. From what I understood of your problems, group update is the simple, typical case of sending a command to a full group. Group observe is technically a reverse group: whenever a client requests to observe a group, the server includes the multicast address in which such information will be sent to. I don't understand the group synchronisation case. Can you clarify? There are a couple of technical challenges for us. 1) group address assignment We need a way to dynamically create a group ID for each group. I did a search for existing proposals on this topic and all I found has been obsoleted. The conclusion from RFC 6308 (https://tools.ietf.org/html/rfc6308#section-3.5) is that this needed more research and wasn't deployed. Is there any reason to have the group address be anything other than randomly assigned upon creation? If it is random, how does it persist across device reboots? 2) group address reuse With 96 bits of group addresses, we are unlikely to reuse the same ID more than once, but assuming it happens, is that a problem? From your proposal, it would be. Take your example on slide 6: PUT coap://[ff12::1]/ {"on-off": true} Since there is no URI path associated, we can't very well have other devices that don't belong in this group receiving the packet. That means the address assignment, whether random or not, needs to verify whether the group is empty before. One way to solve this is to have a CONfirmed ping message sent to the group ID and, if any reply is received, we conclude the group is in use. Another way is to simply reuse IGMP, which has that exact functionality: finding out if a multicast address is in use. Though note that some networks might not use IGMP, but something else instead (Thread). A third option is to create a unique group ID which is known to the group members. Then the PUT message would instead be: PUT coap://[ff12::1]/group-id {"on-off": true} For example, the group-id could be derived from the group host's own UUID plus a unique number. Example: 1ad1f31e-c29f-4a63-a21f-c286526c2c0a/1. I recommend we use a group ID created by the group host, plus use that to create the IPv6 group address (a simple XOR of every 64 bits of data; in the example above, we'd have group address 0x1ad1f31ec29f4a63 ^ 0xa21fc286526c2c0a ^ 1 = 0xb8ce319890f36668 ? ff12::b8ce:3198:90f3:6668 ) Note the packet size impact: the IPv6 group address is carried in-line as 64- bit and the group ID is carried in full (if we drop the dashes, 34-40 bytes). If this is too much, instead of XOR, we can design the multicast group address generation in such a way that we can avoid duplicating information. 3) full-group reachability Currently, the group host sends CONfirmed packets to each group member. You're replacing that with NON-confirmed, which means packet loss would be a visible behaviour to the user. I propose it be CONfirmed instead. The group host knows how many devices are still in the group, so it can tick off the ACKs, then resend via unicast to those that failed to ACK. Unfortunately, this implies a delay of up to a few seconds. For actions that should be real-time, multicasting may not be a viable answer, as long as it's not reliable. 4) multicast join failure Constrained devices may not be able to join more than a handful of multicast groups. What's more, in some networks (e.g., Thread), multicast membership is stateful, which means joining additional groups may not work if the router can't add to the multicast tables. Therefore, the group host needs to be able to fall back to unicast gracefully. I propose this be done by way of #3 above. The alternative approach is that, for the normal group scenario, we have a new payload that is sent to each group member telling them that they've been added to the group and include the group ID. The device will then attempt to join the multicast group. Its failure or success to join the group is included in the ACK reply. This way, the group host knows which devices it should be able to reach via multicast and which ones will need unicast. This isn't possible for the observe scenario, since the "you should join this group" command comes as a reply. If the device being told to join a group (the observer) fails to do so, it can't warn the observed device that it failed. Therefore, I recommend the graceful fail-over to unicast. 5) scope and reachability As you noted in your slides, multicast forwarding is not deployed in the wild today. So we can easily assume today that groups are of link-local scope only. Should we then only use link-local scopes (ff12::) and/or realm-local scopes (ff13::)? Or should we go for something higher? And for any level: how do you ensure that the device being added to the group can be reached in that group? Imagine, for example, that a device that isn't part of the same link gets added to a group. If we tell it to join ff12::b8ce:3198:90f3:6668, it might succeed but will never be reached. Again, this may not be a problem given #3, but we should still choose a suitable scope. 6) Bluetooth and other transports As you mentioned on slide 12, Bluetooth is a problem. It has no concept of multicast, only unicast. I would argue that this applies *only* to IPv6 networks, where IPv6 is mandatory. Whenever Bluetooth implements 6lo, they will figure out how to do multicasting. That's their problem, not ours. A few more comments on each slide: slide 5: your picture of the IPv6 multicast addressing is outdated. Please update it with the latest from RFC 7371 section 4.2 (https://tools.ietf.org/html/rfc7371). It extends the flags to 8 bits (XRPT/rrrr), but note that the only flag interesting to us is still T, so your examples don't change. slides 7, 9, 10: where you wrote "coap://2001::DB8", it should be "coap://[2001:DB8::]" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
