idnits 2.17.1 draft-ietf-core-groupcomm-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 02, 2013) is 3859 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-21) exists of draft-ietf-core-block-12 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-05 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-00 == Outdated reference: A later version (-05) exists of draft-ietf-appsawg-uri-get-off-my-lawn-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group A. Rahman, Ed. 3 Internet-Draft InterDigital Communications, LLC 4 Intended status: Informational E. Dijk, Ed. 5 Expires: April 05, 2014 Philips Research 6 October 02, 2013 8 Group Communication for CoAP 9 draft-ietf-core-groupcomm-16 11 Abstract 13 CoAP is a specialized web transfer protocol for constrained devices 14 and constrained networks. It is anticipated that constrained devices 15 will often naturally operate in groups (e.g., in a building 16 automation scenario all lights in a given room may need to be 17 switched on/off as a group). This document provides guidance for how 18 the CoAP protocol should be used in a group communication context. 19 An approach for using CoAP on top of IP multicast is detailed. Also, 20 various use cases and corresponding protocol flows are provided to 21 illustrate important concepts. Finally, guidance is provided for 22 deployment in various network topologies. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 05, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4 62 2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 4 63 2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 4 64 2.2. Group Definition and Naming . . . . . . . . . . . . . . . 5 65 2.3. Port and URI Configuration . . . . . . . . . . . . . . . 6 66 2.4. Group Methods . . . . . . . . . . . . . . . . . . . . . . 7 67 2.5. Group Member Discovery . . . . . . . . . . . . . . . . . 8 68 2.6. Configuring Group Membership in Endpoints . . . . . . . . 8 69 2.6.1. Background . . . . . . . . . . . . . . . . . . . . . 8 70 2.6.2. RESTful Interface . . . . . . . . . . . . . . . . . . 9 71 2.7. Multicast Request Acceptance and Response Suppression . . 11 72 2.8. Congestion Control . . . . . . . . . . . . . . . . . . . 13 73 2.9. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 14 74 2.10. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 15 75 3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 16 76 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 16 77 3.2. Network Configuration . . . . . . . . . . . . . . . . . . 16 78 3.3. Discovery of Resource Directory . . . . . . . . . . . . . 18 79 3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 20 80 3.5. Lighting Control in MLD Enabled Network . . . . . . . . . 23 81 3.6. Commissioning the Network Based On Resource Directory . . 24 82 4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 25 83 4.1. Target Network Topologies . . . . . . . . . . . . . . . . 25 84 4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 25 85 4.3. Networks Using RPL Multicast Without MLD . . . . . . . . 26 86 4.4. Networks Using MPL Forwarding Without MLD . . . . . . . . 26 87 4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 27 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 89 5.1. Security Configuration . . . . . . . . . . . . . . . . . 28 90 5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 28 92 5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 28 93 5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 29 94 5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 29 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 96 6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 29 97 6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 29 98 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 101 8.2. Informative References . . . . . . . . . . . . . . . . . 32 102 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 33 103 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 106 1. Introduction 108 1.1. Background 110 Constrained Application Protocol (CoAP) is a Representational State 111 Transfer (REST) based web transfer protocol for resource constrained 112 devices operating in an IP network [I-D.ietf-core-coap]. CoAP has 113 many similarities to HTTP [RFC2616] but also has some key 114 differences. Constrained devices can be large in numbers, but are 115 often related to each other in function or location. For example, 116 all the light switches in a building may belong to one group and all 117 the thermostats may belong to another group. Groups may be pre- 118 configured before deployment or dynamically formed during operation. 119 If information needs to be sent to or received from a group of 120 devices, group communication mechanisms can improve efficiency and 121 latency of communication and reduce bandwidth requirements for a 122 given application. HTTP does not support any equivalent 123 functionality to CoAP group communication. 125 1.2. Scope 127 Group communication involves a one-to-many relationship between CoAP 128 endpoints. Specifically, a single CoAP client will simultaneously 129 get (or set) resource representations from multiple CoAP servers 130 using CoAP over IP multicast. An example would be a CoAP light 131 switch turning on/off multiple lights in a room with a single CoAP 132 group communication PUT request, and handling the potential multitude 133 of (unicast) responses. 135 The normative protocol aspects of running CoAP on top of IP Multicast 136 and processing the responses are given in [I-D.ietf-core-coap]. The 137 main contribution of this document lies in providing additional 138 guidance for several important group communication features. Among 139 the topics covered are group definition, group resource manipulation, 140 and group configuration. Also, proxy operation and minimizing 141 network congestion for group communication is discussed. Finally, 142 specific use cases and deployment guidelines for CoAP group 143 communication are outlined. 145 1.3. Conventions and Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 [RFC2119]. 152 The above key words are used to establish a set of guidelines for 153 CoAP group communication. An implementation of CoAP group 154 communication MAY implement these guidelines; an implementation 155 claiming compliance to this document MUST implement the set of 156 guidelines. 158 This document assumes readers are familiar with the terms and 159 concepts that are used in [I-D.ietf-core-coap]. In addition, this 160 document defines the following terminology: 162 Group Communication 163 A source node sends a single message which is delivered to 164 multiple destination nodes, where all destinations are identified 165 to belong to a specific group. The source node itself may be part 166 of the group. The underlying mechanism for group communication is 167 assumed to be multicast based. The network involved may be a 168 constrained network such as a low-power, lossy network. 170 Multicast 171 Sending a message to multiple destination nodes with one network 172 invocation. There are various options to implement multicast 173 including layer 2 (Media Access Control) and layer 3 (IP) 174 mechanisms. 176 IP Multicast 177 A specific multicast solution based on the use of IP multicast 178 addresses as defined in "IANA Guidelines for IPv4 Multicast 179 Address Assignments" [RFC5771] and "IP Version 6 Addressing 180 Architecture" [RFC4291]. 182 Low power and Lossy Network (LLN) 183 A type of constrained IP network where devices are interconnected 184 by low-power and lossy links. The links may be may composed of 185 one or more technologies such as IEEE 802.15.4, Bluetooth Low 186 Energy (BLE), Digital Enhanced Cordless Telecommunication (DECT), 187 and IEEE P1901.2 power-line communication. 189 2. Protocol Considerations 191 2.1. IP Multicast Background 192 IP Multicast protocols have been evolving for decades, resulting in 193 standards such as Protocol Independent Multicast - Sparse Mode (PIM- 194 SM) [RFC4601]. IP Multicast is very popular in specific deployments 195 such as in enterprise networks (e.g., for video conferencing), smart 196 home networks (e.g., Universal Plug and Play (UPnP)) and carrier IPTV 197 deployments. The packet economy and minimal host complexity of IP 198 multicast make it attractive for group communication in constrained 199 environments. 201 To achieve IP multicast beyond link-local scope, an IP multicast 202 routing or forwarding protocol needs to be active on IP routers. An 203 example of a routing protocol specifically for LLNs is the IPv6 204 Routing Protocol for Low-Power and Lossy Networks (RPL) (Section 12 205 of [RFC6550]) and an example of a forwarding protocol for LLNs is 206 Multicast Protocol for Low power and Lossy Networks (MPL) 207 [I-D.ietf-roll-trickle-mcast]. RPL and MPL do not depend on each 208 other; each can be used in isolation and both can be used in 209 combination in a network. Finally, PIM-SM [RFC4601] is often used 210 for multicast routing in traditional IP networks (i.e. networks that 211 are not constrained). 213 IP multicast can also be run in a Link-Local (LL) scope. This means 214 that there is no routing involved and an IP multicast message is only 215 received over the link on which it was sent. 217 For a complete IP multicast solution, in addition to a routing/ 218 forwarding protocol, a "listener" protocol may be needed for the 219 devices to subscribe to groups (see Section 4.2). 221 2.2. Group Definition and Naming 223 A group is defined as a set of CoAP endpoints, where each endpoint is 224 configured to receive multicast CoAP requests that are sent to the 225 group's associated IP multicast address. An endpoint MAY be a member 226 of multiple groups. Group membership of an endpoint MAY dynamically 227 change over time. 229 A Group URI has the scheme 'coap' and includes in the authority part 230 either a group IP multicast address or a hostname (e.g., Group Fully 231 Qualified Domain Name (FQDN)) that can be resolved to the group IP 232 multicast address. A Group URI also contains an optional CoAP port 233 number in the authority part. Group URIs follow the CoAP URI syntax 234 [I-D.ietf-core-coap]. 236 Note: A Group URI is needed to initiate CoAP group communications. 237 If a CoAP implementation accepts a CoAP URI as input in the group 238 communications request API, then the parsing method of Section 6.4 of 239 [I-D.ietf-core-coap] should be used in such way that a CoAP multicast 240 request is generated. 242 It is recommended, for sending nodes, to use the IP multicast address 243 literal in a Group URI. In case a Group hostname is used, it can be 244 uniquely mapped to a site-local or global IP multicast address via 245 DNS resolution (if supported). Some examples of hierarchical Group 246 FQDN naming (and scoping) for a building control application are 247 shown below (and are derived from [I-D.vanderstok-core-dna]): 249 URI authority Targeted group of nodes 250 --------------------------------------- -------------------------- 251 all.bldg6.example.com "all nodes in building 6" 252 all.west.bldg6.example.com "all nodes in west wing, 253 building 6" 254 all.floor1.west.bldg6.example.com "all nodes in floor 1, 255 west wing, building 6" 256 all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036, 257 floor1, west wing, 258 building 6" 260 Similarly, if supported, reverse mapping (from IP multicast address 261 to Group FQDN) is possible using the reverse DNS resolution technique 262 ([I-D.vanderstok-core-dna]). 264 2.3. Port and URI Configuration 266 A CoAP server that is a member of a group listens for CoAP messages 267 on the group's IP multicast address, on a specified UDP port. The 268 default UDP port is the CoAP default port 5683 but a non-default UDP 269 port MAY be specified for the group; in which case implementers MUST 270 ensure that all group members are configured to use this same port. 272 Multicast based group communication will not work if there is 273 diversity in the authority port (e.g., different dynamic port 274 addresses across the group) or if other parts of the URI such as the 275 path, or the query, differ on different endpoints. Therefore, some 276 measures must be present to ensure uniformity in port number and 277 resource names/locations within a group. All CoAP multicast requests 278 MUST be sent using a port number according to one of below options: 280 1. A pre-configured port number. The pre-configuration mechanism 281 MUST ensure that the same port number is pre-configured across 282 all endpoints in a group and across all CoAP clients performing 283 the group requests. 285 2. If the client is configured to use service discovery including 286 port discovery, it uses a port number obtained via a service 287 discovery lookup operation for the targeted CoAP multicast group. 289 3. Use the default CoAP UDP port (5683). 291 All CoAP multicast requests SHOULD operate on URI paths in one of the 292 following ways: 294 1. Pre-configured URI paths, if available. The pre-configuration 295 mechanism SHOULD ensure that these paths are pre-configured 296 across all CoAP servers in a group and all CoAP clients 297 performing the group requests. Note that 298 [I-D.ietf-appsawg-uri-get-off-my-lawn] prescribes that any 299 specification must not constrain, define structure or semantics 300 for any path component. 302 2. If the client is configured to use default CoRE resource 303 discovery, it uses URI paths retrieved from a "/.well-known/core" 304 lookup on a group member. The URI paths the client will use MUST 305 be known to be available also in all other endpoints in the 306 group. The URI path configuration mechanism on servers MUST 307 ensure that these URIs (identified as being supported by the 308 group) are configured on all group endpoints. 310 3. If the client is configured to use another form of service 311 discovery, it uses URI paths from an equivalent service discovery 312 lookup which returns the resources supported by all group 313 members. 315 4. If the client has received a Group URI through a previous RESTful 316 interaction with a trusted server, for the purpose of the client 317 using this URI in a request, it can use this URI in a multicast 318 request. For example, a commissioning tool may instruct a sensor 319 device in this way to which target (multicast URI) it should 320 report sensor events. 322 2.4. Group Methods 324 Idempotent methods (i.e., CoAP GET, PUT, and DELETE) SHOULD be used 325 for group communication, with one exception as follows. A non- 326 idempotent method (i.e., CoAP POST) MAY be used for group 327 communication if the resource being POSTed to has been designed to 328 cope with the lossy nature of multicast. Note that not all group 329 members are guaranteed to receive the multicast request, and the 330 sender cannot readily find out which group members did not receive 331 it. 333 All CoAP messages that are sent via multicast MUST be Non- 334 confirmable. A unicast response per server MAY be sent back to 335 answer the group communication request (e.g., response "2.05 Content" 336 to a group GET request) taking into account the congestion control 337 rules defined in Section 2.8. The unicast responses received may be 338 a mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not 339 Found) codes depending on the individual server processing results 340 (see section 8 of [I-D.ietf-core-coap]). 342 2.5. Group Member Discovery 344 CoAP Groups, and the membership of these groups, can be discovered 345 via the lookup interfaces defined in 346 [I-D.ietf-core-resource-directory]. An example of doing some of 347 these lookups is given in Section 3.6. 349 2.6. Configuring Group Membership in Endpoints 351 2.6.1. Background 353 The group membership of a CoAP endpoint may be configured in one of 354 the following ways. First, the group membership may be pre- 355 configured before node deployment. Second, a node may be programmed 356 to discover (query) its group membership during operation using a 357 specific service discovery means. Third, it may be configured during 358 operation by another node (e.g., a commissioning device). 360 In the first case, the pre-configured group information may be either 361 directly a IP multicast address, or a hostname (FQDN) which is during 362 operation resolved to a IP multicast address by the endpoint using 363 DNS (if supported). 365 For the second case, a CoAP endpoint may look up its group membership 366 using techniques such as DNS-SD and Resource Directory 367 [I-D.ietf-core-resource-directory]. The latter is detailed more in 368 Section 3.6. 370 In the third case, typical in scenarios such as building control, a 371 commissioning tool determines to which group a sensor or actuator 372 node belongs, and writes this information to the node, which can 373 subsequently join the correct IP multicast group on its network 374 interface. The information written may again be an IP multicast 375 address or a hostname. 377 2.6.2. RESTful Interface 379 To achieve better interoperability between endpoints from different 380 manufacturers, an OPTIONAL RESTful interface for configuring CoAP 381 endpoints with relevant group information is described here. This 382 interface provides a solution for the third case mentioned above. To 383 access this interface a client MUST use unicast methods (GET/PUT/ 384 POST) only as it is a method of configuring group information in 385 individual endpoints. Using multicast operations in this situation 386 may lead to unexpected (possibly circular) behavior in the network. 387 Also, the (unicast) methods to configure group membership SHOULD use 388 DTLS-secured CoAP [I-D.ietf-core-coap]. Thus only authorized 389 controllers should be allowed by an endpoint to configure its group 390 membership. 392 CoAP endpoints implementing this optional mechanism MUST support the 393 group configuration Internet Media Type "application/coap-group+json" 394 (Section 6.2). A resource offering this representation can be 395 annotated for direct discovery [RFC6690] using the resource type (rt) 396 "core.gp" where "gp" is shorthand for "group" (Section 6.1). An 397 authorized controller uses this media type to query/manage group 398 membership of a CoAP endpoint as defined below. 400 2.6.2.1. GET Interface 402 The group configuration resource has a JSON-based content format (as 403 indicated by the media type). A (unicast) GET on a CoAP endpoint 404 with a resource with this format returns a JSON array of group 405 objects, each group object being a JSON object that indicates one 406 multicast group membership. The example below illustrates a request 407 to an endpoint querying its group membership information, where the 408 response is in the "application/coap-group+json" content format 409 containing a single group object: 411 Req: GET /gp 412 Res: 2.05 Content (Content-Format: application/coap-group+json) 413 [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", 414 "a": "ff15::4200:f7fe:ed37:14ca" } 415 ] 417 In a response, the OPTIONAL "n" key/value pair stands for "name" and 418 identifies the group with a hostname, for example a FQDN. 420 The "a" key/value pair specifies the IP multicast address (and 421 optionally the port number) of the group. It contains an IPv4 422 address or an IPv6 address in dotted decimal notation. The following 423 ABNF rule can be used for parsing the address, referring to the 424 definitions in Section 6 of [I-D.ietf-core-coap] and [RFC3986]. 426 group-address = IPv4address [ ":" port ] 427 / "[" IPv6address "]" [":" port ] 429 If the port number is not provided then it is assumed to be the 430 default CoAP port (5683). The "a" key/value pair MUST be included if 431 the IP address is known at the time of generating the response, and 432 SHOULD NOT be included if unknown. 434 Note that each group object in the JSON array represents a single IP 435 multicast group for the endpoint. If there are multiple elements in 436 the array then the endpoint is a member of multiple IP multicast 437 groups. 439 2.6.2.2. POST Interface 441 A (unicast) POST with a group configuration media type as payload 442 instructs the CoAP endpoint to join the defined group(s). The 443 endpoint adds the specified IP multicast address(es) to its network 444 interface configuration. The endpoint also updates the resource by 445 adding the specified group object(s) to the existing ones: 447 Req: POST /gp (Content-Format: application/coap-group+json) 448 [ { "n": "All-Devices.floor1.west.bldg6.example.com", 449 "a": "ff15::4200:f7fe:ed37:abcd" } ] 450 Res: 2.04 Changed 452 In a request, the "a" key/value pair is OPTIONAL to define the 453 group's associated IP multicast address. The "n" pair is also 454 OPTIONAL. If the "a" pair is given, this takes priority and the "n" 455 pair becomes informational. If only the "n" pair is given, the CoAP 456 endpoint may perform DNS resolution (if supported) to obtain the IP 457 multicast address from the hostname. At least one of the "n"/"a" 458 pairs MUST be given per group object. 460 After any change on a Group configuration resource, the endpoint MUST 461 effect registration/de-registration from the corresponding IP 462 multicast group(s) as soon as possible. When a POST payload contains 463 in "a" a multicast address to which the endpoint is already 464 subscribed, the endpoint MUST re-register to that multicast address. 466 2.6.2.3. PUT Interface 468 A (unicast) PUT with a group configuration media type as payload will 469 replace all current group memberships in the endpoint with the new 470 ones defined in the PUT request. The format of the group 471 configuration payload, and the requirements for it, are the same as 472 in Section 2.6.2.2. 474 A (unicast) PUT with an empty array [] will delete all group 475 memberships from the endpoint. Note that it is not possible to 476 delete individual group memberships on an endpoint. (A DELETE 477 interface is not defined as the underlying resource should not be 478 removed even if it is empty). 480 2.7. Multicast Request Acceptance and Response Suppression 482 CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define 483 normative behaviors for: 485 1. Multicast request acceptance - in which cases a CoAP request is 486 accepted and executed, and when not. 488 2. Multicast response suppression - in which cases the CoAP response 489 to an already-executed request is returned to the requesting 490 endpoint, and when not. 492 A CoAP response differs from a CoAP ACK; ACKs are never sent by 493 servers in response to a multicast CoAP request. This section first 494 summarizes these normative behaviors and then presents additional 495 guidelines for response suppression. Also a number of multicast 496 example applications are given to illustrate the overall approach. 498 To apply any rules for request and/or response suppression, a CoAP 499 server must be aware that an incoming request arrived via multicast 500 by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]. 502 For multicast request acceptance, the REQUIRED behaviors are: 504 o A server SHOULD NOT accept a multicast request that cannot be 505 "authenticated" in some way (cryptographically or by some 506 multicast boundary limiting the potential sources) 507 [I-D.ietf-core-coap]. See Section 5.3 for examples of multicast 508 boundary limiting methods. 510 o A server SHOULD NOT accept a multicast discovery request with a 511 query string (as defined in CoRE Link Format [RFC6690]) if 512 filtering ([RFC6690]) is not supported by the server. 514 o A server SHOULD NOT accept a multicast request that acts on a 515 specific resource for which multicast support is not required. 516 (Note that for the resource "/.well-known/core", multicast support 517 is required if "multicast resource discovery" is supported as 518 specified in section 1.2.1 of [RFC6690]). Implementers are 519 advised to disable multicast support by default on any other 520 resource, until explicitly enabled by an application or by 521 configuration.) 523 o Otherwise accept the multicast request. 525 For multicast response suppression, the REQUIRED behaviors are: 527 o A server SHOULD NOT respond to a multicast discovery request if 528 the filter specified by the request's query string does not match. 530 o A server MAY choose not to respond to a multicast request, if 531 there's nothing useful to respond (e.g., error or empty response). 533 o Otherwise respond to the multicast request. 535 The above response suppression behaviors are complemented by the 536 following guidelines. CoAP servers SHOULD implement configurable 537 response suppression, enabling at least the following options per 538 resource that supports multicast requests: 540 o Suppression of all 2.xx success responses; 542 o Suppression of all 4.xx client errors; 544 o Suppression of all 5.xx server errors; 546 o Suppression of all 2.05 responses with empty payload. 548 A number of group communication example applications are given below 549 to illustrate how to make use of response suppression: 551 o CoAP resource discovery: Suppress 2.05 responses with empty 552 payload and all 4.xx and 5.xx errors. 554 o Lighting control: Suppress all 2.xx responses after a lighting 555 change command. 557 o Update configuration data in a group of devices using multicast 558 PUT: No suppression at all. The client uses collected responses 559 to identify which group members did not receive the new 560 configuration; then attempts using CoAP CON unicast to update 561 those specific group members. 563 o Multicast firmware update by sending blocks of data: Suppress all 564 2.xx and 5.xx responses. After having sent all multicast blocks, 565 the client checks each endpoint by unicast to identify which data 566 blocks are still missing in each endpoint. 568 o Conditional reporting for a group (e.g., sensors) based on a URI 569 query: Suppress all 2.05 responses with empty payload (i.e., if a 570 query produces no matching results). 572 2.8. Congestion Control 574 Multicast CoAP requests may result in a multitude of responses from 575 different nodes, potentially causing congestion. Therefore both the 576 sending of multicast requests, and the sending of the unicast CoAP 577 responses to these multicast requests should be conservatively 578 controlled. 580 CoAP [I-D.ietf-core-coap] reduces multicast-specific congestion risks 581 through the following measures: 583 o A server MAY choose not to respond to a multicast request if 584 there's nothing useful to respond (e.g., error or empty response). 585 See Section 2.7 for more detailed guidelines on response 586 suppression. 588 o A server SHOULD limit the support for multicast requests to 589 specific resources where multicast operation is required. 591 o A multicast request MUST be Non-confirmable. 593 o A response to a multicast request SHOULD be Non-confirmable 594 (Section 5.2.3 of [I-D.ietf-core-coap]). 596 o A server does not respond immediately to a multicast request, but 597 SHOULD first wait for a time that is randomly picked within a 598 predetermined time interval called the Leisure. 600 Additional guidelines to reduce congestion risks defined in this 601 document are: 603 o A server in an LLN should only support multicast GET for resources 604 that are small. For example, the payload of the response is 5% of 605 the IP Maximum Transmit Unit (MTU) size (e.g. so it fits into a 606 single link-layer frame). 608 o A server can minimize the payload length in response to a 609 multicast GET on "/.well-known/core" by using hierarchy in 610 arranging link descriptions for the response. An example of this 611 is given in Section 5 of [RFC6690]. 613 o A server can also minimize the payload length of a response to a 614 multicast GET (e.g., on "/.well-known/core") using CoAP blockwise 615 transfers [I-D.ietf-core-block], returning only a first block of 616 the CoRE Link Format description. For this reason, a CoAP client 617 sending a multicast CoAP request to "/.well-known/core" SHOULD 618 support core-block. 620 o A client should use CoAP multicast with the smallest possible 621 multicast scope that fulfills the application needs. As an 622 example, site-local scope is always preferred over global scope IP 623 multicast if this fulfills the application needs. 625 More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944] 626 are given in Section 4.5. 628 2.9. Proxy Operation 630 CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy 631 to process its CoAP request. For this purpose the client either 632 specifies the request URI as a string in the Proxy-URI option, or it 633 specifies the Proxy-Scheme option with the URI constructed from the 634 usual Uri-* options. This approach works well for unicast requests. 635 However, there are certain issues and limitations of processing the 636 (unicast) responses to a group communication request made in this 637 manner through a proxy. 639 A proxy may buffer all the individual (unicast) responses to a group 640 communication request and then send back only a single (aggregated) 641 response to the client. However there are some issues with this 642 aggregation approach: 644 o Aggregation of (unicast) responses to a group communication 645 request in a proxy is difficult. This is because the proxy does 646 not know how many members there are in the group, or how many 647 group members will actually respond. Also the proxy does not know 648 how long to wait before deciding to send back the aggregated 649 response to the client. 651 o There is no default format defined in CoAP for aggregation of 652 multiple responses into a single response. 654 Alternatively, if a proxy follows directly the specification for a 655 CoAP Proxy [I-D.ietf-core-coap], the proxy would simply forward all 656 the individual (unicast) responses to a group communication request 657 to the client (i.e., no aggregation). There are also issues with 658 this approach: 660 o The client may be confused as it may not have known that the 661 Proxy-URI contained a multicast target. That is, the client may 662 be expecting only one (unicast) response but instead receives 663 multiple (unicast) responses potentially leading to fault 664 conditions in the application. 666 o Each individual CoAP response will appear to originate (IP Source 667 address) from the CoAP Proxy, and not from the server that 668 produced the response. This makes it impossible for the client to 669 identify the server that produced each response. 671 Due to above issues, a guideline is defined here that a CoAP Proxy 672 SHOULD NOT support processing a multicast CoAP request but rather 673 return a 501 (Not Implemented) response in such case. The exception 674 case here (i.e., to process it) is allowed under following 675 conditions: 677 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 678 proxied multicast requests by specific client(s). 680 o The proxy SHOULD return individual (unicast) CoAP responses to the 681 client (i.e., not aggregated). The exception case here occurs 682 when a (future) standardized aggregation format is being used. 684 o It MUST be known to the person/entity doing the configuration of 685 the proxy, or otherwise verified in some way, that the client 686 configured in the whitelist supports receiving multiple responses 687 to a proxied unicast CoAP request. 689 2.10. Exceptions 691 Group communication using IP multicast offers improved network 692 efficiency and latency amongst other benefits. However, group 693 communication may not always be possible to implement in a given 694 network. The primary reason for this will be if IP multicast is not 695 (fully) supported in the network. 697 For example, in an LLN where the RPL protocol is used for routing in 698 "Non-storing mode" (Mode Of Operation=1) or "Storing mode with no 699 multicast support" (Mode Of Operation=2) [RFC6550] and no other 700 routing/forwarding protocol is defined, there will be no IP multicast 701 routing beyond link-local scope. This means that any CoAP group 702 communication above link-local scope will not be supported in this 703 network. 705 3. Use Cases and Corresponding Protocol Flows 707 3.1. Introduction 709 The use of CoAP group communication is shown in the context of the 710 following two use cases and corresponding protocol flows: 712 o Discovery of Resource Directory (RD, 713 [I-D.ietf-core-resource-directory]): discovering the local CoAP RD 714 which contains links to resources stored on other CoAP servers 715 [RFC6690]. 717 o Lighting Control: synchronous operation of a group of 718 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 720 3.2. Network Configuration 722 To illustrate the use cases we define two network configurations. 723 Both are based on the topology as shown in Figure 1. The two 724 configurations using this topology are: 726 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 727 6LoWPAN Border Routers (6LBRs, [RFC6775]). 729 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 730 multicast-capable Ethernet routers. 732 Both configurations are further specified by the following: 734 o A large room (Room-A) with three lights (Light-1, Light-2, 735 Light-3) controlled by a Light Switch. The devices are organized 736 into two subnets. In reality, there could be more lights (up to 737 several hundreds) but these are not shown for clarity. 739 o Light-1 and the Light Switch are connected to a router (Rtr-1). 741 o Light-2 and the Light-3 are connected to another router (Rtr-2). 743 o The routers are connected to an IPv6 network backbone which is 744 also multicast enabled. In the general case, this means the 745 network backbone and Rtr-1/Rtr-2 support a PIM based multicast 746 routing protocol, and Multicast Listener Discovery (MLD) for 747 forming groups. 749 o A CoAP RD is connected to the network backbone. 751 o The DNS server is optional. If the server is there (connected to 752 the network backbone) then certain DNS based features are 753 available (e.g., DNS resolution of hostname to IP multicast 754 address). If the DNS server is not there, then different 755 provisioning of the network is required (e.g., IP multicast 756 addresses are hard-coded into devices, or manually configured, or 757 obtained via a service discovery method). 759 o A Controller (CoAP client) is connected to the backbone, which is 760 able to control various building functions including lighting. 762 ################################################ 763 # ********************** Room-A # 764 # ** Subnet-1 ** # Network 765 # * ** # Backbone 766 # * +----------+ * # | 767 # * | Light |-------+ * # | 768 # * | Switch | | * # | 769 # * +----------+ +---------+ * # | 770 # * | Rtr-1 |-----------------------------+ 771 # * +---------+ * # | 772 # * +----------+ | * # | 773 # * | Light-1 |--------+ * # | 774 # * +----------+ * # | 775 # ** ** # | 776 # ************************** # | 777 # # | 778 # ********************** # +------------+ | 779 # ** Subnet-2 ** # | DNS Server | | 780 # * ** # | (Optional) |--+ 781 # * +----------+ * # +------------+ | 782 # * | Light-2 |-------+ * # | 783 # * | | | * # | 784 # * +----------+ +---------+ * # | 785 # * | Rtr-2 |-----------------------------+ 786 # * +---------+ * # | 787 # * +----------+ | * # | 788 # * | Light-3 |--------+ * # | 789 # * +----------+ * # +------------+ | 790 # ** ** # | Controller |--+ 791 # ************************** # | Client | | 792 ################################################ +------------+ | 793 +------------+ | 794 | CoAP | | 795 | Resource |-----------------+ 796 | Directory | 797 +------------+ 799 Figure 1: Network Topology of a Large Room (Room-A) 801 3.3. Discovery of Resource Directory 803 The protocol flow for discovery of the CoAP RD for the given network 804 (of Figure 1) is shown in Figure 2: 806 o Light-2 is installed and powered on for the first time. 808 o Light-2 will then search for the local CoAP RD by sending out a 809 GET request (with the "/.well-known/core?rt=core.rd" request URI) 810 to the site-local "All CoAP Nodes" multicast address. 812 o This multicast message will then go to each node in subnet-2. 813 Rtr-2 will then forward into to the Network Backbone where it will 814 be received by the CoAP RD. All other nodes in subnet-2 will 815 ignore the multicast GET because it is qualified by the query 816 string "?rt=core.rd" (which indicates it should only be processed 817 by the endpoint if it contains a resource of type core.rd). 819 o The CoAP RD will then send back a unicast response containing the 820 requested content, which is a CoRE Link Format representation of a 821 resource of type core.rd. 823 o Note that the flow is shown only for Light-2 for clarity. Similar 824 flows will happen for Light-1, Light-3 and the Light Switch when 825 they are first installed. 827 The CoAP RD may also be discovered by other means such as by assuming 828 a default location (e.g., on a 6LBR), using DHCP, anycast address, 829 etc. However, these approaches do not invoke CoAP group 830 communication so are not further discussed here. (See 831 [I-D.ietf-core-resource-directory] for more details). 833 For other discovery use cases such as discovering local CoAP servers, 834 services or resources group communication can be used in a similar 835 fashion as in the above use case. Both Link-Local (LL) and site- 836 local discovery are possible this way. 838 Light CoAP 839 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD 840 | | | | | | | 841 | | | | | | | 842 ********************************** | | | 843 * Light-2 is installed * | | | 844 * and powers on for first time * | | | 845 ********************************** | | | 846 | | | | | | | 847 | | | | | | | 848 | | COAP NON Mcast(GET | | 849 | | /.well-known/core?rt=core.rd) | | 850 | |--------->-------------------------------->| | 851 | | | | | |--------->| 852 | | | | | | | 853 | | | | | | | 854 | | COAP NON (2.05 Content | | 855 | | ;rt="core.rd";ins="Primary") |<---------| 856 | |<------------------------------------------| | 857 | | | | | | | 859 Figure 2: Resource Directory Discovery via Multicast Request 861 3.4. Lighting Control 863 The protocol flow for a building automation lighting control scenario 864 for the network (Figure 1) is shown in Figure 3. The network is 865 assumed to be in a 6LoWPAN configuration. Also, it is assumed that 866 the CoAP servers in each Light are configured to suppress CoAP 867 responses for any multicast CoAP requests related to lighting 868 control. (See Section 2.7 for more details on response suppression 869 by a server.) 871 In addition, Figure 4 shows a protocol flow example for the case that 872 servers do respond to a lighting control multicast request with 873 (unicast) CoAP NON responses. There are two success responses and 874 one 5.00 error response. In this particular case, the Light Switch 875 does not check that all Lights in the group received the multicast 876 request by examining the responses. This is because the Light Switch 877 is not configured with an exhaustive list of the IP addresses of all 878 Lights belonging to the group. However, based on received error 879 responses it could take additional action such as logging a fault or 880 alerting the user via its LCD display. In case a CoAP message is 881 delivered multiple times to a Light, the subsequent CoAP messages can 882 be filtered out as duplicates, based on the CoAP Message ID. 884 Reliability of CoAP multicast is not guaranteed. Therefore, one or 885 more lights in the group may not have received the CoAP control 886 request due to packet loss. In this use case there is no detection 887 nor correction of such situations: the application layer expects that 888 the multicast forwarding/routing will be of sufficient quality to 889 provide on average a very high probability of packet delivery to all 890 CoAP endpoints in a multicast group. An example protocol to 891 accomplish this using randomized retransmission is the MPL forwarding 892 protocol for LLNs [I-D.ietf-roll-trickle-mcast]. 894 We assume the following steps have already occurred before the 895 illustrated flows: 897 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 898 all devices. The CoAP network is formed. 900 2. Network configuration (application-independent): 6LBRs are 901 configured with multicast addresses, or address blocks, to filter 902 out or to pass through to/from the 6LoWPAN. 904 3. Commissioning phase (application-related): The IP multicast 905 address of the group (Room-A-Lights) has been configured in all 906 the Lights and in the Light Switch. 908 4. As an alternative to the previous step, when a DNS server is 909 available, the Light Switch and/or the Lights have been 910 configured with a group hostname which each nodes resolves to the 911 above IP multicast address of the group. 913 Note for the Commissioning phase: the switch's 6LoWPAN/CoAP software 914 stack supports sending unicast, multicast or proxied unicast CoAP 915 requests, including processing of the multiple responses that may be 916 generated by a multicast CoAP request. 918 Light Network 919 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 920 | | | | | | | 921 | | | | | | | 922 | | *********************** | | 923 | | * User flips on * | | 924 | | * light switch to * | | 925 | | * turn on all the * | | 926 | | * lights in Room A * | | 927 | | *********************** | | 928 | | | | | | | 929 | | | | | | | 930 | | | COAP NON Mcast(PUT, | | 931 | | | Payload=lights ON) | | 932 |<-------------------------------+--------->| | | 933 ON | | | |-------------------->| 934 | | | | | |<---------| 935 | |<---------|<-------------------------------| | 936 | ON ON | | | | 937 ^ ^ ^ | | | | 938 *********************** | | | | 939 * Lights in Room-A * | | | | 940 * turn on (nearly * | | | | 941 * simultaneously) * | | | | 942 *********************** | | | | 943 | | | | | | | 945 Figure 3: Light Switch Sends Multicast Control Message 946 Light Network 947 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 948 | | | | | | | 949 | COAP NON (2.04 Changed) | | | | 950 |------------------------------->| | | | 951 | | | | | | | 952 | | | | | | | 953 | COAP NON (2.04 Changed) | | | 954 | |------------------------------------------>| | 955 | | | | | |--------->| 956 | | | | |<--------------------| 957 | | | |<---------| | | 958 | | | | | | | 959 | | COAP NON (5.00 Internal Server Error) | 960 | | |------------------------------->| | 961 | | | | | |--------->| 962 | | | | |<--------------------| 963 | | | |<---------| | | 964 | | | | | | | 966 Figure 4: Lights (Optionally) Respond to Multicast CoAP Request 968 Another, but similar, lighting control use case is shown in Figure 5. 969 In this case a controller connected to the Network Backbone sends a 970 CoAP multicast request to turn on all lights in Room-A. Every Light 971 sends back a CoAP response to the Controller after being turned on. 973 Network 974 Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller 975 | | | | | | | 976 | | | | | COAP NON Mcast(PUT, 977 | | | | | Payload=lights ON) 978 | | | | | |<-------| 979 | | | |<----------<---------| | 980 |<--------------------------------| | | | 981 ON | | | | | | 982 | |<----------<---------------------| | | 983 | ON ON | | | | 984 ^ ^ ^ | | | | 985 *********************** | | | | 986 * Lights in Room-A * | | | | 987 * turn on (nearly * | | | | 988 * simultaneously) * | | | | 989 *********************** | | | | 990 | | | | | | | 991 | | | | | | | 992 | COAP NON (2.04 Changed) | | | | 993 |-------------------------------->| | | | 994 | | | |-------------------->| | 995 | | COAP NON (2.04 Changed) | |------->| 996 | |-------------------------------->| | | 997 | | | | |--------->| | 998 | | | COAP NON (2.04 Changed) |------->| 999 | | |--------------------->| | | 1000 | | | | |--------->| | 1001 | | | | | |------->| 1002 | | | | | | | 1004 Figure 5: Controller On Backbone Sends Multicast Control Message 1006 3.5. Lighting Control in MLD Enabled Network 1008 The use case of previous section can also apply in networks where 1009 nodes support the MLD protocol [RFC3810]. The Lights then take on 1010 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 1011 Routers. In the Ethernet based network configuration, MLD may be 1012 available on all involved network interfaces. Use of MLD in the 1013 6LoWPAN based configuration is also possible, but requires MLD 1014 support in all nodes in the 6LoWPAN. In current 6LoWPAN 1015 implementations, MLD is however not supported. 1017 The resulting protocol flow is shown in Figure 6. This flow is 1018 executed after the commissioning phase, as soon as Lights are 1019 configured with a group address to listen to. The (unicast) MLD 1020 Reports may require periodic refresh activity as specified by the MLD 1021 protocol. In the figure, LL denotes Link Local communication. 1023 After the shown sequence of MLD Report messages has been executed, 1024 both Rtr-1 and Rtr-2 are automatically configured to forward 1025 multicast traffic destined to Room-A-Lights onto their connected 1026 subnet. Hence, no manual Network Configuration of routers, as 1027 previously indicated in Section 3.4, is needed anymore. 1029 Light Network 1030 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 1031 | | | | | | | 1032 | | | | | | | 1033 | | | | | | | 1034 | MLD Report: Join | | | | | 1035 | Group (Room-A-Lights) | | | | 1036 |---LL------------------------------------->| | | 1037 | | | | |MLD Report: Join | 1038 | | | | |Group (Room-A-Lights)| 1039 | | | | |---LL---->----LL---->| 1040 | | | | | | | 1041 | | MLD Report: Join | | | | 1042 | | Group (Room-A-Lights) | | | 1043 | |---LL------------------------------------->| | 1044 | | | | | | | 1045 | | | MLD Report: Join | | | 1046 | | | Group (Room-A-Lights) | | 1047 | | |---LL-------------------------->| | 1048 | | | | | | | 1049 | | | | |MLD Report: Join | 1050 | | | | |Group (Room-A-Lights)| 1051 | | | | |<--LL-----+---LL---->| 1052 | | | | | | | 1053 | | | | | | | 1055 Figure 6: Joining Lighting Groups Using MLD 1057 3.6. Commissioning the Network Based On Resource Directory 1059 This section outlines how devices in the lighting use case (both 1060 Switches and Lights) can be commissioned, making use of Resource 1061 Directory [I-D.ietf-core-resource-directory] and its group 1062 configuration feature. 1064 Once the Resource Directory (RD) is discovered, the Switches and 1065 Lights need to be discovered and their groups need to be defined. 1066 For the commissioning of these devices, a commissioning tool can be 1067 used that defines the entries in the RD. The commissioning tool has 1068 the authority to change the contents of the RD and the Light/Switch 1069 nodes. DTLS based security is used by the commissioning tool to 1070 modify operational data in RD, Switches and Lights. 1072 In our particular use case, a group of three lights is defined with 1073 one multicast address and hostname 1074 "Room-A-Lights.floor1.west.bldg6.example.com". The commissioning 1075 tool has a list of the three lights and the associated multicast 1076 address. For each light in the list the tool learns the IP address 1077 of the light and instructs the RD with three POST commands to store 1078 the endpoints associated with the three lights as prescribed by the 1079 RD specification [I-D.ietf-core-resource-directory]. Finally the 1080 commissioning tool defines the group in the RD to contain these three 1081 endpoints. Also the commissioning tool writes the multicast address 1082 in the Light endpoints with, for example, the POST /gp command 1083 discussed in Section 2.6.2.2. 1085 The light switch can discover the group in RD and thus learn the 1086 multicast address of the group. The light switch will use this 1087 address to send multicast commands to the members of the group. When 1088 the message arrives the Lights should recognize the multicast address 1089 and accept the message. 1091 4. Deployment Guidelines 1093 This section provides guidelines how IP Multicast based CoAP group 1094 communication can be deployed in various network configurations. 1096 4.1. Target Network Topologies 1098 CoAP group communication can be deployed in various network 1099 topologies. First, the target network may be a traditional IP 1100 network, or a LLN such as a 6LoWPAN network, or consist of mixed 1101 traditional/constrained network segments. Second, it may be a single 1102 subnet only or multi-subnet; e.g., multiple 6LoWPAN networks joined 1103 by a single backbone LAN. Third, a wireless network segment may have 1104 all its nodes reachable in a single IP hop (fully connected), or it 1105 may require multiple IP hops for some pairs of nodes to reach each 1106 other. 1108 Each topology may pose different requirements on the configuration of 1109 routers and protocol(s), in order to enable efficient CoAP group 1110 communication. To enable all the above target network topologies, an 1111 implementation of CoAP group communication needs to allow: 1113 1. Routing/forwarding of IP multicast packets over multiple hops 1115 2. Routing/forwarding of IP multicast packets over subnet boundaries 1116 between traditional and constrained (e.g. LLN) networks. 1118 The remainder of this section discusses solutions to enable this. 1120 4.2. Networks Using the MLD Protocol 1122 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1123 unaware of the specific multicast routing/forwarding protocol being 1124 used. When such a host needs to join a specific (CoAP) multicast 1125 group, it requires a way to signal to multicast routers which 1126 multicast traffic it wants to receive. 1128 The Multicast Listener Discovery (MLD) protocol [RFC3810] (see 1129 Appendix A) is the standard IPv6 method to achieve this; therefore 1130 this approach should be used on traditional IP networks. CoAP server 1131 nodes would then act in the role of MLD Multicast Address Listener. 1133 The guidelines from [RFC6636] on tuning of MLD for mobile and 1134 wireless networks may be useful when implementing MLD in LLNs. 1135 However, on LLNs and 6LoWPAN networks the use of MLD may not be 1136 feasible at all due to constraints on code size, memory, or network 1137 capacity. 1139 4.3. Networks Using RPL Multicast Without MLD 1141 It is assumed in this section that the MLD protocol is not 1142 implemented in a network, for example due to resource constraints. 1143 The RPL routing protocol (see Section 12 of [RFC6550]) defines the 1144 advertisement of IP multicast destinations using DAO messages and 1145 routing of multicast IP packets based on this. It requires the RPL 1146 Mode of Operation (MOP) to be 3 (Storing Mode with multicast 1147 support). 1149 Hence, RPL DAO can be used by CoAP nodes (that are also RPL routers) 1150 to advertise IP multicast group membership to parent routers. Then, 1151 the RPL protocol is used to route multicast CoAP requests over 1152 multiple hops to the correct CoAP servers. 1154 The same mechanism can be used to convey IP multicast group 1155 membership information to an edge router (e.g., 6LBR), in case the 1156 edge router is also the root of the RPL DODAG. This is useful 1157 because the edge router then learns which IP multicast traffic it 1158 needs to pass through from the backbone network into the LLN subnet. 1159 In 6LoWPAN networks, such selective "filtering" may avoid congestion 1160 of a 6LoWPAN subnet by IP multicast traffic from the traditional 1161 backbone network. 1163 4.4. Networks Using MPL Forwarding Without MLD 1165 The MPL forwarding protocol [I-D.ietf-roll-trickle-mcast] can be used 1166 for propagation of IP multicast packets to all MPL Forwarders within 1167 a predefined network domain, over multiple hops. MPL is designed to 1168 work in LLNs. In this section it is again assumed that the MLD 1169 protocol is not implemented in the network, for example due to 1170 resource limitations in an LLN. 1172 In a typical use of MPL, all nodes in an LLN are MPL Forwarders. So 1173 it would appear there is no need for CoAP servers to advertise their 1174 multicast group membership, since any IP multicast packet that enters 1175 the MPL Domain is distributed to all MPL Forwarders without regard to 1176 what multicast addresses the individual nodes are listening to. 1178 However, if an IP multicast request originates outside the MPL 1179 Domain, this request will by default not be propagated by MPL to the 1180 CoAP server(s) within the MPL Domain that need to receive it. This 1181 situation can become a problem in building control use cases. For 1182 example, in a network topology of Figure 1 where the Subnets are 1183 6LoWPAN subnets and per 6LoWPAN subnet one Realm-Local MPL Domain is 1184 defined. Suppose that the Controller Client needs to send a single 1185 CoAP multicast request to group Room-A-Lights. By default, the 1186 request would be blocked by Rtr-1 and by Rtr-2, and not enter the 1187 Realm-Local MPL Domains associated to Subnet-1 and Subnet-2. The 1188 reason is that Rtr-1 and Rtr-2 do not have the knowledge that devices 1189 in Subnet-1/2 want to listen for IP packets destined to multicast 1190 group Room-A-Lights. 1192 To solve the above issue, the following solutions could be applied: 1194 1. Extend the MPL Domain. E.g. in above example, include the 1195 Network Backbone to be part of the MPL Domain. 1197 2. Manual configuration of edge router(s) as MPL Seed(s) for 1198 specific multicast traffic. E.g. in above example, configure 1199 Rtr-1 and Rtr-2 to act as MLD Address Listeners for the 1200 Room-A-Lights multicast group. Then any received traffic from 1201 the backbone, destined to that group, would be injected into the 1202 MPL Domain that is associated to that router. Also a whitelist 1203 filtering should be enabled in these routers, to only pass 1204 through multicast traffic to configured groups such as 1205 Room-A-Lights. This would prevent unnecessarily flooding of the 1206 MPL Domain with multicast packets, which is especially important 1207 if the subnets are LLNs. 1209 3. Use an additional protocol for injection of multicast traffic 1210 from outside an MPL Domain into the MPL Domain, based on 1211 multicast group subscriptions of Forwarders within the MPL 1212 Domain. Such protocol is currently not defined in IETF and 1213 outside scope of [I-D.ietf-roll-trickle-mcast]. 1215 Concluding, MPL can be used directly in case all sources of multicast 1216 CoAP requests (CoAP clients) and also all the destinations (CoAP 1217 servers) are inside a single MPL Domain. Then, each source node acts 1218 as an MPL Seed. In all other cases, MPL can only be used with 1219 additional protocols and/or configuration. 1221 4.5. 6LoWPAN Specific Guidelines for the 6LBR 1223 To support multi-subnet scenarios for CoAP group communication, it is 1224 recommended that a 6LoWPAN Border Router (6LBR) will act in an MLD 1225 Router role on the backbone link. If this is not possible then the 1226 6LBR should be configured to act as an MLD Multicast Address Listener 1227 (see Appendix A) on the backbone link. 1229 5. Security Considerations 1231 This section describes the relevant security configuration for CoAP 1232 group communication using IP multicast. The threats to CoAP group 1233 communication are also identified and various approaches to mitigate 1234 these threats are summarized. 1236 5.1. Security Configuration 1238 As defined in [I-D.ietf-core-coap], CoAP group communication based on 1239 IP multicast: 1241 o Will operate in CoAP NoSec (No Security) mode, until a future 1242 group security solution is developed (see also Section 5.3.3). 1244 o MUST NOT use "coaps" scheme. That is, all group communication 1245 MUST use only "coap" scheme. 1247 5.2. Threats 1249 Essentially the above configuration means that there is no security 1250 at the CoAP layer for group communication. This is due to the fact 1251 that the current DTLS based approach for CoAP is exclusively unicast 1252 oriented and does not support group security features such as group 1253 key exchange and group authentication. As a direct consequence of 1254 this, CoAP group communication is vulnerable to all attacks mentioned 1255 in [I-D.ietf-core-coap] for IP multicast. 1257 5.3. Threat Mitigation 1259 The [I-D.ietf-core-coap] identifies various threat mitigation 1260 techniques for CoAP multicast. In addition to those guidelines, it 1261 is recommended that for sensitive data or safety-critical control, a 1262 combination of appropriate link-layer security and administrative 1263 control of IP multicast boundaries should be used. Some examples are 1264 given below. 1266 5.3.1. WiFi Scenario 1268 In a home automation scenario (using WiFi), the WiFi encryption 1269 should be enabled to prevent rogue nodes from joining. The Customer 1270 Premise Equipment (CPE) that enables access to the Internet should 1271 also have its multicast filters set so that it enforces multicast 1272 scope boundaries to isolate local multicast groups from the rest of 1273 the Internet (e.g., as per [RFC6092]). In addition, the domain of 1274 the IP multicast should be set to be either link-local scope or site- 1275 local scope. For site-local scope, the CPE will be an appropriate 1276 multicast scope boundary point. 1278 5.3.2. 6LoWPAN Scenario 1280 In a building automation scenario, a particular room may have a 1281 single 6LoWPAN network with a single Edge Router (6LBR). Nodes on 1282 the subnet can use link-layer encryption to prevent rogue nodes from 1283 joining. The 6LBR can be configured so that it blocks any incoming 1284 (6LoWPAN-bound) IP multicast traffic. Another example topology could 1285 be a multi-subnet 6LoWPAN in a large conference room. In this case, 1286 the backbone can implement port authentication (IEEE 802.1X) to 1287 ensure only authorized devices can join the Ethernet backbone. The 1288 access router to this secured network segment can also be configured 1289 to block incoming IP multicast traffic. 1291 5.3.3. Future Evolution 1293 In the future, to further mitigate the threats, the developing 1294 approach for DTLS-based IP multicast security for CoAP networks (see 1295 [I-D.keoh-tls-multicast-security]) or similar approaches should be 1296 considered once they mature. 1298 6. IANA Considerations 1300 6.1. New 'core.gp' Resource Type 1302 This memo registers a new resource type (rt) from the CoRE Parameters 1303 Registry called 'core.gp'. 1305 (Note to IANA/RFC Editor: This registration follows the process 1306 described in section 7.4 of [RFC6690]). 1308 Attribute Value: core.gp 1310 Description: Group Configuration resource. This resource is used to 1311 query/manage the group membership of a CoAP server. 1313 Reference: See Section 2.6.2. 1315 6.2. New 'coap-group+json' Internet Media Type 1317 This memo registers a new Internet Media Type for CoAP group 1318 configuration resource called 'application/coap-group+json'. 1320 (Note to IANA/RFC Editor: This registration follows the guidance from 1321 [RFC6839], and (last paragraph) of section 12.3 of 1322 [I-D.ietf-core-coap]. 1324 Type name: application 1325 Subtype name: coap-group+json 1327 Required parameters: None 1329 Optional parameters: None 1331 Encoding considerations: 8bit UTF-8. 1333 JSON to be represented using UTF-8 which is 8bit compatible (and most 1334 efficient for resource constrained implementations). 1336 Security considerations: 1338 Denial of Service attacks could be performed by constantly setting 1339 the group configuration resource of a CoAP endpoint to different 1340 values. This will cause the endpoint to register (or de-register) 1341 from the related IP multicast group. To prevent this it is 1342 recommended that DTLS-secured (unicast) CoAP communication be used 1343 for setting the group configuration resource. Thus only authorized 1344 clients will be allowed by a server to configure its group 1345 membership. 1347 Interoperability considerations: None 1349 Published specification: (This I-D when it becomes an RFC) 1351 Applications that use this media type: 1353 CoAP client and server implementations that wish to set/read the 1354 group configuration resource via 'application/coap-group+json' 1355 payload as described in Section 2.6.2. 1357 Additional Information: 1359 Magic number(s): None 1361 File extension(s): *.json 1363 Macintosh file type code(s): TEXT 1365 Intended usage: COMMON 1367 Restrictions on usage: None 1369 Author: CoRE WG 1371 Change controller: IETF 1373 7. Acknowledgements 1375 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1376 Castellani, Bjoern Hoehrmann, Matthias Kovatsch, Guang Lu, Salvatore 1377 Loreto, Kerry Lynn, Andrew McGregor, Dale Seed, Zach Shelby, Peter 1378 van der Stok, and Juan Carlos Zuniga for their helpful comments and 1379 discussions that have helped shape this document. 1381 8. References 1383 8.1. Normative References 1385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1386 Requirement Levels", BCP 14, RFC 2119, March 1997. 1388 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1389 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1390 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1392 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1393 Thyagarajan, "Internet Group Management Protocol, Version 1394 3", RFC 3376, October 2002. 1396 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1397 "Advanced Sockets Application Program Interface (API) for 1398 IPv6", RFC 3542, May 2003. 1400 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1401 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1403 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1404 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1405 3986, January 2005. 1407 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1408 Architecture", RFC 4291, February 2006. 1410 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1411 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1412 Protocol Specification (Revised)", RFC 4601, August 2006. 1414 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1415 "Transmission of IPv6 Packets over IEEE 802.15.4 1416 Networks", RFC 4944, September 2007. 1418 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1419 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1420 March 2010. 1422 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1423 Customer Premises Equipment (CPE) for Providing 1424 Residential IPv6 Internet Service", RFC 6092, January 1425 2011. 1427 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1428 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1429 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1430 Lossy Networks", RFC 6550, March 2012. 1432 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1433 the Internet Group Management Protocol (IGMP) and 1434 Multicast Listener Discovery (MLD) for Routers in Mobile 1435 and Wireless Networks", RFC 6636, May 2012. 1437 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1438 Format", RFC 6690, August 2012. 1440 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1441 "Neighbor Discovery Optimization for IPv6 over Low-Power 1442 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1443 November 2012. 1445 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 1446 Structured Syntax Suffixes", RFC 6839, January 2013. 1448 [I-D.ietf-core-coap] 1449 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1450 Application Protocol (CoAP)", draft-ietf-core-coap-18 1451 (work in progress), June 2013. 1453 8.2. Informative References 1455 [I-D.ietf-core-block] 1456 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1457 draft-ietf-core-block-12 (work in progress), June 2013. 1459 [I-D.vanderstok-core-dna] 1460 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1461 Naming, and Addressing", draft-vanderstok-core-dna-02 1462 (work in progress), July 2012. 1464 [I-D.ietf-roll-trickle-mcast] 1465 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1466 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1467 mcast-05 (work in progress), August 2013. 1469 [I-D.keoh-tls-multicast-security] 1470 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 1471 Security for Low-Power and Lossy Networks (LLNs)", draft- 1472 keoh-tls-multicast-security-00 (work in progress), October 1473 2012. 1475 [I-D.ietf-core-resource-directory] 1476 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1477 Directory", draft-ietf-core-resource-directory-00 (work in 1478 progress), June 2013. 1480 [I-D.ietf-appsawg-uri-get-off-my-lawn] 1481 Nottingham, M., "Standardising Structure in URIs", draft- 1482 ietf-appsawg-uri-get-off-my-lawn-00 (work in progress), 1483 September 2013. 1485 Appendix A. Multicast Listener Discovery (MLD) 1487 In order to extend the scope of IP multicast beyond link-local scope, 1488 an IP multicast routing or forwarding protocol has to be active in 1489 routers on an LLN. To achieve efficient multicast routing (i.e., 1490 avoid always flooding IP multicast packets), routers have to learn 1491 which hosts need to receive packets addressed to specific IP 1492 multicast destinations. 1494 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1495 IPv4 equivalent IGMP [RFC3376]) is today the method of choice used by 1496 an (IP multicast enabled) router to discover the presence of 1497 multicast listeners on directly attached links, and to discover which 1498 multicast addresses are of interest to those listening nodes. MLD 1499 was specifically designed to cope with fairly dynamic situations in 1500 which multicast listeners may join and leave at any time. 1502 [RFC6636] discusses optimal tuning of the parameters of MLD/IGMP for 1503 routers for mobile and wireless networks. These guidelines may be 1504 useful when implementing MLD in LLNs. 1506 Appendix B. Change Log 1508 [Note to RFC Editor: Please remove this section before publication.] 1510 Changes from ietf-15 to ietf-16: 1512 o In section 2.6.2, changed DELETE in group management interface to 1513 a PUT with empty JSON array to clear the list (#345). 1515 o In section 2.6.2, aligned the syntax for IP addresses to follow 1516 RFC 3986 URI syntax, which is also used by coap-18. This allows 1517 re-use of the parsing code for CoAP URIs for this purpose (#342). 1519 o Addressed some more editorial comments provided by Carsten Bormann 1520 in preparation for WGLC. 1522 o Various editorial updates for improved readability. 1524 Changes from ietf-14 to ietf-15: 1526 o In section 2.2, provided guidance on how implementers should parse 1527 URIs for group communication (#339). 1529 o In section 2.6.2.1, specified that for group membership 1530 configuration interface the "ip" (i.e. "a" parameter) key/value is 1531 not required when it is unknown (#338). 1533 o In section 2.6.2.1, specified that for group membership 1534 configuration interface the port configuration be defaulted to 1535 standard CoAP port 5683, and if not default then should follow 1536 standard notation (#340). 1538 o In section 2.6.2.1, specified that notation of IP address in group 1539 membership configuration interface should follow standard notation 1540 (#342). 1542 o In section 6.2, "coap-group+json" Media Type encoding simplified 1543 to just support UTF-8 (and not UTF-16 and UTF-32) (#344). 1545 o Various editorial updates for improved readability. 1547 Changes from ietf-13 to ietf-14: 1549 o Update to address final editorial comments from the Chair's review 1550 (by Carsten Bormann) of the draft. This included restructuring of 1551 Section 2.6 (Configuring Group Memberships) and Section 4 1552 (Deployment Guidelines) to make it easier to read. Also various 1553 other editorial changes. 1555 o Changed "ip" field to "a" in Section 2.6 (#337) 1557 Changes from ietf-12 to ietf-13: 1559 o Extensive editorial updates due to comments from the Chair's 1560 review (by Carsten Bormann) of the draft. The best way to see the 1561 changes will be to do a -Diff with Rev. 12. 1563 o The technical comments from the Chair's review will be addressed 1564 in a future revision after tickets are generated and the solutions 1565 are agreed to on the WG E-mail list. 1567 Changes from ietf-11 to ietf-12: 1569 o Removed reference to "CoAP Ping" in Section 3.5 (Group Member 1570 Discovery) and replaced it with the more efficient support of 1571 discovery of groups and group members via the CORE RD as suggested 1572 by Zach Shelby. 1574 o Various editorial updates for improved readability. 1576 Changes from ietf-10 to ietf-11: 1578 o Added text to section 3.8 (Congestion Control) to clarify that a 1579 "CoAP client sending a multicast CoAP request to /.well-known/core 1580 SHOULD support core-block" (#332). 1582 o Various editorial updates for improved readability. 1584 Changes from ietf-09 to ietf-10: 1586 o Various editorial updates including: 1588 o Added a fourth option in section 3.3 on ways to obtain the URI 1589 path for a group request. 1591 o Clarified use of content format in GET/PUT requests for 1592 Configuring Group Membership in Endpoints (in section 3.6). 1594 o Changed reference "draft-shelby-core-resource-directory" to 1595 "draft-ietf-core-resource-directory". 1597 o Clarified (in section 3.7) that ACKs are never used for a 1598 multicast request (from #296). 1600 o Clarified (in section 5.2/5.2.3) that MPL does not support group 1601 membership advertisement. 1603 o Adding introductory paragraph to Scope (section 2.2). 1605 o Wrote out fully the URIs in table section 3.2. 1607 o Reworded security text in section 7.2 (New Internet Media Type) to 1608 make it consistent with section 3.6 (Configuring Group 1609 Membership). 1611 o Fixed formatting of hyperlinks in sections 6.3 and 7.2. 1613 Changes from ietf-08 to ietf-09: 1615 o Cleaned up requirements language in general. Also, requirements 1616 language are now only used in section 3 (Protocol Considerations) 1617 and section 6 (Security Considerations). Requirements language 1618 has been removed from other sections to keep them to a minimum 1619 (#271). 1621 o Addressed final comment from Peter van der Stok to define what "IP 1622 stack" meant (#296). Following the lead of CoAP-17, we know refer 1623 instead to "APIs such as IPV6_RECVPKTINFO [RFC3542]". 1625 o Changed text in section 3.4 (Group Methods) to allow multicast 1626 POST under specific conditions and highlighting the risks with 1627 using it (#328). 1629 o Various editorial updates for improved readability. 1631 Changes from ietf-07 to ietf-08: 1633 o Updated text in section 3.6 (Configuring Group Membership in 1634 Endpoints) to make it more explicit that the Internet Media Type 1635 is used in the processing rules (#299). 1637 o Addressed various comments from Peter van der Stok (#296). 1639 o Various editorial updates for improved readability including 1640 defining all acronyms. 1642 Changes from ietf-06 to ietf-07: 1644 o Added an IANA request (in section 7.2) for a dedicated content- 1645 format (Internet Media type) for the group management JSON format 1646 called 'application/coap-group+json' (#299). 1648 o Clarified semantics (in section 3.6) of group management JSON 1649 format (#300). 1651 o Added details of IANA request (in section 7.1) for a new CORE 1652 Resource Type called 'core.gp'. 1654 o Clarified that DELETE method (in section 3.6) is also a valid 1655 group management operation. 1657 o Various editorial updates for improved readability. 1659 Changes from ietf-05 to ietf-06: 1661 o Added a new section on commissioning flow when using discovery 1662 services when end devices discover in which multicast group they 1663 are allocated (#295). 1665 o Added a new section on CoAP Proxy Operation (section 3.9) that 1666 outlines the potential issues and limitations of doing CoAP 1667 multicast requests via a CoAP Proxy (#274). 1669 o Added use case of multicasting controller on the backbone (#279). 1671 o Use cases were updated to show only a single CoAP RD (to replace 1672 the previous multiple RDs with one in each subnet). This is a 1673 more efficient deployment and also avoids RD specific issues such 1674 as synchronization of RD information between serves (#280). 1676 o Added text to section 3.6 (Configuring Group Membership in 1677 Endpoints) that clarified that any (unicast) operation to change 1678 an endpoint's group membership must use DTLS-secured CoAP. 1680 o Clarified relationship of this document to [I-D.ietf-core-coap] in 1681 section 2.2 (Scope). 1683 o Removed IPSec related requirement, as IPSec is not part of 1684 [I-D.ietf-core-coap] anymore. 1686 o Editorial reordering of subsections in section 3 to have a better 1687 flow of topics. Also renamed some of the (sub)sections to better 1688 reflect their content. Finally, moved the URI Configuration text 1689 to the same section as the Port Configuration section as it was a 1690 more natural grouping (now in section 3.3) . 1692 o Editorial rewording of section 3.7 (Multicast Request Acceptance 1693 and Response Suppression) to make the logic easier to comprehend 1694 (parse). 1696 o Various editorial updates for improved readability. 1698 Changes from ietf-04 to ietf-05: 1700 o Added a new section 3.9 (Exceptions) that highlights that IP 1701 multicast (and hence group communication) is not always available 1702 (#187). 1704 o Updated text on the use of [RFC2119] language (#271) in Section 1. 1706 o Included guidelines on when (not) to use CoAP responses to 1707 multicast requests and when (not) to accept multicast requests 1708 (#273). 1710 o Added guideline on use of core-block for minimizing response size 1711 (#275). 1713 o Restructured section 6 (Security Considerations) to more fully 1714 describe threats and threat mitigation (#277). 1716 o Clearly indicated that DNS resolution and reverse DNS lookup are 1717 optional. 1719 o Removed confusing text about a single group having multiple IP 1720 addresses. If multiple IP addresses are required then multiple 1721 groups (with the same members) should be created. 1723 o Removed repetitive text about the fact that group communication is 1724 not guaranteed. 1726 o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP 1727 Multicast Routing Background) and added link to section 5.2 1728 (Advertising Membership of Multicast Groups). 1730 o Clarified text in section 3.8 (Congestion Control) regarding 1731 precedence of use of IP multicast domains (i.e. first try to use 1732 link-local scope, then site-local scope, and only use global IP 1733 multicast as a last resort). 1735 o Extended group resource manipulation guidelines with use of pre- 1736 configured ports/paths for the multicast group. 1738 o Consolidated all text relating to ports in a new section 3.3 (Port 1739 Configuration). 1741 o Clarified that all methods (GET/PUT/POST) for configuring group 1742 membership in endpoints should be unicast (and not multicast) in 1743 section 3.7 (Configuring Group Membership In Endpoints). 1745 o Various editorial updates for improved readability, including 1746 editorial comments by Peter van der Stok to WG list of December 1747 18th, 2012. 1749 Changes from ietf-03 to ietf-04: 1751 o Removed section 2.3 (Potential Solutions for Group Communication) 1752 as it is purely background information and moved section to draft- 1753 dijk-core-groupcomm-misc (#266). 1755 o Added reference to draft-keoh-tls-multicast-security to section 6 1756 (Security Considerations). 1758 o Removed Appendix B (CoAP-Observe Alternative to Group 1759 Communications) as it is as an alternative to IP Multicast that 1760 the WG has not adopted and moved section to draft-dijk-core- 1761 groupcomm-misc (#267). 1763 o Deleted section 8 (Conclusions) as it is redundant (#268). 1765 o Simplified light switch use case (#269) by splitting into basic 1766 operations and additional functions (#269). 1768 o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) 1769 to draft-dijk-core-groupcomm-misc (#270). 1771 o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) 1772 to draft-dijk-core-groupcomm-misc as these sections essentially 1773 just repeated text from other drafts regarding DNS based features. 1774 Clarified remaining text in this draft relating to DNS based 1775 features to clearly indicate that these features are optional 1776 (#272). 1778 o Focus section 3.5 (Configuring Group Membership) on a single 1779 proposed solution. 1781 o Scope of section 5.3 (Use of MLD) widened to multicast destination 1782 advertisement methods in general. 1784 o Rewrote section 2.2 (Scope) for improved readability. 1786 o Moved use cases that are not addressed to draft-dijk-core- 1787 groupcomm-misc. 1789 o Various editorial updates for improved readability. 1791 Changes from ietf-02 to ietf-03: 1793 o Clarified that a group resource manipulation may return back a 1794 mixture of successful and unsuccessful responses (section 3.4 and 1795 Figure 6) (#251). 1797 o Clarified that security option for group communication must be 1798 NoSec mode (section 6) (#250). 1800 o Added mechanism for group membership configuration (#249). 1802 o Removed IANA request for multicast addresses (section 7) and 1803 replaced with a note indicating that the request is being made in 1804 [I-D.ietf-core-coap] (#248). 1806 o Made the definition of 'group' more specific to group of CoAP 1807 endpoints and included text on UDP port selection (#186). 1809 o Added explanatory text in section 3.4 regarding why not to use 1810 group communication for non-idempotent messages (i.e. CoAP POST) 1811 (#186). 1813 o Changed link-local RD discovery to site-local in RD discovery use 1814 case to make it more realistic. 1816 o Fixed lighting control use case CoAP proxying; now returns 1817 individual CoAP responses as in coap-12. 1819 o Replaced link format I-D with RFC6690 reference. 1821 o Various editorial updates for improved readability 1823 Changes from ietf-01 to ietf-02: 1825 o Rewrote congestion control section based on latest CoAP text 1826 including Leisure concept (#188) 1828 o Updated the CoAP/HTTP interworking section and example use case 1829 with more details and use of MLD for multicast group joining 1831 o Key use cases added (#185) 1833 o References to [I-D.vanderstok-core-dna] and draft-castellani-core- 1834 advanced-http-mapping added 1836 o Moved background sections on "MLD" and "CoAP-Observe" to 1837 Appendices 1839 o Removed requirements section (and moved it to draft-dijk-core- 1840 groupcomm-misc) 1842 o Added details for IANA request for group communication multicast 1843 addresses 1845 o Clarified text to distinguish between "link local" and general 1846 multicast cases 1848 o Moved lengthy background section 5 to draft-dijk-core-groupcomm- 1849 misc and replaced with a summary 1851 o Various editorial updates for improved readability 1853 o Change log added 1854 Changes from ietf-00 to ietf-01: 1856 o Moved CoAP-observe solution section to section 2 1858 o Editorial changes 1860 o Moved security requirements into requirements section 1862 o Changed multicast POST to PUT in example use case 1864 o Added CoAP responses in example use case 1866 Changes from rahman-07 to ietf-00: 1868 o Editorial changes 1870 o Use cases section added 1872 o CoRE Resource Directory section added 1874 o Removed section 3.3.5. IP Multicast Transmission Methods 1876 o Removed section 3.4 Overlay Multicast 1878 o Removed section 3.5 CoAP Application Layer Group Management 1880 o Clarified section 4.3.1.3 RPL Routers with Non-RPL Hosts case 1882 o References added and some normative/informative status changes 1884 Authors' Addresses 1886 Akbar Rahman (editor) 1887 InterDigital Communications, LLC 1889 Email: Akbar.Rahman@InterDigital.com 1891 Esko Dijk (editor) 1892 Philips Research 1894 Email: esko.dijk@philips.com