Event Binding for CoAP Multicast

[mkovatsc]

CoAP devices may emit events by POSTing to a specific multicast address + well-known path.

This information can easily packed into a TD. Question is if that multicast address should go into href or rather the mechanism how to join the multicast group.

[egekorkan]

Is there any further comments on this question?

[takuki]

I think we should try this out first in PlugFests.

[takuki]

On September 20 in Fukuoka, it was pointed out that although this is worth discussing further, the IG/WG should incubate first. See minutes here.

[egekorkan]

@ektrah has mentioned that there is activity on this in the IETF ACE and CoRe working groups.

[egekorkan]

With @ektrah we have identified 3 use cases of CoAP Multicast:

1. Composed Things: CoAP Multicast can be also used for "Composed Things" where a single request from the Consumer can trigger multiple Things (e.g. turning off all lamps at once). For a Consumer, this looks like a single IPv6 address, the distribution happens in the IP layer. This single IPv6 address can be in a composed Thing TD.
2. Client Thing Event Notification: A Thing can act as a client and send a request to a multicast group. The Consumers need to be servers and configure themselves in advance to be in this multicast group. Then, they will get the event notifications as CoAP requests. Answering back to the client Thing can be also described dataResponse. In this case, the form of the Event Affordance (via href) with a subscribeevent means to not subscribe to that resource but means that in order to subscribe, the Consumer needs to be in the multicast group.
3. Multicast Observe: A new working draft (on the RFC track) at IETF https://datatracker.ietf.org/doc/draft-ietf-core-observe-multicast-notifications/ allows a server (Thing) to respond to multiple observers (client Consumer) of the same resource at the same time. This would be like the 2nd case but switched roles. We need to wait for it to become RFC.