idnits 2.17.1 draft-ietf-core-groupcomm-20.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 (July 20, 2014) is 3567 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2616' is mentioned on line 1780, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC 7230' is mentioned on line 1780, but not defined ** Obsolete undefined reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Missing Reference: 'RFC 7320' is mentioned on line 1783, but not defined ** Obsolete undefined reference: RFC 7320 (Obsoleted by RFC 8820) == Missing Reference: 'RFC 7252' is mentioned on line 1785, but not defined == Missing Reference: 'RFC 1033' is mentioned on line 1787, but not defined ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) == Outdated reference: A later version (-21) exists of draft-ietf-core-block-15 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-01 Summary: 6 errors (**), 0 flaws (~~), 10 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: January 21, 2015 Philips Research 6 July 20, 2014 8 Group Communication for CoAP 9 draft-ietf-core-groupcomm-20 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 January 21, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . 50 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 [RFC7252]. CoAP has many 116 similarities to HTTP [RFC7230] but also has some key differences. 117 Constrained devices can be large in numbers, but are often related to 118 each other in function or by location. For example, all the light 119 switches in a building may belong to one group and all the 120 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 [RFC7252]. The main contribution of this document lies 140 in providing additional guidance for key CoAP group communication 141 concepts. Among the topics covered are group definition, group 142 RESTful methods, and group request and response processing (see 143 Section 2). Also, proxy operation and minimizing network congestion 144 for group communication is discussed (see Section 2). Finally, 145 specific use cases (see Section 3) and deployment guidelines (see 146 Section 4) for group communication are outlined. 148 1.3. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 [RFC2119]. 155 The above key words are used to establish a set of guidelines for 156 CoAP group communication. An implementation of CoAP group 157 communication MAY implement these guidelines; an implementation 158 claiming compliance to this document MUST implement the set of 159 guidelines. 161 This document assumes readers are familiar with the terms and 162 concepts that are used in [RFC7252]. In addition, this document 163 defines the following terminology: 165 Group Communication 166 A source node sends a single application layer (e.g. CoAP) 167 message which is delivered to multiple destination nodes, where 168 all destinations are identified to belong to a specific group. 169 The source node itself may be part of the group. The underlying 170 mechanisms for CoAP group communication are UDP/IP multicast for 171 the requests, and unicast UDP/IP for the responses. The network 172 involved may be a constrained network such as a low-power, lossy 173 network. 175 Reliable Group Communication 176 A special case of group communication where for each destination 177 node it is guaranteed that the node either 1) eventually receives 178 the message sent by the source node, or 2) does not receive the 179 message and the source node is notified of the non-reception 180 event. 182 Multicast 183 Sending a message to multiple destination nodes with one network 184 invocation. There are various options to implement multicast 185 including layer 2 (Media Access Control) and layer 3 (IP) 186 mechanisms. 188 IP Multicast 189 A specific multicast approach based on the use of IP multicast 190 addresses as defined in "IANA Guidelines for IPv4 Multicast 191 Address Assignments" [RFC5771] and "IP Version 6 Addressing 192 Architecture" [RFC4291]. A complete IP multicast solution may 193 include support for managing group memberships, and IP multicast 194 routing/forwarding (see Section 2.1). 196 Low power and Lossy Network (LLN) 197 A type of constrained IP network where devices are interconnected 198 by low-power and lossy links. The links may be may composed of 199 one or more technologies such as IEEE 802.15.4, Bluetooth Low 200 Energy (BLE), Digital Enhanced Cordless Telecommunication (DECT), 201 and IEEE P1901.2 power-line communication. 203 2. Protocol Considerations 205 2.1. IP Multicast Background 207 IP multicast protocols have been evolving for decades, resulting in 208 standards such as Protocol Independent Multicast - Sparse Mode (PIM- 209 SM) [RFC4601]. IP multicast is very popular in specific deployments 210 such as in enterprise networks (e.g., for video conferencing), smart 211 home networks (e.g., Universal Plug and Play (UPnP)) and carrier IPTV 212 deployments. The packet economy and minimal host complexity of IP 213 multicast make it attractive for group communication in constrained 214 environments. 216 To achieve IP multicast beyond link-local scope, an IP multicast 217 routing or forwarding protocol needs to be active on IP routers. An 218 example of a routing protocol specifically for LLNs is the IPv6 219 Routing Protocol for Low-Power and Lossy Networks (RPL) (Section 12 220 of [RFC6550]) and an example of a forwarding protocol for LLNs is 221 Multicast Protocol for Low power and Lossy Networks (MPL) 222 [I-D.ietf-roll-trickle-mcast]. RPL and MPL do not depend on each 223 other; each can be used in isolation and both can be used in 224 combination in a network. Finally, PIM-SM [RFC4601] is often used 225 for multicast routing in traditional IP networks (i.e. networks that 226 are not constrained). 228 IP multicast can also be run in a Link-Local (LL) scope. This means 229 that there is no routing involved and an IP multicast message is only 230 received over the link on which it was sent. 232 For a complete IP multicast solution, in addition to a routing/ 233 forwarding protocol, a "listener" protocol may be needed for the 234 devices to subscribe to groups (see Section 4.2). 236 IP multicast is generally classified as an unreliable service in that 237 packets are not guaranteed to be delivered to each and every member 238 of the group. In other words, it cannot be directly used as a basis 239 for "reliable group communication" as defined in Section 1.3. 240 However, the level of reliability can be increased by employing a 241 multicast protocol that performs periodic retransmissions as is done 242 for example in MPL. 244 2.2. Group Definition and Naming 246 A CoAP group is defined as a set of CoAP endpoints, where each 247 endpoint is configured to receive CoAP group communication requests 248 that are sent to the group's associated IP multicast address. The 249 individual response by each endpoint receiver to a CoAP group 250 communication request is always sent back as unicast. An endpoint 251 may be a member of multiple groups. Group membership of an endpoint 252 may dynamically change over time. 254 All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast 255 group [RFC7252], Section 12.8) by default to enable CoAP discovery. 256 For IPv4, the address is 224.0.1.187 and for IPv6 a server node joins 257 at least both the link-local scoped address FF02::FD and the site- 258 local scoped address FF05::FD. IPv6 addresses of other scopes MAY be 259 enabled. 261 A CoAP group URI has the scheme 'coap' and includes in the authority 262 part either a group IP multicast address, or a hostname (e.g., Group 263 Fully Qualified Domain Name (FQDN)) that can be resolved to the group 264 IP multicast address. A group URI also contains an optional CoAP 265 port number in the authority part. Group URIs follow the regular 266 CoAP URI syntax [RFC7252]. 268 Note: A group URI is needed to initiate CoAP group communications. 269 For CoAP implementations it is recommended to use the URI composition 270 method of Section 6.5 of [RFC7252] in such way that, from a group 271 URI, a CoAP group communication request is generated. 273 For sending nodes, it is recommended to use the IP multicast address 274 literal in a group URI. However, in case a group hostname is used, 275 it can be uniquely mapped to an IP multicast address via DNS 276 resolution (if supported). Some examples of hierarchical group FQDN 277 naming (and scoping) for a building control application are shown 278 below: 280 URI authority Targeted group of nodes 281 --------------------------------------- -------------------------- 282 all.bldg6.example.com "all nodes in building 6" 283 all.west.bldg6.example.com "all nodes in west wing, 284 building 6" 285 all.floor1.west.bldg6.example.com "all nodes in floor 1, 286 west wing, building 6" 287 all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036, 288 floor1, west wing, 289 building 6" 291 Similarly, if supported, reverse mapping (from IP multicast address 292 to Group FQDN) is possible using the reverse DNS resolution technique 293 ([RFC1033]). Reverse mapping is important, for example, in trouble 294 shooting to translate IP multicast addresses back to human readable 295 hostnames to show in a diagnostics user interface. 297 2.3. Port and URI Configuration 299 A CoAP server that is a member of a group listens for CoAP messages 300 on the group's IP multicast address, on a specified UDP port. The 301 default UDP port is the CoAP default port 5683 but a non-default UDP 302 port MAY be specified for the group; in which case implementers MUST 303 ensure that all group members are configured to use this same port. 304 These rules imply that different ports (for the same IP multicast 305 address) cannot be used to specify different CoAP groups. 307 CoAP group communication will not work if there is diversity in the 308 authority port (e.g., different dynamic port addresses across the 309 group) or if other parts of the group URI such as the path, or the 310 query, differ on different endpoints. Therefore, some measures must 311 be present to ensure uniformity in port number and resource names/ 312 locations within a group. All CoAP group communication requests MUST 313 be sent using a port number according to one of below options: 315 1. A pre-configured port number. The pre-configuration mechanism 316 MUST ensure that the same port number is pre-configured across 317 all endpoints in a group and across all CoAP clients performing 318 the group requests. 320 2. If the client is configured to use service discovery including 321 port discovery, it uses a port number obtained via a service 322 discovery lookup operation for the targeted CoAP group. 324 3. Use the default CoAP UDP port (5683). 326 For a CoAP server node that supports resource discovery, the default 327 port 5683 MUST be supported (Section 7.1 of [RFC7252] for the "All 328 CoAP Nodes" group. 330 All CoAP group communication requests SHOULD operate on group URI 331 paths in one of the following ways: 333 1. Pre-configured group URI paths, if available. The pre- 334 configuration mechanism SHOULD ensure that these paths are pre- 335 configured across all CoAP servers in a group and all CoAP 336 clients performing the group requests. Note that ([RFC7320]). 337 prescribes that any specification must not constrain, define 338 structure or semantics for any path component. 340 2. If the client is configured to use default CoRE resource 341 discovery, it uses URI paths retrieved from a "/.well-known/core" 342 lookup on a group member. The URI paths the client will use MUST 343 be known to be available also in all other endpoints in the 344 group. The URI path configuration mechanism on servers MUST 345 ensure that these URIs (identified as being supported by the 346 group) are configured on all group endpoints. 348 3. If the client is configured to use another form of service 349 discovery, it uses group URI paths from an equivalent service 350 discovery lookup which returns the resources supported by all 351 group members. 353 4. If the client has received a group URI through a previous RESTful 354 interaction with a trusted server it can use this URI in a CoAP 355 group communication request. For example, a commissioning tool 356 may instruct a sensor device in this way to which target group 357 (group URI) it should report sensor events. 359 2.4. RESTful Methods 361 Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD 362 be used for group communication, with one exception as follows. A 363 non-idempotent CoAP method (i.e., POST) MAY be used for group 364 communication if the resource being POSTed to has been designed to 365 cope with the unreliable and lossy nature of IP multicast. Note that 366 not all group members are guaranteed to receive the IP multicast 367 request, and the sender cannot readily find out which group members 368 did not receive it. 370 2.5. Request and Response Model 372 All CoAP requests that are sent via IP multicast MUST be Non- 373 confirmable. The Message ID in an IP multicast CoAP message is used 374 for optional message de-duplication as detailed in Section 4.5 of 375 [RFC7252]. 377 A server MAY send back a unicast response to the CoAP group 378 communication request (e.g., response "2.05 Content" to a group GET 379 request). The unicast responses received by the CoAP client may be a 380 mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not 381 Found) codes depending on the individual server processing results. 382 Detailed processing rules for IP multicast request acceptance and 383 unicast response suppression are given in Section 2.8. 385 A CoAP request sent over IP multicast and any unicast response it 386 causes must take into account the congestion control rules defined in 387 Section 2.9. 389 The CoAP client can distinguish the origin of multiple server 390 responses by source IP address of the UDP message containing the CoAP 391 response, or any other available unique identifier (e.g. contained in 392 the CoAP payload). In case a CoAP client sent multiple group 393 requests, the responses are as usual matched to a request using the 394 CoAP Token. 396 For multicast CoAP requests there are additional constraints on the 397 re-use of Token values, compared to the unicast case. In the unicast 398 case, receiving a response effectively frees up its Token value for 399 re-use since no more responses will follow. However, for multicast 400 CoAP the number of responses is not bounded a-priori. Therefore the 401 reception of a response cannot be used as a trigger to "free up" a 402 Token value for re-use. Re-using a Token value too early could lead 403 to protocol error i.e. a wrong response/request matching in the 404 client. Therefore the time between re-use of Token values (for Token 405 values used in multicast requests) must be at least: 407 NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY 409 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 410 [RFC7252]. MAX_SERVER_RESPONSE_DELAY is defined here as the expected 411 maximum response delay over all servers that the client can send a 412 multicast request to. This delay includes the maximum Leisure time 413 period as defined in Section 8.2 of [RFC7252]. Using the CoAP 414 default protocol parameters the re-use time becomes at least 250 415 seconds, but may need to be much longer in practice since there is no 416 time limit defined in CoAP for generation of responses by a server. 418 2.6. Member Discovery 420 CoAP Groups, and the membership of these groups, can be discovered 421 via the lookup interfaces in the Resource Directory (RD) defined in 422 [I-D.ietf-core-resource-directory]. An example of doing some of 423 these RD lookups is given in Section 3.6. 425 2.7. Membership Configuration 427 2.7.1. Background 429 The group membership of a CoAP endpoint may be configured in one of 430 the following ways. First, the group membership may be pre- 431 configured before node deployment. Second, a node may be programmed 432 to discover (query) its group membership using a specific service 433 discovery means. Third, it may be configured by another node (e.g., 434 a commissioning device). 436 In the first case, the pre-configured group information may be either 437 an IP multicast address or a hostname (FQDN) which is resolved later 438 (during operation) to an IP multicast address by the endpoint using 439 DNS (if supported). 441 For the second case, a CoAP endpoint may look up its group membership 442 using techniques such as DNS-SD and Resource Directory 443 [I-D.ietf-core-resource-directory]. The latter case is detailed more 444 in Section 3.6. 446 In the third case, typical in scenarios such as building control, a 447 dynamic commissioning tool determines to which group a sensor or 448 actuator node belongs, and writes this information to the node, which 449 can subsequently join the correct IP multicast group on its network 450 interface. The information written may again be an IP multicast 451 address or a hostname. 453 2.7.2. Membership Configuration RESTful Interface 455 To achieve better interoperability between endpoints from different 456 manufacturers, an OPTIONAL CoAP membership configuration RESTful 457 interface for configuring endpoints with relevant group information 458 is described here. This interface provides a solution for the third 459 case mentioned above. To access this interface a client MUST use 460 unicast CoAP methods (GET/PUT/POST/DELETE) only as it is a method of 461 configuring group information in individual endpoints. 463 Also, a form of authorization (making use of DTLS-secured CoAP 464 [RFC7252]) SHOULD be used such that only authorized controllers are 465 allowed by an endpoint to configure its group membership. 467 It is important to note that other approaches may be used to 468 configure CoAP endpoints with relevant group information. These 469 alternate approaches may support a subset or super-set of the 470 membership configuration RESTful interface described in this 471 document. For example, a simple interface to just read the endpoint 472 group information may be implemented via a classical Management 473 Information Base (MIB) approach (e.g. following approach of 474 [RFC3433]). 476 2.7.2.1. CoAP-Group Resource Type and Media Type 478 CoAP endpoints implementing the membership configuration RESTful 479 interface MUST support the CoAP group configuration Internet Media 480 Type "application/coap-group+json" (Section 6.2). 482 A resource offering this representation can be annotated for direct 483 discovery [RFC6690] using the resource type (rt) "core.gp" where "gp" 484 is shorthand for "group" (Section 6.1). An authorized client uses 485 this media type to query/manage group membership of a CoAP endpoint 486 as defined in the following subsections. 488 The group configuration resource and its sub-resources have a JSON- 489 based content format (as indicated by the "application/coap- 490 group+json" media type). The resource includes zero or more group 491 membership JSON objects in a format as defined in Section 2.7.2.4. A 492 group membership JSON object contains one or more key/value pairs as 493 defined below. It represents a single IP multicast group membership 494 for the CoAP endpoint. 496 Examples of four different group membership objects are: 498 { "n": "All-Devices.floor1.west.bldg6.example.com", 499 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 501 { "n": "sensors.floor2.east.bldg6.example.com" } 503 { "n": "coap-test", 504 "a": "224.0.1.187:56789" } 506 { "a": "[ff15::c0a7:15:c00l]" } 508 The OPTIONAL "n" key/value pair stands for "name" and identifies the 509 group with a hostname, for example a FQDN. The OPTIONAL "a" key/ 510 value pair specifies the IP multicast address (and optionally the 511 port number) of the group. It contains an IPv4 address (in dotted 512 decimal notation) or an IPv6 address. The following ABNF rule can be 513 used for parsing the address, referring to the definitions in 514 Section 6 of [RFC7252] and [RFC3986]. 516 group-address = IPv4address [ ":" port ] 517 / "[" IPv6address "]" [":" port ] 519 If the port number is not provided then it is assumed to be the 520 default CoAP port (5683). In a response, the "a" key/value pair 521 SHOULD be included if the IP address is known at the time of 522 generating the response, and MUST NOT be included if unknown. If the 523 "a" value is not provided in a request, the "n" value in the same 524 group membership object SHOULD be a valid hostname with optional port 525 number that can be translated to an IP multicast address via DNS 526 resolution, as follows: 528 group-name = host [ ":" port ] 530 If the port number is not provided then it is assumed to be the 531 default CoAP port (5683). At least one of the "n"/"a" pairs MUST be 532 given per group object. 534 After any change on a Group configuration resource, the endpoint MUST 535 effect registration/de-registration from the corresponding IP 536 multicast group(s) as soon as possible. 538 2.7.2.2. Creating a new multicast group membership (POST) 540 Method: POST 541 URI Template: /{+gp} 542 Location-URI Template: /{+gp}/{index} 543 URI Template Variables: 544 gp - Group Configuration Function Set path (mandatory). 545 index - Group index, SHOULD be a string of 1 or 2 alphanumerical 546 characters. It MUST be generated as locally unique. 548 Example: 549 Req: POST /coap-group 550 Content-Format: application/coap-group+json 551 { "n": "All-Devices.floor1.west.bldg6.example.com", 552 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 553 Res: 2.01 Created 554 Location-Path: /coap-group/12 556 For the 'gp' variable it is recommended to use the path "coap-group" 557 by default. If the "a" key/value pair is given, this takes priority 558 and the "n" pair becomes informational. If only the "n" pair is 559 given, the CoAP endpoint may perform DNS resolution (if supported) to 560 obtain the IP multicast address from the hostname. 562 After any change on a Group configuration resource, the endpoint MUST 563 effect registration/de-registration from the corresponding IP 564 multicast group(s) as soon as possible. When a POST payload contains 565 in "a" an IP multicast address to which the endpoint is already 566 subscribed, no change to that subscription is needed. 568 2.7.2.3. Deleting a single group membership (DELETE) 570 Method: DELETE 571 URI Template: {+location} 572 URI Template Variables: 573 location - The Location-Path returned by the CoAP server as a result 574 of a successful group creation. 576 Example: 577 Req: DELETE /coap-group/12 578 Res: 2.02 Deleted 580 2.7.2.4. Reading all group memberships at once (GET) 582 A (unicast) GET on the CoAP-group resource returns a JSON object 583 containing multiple keys and values, the keys being group indices and 584 the values the corresponding group objects. Each group object is a 585 group membership JSON object that indicates one IP multicast group 586 membership. So, the group index is used as a JSON key to point to 587 the group membership object, as shown below. 589 Method: GET 590 URI Template: /{+gp} 591 URI Template Variables: 592 gp - see earlier definition 594 Example: 595 Req: GET /coap-group 596 Res: 2.05 Content 597 Content-Format: application/coap-group+json 598 { "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" }, 599 "11":{ "n": "sensors.floor1.west.bldg6.example.com", 600 "a": "[ff15::4200:f7fe:ed37:25cb]" }, 601 "12":{ "n": "All-Devices.floor1.west.bldg6.example.com", 602 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 603 } 605 Note: the returned IPv6 address may be a different string from the 606 one originally submitted in group membership creation, due to 607 different choices in IPv6 string representation formatting that may 608 be allowed for the same address (see [RFC5952]). 610 2.7.2.5. Reading a single group membership (GET) 612 Method: GET 613 URI Template 1: {+location} 614 URI Template 2: /{+gp}/{index} 615 URI Template Variables: 616 location, gp, index - see earlier definitions 618 Example: 619 Req: GET /coap-group/12 620 Res: 2.05 Content 621 Content-Format: application/coap-group+json 622 {"n": "All-Devices.floor1.west.bldg6.example.com", 623 "a": "[ff15::4200:f7fe:ed37:abcd]:4567"} 625 2.7.2.6. Creating/updating all group memberships at once (PUT) 627 A (unicast) PUT with a group configuration media type as payload will 628 replace all current group memberships in the endpoint with the new 629 ones defined in the PUT request. This operation SHOULD only be used 630 to delete or update group membership objects for which the CoAP 631 client, invoking this operation, is responsible. The responsibility 632 is based on application level knowledge. For example, a 633 commissioning tool will be responsible for any group membership 634 objects that it created. 636 Method: PUT 637 URI Template: /{+gp} 638 URI Template Variables: 639 gp - see earlier definition 641 Example: (replacing all existing group memberships with two new groups) 642 Req: PUT /coap-group 643 Content-Format: application/coap-group+json 644 { "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" }, 645 "2":{ "a": "[ff15::4200:f7fe:ed37:5678]" } 646 } 647 Res: 2.04 Changed 649 Example: (clearing all group memberships at once) 650 Req: PUT /coap-group 651 Content-Format: application/coap-group+json 652 {} 653 Res: 2.04 Changed 655 After a successful PUT on the Group configuration resource, the 656 endpoint MUST effect registration to any new IP multicast group(s) 657 and de-registration from any previous IP multicast group(s), i.e. not 658 anymore present in the new memberships, as soon as possible. Also it 659 MUST take into account the group indices present in the new resource 660 during the generation of any new unique group indices in the future. 662 2.7.2.7. Updating a single group membership (PUT) 664 A (unicast) PUT with a group membership JSON object will replace an 665 existing group membership in the endpoint with the new one defined in 666 the PUT request. This can be used to update the group membership. 668 Method: PUT 669 URI Template 1: {+location} 670 URI Template 2: /{+gp}/{index} 671 URI Template Variables: 672 location, gp, index - see earlier definitions 674 Example: (group name and IP multicast port change) 675 Req: PUT /coap-group/12 676 Content-Format: application/coap-group+json 677 {"n": "All-My-Devices.floor1.west.bldg6.example.com", 678 "a": "[ff15::4200:f7fe:ed37:abcd]"} 679 Res: 2.04 Changed 681 After a successful PUT on the Group configuration resource, the 682 endpoint MUST effect registration to any new IP multicast group(s) 683 and de-registration from any previous IP multicast group(s), i.e. not 684 anymore present in the new membership, as soon as possible. 686 2.8. Request Acceptance and Response Suppression Rules 688 CoAP [RFC7252] and CoRE Link Format [RFC6690] define normative 689 behaviors for: 691 1. IP multicast request acceptance - in which cases a CoAP request 692 is accepted and executed, and when not. 694 2. IP multicast response suppression - in which cases the CoAP 695 response to an already-executed request is returned to the 696 requesting endpoint, and when not. 698 A CoAP response differs from a CoAP ACK; ACKs are never sent by 699 servers in response to an IP multicast CoAP request. This section 700 first summarizes these normative behaviors and then presents 701 additional guidelines for response suppression. Also a number of IP 702 multicast example applications are given to illustrate the overall 703 approach. 705 To apply any rules for request and/or response suppression, a CoAP 706 server must be aware that an incoming request arrived via IP 707 multicast by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]. 709 For IP multicast request acceptance, the REQUIRED behaviors are: 711 o A server SHOULD NOT accept an IP multicast request that cannot be 712 "authenticated" in some way (cryptographically or by some 713 multicast boundary limiting the potential sources) [RFC7252]. See 714 Section 5.3 for examples of multicast boundary limiting methods. 716 o A server SHOULD NOT accept an IP multicast discovery request with 717 a query string (as defined in CoRE Link Format [RFC6690]) if 718 filtering ([RFC6690]) is not supported by the server. 720 o A server SHOULD NOT accept an IP multicast request that acts on a 721 specific resource for which IP multicast support is not required. 722 (Note that for the resource "/.well-known/core", IP multicast 723 support is required if "multicast resource discovery" is supported 724 as specified in section 1.2.1 of [RFC6690]). Implementers are 725 advised to disable IP multicast support by default on any other 726 resource, until explicitly enabled by an application or by 727 configuration.) 729 o Otherwise accept the IP multicast request. 731 For IP multicast response suppression, the REQUIRED behaviors are: 733 o A server SHOULD NOT respond to an IP multicast discovery request 734 if the filter specified by the request's query string does not 735 match. 737 o A server MAY choose not to respond to an IP multicast request, if 738 there's nothing useful to respond (e.g., error or empty response). 740 o Otherwise respond to the IP multicast request. 742 The above response suppression behaviors are complemented by the 743 following guidelines. CoAP servers SHOULD implement configurable 744 response suppression, enabling at least the following options per 745 resource that supports IP multicast requests: 747 o Suppression of all 2.xx success responses; 749 o Suppression of all 4.xx client errors; 751 o Suppression of all 5.xx server errors; 752 o Suppression of all 2.05 responses with empty payload. 754 A number of CoAP group communication example applications are given 755 below to illustrate how to make use of response suppression: 757 o CoAP resource discovery: Suppress 2.05 responses with empty 758 payload and all 4.xx and 5.xx errors. 760 o Lighting control: Suppress all 2.xx responses after a lighting 761 change command. 763 o Update configuration data in a group of devices using group 764 communication PUT: No suppression at all. The client uses 765 collected responses to identify which group members did not 766 receive the new configuration; then attempts using CoAP CON 767 unicast to update those specific group members. Note that in this 768 case the client implements a "reliable group communication" (as 769 defined in Section 1.3) function using additional, non- 770 standardized functions above the CoAP layer. 772 o IP multicast firmware update by sending blocks of data: Suppress 773 all 2.xx and 5.xx responses. After having sent all IP multicast 774 blocks, the client checks each endpoint by unicast to identify 775 which data blocks are still missing in each endpoint. 777 o Conditional reporting for a group (e.g., sensors) based on a group 778 URI query: Suppress all 2.05 responses with empty payload (i.e., 779 if a query produces no matching results). 781 2.9. Congestion Control 783 CoAP group communication requests may result in a multitude of 784 responses from different nodes, potentially causing congestion. 785 Therefore both the sending of IP multicast requests, and the sending 786 of the unicast CoAP responses to these multicast requests should be 787 conservatively controlled. 789 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 790 the following measures: 792 o A server MAY choose not to respond to an IP multicast request if 793 there's nothing useful to respond (e.g., error or empty response). 794 See Section 2.8 for more detailed guidelines on response 795 suppression. 797 o A server SHOULD limit the support for IP multicast requests to 798 specific resources where multicast operation is required. 800 o An IP multicast request MUST be Non-confirmable. 802 o A response to an IP multicast request SHOULD be Non-confirmable 803 (Section 5.2.3 of [RFC7252]). 805 o A server does not respond immediately to an IP multicast request, 806 but SHOULD first wait for a time that is randomly picked within a 807 predetermined time interval called the Leisure. 809 Additional guidelines to reduce congestion risks defined in this 810 document are: 812 o A server in an LLN should only support group communication GET for 813 resources that are small. For example, the payload of the 814 response is limited to approximately 5% of the IP Maximum Transmit 815 Unit (MTU) size so it fits into a single link-layer frame in case 816 6LoWPAN [RFC4944] is used. 818 o A server can minimize the payload length in response to a group 819 communication GET on "/.well-known/core" by using hierarchy in 820 arranging link descriptions for the response. An example of this 821 is given in Section 5 of [RFC6690]. 823 o A server can also minimize the payload length of a response to a 824 group communication GET (e.g., on "/.well-known/core") using CoAP 825 blockwise transfers [I-D.ietf-core-block], returning only a first 826 block of the CoRE Link Format description. For this reason, a 827 CoAP client sending an IP multicast CoAP request to "/.well-known/ 828 core" SHOULD support core-block. 830 o A client should use CoAP group communication with the smallest 831 possible IP multicast scope that fulfills the application needs. 832 As an example, site-local scope is always preferred over global 833 scope IP multicast if this fulfills the application needs. 835 More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944] 836 are given in Section 4.5. 838 2.10. Proxy Operation 840 CoAP [RFC7252] allows a client to request a forward-proxy to process 841 its CoAP request. For this purpose the client either specifies the 842 request group URI as a string in the Proxy-URI option, or it 843 specifies the Proxy-Scheme option with the group URI constructed from 844 the usual Uri-* options. This approach works well for unicast 845 requests. However, there are certain issues and limitations of 846 processing the (unicast) responses to a CoAP group communication 847 request made in this manner through a proxy. 849 A proxy may buffer all the individual (unicast) responses to a CoAP 850 group communication request and then send back only a single 851 (aggregated) response to the client. However there are some issues 852 with this aggregation approach: 854 o Aggregation of (unicast) responses to a CoAP group communication 855 request in a proxy is difficult. This is because the proxy does 856 not know how many members there are in the group, or how many 857 group members will actually respond. Also the proxy does not know 858 how long to wait before deciding to send back the aggregated 859 response to the client. 861 o There is no default format defined in CoAP for aggregation of 862 multiple responses into a single response. 864 Alternatively, if a proxy follows directly the specification for a 865 CoAP Proxy [RFC7252], the proxy would simply forward all the 866 individual (unicast) responses to a CoAP group communication request 867 to the client (i.e., no aggregation). There are also issues with 868 this approach: 870 o The client may be confused as it may not have known that the 871 Proxy-URI contained a group URI target. That is, the client may 872 be expecting only one (unicast) response but instead receives 873 multiple (unicast) responses potentially leading to fault 874 conditions in the application. 876 o Each individual CoAP response will appear to originate (IP Source 877 address) from the CoAP Proxy, and not from the server that 878 produced the response. This makes it impossible for the client to 879 identify the server that produced each response. 881 Due to above issues, a guideline is defined here that a CoAP Proxy 882 SHOULD NOT support processing an IP multicast CoAP request but rather 883 return a 501 (Not Implemented) response in such case. The exception 884 case here (i.e., to process it) is allowed under following 885 conditions: 887 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 888 proxied IP multicast requests by specific client(s). 890 o The proxy SHOULD return individual (unicast) CoAP responses to the 891 client (i.e., not aggregated). The exception case here occurs 892 when a (future) standardized aggregation format is being used. 894 o It MUST be known to the person/entity doing the configuration of 895 the proxy, or otherwise verified in some way, that the client 896 configured in the whitelist supports receiving multiple responses 897 to a proxied unicast CoAP request. 899 2.11. Exceptions 901 CoAP group communication using IP multicast offers improved network 902 efficiency and latency amongst other benefits. However, group 903 communication may not always be implementable in a given network. 904 The primary reason for this will be that IP multicast is not (fully) 905 supported in the network. 907 For example, if only the RPL protocol [RFC6550] is used in a network 908 with its optional multicast support disabled, there will be no IP 909 multicast routing at all. The only multicast that works in this case 910 is link-local IPv6 multicast. This implies that any CoAP group 911 communication request will be delivered to nodes on the local link 912 only, regardless of the scope value used in the IPv6 destination 913 address. 915 3. Use Cases and Corresponding Protocol Flows 917 3.1. Introduction 919 The use of CoAP group communication is shown in the context of the 920 following two use cases and corresponding protocol flows: 922 o Discovery of RD [I-D.ietf-core-resource-directory]: discovering 923 the local CoAP RD which contains links to resources stored on 924 other CoAP servers [RFC6690]. 926 o Lighting Control: synchronous operation of a group of 927 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 929 3.2. Network Configuration 931 To illustrate the use cases we define two IPv6 network 932 configurations. Both are based on the topology as shown in Figure 1. 933 The two configurations using this topology are: 935 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 936 6LoWPAN Border Routers (6LBRs, [RFC6775]). 938 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 939 multicast-capable Ethernet routers. 941 Both configurations are further specified by the following: 943 o A large room (Room-A) with three lights (Light-1, Light-2, Light- 944 3) controlled by a Light Switch. The devices are organized into 945 two subnets. In reality, there could be more lights (up to 946 several hundreds) but these are not shown for clarity. 948 o Light-1 and the Light Switch are connected to a router (Rtr-1). 950 o Light-2 and the Light-3 are connected to another router (Rtr-2). 952 o The routers are connected to an IPv6 network backbone which is 953 also multicast enabled. In the general case, this means the 954 network backbone and Rtr-1/Rtr-2 support a PIM based multicast 955 routing protocol, and Multicast Listener Discovery (MLD) for 956 forming groups. 958 o A CoAP RD is connected to the network backbone. 960 o The DNS server is optional. If the server is there (connected to 961 the network backbone) then certain DNS based features are 962 available (e.g., DNS resolution of hostname to IP multicast 963 address). If the DNS server is not there, then different 964 provisioning of the network is required (e.g., IP multicast 965 addresses are hard-coded into devices, or manually configured, or 966 obtained via a service discovery method). 968 o A Controller (CoAP client) is connected to the backbone, which is 969 able to control various building functions including lighting. 971 ################################################ 972 # ********************** Room-A # 973 # ** Subnet-1 ** # Network 974 # * ** # Backbone 975 # * +----------+ * # | 976 # * | Light |-------+ * # | 977 # * | Switch | | * # | 978 # * +----------+ +---------+ * # | 979 # * | Rtr-1 |-----------------------------+ 980 # * +---------+ * # | 981 # * +----------+ | * # | 982 # * | Light-1 |--------+ * # | 983 # * +----------+ * # | 984 # ** ** # | 985 # ************************** # | 986 # # | 987 # ********************** # +------------+ | 988 # ** Subnet-2 ** # | DNS Server | | 989 # * ** # | (Optional) |--+ 990 # * +----------+ * # +------------+ | 991 # * | Light-2 |-------+ * # | 992 # * | | | * # | 993 # * +----------+ +---------+ * # | 994 # * | Rtr-2 |-----------------------------+ 995 # * +---------+ * # | 996 # * +----------+ | * # | 997 # * | Light-3 |--------+ * # | 998 # * +----------+ * # +------------+ | 999 # ** ** # | Controller |--+ 1000 # ************************** # | Client | | 1001 ################################################ +------------+ | 1002 +------------+ | 1003 | CoAP | | 1004 | Resource |-----------------+ 1005 | Directory | 1006 +------------+ 1008 Figure 1: Network Topology of a Large Room (Room-A) 1010 3.3. Discovery of Resource Directory 1012 The protocol flow for discovery of the CoAP RD for the given network 1013 (of Figure 1) is shown in Figure 2: 1015 o Light-2 is installed and powered on for the first time. 1017 o Light-2 will then search for the local CoAP RD by sending out a 1018 group communication GET request (with the "/.well-known/ 1019 core?rt=core.rd" request URI) to the site-local "All CoAP Nodes" 1020 multicast address (FF05:::FD). 1022 o This multicast message will then go to each node in subnet-2. 1023 Rtr-2 will then forward it into to the Network Backbone where it 1024 will be received by the CoAP RD. All other nodes in subnet-2 will 1025 ignore the group communication GET request because it is qualified 1026 by the query string "?rt=core.rd" (which indicates it should only 1027 be processed by the endpoint if it contains a resource of type 1028 "core.rd"). 1030 o The CoAP RD will then send back a unicast response containing the 1031 requested content, which is a CoRE Link Format representation of a 1032 resource of type "core.rd". 1034 o Note that the flow is shown only for Light-2 for clarity. Similar 1035 flows will happen for Light-1, Light-3 and the Light Switch when 1036 they are first installed. 1038 The CoAP RD may also be discovered by other means such as by assuming 1039 a default location (e.g., on a 6LBR), using DHCP, anycast address, 1040 etc. However, these approaches do not invoke CoAP group 1041 communication so are not further discussed here. (See 1042 [I-D.ietf-core-resource-directory] for more details). 1044 For other discovery use cases such as discovering local CoAP servers, 1045 services or resources, CoAP group communication can be used in a 1046 similar fashion as in the above use case. For example, Link-Local 1047 (LL), admin-local or site-local scoped discovery can be done this 1048 way. 1050 Light CoAP 1051 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD 1052 | | | | | | | 1053 | | | | | | | 1054 ********************************** | | | 1055 * Light-2 is installed * | | | 1056 * and powers on for first time * | | | 1057 ********************************** | | | 1058 | | | | | | | 1059 | | | | | | | 1060 | | COAP NON Mcast(GET | | 1061 | | /.well-known/core?rt=core.rd) | | 1062 | |--------->-------------------------------->| | 1063 | | | | | |--------->| 1064 | | | | | | | 1065 | | | | | | | 1066 | | COAP NON (2.05 Content | | 1067 | | ;rt="core.rd";ins="Primary") |<---------| 1068 | |<------------------------------------------| | 1069 | | | | | | | 1071 Figure 2: Resource Directory Discovery via Multicast Request 1073 3.4. Lighting Control 1075 The protocol flow for a building automation lighting control scenario 1076 for the network (Figure 1) is shown in Figure 3. The network is 1077 assumed to be in a 6LoWPAN configuration. Also, it is assumed that 1078 the CoAP servers in each Light are configured to suppress CoAP 1079 responses for any IP multicast CoAP requests related to lighting 1080 control. (See Section 2.8 for more details on response suppression 1081 by a server.) 1083 In addition, Figure 4 shows a protocol flow example for the case that 1084 servers do respond to a lighting control IP multicast request with 1085 (unicast) CoAP NON responses. There are two success responses and 1086 one 5.00 error response. In this particular case, the Light Switch 1087 does not check that all Lights in the group received the IP multicast 1088 request by examining the responses. This is because the Light Switch 1089 is not configured with an exhaustive list of the IP addresses of all 1090 Lights belonging to the group. However, based on received error 1091 responses it could take additional action such as logging a fault or 1092 alerting the user via its LCD display. In case a CoAP message is 1093 delivered multiple times to a Light, the subsequent CoAP messages can 1094 be filtered out as duplicates, based on the CoAP Message ID. 1096 Reliability of IP multicast is not guaranteed. Therefore, one or 1097 more lights in the group may not have received the CoAP control 1098 request due to packet loss. In this use case there is no detection 1099 nor correction of such situations: the application layer expects that 1100 the IP multicast forwarding/routing will be of sufficient quality to 1101 provide on average a very high probability of packet delivery to all 1102 CoAP endpoints in an IP multicast group. An example protocol to 1103 accomplish this using randomized retransmission is the MPL forwarding 1104 protocol for LLNs [I-D.ietf-roll-trickle-mcast]. 1106 We assume the following steps have already occurred before the 1107 illustrated flows: 1109 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 1110 all devices. The CoAP network is formed. 1112 2. Network configuration (application-independent): 6LBRs are 1113 configured with IP multicast addresses, or address blocks, to 1114 filter out or to pass through to/from the 6LoWPAN. 1116 3. Commissioning phase (application-related): The IP multicast 1117 address of the group (Room-A-Lights) has been configured in all 1118 the Lights and in the Light Switch. 1120 4. As an alternative to the previous step, when a DNS server is 1121 available, the Light Switch and/or the Lights have been 1122 configured with a group hostname which each nodes resolves to the 1123 above IP multicast address of the group. 1125 Note for the Commissioning phase: the switch's 6LoWPAN/CoAP software 1126 stack supports sending unicast, multicast or proxied unicast CoAP 1127 requests, including processing of the multiple responses that may be 1128 generated by an IP multicast CoAP request. 1130 Light Network 1131 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 1132 | | | | | | | 1133 | | | | | | | 1134 | | *********************** | | 1135 | | * User flips on * | | 1136 | | * light switch to * | | 1137 | | * turn on all the * | | 1138 | | * lights in Room A * | | 1139 | | *********************** | | 1140 | | | | | | | 1141 | | | | | | | 1142 | | | COAP NON Mcast(PUT, | | 1143 | | | Payload=lights ON) | | 1144 |<-------------------------------+--------->| | | 1145 ON | | | |-------------------->| 1146 | | | | | |<---------| 1147 | |<---------|<-------------------------------| | 1148 | ON ON | | | | 1149 ^ ^ ^ | | | | 1150 *********************** | | | | 1151 * Lights in Room-A * | | | | 1152 * turn on (nearly * | | | | 1153 * simultaneously) * | | | | 1154 *********************** | | | | 1155 | | | | | | | 1157 Figure 3: Light Switch Sends Multicast Control Message 1158 Light Network 1159 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 1160 | | | | | | | 1161 | COAP NON (2.04 Changed) | | | | 1162 |------------------------------->| | | | 1163 | | | | | | | 1164 | | | | | | | 1165 | COAP NON (2.04 Changed) | | | 1166 | |------------------------------------------>| | 1167 | | | | | |--------->| 1168 | | | | |<--------------------| 1169 | | | |<---------| | | 1170 | | | | | | | 1171 | | COAP NON (5.00 Internal Server Error) | 1172 | | |------------------------------->| | 1173 | | | | | |--------->| 1174 | | | | |<--------------------| 1175 | | | |<---------| | | 1176 | | | | | | | 1178 Figure 4: Lights (Optionally) Respond to Multicast CoAP Request 1180 Another, but similar, lighting control use case is shown in Figure 5. 1181 In this case a controller connected to the Network Backbone sends a 1182 CoAP group communication request to turn on all lights in Room-A. 1183 Every Light sends back a CoAP response to the Controller after being 1184 turned on. 1186 Network 1187 Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller 1188 | | | | | | | 1189 | | | | | COAP NON Mcast(PUT, 1190 | | | | | Payload=lights ON) 1191 | | | | | |<-------| 1192 | | | |<----------<---------| | 1193 |<--------------------------------| | | | 1194 ON | | | | | | 1195 | |<----------<---------------------| | | 1196 | ON ON | | | | 1197 ^ ^ ^ | | | | 1198 *********************** | | | | 1199 * Lights in Room-A * | | | | 1200 * turn on (nearly * | | | | 1201 * simultaneously) * | | | | 1202 *********************** | | | | 1203 | | | | | | | 1204 | | | | | | | 1205 | COAP NON (2.04 Changed) | | | | 1206 |-------------------------------->| | | | 1207 | | | |-------------------->| | 1208 | | COAP NON (2.04 Changed) | |------->| 1209 | |-------------------------------->| | | 1210 | | | | |--------->| | 1211 | | | COAP NON (2.04 Changed) |------->| 1212 | | |--------------------->| | | 1213 | | | | |--------->| | 1214 | | | | | |------->| 1215 | | | | | | | 1217 Figure 5: Controller On Backbone Sends Multicast Control Message 1219 3.5. Lighting Control in MLD Enabled Network 1221 The use case of previous section can also apply in networks where 1222 nodes support the MLD protocol [RFC3810]. The Lights then take on 1223 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 1224 Routers. In the Ethernet based network configuration, MLD may be 1225 available on all involved network interfaces. Use of MLD in the 1226 6LoWPAN based configuration is also possible, but requires MLD 1227 support in all nodes in the 6LoWPAN. In current 6LoWPAN 1228 implementations, MLD is however not supported. 1230 The resulting protocol flow is shown in Figure 6. This flow is 1231 executed after the commissioning phase, as soon as Lights are 1232 configured with a group address to listen to. The (unicast) MLD 1233 Reports may require periodic refresh activity as specified by the MLD 1234 protocol. In the figure, LL denotes Link Local communication. 1236 After the shown sequence of MLD Report messages has been executed, 1237 both Rtr-1 and Rtr-2 are automatically configured to forward IP 1238 multicast traffic destined to Room-A-Lights onto their connected 1239 subnet. Hence, no manual Network Configuration of routers, as 1240 previously indicated in Section 3.4, is needed anymore. 1242 Light Network 1243 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 1244 | | | | | | | 1245 | | | | | | | 1246 | | | | | | | 1247 | MLD Report: Join | | | | | 1248 | Group (Room-A-Lights) | | | | 1249 |---LL------------------------------------->| | | 1250 | | | | |MLD Report: Join | 1251 | | | | |Group (Room-A-Lights)| 1252 | | | | |---LL---->----LL---->| 1253 | | | | | | | 1254 | | MLD Report: Join | | | | 1255 | | Group (Room-A-Lights) | | | 1256 | |---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-----+---LL---->| 1265 | | | | | | | 1266 | | | | | | | 1268 Figure 6: Joining Lighting Groups Using MLD 1270 3.6. Commissioning the Network Based On Resource Directory 1272 This section outlines how devices in the lighting use case (both 1273 Switches and Lights) can be commissioned, making use of Resource 1274 Directory [I-D.ietf-core-resource-directory] and its group 1275 configuration feature. 1277 Once the Resource Directory (RD) is discovered, the Switches and 1278 Lights need to be discovered and their groups need to be defined. 1280 For the commissioning of these devices, a commissioning tool can be 1281 used that defines the entries in the RD. The commissioning tool has 1282 the authority to change the contents of the RD and the Light/Switch 1283 nodes. DTLS based security is used by the commissioning tool to 1284 modify operational data in RD, Switches and Lights. 1286 In our particular use case, a group of three lights is defined with 1287 one IP multicast address and hostname "Room- 1288 A-Lights.floor1.west.bldg6.example.com". The commissioning tool has 1289 a list of the three lights and the associated IP multicast address. 1290 For each light in the list the tool learns the IP address of the 1291 light and instructs the RD with three (unicast) POST commands to 1292 store the endpoints associated with the three lights as prescribed by 1293 the RD specification [I-D.ietf-core-resource-directory]. Finally the 1294 commissioning tool defines the group in the RD to contain these three 1295 endpoints. Also the commissioning tool writes the IP multicast 1296 address in the Light endpoints with, for example, the (unicast) POST 1297 command discussed in Section 2.7.2.2. 1299 The light switch can discover the group in RD and thus learn the IP 1300 multicast address of the group. The light switch will use this 1301 address to send CoAP group communication requests to the members of 1302 the group. When the message arrives the Lights should recognize the 1303 IP multicast address and accept the message. 1305 4. Deployment Guidelines 1307 This section provides guidelines how IP multicast based CoAP group 1308 communication can be deployed in various network configurations. 1310 4.1. Target Network Topologies 1312 CoAP group communication can be deployed in various network 1313 topologies. First, the target network may be a traditional IP 1314 network, or a LLN such as a 6LoWPAN network, or consist of mixed 1315 traditional/constrained network segments. Second, it may be a single 1316 subnet only or multi-subnet; e.g., multiple 6LoWPAN networks joined 1317 by a single backbone LAN. Third, a wireless network segment may have 1318 all its nodes reachable in a single IP hop (fully connected), or it 1319 may require multiple IP hops for some pairs of nodes to reach each 1320 other. 1322 Each topology may pose different requirements on the configuration of 1323 routers and protocol(s), in order to enable efficient CoAP group 1324 communication. To enable all the above target network topologies, an 1325 implementation of CoAP group communication needs to allow: 1327 1. Routing/forwarding of IP multicast packets over multiple hops 1328 2. Routing/forwarding of IP multicast packets over subnet boundaries 1329 between traditional and constrained (e.g. LLN) networks. 1331 The remainder of this section discusses solutions to enable both 1332 features. 1334 4.2. Networks Using the MLD Protocol 1336 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1337 unaware of the specific IP multicast routing/forwarding protocol 1338 being used. When such a host needs to join a specific (CoAP) 1339 multicast group, it requires a way to signal to IP multicast routers 1340 which IP multicast traffic it wants to receive. 1342 The Multicast Listener Discovery (MLD) protocol [RFC3810] (see 1343 Appendix A) is the standard IPv6 method to achieve this; therefore 1344 this approach should be used on traditional IP networks. CoAP server 1345 nodes would then act in the role of MLD Multicast Address Listener. 1347 The guidelines from [RFC6636] on tuning of MLD for mobile and 1348 wireless networks may be useful when implementing MLD in LLNs. 1349 However, on LLNs and 6LoWPAN networks the use of MLD may not be 1350 feasible at all due to constraints on code size, memory, or network 1351 capacity. 1353 4.3. Networks Using RPL Multicast Without MLD 1355 It is assumed in this section that the MLD protocol is not 1356 implemented in a network, for example due to resource constraints. 1357 The RPL routing protocol (see Section 12 of [RFC6550]) defines the 1358 advertisement of IP multicast destinations using DAO messages and 1359 routing of multicast IPv6 packets based on this. It requires the RPL 1360 Mode of Operation (MOP) to be 3 (Storing Mode with multicast 1361 support). 1363 Hence, RPL DAO can be used by CoAP nodes that are RPL Routers, or are 1364 RPL Leaf Nodes, to advertise IP multicast group membership to parent 1365 routers. Then, the RPL protocol is used to route IP multicast CoAP 1366 requests over multiple hops to the correct CoAP servers. 1368 The same DAO mechanism can be used to convey IP multicast group 1369 membership information to an edge router (e.g., 6LBR), in case the 1370 edge router is also the root of the RPL DODAG. This is useful 1371 because the edge router then learns which IP multicast traffic it 1372 needs to pass through from the backbone network into the LLN subnet. 1373 In 6LoWPAN networks, such selective "filtering" helps to avoid 1374 congestion of a 6LoWPAN subnet by IP multicast traffic from the 1375 traditional backbone IP network. 1377 4.4. Networks Using MPL Forwarding Without MLD 1379 The MPL forwarding protocol [I-D.ietf-roll-trickle-mcast] can be used 1380 for propagation of IPv6 multicast packets to all MPL Forwarders 1381 within a predefined network domain, over multiple hops. MPL is 1382 designed to work in LLNs. In this section it is again assumed that 1383 Multicast Listener Discovery (MLD) is not implemented in the network, 1384 for example due to resource limitations in an LLN. 1386 The purpose of MPL is to let a predefined group of Forwarders 1387 collectively work towards the goal of distributing an IPv6 multicast 1388 packet throughout an MPL Domain. (A Forwarder node may be associated 1389 to multiple MPL Domains at the same time.) So it would appear there 1390 is no need for CoAP servers to advertise their multicast group 1391 membership, since any IP multicast packet that enters the MPL Domain 1392 is distributed to all MPL Forwarders without regard to what multicast 1393 addresses the individual nodes are listening to. 1395 However, if an IP multicast request originates just outside the MPL 1396 Domain, the request will not be propagated by MPL. An example of 1397 such a case is the network topology of Figure 1 where the Subnets are 1398 6LoWPAN subnets and per 6LoWPAN subnet one Realm-Local 1399 ([I-D.droms-6man-multicast-scopes]) MPL Domain is defined. The 1400 backbone network in this case is not part of any MPL Domain. 1402 This situation can become a problem in building control use cases. 1403 For example, when the Controller Client needs to send a single IP 1404 multicast request to the group Room-A-Lights. By default, the 1405 request would be blocked by Rtr-1 and by Rtr-2, and not enter the 1406 Realm-Local MPL Domains associated to Subnet-1 and Subnet-2. The 1407 reason is that Rtr-1 and Rtr-2 do not have the knowledge that devices 1408 in Subnet-1/2 want to listen for IP packets destined to IP multicast 1409 group Room-A-Lights. 1411 To solve the above issue, the following solutions could be applied: 1413 1. Extend the MPL Domain. E.g. in above example, include the 1414 Network Backbone to be part of each of the two MPL Domains. Or 1415 in above example, create just a single MPL Domain that includes 1416 both 6LoWPAN subnets plus the backbone link, which is possible 1417 since MPL is not tied to a single link-layer technology. 1419 2. Manual configuration of edge router(s) as MPL Seed(s) for 1420 specific IP multicast traffic. E.g. in above example, first 1421 configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the 1422 Room-A-Lights IP multicast group. This step allows any (other) 1423 routers on the backbone to learn that at least one node on the 1424 backbone link is interested to receive any IP multicast traffic 1425 to Room-A-Lights. Second, configure both routers to "inject" any 1426 IP multicast packets destined to group Room-A-Lights into the 1427 (Realm-Local) MPL Domain that is associated to that router. 1428 Third, configure both routers to propagate any IPv6 multicast 1429 packets originating from within their associated MPL Domain to 1430 the backbone, if at least one node on the backbone has indicated 1431 interest to receive such IPv6 packets (for which MLD is used on 1432 the backbone). 1434 3. Use an additional protocol/mechanism for injection of IP 1435 multicast traffic from outside an MPL Domain into that MPL 1436 Domain, based on IP multicast group subscriptions of Forwarders 1437 within the MPL Domain. Such protocol is currently not defined in 1438 [I-D.ietf-roll-trickle-mcast]. 1440 Concluding, MPL can be used directly in case all sources of IP 1441 multicast CoAP requests (CoAP clients) and also all the destinations 1442 (CoAP servers) are inside a single MPL Domain. Then, each source 1443 node acts as an MPL Seed. In all other cases, MPL can only be used 1444 with additional protocols and/or configuration on how IP multicast 1445 packets can be injected from outside into an MPL Domain. 1447 4.5. 6LoWPAN Specific Guidelines for the 6LBR 1449 To support multi-subnet scenarios for CoAP group communication, it is 1450 recommended that a 6LoWPAN Border Router (6LBR) will act in an MLD 1451 Router role on the backbone link. If this is not possible then the 1452 6LBR should be configured to act as an MLD Multicast Address Listener 1453 (see Appendix A) on the backbone link. 1455 5. Security Considerations 1457 This section describes the relevant security configuration for CoAP 1458 group communication using IP multicast. The threats to CoAP group 1459 communication are also identified and various approaches to mitigate 1460 these threats are summarized. 1462 5.1. Security Configuration 1464 As defined in [RFC7252], CoAP group communication based on IP 1465 multicast: 1467 o Will operate in CoAP NoSec (No Security) mode, until a future 1468 group security solution is developed (see also Section 5.3.3). 1470 o Will use "coap" scheme mode. The "coaps" scheme should only be 1471 used when a future group security solution is developed (see also 1472 Section 5.3.3). 1474 5.2. Threats 1476 Essentially the above configuration means that there is currently no 1477 security at the CoAP layer for group communication. This is due to 1478 the fact that the current DTLS based approach for CoAP is exclusively 1479 unicast oriented and does not support group security features such as 1480 group key exchange and group authentication. As a direct consequence 1481 of this, CoAP group communication is vulnerable to all attacks 1482 mentioned in [RFC7252] for IP multicast. 1484 5.3. Threat Mitigation 1486 The [RFC7252] identifies various threat mitigation techniques for 1487 CoAP group communication. In addition to those guidelines, it is 1488 recommended that for sensitive data or safety-critical control, a 1489 combination of appropriate link-layer security and administrative 1490 control of IP multicast boundaries should be used. Some examples are 1491 given below. 1493 5.3.1. WiFi Scenario 1495 In a home automation scenario (using WiFi), the WiFi encryption 1496 should be enabled to prevent rogue nodes from joining. The Customer 1497 Premise Equipment (CPE) that enables access to the Internet should 1498 also have its IP multicast filters set so that it enforces multicast 1499 scope boundaries to isolate local multicast groups from the rest of 1500 the Internet (e.g., as per [RFC6092]). In addition, the scope of the 1501 IP multicast should be set to be site-local or smaller scope. For 1502 site-local scope, the CPE will be an appropriate multicast scope 1503 boundary point. 1505 5.3.2. 6LoWPAN Scenario 1507 In a building automation scenario, a particular room may have a 1508 single 6LoWPAN network with a single Edge Router (6LBR). Nodes on 1509 the subnet can use link-layer encryption to prevent rogue nodes from 1510 joining. The 6LBR can be configured so that it blocks any incoming 1511 (6LoWPAN-bound) IP multicast traffic. Another example topology could 1512 be a multi-subnet 6LoWPAN in a large conference room. In this case, 1513 the backbone can implement port authentication (IEEE 802.1X) to 1514 ensure only authorized devices can join the Ethernet backbone. The 1515 access router to this secured network segment can also be configured 1516 to block incoming IP multicast traffic. 1518 5.3.3. Future Evolution 1520 In the future, to further mitigate the threats, the developing 1521 approach for DTLS-based IP multicast security for CoAP communications 1522 (see [I-D.keoh-dice-multicast-security]) or similar approaches should 1523 be considered. This will allow introduction of a secure mode of CoAP 1524 group communication, and use of the "coaps" scheme for that purpose. 1526 5.4. Pervasive Monitoring Considerations 1528 A key additional threat consideration for group communication is 1529 pointed to by [RFC7258] which warns of the dangers of pervasive 1530 monitoring. CoAP group communication which is built on top of IP 1531 multicast should pay particular heed to these dangers. This is 1532 because IP multicast is easier to intercept (e.g. and to secretly 1533 record) compared to unicast traffic. Also, CoAP traffic is meant for 1534 the Internet of Things. This means that CoAP traffic is often used 1535 for the control and monitoring of critical infrastructure (e.g. 1536 lights, alarms, etc.) which may be prime targets for attack. 1538 For example, an attacker may attempt to record all the CoAP traffic 1539 going over the smart grid (i.e. networked electrical utility) of a 1540 country and try to determine critical control nodes for further 1541 attacks. CoAP multicast traffic is inherently more vulnerable 1542 (compared to a unicast packet) as the same packet may be replicated 1543 over many links so there is a much higher probability of it getting 1544 captured by a pervasive monitoring system. 1546 One useful mitigation to pervasive monitoring is to restrict the 1547 scope of the IP multicast to the minimal scope that fulfills the 1548 application need. Thus, for example, site-local IP multicast scope 1549 is always preferred over global scope IP multicast if this fulfills 1550 the application needs. This approach has the added advantage that it 1551 coincides with the guidelines for minimizing congestion control (see 1552 Section 2.9. 1554 In the future, even if all the CoAP multicast traffic is encrypted 1555 (e.g. [I-D.keoh-dice-multicast-security]), an attacker may still 1556 attempt to capture the traffic and perform an off-line attack. 1557 Though of course having the multicast traffic protected is always 1558 desirable as it significantly raises the cost to an attacker (e.g. to 1559 break the encryption) versus unprotected multicast traffic. 1561 6. IANA Considerations 1562 6.1. New 'core.gp' Resource Type 1564 This memo registers a new resource type (rt) from the CoRE Parameters 1565 Registry called 'core.gp'. 1567 (Note to IANA/RFC Editor: This registration follows the process 1568 described in section 7.4 of [RFC6690]). 1570 Attribute Value: core.gp 1572 Description: Group Configuration resource. This resource is used to 1573 query/manage the group membership of a CoAP server. 1575 Reference: See Section 2.7.2. 1577 6.2. New 'coap-group+json' Internet Media Type 1579 This memo registers a new Internet Media Type for CoAP group 1580 configuration resource called 'application/coap-group+json'. 1582 (Note to IANA/RFC Editor: This registration follows the guidance from 1583 [RFC6839], and (last paragraph) of section 12.3 of [RFC7252]. 1585 Type name: application 1587 Subtype name: coap-group+json 1589 Required parameters: None 1591 Optional parameters: None 1593 Encoding considerations: 8bit UTF-8. 1595 JSON to be represented using UTF-8 which is 8bit compatible (and most 1596 efficient for resource constrained implementations). 1598 Security considerations: 1600 Denial of Service attacks could be performed by constantly 1601 (re-)setting the group configuration resource of a CoAP endpoint to 1602 different values. This will cause the endpoint to register (or de- 1603 register) from the related IP multicast group. To prevent this it is 1604 recommended that a form of authorization (making use of DTLS-secured 1605 CoAP) be used such that only authorized controllers are allowed by an 1606 endpoint to configure its group membership. 1608 Interoperability considerations: None 1609 Published specification: (This I-D when it becomes an RFC) 1611 Applications that use this media type: 1613 CoAP client and server implementations that wish to set/read the 1614 group configuration resource via 'application/coap-group+json' 1615 payload as described in Section 2.7.2. 1617 Additional Information: 1619 Magic number(s): None 1621 File extension(s): *.json 1623 Macintosh file type code(s): TEXT 1625 Intended usage: COMMON 1627 Restrictions on usage: None 1629 Author: CoRE WG 1631 Change controller: IETF 1633 7. Acknowledgements 1635 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1636 Castellani, Thomas Fossati, Bjoern Hoehrmann, Matthias Kovatsch, 1637 Guang Lu, Salvatore Loreto, Kerry Lynn, Andrew McGregor, Dale Seed, 1638 Zach Shelby, Peter van der Stok, Gengyu Wei, and Juan Carlos Zuniga 1639 for their helpful comments and discussions that have helped shape 1640 this document. 1642 8. References 1644 8.1. Normative References 1646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1647 Requirement Levels", BCP 14, RFC 2119, March 1997. 1649 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1650 Thyagarajan, "Internet Group Management Protocol, Version 1651 3", RFC 3376, October 2002. 1653 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1654 Management Information Base", RFC 3433, December 2002. 1656 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1657 "Advanced Sockets Application Program Interface (API) for 1658 IPv6", RFC 3542, May 2003. 1660 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1661 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1663 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1664 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1665 3986, January 2005. 1667 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1668 Architecture", RFC 4291, February 2006. 1670 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1671 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1672 Protocol Specification (Revised)", RFC 4601, August 2006. 1674 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1675 "Transmission of IPv6 Packets over IEEE 802.15.4 1676 Networks", RFC 4944, September 2007. 1678 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1679 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1680 March 2010. 1682 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1683 Address Text Representation", RFC 5952, August 2010. 1685 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1686 Customer Premises Equipment (CPE) for Providing 1687 Residential IPv6 Internet Service", RFC 6092, January 1688 2011. 1690 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1691 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1692 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1693 Lossy Networks", RFC 6550, March 2012. 1695 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1696 the Internet Group Management Protocol (IGMP) and 1697 Multicast Listener Discovery (MLD) for Routers in Mobile 1698 and Wireless Networks", RFC 6636, May 2012. 1700 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1701 Format", RFC 6690, August 2012. 1703 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1704 "Neighbor Discovery Optimization for IPv6 over Low-Power 1705 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1706 November 2012. 1708 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 1709 Structured Syntax Suffixes", RFC 6839, January 2013. 1711 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1712 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1713 2014. 1715 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1716 Application Protocol (CoAP)", RFC 7252, June 2014. 1718 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1719 Attack", BCP 188, RFC 7258, May 2014. 1721 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 1722 7320, July 2014. 1724 8.2. Informative References 1726 [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1727 1033, November 1987. 1729 [I-D.ietf-core-block] 1730 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1731 draft-ietf-core-block-15 (work in progress), July 2014. 1733 [I-D.ietf-roll-trickle-mcast] 1734 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1735 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1736 mcast-09 (work in progress), April 2014. 1738 [I-D.keoh-dice-multicast-security] 1739 Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. 1740 Rahman, "DTLS-based Multicast Security in Constrained 1741 Environments", draft-keoh-dice-multicast-security-08 (work 1742 in progress), July 2014. 1744 [I-D.ietf-core-resource-directory] 1745 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 1746 Directory", draft-ietf-core-resource-directory-01 (work in 1747 progress), December 2013. 1749 [I-D.droms-6man-multicast-scopes] 1750 Droms, R., "IPv6 Multicast Address Scopes", draft-droms- 1751 6man-multicast-scopes-02 (work in progress), July 2013. 1753 Appendix A. Multicast Listener Discovery (MLD) 1755 In order to extend the scope of IP multicast beyond link-local scope, 1756 an IP multicast routing or forwarding protocol has to be active in 1757 routers on an LLN. To achieve efficient IP multicast routing (i.e., 1758 avoid always flooding IP multicast packets), routers have to learn 1759 which hosts need to receive packets addressed to specific IP 1760 multicast destinations. 1762 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1763 IPv4 equivalent IGMP [RFC3376]) is today the method of choice used by 1764 an (IP multicast enabled) router to discover the presence of IP 1765 multicast listeners on directly attached links, and to discover which 1766 IP multicast addresses are of interest to those listening nodes. MLD 1767 was specifically designed to cope with fairly dynamic situations in 1768 which IP multicast listeners may join and leave at any time. 1770 [RFC6636] discusses optimal tuning of the parameters of MLD/IGMP for 1771 routers for mobile and wireless networks. These guidelines may be 1772 useful when implementing MLD in LLNs. 1774 Appendix B. Change Log 1776 [Note to RFC Editor: Please remove this section before publication.] 1778 Changes from ietf-19 to ietf-20: 1780 o Replaced obsolete reference [RFC 2616] by [RFC 7230]. 1782 o Replaced outdated reference draft-ietf-appsawg-uri-get-off-my-lawn 1783 by [RFC 7320] and moved to Normative reference. 1785 o Replaced outdated reference draft-ietf-core-coap by [RFC 7252]. 1787 o Moved [RFC 1033] to Informative reference. 1789 o Updated to latest revision numbers for informative draft 1790 references by regenerating file through xml2rfc tool. 1792 o Re-ran IETF spell check tool and corrected some minor spelling 1793 errors. 1795 o Various minor editorial updates. 1797 Changes from ietf-18 to ietf-19: 1799 o Added guideline on Token value re-use in section 2.5. 1801 o Updated section 5.1 (Security Configuration) and 5.3.3 (Future 1802 Security Evolution) to point to latest security developments 1803 happening in DICE WG for support of group security. 1805 o Added Pervasive Monitoring considerations in section 5.4. 1807 o Various editorial updates for improved readability. 1809 Changes from ietf-17 to ietf-18: 1811 o Extensive editorial updates based on WGLC comments by Thomas 1812 Fossati and Gengyu Wei. 1814 o Addressed ticket #361: Added text for single membership PUT 1815 section 2.7.2.7 (Updating a single group membership (PUT)). 1817 o Addressed ticket #360: Added text for server duties upon all-at- 1818 once PUT section 2.7.2.6 (Creating/updating all group memberships 1819 at once (PUT)). 1821 o Addressed ticket #359: Fixed requirements text for Section 2.7.2.2 1822 (Creating a new multicast group membership (POST)). 1824 o Addressed ticket #358: Fixed requirements text for Section 2.7.2.1 1825 (CoAP-Group Resource Type and Media Type). 1827 o Addressed ticket #357: Added that "IPv6 addresses of other scopes 1828 MAY be enabled" in section 2.2 (Group Definition and Naming). 1830 o Various editorial updates for improved readability. 1832 Changes from ietf-16 to ietf-17: 1834 o Added guidelines on joining of IPv6/IPv4 "All CoAP Nodes" 1835 multicast addresses (#356). 1837 o Added MUST support default port in case multicast discovery is 1838 available. 1840 o In section 2.1 (IP Multicast Background), clarified that IP 1841 multicast is not guaranteed and referenced a definition of 1842 Reliable Group Communication (#355). 1844 o Added section 2.5 (Messages and Responses) to clarify how 1845 responses are identified and how Token/MID are used in multicast 1846 CoAP. 1848 o In section 2.6.2 (RESTful Interface for Configuring Group 1849 Memberships), clarified that group management interface is an 1850 optional approach for dynamic commissioning and that other 1851 approaches can also be used if desired. 1853 o Updated section 2.6.2 (RESTful Interface for Configuring Group 1854 Memberships) to allow deletion of individual group memberships 1855 (#354). 1857 o Various editorial updates based on comments by Peter van der Stok. 1858 Removed reference to expired draft-vanderstok-core-dna at request 1859 of its author. 1861 o Various editorial updates for improved readability. 1863 Changes from ietf-15 to ietf-16: 1865 o In section 2.6.2, changed DELETE in group management interface to 1866 a PUT with empty JSON array to clear the list (#345). 1868 o In section 2.6.2, aligned the syntax for IP addresses to follow 1869 RFC 3986 URI syntax, which is also used by coap-18. This allows 1870 re-use of the parsing code for CoAP URIs for this purpose (#342). 1872 o Addressed some more editorial comments provided by Carsten Bormann 1873 in preparation for WGLC. 1875 o Various editorial updates for improved readability. 1877 Changes from ietf-14 to ietf-15: 1879 o In section 2.2, provided guidance on how implementers should parse 1880 URIs for group communication (#339). 1882 o In section 2.6.2.1, specified that for group membership 1883 configuration interface the "ip" (i.e. "a" parameter) key/value is 1884 not required when it is unknown (#338). 1886 o In section 2.6.2.1, specified that for group membership 1887 configuration interface the port configuration be defaulted to 1888 standard CoAP port 5683, and if not default then should follow 1889 standard notation (#340). 1891 o In section 2.6.2.1, specified that notation of IP address in group 1892 membership configuration interface should follow standard notation 1893 (#342). 1895 o In section 6.2, "coap-group+json" Media Type encoding simplified 1896 to just support UTF-8 (and not UTF-16 and UTF-32) (#344). 1898 o Various editorial updates for improved readability. 1900 Changes from ietf-13 to ietf-14: 1902 o Update to address final editorial comments from the Chair's review 1903 (by Carsten Bormann) of the draft. This included restructuring of 1904 Section 2.6 (Configuring Group Memberships) and Section 4 1905 (Deployment Guidelines) to make it easier to read. Also various 1906 other editorial changes. 1908 o Changed "ip" field to "a" in Section 2.6 (#337) 1910 Changes from ietf-12 to ietf-13: 1912 o Extensive editorial updates due to comments from the Chair's 1913 review (by Carsten Bormann) of the draft. The best way to see the 1914 changes will be to do a -Diff with Rev. 12. 1916 o The technical comments from the Chair's review will be addressed 1917 in a future revision after tickets are generated and the solutions 1918 are agreed to on the WG E-mail list. 1920 Changes from ietf-11 to ietf-12: 1922 o Removed reference to "CoAP Ping" in Section 3.5 (Group Member 1923 Discovery) and replaced it with the more efficient support of 1924 discovery of groups and group members via the CORE RD as suggested 1925 by Zach Shelby. 1927 o Various editorial updates for improved readability. 1929 Changes from ietf-10 to ietf-11: 1931 o Added text to section 3.8 (Congestion Control) to clarify that a 1932 "CoAP client sending a multicast CoAP request to /.well-known/core 1933 SHOULD support core-block" (#332). 1935 o Various editorial updates for improved readability. 1937 Changes from ietf-09 to ietf-10: 1939 o Various editorial updates including: 1941 o Added a fourth option in section 3.3 on ways to obtain the URI 1942 path for a group request. 1944 o Clarified use of content format in GET/PUT requests for 1945 Configuring Group Membership in Endpoints (in section 3.6). 1947 o Changed reference "draft-shelby-core-resource-directory" to 1948 "draft-ietf-core-resource-directory". 1950 o Clarified (in section 3.7) that ACKs are never used for a 1951 multicast request (from #296). 1953 o Clarified (in section 5.2/5.2.3) that MPL does not support group 1954 membership advertisement. 1956 o Adding introductory paragraph to Scope (section 2.2). 1958 o Wrote out fully the URIs in table section 3.2. 1960 o Reworded security text in section 7.2 (New Internet Media Type) to 1961 make it consistent with section 3.6 (Configuring Group 1962 Membership). 1964 o Fixed formatting of hyperlinks in sections 6.3 and 7.2. 1966 Changes from ietf-08 to ietf-09: 1968 o Cleaned up requirements language in general. Also, requirements 1969 language are now only used in section 3 (Protocol Considerations) 1970 and section 6 (Security Considerations). Requirements language 1971 has been removed from other sections to keep them to a minimum 1972 (#271). 1974 o Addressed final comment from Peter van der Stok to define what "IP 1975 stack" meant (#296). Following the lead of CoAP-17, we know refer 1976 instead to "APIs such as IPV6_RECVPKTINFO [RFC 3542]". 1978 o Changed text in section 3.4 (Group Methods) to allow multicast 1979 POST under specific conditions and highlighting the risks with 1980 using it (#328). 1982 o Various editorial updates for improved readability. 1984 Changes from ietf-07 to ietf-08: 1986 o Updated text in section 3.6 (Configuring Group Membership in 1987 Endpoints) to make it more explicit that the Internet Media Type 1988 is used in the processing rules (#299). 1990 o Addressed various comments from Peter van der Stok (#296). 1992 o Various editorial updates for improved readability including 1993 defining all acronyms. 1995 Changes from ietf-06 to ietf-07: 1997 o Added an IANA request (in section 7.2) for a dedicated content- 1998 format (Internet Media type) for the group management JSON format 1999 called 'application/coap-group+json' (#299). 2001 o Clarified semantics (in section 3.6) of group management JSON 2002 format (#300). 2004 o Added details of IANA request (in section 7.1) for a new CORE 2005 Resource Type called 'core.gp'. 2007 o Clarified that DELETE method (in section 3.6) is also a valid 2008 group management operation. 2010 o Various editorial updates for improved readability. 2012 Changes from ietf-05 to ietf-06: 2014 o Added a new section on commissioning flow when using discovery 2015 services when end devices discover in which multicast group they 2016 are allocated (#295). 2018 o Added a new section on CoAP Proxy Operation (section 3.9) that 2019 outlines the potential issues and limitations of doing CoAP 2020 multicast requests via a CoAP Proxy (#274). 2022 o Added use case of multicasting controller on the backbone (#279). 2024 o Use cases were updated to show only a single CoAP RD (to replace 2025 the previous multiple RDs with one in each subnet). This is a 2026 more efficient deployment and also avoids RD specific issues such 2027 as synchronization of RD information between serves (#280). 2029 o Added text to section 3.6 (Configuring Group Membership in 2030 Endpoints) that clarified that any (unicast) operation to change 2031 an endpoint's group membership must use DTLS-secured CoAP. 2033 o Clarified relationship of this document to draft-ietf-core-coap in 2034 section 2.2 (Scope). 2036 o Removed IPSec related requirement, as IPSec is not part of draft- 2037 ietf-core-coap anymore. 2039 o Editorial reordering of subsections in section 3 to have a better 2040 flow of topics. Also renamed some of the (sub)sections to better 2041 reflect their content. Finally, moved the URI Configuration text 2042 to the same section as the Port Configuration section as it was a 2043 more natural grouping (now in section 3.3) . 2045 o Editorial rewording of section 3.7 (Multicast Request Acceptance 2046 and Response Suppression) to make the logic easier to comprehend 2047 (parse). 2049 o Various editorial updates for improved readability. 2051 Changes from ietf-04 to ietf-05: 2053 o Added a new section 3.9 (Exceptions) that highlights that IP 2054 multicast (and hence group communication) is not always available 2055 (#187). 2057 o Updated text on the use of [RFC2119] language (#271) in Section 1. 2059 o Included guidelines on when (not) to use CoAP responses to 2060 multicast requests and when (not) to accept multicast requests 2061 (#273). 2063 o Added guideline on use of core-block for minimizing response size 2064 (#275). 2066 o Restructured section 6 (Security Considerations) to more fully 2067 describe threats and threat mitigation (#277). 2069 o Clearly indicated that DNS resolution and reverse DNS lookup are 2070 optional. 2072 o Removed confusing text about a single group having multiple IP 2073 addresses. If multiple IP addresses are required then multiple 2074 groups (with the same members) should be created. 2076 o Removed repetitive text about the fact that group communication is 2077 not guaranteed. 2079 o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP 2080 Multicast Routing Background) and added link to section 5.2 2081 (Advertising Membership of Multicast Groups). 2083 o Clarified text in section 3.8 (Congestion Control) regarding 2084 precedence of use of IP multicast domains (i.e. first try to use 2085 link-local scope, then site-local scope, and only use global IP 2086 multicast as a last resort). 2088 o Extended group resource manipulation guidelines with use of pre- 2089 configured ports/paths for the multicast group. 2091 o Consolidated all text relating to ports in a new section 3.3 (Port 2092 Configuration). 2094 o Clarified that all methods (GET/PUT/POST) for configuring group 2095 membership in endpoints should be unicast (and not multicast) in 2096 section 3.7 (Configuring Group Membership In Endpoints). 2098 o Various editorial updates for improved readability, including 2099 editorial comments by Peter van der Stok to WG list of December 2100 18th, 2012. 2102 Changes from ietf-03 to ietf-04: 2104 o Removed section 2.3 (Potential Solutions for Group Communication) 2105 as it is purely background information and moved section to draft- 2106 dijk-core-groupcomm-misc (#266). 2108 o Added reference to draft-keoh-tls-multicast-security to section 6 2109 (Security Considerations). 2111 o Removed Appendix B (CoAP-Observe Alternative to Group 2112 Communications) as it is as an alternative to IP Multicast that 2113 the WG has not adopted and moved section to draft-dijk-core- 2114 groupcomm-misc (#267). 2116 o Deleted section 8 (Conclusions) as it is redundant (#268). 2118 o Simplified light switch use case (#269) by splitting into basic 2119 operations and additional functions (#269). 2121 o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) 2122 to draft-dijk-core-groupcomm-misc (#270). 2124 o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) 2125 to draft-dijk-core-groupcomm-misc as these sections essentially 2126 just repeated text from other drafts regarding DNS based features. 2128 Clarified remaining text in this draft relating to DNS based 2129 features to clearly indicate that these features are optional 2130 (#272). 2132 o Focus section 3.5 (Configuring Group Membership) on a single 2133 proposed solution. 2135 o Scope of section 5.3 (Use of MLD) widened to multicast destination 2136 advertisement methods in general. 2138 o Rewrote section 2.2 (Scope) for improved readability. 2140 o Moved use cases that are not addressed to draft-dijk-core- 2141 groupcomm-misc. 2143 o Various editorial updates for improved readability. 2145 Changes from ietf-02 to ietf-03: 2147 o Clarified that a group resource manipulation may return back a 2148 mixture of successful and unsuccessful responses (section 3.4 and 2149 Figure 6) (#251). 2151 o Clarified that security option for group communication must be 2152 NoSec mode (section 6) (#250). 2154 o Added mechanism for group membership configuration (#249). 2156 o Removed IANA request for multicast addresses (section 7) and 2157 replaced with a note indicating that the request is being made in 2158 draft-ietf-core-coap (#248). 2160 o Made the definition of 'group' more specific to group of CoAP 2161 endpoints and included text on UDP port selection (#186). 2163 o Added explanatory text in section 3.4 regarding why not to use 2164 group communication for non-idempotent messages (i.e. CoAP POST) 2165 (#186). 2167 o Changed link-local RD discovery to site-local in RD discovery use 2168 case to make it more realistic. 2170 o Fixed lighting control use case CoAP proxying; now returns 2171 individual CoAP responses as in coap-12. 2173 o Replaced link format I-D with RFC6690 reference. 2175 o Various editorial updates for improved readability 2176 Changes from ietf-01 to ietf-02: 2178 o Rewrote congestion control section based on latest CoAP text 2179 including Leisure concept (#188) 2181 o Updated the CoAP/HTTP interworking section and example use case 2182 with more details and use of MLD for multicast group joining 2184 o Key use cases added (#185) 2186 o References to draft-vanderstok-core-dna and draft-castellani-core- 2187 advanced-http-mapping added 2189 o Moved background sections on "MLD" and "CoAP-Observe" to 2190 Appendices 2192 o Removed requirements section (and moved it to draft-dijk-core- 2193 groupcomm-misc) 2195 o Added details for IANA request for group communication multicast 2196 addresses 2198 o Clarified text to distinguish between "link local" and general 2199 multicast cases 2201 o Moved lengthy background section 5 to draft-dijk-core-groupcomm- 2202 misc and replaced with a summary 2204 o Various editorial updates for improved readability 2206 o Change log added 2208 Changes from ietf-00 to ietf-01: 2210 o Moved CoAP-observe solution section to section 2 2212 o Editorial changes 2214 o Moved security requirements into requirements section 2216 o Changed multicast POST to PUT in example use case 2218 o Added CoAP responses in example use case 2220 Changes from rahman-07 to ietf-00: 2222 o Editorial changes 2223 o Use cases section added 2225 o CoRE Resource Directory section added 2227 o Removed section 3.3.5. IP Multicast Transmission Methods 2229 o Removed section 3.4 Overlay Multicast 2231 o Removed section 3.5 CoAP Application Layer Group Management 2233 o Clarified section 4.3.1.3 RPL Routers with Non-RPL Hosts case 2235 o References added and some normative/informative status changes 2237 Authors' Addresses 2239 Akbar Rahman (editor) 2240 InterDigital Communications, LLC 2242 Email: Akbar.Rahman@InterDigital.com 2244 Esko Dijk (editor) 2245 Philips Research 2247 Email: esko.dijk@philips.com