8. Multicast CoAP
CoAP supports making requests to an IP multicast group. This is defined by a series of deltas to unicast CoAP. A more general discussion of CoAP group communication is provided in [GROUPCOMM].
A CoAP endpoint that provides a service that is discoverable by other endpoints using multicast service discovery joins one or more of the appropriate all-CoAP-nodes multicast addresses (Section 12.8) and listens on the default CoAP port. Note that an endpoint may receive multicast requests on other multicast addresses (including the all-nodes IPv6 address) or via broadcast on IPv4; therefore, an endpoint MUST be prepared to receive such messages but MAY ignore them if multicast service discovery is not desired.
8.1. Messaging Layer
A multicast request is characterized by being transported in a CoAP message that is addressed to an IP multicast address instead of a CoAP endpoint. Such multicast requests MUST be Non-confirmable.
A server SHOULD be aware that a request arrived via multicast, e.g., by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available.
To avoid an implosion of error responses, when a server is aware that a request arrived via multicast, it MUST NOT return a Reset message in reply to a Non-confirmable message. If it does not know, it MAY return a Reset message in reply to a Non-confirmable message as usual. Because such a Reset message will look identical to one sent for a unicast message to the sender, the sender MUST avoid using Message IDs that are also still active from this endpoint with any endpoint that might receive the multicast message.
At the time of writing, multicast messages can only be carried in UDP not DTLS. This means that the security modes defined in this document for CoAP do not apply to multicast.
8.2. Request/Response Layer
When a server is aware that a request arrived via multicast, the server MAY always ignore the request, particularly if it does not have a useful response (e.g., if it only would have an empty payload or an error response). This decision may depend on the application. (For example, in the query filtering described in [RFC6690], the server does not respond to a multicast request if the filter does not match. More examples are in [GROUPCOMM].)
If a server does decide to respond to a multicast request, it SHOULD NOT respond immediately. Instead, it SHOULD pick a duration for the time period during which it intends to respond. For the purposes of this exposition, we call the length of this period the Leisure. The specific value of this Leisure may depend on the application or MAY be derived as described below. The server then SHOULD pick a random point of time within the chosen leisure period to send back the unicast response to the multicast request. If further responses need to be sent based on the same multicast address membership, a new leisure period starts at the earliest after the previous one finishes.
To compute a value for Leisure, the server SHOULD have a group size estimate G, a target data transfer rate R (both chosen conservatively), and an estimated response size S; a rough lower bound for Leisure can then be computed as
lb_Leisure = S * G / R
For example, for a multicast request with link-local scope on a 2.4 GHz IEEE 802.15.4 (6LoWPAN) network, G can be (relatively conservatively) set to 100, S set to 100 bytes, and the target rate to 8 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is 10 s.
If a CoAP endpoint does not have suitable data to compute a value for Leisure, it MAY resort to DEFAULT_LEISURE.
When matching a response to a multicast request, only the token MUST match; the source endpoint of the response does not (and will not) be the same as the destination endpoint of the original request.
For the purposes of interpreting the Location-* options and any links embedded in the representation, the request URI (i.e., the base URI relative to which the response is interpreted) is formed by replacing the multicast address in the Host component of the original request URI by the literal IP address of the endpoint actually responding.
8.2.1. Caching
When a client makes a multicast request, it always makes a new request to the multicast group (since there may be new group members that joined meanwhile or that did not get the previous request). It MAY update a cache with the received responses. It then uses both cached-still-fresh and new responses as the result of the request.
A response received in reply to a GET request to a multicast group MAY be used to satisfy a subsequent request on the related unicast request URI. The unicast request URI is obtained by replacing the authority part of the request URI with the transport-layer source address of the response message.
A cache MAY revalidate a response by making a GET request on the related unicast request URI.
A GET request to a multicast group MUST NOT contain an ETag option. The mechanism for suppressing responses the client already has is left for further study.
8.2.2. Proxying
When a forward-proxy receives a request with a Proxy-Uri or URI constructed from Proxy-Scheme that indicates a multicast address, the proxy obtains a set of responses as described above and sends all responses (both cached-still-fresh and new) back to the original client.
This specification provides no way to indicate the unicast-modified request URI (base URI) in the responses thus forwarded. Proxying multicast requests is discussed in more detail in [GROUPCOMM]; one way to address the base URI issue can be found in Section 3 of [CoAP-MISC].