CoRE Working Group E. Dijk, Ed. Internet-Draft Philips Research Intended status: Informational A. Rahman, Ed. Expires: July 16, 2012 InterDigital Communications, LLC January 13, 2012 Miscellaneous CoAP Group Communication Topics draft-dijk-core-groupcomm-misc-00 Abstract This document contains miscellaneous text around the topic of group communication for the Constrained Application Protocol (CoAP). The first part contains, for reference, text that was removed from the Group Communication for CoAP draft. The second part describes group communication and multicast functionality that may be input to future standardization in the CoRE WG. 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 July 16, 2012. Copyright Notice Copyright (c) 2012 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 Dijk & Rahman Expires July 16, 2012 [Page 1] Internet-Draft Miscellaneous CoAP Group Communication January 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Group Communication Solutions . . . . . . . . . . . . . . . . . 3 2.1. IP Multicast Transmission Methods . . . . . . . . . . . . . 3 2.1.1. Serial unicast . . . . . . . . . . . . . . . . . . . . 3 2.1.2. Unreliable IP Multicast . . . . . . . . . . . . . . . . 3 2.1.3. Reliable IP Multicast . . . . . . . . . . . . . . . . . 3 2.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . . 4 2.3. CoAP Application Layer Group Management . . . . . . . . . . 5 3. Miscellaneous Topics . . . . . . . . . . . . . . . . . . . . . 8 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Dijk & Rahman Expires July 16, 2012 [Page 2] Internet-Draft Miscellaneous CoAP Group Communication January 2012 1. Introduction This document contains miscellaneous text around the topic of group communication for the Constrained Application Protocol, CoAP [I-D.ietf-core-coap]. The first part of the document (Section 2) contains, for reference, text that was removed from the Group Communication for CoAP [I-D.ietf-core-groupcomm] draft and its predecessor [I-D.rahman-core-groupcomm]. The second part of the document (Section 3) contains text and/or functionality that may be considered for inclusion in [I-D.ietf-core-groupcomm] or otherwise may be input to future standardization in the CoRE WG. 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 RFC 2119 [RFC2119]. 2. Group Communication Solutions This section includes the text that describes the solutions of IP multicast, overlay multicast, and application layer group communication which were removed from [I-D.rahman-core-groupcomm] version 07 when the text was transferred to [I-D.ietf-core-groupcomm]. 2.1. IP Multicast Transmission Methods 2.1.1. Serial unicast Even in systems that generally support IP Multicast, there may be certain data links (or transports) that don't support IP multicast. For those links a serial unicast alternative must be provided. This implies that it should be possible to enumerate the members of a group, in order to determine the correct unicast destinations. 2.1.2. Unreliable IP Multicast The CoRE WG charter specified support for non-reliable IP multicast. In the current CoAP protocol design [I-D.ietf-core-coap], unreliable multicast is realized by the source sending Non-Confirmable messages to a multicast IP address. IP Multicast (using UDP) in itself is unreliable, unless specific reliability features are added to it. 2.1.3. Reliable IP Multicast [TBD: 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 MID or a new MID for repeated requests? Dijk & Rahman Expires July 16, 2012 [Page 3] Internet-Draft Miscellaneous CoAP Group Communication January 2012 Carsten suggests the use of bloom filters to suppress duplicate responses. One could argue that non-idempotent operations (POST) cannot be supported without a *truly* reliable multicast protocol. However, is this the case? If a multicast POST request is sent repeatedly with the same Message ID (MID), then CoAP nodes that already received it once will ignore duplicates. Sending with Message ID is supported in CoAP for Non-Confirmable messages (thus including multicast messages) as per [I-D.ietf-core-coap] section 4.2. ] Reliable multicast supports guaranteed delivery of messages to a group of nodes. The following specifies the requirements as was proposed originally in version 01 of [I-D.vanderstok-core-bc]: o 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. o Integrity - destination receives m at most once from sender and only if sender sent m to a group including destination. o Agreement - If a correct destination of g receives m, then all correct destinations of g receive m. o 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 o Destination node sends response: a destination sends a CoAP Response upon multicast Request reception (it SHOULD be a Non- Confirmable response). The source node may retry a request to destination nodes that did not respond in time with a CoAP response. o Route redundancy o Source node transmits multiple times (destinations do not respond) 2.2. Overlay Multicast An alternative group communication solution (to IP Multicast) is an "overlay multicast" approach. We define an overlay multicast as one that utilizes an infrastructure based on proxies (rather than an IP router based IP multicast backbone) to deliver IP multicast packets Dijk & Rahman Expires July 16, 2012 [Page 4] Internet-Draft Miscellaneous CoAP Group Communication January 2012 to end devices. MLD ([RFC3810]) has been selected as the basis for multicast support by the ROLL working group for the RPL routing protocol. Therefore, it is proposed that "IGMP/MLD Proxying" [RFC4605] be used as a basis for 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 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. This will require modifications to the existing [RFC4605] functionality. Note that the CoAP (MLD) proxy may or may not be connected to an external IP multicast enabled 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. 2.3. CoAP Application Layer Group Management Another alternative solution (to IP Multicast and Overlay Multicast) is to define CoAP application level group management primitives. Thus, CoAP can support group management features without need for any underlying IP multicast support. Interestingly, such group management primitives could also be offered even if there is underlying IP multicast support. This is useful because IP multicast inherently does not support the concept of a group with managed members, while a managed group may be required for some applications. The following group management primitives are in general useful: o discover groups; o query group properties (e.g. related resource descriptions); o create a group; o remove a group; o add a group member; o remove a group member; o enumerate group members; Dijk & Rahman Expires July 16, 2012 [Page 5] Internet-Draft Miscellaneous CoAP Group Communication January 2012 o security and access control primitives. In this proposal a (at least one) CoAP Proxy node is responsible for group membership management. A constrained node can specify which group it intends to join (or leave) using a CoAP request to the appropriate CoAP Proxy. To Join, the group name will be included in optional request header fields (explained below). These header fields will be included in a PUT request to the Proxy. The Proxy-URI is set to the Group Management URI of the Proxy (found previously through the "/.well-known/" resource discovery mechanism). Note that in this solution also CoAP Proxies may exist in a network that are not capable of CoAP group operations. Group names may be defined as arbitrary strings with a predefined maximum length (e.g. 268 characters or the maximum string length in a CoAP Option), or as URIs. [ TBD: how can a client send a request to a group? Does it only need to know the group name (string or URI) or also an IP multicast address? One way is to send a CoAP request to the CoAP Proxy with a group URI directly in the Proxy-URI field. This avoids having to know anything related to IP multicast addresses. ] This solution in principle supports both unreliable and reliable group communication. A client would indicate unreliable communication by sending a CoAP Non-Confirmable request to the CoAP Proxy, or reliable communication by sending a CoAP Confirmable request. 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 | |------+-----+---------------+--------------+--------+--------------+ | | | | | | | | 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 Dijk & Rahman Expires July 16, 2012 [Page 6] Internet-Draft Miscellaneous CoAP Group Communication January 2012 Figure 2 illustrates how a node can join or leave a group using the Header Options in a CoAP message: 0 1 2 3 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 | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. Message ID: 16-bit value assigned by the source to uniquely identify a pair of Request and Response. CoAP defines 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 2, 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. An alternative solution to using Header Options (explained above) is to use designated parameters in the query part of the URI in the Dijk & Rahman Expires July 16, 2012 [Page 7] Internet-Draft Miscellaneous CoAP Group Communication January 2012 Proxy-URI field of a POST (TBD: or PUT?) request to a Proxy's group management service resource advertized by DNS-SD. For example, to join group1 and leave group2: coap://proxy1.bld2.example.com/groupmgt?j=group1&l=group2 3. Miscellaneous Topics This section is a placeholder to add miscellaneous text, topics or proposals related to CoAP group communication in future versions of this document. 4. Acknowledgements Thanks to all CoRE WG members who participated in the IETF 82 discussions, which was the trigger to initiate this document. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations Security aspects of group communication for CoAP are discussed in [I-D.ietf-core-groupcomm]. The current document contains no new proposals yet, for which security considerations have to be analyzed here. 7. References 7.1. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-08 (work in progress), October 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Dijk & Rahman Expires July 16, 2012 [Page 8] Internet-Draft Miscellaneous CoAP Group Communication January 2012 [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. 7.2. Informative References [I-D.ietf-core-groupcomm] Rahman, A. and E. Dijk, "Group Communication for CoAP", draft-ietf-core-groupcomm-00 (work in progress), January 2012. [I-D.rahman-core-groupcomm] Rahman, A. and E. Dijk, "Group Communication for CoAP", draft-rahman-core-groupcomm-07 (work in progress), October 2011. [I-D.vanderstok-core-bc] Stok, P. and K. Lynn, "CoAP Utilization for Building Control", draft-vanderstok-core-bc-05 (work in progress), October 2011. Authors' Addresses Esko Dijk (editor) Philips Research Email: esko.dijk@philips.com Akbar Rahman (editor) InterDigital Communications, LLC Email: Akbar.Rahman@InterDigital.com Dijk & Rahman Expires July 16, 2012 [Page 9]