idnits 2.17.00 (12 Aug 2021) /tmp/idnits39594/draft-ietf-core-groupcomm-19.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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2014) is 2894 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: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: draft-ietf-core-block has been published as RFC 7959 == Outdated reference: draft-ietf-roll-trickle-mcast has been published as RFC 7731 == Outdated reference: A later version (-08) exists of draft-keoh-dice-multicast-security-07 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: draft-ietf-appsawg-uri-get-off-my-lawn has been published as RFC 7320 Summary: 2 errors (**), 0 flaws (~~), 8 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: December 19, 2014 Philips Research 6 June 17, 2014 8 Group Communication for CoAP 9 draft-ietf-core-groupcomm-19 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 December 19, 2014. 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 5 63 2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5 64 2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6 65 2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7 66 2.4. RESTful Methods . . . . . . . . . . . . . . . . . . . . . 8 67 2.5. Request and Response Model . . . . . . . . . . . . . . . 9 68 2.6. Member Discovery . . . . . . . . . . . . . . . . . . . . 10 69 2.7. Membership Configuration . . . . . . . . . . . . . . . . 10 70 2.7.1. Background . . . . . . . . . . . . . . . . . . . . . 10 71 2.7.2. Membership Configuration RESTful Interface . . . . . 10 72 2.8. Request Acceptance and Response Suppression Rules . . . . 15 73 2.9. Congestion Control . . . . . . . . . . . . . . . . . . . 17 74 2.10. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 18 75 2.11. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 20 76 3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 20 77 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20 78 3.2. Network Configuration . . . . . . . . . . . . . . . . . . 20 79 3.3. Discovery of Resource Directory . . . . . . . . . . . . . 22 80 3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 24 81 3.5. Lighting Control in MLD Enabled Network . . . . . . . . . 28 82 3.6. Commissioning the Network Based On Resource Directory . . 29 83 4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 30 84 4.1. Target Network Topologies . . . . . . . . . . . . . . . . 30 85 4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 31 86 4.3. Networks Using RPL Multicast Without MLD . . . . . . . . 31 87 4.4. Networks Using MPL Forwarding Without MLD . . . . . . . . 32 88 4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 33 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 90 5.1. Security Configuration . . . . . . . . . . . . . . . . . 33 91 5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 34 92 5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 34 93 5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 34 94 5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 34 95 5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 35 96 5.4. Pervasive Monitoring Considerations . . . . . . . . . . . 35 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 99 6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 36 100 6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 36 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 104 8.2. Informative References . . . . . . . . . . . . . . . . . 39 105 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 40 106 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 40 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 109 1. Introduction 111 1.1. Background 113 Constrained Application Protocol (CoAP) is a Representational State 114 Transfer (REST) based web transfer protocol for resource constrained 115 devices operating in an IP network [I-D.ietf-core-coap]. CoAP has 116 many similarities to HTTP [RFC2616] but also has some key 117 differences. Constrained devices can be large in numbers, but are 118 often related to each other in function or by location. For example, 119 all the light switches in a building may belong to one group and all 120 the thermostats may belong to another group. Groups may be pre- 121 configured before deployment or dynamically formed during operation. 122 If information needs to be sent to or received from a group of 123 devices, group communication mechanisms can improve efficiency and 124 latency of communication and reduce bandwidth requirements for a 125 given application. HTTP does not support any equivalent 126 functionality to CoAP group communication. 128 1.2. Scope 130 Group communication involves a one-to-many relationship between CoAP 131 endpoints. Specifically, a single CoAP client can simultaneously get 132 (or set) resources from multiple CoAP servers using CoAP over IP 133 multicast. An example would be a CoAP light switch turning on/off 134 multiple lights in a room with a single CoAP group communication PUT 135 request, and handling the potential multitude of (unicast) responses. 137 The normative protocol aspects of sending CoAP requests on top of IP 138 multicast, and processing the (unicast IP) responses are given in 139 Section 8 of [I-D.ietf-core-coap]. The main contribution of this 140 document lies in providing additional guidance for key CoAP group 141 communication concepts. Among the topics covered are group 142 definition, group RESTful methods, and group request and response 143 processing (see Section 2). Also, proxy operation and minimizing 144 network congestion for group communication is discussed (see 145 Section 2). Finally, specific use cases (see Section 3) and 146 deployment guidelines (see Section 4) for group communication are 147 outlined. 149 1.3. Conventions and Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 [RFC2119]. 156 The above key words are used to establish a set of guidelines for 157 CoAP group communication. An implementation of CoAP group 158 communication MAY implement these guidelines; an implementation 159 claiming compliance to this document MUST implement the set of 160 guidelines. 162 This document assumes readers are familiar with the terms and 163 concepts that are used in [I-D.ietf-core-coap]. In addition, this 164 document defines the following terminology: 166 Group Communication 167 A source node sends a single application layer (e.g. CoAP) 168 message which is delivered to multiple destination nodes, where 169 all destinations are identified to belong to a specific group. 170 The source node itself may be part of the group. The underlying 171 mechanisms for CoAP group communication are UDP/IP multicast for 172 the requests, and unicast UDP/IP for the responses. The network 173 involved may be a constrained network such as a low-power, lossy 174 network. 176 Reliable Group Communication 177 A special case of group communication where for each destination 178 node it is guaranteed that the node either 1) eventually receives 179 the message sent by the source node, or 2) does not receive the 180 message and the source node is notified of the non-reception 181 event. 183 Multicast 184 Sending a message to multiple destination nodes with one network 185 invocation. There are various options to implement multicast 186 including layer 2 (Media Access Control) and layer 3 (IP) 187 mechanisms. 189 IP Multicast 190 A specific multicast approach based on the use of IP multicast 191 addresses as defined in "IANA Guidelines for IPv4 Multicast 192 Address Assignments" [RFC5771] and "IP Version 6 Addressing 193 Architecture" [RFC4291]. A complete IP multicast solution may 194 include support for managing group memberships, and IP multicast 195 routing/forwarding (see Section 2.1). 197 Low power and Lossy Network (LLN) 198 A type of constrained IP network where devices are interconnected 199 by low-power and lossy links. The links may be may composed of 200 one or more technologies such as IEEE 802.15.4, Bluetooth Low 201 Energy (BLE), Digital Enhanced Cordless Telecommunication (DECT), 202 and IEEE P1901.2 power-line communication. 204 2. Protocol Considerations 206 2.1. IP Multicast Background 208 IP multicast protocols have been evolving for decades, resulting in 209 standards such as Protocol Independent Multicast - Sparse Mode (PIM- 210 SM) [RFC4601]. IP multicast is very popular in specific deployments 211 such as in enterprise networks (e.g., for video conferencing), smart 212 home networks (e.g., Universal Plug and Play (UPnP)) and carrier IPTV 213 deployments. The packet economy and minimal host complexity of IP 214 multicast make it attractive for group communication in constrained 215 environments. 217 To achieve IP multicast beyond link-local scope, an IP multicast 218 routing or forwarding protocol needs to be active on IP routers. An 219 example of a routing protocol specifically for LLNs is the IPv6 220 Routing Protocol for Low-Power and Lossy Networks (RPL) (Section 12 221 of [RFC6550]) and an example of a forwarding protocol for LLNs is 222 Multicast Protocol for Low power and Lossy Networks (MPL) 223 [I-D.ietf-roll-trickle-mcast]. RPL and MPL do not depend on each 224 other; each can be used in isolation and both can be used in 225 combination in a network. Finally, PIM-SM [RFC4601] is often used 226 for multicast routing in traditional IP networks (i.e. networks that 227 are not constrained). 229 IP multicast can also be run in a Link-Local (LL) scope. This means 230 that there is no routing involved and an IP multicast message is only 231 received over the link on which it was sent. 233 For a complete IP multicast solution, in addition to a routing/ 234 forwarding protocol, a "listener" protocol may be needed for the 235 devices to subscribe to groups (see Section 4.2). 237 IP multicast is generally classified as an unreliable service in that 238 packets are not guaranteed to be delivered to each and every member 239 of the group. In other words, it cannot be directly used as a basis 240 for "reliable group communication" as defined in Section 1.3. 241 However, the level of reliability can be increased by employing a 242 multicast protocol that performs periodic retransmissions as is done 243 for example in MPL. 245 2.2. Group Definition and Naming 247 A CoAP group is defined as a set of CoAP endpoints, where each 248 endpoint is configured to receive CoAP group communication requests 249 that are sent to the group's associated IP multicast address. The 250 individual response by each endpoint receiver to a CoAP group 251 communication request is always sent back as unicast. An endpoint 252 may be a member of multiple groups. Group membership of an endpoint 253 may dynamically change over time. 255 All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast 256 group ([I-D.ietf-core-coap], Section 12.8) by default to enable CoAP 257 discovery. For IPv4, the address is 224.0.1.187 and for IPv6 a 258 server node joins at least both the link-local scoped address 259 FF02::FD and the site-local scoped address FF05::FD. IPv6 addresses 260 of other scopes MAY be enabled. 262 A CoAP group URI has the scheme 'coap' and includes in the authority 263 part either a group IP multicast address, or a hostname (e.g., Group 264 Fully Qualified Domain Name (FQDN)) that can be resolved to the group 265 IP multicast address. A group URI also contains an optional CoAP 266 port number in the authority part. Group URIs follow the regular 267 CoAP URI syntax [I-D.ietf-core-coap]. 269 Note: A group URI is needed to initiate CoAP group communications. 270 For CoAP implementations it is recommended to use the URI composition 271 method of Section 6.5 of [I-D.ietf-core-coap] in such way that, from 272 a group URI, a CoAP group communication request is generated. 274 For sending nodes, it is recommended to use the IP multicast address 275 literal in a group URI. However, in case a group hostname is used, 276 it can be uniquely mapped to an IP multicast address via DNS 277 resolution (if supported). Some examples of hierarchical group FQDN 278 naming (and scoping) for a building control application are shown 279 below: 281 URI authority Targeted group of nodes 282 --------------------------------------- -------------------------- 283 all.bldg6.example.com "all nodes in building 6" 284 all.west.bldg6.example.com "all nodes in west wing, 285 building 6" 286 all.floor1.west.bldg6.example.com "all nodes in floor 1, 287 west wing, building 6" 288 all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036, 289 floor1, west wing, 290 building 6" 292 Similarly, if supported, reverse mapping (from IP multicast address 293 to Group FQDN) is possible using the reverse DNS resolution technique 294 ([RFC1033]). Reverse mapping is important, for example, in trouble 295 shooting to translate IP multicast addresses back to human readable 296 hostnames to show in a diagnostics user interface. 298 2.3. Port and URI Configuration 300 A CoAP server that is a member of a group listens for CoAP messages 301 on the group's IP multicast address, on a specified UDP port. The 302 default UDP port is the CoAP default port 5683 but a non-default UDP 303 port MAY be specified for the group; in which case implementers MUST 304 ensure that all group members are configured to use this same port. 305 These rules imply that different ports (for the same IP multicast 306 address) cannot be used to specify different CoAP groups. 308 CoAP group communication will not work if there is diversity in the 309 authority port (e.g., different dynamic port addresses across the 310 group) or if other parts of the group URI such as the path, or the 311 query, differ on different endpoints. Therefore, some measures must 312 be present to ensure uniformity in port number and resource names/ 313 locations within a group. All CoAP group communication requests MUST 314 be sent using a port number according to one of below options: 316 1. A pre-configured port number. The pre-configuration mechanism 317 MUST ensure that the same port number is pre-configured across 318 all endpoints in a group and across all CoAP clients performing 319 the group requests. 321 2. If the client is configured to use service discovery including 322 port discovery, it uses a port number obtained via a service 323 discovery lookup operation for the targeted CoAP group. 325 3. Use the default CoAP UDP port (5683). 327 For a CoAP server node that supports resource discovery, the default 328 port 5683 MUST be supported (Section 7.1 of [I-D.ietf-core-coap]) for 329 the "All CoAP Nodes" group. 331 All CoAP group communication requests SHOULD operate on group URI 332 paths in one of the following ways: 334 1. Pre-configured group URI paths, if available. The pre- 335 configuration mechanism SHOULD ensure that these paths are pre- 336 configured across all CoAP servers in a group and all CoAP 337 clients performing the group requests. Note that 338 [I-D.ietf-appsawg-uri-get-off-my-lawn] prescribes that any 339 specification must not constrain, define structure or semantics 340 for any path component. 342 2. If the client is configured to use default CoRE resource 343 discovery, it uses URI paths retrieved from a "/.well-known/core" 344 lookup on a group member. The URI paths the client will use MUST 345 be known to be available also in all other endpoints in the 346 group. The URI path configuration mechanism on servers MUST 347 ensure that these URIs (identified as being supported by the 348 group) are configured on all group endpoints. 350 3. If the client is configured to use another form of service 351 discovery, it uses group URI paths from an equivalent service 352 discovery lookup which returns the resources supported by all 353 group members. 355 4. If the client has received a group URI through a previous RESTful 356 interaction with a trusted server it can use this URI in a CoAP 357 group communication request. For example, a commissioning tool 358 may instruct a sensor device in this way to which target group 359 (group URI) it should report sensor events. 361 2.4. RESTful Methods 363 Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD 364 be used for group communication, with one exception as follows. A 365 non-idempotent CoAP method (i.e., POST) MAY be used for group 366 communication if the resource being POSTed to has been designed to 367 cope with the unreliable and lossy nature of IP multicast. Note that 368 not all group members are guaranteed to receive the IP multicast 369 request, and the sender cannot readily find out which group members 370 did not receive it. 372 2.5. Request and Response Model 374 All CoAP requests that are sent via IP multicast MUST be Non- 375 confirmable. The Message ID in an IP multicast CoAP message is used 376 for optional message deduplication as detailed in Section 4.5 of 377 [I-D.ietf-core-coap]. 379 A server MAY send back a unicast response to the CoAP group 380 communication request (e.g., response "2.05 Content" to a group GET 381 request). The unicast responses received by the CoAP client may be a 382 mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not 383 Found) codes depending on the individual server processing results. 384 Detailed processing rules for IP multicast request acceptance and 385 unicast response suppression are given in Section 2.8. 387 A CoAP request sent over IP multicast and any unicast response it 388 causes must take into account the congestion control rules defined in 389 Section 2.9. 391 The CoAP client can distinguish the origin of multiple server 392 responses by source IP address of the UDP message containing the CoAP 393 response, or any other available unique identifier (e.g. contained in 394 the CoAP payload). In case a CoAP client sent multiple group 395 requests, the responses are as usual matched to a request using the 396 CoAP Token. 398 For multicast CoAP requests there are additional constraints on the 399 re-use of Token values, compared to the unicast case. In the unicast 400 case, receiving a response effectively frees up its Token value for 401 re-use since no more responses will follow. However, for multicast 402 CoAP the number of responses is not bounded a-priori. Therefore the 403 reception of a response cannot be used as a trigger to "free up" a 404 Token value for re-use. Re-using a Token value too early could lead 405 to protocol error i.e. a wrong response/request matching in the 406 client. Therefore the time between re-use of Token values (for Token 407 values used in multicast requests) must be at least: 409 NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY 411 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 412 [I-D.ietf-core-coap]. MAX_SERVER_RESPONSE_DELAY is defined here as 413 the expected maximum response delay over all servers that the client 414 can send a multicast request to. This delay includes the maximum 415 Leisure time period as defined in Section 8.2 of 416 [I-D.ietf-core-coap]. Using the CoAP default protocol parameters the 417 re-use time becomes at least 250 seconds, but may need to be much 418 longer in practice since there is no time limit defined in CoAP for 419 generation of responses by a server. 421 2.6. Member Discovery 423 CoAP Groups, and the membership of these groups, can be discovered 424 via the lookup interfaces in the Resource Directory (RD) defined in 425 [I-D.ietf-core-resource-directory]. An example of doing some of 426 these RD lookups is given in Section 3.6. 428 2.7. Membership Configuration 430 2.7.1. Background 432 The group membership of a CoAP endpoint may be configured in one of 433 the following ways. First, the group membership may be pre- 434 configured before node deployment. Second, a node may be programmed 435 to discover (query) its group membership using a specific service 436 discovery means. Third, it may be configured by another node (e.g., 437 a commissioning device). 439 In the first case, the pre-configured group information may be either 440 an IP multicast address or a hostname (FQDN) which is resolved later 441 (during operation) to an IP multicast address by the endpoint using 442 DNS (if supported). 444 For the second case, a CoAP endpoint may look up its group membership 445 using techniques such as DNS-SD and Resource Directory 446 [I-D.ietf-core-resource-directory]. The latter case is detailed more 447 in Section 3.6. 449 In the third case, typical in scenarios such as building control, a 450 dynamic commissioning tool determines to which group a sensor or 451 actuator node belongs, and writes this information to the node, which 452 can subsequently join the correct IP multicast group on its network 453 interface. The information written may again be an IP multicast 454 address or a hostname. 456 2.7.2. Membership Configuration RESTful Interface 458 To achieve better interoperability between endpoints from different 459 manufacturers, an OPTIONAL CoAP membership configuration RESTful 460 interface for configuring endpoints with relevant group information 461 is described here. This interface provides a solution for the third 462 case mentioned above. To access this interface a client MUST use 463 unicast CoAP methods (GET/PUT/POST/DELETE) only as it is a method of 464 configuring group information in individual endpoints. 466 Also, a form of authorization (making use of DTLS-secured CoAP 467 [I-D.ietf-core-coap]) SHOULD be used such that only authorized 468 controllers are allowed by an endpoint to configure its group 469 membership. 471 It is important to note that other approaches may be used to 472 configure CoAP endpoints with relevant group information. These 473 alternate approaches may support a subset or superset of the 474 membership configuration RESTful interface described in this 475 document. For example, a simple interface to just read the endpoint 476 group information may be implemented via a classical Management 477 Information Base (MIB) approach (e.g. following approach of 478 [RFC3433]). 480 2.7.2.1. CoAP-Group Resource Type and Media Type 482 CoAP endpoints implementing the membership configuration RESTful 483 interface MUST support the CoAP group configuration Internet Media 484 Type "application/coap-group+json" (Section 6.2). 486 A resource offering this representation can be annotated for direct 487 discovery [RFC6690] using the resource type (rt) "core.gp" where "gp" 488 is shorthand for "group" (Section 6.1). An authorized client uses 489 this media type to query/manage group membership of a CoAP endpoint 490 as defined in the following subsections. 492 The group configuration resource and its sub-resources have a JSON- 493 based content format (as indicated by the "application/coap- 494 group+json" media type). The resource includes zero or more group 495 membership JSON objects in a format as defined in Section 2.7.2.4. A 496 group membership JSON object contains one or more key/value pairs as 497 defined below. It represents a single IP multicast group membership 498 for the CoAP endpoint. 500 Examples of four different group membership objects are: 502 { "n": "All-Devices.floor1.west.bldg6.example.com", 503 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 505 { "n": "sensors.floor2.east.bldg6.example.com" } 507 { "n": "coap-test", 508 "a": "224.0.1.187:56789" } 510 { "a": "[ff15::c0a7:15:c00l]" } 512 The OPTIONAL "n" key/value pair stands for "name" and identifies the 513 group with a hostname, for example a FQDN. The OPTIONAL "a" key/ 514 value pair specifies the IP multicast address (and optionally the 515 port number) of the group. It contains an IPv4 address (in dotted 516 decimal notation) or an IPv6 address. The following ABNF rule can be 517 used for parsing the address, referring to the definitions in 518 Section 6 of [I-D.ietf-core-coap] and [RFC3986]. 520 group-address = IPv4address [ ":" port ] 521 / "[" IPv6address "]" [":" port ] 523 If the port number is not provided then it is assumed to be the 524 default CoAP port (5683). In a response, the "a" key/value pair 525 SHOULD be included if the IP address is known at the time of 526 generating the response, and MUST NOT be included if unknown. If the 527 "a" value is not provided in a request, the "n" value in the same 528 group membership object SHOULD be a valid hostname with optional port 529 number that can be translated to an IP multicast address via DNS 530 resolution, as follows: 532 group-name = host [ ":" port ] 534 If the port number is not provided then it is assumed to be the 535 default CoAP port (5683). At least one of the "n"/"a" pairs MUST be 536 given per group object. 538 After any change on a Group configuration resource, the endpoint MUST 539 effect registration/de-registration from the corresponding IP 540 multicast group(s) as soon as possible. 542 2.7.2.2. Creating a new multicast group membership (POST) 544 Method: POST 545 URI Template: /{+gp} 546 Location-URI Template: /{+gp}/{index} 547 URI Template Variables: 548 gp - Group Configuration Function Set path (mandatory). 549 index - Group index, SHOULD be a string of 1 or 2 alphanumerical 550 characters. It MUST be generated as locally unique. 552 Example: 553 Req: POST /coap-group 554 Content-Format: application/coap-group+json 555 { "n": "All-Devices.floor1.west.bldg6.example.com", 556 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 557 Res: 2.01 Created 558 Location-Path: /coap-group/12 560 For the 'gp' variable it is recommended to use the path "coap-group" 561 by default. If the "a" key/value pair is given, this takes priority 562 and the "n" pair becomes informational. If only the "n" pair is 563 given, the CoAP endpoint may perform DNS resolution (if supported) to 564 obtain the IP multicast address from the hostname. 566 After any change on a Group configuration resource, the endpoint MUST 567 effect registration/de-registration from the corresponding IP 568 multicast group(s) as soon as possible. When a POST payload contains 569 in "a" an IP multicast address to which the endpoint is already 570 subscribed, no change to that subscription is needed. 572 2.7.2.3. Deleting a single group membership (DELETE) 574 Method: DELETE 575 URI Template: {+location} 576 URI Template Variables: 577 location - The Location-Path returned by the CoAP server as a result 578 of a successful group creation. 580 Example: 581 Req: DELETE /coap-group/12 582 Res: 2.02 Deleted 584 2.7.2.4. Reading all group memberships at once (GET) 586 A (unicast) GET on the CoAP-group resource returns a JSON object 587 containing multiple keys and values, the keys being group indices and 588 the values the corresponding group objects. Each group object is a 589 group membership JSON object that indicates one IP multicast group 590 membership. So, the group index is used as a JSON key to point to 591 the group membership object, as shown below. 593 Method: GET 594 URI Template: /{+gp} 595 URI Template Variables: 596 gp - see earlier definition 598 Example: 599 Req: GET /coap-group 600 Res: 2.05 Content 601 Content-Format: application/coap-group+json 602 { "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" }, 603 "11":{ "n": "sensors.floor1.west.bldg6.example.com", 604 "a": "[ff15::4200:f7fe:ed37:25cb]" }, 605 "12":{ "n": "All-Devices.floor1.west.bldg6.example.com", 606 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 607 } 609 Note: the returned IPv6 address may be a different string from the 610 one originally submitted in group membership creation, due to 611 different choices in IPv6 string representation formatting that may 612 be allowed for the same address (see [RFC5952]). 614 2.7.2.5. Reading a single group membership (GET) 616 Method: GET 617 URI Template 1: {+location} 618 URI Template 2: /{+gp}/{index} 619 URI Template Variables: 620 location, gp, index - see earlier definitions 622 Example: 623 Req: GET /coap-group/12 624 Res: 2.05 Content 625 Content-Format: application/coap-group+json 626 {"n": "All-Devices.floor1.west.bldg6.example.com", 627 "a": "[ff15::4200:f7fe:ed37:abcd]:4567"} 629 2.7.2.6. Creating/updating all group memberships at once (PUT) 631 A (unicast) PUT with a group configuration media type as payload will 632 replace all current group memberships in the endpoint with the new 633 ones defined in the PUT request. This operation SHOULD only be used 634 to delete or update group membership objects for which the CoAP 635 client, invoking this operation, is responsible. The responsibility 636 is based on application level knowledge. For example, a 637 commissioning tool will be responsible for any group membership 638 objects that it created. 640 Method: PUT 641 URI Template: /{+gp} 642 URI Template Variables: 643 gp - see earlier definition 645 Example: (replacing all existing group memberships with two new groups) 646 Req: PUT /coap-group 647 Content-Format: application/coap-group+json 648 { "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" }, 649 "2":{ "a": "[ff15::4200:f7fe:ed37:5678]" } 650 } 651 Res: 2.04 Changed 653 Example: (clearing all group memberships at once) 654 Req: PUT /coap-group 655 Content-Format: application/coap-group+json 656 {} 657 Res: 2.04 Changed 658 After a successful PUT on the Group configuration resource, the 659 endpoint MUST effect registration to any new IP multicast group(s) 660 and de-registration from any previous IP multicast group(s), i.e. not 661 anymore present in the new memberships, as soon as possible. Also it 662 MUST take into account the group indices present in the new resource 663 during the generation of any new unique group indices in the future. 665 2.7.2.7. Updating a single group membership (PUT) 667 A (unicast) PUT with a group membership JSON object will replace an 668 existing group membership in the endpoint with the new one defined in 669 the PUT request. This can be used to update the group membership. 671 Method: PUT 672 URI Template 1: {+location} 673 URI Template 2: /{+gp}/{index} 674 URI Template Variables: 675 location, gp, index - see earlier definitions 677 Example: (group name and IP multicast port change) 678 Req: PUT /coap-group/12 679 Content-Format: application/coap-group+json 680 {"n": "All-My-Devices.floor1.west.bldg6.example.com", 681 "a": "[ff15::4200:f7fe:ed37:abcd]"} 682 Res: 2.04 Changed 684 After a successful PUT on the Group configuration resource, the 685 endpoint MUST effect registration to any new IP multicast group(s) 686 and de-registration from any previous IP multicast group(s), i.e. not 687 anymore present in the new membership, as soon as possible. 689 2.8. Request Acceptance and Response Suppression Rules 691 CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define 692 normative behaviors for: 694 1. IP multicast request acceptance - in which cases a CoAP request 695 is accepted and executed, and when not. 697 2. IP multicast response suppression - in which cases the CoAP 698 response to an already-executed request is returned to the 699 requesting endpoint, and when not. 701 A CoAP response differs from a CoAP ACK; ACKs are never sent by 702 servers in response to an IP multicast CoAP request. This section 703 first summarizes these normative behaviors and then presents 704 additional guidelines for response suppression. Also a number of IP 705 multicast example applications are given to illustrate the overall 706 approach. 708 To apply any rules for request and/or response suppression, a CoAP 709 server must be aware that an incoming request arrived via IP 710 multicast by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]. 712 For IP multicast request acceptance, the REQUIRED behaviors are: 714 o A server SHOULD NOT accept an IP multicast request that cannot be 715 "authenticated" in some way (cryptographically or by some 716 multicast boundary limiting the potential sources) 717 [I-D.ietf-core-coap]. See Section 5.3 for examples of multicast 718 boundary limiting methods. 720 o A server SHOULD NOT accept an IP multicast discovery request with 721 a query string (as defined in CoRE Link Format [RFC6690]) if 722 filtering ([RFC6690]) is not supported by the server. 724 o A server SHOULD NOT accept an IP multicast request that acts on a 725 specific resource for which IP multicast support is not required. 726 (Note that for the resource "/.well-known/core", IP multicast 727 support is required if "multicast resource discovery" is supported 728 as specified in section 1.2.1 of [RFC6690]). Implementers are 729 advised to disable IP multicast support by default on any other 730 resource, until explicitly enabled by an application or by 731 configuration.) 733 o Otherwise accept the IP multicast request. 735 For IP multicast response suppression, the REQUIRED behaviors are: 737 o A server SHOULD NOT respond to an IP multicast discovery request 738 if the filter specified by the request's query string does not 739 match. 741 o A server MAY choose not to respond to an IP multicast request, if 742 there's nothing useful to respond (e.g., error or empty response). 744 o Otherwise respond to the IP multicast request. 746 The above response suppression behaviors are complemented by the 747 following guidelines. CoAP servers SHOULD implement configurable 748 response suppression, enabling at least the following options per 749 resource that supports IP multicast requests: 751 o Suppression of all 2.xx success responses; 752 o Suppression of all 4.xx client errors; 754 o Suppression of all 5.xx server errors; 756 o Suppression of all 2.05 responses with empty payload. 758 A number of CoAP group communication example applications are given 759 below to illustrate how to make use of response suppression: 761 o CoAP resource discovery: Suppress 2.05 responses with empty 762 payload and all 4.xx and 5.xx errors. 764 o Lighting control: Suppress all 2.xx responses after a lighting 765 change command. 767 o Update configuration data in a group of devices using group 768 communication PUT: No suppression at all. The client uses 769 collected responses to identify which group members did not 770 receive the new configuration; then attempts using CoAP CON 771 unicast to update those specific group members. Note that in this 772 case the client implements a "reliable group communication" (as 773 defined in Section 1.3) function using additional, non- 774 standardized functions above the CoAP layer. 776 o IP multicast firmware update by sending blocks of data: Suppress 777 all 2.xx and 5.xx responses. After having sent all IP multicast 778 blocks, the client checks each endpoint by unicast to identify 779 which data blocks are still missing in each endpoint. 781 o Conditional reporting for a group (e.g., sensors) based on a group 782 URI query: Suppress all 2.05 responses with empty payload (i.e., 783 if a query produces no matching results). 785 2.9. Congestion Control 787 CoAP group communication requests may result in a multitude of 788 responses from different nodes, potentially causing congestion. 789 Therefore both the sending of IP multicast requests, and the sending 790 of the unicast CoAP responses to these multicast requests should be 791 conservatively controlled. 793 CoAP [I-D.ietf-core-coap] reduces IP multicast-specific congestion 794 risks through the following measures: 796 o A server MAY choose not to respond to an IP multicast request if 797 there's nothing useful to respond (e.g., error or empty response). 798 See Section 2.8 for more detailed guidelines on response 799 suppression. 801 o A server SHOULD limit the support for IP multicast requests to 802 specific resources where multicast operation is required. 804 o An IP multicast request MUST be Non-confirmable. 806 o A response to an IP multicast request SHOULD be Non-confirmable 807 (Section 5.2.3 of [I-D.ietf-core-coap]). 809 o A server does not respond immediately to an IP multicast request, 810 but SHOULD first wait for a time that is randomly picked within a 811 predetermined time interval called the Leisure. 813 Additional guidelines to reduce congestion risks defined in this 814 document are: 816 o A server in an LLN should only support group communication GET for 817 resources that are small. For example, the payload of the 818 response is limited to approximately 5% of the IP Maximum Transmit 819 Unit (MTU) size so it fits into a single link-layer frame in case 820 6LoWPAN [RFC4944] is used. 822 o A server can minimize the payload length in response to a group 823 communication GET on "/.well-known/core" by using hierarchy in 824 arranging link descriptions for the response. An example of this 825 is given in Section 5 of [RFC6690]. 827 o A server can also minimize the payload length of a response to a 828 group communication GET (e.g., on "/.well-known/core") using CoAP 829 blockwise transfers [I-D.ietf-core-block], returning only a first 830 block of the CoRE Link Format description. For this reason, a 831 CoAP client sending an IP multicast CoAP request to "/.well-known/ 832 core" SHOULD support core-block. 834 o A client should use CoAP group communication with the smallest 835 possible IP multicast scope that fulfils the application needs. 836 As an example, site-local scope is always preferred over global 837 scope IP multicast if this fulfils the application needs. 839 More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944] 840 are given in Section 4.5. 842 2.10. Proxy Operation 844 CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy 845 to process its CoAP request. For this purpose the client either 846 specifies the request group URI as a string in the Proxy-URI option, 847 or it specifies the Proxy-Scheme option with the group URI 848 constructed from the usual Uri-* options. This approach works well 849 for unicast requests. However, there are certain issues and 850 limitations of processing the (unicast) responses to a CoAP group 851 communication request made in this manner through a proxy. 853 A proxy may buffer all the individual (unicast) responses to a CoAP 854 group communication request and then send back only a single 855 (aggregated) response to the client. However there are some issues 856 with this aggregation approach: 858 o Aggregation of (unicast) responses to a CoAP group communication 859 request in a proxy is difficult. This is because the proxy does 860 not know how many members there are in the group, or how many 861 group members will actually respond. Also the proxy does not know 862 how long to wait before deciding to send back the aggregated 863 response to the client. 865 o There is no default format defined in CoAP for aggregation of 866 multiple responses into a single response. 868 Alternatively, if a proxy follows directly the specification for a 869 CoAP Proxy [I-D.ietf-core-coap], the proxy would simply forward all 870 the individual (unicast) responses to a CoAP group communication 871 request to the client (i.e., no aggregation). There are also issues 872 with this approach: 874 o The client may be confused as it may not have known that the 875 Proxy-URI contained a group URI target. That is, the client may 876 be expecting only one (unicast) response but instead receives 877 multiple (unicast) responses potentially leading to fault 878 conditions in the application. 880 o Each individual CoAP response will appear to originate (IP Source 881 address) from the CoAP Proxy, and not from the server that 882 produced the response. This makes it impossible for the client to 883 identify the server that produced each response. 885 Due to above issues, a guideline is defined here that a CoAP Proxy 886 SHOULD NOT support processing an IP multicast CoAP request but rather 887 return a 501 (Not Implemented) response in such case. The exception 888 case here (i.e., to process it) is allowed under following 889 conditions: 891 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 892 proxied IP multicast requests by specific client(s). 894 o The proxy SHOULD return individual (unicast) CoAP responses to the 895 client (i.e., not aggregated). The exception case here occurs 896 when a (future) standardized aggregation format is being used. 898 o It MUST be known to the person/entity doing the configuration of 899 the proxy, or otherwise verified in some way, that the client 900 configured in the whitelist supports receiving multiple responses 901 to a proxied unicast CoAP request. 903 2.11. Exceptions 905 CoAP group communication using IP multicast offers improved network 906 efficiency and latency amongst other benefits. However, group 907 communication may not always be implementable in a given network. 908 The primary reason for this will be that IP multicast is not (fully) 909 supported in the network. 911 For example, if only the RPL protocol [RFC6550] is used in a network 912 with its optional multicast support disabled, there will be no IP 913 multicast routing at all. The only multicast that works in this case 914 is link-local IPv6 multicast. This implies that any CoAP group 915 communication request will be delivered to nodes on the local link 916 only, regardless of the scope value used in the IPv6 destination 917 address. 919 3. Use Cases and Corresponding Protocol Flows 921 3.1. Introduction 923 The use of CoAP group communication is shown in the context of the 924 following two use cases and corresponding protocol flows: 926 o Discovery of RD [I-D.ietf-core-resource-directory]: discovering 927 the local CoAP RD which contains links to resources stored on 928 other CoAP servers [RFC6690]. 930 o Lighting Control: synchronous operation of a group of 931 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 933 3.2. Network Configuration 935 To illustrate the use cases we define two IPv6 network 936 configurations. Both are based on the topology as shown in Figure 1. 937 The two configurations using this topology are: 939 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 940 6LoWPAN Border Routers (6LBRs, [RFC6775]). 942 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 943 multicast-capable Ethernet routers. 945 Both configurations are further specified by the following: 947 o A large room (Room-A) with three lights (Light-1, Light-2, Light- 948 3) controlled by a Light Switch. The devices are organized into 949 two subnets. In reality, there could be more lights (up to 950 several hundreds) but these are not shown for clarity. 952 o Light-1 and the Light Switch are connected to a router (Rtr-1). 954 o Light-2 and the Light-3 are connected to another router (Rtr-2). 956 o The routers are connected to an IPv6 network backbone which is 957 also multicast enabled. In the general case, this means the 958 network backbone and Rtr-1/Rtr-2 support a PIM based multicast 959 routing protocol, and Multicast Listener Discovery (MLD) for 960 forming groups. 962 o A CoAP RD is connected to the network backbone. 964 o The DNS server is optional. If the server is there (connected to 965 the network backbone) then certain DNS based features are 966 available (e.g., DNS resolution of hostname to IP multicast 967 address). If the DNS server is not there, then different 968 provisioning of the network is required (e.g., IP multicast 969 addresses are hard-coded into devices, or manually configured, or 970 obtained via a service discovery method). 972 o A Controller (CoAP client) is connected to the backbone, which is 973 able to control various building functions including lighting. 975 ################################################ 976 # ********************** Room-A # 977 # ** Subnet-1 ** # Network 978 # * ** # Backbone 979 # * +----------+ * # | 980 # * | Light |-------+ * # | 981 # * | Switch | | * # | 982 # * +----------+ +---------+ * # | 983 # * | Rtr-1 |-----------------------------+ 984 # * +---------+ * # | 985 # * +----------+ | * # | 986 # * | Light-1 |--------+ * # | 987 # * +----------+ * # | 988 # ** ** # | 989 # ************************** # | 990 # # | 991 # ********************** # +------------+ | 992 # ** Subnet-2 ** # | DNS Server | | 993 # * ** # | (Optional) |--+ 994 # * +----------+ * # +------------+ | 995 # * | Light-2 |-------+ * # | 996 # * | | | * # | 997 # * +----------+ +---------+ * # | 998 # * | Rtr-2 |-----------------------------+ 999 # * +---------+ * # | 1000 # * +----------+ | * # | 1001 # * | Light-3 |--------+ * # | 1002 # * +----------+ * # +------------+ | 1003 # ** ** # | Controller |--+ 1004 # ************************** # | Client | | 1005 ################################################ +------------+ | 1006 +------------+ | 1007 | CoAP | | 1008 | Resource |-----------------+ 1009 | Directory | 1010 +------------+ 1012 Figure 1: Network Topology of a Large Room (Room-A) 1014 3.3. Discovery of Resource Directory 1016 The protocol flow for discovery of the CoAP RD for the given network 1017 (of Figure 1) is shown in Figure 2: 1019 o Light-2 is installed and powered on for the first time. 1021 o Light-2 will then search for the local CoAP RD by sending out a 1022 group communication GET request (with the "/.well-known/ 1023 core?rt=core.rd" request URI) to the site-local "All CoAP Nodes" 1024 multicast address (FF05:::FD). 1026 o This multicast message will then go to each node in subnet-2. 1027 Rtr-2 will then forward it into to the Network Backbone where it 1028 will be received by the CoAP RD. All other nodes in subnet-2 will 1029 ignore the group communication GET request because it is qualified 1030 by the query string "?rt=core.rd" (which indicates it should only 1031 be processed by the endpoint if it contains a resource of type 1032 "core.rd"). 1034 o The CoAP RD will then send back a unicast response containing the 1035 requested content, which is a CoRE Link Format representation of a 1036 resource of type "core.rd". 1038 o Note that the flow is shown only for Light-2 for clarity. Similar 1039 flows will happen for Light-1, Light-3 and the Light Switch when 1040 they are first installed. 1042 The CoAP RD may also be discovered by other means such as by assuming 1043 a default location (e.g., on a 6LBR), using DHCP, anycast address, 1044 etc. However, these approaches do not invoke CoAP group 1045 communication so are not further discussed here. (See 1046 [I-D.ietf-core-resource-directory] for more details). 1048 For other discovery use cases such as discovering local CoAP servers, 1049 services or resources, CoAP group communication can be used in a 1050 similar fashion as in the above use case. For example, Link-Local 1051 (LL), admin-local or site-local scoped discovery can be done this 1052 way. 1054 Light CoAP 1055 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD 1056 | | | | | | | 1057 | | | | | | | 1058 ********************************** | | | 1059 * Light-2 is installed * | | | 1060 * and powers on for first time * | | | 1061 ********************************** | | | 1062 | | | | | | | 1063 | | | | | | | 1064 | | COAP NON Mcast(GET | | 1065 | | /.well-known/core?rt=core.rd) | | 1066 | |--------->-------------------------------->| | 1067 | | | | | |--------->| 1068 | | | | | | | 1069 | | | | | | | 1070 | | COAP NON (2.05 Content | | 1071 | | ;rt="core.rd";ins="Primary") |<---------| 1072 | |<------------------------------------------| | 1073 | | | | | | | 1075 Figure 2: Resource Directory Discovery via Multicast Request 1077 3.4. Lighting Control 1079 The protocol flow for a building automation lighting control scenario 1080 for the network (Figure 1) is shown in Figure 3. The network is 1081 assumed to be in a 6LoWPAN configuration. Also, it is assumed that 1082 the CoAP servers in each Light are configured to suppress CoAP 1083 responses for any IP multicast CoAP requests related to lighting 1084 control. (See Section 2.8 for more details on response suppression 1085 by a server.) 1087 In addition, Figure 4 shows a protocol flow example for the case that 1088 servers do respond to a lighting control IP multicast request with 1089 (unicast) CoAP NON responses. There are two success responses and 1090 one 5.00 error response. In this particular case, the Light Switch 1091 does not check that all Lights in the group received the IP multicast 1092 request by examining the responses. This is because the Light Switch 1093 is not configured with an exhaustive list of the IP addresses of all 1094 Lights belonging to the group. However, based on received error 1095 responses it could take additional action such as logging a fault or 1096 alerting the user via its LCD display. In case a CoAP message is 1097 delivered multiple times to a Light, the subsequent CoAP messages can 1098 be filtered out as duplicates, based on the CoAP Message ID. 1100 Reliability of IP multicast is not guaranteed. Therefore, one or 1101 more lights in the group may not have received the CoAP control 1102 request due to packet loss. In this use case there is no detection 1103 nor correction of such situations: the application layer expects that 1104 the IP multicast forwarding/routing will be of sufficient quality to 1105 provide on average a very high probability of packet delivery to all 1106 CoAP endpoints in an IP multicast group. An example protocol to 1107 accomplish this using randomized retransmission is the MPL forwarding 1108 protocol for LLNs [I-D.ietf-roll-trickle-mcast]. 1110 We assume the following steps have already occurred before the 1111 illustrated flows: 1113 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 1114 all devices. The CoAP network is formed. 1116 2. Network configuration (application-independent): 6LBRs are 1117 configured with IP multicast addresses, or address blocks, to 1118 filter out or to pass through to/from the 6LoWPAN. 1120 3. Commissioning phase (application-related): The IP multicast 1121 address of the group (Room-A-Lights) has been configured in all 1122 the Lights and in the Light Switch. 1124 4. As an alternative to the previous step, when a DNS server is 1125 available, the Light Switch and/or the Lights have been 1126 configured with a group hostname which each nodes resolves to the 1127 above IP multicast address of the group. 1129 Note for the Commissioning phase: the switch's 6LoWPAN/CoAP software 1130 stack supports sending unicast, multicast or proxied unicast CoAP 1131 requests, including processing of the multiple responses that may be 1132 generated by an IP multicast CoAP request. 1134 Light Network 1135 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 1136 | | | | | | | 1137 | | | | | | | 1138 | | *********************** | | 1139 | | * User flips on * | | 1140 | | * light switch to * | | 1141 | | * turn on all the * | | 1142 | | * lights in Room A * | | 1143 | | *********************** | | 1144 | | | | | | | 1145 | | | | | | | 1146 | | | COAP NON Mcast(PUT, | | 1147 | | | Payload=lights ON) | | 1148 |<-------------------------------+--------->| | | 1149 ON | | | |-------------------->| 1150 | | | | | |<---------| 1151 | |<---------|<-------------------------------| | 1152 | ON ON | | | | 1153 ^ ^ ^ | | | | 1154 *********************** | | | | 1155 * Lights in Room-A * | | | | 1156 * turn on (nearly * | | | | 1157 * simultaneously) * | | | | 1158 *********************** | | | | 1159 | | | | | | | 1161 Figure 3: Light Switch Sends Multicast Control Message 1162 Light Network 1163 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 1164 | | | | | | | 1165 | COAP NON (2.04 Changed) | | | | 1166 |------------------------------->| | | | 1167 | | | | | | | 1168 | | | | | | | 1169 | COAP NON (2.04 Changed) | | | 1170 | |------------------------------------------>| | 1171 | | | | | |--------->| 1172 | | | | |<--------------------| 1173 | | | |<---------| | | 1174 | | | | | | | 1175 | | COAP NON (5.00 Internal Server Error) | 1176 | | |------------------------------->| | 1177 | | | | | |--------->| 1178 | | | | |<--------------------| 1179 | | | |<---------| | | 1180 | | | | | | | 1182 Figure 4: Lights (Optionally) Respond to Multicast CoAP Request 1184 Another, but similar, lighting control use case is shown in Figure 5. 1185 In this case a controller connected to the Network Backbone sends a 1186 CoAP group communication request to turn on all lights in Room-A. 1187 Every Light sends back a CoAP response to the Controller after being 1188 turned on. 1190 Network 1191 Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller 1192 | | | | | | | 1193 | | | | | COAP NON Mcast(PUT, 1194 | | | | | Payload=lights ON) 1195 | | | | | |<-------| 1196 | | | |<----------<---------| | 1197 |<--------------------------------| | | | 1198 ON | | | | | | 1199 | |<----------<---------------------| | | 1200 | ON ON | | | | 1201 ^ ^ ^ | | | | 1202 *********************** | | | | 1203 * Lights in Room-A * | | | | 1204 * turn on (nearly * | | | | 1205 * simultaneously) * | | | | 1206 *********************** | | | | 1207 | | | | | | | 1208 | | | | | | | 1209 | COAP NON (2.04 Changed) | | | | 1210 |-------------------------------->| | | | 1211 | | | |-------------------->| | 1212 | | COAP NON (2.04 Changed) | |------->| 1213 | |-------------------------------->| | | 1214 | | | | |--------->| | 1215 | | | COAP NON (2.04 Changed) |------->| 1216 | | |--------------------->| | | 1217 | | | | |--------->| | 1218 | | | | | |------->| 1219 | | | | | | | 1221 Figure 5: Controller On Backbone Sends Multicast Control Message 1223 3.5. Lighting Control in MLD Enabled Network 1225 The use case of previous section can also apply in networks where 1226 nodes support the MLD protocol [RFC3810]. The Lights then take on 1227 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 1228 Routers. In the Ethernet based network configuration, MLD may be 1229 available on all involved network interfaces. Use of MLD in the 1230 6LoWPAN based configuration is also possible, but requires MLD 1231 support in all nodes in the 6LoWPAN. In current 6LoWPAN 1232 implementations, MLD is however not supported. 1234 The resulting protocol flow is shown in Figure 6. This flow is 1235 executed after the commissioning phase, as soon as Lights are 1236 configured with a group address to listen to. The (unicast) MLD 1237 Reports may require periodic refresh activity as specified by the MLD 1238 protocol. In the figure, LL denotes Link Local communication. 1240 After the shown sequence of MLD Report messages has been executed, 1241 both Rtr-1 and Rtr-2 are automatically configured to forward IP 1242 multicast traffic destined to Room-A-Lights onto their connected 1243 subnet. Hence, no manual Network Configuration of routers, as 1244 previously indicated in Section 3.4, is needed anymore. 1246 Light Network 1247 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 1248 | | | | | | | 1249 | | | | | | | 1250 | | | | | | | 1251 | MLD Report: Join | | | | | 1252 | Group (Room-A-Lights) | | | | 1253 |---LL------------------------------------->| | | 1254 | | | | |MLD Report: Join | 1255 | | | | |Group (Room-A-Lights)| 1256 | | | | |---LL---->----LL---->| 1257 | | | | | | | 1258 | | MLD Report: Join | | | | 1259 | | Group (Room-A-Lights) | | | 1260 | |---LL------------------------------------->| | 1261 | | | | | | | 1262 | | | MLD Report: Join | | | 1263 | | | Group (Room-A-Lights) | | 1264 | | |---LL-------------------------->| | 1265 | | | | | | | 1266 | | | | |MLD Report: Join | 1267 | | | | |Group (Room-A-Lights)| 1268 | | | | |<--LL-----+---LL---->| 1269 | | | | | | | 1270 | | | | | | | 1272 Figure 6: Joining Lighting Groups Using MLD 1274 3.6. Commissioning the Network Based On Resource Directory 1276 This section outlines how devices in the lighting use case (both 1277 Switches and Lights) can be commissioned, making use of Resource 1278 Directory [I-D.ietf-core-resource-directory] and its group 1279 configuration feature. 1281 Once the Resource Directory (RD) is discovered, the Switches and 1282 Lights need to be discovered and their groups need to be defined. 1284 For the commissioning of these devices, a commissioning tool can be 1285 used that defines the entries in the RD. The commissioning tool has 1286 the authority to change the contents of the RD and the Light/Switch 1287 nodes. DTLS based security is used by the commissioning tool to 1288 modify operational data in RD, Switches and Lights. 1290 In our particular use case, a group of three lights is defined with 1291 one IP multicast address and hostname "Room- 1292 A-Lights.floor1.west.bldg6.example.com". The commissioning tool has 1293 a list of the three lights and the associated IP multicast address. 1294 For each light in the list the tool learns the IP address of the 1295 light and instructs the RD with three (unicast) POST commands to 1296 store the endpoints associated with the three lights as prescribed by 1297 the RD specification [I-D.ietf-core-resource-directory]. Finally the 1298 commissioning tool defines the group in the RD to contain these three 1299 endpoints. Also the commissioning tool writes the IP multicast 1300 address in the Light endpoints with, for example, the (unicast) POST 1301 command discussed in Section 2.7.2.2. 1303 The light switch can discover the group in RD and thus learn the IP 1304 multicast address of the group. The light switch will use this 1305 address to send CoAP group communication requests to the members of 1306 the group. When the message arrives the Lights should recognize the 1307 IP multicast address and accept the message. 1309 4. Deployment Guidelines 1311 This section provides guidelines how IP multicast based CoAP group 1312 communication can be deployed in various network configurations. 1314 4.1. Target Network Topologies 1316 CoAP group communication can be deployed in various network 1317 topologies. First, the target network may be a traditional IP 1318 network, or a LLN such as a 6LoWPAN network, or consist of mixed 1319 traditional/constrained network segments. Second, it may be a single 1320 subnet only or multi-subnet; e.g., multiple 6LoWPAN networks joined 1321 by a single backbone LAN. Third, a wireless network segment may have 1322 all its nodes reachable in a single IP hop (fully connected), or it 1323 may require multiple IP hops for some pairs of nodes to reach each 1324 other. 1326 Each topology may pose different requirements on the configuration of 1327 routers and protocol(s), in order to enable efficient CoAP group 1328 communication. To enable all the above target network topologies, an 1329 implementation of CoAP group communication needs to allow: 1331 1. Routing/forwarding of IP multicast packets over multiple hops 1332 2. Routing/forwarding of IP multicast packets over subnet boundaries 1333 between traditional and constrained (e.g. LLN) networks. 1335 The remainder of this section discusses solutions to enable both 1336 features. 1338 4.2. Networks Using the MLD Protocol 1340 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1341 unaware of the specific IP multicast routing/forwarding protocol 1342 being used. When such a host needs to join a specific (CoAP) 1343 multicast group, it requires a way to signal to IP multicast routers 1344 which IP multicast traffic it wants to receive. 1346 The Multicast Listener Discovery (MLD) protocol [RFC3810] (see 1347 Appendix A) is the standard IPv6 method to achieve this; therefore 1348 this approach should be used on traditional IP networks. CoAP server 1349 nodes would then act in the role of MLD Multicast Address Listener. 1351 The guidelines from [RFC6636] on tuning of MLD for mobile and 1352 wireless networks may be useful when implementing MLD in LLNs. 1353 However, on LLNs and 6LoWPAN networks the use of MLD may not be 1354 feasible at all due to constraints on code size, memory, or network 1355 capacity. 1357 4.3. Networks Using RPL Multicast Without MLD 1359 It is assumed in this section that the MLD protocol is not 1360 implemented in a network, for example due to resource constraints. 1361 The RPL routing protocol (see Section 12 of [RFC6550]) defines the 1362 advertisement of IP multicast destinations using DAO messages and 1363 routing of multicast IPv6 packets based on this. It requires the RPL 1364 Mode of Operation (MOP) to be 3 (Storing Mode with multicast 1365 support). 1367 Hence, RPL DAO can be used by CoAP nodes that are RPL Routers, or are 1368 RPL Leaf Nodes, to advertise IP multicast group membership to parent 1369 routers. Then, the RPL protocol is used to route IP multicast CoAP 1370 requests over multiple hops to the correct CoAP servers. 1372 The same DAO mechanism can be used to convey IP multicast group 1373 membership information to an edge router (e.g., 6LBR), in case the 1374 edge router is also the root of the RPL DODAG. This is useful 1375 because the edge router then learns which IP multicast traffic it 1376 needs to pass through from the backbone network into the LLN subnet. 1377 In 6LoWPAN networks, such selective "filtering" helps to avoid 1378 congestion of a 6LoWPAN subnet by IP multicast traffic from the 1379 traditional backbone IP network. 1381 4.4. Networks Using MPL Forwarding Without MLD 1383 The MPL forwarding protocol [I-D.ietf-roll-trickle-mcast] can be used 1384 for propagation of IPv6 multicast packets to all MPL Forwarders 1385 within a predefined network domain, over multiple hops. MPL is 1386 designed to work in LLNs. In this section it is again assumed that 1387 Multicast Listener Discovery (MLD) is not implemented in the network, 1388 for example due to resource limitations in an LLN. 1390 The purpose of MPL is to let a predefined group of Forwarders 1391 collectively work towards the goal of distributing an IPv6 multicast 1392 packet throughout an MPL Domain. (A Forwarder node may be associated 1393 to multiple MPL Domains at the same time.) So it would appear there 1394 is no need for CoAP servers to advertise their multicast group 1395 membership, since any IP multicast packet that enters the MPL Domain 1396 is distributed to all MPL Forwarders without regard to what multicast 1397 addresses the individual nodes are listening to. 1399 However, if an IP multicast request originates just outside the MPL 1400 Domain, the request will not be propagated by MPL. An example of 1401 such a case is the network topology of Figure 1 where the Subnets are 1402 6LoWPAN subnets and per 6LoWPAN subnet one Realm-Local 1403 ([I-D.droms-6man-multicast-scopes]) MPL Domain is defined. The 1404 backbone network in this case is not part of any MPL Domain. 1406 This situation can become a problem in building control use cases. 1407 For example, when the Controller Client needs to send a single IP 1408 multicast request to the group Room-A-Lights. By default, the 1409 request would be blocked by Rtr-1 and by Rtr-2, and not enter the 1410 Realm-Local MPL Domains associated to Subnet-1 and Subnet-2. The 1411 reason is that Rtr-1 and Rtr-2 do not have the knowledge that devices 1412 in Subnet-1/2 want to listen for IP packets destined to IP multicast 1413 group Room-A-Lights. 1415 To solve the above issue, the following solutions could be applied: 1417 1. Extend the MPL Domain. E.g. in above example, include the 1418 Network Backbone to be part of each of the two MPL Domains. Or 1419 in above example, create just a single MPL Domain that includes 1420 both 6LoWPAN subnets plus the backbone link, which is possible 1421 since MPL is not tied to a single link-layer technology. 1423 2. Manual configuration of edge router(s) as MPL Seed(s) for 1424 specific IP multicast traffic. E.g. in above example, first 1425 configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the 1426 Room-A-Lights IP multicast group. This step allows any (other) 1427 routers on the backbone to learn that at least one node on the 1428 backbone link is interested to receive any IP multicast traffic 1429 to Room-A-Lights. Second, configure both routers to "inject" any 1430 IP multicast packets destined to group Room-A-Lights into the 1431 (Realm-Local) MPL Domain that is associated to that router. 1432 Third, configure both routers to propagate any IPv6 multicast 1433 packets originating from within their associated MPL Domain to 1434 the backbone, if at least one node on the backbone has indicated 1435 interest to receive such IPv6 packets (for which MLD is used on 1436 the backbone). 1438 3. Use an additional protocol/mechanism for injection of IP 1439 multicast traffic from outside an MPL Domain into that MPL 1440 Domain, based on IP multicast group subscriptions of Forwarders 1441 within the MPL Domain. Such protocol is currently not defined in 1442 [I-D.ietf-roll-trickle-mcast]. 1444 Concluding, MPL can be used directly in case all sources of IP 1445 multicast CoAP requests (CoAP clients) and also all the destinations 1446 (CoAP servers) are inside a single MPL Domain. Then, each source 1447 node acts as an MPL Seed. In all other cases, MPL can only be used 1448 with additional protocols and/or configuration on how IP multicast 1449 packets can be injected from outside into an MPL Domain. 1451 4.5. 6LoWPAN Specific Guidelines for the 6LBR 1453 To support multi-subnet scenarios for CoAP group communication, it is 1454 recommended that a 6LoWPAN Border Router (6LBR) will act in an MLD 1455 Router role on the backbone link. If this is not possible then the 1456 6LBR should be configured to act as an MLD Multicast Address Listener 1457 (see Appendix A) on the backbone link. 1459 5. Security Considerations 1461 This section describes the relevant security configuration for CoAP 1462 group communication using IP multicast. The threats to CoAP group 1463 communication are also identified and various approaches to mitigate 1464 these threats are summarized. 1466 5.1. Security Configuration 1468 As defined in [I-D.ietf-core-coap], CoAP group communication based on 1469 IP multicast: 1471 o Will operate in CoAP NoSec (No Security) mode, until a future 1472 group security solution is developed (see also Section 5.3.3). 1474 o Will use "coap" scheme mode. The "coaps" scheme should only be 1475 used when a future group security solution is developed (see also 1476 Section 5.3.3). 1478 5.2. Threats 1480 Essentially the above configuration means that there is currently no 1481 security at the CoAP layer for group communication. This is due to 1482 the fact that the current DTLS based approach for CoAP is exclusively 1483 unicast oriented and does not support group security features such as 1484 group key exchange and group authentication. As a direct consequence 1485 of this, CoAP group communication is vulnerable to all attacks 1486 mentioned in [I-D.ietf-core-coap] for IP multicast. 1488 5.3. Threat Mitigation 1490 The [I-D.ietf-core-coap] identifies various threat mitigation 1491 techniques for CoAP group communication. In addition to those 1492 guidelines, it is recommended that for sensitive data or safety- 1493 critical control, a combination of appropriate link-layer security 1494 and administrative control of IP multicast boundaries should be used. 1495 Some examples are given below. 1497 5.3.1. WiFi Scenario 1499 In a home automation scenario (using WiFi), the WiFi encryption 1500 should be enabled to prevent rogue nodes from joining. The Customer 1501 Premise Equipment (CPE) that enables access to the Internet should 1502 also have its IP multicast filters set so that it enforces multicast 1503 scope boundaries to isolate local multicast groups from the rest of 1504 the Internet (e.g., as per [RFC6092]). In addition, the scope of the 1505 IP multicast should be set to be site-local or smaller scope. For 1506 site-local scope, the CPE will be an appropriate multicast scope 1507 boundary point. 1509 5.3.2. 6LoWPAN Scenario 1511 In a building automation scenario, a particular room may have a 1512 single 6LoWPAN network with a single Edge Router (6LBR). Nodes on 1513 the subnet can use link-layer encryption to prevent rogue nodes from 1514 joining. The 6LBR can be configured so that it blocks any incoming 1515 (6LoWPAN-bound) IP multicast traffic. Another example topology could 1516 be a multi-subnet 6LoWPAN in a large conference room. In this case, 1517 the backbone can implement port authentication (IEEE 802.1X) to 1518 ensure only authorized devices can join the Ethernet backbone. The 1519 access router to this secured network segment can also be configured 1520 to block incoming IP multicast traffic. 1522 5.3.3. Future Evolution 1524 In the future, to further mitigate the threats, the developing 1525 approach for DTLS-based IP multicast security for CoAP communications 1526 (see [I-D.keoh-dice-multicast-security]) or similar approaches should 1527 be considered. This will allow introduction of a secure mode of CoAP 1528 group communication, and use of the "coaps" scheme for that purpose. 1530 5.4. Pervasive Monitoring Considerations 1532 A key additional threat consideration for group communication is 1533 pointed to by [RFC7258] which warns of the dangers of pervasive 1534 monitoring. CoAP group communication which is built on top of IP 1535 multicast should pay particular heed to these dangers. This is 1536 because IP multicast is easier to intercept (e.g. and to secretly 1537 record) compared to unicast traffic. Also, CoAP traffic is meant for 1538 the Internet of Things. This means that CoAP traffic is often used 1539 for the control and monitoring of critical infrastructure (e.g. 1540 lights, alarms, etc.) which may be prime targets for attack. 1542 For example, an attacker may attempt to record all the CoAP traffic 1543 going over the smart grid (i.e. networked electrical utility) of a 1544 country and try to determine critical control nodes for further 1545 attacks. CoAP multicast traffic is inherently more vulnerable 1546 (compared to a unicast packet) as the same packet may be replicated 1547 over many links so there is a much higher probability of it getting 1548 captured by a pervasive monitoring system. 1550 One useful mitigation to pervasive monitoring is to restrict the 1551 scope of the IP multicast to the minimal scope that fulfils the 1552 application need. Thus, for example, site-local IP multicast scope 1553 is always preferred over global scope IP multicast if this fulfils 1554 the application needs. This approach has the added advantage that it 1555 coincides with the guidelines for minimizing congestion control (see 1556 Section 2.9. 1558 In the future, even if all the CoAP multicast traffic is encrypted 1559 (e.g. [I-D.keoh-dice-multicast-security]), an attacker may still 1560 attempt to capture the traffic and perform an off-line attack. 1561 Though of course having the multicast traffic protected is always 1562 desirable as it significantly raises the cost to an attacker (e.g. to 1563 break the encryption) versus unprotected multicast traffic. 1565 6. IANA Considerations 1566 6.1. New 'core.gp' Resource Type 1568 This memo registers a new resource type (rt) from the CoRE Parameters 1569 Registry called 'core.gp'. 1571 (Note to IANA/RFC Editor: This registration follows the process 1572 described in section 7.4 of [RFC6690]). 1574 Attribute Value: core.gp 1576 Description: Group Configuration resource. This resource is used to 1577 query/manage the group membership of a CoAP server. 1579 Reference: See Section 2.7.2. 1581 6.2. New 'coap-group+json' Internet Media Type 1583 This memo registers a new Internet Media Type for CoAP group 1584 configuration resource called 'application/coap-group+json'. 1586 (Note to IANA/RFC Editor: This registration follows the guidance from 1587 [RFC6839], and (last paragraph) of section 12.3 of 1588 [I-D.ietf-core-coap]. 1590 Type name: application 1592 Subtype name: coap-group+json 1594 Required parameters: None 1596 Optional parameters: None 1598 Encoding considerations: 8bit UTF-8. 1600 JSON to be represented using UTF-8 which is 8bit compatible (and most 1601 efficient for resource constrained implementations). 1603 Security considerations: 1605 Denial of Service attacks could be performed by constantly 1606 (re-)setting the group configuration resource of a CoAP endpoint to 1607 different values. This will cause the endpoint to register (or de- 1608 register) from the related IP multicast group. To prevent this it is 1609 recommended that a form of authorization (making use of DTLS-secured 1610 CoAP) be used such that only authorized controllers are allowed by an 1611 endpoint to configure its group membership. 1613 Interoperability considerations: None 1614 Published specification: (This I-D when it becomes an RFC) 1616 Applications that use this media type: 1618 CoAP client and server implementations that wish to set/read the 1619 group configuration resource via 'application/coap-group+json' 1620 payload as described in Section 2.7.2. 1622 Additional Information: 1624 Magic number(s): None 1626 File extension(s): *.json 1628 Macintosh file type code(s): TEXT 1630 Intended usage: COMMON 1632 Restrictions on usage: None 1634 Author: CoRE WG 1636 Change controller: IETF 1638 7. Acknowledgements 1640 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1641 Castellani, Thomas Fossati, Bjoern Hoehrmann, Matthias Kovatsch, 1642 Guang Lu, Salvatore Loreto, Kerry Lynn, Andrew McGregor, Dale Seed, 1643 Zach Shelby, Peter van der Stok, Gengyu Wei, and Juan Carlos Zuniga 1644 for their helpful comments and discussions that have helped shape 1645 this document. 1647 8. References 1649 8.1. Normative References 1651 [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1652 1033, November 1987. 1654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1655 Requirement Levels", BCP 14, RFC 2119, March 1997. 1657 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1658 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1659 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1661 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1662 Thyagarajan, "Internet Group Management Protocol, Version 1663 3", RFC 3376, October 2002. 1665 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1666 Management Information Base", RFC 3433, December 2002. 1668 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1669 "Advanced Sockets Application Program Interface (API) for 1670 IPv6", RFC 3542, May 2003. 1672 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1673 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1675 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1676 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1677 3986, January 2005. 1679 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1680 Architecture", RFC 4291, February 2006. 1682 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1683 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1684 Protocol Specification (Revised)", RFC 4601, August 2006. 1686 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1687 "Transmission of IPv6 Packets over IEEE 802.15.4 1688 Networks", RFC 4944, September 2007. 1690 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1691 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1692 March 2010. 1694 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1695 Address Text Representation", RFC 5952, August 2010. 1697 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1698 Customer Premises Equipment (CPE) for Providing 1699 Residential IPv6 Internet Service", RFC 6092, January 1700 2011. 1702 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1703 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1704 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1705 Lossy Networks", RFC 6550, March 2012. 1707 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1708 the Internet Group Management Protocol (IGMP) and 1709 Multicast Listener Discovery (MLD) for Routers in Mobile 1710 and Wireless Networks", RFC 6636, May 2012. 1712 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1713 Format", RFC 6690, August 2012. 1715 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1716 "Neighbor Discovery Optimization for IPv6 over Low-Power 1717 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1718 November 2012. 1720 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 1721 Structured Syntax Suffixes", RFC 6839, January 2013. 1723 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1724 Attack", BCP 188, RFC 7258, May 2014. 1726 [I-D.ietf-core-coap] 1727 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1728 Application Protocol (CoAP)", draft-ietf-core-coap-18 1729 (work in progress), June 2013. 1731 8.2. Informative References 1733 [I-D.ietf-core-block] 1734 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1735 draft-ietf-core-block-14 (work in progress), October 2013. 1737 [I-D.ietf-roll-trickle-mcast] 1738 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1739 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1740 mcast-09 (work in progress), April 2014. 1742 [I-D.keoh-dice-multicast-security] 1743 Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. 1744 Rahman, "DTLS-based Multicast Security in Constrained 1745 Environments", draft-keoh-dice-multicast-security-07 (work 1746 in progress), May 2014. 1748 [I-D.ietf-core-resource-directory] 1749 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 1750 Directory", draft-ietf-core-resource-directory-01 (work in 1751 progress), December 2013. 1753 [I-D.ietf-appsawg-uri-get-off-my-lawn] 1754 Nottingham, M., "URI Design and Ownership", draft-ietf- 1755 appsawg-uri-get-off-my-lawn-05 (work in progress), May 1756 2014. 1758 [I-D.droms-6man-multicast-scopes] 1759 Droms, R., "IPv6 Multicast Address Scopes", draft-droms- 1760 6man-multicast-scopes-02 (work in progress), July 2013. 1762 Appendix A. Multicast Listener Discovery (MLD) 1764 In order to extend the scope of IP multicast beyond link-local scope, 1765 an IP multicast routing or forwarding protocol has to be active in 1766 routers on an LLN. To achieve efficient IP multicast routing (i.e., 1767 avoid always flooding IP multicast packets), routers have to learn 1768 which hosts need to receive packets addressed to specific IP 1769 multicast destinations. 1771 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1772 IPv4 equivalent IGMP [RFC3376]) is today the method of choice used by 1773 an (IP multicast enabled) router to discover the presence of IP 1774 multicast listeners on directly attached links, and to discover which 1775 IP multicast addresses are of interest to those listening nodes. MLD 1776 was specifically designed to cope with fairly dynamic situations in 1777 which IP multicast listeners may join and leave at any time. 1779 [RFC6636] discusses optimal tuning of the parameters of MLD/IGMP for 1780 routers for mobile and wireless networks. These guidelines may be 1781 useful when implementing MLD in LLNs. 1783 Appendix B. Change Log 1785 [Note to RFC Editor: Please remove this section before publication.] 1787 Changes from ietf-18 to ietf-19: 1789 o Added guideline on Token value re-use in section 2.5. 1791 o Updated section 5.1 (Security Configuration) and 5.3.3 (Future 1792 Security Evolution) to point to latest security developments 1793 happening in DICE WG for support of group security. 1795 o Added Pervasive Monitoring considerations in section 5.4. 1797 o Various editorial updates for improved readability. 1799 Changes from ietf-17 to ietf-18: 1801 o Extensive editorial updates based on WGLC comments by Thomas 1802 Fossati and Gengyu Wei. 1804 o Addressed ticket #361: Added text for single membership PUT 1805 section 2.7.2.7 (Updating a single group membership (PUT)). 1807 o Addressed ticket #360: Added text for server duties upon all-at- 1808 once PUT section 2.7.2.6 (Creating/updating all group memberships 1809 at once (PUT)). 1811 o Addressed ticket #359: Fixed requirements text for Section 2.7.2.2 1812 (Creating a new multicast group membership (POST)). 1814 o Addressed ticket #358: Fixed requirements text for Section 2.7.2.1 1815 (CoAP-Group Resource Type and Media Type). 1817 o Addressed ticket #357: Added that "IPv6 addresses of other scopes 1818 MAY be enabled" in section 2.2 (Group Definition and Naming). 1820 o Various editorial updates for improved readability. 1822 Changes from ietf-16 to ietf-17: 1824 o Added guidelines on joining of IPv6/IPv4 "All CoAP Nodes" 1825 multicast addresses (#356). 1827 o Added MUST support default port in case multicast discovery is 1828 available. 1830 o In section 2.1 (IP Multicast Background), clarified that IP 1831 multicast is not guaranteed and referenced a definition of 1832 Reliable Group Communication (#355). 1834 o Added section 2.5 (Messages and Responses) to clarify how 1835 responses are identified and how Token/MID are used in multicast 1836 CoAP. 1838 o In section 2.6.2 (RESTful Interface for Configuring Group 1839 Memberships), clarified that group management interface is an 1840 optional approach for dynamic commissioning and that other 1841 approaches can also be used if desired. 1843 o Updated section 2.6.2 (RESTful Interface for Configuring Group 1844 Memberships) to allow deletion of individual group memberships 1845 (#354). 1847 o Various editorial updates based on comments by Peter van der Stok. 1848 Removed reference to expired draft-vanderstok-core-dna at request 1849 of its author. 1851 o Various editorial updates for improved readability. 1853 Changes from ietf-15 to ietf-16: 1855 o In section 2.6.2, changed DELETE in group management interface to 1856 a PUT with empty JSON array to clear the list (#345). 1858 o In section 2.6.2, aligned the syntax for IP addresses to follow 1859 RFC 3986 URI syntax, which is also used by coap-18. This allows 1860 re-use of the parsing code for CoAP URIs for this purpose (#342). 1862 o Addressed some more editorial comments provided by Carsten Bormann 1863 in preparation for WGLC. 1865 o Various editorial updates for improved readability. 1867 Changes from ietf-14 to ietf-15: 1869 o In section 2.2, provided guidance on how implementers should parse 1870 URIs for group communication (#339). 1872 o In section 2.6.2.1, specified that for group membership 1873 configuration interface the "ip" (i.e. "a" parameter) key/value is 1874 not required when it is unknown (#338). 1876 o In section 2.6.2.1, specified that for group membership 1877 configuration interface the port configuration be defaulted to 1878 standard CoAP port 5683, and if not default then should follow 1879 standard notation (#340). 1881 o In section 2.6.2.1, specified that notation of IP address in group 1882 membership configuration interface should follow standard notation 1883 (#342). 1885 o In section 6.2, "coap-group+json" Media Type encoding simplified 1886 to just support UTF-8 (and not UTF-16 and UTF-32) (#344). 1888 o Various editorial updates for improved readability. 1890 Changes from ietf-13 to ietf-14: 1892 o Update to address final editorial comments from the Chair's review 1893 (by Carsten Bormann) of the draft. This included restructuring of 1894 Section 2.6 (Configuring Group Memberships) and Section 4 1895 (Deployment Guidelines) to make it easier to read. Also various 1896 other editorial changes. 1898 o Changed "ip" field to "a" in Section 2.6 (#337) 1900 Changes from ietf-12 to ietf-13: 1902 o Extensive editorial updates due to comments from the Chair's 1903 review (by Carsten Bormann) of the draft. The best way to see the 1904 changes will be to do a -Diff with Rev. 12. 1906 o The technical comments from the Chair's review will be addressed 1907 in a future revision after tickets are generated and the solutions 1908 are agreed to on the WG E-mail list. 1910 Changes from ietf-11 to ietf-12: 1912 o Removed reference to "CoAP Ping" in Section 3.5 (Group Member 1913 Discovery) and replaced it with the more efficient support of 1914 discovery of groups and group members via the CORE RD as suggested 1915 by Zach Shelby. 1917 o Various editorial updates for improved readability. 1919 Changes from ietf-10 to ietf-11: 1921 o Added text to section 3.8 (Congestion Control) to clarify that a 1922 "CoAP client sending a multicast CoAP request to /.well-known/core 1923 SHOULD support core-block" (#332). 1925 o Various editorial updates for improved readability. 1927 Changes from ietf-09 to ietf-10: 1929 o Various editorial updates including: 1931 o Added a fourth option in section 3.3 on ways to obtain the URI 1932 path for a group request. 1934 o Clarified use of content format in GET/PUT requests for 1935 Configuring Group Membership in Endpoints (in section 3.6). 1937 o Changed reference "draft-shelby-core-resource-directory" to 1938 "draft-ietf-core-resource-directory". 1940 o Clarified (in section 3.7) that ACKs are never used for a 1941 multicast request (from #296). 1943 o Clarified (in section 5.2/5.2.3) that MPL does not support group 1944 membership advertisement. 1946 o Adding introductory paragraph to Scope (section 2.2). 1948 o Wrote out fully the URIs in table section 3.2. 1950 o Reworded security text in section 7.2 (New Internet Media Type) to 1951 make it consistent with section 3.6 (Configuring Group 1952 Membership). 1954 o Fixed formatting of hyperlinks in sections 6.3 and 7.2. 1956 Changes from ietf-08 to ietf-09: 1958 o Cleaned up requirements language in general. Also, requirements 1959 language are now only used in section 3 (Protocol Considerations) 1960 and section 6 (Security Considerations). Requirements language 1961 has been removed from other sections to keep them to a minimum 1962 (#271). 1964 o Addressed final comment from Peter van der Stok to define what "IP 1965 stack" meant (#296). Following the lead of CoAP-17, we know refer 1966 instead to "APIs such as IPV6_RECVPKTINFO [RFC 3542]". 1968 o Changed text in section 3.4 (Group Methods) to allow multicast 1969 POST under specific conditions and highlighting the risks with 1970 using it (#328). 1972 o Various editorial updates for improved readability. 1974 Changes from ietf-07 to ietf-08: 1976 o Updated text in section 3.6 (Configuring Group Membership in 1977 Endpoints) to make it more explicit that the Internet Media Type 1978 is used in the processing rules (#299). 1980 o Addressed various comments from Peter van der Stok (#296). 1982 o Various editorial updates for improved readability including 1983 defining all acronyms. 1985 Changes from ietf-06 to ietf-07: 1987 o Added an IANA request (in section 7.2) for a dedicated content- 1988 format (Internet Media type) for the group management JSON format 1989 called 'application/coap-group+json' (#299). 1991 o Clarified semantics (in section 3.6) of group management JSON 1992 format (#300). 1994 o Added details of IANA request (in section 7.1) for a new CORE 1995 Resource Type called 'core.gp'. 1997 o Clarified that DELETE method (in section 3.6) is also a valid 1998 group management operation. 2000 o Various editorial updates for improved readability. 2002 Changes from ietf-05 to ietf-06: 2004 o Added a new section on commissioning flow when using discovery 2005 services when end devices discover in which multicast group they 2006 are allocated (#295). 2008 o Added a new section on CoAP Proxy Operation (section 3.9) that 2009 outlines the potential issues and limitations of doing CoAP 2010 multicast requests via a CoAP Proxy (#274). 2012 o Added use case of multicasting controller on the backbone (#279). 2014 o Use cases were updated to show only a single CoAP RD (to replace 2015 the previous multiple RDs with one in each subnet). This is a 2016 more efficient deployment and also avoids RD specific issues such 2017 as synchronization of RD information between serves (#280). 2019 o Added text to section 3.6 (Configuring Group Membership in 2020 Endpoints) that clarified that any (unicast) operation to change 2021 an endpoint's group membership must use DTLS-secured CoAP. 2023 o Clarified relationship of this document to [I-D.ietf-core-coap] in 2024 section 2.2 (Scope). 2026 o Removed IPSec related requirement, as IPSec is not part of 2027 [I-D.ietf-core-coap] anymore. 2029 o Editorial reordering of subsections in section 3 to have a better 2030 flow of topics. Also renamed some of the (sub)sections to better 2031 reflect their content. Finally, moved the URI Configuration text 2032 to the same section as the Port Configuration section as it was a 2033 more natural grouping (now in section 3.3) . 2035 o Editorial rewording of section 3.7 (Multicast Request Acceptance 2036 and Response Suppression) to make the logic easier to comprehend 2037 (parse). 2039 o Various editorial updates for improved readability. 2041 Changes from ietf-04 to ietf-05: 2043 o Added a new section 3.9 (Exceptions) that highlights that IP 2044 multicast (and hence group communication) is not always available 2045 (#187). 2047 o Updated text on the use of [RFC2119] language (#271) in Section 1. 2049 o Included guidelines on when (not) to use CoAP responses to 2050 multicast requests and when (not) to accept multicast requests 2051 (#273). 2053 o Added guideline on use of core-block for minimizing response size 2054 (#275). 2056 o Restructured section 6 (Security Considerations) to more fully 2057 describe threats and threat mitigation (#277). 2059 o Clearly indicated that DNS resolution and reverse DNS lookup are 2060 optional. 2062 o Removed confusing text about a single group having multiple IP 2063 addresses. If multiple IP addresses are required then multiple 2064 groups (with the same members) should be created. 2066 o Removed repetitive text about the fact that group communication is 2067 not guaranteed. 2069 o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP 2070 Multicast Routing Background) and added link to section 5.2 2071 (Advertising Membership of Multicast Groups). 2073 o Clarified text in section 3.8 (Congestion Control) regarding 2074 precedence of use of IP multicast domains (i.e. first try to use 2075 link-local scope, then site-local scope, and only use global IP 2076 multicast as a last resort). 2078 o Extended group resource manipulation guidelines with use of pre- 2079 configured ports/paths for the multicast group. 2081 o Consolidated all text relating to ports in a new section 3.3 (Port 2082 Configuration). 2084 o Clarified that all methods (GET/PUT/POST) for configuring group 2085 membership in endpoints should be unicast (and not multicast) in 2086 section 3.7 (Configuring Group Membership In Endpoints). 2088 o Various editorial updates for improved readability, including 2089 editorial comments by Peter van der Stok to WG list of December 2090 18th, 2012. 2092 Changes from ietf-03 to ietf-04: 2094 o Removed section 2.3 (Potential Solutions for Group Communication) 2095 as it is purely background information and moved section to draft- 2096 dijk-core-groupcomm-misc (#266). 2098 o Added reference to draft-keoh-tls-multicast-security to section 6 2099 (Security Considerations). 2101 o Removed Appendix B (CoAP-Observe Alternative to Group 2102 Communications) as it is as an alternative to IP Multicast that 2103 the WG has not adopted and moved section to draft-dijk-core- 2104 groupcomm-misc (#267). 2106 o Deleted section 8 (Conclusions) as it is redundant (#268). 2108 o Simplified light switch use case (#269) by splitting into basic 2109 operations and additional functions (#269). 2111 o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) 2112 to draft-dijk-core-groupcomm-misc (#270). 2114 o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) 2115 to draft-dijk-core-groupcomm-misc as these sections essentially 2116 just repeated text from other drafts regarding DNS based features. 2117 Clarified remaining text in this draft relating to DNS based 2118 features to clearly indicate that these features are optional 2119 (#272). 2121 o Focus section 3.5 (Configuring Group Membership) on a single 2122 proposed solution. 2124 o Scope of section 5.3 (Use of MLD) widened to multicast destination 2125 advertisement methods in general. 2127 o Rewrote section 2.2 (Scope) for improved readability. 2129 o Moved use cases that are not addressed to draft-dijk-core- 2130 groupcomm-misc. 2132 o Various editorial updates for improved readability. 2134 Changes from ietf-02 to ietf-03: 2136 o Clarified that a group resource manipulation may return back a 2137 mixture of successful and unsuccessful responses (section 3.4 and 2138 Figure 6) (#251). 2140 o Clarified that security option for group communication must be 2141 NoSec mode (section 6) (#250). 2143 o Added mechanism for group membership configuration (#249). 2145 o Removed IANA request for multicast addresses (section 7) and 2146 replaced with a note indicating that the request is being made in 2147 [I-D.ietf-core-coap] (#248). 2149 o Made the definition of 'group' more specific to group of CoAP 2150 endpoints and included text on UDP port selection (#186). 2152 o Added explanatory text in section 3.4 regarding why not to use 2153 group communication for non-idempotent messages (i.e. CoAP POST) 2154 (#186). 2156 o Changed link-local RD discovery to site-local in RD discovery use 2157 case to make it more realistic. 2159 o Fixed lighting control use case CoAP proxying; now returns 2160 individual CoAP responses as in coap-12. 2162 o Replaced link format I-D with RFC6690 reference. 2164 o Various editorial updates for improved readability 2166 Changes from ietf-01 to ietf-02: 2168 o Rewrote congestion control section based on latest CoAP text 2169 including Leisure concept (#188) 2171 o Updated the CoAP/HTTP interworking section and example use case 2172 with more details and use of MLD for multicast group joining 2174 o Key use cases added (#185) 2176 o References to draft-vanderstok-core-dna and draft-castellani-core- 2177 advanced-http-mapping added 2179 o Moved background sections on "MLD" and "CoAP-Observe" to 2180 Appendices 2182 o Removed requirements section (and moved it to draft-dijk-core- 2183 groupcomm-misc) 2185 o Added details for IANA request for group communication multicast 2186 addresses 2188 o Clarified text to distinguish between "link local" and general 2189 multicast cases 2191 o Moved lengthy background section 5 to draft-dijk-core-groupcomm- 2192 misc and replaced with a summary 2194 o Various editorial updates for improved readability 2196 o Change log added 2198 Changes from ietf-00 to ietf-01: 2200 o Moved CoAP-observe solution section to section 2 2202 o Editorial changes 2204 o Moved security requirements into requirements section 2206 o Changed multicast POST to PUT in example use case 2208 o Added CoAP responses in example use case 2210 Changes from rahman-07 to ietf-00: 2212 o Editorial changes 2214 o Use cases section added 2216 o CoRE Resource Directory section added 2218 o Removed section 3.3.5. IP Multicast Transmission Methods 2220 o Removed section 3.4 Overlay Multicast 2222 o Removed section 3.5 CoAP Application Layer Group Management 2224 o Clarified section 4.3.1.3 RPL Routers with Non-RPL Hosts case 2226 o References added and some normative/informative status changes 2228 Authors' Addresses 2229 Akbar Rahman (editor) 2230 InterDigital Communications, LLC 2232 Email: Akbar.Rahman@InterDigital.com 2234 Esko Dijk (editor) 2235 Philips Research 2237 Email: esko.dijk@philips.com