idnits 2.17.1 draft-rahman-core-groupcomm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of 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 (October 12, 2011) is 4578 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 5867' is mentioned on line 262, but not defined == Unused Reference: 'I-D.ietf-6lowpan-hc' is defined on line 1500, 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 (-11) exists of draft-cheshire-dnsext-dns-sd-10 == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-17 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-07 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-07 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-02 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 == Outdated reference: A later version (-05) exists of draft-vanderstok-core-bc-04 == Outdated reference: A later version (-07) exists of draft-castellani-core-http-mapping-01 == Outdated reference: A later version (-06) exists of draft-garcia-core-security-02 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-00 Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE A. Rahman, Ed. 3 Internet-Draft InterDigital Communications, LLC 4 Intended status: Informational E. Dijk, Ed. 5 Expires: April 14, 2012 Philips Research 6 October 12, 2011 8 Group Communication for CoAP 9 draft-rahman-core-groupcomm-07 11 Abstract 13 This is a working document intended to trigger discussion and develop 14 draft text for the CoAP protocol specification in the area of group 15 communication. Engineering tradeoffs become more challenging in 16 constrained environments, therefore group communication is considered 17 within the context of adjacent topics that may impact or be impacted 18 by design choices in the subject area. A solution based on IP 19 multicast is proposed. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 14, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Problem Statement and Scope . . . . . . . . . . . . . . . 4 59 3. Potential Solutions . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.3.1. Multicast Listener Discovery (MLD) and Multicast 64 Router Discovery (MRD) . . . . . . . . . . . . . . . . 8 65 3.3.2. Group URIs and Multicast Addresses . . . . . . . . . . 9 66 3.3.3. Group Discovery . . . . . . . . . . . . . . . . . . . 9 67 3.3.4. Group Resource Manipulation . . . . . . . . . . . . . 10 68 3.3.5. IP Multicast Transmission Methods . . . . . . . . . . 11 69 3.3.6. Congestion Control . . . . . . . . . . . . . . . . . . 12 70 3.4. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 13 71 3.5. CoAP Application Layer Group Management . . . . . . . . . 13 72 3.6. CoAP Multicast and HTTP Unicast Interworking . . . . . . . 16 73 3.7. CoAP-Observe for Group Communication . . . . . . . . . . . 18 74 4. Recommended Solution . . . . . . . . . . . . . . . . . . . . . 18 75 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.2. An Example Protocol Flow . . . . . . . . . . . . . . . . . 19 77 4.3. Implementation in Target Network Topologies . . . . . . . 22 78 4.3.1. Single LLN Topology . . . . . . . . . . . . . . . . . 23 79 4.3.2. Single LLN with Backbone Topology . . . . . . . . . . 25 80 4.3.3. Multiple LLNs with Backbone Topology . . . . . . . . . 27 81 4.3.4. LLN(s) with Multiple 6LBRs . . . . . . . . . . . . . . 27 82 4.3.5. Conclusions . . . . . . . . . . . . . . . . . . . . . 27 83 4.4. HTTP/CoAP Interworking Aspects . . . . . . . . . . . . . . 28 84 4.5. Implementation Considerations . . . . . . . . . . . . . . 28 85 4.5.1. MLD Implementation on LLNs . . . . . . . . . . . . . . 28 86 4.5.2. 6LBR Implementation . . . . . . . . . . . . . . . . . 29 87 4.5.3. Backbone IP Multicast Infrastructure . . . . . . . . . 29 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 90 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 33 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 97 1. Conventions and Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 The following are definitions of specific terminology used in this 104 draft. 106 Group Communication: A source node sends a message to more than one 107 destination node, where all destinations are identified to belong to 108 a specific group. The set of source nodes and destination nodes may 109 consist of an arbitrary mix of constrained and non-constrained nodes. 110 Sending methods may include serial unicast, multicast, or hybrid 111 unicast-to-multicast solutions. 113 Multicast: Sending a message to multiple receiving nodes 114 simultaneously. Typically, this is done as part of a group 115 communication process. There are various options to implement 116 multicast including layer 2 (Media Access Control) or layer 3 (IP) 117 mechanisms. 119 IP Multicast: A specific multicast solution based on the use of IP 120 multicast addresses as defined in "IANA Guidelines for IPv4 Multicast 121 Address Assignments" [RFC5771] and "IP Version 6 Addressing 122 Architecture" [RFC4291]. 124 Low power and Lossy Network (LLN): LLNs are made up of constrained 125 devices. These devices may be interconnected by a variety of links, 126 such as IEEE 802.15.4, Bluetooth, WiFi, wired or low-power powerline 127 communication links. 129 2. Introduction 131 2.1. Background 133 The CoRE working group is chartered to design and standardize a 134 Constrained Application Protocol (CoAP) for resource constrained 135 devices and networks [I-D.ietf-core-coap]. The requirements for CoAP 136 are documented in [I-D.shelby-core-coap-req]. 138 Constrained devices can be large in number, but highly correlated to 139 each other. For example, all the light switches in a building may 140 belong to one group and all the thermostats belong to another group. 141 All the smart meters in the same region can belong to a group as 142 well. Groups may be composed by function; for example, the group 143 "all lights in building one" may consist of the groups "all lights on 144 floor one of building one", "all lights on floor two of building 145 one", etc. Groups may also be configured or dynamically formed. 147 In this draft, we focus and expand discussions on the requirements 148 pertaining to CoAP "group communication" and "multicast" support 149 including: 151 REQ 9: CoAP will support a non-reliable IP multicast message to be 152 sent to a group of Devices to manipulate a resource on all the 153 Devices simultaneously. The use of multicast to query and 154 advertise descriptions must be supported, along with the support 155 of unicast responses. 157 Currently, the CoAP protocol [I-D.ietf-core-coap] supports unreliable 158 IP multicast using UDP. It defines the unreliable multicast 159 operation as follows: 161 "CoAP supports sending messages to multicast destination 162 addresses. Such multicast messages MUST be Non-Confirmable. 163 Mechanisms for avoiding congestion from multicast requests are 164 being considered in [I-D.eggert-core-congestion-control]." 166 Additional requirements were introduced in [I-D.vanderstok-core-bc] 167 driven by quality of experience issues in commercial lighting; the 168 need for large numbers of devices to respond with near simultaneity 169 to a command (multicast PUT), and for that command to be received 170 reliably (reliable multicast). 172 2.2. Problem Statement and Scope 174 In this draft, we expand the scope from unreliable IP multicast in 175 the current CoAP requirement to group communication, using either 176 (reliable or unreliable) multicast or unicast or combinations 177 thereof. We assume that all, or a substantial part of, devices 178 participating in group communication are constrained devices (e.g. 179 such as Low Power and Lossy Network (LLN) devices). 181 Machine-to-Machine (M2M) networks may contain groups of nodes that 182 are highly correlated (e.g. by type or location). For example, all 183 smart meters in a region may belong to one group, and all light 184 switches in a building control system belong to another. Group 185 communication mechanisms can improve efficiency and latency of 186 communication and reduce bandwidth requirements for a given 187 application. 189 In the following sections, we address the issues related to group 190 communication in detail, with requirements, proposed solutions and 191 analysis of their impact to the CoAP protocol and implementations. 193 3. Potential Solutions 195 3.1. Overview 197 The classic concept of group communications is that of a single 198 source distributing content to multiple recipients that are all part 199 of a group, as shown in the example sequence diagram in Figure 1. 200 Also shown there is the pre-requisite step of forming the group 201 before content can be distributed to it. 203 Group communication solutions have evolved from "bottom" to "top", 204 i.e., from the network layer (IP multicast) to application layer 205 group communication, also referred to as application layer multicast. 206 A study published in 2005 [STUDY1] identified new solutions in the 207 "middle" (referred to as overlay multicast) that utilize an 208 infrastructure based on proxies. 210 Each of these classes of solutions may be compared [STUDY1] using 211 metrics such as link stress and level of host complexity [STUDY2]. 212 The results show for a realistic internet topology that IP Multicast 213 is most resource-efficient, with the only downside being that it 214 requires most effort to deploy in the infrastructure. 216 The approach adopted in this section is to begin with group 217 communication requirements. This is followed by the solutions of IP 218 multicast, an overlay multicast solution, and application layer group 219 communication. Finally additional topics are covered such as group 220 management and CoAP/HTTP proxies in group communication. 222 CoAP CoAP CoAP CoAP 223 Node 1 Node 2 Proxy Node 3 224 | | | | 225 | REQUEST | | | 226 | (Join Group X) | | | 227 |-----------------|------------- >| | 228 | RESPONSE | | | 229 |< ---------------|---------------| | 230 | | | | 231 | | REQUEST | | 232 | |(Join Group X) | | 233 | |------------- >| | 234 | | RESPONSE | | 235 | |< -------------| | 236 | | | | 237 | | | | 238 | | | REQUEST | 239 | | | (Send to | 240 | | | Group X ) | 241 | | |< -----------------| 242 | | | | 243 | | Map to | 244 | | Group X addresses | 245 | | | | 246 | | | | 247 | REQUEST (to multicast addr) | | 248 |< ---------------|< -------------| | 249 | | | | 250 | (optional) RESPONSE | | 251 | |------------- >| | 252 |-----------------|-------------->| | 253 | | | RESPONSE | 254 | | |----------------- >| 255 | | | | 257 Figure 1: CoAP Group Communications 259 3.2. Requirements 261 Requirements that a group communication solution in CoRE should 262 fulfill can be found in existing documents [RFC 5867] 263 [draft-ietf-6lowpan-routing-requirements] [I-D.vanderstok-core-bc] 264 [I-D.shelby-core-coap-req]. Below, a set of high-level requirements 265 is listed that a group communication solution in CoRE should ideally 266 fulfill. More precise requirements may depend on the chosen 267 application (area). 269 A CoRE group communication solution should (ideally) offer: 270 REQ 1: Optional Reliability: unreliable group communication, with 271 preferably reliable group communication as an option. 272 REQ 2: Efficiency: delivers messages more efficiently than a 273 "serial unicast only" solution. Also, it should provide a 274 right balance between group data traffic and control 275 overhead. 276 REQ 3: Low latency: deliver a message (preferably) as fast as 277 possible. 278 REQ 4: Synchrony: allows near-simultaneous modification of a 279 resource on all devices in a group, providing to users a 280 perceived effect of synchrony or simultaneity. It can be 281 expressed as a time span D such that message m is delivered 282 to all destinations in a time interval [t,t+D] for 283 arbitrary t. 284 REQ 5: Ordering: message ordering in the reliable group 285 communication mode. 286 REQ 6: Security: see Section 5 for security requirements for group 287 communication. 288 REQ 7: Flexibility: support for one or many source(s), for dense 289 and sparse networks, for high or low listener density, one 290 or many group(s), and multi-group membership. 291 REQ 8: Robust group management: includes functionality to join 292 groups, leave groups, view group membership, and persistent 293 group membership in failing node or sleeping node 294 situations. 295 REQ 9: Network layer independence: a solution should be specified 296 independent from specific unicast and/or IP multicast 297 routing protocols. It should support different routing 298 protocols and implementations thereof. 299 REQ 10: Minimal specification overhead: a group communication 300 solution should preferably re-use existing/established 301 (IETF) protocols that are suitable for LLN deployments, 302 instead of defining new protocols from scratch. 303 REQ 11: Minimal implementation overhead: e.g. a solution allows to 304 re-use existing (software) components that are already 305 present on constrained nodes such as (typical) 6LoWPAN/CoAP 306 nodes. 307 REQ 12: Mixed backbone/LLN topology support: a solution should work 308 within a single LLN, and in combined LLN/backbone network 309 topologies, including multi-LLN topologies. Both the 310 senders and receivers of CoAP group messages may be 311 attached to different network links or be part of different 312 LLNs, possibly with routers or switches in between group 313 members. In addition, different routing protocols may 314 operate on the LLN and backbone networks. Preferably a 315 solution also works with existing, common backbone IP 316 infrastructure (e.g. switches or routers). 318 REQ 13: CoAP Proxying support: a CoAP proxy can handle distribution 319 of a message to a group on behalf of a (constrained) CoAP 320 client. 321 REQ 14: Suitable for operation on LLNs with constrained nodes. 323 3.3. IP Multicast 325 IP Multicast protocols have been evolving for decades, resulting in 326 proposed standards such as Protocol Independent Multicast - Sparse 327 Mode (PIM-SM) [RFC4601]. Yet, due to various technical and marketing 328 reasons, IP Multicast is not widely deployed on the general Internet. 329 However, IP Multicast is popular in specific deployments such as in 330 enterprise networks (e.g. for video conferencing or general IP 331 multicast PC applications within a single LAN broadcast domain) and 332 carrier IPTV deployments. Therefore, the packet economy and minimal 333 host complexity of IP multicast make it worth investigating for group 334 communication in constrained environments. 336 3.3.1. Multicast Listener Discovery (MLD) and Multicast Router 337 Discovery (MRD) 339 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 340 IPv4 pendant IGMP) is today the method of choice used by an (IP 341 multicast enabled) IPv6 router to discover the presence of multicast 342 listeners on directly attached links, and to discover which multicast 343 addresses are of interest to those listening nodes. It was 344 specifically designed to cope with fairly dynamic situations in which 345 multicast listeners may join and leave at any time. 347 IGMP/MLD Snooping is a technique implemented in some corporate LAN 348 routing/switching devices. An MLD snooping switch listens to MLD 349 State Change Report messages from MLD listeners on attached links. 350 Based on this, the switch learns on what LAN segments there is 351 interest for what IP multicast traffic. If the switch receives at 352 some point a multicast packet, it uses the stored information to 353 decide onto which LAN segment(s) to send the packet. This improves 354 network efficiency compared to the regular switch behavior of 355 forwarding every incoming multicast packet onto all LAN segments. An 356 MLD snooping switch may also send out MLD Query messages (which is 357 normally done by an MLD Router) if no MLD router is present. 359 The Multicast Router Discovery (MRD) protocol [RFC4286] defines a way 360 to discover multicast routers, for the purpose of using this 361 information by IGMP/MLD snooping devices. However, it appears that 362 this protocol is not as commonly implemented in existing products as 363 MLD is. 365 3.3.2. Group URIs and Multicast Addresses 367 An approach to map group authorities onto IP multicast addresses 368 using DNS was proposed in [I-D.vanderstok-core-bc]. Examples of 369 group URI naming (and scoping) for a building control application are 370 shown below. Group URIs MUST follow the approach of the URI 371 structure defined in [RFC3986]. 373 URI authority Targeted group 374 all.bldg6... "all nodes in building 6" 375 all.west.bldg6... "all nodes in west wing, building 6" 376 all.floor1.west.bldg6... "all nodes in floor 1, west wing, 377 etc." 378 all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, 379 etc." 381 The authority portion of the URI is used to identify a node (or 382 group) and the resulting DNS name is bound to a unicast or multicast 383 IP address. Each example group URI shown above can be mapped to a 384 unique multicast IP address. This may be an address allocated 385 according to [RFC3956], [RFC3306] or [RFC3307]. 387 3.3.3. Group Discovery 389 CoAP defines a resource discovery capability but, in the absence of a 390 standardized group communication infrastructure, it is limited to 391 link-local scope IP multicast; examples may be found in 392 [I-D.ietf-core-link-format]. A service discovery capability is 393 required to extend discovery to other subnets and scale beyond a 394 certain point, as originally proposed in [I-D.vanderstok-core-bc]. 396 DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a 397 conventional way to configure DNS PTR, SRV, and TXT records to enable 398 enumeration of services, such as services offered by CoAP nodes, or 399 enumeration of all CoAP nodes, within specified subdomains. A 400 service is specified by a name of the form 401 .., where the service type for CoAP 402 nodes is _coap._udp and the domain is a DNS domain name that 403 identifies a group as in the examples above. For each CoAP end-point 404 in a group, a PTR record with the name _coap._udp or alternatively 405 the name _coap._upd. is defined and it points to an SRV 406 record having the .. name. 408 All CoAP nodes in a given subdomain may be enumerated by sending a 409 query for PTR records named _coap._udp to the authoritative DNS 410 server for that zone. A list of SRV records is returned. Each SRV 411 record contains the port and host name (AAAA record) of a CoAP node. 412 The IP address of the node is obtained by resolving the host name. 414 DNS-SD also specifies an optional TXT record, having the same name as 415 the SRV record, which can contain "key=value" attributes. This can 416 be used to store information about the device, e.g. schema=DALI, 417 type=switch, group=lighting.bldg6, etc. 419 Another feature of DNS-SD is the ability to specify service subtypes 420 using PTR records. For example, one could represent all the CoAP 421 groups in a subdomain by PTR records with the name 422 _group._sub._coap._udp or alternatively 423 _group._sub._coap._udp.. 425 3.3.4. Group Resource Manipulation 427 At least two forms of group resource manipulation must be supported. 428 The first is push (multicast PUT or MPUT for short) as e.g. "turn off 429 all the lights simultaneously". Logically, this is similar to 430 publishing a value to multiple subscribers. The second operation is 431 pull (multicast GET or MGET), which is essential for discovery during 432 commissioning and can be illustrated by the example "return all the 433 resources on all CoAP servers advertized by their .well-known/core 434 URI". MGET to an "all-nodes" or "all-CoAP-nodes" multicast IP 435 address should perhaps be limited in scope to link-local multicast 436 for scaling [TBD: and possibly for security reasons, e.g. DoS 437 attacks]. 439 Conceptually, the result of a multicast GET or PUT should be the same 440 as if the client had unicast them serially (that is, a set of {URI, 441 representation} tuples). Practically, there are major benefits to 442 avoiding serial unicast in favor of a multicast CoAP GET/PUT 443 solution: 445 - packet economy on constrained networks 446 - M2M resource discovery (solves the "chicken-and-egg" problem) 447 - apparent simultaneity of events (e.g. in lighting applications) 448 - average lower latency per event (e.g. in lighting applications) 450 Ideally, all nodes in a given group (defined by its multicast IP 451 address) must receive the same request with high probability. This 452 will not be the case if there is diversity in the authority port 453 (i.e. a diversity of dynamic port addresses across the group) or if 454 the targeted resource is located at different paths on different 455 nodes. Extending the definition of group membership to include port 456 and path discovery is not desirable. 458 Therefore, some measures must be present to ensure uniformity in port 459 number and resource name/location within a group. 461 A first solution in this respect is to couple groups to service 462 descriptions in DNS (using DNS-SD as in Section 3.3.3 and 463 [I-D.vanderstok-core-bc]). A service description for a multicast 464 group may have a TXT record in DNS defining a schema X (e.g. 465 "schema=DALI"), which defines by service standard X (e.g. "DALI") 466 which resources a node supporting X MUST have. Therefore a multicast 467 source can safely refer to all resources with corresponding 468 operations as prescribed by standard X. For port numbers (which can 469 be found using DNS-SD also) the same holds. Alternatively, only the 470 default CoAP port may be used in all requests. 472 A second solution is to impose the following restrictions, e.g. for 473 groups not found using, or advertized in, DNS-SD: 474 o All CoAP multicast requests MUST be sent to the well-known CoAP 475 port. 476 o All CoAP multicast requests SHOULD operate on /.well-known/core 477 URIs 479 One question is whether the application (or middleboxes) need to be 480 aware that a request is intended for a group. A separate scheme as 481 proposed by [ID.goland-http-udp] might be useful (e.g. "corem" vs. 482 "core"). To the extent that group membership might be implemented as 483 a series of IP multicast, serial unicast, or some combination, having 484 a distinct scheme for group operations might be a useful signal for a 485 proxy receiving the request to look up the group membership and 486 replicate serial unicasts as well as send multicast packets. 488 3.3.5. IP Multicast Transmission Methods 490 3.3.5.1. Serial unicast 492 Even in systems that generally support IP Multicast, there may be 493 certain data links (or transports) that don't support IP multicast. 494 For those links a serial unicast alternative must be provided. This 495 implies that it should be possible to enumerate the members of a 496 group, in order to determine the correct unicast destinations. 498 3.3.5.2. Unreliable IP Multicast 500 The CoRE WG charter specified support for non-reliable IP multicast. 501 In the current CoAP protocol design [I-D.ietf-core-coap], unreliable 502 multicast is realized by the source sending Non-Confirmable messages 503 to a multicast IP address. IP Multicast (using UDP) in itself is 504 unreliable, unless specific reliability features are added to it. 506 3.3.5.3. Reliable IP Multicast 508 [TBD: This is a difficult problem. Need to investigate the benefits 509 of repeating MGET and MPUT requests (saturation) to get "Pretty Good 510 Reliability". Use the same MID or a new MID for repeated requests? 511 Carsten suggests the use of bloom filters to suppress duplicate 512 responses. 514 One could argue that non-idempotent operations (POST) cannot be 515 supported without a *truly* reliable multicast protocol. However, is 516 this the case? If a multicast POST request is sent repeatedly with 517 the same Message ID (MID), then CoAP nodes that already received it 518 once will ignore duplicates. Sending with Message ID is supported in 519 CoAP for Non-Confirmable messages (thus including multicast messages) 520 as per [I-D.ietf-core-coap] section 4.2. ] 522 Reliable multicast supports guaranteed delivery of messages to a 523 group of nodes. The following specifies the requirements as was 524 proposed originally in version 01 of [I-D.vanderstok-core-bc]: 525 o Validity - If sender sends a message, m, to a group, g, of 526 destinations, a path exists between sender and destinations, and 527 the sender and destinations are correct, all destinations in g 528 eventually receive m. 529 o Integrity - destination receives m at most once from sender and 530 only if sender sent m to a group including destination. 531 o Agreement - If a correct destination of g receives m, then all 532 correct destinations of g receive m. 533 o Timeliness - For real-time control of devices, there is a known 534 constant D such that if m is sent at time t, no correct 535 destination receives m after t+D. 536 There are various approaches to achieve reliability, such as 538 o Destination node sends response: a destination sends a CoAP 539 Response upon multicast Request reception (it SHOULD be a Non- 540 Confirmable response). The source node may retry a request to 541 destination nodes that did not respond in time with a CoAP 542 response. 543 o Route redundancy 544 o Source node transmits multiple times (destinations do not respond) 546 3.3.6. Congestion Control 548 CoAP requests may be multicast, resulting a multitude of replies from 549 different nodes, potentially causing congestion. 550 [I-D.eggert-core-congestion-control] suggests to conservatively 551 control sending multicast requests. 553 CoAP already addresses the congestion problem to some extent by 554 requiring all multicast CoAP requests to be Non-Confirmable. 555 However, as responses to multicast requests (both MGET or MPUT) are 556 required in CoAP, using CoAP multicast still may lead to congestion 557 issues. 559 Various means can be implemented to prevent congestion. 561 [TBD: if an MGET or MPUT request leads to the sending of a CoAP 562 response by servers, the servers should enforce a random delay within 563 TIMEOUT before sending their responses. More investigation 564 required.] 566 Currently in the CoAP protocol, a MAX_RETRANSMIT value set by default 567 to 4 is used for retransmission of Confirmable messages. Since CoAP 568 multicast messages are Non-Confirmable, no retransmissions will occur 569 in CoAP, making the effective retransmission value 0. 571 3.4. Overlay Multicast 573 An alternative group communication solution (to IP Multicast) is an 574 "overlay multicast" approach. We define an overlay multicast as one 575 that utilizes an infrastructure based on proxies (rather than an IP 576 router based IP multicast backbone) to deliver IP multicast packets 577 to end devices. MLD (Section 3.3.1) has been selected as the basis 578 for multicast support by the ROLL working group for the RPL routing 579 protocol. Therefore, it is proposed that "IGMP/MLD Proxying" 580 [RFC4605] be used as a basis for an overlay multicast solution for 581 CoAP. 583 Specifically, a CoAP proxy [I-D.ietf-core-coap] may also contain an 584 MLD Proxy function. All CoAP devices that want to join a given IP 585 multicast group would then send an MLD Join to the CoAP (MLD) proxy. 586 Thereafter, the CoAP (MLD) proxy would be responsible for delivering 587 any IP multicast message to the subscribed CoAP devices. This will 588 require modifications to the existing [RFC4605] functionality. 590 Note that the CoAP (MLD) proxy may or may not be connected to an 591 external IP multicast enabled backbone. The key function for the 592 CoAP (MLD) proxy is to distribute CoAP generated multicast packets 593 even in the absence of router support for multicast. 595 3.5. CoAP Application Layer Group Management 597 Another alternative solution (to IP Multicast and Overlay Multicast) 598 is to define CoAP application level group management primitives. 599 Thus, CoAP can support group management features without need for any 600 underlying IP multicast support. 602 Interestingly, such group management primitives could also be offered 603 even if there is underlying IP multicast support. This is useful 604 because IP multicast inherently does not support the concept of a 605 group with managed members, while a managed group may be required for 606 some applications. 608 The following group management primitives are in general useful: 609 o discover groups; 610 o query group properties (e.g. related resource descriptions); 611 o create a group; 612 o remove a group; 613 o add a group member; 614 o remove a group member; 615 o enumerate group members; 616 o security and access control primitives. 618 In this proposal a (at least one) CoAP Proxy node is responsible for 619 group membership management. A constrained node can specify which 620 group it intends to join (or leave) using a CoAP request to the 621 appropriate CoAP Proxy. To Join, the group name will be included in 622 optional request header fields (explained below). These header 623 fields will be included in a PUT request to the Proxy. The Proxy-URI 624 is set to the Group Management URI of the Proxy (found previously 625 through the "/.well-known/" resource discovery mechanism). Note that 626 in this solution also CoAP Proxies may exist in a network that are 627 not capable of CoAP group operations. 629 Group names may be defined as arbitrary strings with a predefined 630 maximum length (e.g. 268 characters or the maximum string length in a 631 CoAP Option), or as URIs. 633 [ TBD: how can a client send a request to a group? Does it only need 634 to know the group name (string or URI) or also an IP multicast 635 address? One way is to send a CoAP request to the CoAP Proxy with a 636 group URI directly in the Proxy-URI field. This avoids having to 637 know anything related to IP multicast addresses. ] 639 This solution in principle supports both unreliable and reliable 640 group communication. A client would indicate unreliable 641 communication by sending a CoAP Non-Confirmable request to the CoAP 642 Proxy, or reliable communication by sending a CoAP Confirmable 643 request. 645 It is proposed that CoAP supports two Header Options for group "Join" 646 and "Leave". These Options are Elective so they should be assigned 647 an even number. Assuming the Type for "join" is x (value TBD), the 648 Header Options are illustrated by the table in Figure 2: 650 +------+-----+---------------+--------------+--------+--------------+ 651 | Type | C/E | Name | Data type | Length | Default | 652 |------+-----+---------------+--------------+--------+--------------+ 653 | | | | | | | 654 | x | E | Group Join | String | 1-270 | "" | 655 | | | | | B | | 656 | x+2 | E | Group Leave | String | 1-270 | "" | 657 | | | | | B | | 658 +------+-----|---------------+--------------+--------+--------------+ 660 Figure 2: CoAP Header Options for Group Management 662 Figure 3 illustrates how a node can join or leave a group using the 663 Header Options in a CoAP message: 665 0 1 2 3 666 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 |Ver| T | OC | Code | Message ID | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | delta |length | Join Group A (ID or URI) 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | 0 |length | Join Group B (ID or URI) 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | 2 |length | Leave Group C (ID or URI) 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 3: CoAP Message for Group Management 679 Header Fields for the above example: 681 Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by 682 implementation as defined by the CoAP specification. 684 T: 2-bit unsigned integer for CoAP Transaction Type. Either '0' 685 Confirmation or '1' Non-Confirmable can be used for group "join" or 686 "leave" request. 688 OC: 4-bit unsigned integer for Option Count. For this example, the 689 value should be "3" since there are three option fields. 691 Code: 8-bit unsigned integer to indicate the Method in a Request or a 692 Response Code in a Response message. Any Code can be used so the 693 group management can be piggy-backed in either Request or Response 694 message. 696 Message ID: 16-bit value assigned by the source to uniquely identify 697 a pair of Request and Response. 699 CoAP defines a delta encoding for header options. The first delta is 700 the "Type" for group join in this specific example. If the type for 701 group join is x as illustrated in Figure 3, delta will be x. In the 702 second header option, it is also a group join so the delta is 0. The 703 third header option is a group leave so the delta is 2. 705 An alternative solution to using Header Options (explained above) is 706 to use designated parameters in the query part of the URI in the 707 Proxy-URI field of a POST (TBD: or PUT?) request to a Proxy's group 708 management service resource advertized by DNS-SD. For example, to 709 join group1 and leave group2: 711 coap://proxy1.bld2.example.com/groupmgt?j=group1&l=group2 713 3.6. CoAP Multicast and HTTP Unicast Interworking 715 Within the constrained network, CoAP runs over UDP for which IP 716 multicast is supported. In a non-constrained network (i.e. general 717 Internet), HTTP over TCP is used for which IP multicast is not 718 supported. Therefore a CoAP/HTTP Proxy node that supports group 719 communication needs to have functionalities to support interworking 720 of unicast and multicast. One possible way of operation of the Proxy 721 is illustrated in Figure 4. Note that this topic is covered in more 722 detail in [I-D.castellani-core-http-mapping]. 724 CoAP CoAP CoAP/HTTP HTTP 725 Node 1 Node 2 Proxy Node 3 726 | | | | 727 | REQUEST | | | 728 | (Join Group X) | | | 729 |-----------------|------------- >| | 730 | RESPONSE | | | 731 |< ---------------|---------------| | 732 | | | | 733 | | REQUEST | | 734 | | (Join Group X)| | 735 | |------------- >| | 736 | | RESPONSE | | 737 | |< -------------| | 738 | | | | 739 | | | | 740 | | | HTTP REQUEST | 741 | | | (URI to | 742 | | | unicast addr) | 743 | | |< -----------------| 744 | | | | 745 | | Map URI | 746 | | to Group X multicast address | 747 | | | | 748 | REQUEST (to multicast addr) | | 749 |< ---------------|< -------------| | 750 | | | | 751 | | | | 752 | (optional) RESPONSE | | 753 | |------------- >| | 754 |-----------------|-------------->| | 755 | | | HTTP RESPONSE | 756 | | |----------------- >| 757 | | | | 759 Figure 4: CoAP Multicast and HTTP Unicast Interworking 761 Note that Figure 4 illustrates the case of IP multicast as the 762 underlying group communications mechanism. However the overlay 763 multicast group communication (Section 3.4) or CoAP application group 764 communication (Section 3.5) can be used as the underlying mechanism 765 and the principles of the figure would still apply (i.e. CoAP proxy 766 needs to do interworking between HTTP unicast and CoAP multicast). 768 A key point in Figure 4 is that the incoming HTTP Request (from node 769 3) will carry a URI (with the HTTP scheme) that resolves in the 770 general Internet to the proxy node. At the proxy node, the URI will 771 then possibly be mapped (as detailed in 772 [I-D.castellani-core-http-mapping]) and again resolved (with the CoAP 773 scheme) to an IP multicast destination. This may be accomplished, 774 for example, by using DNS-SD (Section 3.3.3). The proxy node will 775 then IP multicast the CoAP Request (corresponding to the received 776 HTTP Request) to the appropriate nodes (i.e. nodes 1 and 2). 778 In terms of the HTTP Response, Figure 4 illustrates that it will be 779 generated by the proxy node based on aggregated responses of the CoAP 780 nodes and sent back to the client in the general Internet that sent 781 the HTTP Request (i.e. node 1). In 782 [I-D.castellani-core-http-mapping] the HTTP Response that the Proxy 783 may use to aggregate multiple CoAP responses is described in more 784 detail. So in terms of overall operation, the CoAP proxy can be 785 considered to be a "non-transparent" proxy according to [RFC2616]. 786 Specifically, [RFC2616] states that a "non-transparent proxy is a 787 proxy that modifies the request or response in order to provide some 788 added service to the user agent, such as group annotation services, 789 media type transformation, protocol reduction or anonymity 790 filtering." 792 An alternative to the above is using a Forward Proxy. In this case, 793 the CoAP request URI could be carried in the HTTP Request Line (as 794 defined in [I-D.ietf-core-coap] Section 8) in a HTTP request sent to 795 the IP address of the Proxy. 797 3.7. CoAP-Observe for Group Communication 799 The CoAP Observation extension [I-D.ietf-core-observe] can be 800 directly used for group communication. A group then consists of a 801 CoAP server hosting a specific resource, plus all CoAP clients 802 observing that resource. The server is the only group member that 803 can send a group message. It does this by modifying the state of a 804 resource under observation and subsequently notifying its observers 805 of the change. Serial unicast is used in this case for 806 notifications. 808 Group communication is unreliable in the sense that, even though 809 confirmable CoAP messages may be used, there are no guarantees that 810 an update will be received. For example, a client may believe it is 811 observing a resource while in reality the server rebooted and lost 812 its listener state. 814 4. Recommended Solution 815 4.1. Overview 817 We recommend that IP multicast as outlined in Section 3.3 be adopted 818 as the base solution for CoAP Group Communication. This approach re- 819 uses the IP multicast suite of protocols and can operate on both 820 constrained and non-constrained network segments. The group 821 communication can hence work regardless of the underlying networking 822 technology. Still, this approach may require specifying or 823 implementing additional IP Multicast functionality in an LLN, in a 824 backbone network, or in both - this will be evaluated in more detail 825 in this section. 827 4.2. An Example Protocol Flow 829 We first present an example use case to illustrate the overall steps 830 in an IP Multicast based CoAP Group Communication solution. We 831 assume the following network configuration for this example (see 832 Figure 5): 834 1) A large room (Room-A) with three lights (Light-1, Light-2, 835 Light-3) controlled by a Light Switch. The devices are organized 836 into two 6LoWPAN subnets. 838 2) Light-1 and the Light Switch are connected to a router (Rtr-1) 839 which is also a CoAP Proxy and a 6LoWPAN Border Router (6LBR). 841 3) Light-2 and the Light-3 are connected to another router (Rtr-2) 842 which is also a CoAP Proxy and a 6LBR. 844 4) The routers are connected to a an IPv6 network backbone which is 845 also multicast enabled. In the general case, this means the network 846 backbone and 6LBRs support a PIM based multicast routing protocol, 847 and MLD for forming groups. In a limited case, if the network 848 backbone is one link, then the routers only have to support MLD- 849 snooping for the example use case to work. 851 Network 852 Backbone 853 | 854 ################################################ | 855 # Room-A # | 856 # ********************** # | 857 # ** LoWPAN-1 ** # | 858 # * * # | 859 # * +----------+ * # | 860 # * | Light |-------+ * # | 861 # * | Switch | | * # | 862 # * +----------+ +---------+ * # | 863 # * | Rtr-1 |-----------------------------| 864 # * +---------+ * # | 865 # * +----------+ | * # | 866 # * | Light-1 |--------+ * # | 867 # * +----------+ * # | 868 # * * # | 869 # ** ** # | 870 # ********************** # | 871 # # | 872 # # | 873 # ********************** # | 874 # ** LoWPAN-2 ** # | 875 # * * # | 876 # * +----------+ * # | 877 # * | Light-2 |-------+ * # | 878 # * | | | * # | 879 # * +----------+ +---------+ * # | 880 # * | Rtr-2 |-----------------------------| 881 # * +---------+ * # | 882 # * +----------+ | * # | 883 # * | Light-3 |--------+ * # | 884 # * +----------+ * # | 885 # * * # | 886 # ** ** # | 887 # ********************** # | 888 # # | 889 ################################################# | 890 | 891 +--------+ | 892 | DNS |------------------| 893 | Server | 894 +--------+ 896 Figure 5: Network Topology of a Large Room (Room-A) 898 The corresponding protocol flow for an IP Multicast based CoAP Group 899 Communication solution for the network shown in Figure 5 is shown in 900 Figure 6. We assume the following steps occur before the illustrated 901 flow: 903 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 904 all devices. The CoAP network is formed. 906 2) Commissioning phase (by applications): The IP multicast address of 907 the group (Room-A-Lights) has been set in all the Lights. The URI of 908 the group (Room-A-Lights) has been set in the Light Switch. 910 Light Network 911 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 912 | | | | | | | 913 | | | | | | | 914 | MLD Report: Join | | | | | 915 | Group (Room-A-Lights) | | | | 916 |------------------------------------------>| | | 917 | | | | |MLD Report: Join | 918 | | | | |Group (Room-A-Lights)| 919 | | | | |-------------------->| 920 | | | | | | | 921 | | MLD Report: Join | | | | 922 | | Group (Room-A-Lights) | | | 923 | |------------------------------------------>| | 924 | | | | | | | 925 | | | MLD Report: Join | | | 926 | | | Group (Room-A-Lights) | | 927 | | |------------------------------->| | 928 | | | | | | | 929 | | | | |MLD Report: Join | 930 | | | | |Group (Room-A-Lights)| 931 | | | | | |--------->| 932 | | | | | | | 933 | | *********************** | | 934 | | * User flips on * | | 935 | | * light switch to * | | 936 | | * turn on all the * | | 937 | | * lights in Room A * | | 938 | | *********************** | | 939 | | | | | | | 940 | | | | | | | 941 | | | COAP NON (POST | | | 942 | | | (Proxy-URI | | | 943 | | | (URI for Room-A-Lights)) | 944 | | | turn on lights) | | 945 | | | |--------->| | | 946 | | | | | | | 947 | | | | | | | 948 | | | | Request DNS resolution of | 949 | | | | URI for Room-A-Lights | 950 | | | | |-------------------->| 951 | | | | | | | 952 | | | | | | | 953 | | | | DNS returns: AAAA | 954 | | | | Group (Room-A-Lights) | 955 | | | | IPv6 multicast address | 956 | | | | |<--------------------| 957 | | | | | | | 958 | | | | | | | 959 | | | | COAP NON (POST | 960 | | | | (URI Path) | 961 | | | | turn on lights) | 962 | | | | with IP multicast address| 963 | | | | for Group (Room-A-Lights)| 964 | | | | |-------------------->| 965 |<------------------------------------------| | | 966 | | | | | | | 967 | | | | | |<---------| 968 | |<---------|<-------------------------------| | 969 | | | | | | | 970 *********************** | | | | 971 * Lights in Room-A * | | | | 972 * turn on (nearly * | | | | 973 * simultaneously) * | | | | 974 *********************** | | | | 975 | | | | | | | 977 Figure 6: Turning on Lights in a Large Room (Room-A) 979 The indicated MLD Report messages are link-local multicast. In each 980 LoWPAN, it is assumed that a multicast routing protocol in 6LRs will 981 propagate the Join information over multiple hops to the 6LBR. 983 4.3. Implementation in Target Network Topologies 985 This section looks in more detail how an IP Multicast based solution 986 can be deployed onto the various network topologies that we consider 987 important for group communication use cases. Note that the chosen 988 solution of IP Multicast for CoAP group communication works mostly 989 independently from the underlying network topology and its specific 990 IP multicast implementation. 992 Starting from the simplest case of a single LLN topology, we move to 993 more complex topologies involving a backbone network or multiple 994 LLNs. With "backbone" we refer here typically to a corporate LAN or 995 VLAN, which constitutes a single broadcast domain by design. It 996 could also be an in-home network. A multi-link backbone is also 997 possible, if there is proper IP multicast routing or forwarding 998 configured between these links. (The term 6LoWPAN Border Router or 999 "6LBR" is used here for a border router, though our evaluation is not 1000 necessarily restricted to 6LoWPAN networks.) 1002 4.3.1. Single LLN Topology 1004 The simplest topology is a single LLN, where all the IP multicast 1005 source(s) and destinations are constrained nodes within this same 1006 LLN. Possible implementations of IP multicast routing and group 1007 administration for this topology are listed below. 1009 4.3.1.1. Mesh-Under Multicast Routing 1011 The LLN may be set up in either a mesh-under or a route-over 1012 configuration. In the former case, the mesh routing protocol should 1013 take care of routing IP multicast messages througout the LLN. 1015 Because conceptually all nodes in the LLN are attached to a single 1016 link, there is in principle no need for nodes to announce their 1017 interest in multicast IP addresses via MLD (see Section 3.3.1). A 1018 multicast message to a specific IP destination, which is delivered to 1019 all 6LoWPAN nodes by the mesh routing algorithm, is accepted by the 1020 IP network layer of that node only if it is listening on that 1021 specific multicast IP address and port. 1023 4.3.1.2. RPL Multicast Routing 1025 The RPL routing protocol for LLNs provides support for routing to 1026 multicast IP destinations (Section 12 of [I-D.ietf-roll-rpl]). Like 1027 regular unicast destinations, multicast destinations are advertized 1028 by nodes using RPL DAO messages. This functionality requires 1029 "Storing mode with multicast support" (Mode Of Operation, MOP is 3) 1030 in the RPL network. 1032 Once all RPL routing tables in the network are populated, any RPL 1033 node can send packets to an IP multicast destination. The RPL 1034 protocol performs distribution of multicast packet both upward 1035 towards the DODAG root and downwards into the DODAG. 1037 The text in Section 12 of the RPL specification clearly implies that 1038 IP multicast packets are distributed using link-layer unicast 1039 transmissions, looking at the use of the word "copied" in this 1040 section. Specifically in 6LoWPAN networks, this behavior conflicts 1041 with the requirement that IP multicast packets MUST be carried as 1042 link-layer 802.15.4 broadcast frames [RFC4944]. 1044 Assuming that link-layer unicast is indeed meant, this approach seems 1045 efficient only in a balanced, sparse tree network topology, or in 1046 situations where the fraction of nodes listening to a specific 1047 multicast IP address is low, or in duty cycled LLNs where link-layer 1048 broadcast is a very expensive operation. 1050 4.3.1.3. RPL Routers with Non-RPL Hosts 1052 Now we consider the case that hosts exist in a RPL network that are 1053 not RPL-aware themselves, but use link-local RPL routers for their IP 1054 connectivity. Note that the current RPL specification 1055 [I-D.ietf-roll-rpl] considers this case to be out of scope. However, 1056 it was suggested on the ROLL mailing list that RPL could potentially 1057 be run with non-RPL-aware hosts but that it is simply not specified 1058 yet. Such non-RPL hosts can't advertize their IP multicast groups of 1059 interest via RPL DAO messages as defined above. Therefore in that 1060 case MLD can be used for such advertizements (State Change Report 1061 messages), with all or a subset of RPL routers acting in the role of 1062 MLD Routers as defined in [RFC3810]. However, as the MLD protocol is 1063 not designed specifically for LLNs it may be a burden for the 1064 constrained RPL router nodes to run the full MLD protocol. 1065 Alternatives are therefore proposed in Section 4.5.1. 1067 4.3.1.4. Trickle Multicast Forwarding 1069 Trickle Multicast Forwarding [I-D.ietf-roll-trickle-mcast] is an IP 1070 multicast routing protocol suitable for LLNs, that uses the Trickle 1071 algorithm as a basis. It is a simple protocol in the sense that no 1072 topology maintenance is required. It can deal especially well with 1073 situations where the node density is a-priori unknown. 1075 Nodes from anywhere in the LLN can be the multicast source, and nodes 1076 anywhere in the LLN can be multicast destinations. 1078 Using Trickle Multicast Forwarding it is not required for IP 1079 multicast destinations (listeners) to announce their interest in a 1080 specific multicast IP address, e.g. by means of MLD. Instead, all 1081 multicast IP packets regardless of IP destination address are stored 1082 and forwarded by all routers. Because forwarding is always done by 1083 multicast, both hosts and routers will be able to receive all 1084 multicast IP packets. Routers that receive multicast packets they 1085 are not interested in, will only buffer these for a limited time 1086 until retransmission can be stopped as specified by the protocol. 1087 Hosts that receive multicast packets they are not interested in, will 1088 discard multicast packets that are not of interest. Above properties 1089 seem to make Trickle especially efficient for cases where the 1090 multicast listener density is high and the number of distinct 1091 multicast groups relatively low. 1093 4.3.1.5. Other Route-Over Methods 1095 Other known IP multicast routing methods may be used, for example 1096 flooding or other to be defined methods suitable for LLNs. An 1097 important design consideration here is whether multicast listeners 1098 need to advertize their interest in specific multicast addresses, or 1099 not. If they do, MLD is a possible option but also protocol-specific 1100 means (as in RPL) is an option. See Section 4.5.1 for more efficient 1101 substitutes for MLD targeted towards a LLN context. 1103 4.3.2. Single LLN with Backbone Topology 1105 A LLN may be connected via a Border Router (e.g. 6LBR) to a backbone 1106 network, on which IP multicast listeners and/or sources may be 1107 present. This section analyzes cases in which IP multicast traffic 1108 needs to flow from/to the backbone, to/from the LLN. 1110 4.3.2.1. Mesh-Under Multicast Routing 1112 Because in a mesh routing network conceptually all nodes in the LLN 1113 are attached to a single link, a multicast IP packet originating in 1114 the LLN is typically delivered by the mesh routing algorithm to the 1115 6LBR as well, although there is no guaranteed delivery. The 6LBR may 1116 be configured to accept all IP multicast traffic from the LLN and 1117 then may forward such packets onto its backbone link. Alternatively, 1118 the 6LBR may act in an MLD Router or MLD Snooper role on its backbone 1119 link and decide whether to forward a multicast packet or not based on 1120 information learnt from previous MLD Reports received on its backbone 1121 link. 1123 Conversely, multicast packets originating on the backbone network 1124 will reach the 6LBR if either the backbone is a single link (LAN/ 1125 VLAN) or IPv6 multicast routing is enabled on the backbone. Then, 1126 the 6LBR could simply forward all IP multicast traffic from the 1127 backbone onto the LLN. However, in practice this situation may lead 1128 to overload of the LLN caused by unnecessary multicast traffic. 1129 Therefore the 6LBR SHOULD only forward traffic that one or more nodes 1130 in the LLN have expressed interest in, effectively filtering inbound 1131 LLN multicast traffic. 1133 To realize this "filter", nodes on the LLN may use MLD to announce 1134 their interest in specific multicast IP addresses to the 6LBR. One 1135 option is for the 6LBR to act in an MLD Router role on its LLN 1136 interface. However, this may be too much of a "burden" for 1137 constrained nodes. Light-weight alternatives for MLD are discussed 1138 in Section 4.5.1. 1140 4.3.2.2. RPL Multicast Routing 1142 For RPL routing within the 6LoWPAN, we first consider the case of an 1143 IP multicast source on the backbone network with one or more IP 1144 multicast listeners on the RPL LLN. Typically, the 6LBR would be the 1145 root of a DODAG so that the 6LBR can easily forward the IP multicast 1146 packet received on its backbone interface to the right RPL nodes in 1147 the LLN down along this DODAG (based on previously DAO-advertized 1148 destinations). 1150 Second, a multicast source may be in the RPL LLN and listeners may be 1151 both on the LLN and on the backbone. For this case RPL defines that 1152 the multicast packet will propagate both up and down the DODAG, 1153 eventually reaching the DODAG root (typically a 6LBR) from which the 1154 packet can be routed onto the backbone in a manner specified in the 1155 previous section. 1157 4.3.2.3. RPL Routers with Non-RPL Hosts 1159 For the case that a RPL LLN contains non-RPL hosts, the solutions 1160 from the previous section can be used if in addition RPL routers 1161 implement MLD or "MLD like" functionality similar to as described in 1162 Section 4.3.1.3. 1164 4.3.2.4. Trickle Multicast Forwarding 1166 First, we consider the case of an IP multicast source node on the LLN 1167 (where all 6LRs support Trickle Multicast Forwarding) and IP 1168 multicast listeners that may be on the LLN and on the backbone. As 1169 Trickle will eventually deliver multicast packets also to a 6LBR, 1170 which acts as a Trickle Multicast router as well, the 6LBR can then 1171 forward onto the backbone in the ways described earlier in 1172 Section 4.3.2.1. 1174 Second, for the case of an IP multicast source on the backbone and 1175 multicast listeners on both backbone and/or LLN, the 6LBR needs to 1176 forward multicast traffic from the backbone onto the LLN. Here, the 1177 aforementioned problem (Section 4.3.2.1) of potentially overloading 1178 the LLN with unwanted backbone IP multicast traffic appears again. 1180 A possible solution to this is (again) to let multicast listeners 1181 advertize their interest using MLD as described in Section 4.3.2.1 or 1182 to use an MLD alternative suitable for LLNs as described in 1183 Section 4.5.1. However, following this approach requires possibly an 1184 extension to Trickle Multicast Forwarding: the protocol should ensure 1185 that MLD-advertized information is somehow communicated to the 6LBR, 1186 possibly over multiple hops. MLD itself supports link-local 1187 communication only. 1189 4.3.2.5. Other Route-Over Methods 1191 For other multicast routing methods used on the LLN, there are 1192 similar considerations to the ones in sections above: the strong need 1193 to filter IP multicast traffic coming into the LLN, the need for 1194 reporting multicast listener interest (e.g. with MLD or a to-be- 1195 defined MLD alternative) by constrained (6LoWPAN) nodes, and the need 1196 for LLN-internal routing as identified in the previous section such 1197 that the MLD communicated information can reach the 6LBR to be used 1198 there in multicast traffic filtering decisions. 1200 4.3.3. Multiple LLNs with Backbone Topology 1202 Now the case of a single backbone network with two or more LLNs 1203 attached to it via 6LBRs is considered. For this case all the 1204 considerations and solutions of the previous section can be applied. 1206 For the specific case that a source on a backbone network has to send 1207 to a very large number of destination located on many LLNs, the use 1208 of IGMP/MLD Proxying [RFC4605] with a leaf IGMP/MLD Proxy located in 1209 each 6LBR may be useful. This method only is defined for a tree 1210 topology backbone network with the IP multicast source at the root of 1211 the tree. 1213 4.3.4. LLN(s) with Multiple 6LBRs 1215 [ TBD: an LLN with multiple 6LBRs may require some additional 1216 consideration. Any need to synchronize mutually on multicast 1217 listener information? ] 1219 4.3.5. Conclusions 1221 For all network topologies that were evaluated, CoAP group 1222 communication can be in principle supported with IP Multicast, making 1223 use of existing protocols. For the case of Trickle Multicast 1224 Forwarding, it appears that an addition to the protocol is required 1225 such that information about multicast listeners can be distributed 1226 towards the 6LBR. Opportunities were identified for an "MLD-like" or 1227 "MLD-lightweight" protocol specifically suitable for LLNs, which 1228 should interwork with regular MLD on the backbone network. Such MLD 1229 variants are further analyzed in Section 4.5.1. 1231 4.4. HTTP/CoAP Interworking Aspects 1233 The topic of HTTP unicast to CoAP multicast request proxying is 1234 treated in [I-D.castellani-core-http-mapping]. [TBD: only if needed 1235 more information will be added here in the future.] 1237 4.5. Implementation Considerations 1239 In this section various implementation aspects are considered such as 1240 required protocol implementations, additional functionality of the 1241 6LBR and backbone network equipment. 1243 4.5.1. MLD Implementation on LLNs 1245 In previous sections, it was mentioned that the MLDv2 protocol 1246 [RFC3810] may be too costly for use in a LLN. MLD relies on periodic 1247 link-local multicast operations to maintain state. Also it is 1248 optimized to fairly dynamic situations where multicast listeners may 1249 come and go over time. Such dynamic situations are less frequently 1250 found in typical LLN use cases such as building control, where 1251 multicast group membership can remain constant over longer periods of 1252 time (e.g. months) after commissioning. 1254 Hence, a viable strategy is to implement a subset of MLD 1255 functionality in 6LoWPAN nodes which is just enough for the required 1256 functionality. A first option is that 6LoWPAN Routers, like MLD 1257 Snoopers, passively listen to MLD State Change Report messages and 1258 handle the learnt ("snooped") IP multicast destinations in the way 1259 defined by the multicast routing protocol they are running (e.g. for 1260 RPL, Routers advertize these destinations using DAO messages). 1262 A second option is to use MLD as-is but adapt the recommended 1263 parameter values such that operation on a LLN becomes more efficient. 1265 A third option is to standardize a new protocol, taking a subset of 1266 MLD functionality into a "MLD for 6LoWPAN" protocol to support 1267 constrained nodes optimally. 1269 A fourth option is now presented, which seems attractive in that it 1270 minimizes standardization, implementation and network communication 1271 overhead all at the same time. This option is to specify a new 1272 Multicast Listener Option (MLO) as an addition to the 6LoWPAN-ND 1273 [I-D.ietf-6lowpan-nd] protocol communication that is anyway ongoing 1274 between a 6LoWPAN host and router(s). This MLO is preferably 1275 designed to be maximally similar to the Address Registration Option 1276 (ARO), which minimizes the need for additional program code on 1277 constrained nodes. With an MLO, instead of registering a unicast IP 1278 address, a host "registers" its interest in a multicast IP address. 1280 Unlike ARO, multiple MLO can be used in the same ND packet. A 1281 registration period is also defined just like in the ARO. MLO allows 1282 a host to persistently register as a listener to IP multicast traffic 1283 and to avoid the overhead of periodic multicast communication which 1284 is required for full MLD. 1286 [ TBD: consider what aspects are needed/not needed for CoAP/LLN 1287 applications. Will MLDv1 suffice? What to do with options like 1288 'source specific' and include/exclude. Source-specific can also be 1289 dealt with at the destination host by filtering? Do we need limits 1290 on number of records per packet? Do we need a higher MLD reliability 1291 setting - see the parameters in the MLD RFC ] 1293 4.5.2. 6LBR Implementation 1295 To support mixed backbone/LLN scenarios in CoAP group communication, 1296 it is RECOMMENDED that a 6LowPAN Border Router (6LBR) will act in an 1297 MLD Router role on the backbone link. If this is not possible then 1298 the 6LBR SHOULD be configured to act as an MLD Multicast Address 1299 Listener and/or MLD Snooper on the backbone link. 1301 4.5.3. Backbone IP Multicast Infrastructure 1303 For corporate/professional applications, most routing and switching 1304 equipment that is currently on the market is IPv6 capable. For that 1305 reason backbone infrastructure operating IPv4 only is considered out 1306 of scope in this document, at least for the backbone network 1307 segment(s) where IP multicast destinations are present. What is 1308 still in scope is for example an IPv4-only HTTP client that wants to 1309 send a group communication message via a HTTP-CoAP proxy as 1310 considered in [I-D.castellani-core-http-mapping]. 1312 The availability of, and requirements for, IP multicast support may 1313 depend on the specific installation use case. For example, the 1314 following cases may be relevant for new IP based building control 1315 installations: 1316 1. System deployed on existing IP (Ethernet/WiFi/...) 1317 infrastructure, shared with existing IP devices (PCs) 1318 2. Newly designed & deployed IP (Ethernet/WiFi/...) infrastructure, 1319 to be shared with other IP devices (PCs) 1320 3. Newly designed & deployed IP (Ethernet/WiFi/...) infrastructure, 1321 exclusively used for building control. 1322 Besides physical separation the building control backbone can be 1323 separated from regular (PC) infrastructure by using a different VLAN. 1324 A typical corporate installation will have many LAN switches and/or 1325 routing switches, which pass through IP multicast traffic but on the 1326 other hand do not support acting in the Router role of MLD/IGMP. 1327 Perhaps for case 2) and 3) above it is acceptable to add a MLD/IGMP 1328 capable router somewhere in the network, while for case 1) this may 1329 not be the case. 1331 [TBD: consider the influence of WiFi based backbone networks. What 1332 if 6LBRs are at the same time also WiFi routers? What if 6LBRs have 1333 an Ethernet connection to legacy WiFI routers? Check if equivalent 1334 with Ethernet backbone.] 1336 5. Security Considerations 1338 Security for group communications at the IP level has been studied 1339 extensively in the IETF MSEC (Multicast Security) WG, and to a lesser 1340 extent in the IRTF SAMRG (Scalable Adaptive Multicast Research 1341 Group). In particular, [RFC3740], [RFC5374] and [RFC4046] are very 1342 instructive. A set of requirements for securing group communications 1343 in CoAP were derived from a study of these previous investigations as 1344 well as understanding of CoAP specific needs. These are listed 1345 below. 1347 Note that some of the requirements are marked optional. This means 1348 that, depending on the use case, these may be required or not. For 1349 this purpose each use case can be associated to a security profile as 1350 specified in [I-D.garcia-core-security]. The security profile 1351 prescribes what requirements should be taken into account for this 1352 profile. A mapping of these requirements to these profiles has not 1353 yet been done. 1355 REQ1- Group communications data encryption: Important CoAP group 1356 communications shall be encrypted (using a group key) to preserve 1357 confidentiality. It shall also be possible to send CoAP group 1358 communications in the clear (i.e. unencrypted) for low value data. 1360 REQ2- Group communications source data authentication: Important CoAP 1361 group communications shall be authenticated by verifying the source 1362 of the data (i.e. that it was generated by a given and trusted group 1363 member). It shall also be possible to send unauthenticated CoAP 1364 group communications for low value data. 1366 REQ3- Group communications limited data authentication: Less 1367 important CoAP group communications shall be authenticated by simply 1368 verifying that it originated from one of the group members (i.e. 1369 without explicitly identifying the source node). This is a weaker 1370 requirement (but simpler to implement) than REQ2. It shall also be 1371 possible to send unauthenticated CoAP group communications for low 1372 value data. 1374 REQ4- Group key management: There shall be a secure mechanism to 1375 manage the cryptographic keys (e.g. generation and distribution) 1376 belonging to the group; the state (e.g. current membership) 1377 associated with the keys; and other security parameters. 1379 REQ5- Use of Multicast IPSec: The CoAP protocol [I-D.ietf-core-coap] 1380 allows IPSec to be used as one option to secure CoAP. If IPSec is 1381 used as a way to security CoAP communications, then multicast IPSec 1382 [RFC5374] should be used for securing CoAP group communications. 1384 REQ6- Independence from underlying routing security: CoAP group 1385 communication security shall not be tied to the security of 1386 underlying routing and distribution protocols such as PIM [RFC4601] 1387 and RPL [I-D.ietf-roll-rpl]. Insecure or inappropriate routing 1388 (including IP multicast routing) may cause loss of data to CoAP but 1389 will not affect the authenticity or secrecy of CoAP group 1390 communications. 1392 REQ7- Interaction with HTTPS: The security scheme for CoAP group 1393 communications shall account for the fact that it may need to 1394 interact with HTTPS (Hypertext Transfer Protocol Secure) when a 1395 transaction involves a node in the general Internet (non-constrained 1396 network) communicating via a HTTP-CoAP proxy. 1398 6. IANA Considerations 1400 This document makes no request of IANA. 1402 7. Conclusions 1404 Three solutions for enabling CoAP group communications have been 1405 discussed. 1407 Unreliable IP multicast as outlined in Section 3.3 is recommended to 1408 be adopted as the base solution for CoAP Group Communication on LLNs. 1409 This approach requires no standards changes to the IP multicast suite 1410 of protocols and it provides interoperability with IP multicast group 1411 communication on unconstrained backbone networks. 1413 The proposals for group communication described in this draft should 1414 be considered for incorporation into the overall CoAP protocol 1415 specification. 1417 8. Acknowledgements 1419 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1420 Castellani, Guang Lu, Salvatore Loreto, Kerry Lynn, Dale Seed, Zach 1421 Shelby, Peter van der Stok, and Juan Carlos Zuniga for their helpful 1422 comments and discussions that have helped shape this document. 1424 9. References 1426 9.1. Normative References 1428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1429 Requirement Levels", BCP 14, RFC 2119, March 1997. 1431 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1432 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1433 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1435 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1436 Multicast Addresses", RFC 3306, August 2002. 1438 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1439 Addresses", RFC 3307, August 2002. 1441 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 1442 Architecture", RFC 3740, March 2004. 1444 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1445 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1447 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1448 Point (RP) Address in an IPv6 Multicast Address", 1449 RFC 3956, November 2004. 1451 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1452 Resource Identifier (URI): Generic Syntax", STD 66, 1453 RFC 3986, January 2005. 1455 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1456 "Multicast Security (MSEC) Group Key Management 1457 Architecture", RFC 4046, April 2005. 1459 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 1460 RFC 4286, December 2005. 1462 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1463 Architecture", RFC 4291, February 2006. 1465 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1466 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1468 Protocol Specification (Revised)", RFC 4601, August 2006. 1470 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1471 "Internet Group Management Protocol (IGMP) / Multicast 1472 Listener Discovery (MLD)-Based Multicast Forwarding 1473 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1475 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1476 "Transmission of IPv6 Packets over IEEE 802.15.4 1477 Networks", RFC 4944, September 2007. 1479 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 1480 Extensions to the Security Architecture for the Internet 1481 Protocol", RFC 5374, November 2008. 1483 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1484 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1485 March 2010. 1487 9.2. Informative References 1489 [I-D.cheshire-dnsext-dns-sd] 1490 Cheshire, S. and M. Krochmal, "DNS-Based Service 1491 Discovery", draft-cheshire-dnsext-dns-sd-10 (work in 1492 progress), February 2011. 1494 [I-D.eggert-core-congestion-control] 1495 Eggert, L., "Congestion Control for the Constrained 1496 Application Protocol (CoAP)", 1497 draft-eggert-core-congestion-control-01 (work in 1498 progress), January 2011. 1500 [I-D.ietf-6lowpan-hc] 1501 Hui, J. and P. Thubert, "Compression Format for IPv6 1502 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 1503 draft-ietf-6lowpan-hc-15 (work in progress), 1504 February 2011. 1506 [I-D.ietf-6lowpan-nd] 1507 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 1508 Discovery Optimization for Low Power and Lossy Networks 1509 (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), 1510 June 2011. 1512 [I-D.ietf-core-coap] 1513 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1514 "Constrained Application Protocol (CoAP)", 1515 draft-ietf-core-coap-07 (work in progress), July 2011. 1517 [I-D.ietf-core-link-format] 1518 Shelby, Z., "CoRE Link Format", 1519 draft-ietf-core-link-format-07 (work in progress), 1520 July 2011. 1522 [I-D.ietf-core-observe] 1523 Hartke, K. and Z. Shelby, "Observing Resources in CoAP", 1524 draft-ietf-core-observe-02 (work in progress), March 2011. 1526 [I-D.shelby-core-coap-req] 1527 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 1528 Kelsey, "CoAP Requirements and Features", 1529 draft-shelby-core-coap-req-02 (work in progress), 1530 October 2010. 1532 [I-D.vanderstok-core-bc] 1533 Stok, P. and K. Lynn, "CoAP Utilization for Building 1534 Control", draft-vanderstok-core-bc-04 (work in progress), 1535 July 2011. 1537 [I-D.castellani-core-http-mapping] 1538 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1539 E. Dijk, "Best practices for HTTP-CoAP mapping 1540 implementation", draft-castellani-core-http-mapping-01 1541 (work in progress), July 2011. 1543 [I-D.garcia-core-security] 1544 Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and 1545 R. Struik, "Security Considerations in the IP-based 1546 Internet of Things", draft-garcia-core-security-02 (work 1547 in progress), July 2011. 1549 [I-D.ietf-roll-rpl] 1550 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1551 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 1552 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1553 Lossy Networks", draft-ietf-roll-rpl-19 (work in 1554 progress), March 2011. 1556 [I-D.ietf-roll-trickle-mcast] 1557 Hui, J. and R. Kelsey, "Multicast Forwarding Using 1558 Trickle", draft-ietf-roll-trickle-mcast-00 (work in 1559 progress), April 2011. 1561 [ID.goland-http-udp] 1562 Goland, Y., "Multicast and Unicast UDP HTTP Messages", 1563 1999, 1564 . 1566 [STUDY1] Lao, L., Cui, J., Gerla, M., and D. Maggiorini, "A 1567 Comparative Study of Multicast Protocols: Top, Bottom, or 1568 In the Middle?", 2005, . 1571 [STUDY2] Banerjee, B. and B. Bhattacharjee, "A Comparative Study of 1572 Application Layer Multicast Protocols", 2001, . 1576 Authors' Addresses 1578 Akbar Rahman (editor) 1579 InterDigital Communications, LLC 1581 Email: Akbar.Rahman@InterDigital.com 1583 Esko Dijk (editor) 1584 Philips Research 1586 Email: esko.dijk@philips.com