CoRE A. Rahman, Ed. Internet-Draft InterDigital Communications, LLC Intended status: Informational October 14, 2010 Expires: April 17, 2011 Group Communication for CoAP draft-rahman-core-groupcomm-00 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 April 17, 2011. Copyright Notice Copyright (c) 2010 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 April 17, 2011 [Page 1] Internet-Draft Group Communication for CoAP October 2010 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 Level Group Management . . . . . . . . . . . . . . . . . 8 5. Alternate Group Transmission Methods . . . . . . . . . . . . . 10 5.1. Serial Unicast . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Unicast-to-Multicast . . . . . . . . . . . . . . . . . . . 10 6. CoAP and HTTP Interworking . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Rahman Expires April 17, 2011 [Page 2] Internet-Draft Group Communication for CoAP October 2010 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 multicast addresses as defined in "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: "Multicast messages SHOULD be Non-Confirmable. If a Confirmable multicast message is sent then retransmission MUST NOT be performed. Furthermore, a destination end-point to a multicast Confirmable message MUST only send an Acknowledgment if the response code included indicates success (Code = 2XX) in order to eliminate error code response floods." Additional requirements were introduced in [I-D.vanderstok-core-bc] driven by quality of experience issues in commercial lighting; the Rahman Expires April 17, 2011 [Page 3] Internet-Draft Group Communication for CoAP October 2010 need for large numbers of devices to respond with near simultaneity 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 servers 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 April 17, 2011 [Page 4] Internet-Draft Group Communication for CoAP October 2010 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, we propose the use of this addressing mode 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 scope) for a building control application are shown below: //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." Group URIs MUST follow the approach of the URI structure defined in [RFC3986]. 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 would be mapped to a unique multicast IP addresses as defined in [RFC4291]. 3.1.3. Group Discovery [Need to describe how group naming/scoping as defined in the previous section relates to group formation and discovery.] CoAP defines a resource discovery capability but it is limited to link-local scope; examples may be found in [I-D.ietf-core-coap]. A service discovery capability is required to extend discovery to other subnets, 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 DNS zone as in the examples above. For each CoAP end-point in the zone, a PTR record with the name Rahman Expires April 17, 2011 [Page 5] Internet-Draft Group Communication for CoAP October 2010 _coap._udp is defined and it points to an SRV record having the 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. 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 April 17, 2011 [Page 6] Internet-Draft Group Communication for CoAP October 2010 - All multicast requests SHOULD operate on /.well-known/core URIs 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 [1998 Microsoft I-D ref] might be useful (e.g., "corem:" vs. "core:"). 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 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 Rahman Expires April 17, 2011 [Page 7] Internet-Draft Group Communication for CoAP October 2010 * 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 [Discuss proxy-based multicast solutions that eliminate the need for router support, e.g., "IGMP/MLD Proxying" [RFC4605].] 4. CoAP Level 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. Rahman Expires April 17, 2011 [Page 8] Internet-Draft Group Communication for CoAP October 2010 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 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 Rahman Expires April 17, 2011 [Page 9] Internet-Draft Group Communication for CoAP October 2010 "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. 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. 5.2. Unicast-to-Multicast [Discuss how a unicast message can be converted by a proxy to a CoAP multicast request as in Figure 3.] 6. CoAP and HTTP Interworking Within the constrained network, an application protocol (e.g., CoAP) usually runs over UDP for which IP multicast is supported. In a non- constrained network (i.e. general Internet), HTTP over TCP is typically used for which IP multicast is not naturally supported. This causes the scenario below: The traffic within the constrained network is multicast (such as CoAP over UDP), and within the non-constrained network it is unicast (such as HTTP over TCP) Therefore the proxy node needs to have functionalities to support Rahman Expires April 17, 2011 [Page 10] Internet-Draft Group Communication for CoAP October 2010 interworking of unicast and multicast as illustrated in Figure 3: CoAP CoAP CoAP/HTTP HTTP Node 1 Node 2 Proxy Node 3 | | | | | REQUEST | | | | (Group Join) | | | |-----------------|------------- >| | | RESPONSE | | | |< ---------------|---------------| | | | | | | | REQUEST | | | | (Group Join) | | | |------------- >| | | | RESPONSE | | | |< -------------| | | | | | | | | | | | | HTTP REQUEST | | | | (to unicast addr) | | | |< -----------------| | | | | | | map destination | | | to multicast address | | | | | | REQUEST (to multicast addr) | | | |< -------------| | |< ---------------|---------------| | | | | | | (optional) RESPONSE | | | |------------- >| | |-----------------|-------------->| | | | | HTTP RESPONSE | | | |----------------- >| | | | | Figure 3: Multicast and Unicast Interworking 7. Security Considerations There is an IETF WG (msec) engaged in group security. Additionally, the control plane of PIM-SM seems to require IPSec for its operations. Any secure data transfers over IP multicast would seem to require a group keying scheme. More investigation required. Rahman Expires April 17, 2011 [Page 11] Internet-Draft Group Communication for CoAP October 2010 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 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, Kerry Lynn, Guang Lu, Zach Shelby, Peter van der Stok, Juan Carlos Zuniga and others for helpful comments and discussions that have shaped 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. [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. [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. Rahman Expires April 17, 2011 [Page 12] Internet-Draft Group Communication for CoAP October 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-06 (work in progress), March 2010. [I-D.eggert-core-congestion-control] Eggert, L., "Congestion Control for the Constrained Application Protocol (CoAP)", draft-eggert-core-congestion-control-00 (work in progress), June 2010. [I-D.ietf-6lowpan-hc] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-13 (work in progress), September 2010. [I-D.ietf-core-coap] Shelby, Z., Frank, B., and D. Sturek, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-02 (work in progress), September 2010. [I-D.rahman-core-sleeping] Rahman, A., Zuniga, J., and G. Lu, "Sleeping and Multicast Considerations for CoAP", draft-rahman-core-sleeping-00 (work in progress), June 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-01 (work in progress), April 2010. [I-D.vanderstok-core-bc] Stok, P. and K. Lynn, "CoAP Utilization for Building Control", draft-vanderstok-core-bc-01 (work in progress), July 2010. [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, . Rahman Expires April 17, 2011 [Page 13] Internet-Draft Group Communication for CoAP October 2010 Author's Address Akbar Rahman (editor) InterDigital Communications, LLC Email: Akbar.Rahman@InterDigital.com Rahman Expires April 17, 2011 [Page 14]