idnits 2.17.1 draft-ietf-core-groupcomm-05.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 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2013) is 4091 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC2616' is defined on line 1055, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-10 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-03 Summary: 2 errors (**), 0 flaws (~~), 6 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: August 9, 2013 Philips Research 6 February 5, 2013 8 Group Communication for CoAP 9 draft-ietf-core-groupcomm-05 11 Abstract 13 CoAP is a RESTful transfer protocol for constrained devices and 14 networks. It is anticipated that constrained devices will often 15 naturally operate in groups (e.g. in a building automation scenario 16 all lights in a given room may need to be switched on/off as a 17 group). This document defines how the CoAP protocol should be used 18 in a group communication context. An approach for using CoAP on top 19 of IP multicast is detailed for both constrained and un-constrained 20 networks. Also, various use cases and corresponding protocol flows 21 are provided to illustrate important concepts. Finally, guidance is 22 provided for 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 August 9, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. CoAP Group Communication Based on IP Multicast . . . . . . . . 5 63 3.1. IP Multicast Routing Background . . . . . . . . . . . . . 5 64 3.2. Group Definition and Naming . . . . . . . . . . . . . . . 6 65 3.3. Port Configuration . . . . . . . . . . . . . . . . . . . . 7 66 3.4. Group Discovery and Member Discovery . . . . . . . . . . . 7 67 3.5. Group Resource Manipulation . . . . . . . . . . . . . . . 7 68 3.6. Multicast Request Acceptance and Response Suppression . . 8 69 3.7. Configuring Group Membership In Endpoints . . . . . . . . 10 70 3.8. Congestion Control . . . . . . . . . . . . . . . . . . . . 11 71 3.9. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4. Use Cases and Corresponding Protocol Flows . . . . . . . . . . 13 73 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.2. Network Configuration . . . . . . . . . . . . . . . . . . 13 75 4.3. Discovery of Resource Directory . . . . . . . . . . . . . 16 76 4.4. Lighting Control . . . . . . . . . . . . . . . . . . . . . 17 77 4.5. Lighting Control in MLD Enabled Network . . . . . . . . . 20 78 5. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 21 79 5.1. Target Network Topologies . . . . . . . . . . . . . . . . 21 80 5.2. Advertising Membership of Multicast Groups . . . . . . . . 22 81 5.2.1. Using the Multicast Listener Discovery (MLD) 82 Protocol . . . . . . . . . . . . . . . . . . . . . . . 22 83 5.2.2. Using the RPL Routing Protocol . . . . . . . . . . . . 22 84 5.2.3. Using the MPL Forwarding Protocol . . . . . . . . . . 23 85 5.3. 6LoWPAN-Specific Guidelines . . . . . . . . . . . . . . . 23 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 87 6.1. Security Configuration . . . . . . . . . . . . . . . . . . 24 88 6.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 6.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 24 90 6.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 24 91 6.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . . 25 92 6.3.3. Future Evolution . . . . . . . . . . . . . . . . . . . 25 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 98 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 27 99 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 102 1. Conventions and Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 [RFC2119]. 109 These key words are used to establish a set of best practices for 110 CoAP group communication. An implementation of CoAP group 111 communication MAY implement these guidelines; an implementation 112 claiming compliance to this document MUST implement the set. 114 This document assumes readers are familiar with the terms and 115 concepts that are used in [I-D.ietf-core-coap]. In addition, this 116 document defines the following terminology: 118 Group Communication 119 A source node sends a single message which is delivered to 120 multiple destination nodes, where all destinations are identified 121 to belong to a specific group. The source node itself may be part 122 of the group. The underlying mechanism for group communication is 123 assumed to be multicast based. The network involved may be a 124 constrained network such as a low-power, lossy network. 126 Multicast 127 Sending a message to multiple destination nodes with one network 128 invocation. There are various options to implement multicast 129 including layer 2 (Media Access Control) and layer 3 (IP) 130 mechanisms. 132 IP Multicast 133 A specific multicast solution based on the use of IP multicast 134 addresses as defined in "IANA Guidelines for IPv4 Multicast 135 Address Assignments" [RFC5771] and "IP Version 6 Addressing 136 Architecture" [RFC4291]. 138 Low power and Lossy Network (LLN) 139 A type of constrained IP network where devices are interconnected 140 by a variety of low-power and lossy links (such as IEEE 802.15.4, 141 Bluetooth LE, DECT, DECT ULE) or lossy links (such as IEEE P1901.2 142 power-line communication). 144 2. Introduction 145 2.1. Background 147 The Constrained Application Protocol (CoAP) is an application 148 protocol (analogous to HTTP) for resource constrained devices 149 operating in an IP network [I-D.ietf-core-coap]. Constrained devices 150 can be large in number, but are often highly correlated to each other 151 (e.g. by type or location). For example, all the light switches in a 152 building may belong to one group and all the thermostats may belong 153 to another group. Groups may be preconfigured before deployment or 154 dynamically formed during operation. If information needs to be sent 155 to or received from a group of devices, group communication 156 mechanisms can improve efficiency and latency of communication and 157 reduce bandwidth requirements for a given application. HTTP does not 158 support any equivalent functionality to CoAP group communication. 160 2.2. Scope 162 This document describes how to use the CoAP protocol in a group 163 communication context with IP Multicast running underneath CoAP. No 164 changes to either CoAP or IP Multicast are required for this purpose. 165 However, proper operation of group communication does require 166 judicious use of these and a variety of other IETF protocols. The 167 main contribution of this document lies in explaining how various 168 IETF mechanisms may be used to fulfill CoAP group communication needs 169 for specific use cases and deployments. 171 3. CoAP Group Communication Based on IP Multicast 173 3.1. IP Multicast Routing Background 175 IP Multicast routing protocols have been evolving for decades, 176 resulting in proposed standards such as Protocol Independent 177 Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various 178 technical and marketing reasons, IP Multicast routing is not widely 179 deployed on the general Internet. However, IP Multicast is very 180 popular in specific deployments such as in enterprise networks (e.g. 181 for video conferencing), smart home networks (e.g. UPnP) and carrier 182 IPTV deployments. The packet economy and minimal host complexity of 183 IP multicast make it attractive for group communication in 184 constrained environments. Therefore IP multicast is the recommended 185 underlying mechanism for CoAP group communication, and the approach 186 assumed in this document. 188 To achieve IP multicast beyond a subnet, an IP multicast routing or 189 forwarding protocol needs to be active on IP routers. An examples of 190 a routing protocol specifically for LLNs is RPL (Section 12 of 191 [RFC6550]) and an example of a forwarding protocol for LLNs is MPL 193 [I-D.ietf-roll-trickle-mcast]. PIM-SM [RFC4601] is often used for 194 multicast routing in un-constrained networks. 196 IP multicast can also be run in a Link-Local (LL) scope. This means 197 that there is no routing involved and an IP multicast message is only 198 received over the link on which it was sent. 200 For a complete IP multicast solution, in addition to a routing/ 201 forwarding protocol, a so-called "listener" protocol is needed for 202 the devices to subscribe to groups (see Section 5.2). 204 3.2. Group Definition and Naming 206 A group is defined as a set of CoAP endpoints, where each endpoint is 207 configured to receive a multicast CoAP request that is sent to the 208 group's associated IP multicast address. An endpoint MAY be a member 209 of multiple groups. Group membership of an endpoint MAY dynamically 210 change over time. 212 For group communications, the Group URI will be the CoAP request URI. 213 A Group URI has the scheme 'coap' and includes in the authority part 214 either a group IP multicast address plus optional port number or a 215 hostname plus optional port number that can be resolved to the group 216 IP multicast address (e.g., a Group Name or Group FQDN). Group URIs 217 follow the CoAP URI syntax [I-D.ietf-core-coap]. It is recommended 218 for sending nodes to use the IP multicast address literal in the 219 authority for the Group URI as the default. 221 If a Group FQDN is used, it can be uniquely mapped to a site-local or 222 global multicast IP address via DNS resolution (if supported). Some 223 examples of hierarchical Group FQDN naming (and scoping) for a 224 building control application are shown below 225 ([I-D.vanderstok-core-dna]): 227 URI authority Targeted group 228 all.bldg6.example.com "all nodes in building 6" 229 all.west.bldg6.example.com "all nodes in west wing, building 6" 230 all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, 231 building 6" 232 all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, 233 west wing, building 6" 235 Similarly, if supported, reverse mapping (from IP multicast address 236 to Group FQDN) is possible using the reverse DNS resolution technique 237 ([I-D.vanderstok-core-dna]). 239 3.3. Port Configuration 241 A CoAP group member listens for CoAP messages on the group's IP 242 multicast address, on a specified UDP port. Note that the default 243 UDP port is the CoAP default port 5683 but a non-default UDP port MAY 244 be specified for the group; in which case implementers MUST ensure 245 that all group members are configured to use this same port. 247 Group communications will not work if there diversity in the 248 authority port (i.e. a diversity of dynamic port addresses across the 249 group) or if the resources are located at different paths on 250 different end-points. Therefore, some measures must be present to 251 ensure uniformity in port number and resource names/locations within 252 a group. All CoAP multicast requests MUST be sent using the port 253 number as follows: 255 1. A preconfigured port number, if available. The pre-configuration 256 mechanism MUST ensure that the same port number is preconfigured 257 across all endpoints in a group and across all CoAP clients 258 performing the group requests. 260 2. If the client is configured to use service discovery including 261 port discovery, it uses a port number obtained via a service 262 discovery lookup operation as a valid CoAP port for the targeted 263 CoAP multicast group. 265 3. Otherwise use the default CoAP UDP port. 267 3.4. Group Discovery and Member Discovery 269 CoAP defines a resource discovery capability [RFC6690], but does not 270 specify how to discover groups (e.g. find a group to join or send a 271 multicast message to) or how to discover members of a group (e.g. to 272 address selected group members by unicast). A simple ad-hoc method 273 to discover members of a CoAP group would be to send a multicast 274 "CoAP ping" [I-D.ietf-core-coap]. The collected responses to the 275 ping would then give an indication of the group members. 277 3.5. Group Resource Manipulation 279 Group communications SHALL only be used for idempotent methods (i.e. 280 CoAP GET, PUT, and DELETE). The CoAP messages that are sent via 281 multicast SHALL be Non-Confirmable. 283 A unicast response per server MAY be sent back to answer the group 284 request (e.g. response "2.05 Content" to a group GET request) taking 285 into account the congestion control rules defined in Section 3.8. 286 The unicast responses received may be a mixture of success (e.g. 2.05 287 Content) and failure (e.g. 4.04 Not Found) codes depending on the 288 individual server processing result. 290 Group communications SHALL NOT be used for non-idempotent methods 291 (i.e. CoAP POST). This is because not all group members are 292 guaranteed to receive the multicast request, and the sender can not 293 readily find out which group members did not receive it. 295 All CoAP multicast requests SHOULD operate on URI paths ("links") as 296 follows: 298 1. Preconfigured URI paths, if available. The pre-configuration 299 mechanism MUST ensure that these URIs are preconfigured across 300 all CoAP servers in a group and all CoAP clients performing the 301 group requests. 303 2. If the client is configured to use default CoRE service 304 discovery, it uses URI paths which were retrieved from a "/.well- 305 known/core" lookup on at least one group member endpoint; where 306 the selected URI paths are known from application knowledge to be 307 available in all endpoints in the group. The URI path 308 configuration mechanism on servers MUST ensure that these URIs 309 (identified as being supported by the group) are configured on 310 all group endpoints. 312 3. If the client is configured to use another form of service 313 discovery, it uses URI paths from an equivalent service discovery 314 lookup which returns the resources supported by all group 315 members. 317 3.6. Multicast Request Acceptance and Response Suppression 319 CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define 320 normative requirements for two aspects: 322 1. Multicast request acceptance; in what cases a request is accepted 323 and executed, and when not. 325 2. Multicast response suppression; in what cases the response of an 326 executed request is returned to the requesting endpoint, and when 327 not. 329 This section aims to first summarize these normative requirements and 330 then present guidelines, for a number of multicast example 331 applications, in what way the request suppression and response 332 suppression should be configured. 334 To apply any rules for request and/or response suppression, the IP 335 stack interface of a CoAP server must be able to indicate for an 336 incoming request that the destination address of the request was 337 multicast. The case that an IP stack interface cannot provide this 338 indication, is the exception case for the RECOMMENDED behaviours 339 listed below. In that case, only response suppression (aspect 2.) 340 can be supported for selected resources which are known (through 341 application knowledge) and configured to be used for multicast 342 requests. 344 For aspect 1 (request acceptance), the requirements are: 346 o A server SHOULD NOT accept a multicast request that cannot be 347 "authenticated" in some way (cryptographically or by some 348 multicast boundary limiting the potential sources) 349 [I-D.ietf-core-coap]. 351 o A server SHOULD NOT accept a multicast discovery request with a 352 query string (as defined in CoRE Link Format [RFC6690]) if 353 filtering ([RFC6690]) is not supported by the server; 355 o A server SHOULD NOT accept a multicast request that acts on a 356 specific resource for which multicast support is not required. 357 (Note that for discovery resource "/.well-known/core" multicast 358 support is always required. Implementers are advised to disable 359 multicast support by default on any other resource, until 360 explicitly enabled by an application.) 362 Regarding the first requirement see Section 6.3 for examples of 363 multicast boundary limiting methods. 365 For aspect 2 (response suppression), the requirements are: 367 o A server SHOULD NOT respond to a multicast discovery request if 368 the filter specified by the request's query string does not match; 370 o A server MAY choose not to respond to a multicast request, if 371 there's nothing useful to respond (e.g. error or empty response). 372 This optional response suppression will be illustrated by some use 373 cases in the remainder of this section. 375 The above response suppression requirements are complemented by the 376 following guidelines in this document. CoAP servers should 377 preferably implement configurable response suppression, enabling at 378 least the following configuration items per resource: 380 o Suppression of all 2.xx success responses; 381 o Suppression of all 4.xx client errors; 383 o Suppression of all 5.xx server errors; 385 o Suppression of all 2.05 responses with empty payload. 387 Below a number of group communication example applications are 388 mentioned and in what way these could typically make use of response 389 suppression as defined by the above four configuration items. 391 o CoAP resource discovery: suppression of 2.05 responses with empty 392 payload and all 4.xx and 5.xx errors. 394 o Lighting control: suppress all 2.xx responses after a lighting 395 change command. 397 o Update group configuration data using multicast PUT: no 398 suppression at all. Use collected responses to identify which 399 group members did not receive the new configuration; then attempt 400 using CoAP CON unicast to update those group members. 402 o Multicast firmware update by sending blocks of data: suppress all 403 2.xx and 5.xx responses. After having sent all multicast blocks, 404 the client checks each endpoint by unicast to identify which 405 blocks are still missing in each endpoint. 407 o Conditional reporting for a group (e.g. sensors) based on a URI 408 query: suppress all 2.05 responses with empty payload (i.e. if a 409 query produces no matching results). 411 3.7. Configuring Group Membership In Endpoints 413 The group membership of a CoAP server may be determined in one or 414 more of the following ways. First, the group membership may be 415 preconfigured before node deployment. Second, it may be configured 416 during operation by another node e.g. a commissioning device. Third, 417 a node may be programmed to discover (query) its group membership 418 during operation using a specific service discovery means. 420 In the first case, the preconfigured group may be a multicast IP 421 address or a hostname which is during operation resolved to a 422 multicast IP address by the endpoint using DNS. 424 In the second case, typical in building control, a commissioning tool 425 determines to which groups a sensor or actuator node belongs, and 426 writes this information to the node, which can subsequently join the 427 correct IP multicast group on its network interface. The information 428 written may again be a multicast IP address or a hostname. 430 To achieve smoother interoperability between nodes/endpoints from 431 different manufacturers, an OPTIONAL RESTful method of configuring 432 CoAP endpoints with relevant group information is specified here. 433 This approach MUST use unicast methods (GET/PUT/POST) only as it is a 434 method of configuring group information in individual endpoints. 435 Using multicast operations in this situation may lead to unexpected 436 (possibly circular) behavior in the network. 438 CoAP endpoints implementing this mechanism MUST support at least one 439 discoverable "Group Configuration" resource of resource type (rt) 440 [RFC6690] "core.gp" where "gp" is shorthand for "group". This 441 resource is used by an authorized endpoint to manage group membership 442 of the CoAP endpoint. 444 The resource of type "core.gp" has a JSON content format. A 445 (unicast) GET on this resource returns a JSON array of group objects, 446 each group object formatted as shown below: 448 Req: GET /gp 449 Res: 2.05 Content (Content-Format: application/json) 450 [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", 451 "ip": "ff15::4200:f7fe:ed37:14ca" } 452 ] 454 where the OPTIONAL "n" key/value pair defines the Group name as FQDN 455 and the OPTIONAL "ip" key/value pair defines the associated multicast 456 IP address. A CoAP endpoint can be added to another group by a 457 (unicast) POST on the resource with a single JSON group object, which 458 updates the existing resource by adding the group object to the 459 existing ones: 461 Req: POST /gp (Content-Format: application/json) 462 { "n": "floor1.west.bldg6.example.com", 463 "ip": "ff15::4200:f7fe:ed37:14cb" } 464 Res: 2.04 Changed 466 A (unicast) PUT with as payload an array of JSON group objects will 467 replace all current group memberships with the new ones as defined in 468 the payload. After a change effected on the "core.gp" type resource, 469 the endpoint MUST effect registration/deregistration from 470 corresponding IP multicast groups as soon as possible. 472 3.8. Congestion Control 474 Multicast CoAP requests may result in a multitude of replies from 475 different nodes, potentially causing congestion. Therefore both the 476 sending of multicast requests and sending unicast CoAP responses to 477 multicast requests should be conservatively controlled. 479 The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific 480 congestion risks through the following measures: 482 o A server MAY choose not to respond to a multicast request if 483 there's nothing useful to respond (e.g. error or empty response). 484 See Section 3.6 for more detailed guidelines on response 485 suppression. 487 o A server SHOULD limit the support for multicast requests to 488 specific resources where multicast operation is required. 490 o A multicast request MUST be Non-Confirmable. 492 o A response to a multicast request SHOULD be Non-Confirmable 493 (Section 5.2.3). 495 o A server does not respond immediately to a multicast request, but 496 SHOULD first wait for a time that is randomly picked within a 497 predetermined time interval called the Leisure. 499 o A server SHOULD NOT accept multicast requests that can not be 500 authenticated in some way. See Section 3.6 for more details on 501 request suppression and multicast source authentication. 503 Additional guidelines to reduce congestion risks are: 505 o A server in an LLN should only support multicast GET for resources 506 that are small, e.g. the payload of the response fits into a 507 single link-layer frame. 509 o A server can minimize the payload length in response to a 510 multicast GET on "/.well-known/core" by using hierarchy in 511 arranging link descriptions for the response. An example of this 512 is given in Section 5 of [RFC6690]. 514 o Alternatively a server can also minimize the payload length of a 515 response to a multicast GET (e.g. on "/.well-known/core") using 516 CoAP blockwise transfers [I-D.ietf-core-block], returning only a 517 first block of the link format description. 519 o A client should always aim to use IP multicast with link-local 520 scope if possible. If this is not possible, then site-local scope 521 IP multicast should be considered. If this is not possible, then 522 global scope IP multicast should be considered as a last resort 523 only. 525 3.9. Exceptions 527 Group communication using IP multicast offers improved network 528 efficiency and latency amongst other benefits. However, group 529 communications may not always be possible to implement in a given 530 network. The primary reason for this will be if IP multicast is not 531 supported in the network. For example, in a LLN, if the RPL protocol 532 is used and set to "Non-storing mode" [RFC6550] there will be no IP 533 multicast routing in that network beyond link-local scope. This 534 means that any CoAP group communications above link-local scope will 535 not be supported in that network. 537 4. Use Cases and Corresponding Protocol Flows 539 4.1. Introduction 541 The use of CoAP group communication is shown in the context of the 542 following two use cases and corresponding protocol flows: 544 o Discovery of Resource Directory: discovering the local CoRE RD 545 which contains links (URIs) to resources stored on other servers 546 [RFC6690]. 548 o Lighting Control: synchronous operation of a group of IPv6- 549 connected lights (e.g., 6LoWPAN [RFC4944] lights). 551 4.2. Network Configuration 553 To illustrate the use cases we define two network configurations. 554 Both are based on the topology as shown in Figure 1. The two 555 configurations using this topology are: 557 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 558 6LoWPAN Border Routers (6LBRs, [RFC6775]). 560 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 561 multicast-capable Ethernet routers. 563 Both configurations are further specified by the following: 565 o A large room (Room-A) with three lights (Light-1, Light-2, 566 Light-3) controlled by a Light Switch. The devices are organized 567 into two subnets. In reality, there could be more lights (up to 568 several hundreds) but these are not shown for clarity. 570 o Light-1 and the Light Switch are connected to a router (Rtr-1) 571 which is also a CoAP Resource Directory (RD). 573 o Light-2 and the Light-3 are connected to another router (Rtr-2) 574 which is also a CoAP RD. 576 o The routers are connected to an IPv6 network backbone which is 577 also multicast enabled. In the general case, this means the 578 network backbone and Rtr-1/Rtr-2 support a PIM based multicast 579 routing protocol, and MLD for forming groups. In a limited case, 580 if the network backbone is one link, then the routers only have to 581 support MLD-snooping (Appendix A) for the following use cases to 582 work. 584 o The DNS server is optional. If the server is there then certain 585 DNS based features are available (e.g. DNS resolution of URI to 586 IP multicast address). If the DNS server is not there, then 587 different manual provisioning of the network is required (e.g. IP 588 multicast addresses are hardcoded into devices). 590 Network 591 Backbone 592 | 593 ################################################ | 594 # Room-A # | 595 # ********************** # | 596 # ** Subnet-1 ** # | 597 # * * # | 598 # * +----------+ * # | 599 # * | Light |-------+ * # | 600 # * | Switch | | * # | 601 # * +----------+ +---------+ * # | 602 # * | Rtr-1 |-----------------------------| 603 # * +---------+ * # | 604 # * +----------+ | * # | 605 # * | Light-1 |--------+ * # | 606 # * +----------+ * # | 607 # * * # | 608 # ** ** # | 609 # ********************** # | 610 # # | 611 # # | 612 # ********************** # | 613 # ** Subnet-2 ** # | 614 # * * # | 615 # * +----------+ * # | 616 # * | Light-2 |-------+ * # | 617 # * | | | * # | 618 # * +----------+ +---------+ * # | 619 # * | Rtr-2 |-----------------------------| 620 # * +---------+ * # | 621 # * +----------+ | * # | 622 # * | Light-3 |--------+ * # | 623 # * +----------+ * # | 624 # * * # | 625 # ** ** # | 626 # ********************** # | 627 # # | 628 ################################################# | 629 | 630 +------------+ | 631 | DNS | | 632 | Server |-----------------+ 633 | (Optional) | 634 +------------+ 636 Figure 1: Network Topology of a Large Room (Room-A) 638 4.3. Discovery of Resource Directory 640 The protocol flow for discovery of a RD for the given network (of 641 Figure 1) is shown in Figure 2: 643 o The fixture for Light-2 is installed and powered on for the first 644 time. 646 o Light-2 will then search for the local RD (RD-2) by sending out a 647 GET request (with the "/.well-known/core?rt=core.rd" request URI) 648 to the site-local "All CoAP Nodes" address. In this case, the 649 site is configured to include at least all nodes in the subnet. 651 o This multicast message will then go to each node in subnet-2. 652 However, only Rtr-2 (RD-2) will respond because the GET is 653 qualified by the query string "?rt=core.rd". Note that the router 654 Rtr-2 is configured not to forward this multicast request further 655 onto the backbone. 657 o Note that the flow is shown only for Light-2 for clarity. Similar 658 flows will happen for Light-1, Light-3 and the Light Switch when 659 they are first powered on. 661 The RD may also be discovered by other means such as by assuming a 662 default location (e.g. on a 6LBR), using DHCP, anycast address, etc. 663 However, these approaches do not invoke CoAP group communication so 664 are not further discussed here. 666 For other discovery use cases such as discovering local CoAP servers, 667 services or resources group communication can be used in a similar 668 fashion as in the above use case. Both Link-Local (LL) and site- 669 local discovery are possible this way. 671 Light Rtr-1 Rtr-2 Network 672 Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) Backbone 673 | | | | | | | 674 | | | | | | | 675 ********************************** | | | 676 * Light-2 is installed * | | | 677 * and powers on for first time * | | | 678 ********************************** | | | 679 | | | | | | | 680 | | | | | | | 681 | | COAP NON Mcast(GET | | 682 | | /.well-known/core?rt=core.rd) | | 683 | |--------->-------------------------------->| | 684 | | | | | | | 685 | | | | | | | 686 | | | | | | | 687 | | COAP NON (2.05 Content | | 688 | | ;rt="core.rd";ins="Primary") | | 689 | |<------------------------------------------| | 690 | | | | | | | 692 Figure 2: Resource Directory Discovery via Multicast Message 694 4.4. Lighting Control 696 The protocol flow for a building automation lighting control scenario 697 for the network (Figure 1) in 6LoWPAN configuration is shown in 698 sequence in Figure 3 for the case that the CoAP servers in each Light 699 are configured to not generate a CoAP response to lighting control 700 CoAP multicast requests. (See section Section 3.6 for more details 701 on response suppression by a server.) 703 In addition, Figure 4 shows a protocol flow example for the case that 704 servers do respond to a lighting control multicast request with CoAP 705 NON responses. There are two success responses and one 5.00 error 706 response. In this particular use case the Light Switch does not 707 check, based on the responses, that all Lights in the group actually 708 received the multicast request, because it is not configured with an 709 exhaustive list of IP addresses of all Lights belonging to the group. 710 However, based on received error responses it could take additional 711 action such as logging a fault or alerting the user via its LCD 712 display. 714 Reliability of CoAP multicast is not guaranteed. Therefore, one or 715 more lights in the group may not have received the CoAP control 716 request due to packet loss. In this use case there is no detection 717 nor correction of such situations: the application layer expects that 718 the multicast forwarding/routing will be of sufficient quality to 719 provide on average a very high probability of packet delivery to all 720 CoAP endpoints in a multicast group. An example protocol to 721 accomplish this is the MPL forwarding protocol for LLNs 722 [I-D.ietf-roll-trickle-mcast]. 724 We assume the following steps have already occurred before the 725 illustrated flows: 727 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 728 all devices. The CoAP network is formed. 730 2. Network configuration (application-independent): 6LBRs are 731 configured with multicast address blocks to filter out or to pass 732 through to/from the 6LoWPAN. 734 3. Commissioning phase (application-related): The IP multicast 735 address of the group (Room-A-Lights) has been configured in all 736 the Lights and in the Light Switch. 738 4. As an alternative to the previous step, when a DNS server is 739 available, the Light Switch and/or the Lights have been 740 configured with a group hostname which each nodes resolves to the 741 above IP multicast address of the group. 743 Note for the Commissioning phase: the switch's software supports 744 sending unicast, multicast or proxied unicast/multicast CoAP 745 requests, including processing of the multiple responses that may be 746 generated by a multicast CoAP request. 748 Light Network 749 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 750 | | | | | | | 751 | | | | | | | 752 | | *********************** | | 753 | | * User flips on * | | 754 | | * light switch to * | | 755 | | * turn on all the * | | 756 | | * lights in Room A * | | 757 | | *********************** | | 758 | | | | | | | 759 | | | | | | | 760 | | | COAP NON Mcast(PUT, | | 761 | | | Payload=lights ON) | | 762 |<-------------------------------+--------->| | | 763 ON | | | |-------------------->| 764 | | | | | |<---------| 765 | |<---------|<-------------------------------| | 766 | ON ON | | | | 767 ^ ^ ^ | | | | 768 *********************** | | | | 769 * Lights in Room-A * | | | | 770 * turn on (nearly * | | | | 771 * simultaneously) * | | | | 772 *********************** | | | | 773 | | | | | | | 775 Figure 3: Light Switch Sends Multicast Control Message 776 Light Network 777 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 778 | | | | | | | 779 | COAP NON (2.04 Changed) | | | | 780 |------------------------------->| | | | 781 | | | | | | | 782 | | | | | | | 783 | COAP NON (2.04 Changed) | | | 784 | |------------------------------------------>| | 785 | | | | | |--------->| 786 | | | | |<--------------------| 787 | | | |<---------| | | 788 | | | | | | | 789 | | COAP NON (5.00 Internal Server Error) | 790 | | |------------------------------->| | 791 | | | | | |--------->| 792 | | | | |<--------------------| 793 | | | |<---------| | | 794 | | | | | | | 796 Figure 4: Lights (Optionally) Respond to Multicast CoAP Request 798 4.5. Lighting Control in MLD Enabled Network 800 The use case of previous section can also apply in networks where 801 nodes support the MLD protocol [RFC3810]. The Lights then take on 802 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 803 Routers. In the Ethernet based network configuration, MLD may be 804 available on all involved network interfaces. Use of MLD in the 805 6LoWPAN based configuration is also possible, but requires MLD 806 support in all nodes in the 6LoWPAN which is usually not implemented 807 in many deployments. 809 The resulting protocol flow is shown in Figure 5. This flow is 810 executed after the commissioning phase, as soon as Lights are 811 configured with a group address to listen to. The MLD Reports may 812 require periodic refresh activity as specified by the MLD protocol. 814 After the shown sequence of MLD Report messages has been executed, 815 both Rtr-1 and Rtr-2 are automatically configured to forward 816 multicast traffic destined to Room-A-Lights onto their connected 817 subnet. Hence, no manual Network Configuration of routers, as 818 previously indicated in Section 4.4, is needed anymore. 820 Light Network 821 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 822 | | | | | | | 823 | | | | | | | 824 | | | | | | | 825 | MLD Report: Join | | | | | 826 | Group (Room-A-Lights) | | | | 827 |---LL------------------------------------->| | | 828 | | | | |MLD Report: Join | 829 | | | | |Group (Room-A-Lights)| 830 | | | | |---LL---->----LL---->| 831 | | | | | | | 832 | | MLD Report: Join | | | | 833 | | Group (Room-A-Lights) | | | 834 | |---LL------------------------------------->| | 835 | | | | | | | 836 | | | MLD Report: Join | | | 837 | | | Group (Room-A-Lights) | | 838 | | |---LL-------------------------->| | 839 | | | | | | | 840 | | | | |MLD Report: Join | 841 | | | | |Group (Room-A-Lights)| 842 | | | | |<--LL-----+---LL---->| 843 | | | | | | | 844 | | | | | | | 846 Figure 5: Joining Lighting Groups Using MLD 848 5. Deployment Guidelines 850 This section provides guidelines how an IP Multicast based solution 851 for CoAP group communication can be deployed in various network 852 configurations. 854 5.1. Target Network Topologies 856 CoAP group communication can be deployed in various network 857 topologies. First, the target network may be a regular IP network, 858 or a LLN such as a 6LoWPAN network, or consist of mixed constrained/ 859 unconstrained network segments. Second, it may be a single subnet 860 only or multi-subnet; e.g. multiple 6LoWPAN networks joined by a 861 single backbone LAN. Third, a wireless network segment may have all 862 nodes reachable in a single IP hop, or it may require multiple IP 863 hops for some pairs of nodes to reach each other. 865 Each topology may pose different requirements on the configuration of 866 routers and protocol(s), in order to enable efficient CoAP group 867 communication. 869 5.2. Advertising Membership of Multicast Groups 871 If a multicast routing/forwarding protocol is used in a network, 872 server nodes that intend to receive CoAP multicast requests generally 873 require a method to advertise the specific IP multicast address(es) 874 they want to receive, i.e. a method to join specific IP multicast 875 groups. This section identifies the ways in which this can be 876 accomplished. 878 5.2.1. Using the Multicast Listener Discovery (MLD) Protocol 880 CoAP nodes that are IP hosts (i.e. not IP routers) are generally 881 unaware of the specific multicast routing/forwarding protocol being 882 used. When such a host needs to join a specific (CoAP) multicast 883 group, it usually requires a way to signal to multicast routers which 884 multicast traffic it wants to receive. For efficient multicast 885 routing (i.e. avoid always flooding multicast IP packets), routers 886 must know which hosts need to receive packets addressed to specific 887 IP multicast destinations. 889 The Multicast Listener Discovery (MLD) protocol ([RFC3810], 890 Appendix A) is the standard IPv6 method to achieve this. [RFC6636] 891 discusses tuning of MLD for mobile and wireless networks. These 892 guidelines may be useful when implementing MLD in LLNs. 894 Alternatively, to avoid the use of MLD in LLN deployments, either all 895 nodes can be configured as multicast routers in an LLN, or a 896 multicast forwarding/flooding protocol can be used that forwards any 897 IP multicast packet to all forwarders (routers) in the subnet (LLN). 899 5.2.2. Using the RPL Routing Protocol 901 The RPL routing protocol [RFC6550] defines in Section 12 the 902 advertisement of IP multicast destinations using DAO messages. This 903 mechanism can be used by CoAP nodes (which are also RPL routers) to 904 advertise IP multicast group membership to other RPL routers. Then, 905 the RPL protocol can route multicast CoAP requests over multiple hops 906 to the correct CoAP servers. 908 This mechanism can be used as a means to convey IP multicast group 909 membership information to an edge router (e.g. 6LBR), in case the 910 edge router is also the root of the RPL DODAG. This could be useful 911 in LLN segments where MLD is not available and the edge router needs 912 to know what IP multicast traffic to pass through from the backbone 913 network into the LLN subnet. 915 5.2.3. Using the MPL Forwarding Protocol 917 The MPL forwarding protocol [I-D.ietf-roll-trickle-mcast] can be used 918 in a predefined network domain for propagation of IP multicast 919 packets to all MPL routers, over multiple hops. MPL is designed to 920 work in LLN deployments. Due to its property of propagating all 921 (non-link-local) IP multicast packets to all MPL routers, there is in 922 principle no need for CoAP server nodes to advertise IP multicast 923 group membership assuming that any IP multicast source is also part 924 of the MPL domain. 926 5.3. 6LoWPAN-Specific Guidelines 928 To support multi-LoWPAN scenarios for CoAP group communication, it is 929 RECOMMENDED that a 6LoWPAN Border Router (6LBR) will act in an MLD 930 Router role on the backbone link. If this is not possible then the 931 6LBR SHOULD be configured to act as an MLD Multicast Address Listener 932 and/or MLD Snooper (Appendix A) on the backbone link. 934 To avoid that backbone IP multicast traffic needlessly congests 935 6LoWPAN network segments, it is RECOMMENDED that a filtering means is 936 implemented to block IP multicast traffic from 6LoWPAN segments where 937 none of the 6LoWPAN nodes listen to this traffic. Possible means 938 are: 940 o Filtering in 6LBRs based on information from the routing protocol. 941 This allows a 6LBR to only forward multicast traffic onto the 942 LoWPAN, for which it is known that there exists at least one 943 listener on the LoWPAN. 945 o Filtering in 6LBRs based on MLD reports. Similar as previous but 946 based directly on MLD reports from 6LoWPAN nodes. This only works 947 in a single-IP-hop 6LoWPAN network, such as a mesh-under routing 948 network or a star topology network, because MLD relies on link- 949 local communication. 951 o Filtering in 6LBRs based on settings. Filtering tables with 952 blacklists/whitelists can be configured in the 6LBR by system 953 administration for all 6LBRs or configured on a per-6LBR basis. 955 o Filtering in router(s) or firewalls that provide access to 956 constrained network segments. For example, in an access router/ 957 bridge that connects a regular intranet LAN to a building control 958 IPv6 backbone. This backbone connects multiple 6LoWPAN segments, 959 each segment connected via a 6LBR. 961 6. Security Considerations 963 This section describes the relevant security configuration for CoAP 964 group communications using IP multicast. The threats to CoAP group 965 communications are also identified and various approaches to mitigate 966 these threats are summarized. 968 6.1. Security Configuration 970 As defined in [I-D.ietf-core-coap], CoAP group communications based 971 on IP multicast must use the following security modes: 973 o Group communications MUST operate in CoAP NoSec (No Security) 974 mode. 976 o Group communications MUST NOT use "coaps" scheme. That is, all 977 group communications MUST use only "coap" scheme. 979 o Group communications MUST NOT use IPSec. 981 6.2. Threats 983 Essentially the above configuration means that there is no security 984 at the CoAP layer for group communications. This is due to the fact 985 that the current DTLS based approach for CoAP is exclusively unicast 986 oriented and does not support group security features such as group 987 key exchange and group authentication. As a direct consequence of 988 this, CoAP group communications is vulnerable to all attacks 989 mentioned in [I-D.ietf-core-coap] for IP multicast. 991 6.3. Threat Mitigation 993 [I-D.ietf-core-coap] identifies various threat mitigation techniques 994 for CoAP IP multicast. In addition to those guidelines, it is 995 recommended that for sensitive data or safety-critical control, a 996 combination of appropriate link-layer security and administrative 997 control of IP multicast boundaries should be used. Some examples are 998 given below. 1000 6.3.1. WiFi Scenario 1002 In a home automation scenario (using WiFi), the WiFi encryption 1003 should be enabled to prevent rogue nodes from joining. Also, if MAC 1004 address filtering at the WiFi Access Point is supported that should 1005 also be enabled. The IP router should have the fire wall enabled to 1006 isolate the home network from the rest of the Internet. In addition, 1007 the domain of the IP multicast should be set to be either link-local 1008 scope or site-local scope. Finally, if possible, devices should be 1009 configured to accept only Source Specific Multicast (SSM) packets 1010 (see [RFC4607]) from within the trusted home network. For example, 1011 all lights in a particular room should only accept IP multicast 1012 traffic originating from the master light switch in that room. In 1013 this case, the Spoofed Source Address considerations of Section 7.4 1014 of [RFC4607] should be heeded. 1016 6.3.2. 6LoWPAN Scenario 1018 In a building automation scenario, a particular room may have a 1019 single 6LoWPAN topology with a single Edge Router (6LBR). Nodes on 1020 the subnet can use link-layer encryption to prevent rogue nodes from 1021 joining. The 6LBR can be configured so that it blocks any incoming 1022 IP multicast traffic. Another example topology could be a multi- 1023 subnet 6LoWPAN in a large conference room. In this case, the 1024 backbone can implement port authentication (IEEE 802.1X) to ensure 1025 only authorized devices can join the Ethernet backbone. The access 1026 router to this secured segment can also be configured to block 1027 incoming IP multicast traffic. 1029 6.3.3. Future Evolution 1031 In the future, to further mitigate the threats, the developing 1032 approach for DTLS-based IP multicast security for CoAP networks (see 1033 [I-D.keoh-tls-multicast-security]) or similiar approaches should be 1034 considered once they mature. 1036 7. IANA Considerations 1038 No request is made to IANA. (Note to RFC Editor: The required 1039 multicast address request to IANA is made in [I-D.ietf-core-coap]). 1041 8. Acknowledgements 1043 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1044 Castellani, Guang Lu, Salvatore Loreto, Kerry Lynn, Dale Seed, Zach 1045 Shelby, Peter van der Stok, and Juan Carlos Zuniga for their helpful 1046 comments and discussions that have helped shape this document. 1048 9. References 1050 9.1. Normative References 1052 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1053 Requirement Levels", BCP 14, RFC 2119, March 1997. 1055 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1056 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1057 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1059 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1060 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1062 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1063 Architecture", RFC 4291, February 2006. 1065 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1066 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1067 Protocol Specification (Revised)", RFC 4601, August 2006. 1069 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1070 IP", RFC 4607, August 2006. 1072 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1073 "Transmission of IPv6 Packets over IEEE 802.15.4 1074 Networks", RFC 4944, September 2007. 1076 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1077 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1078 March 2010. 1080 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1081 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1082 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1083 Lossy Networks", RFC 6550, March 2012. 1085 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1086 the Internet Group Management Protocol (IGMP) and 1087 Multicast Listener Discovery (MLD) for Routers in Mobile 1088 and Wireless Networks", RFC 6636, May 2012. 1090 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1091 Format", RFC 6690, August 2012. 1093 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1094 "Neighbor Discovery Optimization for IPv6 over Low-Power 1095 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1096 November 2012. 1098 [I-D.ietf-core-coap] 1099 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1100 "Constrained Application Protocol (CoAP)", 1101 draft-ietf-core-coap-13 (work in progress), December 2012. 1103 9.2. Informative References 1105 [I-D.ietf-core-block] 1106 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1107 draft-ietf-core-block-10 (work in progress), October 2012. 1109 [I-D.vanderstok-core-dna] 1110 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1111 Naming, and Addressing", draft-vanderstok-core-dna-02 1112 (work in progress), July 2012. 1114 [I-D.ietf-roll-trickle-mcast] 1115 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1116 and Lossy Networks (MPL)", 1117 draft-ietf-roll-trickle-mcast-03 (work in progress), 1118 January 2013. 1120 [I-D.keoh-tls-multicast-security] 1121 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 1122 Security for Low-Power and Lossy Networks (LLNs)", 1123 draft-keoh-tls-multicast-security-00 (work in progress), 1124 October 2012. 1126 Appendix A. Multicast Listener Discovery (MLD) 1128 In order to extend the scope of IP multicast beyond link-local scope, 1129 an IP multicast routing or forwarding protocol has to be active in 1130 routers on an LLN. To achieve efficient multicast routing (i.e. 1131 avoid always flooding multicast IP packets), routers have to learn 1132 which hosts need to receive packets addressed to specific IP 1133 multicast destinations. 1135 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1136 IPv4 pendant IGMP) is today the method of choice used by an (IP 1137 multicast enabled) router to discover the presence of multicast 1138 listeners on directly attached links, and to discover which multicast 1139 addresses are of interest to those listening nodes. MLD was 1140 specifically designed to cope with fairly dynamic situations in which 1141 multicast listeners may join and leave at any time. 1143 IGMP/MLD Snooping is a technique implemented in some corporate LAN 1144 routing/switching devices. An MLD snooping switch listens to MLD 1145 State Change Report messages from MLD listeners on attached links. 1146 Based on this, the switch learns on what LAN segments there is 1147 interest for what IP multicast traffic. If the switch receives at 1148 some point an IP multicast packet, it uses the stored information to 1149 decide onto which LAN segment(s) to send the packet. This improves 1150 network efficiency compared to the regular behavior of forwarding 1151 every incoming multicast packet onto all LAN segments. An MLD 1152 snooping switch may also send out MLD Query messages (which is 1153 normally done by a device in MLD Router role) if no MLD Router is 1154 present. 1156 [RFC6636] discusses optimal tuning of the parameters of MLD for 1157 routers for mobile and wireless networks. These guidelines may be 1158 useful when implementing MLD in LLNs. 1160 Appendix B. Change Log 1162 Changes from ietf-04 to ietf-05: 1164 o Added a new section 3.9 (Exceptions) that highlights that IP 1165 multicast (and hence group communications) is not always available 1166 (#187). 1168 o Updated text on the use of [RFC2119] language (#271) in Section 1. 1170 o Included guidelines on when (not) to use CoAP responses to 1171 multicast requests and when (not) to accept multicast requests 1172 (#273). 1174 o Added guideline on use of core-block for minimizing response size 1175 (#275). 1177 o Restructured section 6 (Security Considerations) to more fully 1178 describe threats and threat mitigation (#277). 1180 o Clearly indicated that DNS resolution and reverse DNS lookup are 1181 optional. 1183 o Removed confusing text about a single group having multiple IP 1184 addresses. If multiple IP addresses are required then multiple 1185 groups (with the same members) should be created. 1187 o Removed repetitive text about the fact that group communications 1188 is not guaranteed. 1190 o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP 1191 Multicast Routing Background) and added link to section 5.2 1192 (Advertising Membership of Multicast Groups). 1194 o Clarified text in section 3.8 (Congestion Control) regarding 1195 precedence of use of IP multicast domains (i.e. first try to use 1196 link-local scope, then site-local scope, and only use global IP 1197 multicast as a last resort). 1199 o Extended group resource manipulation guidelines with use of 1200 preconfigured ports/paths for the multicast group. 1202 o Consolidated all text relating to ports in a new section 3.3 (Port 1203 Configuration). 1205 o Clarified that all methods (GET/PUT/POST) for configuring group 1206 membership in endpoints should be unicast (and not multicast) in 1207 section 3.7 (Configuring Group Membership In Endpoints). 1209 o Various editorial updates for improved readability, including 1210 editorial comments by Peter van der Stok to WG list of December 1211 18th, 2012. 1213 Changes from ietf-03 to ietf-04: 1215 o Removed section 2.3 (Potential Solutions for Group Communications) 1216 as it is purely background information and moved section to 1217 draft-dijk-core-groupcomm-misc (#266). 1219 o Added reference to draft-keoh-tls-multicast-security to section 6 1220 (Security Considerations). 1222 o Removed Appendix B (CoAP-Observe Alternative to Group 1223 Communications) as it is as an alternative to IP Multicast that 1224 the WG has not adopted and moved section to 1225 draft-dijk-core-groupcomm-misc (#267). 1227 o Deleted section 8 (Conclusions) as it is redundant (#268). 1229 o Simplified light switch use case (#269) by splitting into basic 1230 operations and additional functions (#269). 1232 o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) 1233 to draft-dijk-core-groupcomm-misc (#270). 1235 o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) 1236 to draft-dijk-core-groupcomm-misc as these sections essentially 1237 just repeated text from other drafts regarding DNS based features. 1238 Clarified remaining text in this draft relating to DNS based 1239 features to clearly indicate that these features are optional 1240 (#272). 1242 o Focus section 3.5 (Configuring Group Membership) on a single 1243 proposed solution. 1245 o Scope of section 5.3 (Use of MLD) widened to multicast destination 1246 advertisement methods in general. 1248 o Rewrote section 2.2 (Scope) for improved readability. 1250 o Moved use cases that are not addressed to 1251 draft-dijk-core-groupcomm-misc. 1253 o Various editorial updates for improved readability. 1255 Changes from ietf-02 to ietf-03: 1257 o Clarified that a group resource manipulation may return back a 1258 mixture of successful and unsuccessful responses (section 3.4 and 1259 Figure 6) (#251). 1261 o Clarified that security option for group communication must be 1262 NoSec mode (section 6) (#250). 1264 o Added mechanism for group membership configuration (#249). 1266 o Removed IANA request for multicast addresses (section 7) and 1267 replaced with a note indicating that the request is being made in 1268 [I-D.ietf-core-coap] (#248). 1270 o Made the definition of 'group' more specific to group of CoAP 1271 endpoints and included text on UDP port selection (#186). 1273 o Added explanatory text in section 3.4 regarding why not to use 1274 group communication for non-idempotent messages (i.e. CoAP POST) 1275 (#186). 1277 o Changed link-local RD discovery to site-local in RD discovery use 1278 case to make it more realistic. 1280 o Fixed lighting control use case CoAP proxying; now returns 1281 individual CoAP responses as in coap-12. 1283 o Replaced link format I-D with RFC6690 reference. 1285 o Various editorial updates for improved readability 1287 Changes from ietf-01 to ietf-02: 1289 o Rewrote congestion control section based on latest CoAP text 1290 including Leisure concept (#188) 1292 o Updated the CoAP/HTTP interworking section and example use case 1293 with more details and use of MLD for multicast group joining 1295 o Key use cases added (#185) 1297 o References to [I-D.vanderstok-core-dna] and 1298 draft-castellani-core-advanced-http-mapping added 1300 o Moved background sections on "MLD" and "CoAP-Observe" to 1301 Appendices 1303 o Removed requirements section (and moved it to 1304 draft-dijk-core-groupcomm-misc) 1306 o Added details for IANA request for group communication multicast 1307 addresses 1309 o Clarified text to distinguish between "link local" and general 1310 multicast cases 1312 o Moved lengthy background section 5 to 1313 draft-dijk-core-groupcomm-misc and replaced with a summary 1315 o Various editorial updates for improved readability 1317 o Change log added 1319 Changes from ietf-00 to ietf-01: 1321 o Moved CoAP-observe solution section to section 2 1323 o Editorial changes 1325 o Moved security requirements into requirements section 1327 o Changed multicast POST to PUT in example use case 1329 o Added CoAP responses in example use case 1331 Changes from rahman-07 to ietf-00: 1333 o Editorial changes 1335 o Use cases section added 1337 o CoRE Resource Directory section added 1338 o Removed section 3.3.5. IP Multicast Transmission Methods 1340 o Removed section 3.4 Overlay Multicast 1342 o Removed section 3.5 CoAP Application Layer Group Management 1344 o Clarified section 4.3.1.3 RPL Routers with Non-RPL Hosts case 1346 o References added and some normative/informative status changes 1348 Authors' Addresses 1350 Akbar Rahman (editor) 1351 InterDigital Communications, LLC 1353 Email: Akbar.Rahman@InterDigital.com 1355 Esko Dijk (editor) 1356 Philips Research 1358 Email: esko.dijk@philips.com