[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/