idnits 2.17.1 draft-dijk-core-groupcomm-misc-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2013) is 3788 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-06) exists of draft-castellani-core-advanced-http-mapping-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-14 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-16 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-05 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group E. Dijk, Ed. 3 Internet-Draft Philips Research 4 Intended status: Informational A. Rahman, Ed. 5 Expires: June 12, 2014 InterDigital Communications, LLC 6 December 9, 2013 8 Miscellaneous CoAP Group Communication Topics 9 draft-dijk-core-groupcomm-misc-05 11 Abstract 13 This document contains miscellaneous text around the topic of group 14 communication for the Constrained Application Protocol (CoAP). The 15 first part contains, for reference, text that was removed from the WG 16 version of Group Communication for CoAP draft. The second part 17 describes group communication and multicast functionality that may be 18 input to future standardization in the CoRE WG. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 12, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Potential Solutions for Group Communication . . . . . . . . . 3 56 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. General Requirements . . . . . . . . . . . . . . . . . . 5 60 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 6 61 5. Group Communication Solutions . . . . . . . . . . . . . . . . 8 62 5.1. IP Multicast Transmission Methods . . . . . . . . . . . . 8 63 5.1.1. Serial unicast . . . . . . . . . . . . . . . . . . . 8 64 5.1.2. Unreliable IP Multicast . . . . . . . . . . . . . . . 8 65 5.1.3. Reliable IP Multicast . . . . . . . . . . . . . . . . 8 66 5.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 9 67 5.3. CoAP Application Layer Group Management . . . . . . . . . 10 68 6. DNS-SD Based Group Resource Manipulation . . . . . . . . . . 12 69 7. Group Discovery and Member Discovery . . . . . . . . . . . . 13 70 7.1. DNS-SD . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.2. CoRE Resource Directory . . . . . . . . . . . . . . . . . 14 72 8. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 14 73 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.2. Implementation in Target Network Topologies . . . . . . . 14 75 8.2.1. Single LLN Topology . . . . . . . . . . . . . . . . . 15 76 8.2.2. Single LLN with Backbone Topology . . . . . . . . . . 17 77 8.2.3. Multiple LLNs with Backbone Topology . . . . . . . . 19 78 8.2.4. LLN(s) with Multiple 6LBRs . . . . . . . . . . . . . 19 79 8.2.5. Conclusions . . . . . . . . . . . . . . . . . . . . . 19 80 8.3. Implementation Considerations . . . . . . . . . . . . . . 19 81 8.3.1. MLD Implementation on LLNs and MLD alternatives . . . 20 82 8.3.2. 6LBR Implementation . . . . . . . . . . . . . . . . . 21 83 8.3.3. Backbone IP Multicast Infrastructure . . . . . . . . 21 84 9. Miscellaneous Topics . . . . . . . . . . . . . . . . . . . . 22 85 9.1. CoAP Multicast and HTTP Unicast Interworking . . . . . . 22 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 91 13.2. Informative References . . . . . . . . . . . . . . . . . 25 92 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 27 93 Appendix B. CoAP-Observe Alternative to Group Communication . . 28 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 96 1. Introduction 98 This document contains miscellaneous text around the topic of group 99 communication for the Constrained Application Protocol, CoAP 100 [I-D.ietf-core-coap]. The first part of the document (Section 5) 101 contains, for reference, text that was removed from the Group 102 Communication for CoAP [I-D.ietf-core-groupcomm] draft and its 103 predecessor [I-D.rahman-core-groupcomm]. The second part of the 104 document (Section 9) contains text and/or functionality that may be 105 considered for inclusion in [I-D.ietf-core-groupcomm] or otherwise 106 may be input to future standardization in the CoRE WG. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Potential Solutions for Group Communication 114 The classic concept of group communications is that of a single 115 source distributing content to multiple destination recipients that 116 are all part of a group. Before content can be distributed, there is 117 a separate process to form the group. The source may be either a 118 member or non-member of the group. 120 Group communication solutions have evolved from "bottom" to "top", 121 i.e., from layer 2 (Media Access Control broadcast/multicast) and 122 layer 3 (IP multicast) to application layer group communication, also 123 referred to as application layer multicast. A study published in 124 2005 [Lao05] identified new solutions in the "middle" (referred to as 125 overlay multicast) that utilize an infrastructure based on proxies. 127 Each of these classes of solutions may be compared [Lao05] using 128 metrics such as link stress and level of host complexity 129 [Banerjee01]. The results show for a realistic internet topology 130 that IP Multicast is the most resource-efficient, with the downside 131 being that it requires the most effort to deploy in the 132 infrastructure. IP Multicast is the solution adopted by this draft 133 for CoAP group communication. 135 3. Use Cases 137 CoAP group communication can be applied in the context of the 138 following use cases: 140 o Discovery of Resource Directory: discovering the local CoRE RD 141 which contains links (URIs) to resources stored on other servers 142 [RFC6690]. 144 o Lighting Control: synchronous operation of a group of 145 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 147 o Parameter Update: updating parameters/settings simultaneously in a 148 large group of devices in a building/campus control 149 ([I-D.vanderstok-core-bc]) application. 151 o Firmware Update: efficiently updating firmware simultaneously in a 152 large group of devices in a building/campus control 153 ([I-D.vanderstok-core-bc]) application. Here, the use of CoAP 154 group communication could be realized via a multicast extension of 155 CoAP blockwise transfer [I-D.ietf-core-block]. This use case and 156 use of multicast is especially valuable if there are time 157 constraints related to the software update for large groups of 158 devices. 160 o Group Status Report: requesting status information or event 161 reports from a group of devices in a building/campus control 162 application. In this use case, conditional reporting is required: 163 only device that have events to report (as indicated by the 164 request query) respond, others remain silent. This use case 165 requires reliable CoAP group communication, which is currently not 166 in CoRE WG scope. 168 4. Requirements 170 Requirements that a CoAP group communication solution should fulfill 171 can be found in existing documents ([RFC5867], 172 [I-D.ietf-6lowpan-routing-requirements], [I-D.vanderstok-core-bc], 173 and [I-D.shelby-core-coap-req]). Below, a set of high-level 174 requirements is listed that a group communication solution should 175 ideally fulfill. In practice, all these requirements can never be 176 satisfied at once in an LLN context. Furthermore, different use 177 cases will have different needs i.e. an elaboration of a subset of 178 below requirements. 180 4.1. Background 182 The requirements for CoAP are documented in 183 [I-D.shelby-core-coap-req]. In this draft, we focus and expand 184 discussions on the requirements pertaining to CoAP "group 185 communication" and "multicast" support as stated in 186 [I-D.shelby-core-coap-req]: 188 REQ 9: CoAP will support a non-reliable IP multicast message to be 189 sent to a group of Devices to manipulate a resource on all the 190 Devices simultaneously. The use of multicast to query and 191 advertise descriptions must be supported, along with the support 192 of unicast responses. 194 Currently, the CoAP protocol [I-D.ietf-core-coap] supports unreliable 195 IP multicast using UDP. It defines the unreliable multicast 196 operation as follows in Section 4.5: 198 "CoAP supports sending messages to multicast destination 199 addresses. Such multicast messages MUST be Non-Confirmable. Some 200 mechanisms for avoiding congestion from multicast requests are 201 being considered in [I-D.eggert-core-congestion-control]." 203 Additional requirements were introduced in [I-D.vanderstok-core-bc] 204 driven by quality of experience issues in commercial lighting; the 205 need for large numbers of devices to respond with near simultaneity 206 to a command (multicast PUT), and for that command to be received 207 reliably (reliable multicast). 209 4.2. General Requirements 211 A CoAP group communication solution should (ideally) meet the 212 following general requirements: 214 GEN-REQ 1: Optional Reliability: the application can select 215 between unreliable group communication and reliable group 216 communication. 218 GEN-REQ 2: Efficiency: delivers messages more efficiently than a 219 "serial unicast" solution. Provides a balance between group data 220 traffic and control overhead. 222 GEN-REQ 3: Low latency: deliver a message as quickly as possible. 224 GEN-REQ 4: Synchrony: allows near-simultaneous modification of a 225 resource on all devices in a target group, providing a perceived 226 effect of synchrony or simultaneity. For example a specified time 227 span D such that a message is delivered to all destinations in a 228 time interval [t,t+D]. 230 GEN-REQ 5: Ordering: message ordering may be required for reliable 231 group communication use cases. 233 GEN-REQ 6: Security: see Section 4.3 for security requirements for 234 group communication. 236 GEN-REQ 7: Flexibility: support for one or many source(s), both 237 dense and sparse networks, for high or low listener density, small 238 or large number of groups, and multi-group membership. 240 GEN-REQ 8: Robust group management: functionality to join groups, 241 leave groups, view group membership, and persistent group 242 membership in failure or sleeping node situations. 244 GEN-REQ 9: Network layer independence: a solution is independent 245 from specific unicast and/or IP multicast routing protocols. 247 GEN-REQ 10: Minimal specification overhead: a group communication 248 solution should preferably re-use existing/established (IETF) 249 protocols that are suitable for LLN deployments, instead of 250 defining new protocols from scratch. 252 GEN-REQ 11: Minimal implementation overhead: e.g. a solution allows 253 to re-use existing (software) components that are already present 254 on constrained nodes such as (typical) 6LoWPAN/CoAP nodes. 256 GEN-REQ 12: Mixed backbone/LLN topology support: a solution should 257 work within a single LLN, and in combined LLN/backbone network 258 topologies, including multi-LLN topologies. Both the senders and 259 receivers of CoAP group messages may be attached to different 260 network links or be part of different LLNs, possibly with routers 261 or switches in between group members. In addition, different 262 routing protocols may operate on the LLN and backbone networks. 263 Preferably a solution also works with existing, common backbone IP 264 infrastructure (e.g. switches or routers). 266 GEN-REQ 13: CoAP Proxying support: a CoAP proxy can handle 267 distribution of a message to a group on behalf of a (constrained) 268 CoAP client. 270 GEN-REQ 14: Suitable for operation on LLNs with constrained nodes. 272 4.3. Security Requirements 274 Security for group communications at the IP level has been studied 275 extensively in the IETF MSEC (Multicast Security) WG, and to a lesser 276 extent in the IRTF SAMRG (Scalable Adaptive Multicast Research 277 Group). In particular, [RFC3740], [RFC5374] and [RFC4046] are very 278 instructive. A set of requirements for securing group communications 279 in CoAP were derived from a study of these previous investigations as 280 well as understanding of CoAP specific needs. These are listed 281 below. 283 A CoAP group communication solution should (ideally) meet the 284 following security requirements: 286 SEC-REQ 1: Group communications data encryption: Important CoAP 287 group communications shall be encrypted (using a group key) to 288 preserve confidentiality. It shall also be possible to send CoAP 289 group communications in the clear (i.e. unencrypted) for low value 290 data. 292 SEC-REQ 2: Group communications source data authentication: 293 Important CoAP group communications shall be authenticated by 294 verifying the source of the data (i.e. that it was generated by a 295 given and trusted group member). It shall also be possible to 296 send unauthenticated CoAP group communications for low value data. 298 SEC-REQ 3: Group communications limited data authentication: Less 299 important CoAP group communications shall be authenticated by 300 simply verifying that it originated from one of the group members 301 (i.e. without explicitly identifying the source node). This is a 302 weaker requirement (but simpler to implement) than REQ2. It shall 303 also be possible to send unauthenticated CoAP group communications 304 for low value data. 306 SEC-REQ 4: Group key management: There shall be a secure mechanism 307 to manage the cryptographic keys (e.g. generation and 308 distribution) belonging to the group; the state (e.g. current 309 membership) associated with the keys; and other security 310 parameters. 312 SEC-REQ 5: Use of Multicast IPSec: The CoAP protocol 313 [I-D.ietf-core-coap] allows IPSec to be used as one option to 314 secure CoAP. If IPSec is used as a way to security CoAP 315 communications, then multicast IPSec [RFC5374] should be used for 316 securing CoAP group communications. 318 SEC-REQ 6: Independence from underlying routing security: CoAP 319 group communication security shall not be tied to the security of 320 underlying routing and distribution protocols such as PIM 321 [RFC4601] and RPL [RFC6550]. Insecure or inappropriate routing 322 (including IP multicast routing) may cause loss of data to CoAP 323 but will not affect the authenticity or secrecy of CoAP group 324 communications. 326 SEC-REQ 7: Interaction with HTTPS: The security scheme for CoAP 327 group communications shall account for the fact that it may need 328 to interact with HTTPS (Hypertext Transfer Protocol Secure) when a 329 transaction involves a node in the general Internet (non- 330 constrained network) communicating via a HTTP-CoAP proxy. 332 5. Group Communication Solutions 334 This section includes the text that describes the solutions of IP 335 multicast, overlay multicast, and application layer group 336 communication which were removed from [I-D.rahman-core-groupcomm] 337 version 07 when the text was transferred to 338 [I-D.ietf-core-groupcomm]. 340 5.1. IP Multicast Transmission Methods 342 5.1.1. Serial unicast 344 Even in systems that generally support IP Multicast, there may be 345 certain data links (or transports) that don't support IP multicast. 346 For those links a serial unicast alternative must be provided. This 347 implies that it should be possible to enumerate the members of a 348 group, in order to determine the correct unicast destinations. 350 5.1.2. Unreliable IP Multicast 352 The CoRE WG charter specified support for non-reliable IP multicast. 353 In the current CoAP protocol design [I-D.ietf-core-coap], unreliable 354 multicast is realized by the source sending Non-Confirmable messages 355 to a multicast IP address. IP Multicast (using UDP) in itself is 356 unreliable, unless specific reliability features are added to it. 358 5.1.3. Reliable IP Multicast 360 [TBD: This is a difficult problem. Need to investigate the benefits 361 of repeating MGET and MPUT requests (saturation) to get "Pretty Good 362 Reliability". Use the same MID or a new MID for repeated requests? 363 Carsten suggests the use of bloom filters to suppress duplicate 364 responses. 366 One could argue that non-idempotent operations (POST) cannot be 367 supported without a *truly* reliable multicast protocol. However, is 368 this the case? If a multicast POST request is sent repeatedly with 369 the same Message ID (MID), then CoAP nodes that already received it 370 once will ignore duplicates. Sending with Message ID is supported in 371 CoAP for Non-Confirmable messages (thus including multicast messages) 372 as per [I-D.ietf-core-coap] section 4.2. ] 374 Reliable multicast supports guaranteed delivery of messages to a 375 group of nodes. The following specifies the requirements as was 376 proposed originally in version 01 of [I-D.vanderstok-core-bc]: 378 o Validity - If sender sends a message, m, to a group, g, of 379 destinations, a path exists between sender and destinations, and 380 the sender and destinations are correct, all destinations in g 381 eventually receive m. 383 o Integrity - destination receives m at most once from sender and 384 only if sender sent m to a group including destination. 386 o Agreement - If a correct destination of g receives m, then all 387 correct destinations of g receive m. 389 o Timeliness - For real-time control of devices, there is a known 390 constant D such that if m is sent at time t, no correct 391 destination receives m after t+D. 393 There are various approaches to achieve reliability, such as 395 o Destination node sends response: a destination sends a CoAP 396 Response upon multicast Request reception (it SHOULD be a Non- 397 Confirmable response). The source node may retry a request to 398 destination nodes that did not respond in time with a CoAP 399 response. 401 o Route redundancy 403 o Source node transmits multiple times (destinations do not respond) 405 5.2. Overlay Multicast 407 An alternative group communication solution (to IP Multicast) is an 408 "overlay multicast" approach. We define an overlay multicast as one 409 that utilizes an infrastructure based on proxies (rather than an IP 410 router based IP multicast backbone) to deliver IP multicast packets 411 to end devices. MLD ([RFC3810]) has been selected as the basis for 412 multicast support by the ROLL working group for the RPL routing 413 protocol. Therefore, it is proposed that "IGMP/MLD Proxying" 414 [RFC4605] be used as a basis for an overlay multicast solution for 415 CoAP. 417 Specifically, a CoAP proxy [I-D.ietf-core-coap] may also contain an 418 MLD Proxy function. All CoAP devices that want to join a given IP 419 multicast group would then send an MLD Join to the CoAP (MLD) proxy. 420 Thereafter, the CoAP (MLD) proxy would be responsible for delivering 421 any IP multicast message to the subscribed CoAP devices. This will 422 require modifications to the existing [RFC4605] functionality. 424 Note that the CoAP (MLD) proxy may or may not be connected to an 425 external IP multicast enabled backbone. The key function for the 426 CoAP (MLD) proxy is to distribute CoAP generated multicast packets 427 even in the absence of router support for multicast. 429 5.3. CoAP Application Layer Group Management 431 Another alternative solution (to IP Multicast and Overlay Multicast) 432 is to define CoAP application level group management primitives. 433 Thus, CoAP can support group management features without need for any 434 underlying IP multicast support. 436 Interestingly, such group management primitives could also be offered 437 even if there is underlying IP multicast support. This is useful 438 because IP multicast inherently does not support the concept of a 439 group with managed members, while a managed group may be required for 440 some applications. 442 The following group management primitives are in general useful: 444 o discover groups; 446 o query group properties (e.g. related resource descriptions); 448 o create a group; 450 o remove a group; 452 o add a group member; 454 o remove a group member; 456 o enumerate group members; 458 o security and access control primitives. 460 In this proposal a (at least one) CoAP Proxy node is responsible for 461 group membership management. A constrained node can specify which 462 group it intends to join (or leave) using a CoAP request to the 463 appropriate CoAP Proxy. To Join, the group name will be included in 464 optional request header fields (explained below). These header 465 fields will be included in a PUT request to the Proxy. The Proxy-URI 466 is set to the Group Management URI of the Proxy (found previously 467 through the "/.well-known/" resource discovery mechanism). Note that 468 in this solution also CoAP Proxies may exist in a network that are 469 not capable of CoAP group operations. 471 Group names may be defined as arbitrary strings with a predefined 472 maximum length (e.g. 268 characters or the maximum string length in a 473 CoAP Option), or as URIs. 475 [ TBD: how can a client send a request to a group? Does it only need 476 to know the group name (string or URI) or also an IP multicast 477 address? One way is to send a CoAP request to the CoAP Proxy with a 478 group URI directly in the Proxy-URI field. This avoids having to 479 know anything related to IP multicast addresses. ] 481 This solution in principle supports both unreliable and reliable 482 group communication. A client would indicate unreliable 483 communication by sending a CoAP Non-Confirmable request to the CoAP 484 Proxy, or reliable communication by sending a CoAP Confirmable 485 request. 487 It is proposed that CoAP supports two Header Options for group "Join" 488 and "Leave". These Options are Elective so they should be assigned 489 an even number. Assuming the Type for "join" is x (value TBD), the 490 Header Options are illustrated by the table in Figure 1: 492 +------+-----+---------------+--------------+--------+--------------+ 493 | Type | C/E | Name | Data type | Length | Default | 494 |------+-----+---------------+--------------+--------+--------------+ 495 | | | | | | | 496 | x | E | Group Join | String | 1-270 | "" | 497 | | | | | B | | 498 | x+2 | E | Group Leave | String | 1-270 | "" | 499 | | | | | B | | 500 +------+-----|---------------+--------------+--------+--------------+ 502 Figure 1: CoAP Header Options for Group Management 504 Figure 2 illustrates how a node can join or leave a group using the 505 Header Options in a CoAP message: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |Ver| T | OC | Code | Message ID | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | delta |length | Join Group A (ID or URI) 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | 0 |length | Join Group B (ID or URI) 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | 2 |length | Leave Group C (ID or URI) 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 2: CoAP Message for Group Management 521 Header Fields for the above example: 523 Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by 524 implementation as defined by the CoAP specification. 526 T: 2-bit unsigned integer for CoAP Transaction Type. Either '0' 527 Confirmation or '1' Non-Confirmable can be used for group "join" or 528 "leave" request. 530 OC: 4-bit unsigned integer for Option Count. For this example, the 531 value should be "3" since there are three option fields. 533 Code: 8-bit unsigned integer to indicate the Method in a Request or a 534 Response Code in a Response message. Any Code can be used so the 535 group management can be piggy-backed in either Request or Response 536 message. 538 Message ID: 16-bit value assigned by the source to uniquely identify 539 a pair of Request and Response. 541 CoAP defines a delta encoding for header options. The first delta is 542 the "Type" for group join in this specific example. If the type for 543 group join is x as illustrated in Figure 2, delta will be x. In the 544 second header option, it is also a group join so the delta is 0. The 545 third header option is a group leave so the delta is 2. 547 An alternative solution to using Header Options (explained above) is 548 to use designated parameters in the query part of the URI in the 549 Proxy-URI field of a POST (TBD: or PUT?) request to a Proxy's group 550 management service resource advertized by DNS-SD. For example, to 551 join group1 and leave group2: 553 coap://proxy1.bld2.example.com/groupmgt?j=group1&l=group2 555 6. DNS-SD Based Group Resource Manipulation 557 Ideally, all nodes in a given group (defined by its multicast IP 558 address) must receive the same request with high probability. This 559 will not be the case if there is diversity in the authority port 560 (i.e. a diversity of dynamic port addresses across the group) or if 561 the targeted resource is located at different paths on different 562 nodes. Extending the definition of group membership to include port 563 and path discovery is not desirable. 565 Therefore, some measures must be present to ensure uniformity in port 566 number and resource name/location within a group. 568 A first solution in this respect is to couple groups to service 569 descriptions in DNS (using DNS-SD as in [I-D.vanderstok-core-bc]). A 570 service description for a multicast group may have a TXT record in 571 DNS defining a schema X (e.g. "schema=DALI"), which defines by 572 service standard X (e.g. "DALI") which resources a node supporting X 573 MUST have. Therefore a multicast source can safely refer to all 574 resources with corresponding operations as prescribed by standard X. 575 For port numbers (which can be found using DNS-SD also) the same 576 holds. Alternatively, only the default CoAP port may be used in all 577 CoAP multicast requests. 579 7. Group Discovery and Member Discovery 581 CoAP defines a resource discovery capability, but does not yet 582 specify how to discover groups (e.g. find a group to join or send a 583 multicast message to) or to discover members of a group (e.g. to 584 address selected group members by unicast). These topics are 585 elaborated in more detail in [I-D.vanderstok-core-dna] including 586 examples for using DNS-SD and CoRE Resource Directory. 588 7.1. DNS-SD 590 DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a 591 conventional way to configure DNS PTR, SRV, and TXT records to enable 592 enumeration of services, such as services offered by CoAP nodes, or 593 enumeration of all CoAP nodes, within specified subdomains. A 594 service is specified by a name of the form 595 .., where the service type for CoAP 596 nodes is _coap._udp and the domain is a DNS domain name that 597 identifies a group as in the examples above. For each CoAP end-point 598 in a group, a PTR record with the name _coap._udp and/or a PTR record 599 with the name _coap._udp. is defined and it points to an SRV 600 record having the .. name. 602 All CoAP nodes in a given subdomain may be enumerated by sending a 603 query for PTR records named _coap._udp to the authoritative DNS 604 server for that zone. A list of SRV records is returned. Each SRV 605 record contains the port and host name (AAAA record) of a CoAP node. 606 The IP address of the node is obtained by resolving the host name. 607 DNS-SD also specifies an optional TXT record, having the same name as 608 the SRV record, which can contain "key=value" attributes. This can 609 be used to store information about the device, e.g. schema=DALI, 610 type=switch, group=lighting.bldg6, etc. 612 Another feature of DNS-SD is the ability to specify service sub-types 613 using PTR records. For example, one could represent all the CoAP 614 groups in a subdomain by PTR records with the name 615 _group._sub._coap._udp or alternatively 616 _group._sub._coap._udp.. 618 7.2. CoRE Resource Directory 620 CoRE Resource Directory [I-D.shelby-core-resource-directory] defines 621 the concept of a Resource Directory (RD) server where CoAP servers 622 can register their resources offered and CoAP clients can discover 623 these resources by querying the RD server. RD syntax can be mapped 624 to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], 625 such that the above approach can be reused for group discovery and 626 group member discovery. 628 Specifically, the Domain (d) parameter can be set to the group URI by 629 an end-point registering to the RD. If an end-point wants to join 630 multiple groups, it has to repeat the registration process for each 631 group it wants to join. 633 8. Deployment Guidelines 635 8.1. Overview 637 We recommend to use IP multicast as the base solution for CoAP Group 638 Communication, provided that the use case and network characteristics 639 allow this. It has the advantage that it re-uses the IP multicast 640 suite of protocols and can operate even if group members are 641 distributed over both constrained and un-constrained network 642 segments. Still, this approach may require specifying or 643 implementing additional IP Multicast functionality in an LLN, in a 644 backbone network, or in both - this will be evaluated in more detail 645 in this section. 647 8.2. Implementation in Target Network Topologies 649 This section looks in more detail how an IP Multicast based solution 650 can be deployed onto the various network topologies that we consider 651 important for group communication use cases. Note that the chosen 652 solution of IP Multicast for CoAP group communication works mostly 653 independently from the underlying network topology and its specific 654 IP multicast implementation. 656 Starting from the simplest case of a single LLN topology, we move to 657 more complex topologies involving a backbone network or multiple 658 LLNs. With "backbone" we refer here typically to a corporate LAN or 659 VLAN, which constitutes a single broadcast domain by design. It 660 could also be an in-home network. A multi-link backbone is also 661 possible, if there is proper IP multicast routing or forwarding 662 configured between these links. (The term 6LoWPAN Border Router or 663 "6LBR" is used here for a border router, though our evaluation is not 664 necessarily restricted to 6LoWPAN networks.) 666 8.2.1. Single LLN Topology 668 The simplest topology is a single LLN, where all the IP multicast 669 source(s) and destinations are constrained nodes within this same 670 LLN. Possible implementations of IP multicast routing and group 671 administration for this topology are listed below. 673 8.2.1.1. Mesh-Under Multicast Routing 675 The LLN may be set up in either a mesh-under or a route-over 676 configuration. In the former case, the mesh routing protocol should 677 take care of routing IP multicast messages throughout the LLN. 679 Because conceptually all nodes in the LLN are attached to a single 680 link, there is in principle no need for nodes to announce their 681 interest in multicast IP addresses via MLD (see Appendix A). A 682 multicast message to a specific IP destination, which is delivered to 683 all 6LoWPAN nodes by the mesh routing algorithm, is accepted by the 684 IP network layer of that node only if it is listening on that 685 specific multicast IP address and port. 687 8.2.1.2. RPL Multicast Routing 689 The RPL routing protocol for LLNs provides support for routing to 690 multicast IP destinations (Section 12 of [RFC6550]). Like regular 691 unicast destinations, multicast destinations are advertised by nodes 692 using RPL DAO messages. This functionality requires "Storing mode 693 with multicast support" (Mode Of Operation, MOP is 3) in the RPL 694 network. 696 Once all RPL routing tables in the network are populated, any RPL 697 node can send packets to an IP multicast destination. The RPL 698 protocol performs distribution of multicast packet both upward 699 towards the DODAG root and downwards into the DODAG. 701 The text in Section 12 of the RPL specification clearly implies that 702 IP multicast packets are distributed using link-layer unicast 703 transmissions, looking at the use of the word "copied" in this 704 section. Specifically in 6LoWPAN networks, this behavior conflicts 705 with the requirement that IP multicast packets MUST be carried as 706 link-layer 802.15.4 broadcast frames [RFC4944]. 708 Assuming that link-layer unicast is indeed meant, this approach seems 709 efficient only in a balanced, sparse tree network topology, or in 710 situations where the fraction of nodes listening to a specific 711 multicast IP address is low, or in duty cycled LLNs where link-layer 712 broadcast is a very expensive operation. 714 8.2.1.3. RPL Routers with Non-RPL Hosts 716 Now we consider the case that hosts exist in a RPL network that are 717 not RPL-aware themselves, but rely on RPL routers for their IP 718 connectivity beyond link-local scope. Note that the current RPL 719 specification [RFC6550] leaves this case for future specification 720 (see Section 16.4). Non-RPL hosts cannot advertise their IP 721 multicast groups of interest via RPL DAO messages as defined above. 722 Therefore in that case MLD could be used for such advertisements 723 (State Change Report messages), with all or a subset of RPL routers 724 acting in the role of MLD Routers as defined in [RFC3810]. However, 725 as the MLD protocol is not designed specifically for LLNs it may be a 726 burden for the constrained RPL router nodes to run the full MLD 727 protocol. Alternatives are therefore proposed in Section 8.3.1. 729 8.2.1.4. Trickle Multicast Forwarding 731 Trickle Multicast Forwarding [I-D.ietf-roll-trickle-mcast] is an IP 732 multicast routing protocol suitable for LLNs, that uses the Trickle 733 algorithm as a basis. It is a simple protocol in the sense that no 734 topology maintenance is required. It can deal especially well with 735 situations where the node density is a-priori unknown. 737 Nodes from anywhere in the LLN can be the multicast source, and nodes 738 anywhere in the LLN can be multicast destinations. 740 Using Trickle Multicast Forwarding it is not required for IP 741 multicast destinations (listeners) to announce their interest in a 742 specific multicast IP address, e.g. by means of MLD. Instead, all 743 multicast IP packets regardless of IP destination address are stored 744 and forwarded by all routers. Because forwarding is always done by 745 multicast, both hosts and routers will be able to receive all 746 multicast IP packets. Routers that receive multicast packets they 747 are not interested in, will only buffer these for a limited time 748 until retransmission can be stopped as specified by the protocol. 749 Hosts that receive multicast packets they are not interested in, will 750 discard multicast packets that are not of interest. Above properties 751 seem to make Trickle especially efficient for cases where the 752 multicast listener density is high and the number of distinct 753 multicast groups relatively low. 755 8.2.1.5. Other Route-Over Methods 757 Other known IP multicast routing methods may be used, for example 758 flooding or other to be defined methods suitable for LLNs. An 759 important design consideration here is whether multicast listeners 760 need to advertise their interest in specific multicast addresses, or 761 not. If they do, MLD is a possible option but also protocol-specific 762 means (as in RPL) is an option. See Section 8.3.1 for more efficient 763 substitutes for MLD targeted towards a LLN context. 765 8.2.2. Single LLN with Backbone Topology 767 A LLN may be connected via a Border Router (e.g. 6LBR) to a backbone 768 network, on which IP multicast listeners and/or sources may be 769 present. This section analyzes cases in which IP multicast traffic 770 needs to flow from/to the backbone, to/from the LLN. 772 8.2.2.1. Mesh-Under Multicast Routing 774 Because in a mesh routing network conceptually all nodes in the LLN 775 are attached to a single link, a multicast IP packet originating in 776 the LLN is typically delivered by the mesh routing algorithm to the 777 6LBR as well, although there is no guaranteed delivery. The 6LBR may 778 be configured to accept all IP multicast traffic from the LLN and 779 then may forward such packets onto its backbone link. Alternatively, 780 the 6LBR may act in an MLD Router or MLD Snooper role on its backbone 781 link and decide whether to forward a multicast packet or not based on 782 information learned from previous MLD Reports received on its 783 backbone link. 785 Conversely, multicast packets originating on the backbone network 786 will reach the 6LBR if either the backbone is a single link (LAN/ 787 VLAN) or IPv6 multicast routing is enabled on the backbone. Then, 788 the 6LBR could simply forward all IP multicast traffic from the 789 backbone onto the LLN. However, in practice this situation may lead 790 to overload of the LLN caused by unnecessary multicast traffic. 791 Therefore the 6LBR SHOULD only forward traffic that one or more nodes 792 in the LLN have expressed interest in, effectively filtering inbound 793 LLN multicast traffic. 795 To realize this "filter", nodes on the LLN may use MLD to announce 796 their interest in specific multicast IP addresses to the 6LBR. One 797 option is for the 6LBR to act in an MLD Router role on its LLN 798 interface. However, this may be too much of a "burden" for 799 constrained nodes. Light-weight alternatives for MLD are discussed 800 in Section 8.3.1. 802 8.2.2.2. RPL Multicast Routing 804 For RPL routing within the 6LoWPAN, we first consider the case of an 805 IP multicast source on the backbone network with one or more IP 806 multicast listeners on the RPL LLN. Typically, the 6LBR would be the 807 root of a DODAG so that the 6LBR can easily forward the IP multicast 808 packet received on its backbone interface to the right RPL nodes in 809 the LLN down along this DODAG (based on previously DAO-advertized 810 destinations). 812 Second, a multicast source may be in the RPL LLN and listeners may be 813 both on the LLN and on the backbone. For this case RPL defines that 814 the multicast packet will propagate both up and down the DODAG, 815 eventually reaching the DODAG root (typically a 6LBR) from which the 816 packet can be routed onto the backbone in a manner specified in the 817 previous section. 819 8.2.2.3. RPL Routers with Non-RPL Hosts 821 For the case that a RPL LLN contains non-RPL hosts, the solutions 822 from the previous section can be used if in addition RPL routers 823 implement MLD or "MLD like" functionality similar to as described in 824 Section 8.2.1.3. 826 8.2.2.4. Trickle Multicast Forwarding 828 First, we consider the case of an IP multicast source node on the LLN 829 (where all 6LRs support Trickle Multicast Forwarding) and IP 830 multicast listeners that may be on the LLN and on the backbone. As 831 Trickle will eventually deliver multicast packets also to a 6LBR, 832 which acts as a Trickle Multicast router as well, the 6LBR can then 833 forward onto the backbone in the ways described earlier in 834 Section 8.2.2.1. 836 Second, for the case of an IP multicast source on the backbone and 837 multicast listeners on both backbone and/or LLN, the 6LBR needs to 838 forward multicast traffic from the backbone onto the LLN. Here, the 839 aforementioned problem (Section 8.2.2.1) of potentially overloading 840 the LLN with unwanted backbone IP multicast traffic appears again. 842 A possible solution to this is (again) to let multicast listeners 843 advertise their interest using MLD as described in Section 8.2.2.1 or 844 to use an MLD alternative suitable for LLNs as described in 845 Section 8.3.1. However, following this approach requires possibly an 846 extension to Trickle Multicast Forwarding: the protocol should ensure 847 that MLD-advertised information is somehow communicated to the 6LBR, 848 possibly over multiple hops. MLD itself supports link-local 849 communication only. 851 8.2.2.5. Other Route-Over Methods 853 For other multicast routing methods used on the LLN, there are 854 similar considerations to the ones in sections above: the strong need 855 to filter IP multicast traffic coming into the LLN, the need for 856 reporting multicast listener interest (e.g. with MLD or a to-be- 857 defined MLD alternative) by constrained (6LoWPAN) nodes, and the need 858 for LLN-internal routing as identified in the previous section such 859 that the MLD communicated information can reach the 6LBR to be used 860 there in multicast traffic filtering decisions. 862 8.2.3. Multiple LLNs with Backbone Topology 864 Now the case of a single backbone network with two or more LLNs 865 attached to it via 6LBRs is considered. For this case all the 866 considerations and solutions of the previous section can be applied. 868 For the specific case that a source on a backbone network has to send 869 to a very large number of destination located on many LLNs, the use 870 of IGMP/MLD Proxying [RFC4605] with a leaf IGMP/MLD Proxy located in 871 each 6LBR may be useful. This method only is defined for a tree 872 topology backbone network with the IP multicast source at the root of 873 the tree. 875 8.2.4. LLN(s) with Multiple 6LBRs 877 [ TBD: an LLN with multiple 6LBRs may require some additional 878 consideration. Any need to synchronize mutually on multicast 879 listener information? ] 881 8.2.5. Conclusions 883 For all network topologies that were evaluated, CoAP group 884 communication can be in principle supported with IP Multicast, making 885 use of existing protocols. For the case of Trickle Multicast 886 Forwarding, it appears that an addition to the protocol is required 887 such that information about multicast listeners can be distributed 888 towards the 6LBR. Opportunities were identified for an "MLD-like" or 889 "MLD-lightweight" protocol specifically suitable for LLNs, which 890 should inter-work with regular MLD on the backbone network. Such MLD 891 variants are further analyzed in Section 8.3.1. 893 8.3. Implementation Considerations 895 In this section various implementation aspects are considered such as 896 required protocol implementations, additional functionality of the 897 6LBR and backbone network equipment. 899 8.3.1. MLD Implementation on LLNs and MLD alternatives 901 In previous sections, it was mentioned that the MLDv2 protocol 902 [RFC3810] may be too costly for use in a LLN. MLD relies on periodic 903 link-local multicast operations to maintain state. Also it is 904 optimized to fairly dynamic situations where multicast listeners may 905 come and go over time. Such dynamic situations are less frequently 906 found in typical LLN use cases such as building control, where 907 multicast group membership can remain constant over longer periods of 908 time (e.g. months) after commissioning. 910 Hence, a viable strategy is to implement a subset of MLD 911 functionality in 6LoWPAN nodes which is just enough for the required 912 functionality. A first option is that 6LoWPAN Routers, like MLD 913 Snoopers, passively listen to MLD State Change Report messages and 914 handle the learned ("snooped") IP multicast destinations in the way 915 defined by the multicast routing protocol they are running (e.g. for 916 RPL, Routers advertise these destinations using DAO messages). 918 A second option is to use MLD as-is but adapt the recommended 919 parameter values such that operation on a LLN becomes more efficient. 920 [RFC6636] could be a guideline in this case. 922 A third option is to standardize a new protocol, taking a subset of 923 MLD functionality into a "MLD for 6LoWPAN" protocol to support 924 constrained nodes optimally. 926 A fourth option is now presented, which seems attractive in that it 927 minimizes standardization, implementation and network communication 928 overhead all at the same time. This option is to specify a new 929 Multicast Listener Option (MLO) as an addition to the 6LoWPAN-ND 930 [RFC6775] protocol communication that is anyway ongoing between a 931 6LoWPAN host and router(s). This MLO is preferably designed to be 932 maximally similar to the Address Registration Option (ARO), which 933 minimizes the need for additional program code on constrained nodes. 934 With an MLO, instead of registering a hosts's unicast IP address as 935 with ARO, a host "registers" its interest in a multicast IPv6 936 address. Unlike the ARO, multiple MLO can be used in the same ND 937 packet. A registration period is also defined in the MLO just like 938 in the ARO. MLO allows a host to persistently register as a listener 939 to IP multicast traffic and to avoid the overhead of periodic 940 multicast communication which is required for the regular MLD 941 protocol. 943 [ TBD: consider what aspects are needed/not needed for CoAP/LLN 944 applications. Will MLDv1 suffice? What to do with options like 945 'source specific' and include/exclude. Source-specific can also be 946 dealt with at the destination host by filtering? Do we need limits 947 on number of records per packet? Do we need a higher MLD reliability 948 setting - see the parameters in the MLD RFC ] 950 8.3.2. 6LBR Implementation 952 To support mixed backbone/LLN scenarios in CoAP group communication, 953 it is RECOMMENDED that a 6LowPAN Border Router (6LBR) will act in an 954 MLD Router role on the backbone link. If this is not possible then 955 the 6LBR SHOULD be configured to act as an MLD Multicast Address 956 Listener and/or MLD Snooper on the backbone link. 958 8.3.3. Backbone IP Multicast Infrastructure 960 For corporate/professional applications, most routing and switching 961 equipment that is currently on the market is IPv6 capable. For that 962 reason backbone infrastructure operating IPv4 only is considered out 963 of scope in this document, at least for the backbone network 964 segment(s) where IP multicast destinations are present. What is 965 still in scope is for example an IPv4-only HTTP client that wants to 966 send a group communication message via a HTTP-CoAP proxy as 967 considered in [I-D.castellani-core-advanced-http-mapping]. 969 The availability of, and requirements for, IP multicast support may 970 depend on the specific installation use case. For example, the 971 following cases may be relevant for new IP based building control 972 installations: 974 1. System deployed on existing IP (Ethernet/WiFi/...) 975 infrastructure, shared with existing IP devices (PCs) 977 2. Newly designed and deployed IP (Ethernet/WiFi/...) 978 infrastructure, to be shared with other IP devices (PCs) 980 3. Newly designed and deployed IP (Ethernet/WiFi/...) 981 infrastructure, exclusively used for building control. 983 Besides physical separation the building control backbone can be 984 separated from regular (PC) infrastructure by using a different VLAN. 985 A typical corporate installation will have many LAN switches and/or 986 routing switches, which pass through IP multicast traffic but on the 987 other hand do not support acting in the Router role of MLD/IGMP. 988 Perhaps for case 2) and 3) above it is acceptable to add a MLD/IGMP 989 capable router somewhere in the network, while for case 1) this may 990 not be the case. 992 [TBD: consider the influence of WiFi based backbone networks. What 993 if 6LBRs are at the same time also WiFi routers? What if 6LBRs have 994 an Ethernet connection to legacy WiFI routers? Check if equivalent 995 with Ethernet backbone.] 997 9. Miscellaneous Topics 999 This section collects miscellaneous text, topics or proposals related 1000 to CoAP group communication which do not directly fit into any of the 1001 preceding sections. 1003 9.1. CoAP Multicast and HTTP Unicast Interworking 1005 CoAP supports operation over UDP multicast, while HTTP does not. For 1006 use cases where it is required that CoAP group communication is 1007 initiated from an HTTP end-point, it would be advantageous if the 1008 HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group 1009 communication based on IP multicast. One possible way of operation 1010 of such HTTP-CoAP Proxy is illustrated in Figure 3. Note that this 1011 topic is covered in more detail in 1012 [I-D.castellani-core-advanced-http-mapping]. 1014 CoAP Mcast CoAP Mcast HTTP-CoAP HTTP 1015 Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 1016 | | | | | | 1017 |MLD REQUEST | | | | 1018 |(Join Group X) | | | | 1019 |--LL-->| | | | | 1020 | | |MLD REQUEST | | 1021 | | |(Join Group X) | | 1022 | | |--LL-->| | | 1023 | | | | | HTTP REQUEST | 1024 | | | | | (URI to | 1025 | | | | | unicast addr) | 1026 | | | | |< -----------------| 1027 | | | | | | 1028 | | | Resolve HTTP Request-Line URI | 1029 | | | to Group X multicast address | 1030 | | | | | | 1031 | CoAP REQUEST (to multicast addr)| | 1032 |< ------<---------<-------<------| | 1033 | | | | | | 1034 | | | | 1035 | (optional) CoAP RESPONSE(s) | | 1036 | |-------------->| | 1037 |-----------------|-------------->| Aggregated | 1038 | | | HTTP RESPONSE | 1039 | | |------------------>| 1040 | | | | 1042 Figure 3: CoAP Multicast and HTTP Unicast Interworking 1044 Note that Figure 3 illustrates the case of IP multicast as the 1045 underlying group communications mechanism. MLD denotes the Multicast 1046 Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a 1047 Link-Local multicast. 1049 A key point in Figure 3 is that the incoming HTTP Request (from node 1050 3) will carry a Host request-header field that resolves in the 1051 general Internet to the proxy node. At the proxy node, this hostname 1052 and/or the Request-Line URI will then possibly be mapped (as detailed 1053 in [I-D.castellani-core-advanced-http-mapping]) and again resolved 1054 (with the CoAP scheme) to an IP multicast address. This may be 1055 accomplished, for example, by using DNS or DNS-SD (Section 7). The 1056 proxy node will then IP multicast the CoAP Request (corresponding to 1057 the received HTTP Request) via multicast routers to the appropriate 1058 nodes (i.e. nodes 1 and 2). 1060 In terms of the HTTP Response, Figure 3 illustrates that it will be 1061 generated by the proxy node based on aggregated responses of the CoAP 1062 nodes and sent back to the client in the general Internet that sent 1063 the HTTP Request (i.e. node 1). In 1064 [I-D.castellani-core-advanced-http-mapping] the HTTP Response that 1065 the Proxy may use to aggregate multiple CoAP responses is described 1066 in more detail. So in terms of overall operation, the CoAP proxy can 1067 be considered to be a "non-transparent" proxy according to [RFC2616]. 1068 Specifically, [RFC2616] states that a "non-transparent proxy is a 1069 proxy that modifies the request or response in order to provide some 1070 added service to the user agent, such as group annotation services, 1071 media type transformation, protocol reduction or anonymity 1072 filtering." 1074 An alternative to the above is using a Forward Proxy. In this case, 1075 the CoAP request URI is carried in the HTTP Request-Line (as defined 1076 in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the 1077 IP address of the Proxy. 1079 10. Acknowledgements 1081 Thanks to all CoRE WG members who participated in the IETF 82 1082 discussions, which was the trigger to initiate this document. 1084 11. IANA Considerations 1085 This memo includes no request to IANA. 1087 12. Security Considerations 1089 Security aspects of group communication for CoAP are discussed in 1090 [I-D.ietf-core-groupcomm]. The current document contains no new 1091 proposals yet, for which security considerations have to be analyzed 1092 here. 1094 13. References 1096 13.1. Normative References 1098 [I-D.ietf-core-coap] 1099 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1100 Application Protocol (CoAP)", draft-ietf-core-coap-18 1101 (work in progress), June 2013. 1103 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1104 Requirement Levels", BCP 14, RFC 2119, March 1997. 1106 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1107 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1108 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1110 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 1111 Architecture", RFC 3740, March 2004. 1113 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1114 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1116 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1117 "Multicast Security (MSEC) Group Key Management 1118 Architecture", RFC 4046, April 2005. 1120 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1121 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1122 Protocol Specification (Revised)", RFC 4601, August 2006. 1124 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1125 "Internet Group Management Protocol (IGMP) / Multicast 1126 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 1127 /MLD Proxying")", RFC 4605, August 2006. 1129 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1130 "Transmission of IPv6 Packets over IEEE 802.15.4 1131 Networks", RFC 4944, September 2007. 1133 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 1134 Extensions to the Security Architecture for the Internet 1135 Protocol", RFC 5374, November 2008. 1137 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1138 "Building Automation Routing Requirements in Low-Power and 1139 Lossy Networks", RFC 5867, June 2010. 1141 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1142 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1143 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1144 Lossy Networks", RFC 6550, March 2012. 1146 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1147 the Internet Group Management Protocol (IGMP) and 1148 Multicast Listener Discovery (MLD) for Routers in Mobile 1149 and Wireless Networks", RFC 6636, May 2012. 1151 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1152 Format", RFC 6690, August 2012. 1154 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1155 "Neighbor Discovery Optimization for IPv6 over Low-Power 1156 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1157 November 2012. 1159 13.2. Informative References 1161 [Banerjee01] 1162 Banerjee, B. and B. Bhattacharjee, "A Comparative Study of 1163 Application Layer Multicast Protocols", 2001, . 1167 [I-D.castellani-core-advanced-http-mapping] 1168 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1169 E. Dijk, "Best Practices for HTTP-CoAP Mapping 1170 Implementation", draft-castellani-core-advanced-http- 1171 mapping-02 (work in progress), July 2013. 1173 [I-D.cheshire-dnsext-dns-sd] 1174 Cheshire, S. and M. Krochmal, "DNS-Based Service 1175 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 1176 progress), December 2011. 1178 [I-D.eggert-core-congestion-control] 1179 Eggert, L., "Congestion Control for the Constrained 1180 Application Protocol (CoAP)", draft-eggert-core- 1181 congestion-control-01 (work in progress), January 2011. 1183 [I-D.ietf-6lowpan-routing-requirements] 1184 Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1185 Statement and Requirements for 6LoWPAN Routing", draft- 1186 ietf-6lowpan-routing-requirements-10 (work in progress), 1187 November 2011. 1189 [I-D.ietf-core-block] 1190 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1191 draft-ietf-core-block-14 (work in progress), October 2013. 1193 [I-D.ietf-core-groupcomm] 1194 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1195 draft-ietf-core-groupcomm-16 (work in progress), October 1196 2013. 1198 [I-D.ietf-core-observe] 1199 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1200 core-observe-11 (work in progress), October 2013. 1202 [I-D.ietf-roll-trickle-mcast] 1203 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1204 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1205 mcast-05 (work in progress), August 2013. 1207 [I-D.lynn-core-discovery-mapping] 1208 Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based 1209 Service Discovery Mapping", draft-lynn-core-discovery- 1210 mapping-02 (work in progress), October 2012. 1212 [I-D.rahman-core-groupcomm] 1213 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1214 draft-rahman-core-groupcomm-07 (work in progress), October 1215 2011. 1217 [I-D.shelby-core-coap-req] 1218 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 1219 Kelsey, "CoAP Requirements and Features", draft-shelby- 1220 core-coap-req-02 (work in progress), October 2010. 1222 [I-D.shelby-core-resource-directory] 1223 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1224 Directory", draft-shelby-core-resource-directory-05 (work 1225 in progress), February 2013. 1227 [I-D.vanderstok-core-bc] 1228 Stok, P. and K. Lynn, "CoAP Utilization for Building 1229 Control", draft-vanderstok-core-bc-05 (work in progress), 1230 October 2011. 1232 [I-D.vanderstok-core-dna] 1233 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1234 Naming, and Addressing", draft-vanderstok-core-dna-02 1235 (work in progress), July 2012. 1237 [Lao05] Lao, L., Cui, J., Gerla, M., and D. Maggiorini, "A 1238 Comparative Study of Multicast Protocols: Top, Bottom, or 1239 In the Middle?", 2005, . 1242 Appendix A. Multicast Listener Discovery (MLD) 1244 In order to extend the scope of IP multicast beyond link-local scope, 1245 an IP multicast routing protocol has to be active in routers on an 1246 LLN. To achieve efficient multicast routing (i.e. avoid always 1247 flooding multicast IP packets), routers have to learn which hosts 1248 need to receive packets addressed to specific IP multicast 1249 destinations. 1251 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1252 IPv4 pendant IGMP) is today the method of choice used by an (IP 1253 multicast enabled) router to discover the presence of multicast 1254 listeners on directly attached links, and to discover which multicast 1255 addresses are of interest to those listening nodes. MLD was 1256 specifically designed to cope with fairly dynamic situations in which 1257 multicast listeners may join and leave at any time. 1259 IGMP/MLD Snooping is a technique implemented in some corporate LAN 1260 routing/switching devices. An MLD snooping switch listens to MLD 1261 State Change Report messages from MLD listeners on attached links. 1262 Based on this, the switch learns on what LAN segments there is 1263 interest for what IP multicast traffic. If the switch receives at 1264 some point an IP multicast packet, it uses the stored information to 1265 decide onto which LAN segment(s) to send the packet. This improves 1266 network efficiency compared to the regular behavior of forwarding 1267 every incoming multicast packet onto all LAN segments. An MLD 1268 snooping switch may also send out MLD Query messages (which is 1269 normally done by a device in MLD Router role) if no MLD Router is 1270 present. 1272 [RFC6636] discusses optimal tuning of the parameters of MLD for 1273 routers for mobile and wireless networks. These guidelines may be 1274 useful when implementing MLD in LLNs. 1276 Appendix B. CoAP-Observe Alternative to Group Communication 1278 The CoAP Observation extension [I-D.ietf-core-observe] can be used as 1279 a simple (but very limited) alternative for group communication. A 1280 group in this case consists of a CoAP server hosting a specific 1281 resource, plus all CoAP clients observing that resource. The server 1282 is the only group member that can send a group message. It does this 1283 by modifying the state of a resource under observation and 1284 subsequently notifying its observers of the change. Serial unicast 1285 is used for sending the notifications. This approach can be a simple 1286 alternative for networks where IP multicast is not available or too 1287 expensive. 1289 The CoAP-Observe approach is unreliable in the sense that, even 1290 though Confirmable CoAP messages may be used, there are no guarantees 1291 that an update will be received. For example, a client may believe 1292 it is observing a resource while in reality the server rebooted and 1293 lost its listener state. 1295 Authors' Addresses 1297 Esko Dijk (editor) 1298 Philips Research 1300 Email: esko.dijk@philips.com 1302 Akbar Rahman (editor) 1303 InterDigital Communications, LLC 1305 Email: Akbar.Rahman@InterDigital.com