CoRE A. Rahman, Ed. Internet-Draft InterDigital Communications, LLC Intended status: Informational March 11, 2011 Expires: September 12, 2011 Group Communication for CoAP draft-rahman-core-groupcomm-04 Abstract This is a working document intended to trigger discussion and develop draft language for the CoAP protocol specification in the area of group communication (including multicast functionality). Engineering tradeoffs become more challenging in constrained environments, therefore group communication is considered within the context of adjacent topics that may impact or be impacted by design choices in the subject area. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 12, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Rahman Expires September 12, 2011 [Page 1] Internet-Draft Group Communication for CoAP March 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Problem Statement and Scope . . . . . . . . . . . . . . . 4 3. Multicast Solutions . . . . . . . . . . . . . . . . . . . . . 4 3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Group Addressing . . . . . . . . . . . . . . . . . . . 5 3.1.2. Group URIs . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3. Group Discovery . . . . . . . . . . . . . . . . . . . 5 3.1.4. Group Resource Manipulation . . . . . . . . . . . . . 6 3.1.5. Multicast Transmission Methods . . . . . . . . . . . . 7 3.1.6. Congestion Control . . . . . . . . . . . . . . . . . . 8 3.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 8 4. CoAP Application Group Management . . . . . . . . . . . . . . 9 5. Alternate Group Transmission Methods . . . . . . . . . . . . . 11 5.1. Serial Unicast . . . . . . . . . . . . . . . . . . . . . . 11 6. CoAP Multicast and HTTP Unicast Interworking . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Rahman Expires September 12, 2011 [Page 2] Internet-Draft Group Communication for CoAP March 2011 1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following are definitions of terminologies used in this draft. Multicast: A solution based on the use of IP multicast addresses as defined in "IANA Guidelines for IPv4 Multicast Address Assignments" [RFC5771] and "IP Version 6 Addressing Architecture" [RFC4291]. Group Communication: One source node sends a CoAP message to more than one destination node. The source and destination nodes can be constrained or non-constrained nodes. This may include serial unicast, multicast, or hybrid unicast-to-multicast solutions. 2. Introduction 2.1. Background The CoRE working group is chartered to design and standardize a Constrained Application Protocol (CoAP) for resource constrained devices and networks [I-D.ietf-core-coap]. The requirements for CoRE are documented in [I-D.shelby-core-coap-req]. In this draft, we focus and expand discussions on requirements pertaining to multicast support, including: REQ 9: CoAP will support a non-reliable IP multicast message to be sent to a group of Devices to manipulate a resource on all the Devices simultaneously. The use of multicast to query and advertise descriptions must be supported, along with the support of unicast responses. Currently, the CoAP protocol [I-D.ietf-core-coap] supports unreliable multicast using UDP. It defines the unreliable multicast operation as follows: "CoAP supports sending messages to multicast destination addresses. Such multicast messages MUST be Non-Confirmable. Mechanisms for avoiding congestion from multicast requests are being considered in [I-D.eggert-core-congestion-control]." Additional requirements were introduced in [I-D.vanderstok-core-bc] driven by quality of experience issues in commercial lighting; the need for large numbers of devices to respond with near simultaneity Rahman Expires September 12, 2011 [Page 3] Internet-Draft Group Communication for CoAP March 2011 to a command (multicast PUT), and for that command to be received reliably (reliable multicast). 2.2. Problem Statement and Scope In this draft, we expand the scope from unreliable multicast in the current CoAP requirement to group communication, using either (reliable or unreliable) multicast or unicast. Machine-to-Machine (M2M) networks may contain groups of nodes that are highly correlated (e.g. by type or location). For example, all smart meters in a region may belong to one group, and all light switches in a building control system belong to another. Group communication can increase the efficiency of communication and reduce bandwidth requirements for a given application. In the following sections, we address the issues related to group communication in detail, with proposed solutions and analysis of impacts to the CoAP protocol and implementations. 3. Multicast Solutions The classic model of a multicast application is that of a single source distributing content to many recipients. Multicast solutions have evolved from "bottom" to "top", i.e., from the network layer (IP multicast) to application layer multicast. A study published in 2005 identified new solutions in the "middle" (referred to as overlay multicast) that utilize an infrastructure based on proxies [STUDY1]. Each of these classes of multicast solutions may be compared using metrics such as link stress and level of host complexity [STUDY2]. The approach adopted here is to begin with IP multicast and present a complete picture to introduce some key concepts, then expand to cover more general scenarios such as group management and CoAP-to-HTTP proxies. 3.1. IP Multicast IP Multicast protocols have been evolving for decades, resulting in proposed standards such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various technical and marketing reasons, IP Multicast is not widely deployed on the Internet, leading to alternative solutions for applications like interactive gaming and publish/subscribe. However, the packet economy and minimal host complexity of IP multicast make it worth investigating for intra- domain group communication in constrained environments. Rahman Expires September 12, 2011 [Page 4] Internet-Draft Group Communication for CoAP March 2011 3.1.1. Group Addressing The header compression proposal of 6LoWPAN [I-D.ietf-6lowpan-hc] includes a format to support Unicast-Prefix-based IPv6 Multicast Addresses such as [RFC3956], which is itself a scheme to simplify the deployment of PIM-SM [RFC4601]. Since the use of header compression for CoAP is highly desirable, it should be investigated if addressing mode can be used for IP multicast. 3.1.2. Group URIs An approach to map group authorities onto multicast addresses using DNS was proposed in [I-D.vanderstok-core-bc]. Examples of group URI naming (and scoping) for a building control application are shown below. Group URIs MUST follow the approach of the URI structure defined in [RFC3986]. //all.bldg6... "all nodes in building 6" //all.west.bldg6... "all nodes in west wing, building 6" //all.floor1.west.bldg6... "all nodes in floor 1, west wing, etc." //all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, etc." The authority portion of the URI is used to identify a node (or group) and the resulting DNS name is bound to a unicast or (or multicast) address. Each example group URI shown above might be mapped to a unique multicast IP addresses as defined in [RFC3956]. 3.1.3. Group Discovery CoAP defines a resource discovery capability but, in the absence of a multicast infrastructure, it is limited to link-local scope; examples may be found in [I-D.ietf-core-link-format]. A service discovery capability is required to extend discovery to other subnets and scale beyond a certain point, as originally proposed in [I-D.vanderstok-core-bc]. DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a conventional way to configure DNS PTR, SRV, and TXT records to enable enumeration of services such as CoAP nodes within subdomains. A service is specified by a name of the form Instance.Type.Domain, where the type for CoAP nodes is _coap._udp and the domain is a DNS domain name that identifies a building zone as in the examples above. For each CoAP end-point in the zone, a PTR record with the name _coap._udp is defined and it points to an SRV record having the Rahman Expires September 12, 2011 [Page 5] Internet-Draft Group Communication for CoAP March 2011 Instance.Type.Domain name. All CoAP nodes in a given subdomain may be enumerated by sending a query for PTR records named _coap._udp to the authoritative server for that zone. A list of SRV records is returned. Each SRV record contains the port and host name (AAAA record) of a CoAP node. The IP address of the node is obtained by resolving the host name. DNS-SD also specifies an optional TXT record, having the same name as the SRV record, which can contain "key=value" attributes. This can be used to store information about the device, e.g. schema=DALI, type=switch, group=lighting.bldg6, etc. Another feature of DNS-SD is the ability to specify service subtypes using PTR records. For example, one could represent all the CoAP groups in a subdomain by PTR records with the name _group._sub._coap._udp. 3.1.4. Group Resource Manipulation Two forms of group resource manipulation must be supported. The first is push (multicast PUT or MPUT for short) as e.g. "turn off all the lights simultaneously". Logically, this is similar to publishing a value to multiple subscribers. The second operation is pull (multicast GET or MGET), which is essential for discovery during comissioning and can be illustrated by the example "return all the resources matching a .well-known URI". MGET should perhaps be limited in scope to link-local multicast for scaling [TBD: and possibly for security reasons, e.g. DoS attacks]. Conceptually, the result of a multicast GET or PUT should be the same as if the client had unicast them serially (that is, a set of {URI, representation} tuples). Practically, there are major benefits to solving this problem: - packet economy on constrained networks - M2M resource discovery (solves the "chicken-and-egg" problem) - apparent simultaneity of events (e.g. lighting applications) For data links (or transports) that don't support IP multicast, a serial unicast alternative must be provided. In either case it should be possible to enumerate the members of a group. For links that do support IP multicast, there are a few implications: - All multicast requests MUST be sent to the well-known CoAP port Rahman Expires September 12, 2011 [Page 6] Internet-Draft Group Communication for CoAP March 2011 - All multicast requests SHOULD operate on /.well-known/core URIs The justification for these constraints is that all nodes in a given group (defined over the IP address space) must receive the same request with high probability. This will not be the case if there is diversity in the authority port (i.e. a diversity of dynamic port addresses across the group) or the targeted resource is located at different paths on different nodes. Extending the definition of group membership to include port and path discovery is not desirable. One question is whether the application (or middleboxes) need to be aware that a request is intended for a group. A separate scheme as proposed by [ID.goland-http-udp] might be useful (e.g. "corem" vs. "core"). To the extent that group membership might be implemented as a list of multicast, serial unicast, or some combination, having a distinct scheme for group operations might be a useful signal for the proxy receiving the request to look up the group membership and replicate serial unicasts as well as multicast packets. 3.1.5. Multicast Transmission Methods 3.1.5.1. Unreliable IP Multicast The CoRE WG charter specified support of non-reliable multicast. In the current CoAP protocol design [I-D.ietf-core-coap], unreliable multicast is realized by the source sending non-confirmable messages. 3.1.5.2. Reliable IP Multicast [This is a difficult problem. Need to investigate the benefits of repeating MGET and MPUT requests (saturation) to get "Pretty Good Reliability". Use the same TID or a new TID for repeated requests? Carsten suggests the use of bloom filters to suppress duplicate responses. Note that non-idempotent operations (POST) cannot be supported without a *truly* reliable multicast protocol.] Reliable multicast supports guaranteed delivery of messages to a group of nodes. The following specifies the requirements as was proposed originally in [I-D.vanderstok-core-bc]: Validity - If sender sends a message, m, to a group, g, of destinations, a path exists between sender and destinations, and the sender and destinations are correct, all destinations in g eventually receive m. Integrity - destination receives m at most once from sender and only Rahman Expires September 12, 2011 [Page 7] Internet-Draft Group Communication for CoAP March 2011 if sender sent m to a group including destination. Agreement - If a correct destination of g receives m, then all correct destinations of g receive m. Timeliness - For real-time control of devices, there is a known constant D such that if m is sent at time t, no correct destination receives m after t+D. There are various approaches to achieve reliability, such as * Destination node sends acknowledgement: in CoAP, multicast messages are confirmable when reliability is required. * Route redundancy * Source node transmits multiple times 3.1.6. Congestion Control [In the case of MGET or Confirmable MPUT, servers should enforce a random delay within TIMEOUT before sending responses. More investigation required.] CoAP requests may be multicast, resulting multitude of replies from different nodes, potentially causing congestion. [I-D.eggert-core-congestion-control] suggests to conservatively control sending multicast request. Various means can be implemented to prevent congestion. Currently in the CoAP protocol, the MAX_RETRANSMIT value is set to 5 by default. It is suggested that two values are used separately for retransmissions, one for unicast transmission between a single source and sink. The current value of 5 is used for such transmission. Another constant is defined for multicast or group communication. The retransmission value for group transmission should be much lower, such as 1. 3.2. Overlay Multicast We define overlay multicast as one that utilizes an infrastructure based on proxies (rather than an IP router based multicast backbone) to deliver IP multicast packets to end devices. MLD [RFC3810] has been selected as the basis for multicast support by the ROLL routing protocol . Therefore, it is proposed that "IGMP/MLD Proxying" [RFC4605] be used as an overlay multicast solution for CoAP. Specifically, a CoAP proxy [I-D.ietf-core-coap] may also contain an MLD Proxy function. All CoAP devices that want to join a given IP Rahman Expires September 12, 2011 [Page 8] Internet-Draft Group Communication for CoAP March 2011 multicast group would then send an MLD Join to the CoAP (MLD) proxy. Thereafter, the CoAP (MLD) proxy would be responsible for delivering any IP multicast message to the subscribed CoAP devices. Note that the CoAP (MLD) proxy may or may not be connected to an external multicast backbone. The key function for the CoAP (MLD) proxy is to distribute CoAP generated multicast packets even in the absence of router support for multicast. 4. CoAP Application Group Management Constrained devices can be large in number, but highly correlated to each other. For example, all the light switches in a building may belong to one group and all the thermostats belong to another group. All the smart meters in the same region can belong to one group as well. Groups may be composed by function; for example, the group "all lights in building one" may consist of the groups "all lights on floor one of building one", "all lights on floor two of building one", etc. Groups may be configured or dynamically formed. The CoAP protocol needs to support CoAP group management features independently of any underlying IP multicast support. For example, a constrained node needs to be able to specify which group it intends to join using a CoAP request by providing the group address. The CoAP Proxy node would be responsible for group membership management. It is proposed that CoAP supports two Header Options for group "join" and "leave". These Options are Elective so they should be assigned an even number. Assuming the Type for "join" is x (value TBD), the Header Options are illustrated by the table in Figure 1: +------+-----+---------------+--------------+--------+--------------+ | Type | C/E | Name | Data type | Length | Default | |------+-----+---------------+--------------+--------+--------------+ | | | ... current Option Headers |.. | | | | | | | | | x | E | Group Join | String | 1-270 | "" | | | | | | B | | | x+2 | E | Group Leave | String | 1-270 | "" | | | | | | B | | +------+-----|---------------+--------------+--------+--------------+ Figure 1: CoAP Header Options for Group Management Rahman Expires September 12, 2011 [Page 9] Internet-Draft Group Communication for CoAP March 2011 Figure 2 illustrates how a node can join or leave a group using the Header Options in a CoAP message: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | OC | Code | TID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delta |length | Join Group A (ID or URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |length | Join Group B (ID or URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 |length | Leave Group C (ID or URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: CoAP Message for Group Management Header Fields for the above example: Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by implementation as defined by the CoAP specification. T: 2-bit unsigned integer for CoAP Transaction Type. Either '0' Confirmation or '1' Non-Confirmable can be used for group "join" or "leave" request. OC: 4-bit unsigned integer for Option Count. For this example, the value should be "3" since there are three option fields. Code: 8-bit unsigned integer to indicate the Method in a Request or a Response Code in a Response message. Any Code can be used so the group management can be piggy-backed in either Request or Response message. Transaction ID: 16-bit unsigned integer assigned by the source to uniquely identify a pair of Request and Response. CoAP defined a delta encoding for header options. The first delta is the "Type" for group join in this specific example. If the type for group join is x as illustrated in Figure 1, delta will be x. In the second header option, it is also a group join so the delta is 0. The third header option is a group leave so the delta is 2. Rahman Expires September 12, 2011 [Page 10] Internet-Draft Group Communication for CoAP March 2011 5. Alternate Group Transmission Methods 5.1. Serial Unicast Unicast can also be used for the transmission of group messages. When unicast is used, no IP multicast address is provided by the application. Instead, the group URI must be expanded into unicast addresses. 6. CoAP Multicast and HTTP Unicast Interworking Within the constrained network, CoAP runs over UDP for which IP multicast is supported. In a non-constrained network (i.e. general Internet), HTTP over TCP is used for which IP multicast is not supported. Therefore the proxy node needs to have functionalities to support interworking of unicast and multicast as illustrated in Figure 3: Rahman Expires September 12, 2011 [Page 11] Internet-Draft Group Communication for CoAP March 2011 CoAP CoAP CoAP/HTTP HTTP Node 1 Node 2 Proxy Node 3 | | | | | REQUEST | | | | (Group Join) | | | |-----------------|------------- >| | | RESPONSE | | | |< ---------------|---------------| | | | | | | | REQUEST | | | | (Group Join) | | | |------------- >| | | | RESPONSE | | | |< -------------| | | | | | | | | | | | | HTTP REQUEST | | | | (URI to | | | | unicast addr) | | | |< -----------------| | | | | | | Map URI | | | to multicast address | | | | | | REQUEST (to multicast addr) | | | |< -------------| | |< ---------------|---------------| | | | | | | (optional) RESPONSE | | | |------------- >| | |-----------------|-------------->| | | | | HTTP RESPONSE | | | |----------------- >| | | | | Figure 3: CoAP Multicast and HTTP Unicast Interworking Note that Figure 3 illustrates the case of IP multicast as the underlying group communications mechanism. However the overlay multicast (Section 3.2) or CoAP application group communication (Section 4) can be used as the underlying mechanism and the principles of the figure would still apply (i.e. CoAP proxy needs to do interworking between HTTP unicast and CoAP multicast). A key point in Figure 3 is that the incoming HTTP Request (from node 3) will carry a URI (with the HTTP scheme) that resolves in the general Internet to the proxy node. At the proxy node, the URI will Rahman Expires September 12, 2011 [Page 12] Internet-Draft Group Communication for CoAP March 2011 then be again resolved (with the CoAP scheme) to an IP multicast destination. This may be accomplished, for example, by using DNS-SD (Section 3.1.3). The proxy node will then multicast the CoAP Request (corresponding to the received HTTP Request) to the appropriate nodes (i.e. nodes 1 and 2). In terms of the HTTP Response, Figure 3 illustrates that it will be generated by the proxy node and sent back to the client in the general Internet that sent the HTTP Request (i.e. node 1). So in terms of overall operation, the CoAP proxy can be considered to be a "non-transparent" proxy according to [RFC2616]. Specifically, [RFC2616] states that a "non-transparent proxy is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction or anonymity filtering." 7. Security Considerations Security for group communications at the IP level has been studied extensively in the IETF MSEC (Multicast Security) WG, and to a lesser extent in the IRTF SAMRG (Scalable Adaptive Multicast Research Group). In particular, [RFC3740], [RFC5374] and [RFC4046] are very instructive. The following requirements for securing group communications in CoAP were derived from a study of these previous investigations as well as understanding of CoAP specific needs: REQ1- Group communications data encryption: Important CoAP group communications shall be encrypted (using a group key) to preserve confidentiality. It shall also be possible to send CoAP group communications in the clear (i.e. unencrypted) for low value data. REQ2- Group communications source data authentication: Important CoAP group communications shall be authenticated by verifying the source of the data (i.e. that it was generated by a given and trusted group member). It shall also be possible to send unauthenticated CoAP group communications for low value data. REQ3- Group communications limited data authentication: Less important CoAP group communications shall be authenticated by simply verifying that it originated from one of the group members (i.e. without explicitly identifying the source node). This is a weaker requirement (but simpler to implement) than REQ2. It shall also be possible to send unauthenticated CoAP group communications for low value data. REQ4- Group key management: There shall be a secure mechanism to manage the cryptographic keys (e.g. generation and distribution) Rahman Expires September 12, 2011 [Page 13] Internet-Draft Group Communication for CoAP March 2011 belonging to the group; the state (e.g. current membership) associated with the keys; and other security parameters. REQ5- Use of Multicast IPSec: The CoAP protocol [I-D.ietf-core-coap] allows IPSec to be used as one option to secure CoAP. If IPSec is used at the CoAP level, then multicast IPSec [RFC5374] should be used for securing CoAP group communications. REQ6- Independence from underlying routing security: CoAP group communication security shall not be tied to the security of underlying routing and distribution protocols such as PIM [RFC4601] and ROLL [I-D.ietf-roll-rpl]. Insecure or inappropriate routing (including multicast routing) may cause loss of data to CoAP but will not affect the authenticity or secrecy of CoAP group communications. REQ7- Interaction with HTTPS: The security scheme for CoAP group communications shall account for the fact that it may need to interact with HTTPS (Hypertext Transfer Protocol Secure) when a transaction involves a node in the general Internet (non-constrained network). 8. IANA Considerations This document makes no request of IANA. 9. Conclusions Consider the proposals for group communication described in this draft for incorporation into the overall CoAP protocol specification. 10. Acknowledgements Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo Castellani, Guang Lu, Salvatore Loreto, Kerry Lynn, Dale Seed, Zach Shelby, Peter van der Stok, and Juan Carlos Zuniga for their helpful comments and discussions that have helped shape this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Rahman Expires September 12, 2011 [Page 14] Internet-Draft Group Communication for CoAP March 2011 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008. [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010. 11.2. Informative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-10 (work in progress), February 2011. Rahman Expires September 12, 2011 [Page 15] Internet-Draft Group Communication for CoAP March 2011 [I-D.eggert-core-congestion-control] Eggert, L., "Congestion Control for the Constrained Application Protocol (CoAP)", draft-eggert-core-congestion-control-01 (work in progress), January 2011. [I-D.ietf-6lowpan-hc] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)", draft-ietf-6lowpan-hc-15 (work in progress), February 2011. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-04 (work in progress), January 2011. [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link-format-02 (work in progress), December 2010. [I-D.shelby-core-coap-req] Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. Kelsey, "CoAP Requirements and Features", draft-shelby-core-coap-req-02 (work in progress), October 2010. [I-D.vanderstok-core-bc] Stok, P. and K. Lynn, "CoAP Utilization for Building Control", draft-vanderstok-core-bc-02 (work in progress), October 2010. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-18 (work in progress), February 2011. [ID.goland-http-udp] Goland, Y., "Multicast and Unicast UDP HTTP Messages", 1999, . [STUDY1] Lao, L., Cui, J., Gerla, M., and D. Maggiorini, "A Comparative Study of Multicast Protocols: Top, Bottom, or In the Middle?", 2005, . [STUDY2] Banerjee, B. and B. Bhattacharjee, "A Comparative Study of Application Layer Multicast Protocols", 2001, . Author's Address Akbar Rahman (editor) InterDigital Communications, LLC Email: Akbar.Rahman@InterDigital.com Rahman Expires September 12, 2011 [Page 17]