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,
              <http://tools.ietf.org/html/draft-goland-http-udp-01>.

   [STUDY1]   Lao, L., Cui, J., Gerla, M., and D. Maggiorini, "A
              Comparative Study of Multicast Protocols: Top, Bottom, or
              In the Middle?", 2005, <http://www.cs.ucla.edu/NRL/hpi/



Rahman                 Expires September 12, 2011              [Page 16]


Internet-Draft        Group Communication for CoAP            March 2011


              AggMC/papers/comparison_gi_2005.pdf>.

   [STUDY2]   Banerjee, B. and B. Bhattacharjee, "A Comparative Study of
              Application Layer Multicast Protocols", 2001, <http://
              wmedia.grnet.gr/P2PBackground/
              a-comparative-study-ofALM.pdf>.


Author's Address

   Akbar Rahman (editor)
   InterDigital Communications, LLC

   Email: Akbar.Rahman@InterDigital.com





































Rahman                 Expires September 12, 2011              [Page 17]