CoRE                                                      A. Rahman, Ed.
Internet-Draft                          InterDigital Communications, LLC
Intended status: Informational                              E. Dijk, Ed.
Expires: November 17, 2011                              Philips Research
                                                            May 16, 2011


                      Group Communication for CoAP
                     draft-rahman-core-groupcomm-05

Abstract

   This is a working document intended to trigger discussion and develop
   draft text 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 November 17, 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



Rahman & Dijk           Expires November 17, 2011               [Page 1]


Internet-Draft        Group Communication for CoAP              May 2011


   include Simplified BSD License text as described in Section 4.e of
   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.  Potential Solutions  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  IP Multicast . . . . . . . . . . . . . . . . . . . . . . .  6
       3.3.1.  Multicast Listener Discovery (MLD) and Multicast
               Router Discovery (MRD) . . . . . . . . . . . . . . . .  7
       3.3.2.  Group URIs and Multicast Addresses . . . . . . . . . .  7
       3.3.3.  Group Discovery  . . . . . . . . . . . . . . . . . . .  8
       3.3.4.  Group Resource Manipulation  . . . . . . . . . . . . .  8
       3.3.5.  IP Multicast Transmission Methods  . . . . . . . . . . 10
       3.3.6.  Congestion Control . . . . . . . . . . . . . . . . . . 11
     3.4.  Overlay Multicast  . . . . . . . . . . . . . . . . . . . . 11
     3.5.  CoAP Application layer Group Management  . . . . . . . . . 12
     3.6.  CoAP Multicast and HTTP Unicast Interworking . . . . . . . 14
     3.7.  CoAP-observe for Group Communication . . . . . . . . . . . 16
   4.  Recommended Solution . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.2.  Implementation in Target Network Topologies  . . . . . . . 17
       4.2.1.  Single LLN Topology  . . . . . . . . . . . . . . . . . 17
       4.2.2.  Single LLN with Backbone Topology  . . . . . . . . . . 19
       4.2.3.  Multiple LLN with Backbone Topology  . . . . . . . . . 21
       4.2.4.  Conclusions  . . . . . . . . . . . . . . . . . . . . . 21
     4.3.  HTTP/CoAP Interworking Aspects . . . . . . . . . . . . . . 21
     4.4.  Implementation Considerations  . . . . . . . . . . . . . . 21
       4.4.1.  MLD Implementation on LLNs . . . . . . . . . . . . . . 22
       4.4.2.  6LBR Implementation  . . . . . . . . . . . . . . . . . 22
       4.4.3.  Backbone Multicast Infrastructure  . . . . . . . . . . 22
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 24
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27





Rahman & Dijk           Expires November 17, 2011               [Page 2]


Internet-Draft        Group Communication for CoAP              May 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 specific terminology used in this
   draft.

   Group Communication: One source node sends a 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.

   Low power and Lossy Network (LLN): LLNs are made up of constrained
   devices.  These devices may be interconnected by a variety of links,
   such as IEEE 802.15.4, Bluetooth, WiFi, wired or low-power powerline
   communication links.

   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].


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 CoAP
   are documented in [I-D.shelby-core-coap-req].

   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 a 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 also be configured or dynamically formed.

   In this draft, we focus and expand discussions on the requirements
   pertaining to CoAP group communication and multicast support,
   including:






Rahman & Dijk           Expires November 17, 2011               [Page 3]


Internet-Draft        Group Communication for CoAP              May 2011


      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
   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 or combinations
   thereof.  We assume that all, or a substantial part of, devices
   participating in group communication are constrained devices (LLN).

   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 mechanisms can improve efficiency and latency 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 requirements, proposed solutions and
   analysis of their impact to the CoAP protocol and implementations.


3.  Potential Solutions

3.1.  Overview

   The classic model of a multicast application is that of a single
   source distributing content to many recipients.  Multicast solutions



Rahman & Dijk           Expires November 17, 2011               [Page 4]


Internet-Draft        Group Communication for CoAP              May 2011


   have evolved from "bottom" to "top", i.e., from the network layer (IP
   multicast) to application layer multicast.  A study published in 2005
   [STUDY1] identified new solutions in the "middle" (referred to as
   overlay multicast) that utilize an infrastructure based on proxies.

   Each of these classes of multicast solutions may be compared [STUDY1]
   using metrics such as link stress and level of host complexity
   [STUDY2].  The results show for a realistic internet topology that IP
   Multicast is most resource-efficient, with the only downside being
   that it requires most effort to deploy in the infrastructure.

   The approach adopted here is to begin with IP multicast and present a
   complete picture to introduce some key concepts, then introduce an
   overlay solution, then application layer multicast and finally cover
   additional topics such as group management and CoAP/HTTP proxies.

3.2.  Requirements

   Requirements that a group communication solution in CoRE should
   fulfill can be found in existing documents [RFC 5867]
   [draft-ietf-6lowpan-routing-requirements] [I-D.vanderstok-core-bc]
   [I-D.shelby-core-coap-req].  Below, a set of high-level requirements
   is listed that a group communication solution in CoRE should ideally
   fulfill.  More precise requirements may depend on the chosen
   application (area).

   A CoRE group communication solution should (ideally) offer:
   REQ 1:    Reliability: at least unreliable group communication, but
             preferably reliable group communication as well.
   REQ 2:    Efficiency: delivers messages more efficiently than a
             "serial unicast" implementation would.  Also, it should
             provide a right balance between multicast traffic and
             control overhead.
   REQ 3:    Low latency: deliver a message (preferably) as fast as
             possible.
   REQ 4:    Synchrony: allows near-simultaneous modification of a
             resource on all devices in a group, providing to users a
             perceived effect of synchrony or simultaneity.  It can be
             expressed as a time span D such that message m is delivered
             to all destinations in a time interval [t,t+D] for
             arbitrary t.
   REQ 5:    Ordering: [ TBD to check what our use cases require in
             terms of message ordering especially in multi-source
             situations. ]







Rahman & Dijk           Expires November 17, 2011               [Page 5]


Internet-Draft        Group Communication for CoAP              May 2011


   REQ 6:    Security: see Section 5 for a list of security requirements
             for group communication.
   REQ 7:    Flexibility: support for one or many multicast source(s),
             for dense and sparse networks, for high or low multicast
             listener density, one or many multicast group(s), and
             multi-group membership.
   REQ 8:    Robust group management: includes functionality to join
             groups, leave groups, view group membership, and persistent
             group membership in failing node or sleeping node
             situations.
   REQ 9:    Network layer independence: a solution should be specified
             independent from specific unicast and/or multicast routing
             protocols.  It should support different routing protocols
             and implementations thereof.
   REQ 10:   Minimal specification overhead: a group communication
             solution should preferably re-use existing/established
             (IETF) protocols that are suitable for Low-power and Lossy
             Network (LLN) deployment, instead of defining new protocols
             from scratch.
   REQ 11:   Mixed backbone/LLN topology support: a solution should work
             within a single LLN, in combined LLN/backbone network
             topologies, including multi-LLN topologies.  Both the
             senders and receivers of CoAP group messages may be
             attached to different network link or be part of different
             LLNs, possibly with routers or switches in between group
             members.  In addition, different routing protocols may
             operate on the LLN and backbone networks.  Preferably a
             solution also works with existing, common backbone
             networked devices (e.g. switches or routers).
   REQ 12:   CoAP Proxying support: a CoAP proxy can handle distribution
             of a message to a group on behalf of a (constrained) CoAP
             client.

3.3.  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 general Internet.
   However, IP Multicast is popular in specific deployments such as in
   enterprise networks (e.g. for video conferencing or general multicast
   PC applications within a single LAN broadcast domain) and carrier
   IPTV deployments.  Therefore, the packet economy and minimal host
   complexity of IP multicast make it worth investigating for group
   communication in constrained environments.






Rahman & Dijk           Expires November 17, 2011               [Page 6]


Internet-Draft        Group Communication for CoAP              May 2011


3.3.1.  Multicast Listener Discovery (MLD) and Multicast Router
        Discovery (MRD)

   The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its
   IPv4 pendant IGMP) is today the method of choice used by an
   (multicast enabled) IPv6 router to discover the presence of multicast
   listeners on directly attached links, and to discover which multicast
   addresses are of interest to those listening nodes.  It was
   specifically designed to cope with fairly dynamic situations in which
   multicast listeners may join and leave at any time.

   IGMP/MLD Snooping is a technique implemented in some corporate LAN
   routing/switching devices.  An MLD snooping switch listens to MLD
   State Change Report messages from MLD listeners on attached links.
   Based on this, the switch learns on what LAN segments there is
   interest for what IP multicast traffic.  If the switch receives at
   some point a multicast packet, it uses the stored information to
   decide onto which LAN segment(s) to send the packet.  This improves
   network efficiency compared to the regular solution of forwarding
   every incoming multicast packet onto all LAN segments.  An MLD
   snooping switch may also send out MLD Query messages (which is
   normally done by an MLD Router) if no MLD router is present.

   The Multicast Router Discovery (MRD) protocol [RFC4286] defines a way
   to discover multicast routers, for the purpose of using this
   information by IGMP/MLD snooping devices.  However, it appears that
   this protocol is not as commonly implemented in existing products as
   MLD is.

3.3.2.  Group URIs and Multicast Addresses

   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].

     URI authority                  Targeted group
     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 can be mapped



Rahman & Dijk           Expires November 17, 2011               [Page 7]


Internet-Draft        Group Communication for CoAP              May 2011


   to a unique multicast IP address.  This may be an address allocated
   according to [RFC3956], [RFC3306] or [RFC3307].

3.3.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 services offered by CoAP nodes, or
   enumeration of all CoAP nodes, within specified subdomains.  A
   service is specified by a name of the form
   <Instance>.<ServiceType>.<Domain>, where the service type for CoAP
   nodes is _coap._udp and the domain is a DNS domain name that
   identifies a group as in the examples above.  For each CoAP end-point
   in a group, a PTR record with the name _coap._udp or alternatively
   the name _coap._upd.<Domain> is defined and it points to an SRV
   record having the <Instance>.<ServiceType>.<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 DNS
   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 or alternatively
   _group._sub._coap._udp.<Domain>.

3.3.4.  Group Resource Manipulation

   At least 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
   commissioning and can be illustrated by the example "return all the



Rahman & Dijk           Expires November 17, 2011               [Page 8]


Internet-Draft        Group Communication for CoAP              May 2011


   resources on all CoAP servers advertized by their .well-known/core
   URI".  MGET to an "all-nodes" or "all-CoAP-nodes" multicast IP
   address 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
   avoiding serial unicast in favor of a multicast CoAP GET/PUT
   solution:

      -  packet economy on constrained networks
      -  M2M resource discovery (solves the "chicken-and-egg" problem)
      -  apparent simultaneity of events (e.g. in lighting applications)
      -  average lower latency per event (e.g. in lighting applications)

   Ideally, all nodes in a given group (defined by multicast 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 if
   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.

   Therefore, some measures must be present to ensure uniformity in port
   number and resource name/location within a group.

   A first solution in this respect is to couple groups to service
   descriptions in DNS (using DNS-SD as in Section 3.3.3 and
   [I-D.vanderstok-core-bc]).  A service description for a multicast
   group may have a TXT record in DNS defining a schema X (e.g.
   "schema=DALI"), which defines by service standard X (e.g.  "DALI")
   which resources a node supporting X MUST have.  Therefore a multicast
   source can safely refer to all resources with corresponding
   operations as prescribed by standard X. For port numbers (which can
   be found using DNS-SD also) the same holds.  Alternatively, only the
   default CoAP port may be used in all requests.

   A second solution is to impose the following restrictions, e.g. for
   multicast groups not found using, or advertized in, DNS-SD:
   o  All multicast requests MUST be sent to the well-known CoAP port.
   o  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 [ID.goland-http-udp] might be useful (e.g. "corem" vs.
   "core").  To the extent that group membership might be implemented as



Rahman & Dijk           Expires November 17, 2011               [Page 9]


Internet-Draft        Group Communication for CoAP              May 2011


   a list of multicast, serial unicast, or some combination, having a
   distinct scheme for group operations might be a useful signal for a
   proxy receiving the request to look up the group membership and
   replicate serial unicasts as well as send multicast packets.

3.3.5.  IP Multicast Transmission Methods

3.3.5.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.

3.3.5.2.  Unreliable IP Multicast

   The CoRE WG charter specified support for 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
   to a multicast IP address.  IP Multicast (using UDP) in itself is
   unreliable, unless specific reliability features are added to it.

3.3.5.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?
   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 (e.g., 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.





Rahman & Dijk           Expires November 17, 2011              [Page 10]


Internet-Draft        Group Communication for CoAP              May 2011


   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: in CoAP, multicast messages MUST
      be Non-Confirmable.  However a destination may send a response
      upon multicast message reception, which SHOULD then be a Non-
      Confirmable response.  The source node could retry delivery to
      destination nodes that did not respond in time.
   o  Route redundancy
   o  Source node transmits multiple times

3.3.6.  Congestion Control

   CoAP requests may be multicast, resulting a multitude of replies from
   different nodes, potentially causing congestion.
   [I-D.eggert-core-congestion-control] suggests to conservatively
   control sending multicast requests.

   CoAP already addresses the congestion problem to some extent by
   requiring all multicast CoAP requests to be Non-Confirmable.
   However, as responses to multicast requests (both MGET or MPUT) are
   typical, using CoAP multicast still may lead to congestion issues.

   Various means can be implemented to prevent congestion.

   [TBD: if an MGET or MPUT request leads to the sending of a CoAP
   response by servers, the servers should enforce a random delay within
   TIMEOUT before sending their responses.  More investigation
   required.]

   Currently in the CoAP protocol, a MAX_RETRANSMIT value set by default
   to 4 is used for retransmission of Confirmable messages.  Since CoAP
   multicast messages are Non-Confirmable, no retransmissions will occur
   in CoAP, making the effective retransmission value 0.

3.4.  Overlay Multicast

   An alternative 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
   multicast backbone) to deliver IP multicast packets to end devices.
   MLD [RFC3810] has been selected as the basis for multicast support by



Rahman & Dijk           Expires November 17, 2011              [Page 11]


Internet-Draft        Group Communication for CoAP              May 2011


   the ROLL working group for the RPL 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
   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 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.

3.5.  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.

   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



Rahman & Dijk           Expires November 17, 2011              [Page 12]


Internet-Draft        Group Communication for CoAP              May 2011


   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


   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'



Rahman & Dijk           Expires November 17, 2011              [Page 13]


Internet-Draft        Group Communication for CoAP              May 2011


   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.

   An alternative solution to using Header Options (explained above) is
   to use designated parameters in the query part of the URI in the
   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.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 a CoAP/HTTP Proxy node that supports group
   communication needs to have functionalities to support interworking
   of unicast and multicast.  One possible way of operation of the Proxy
   is illustrated in Figure 3.  Note that a more detailed example is
   provided in [I-D.castellani-core-http-coap-mapping].

   [ TBD: Need to add another figure like Figure 3 (somewhere in the
   I-D) but just concentrating on multicast within CoAP (i.e. without
   showing interworking with HTTP). ]









Rahman & Dijk           Expires November 17, 2011              [Page 14]


Internet-Draft        Group Communication for CoAP              May 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.4) or CoAP application group communication
   (Section 3.5) 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 & Dijk           Expires November 17, 2011              [Page 15]


Internet-Draft        Group Communication for CoAP              May 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.3.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 based on aggregated responses of the CoAP
   nodes and sent back to the client in the general Internet that sent
   the HTTP Request (i.e. node 1).  In
   [I-D.castellani-core-http-coap-mapping] the HTTP Response that the
   Proxy may use to aggregate multiple CoAP responses is described in
   more detail.  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."

   An alternative to the above is using a Forward Proxy.  In this case,
   the CoAP request URI could be carried in the HTTP Request Line (as
   defined in [I-D.ietf-core-coap] Section 8) in a HTTP request sent to
   the IP address of the Proxy.

3.7.  CoAP-observe for Group Communication

   The CoAP Observation extension [I-D.ietf-core-observe] can be
   directly used for group communication.  A group then consists of a
   CoAP server hosting a specific resource, plus all CoAP clients
   observing that resource.  The server is the only group member that
   can send a group message.  It does this by modifying the state of a
   resource under observation and subsequently notifying its observers
   of the change.  Serial unicast is used in this case for
   notifications.

   Group communication is unreliable in the sense that, even though
   confirmable CoAP messages may be used, there are no guarantees that
   an update will be received.  For example, a client may believe it is
   observing a resource while in reality the server rebooted and lost
   its listener state.


4.  Recommended Solution







Rahman & Dijk           Expires November 17, 2011              [Page 16]


Internet-Draft        Group Communication for CoAP              May 2011


4.1.  Overview

   We recommend that unreliable IP multicast as outlined in Section 3.3
   be adopted as the base solution for CoAP Group Communication.  This
   approach requires no standards changes to the IP multicast suite of
   protocols.  It may require implementing pieces of IP Multicast
   functionality in an LLN, in a backbone network, or in both - this
   will be evaluated in more detail further in this section.

4.2.  Implementation in Target Network Topologies

   This section looks in more detail how an IP Multicast based solution
   can be deployed onto the various network topologies that we consider
   important for group communication use cases.  Note that the chosen
   solution of IP Multicast for CoAP group communication works mostly
   independently from the underlying network topology and its specific
   multicast implementation.

   Starting from the simplest case of a single LLN topology, we move to
   more complex topologies involving a backbone network or multiple
   LLNs.  With "backbone" we refer here typically to a corporate LAN or
   VLAN, which constitutes a single broadcast domain by design.  It
   could also be an in-home network.  A multi-link backbone is also
   possible, if there is proper multicast routing or forwarding
   configured between these links.  (The term 6LoWPAN Border Router or
   "6LBR" is used here for a border router, though our evaluation is not
   necessarily restricted to 6LoWPAN networks.)

4.2.1.  Single LLN Topology

   The simplest topology is a single LLN, where all the multicast
   source(s) and destinations are constrained nodes within this same
   LLN.  Possible implementations of multicast routing and group
   administration for this topology are listed below.

4.2.1.1.  Mesh-Under Multicast Routing

   The LLN may be set up in either a mesh-under or a route-over
   configuration.  In the former case, the mesh routing protocol should
   take care of routing IP multicast messages througout the LLN.

   Because conceptually all nodes in the LLN are attached to a single
   link, there is in principle no need for nodes to announce their
   interest in multicast addresses via MLD.  A multicast message to a
   specific IP destination, which is delivered to all nodes by the mesh
   routing algorithm, is accepted by the IP network layer of that node
   only if it is listening on that specific multicast address.  However,
   packet delivery is not guaranteed because mesh routing algorithms



Rahman & Dijk           Expires November 17, 2011              [Page 17]


Internet-Draft        Group Communication for CoAP              May 2011


   generally make no such delivery guarantees.

4.2.1.2.  RPL Multicast Routing

   The RPL routing protocol for LLNs [I-D.ietf-roll-rpl] provides
   support for routing to multicast destinations.  Like regular unicast
   destinations, multicast destinations are advertized by nodes using
   RPL DAO messages.

   Once all RPL routing tables in the network are populated, the DODAG
   root node can send packets to all IP multicast destinations (that
   were previously advertized using DAOs) downwards into the DODAG.

   This approach seems efficient in a balanced, sparse tree network
   topology or in situations where the fraction of nodes listening to a
   specific multicast address is low.

   [To be investigated: is always serial unicast used in RPL for
   forwarding a packet to child nodes, or can link-local multicast be
   used in case the destination is a multicast IP address, for
   efficiency?]

4.2.1.3.  RPL Routers with Non-RPL Hosts

   When hosts exist in a RPL network that are not RPL-aware, these can't
   advertize their multicast groups of interest via RPL DAO messages as
   defined above.  In that case MLD could be used for such advertizement
   (State Change Report messages), with all or a subset of RPL routers
   acting in the role of MLD Routers as defined in [RFC3810] .

   However, as the MLD protocol is not designed specifically for LLNs it
   may be a burden for the constrained RPL router nodes to run the full
   MLD protocol.  An alternative is to implement a subset of MLD
   functionality in the RPL routers which is just enough for the
   intended operation.  For example, RPL routers could like MLD Snoopers
   passively listen to MLD State Change Report messages and send
   advertized multicast destinations to their RPL parents (e.g., by
   sending DAOs) based on the snooped MLD information.  Alternatively, a
   subset of MLD could be standardized into a "MLD for 6LoWPAN" protocol
   to support constrained nodes even better.  Yet another alternative is
   to standardize a new message Option in existing 6LoWPAN-ND
   [I-D.ietf-6lowpan-nd] communication between a host and router(s).

4.2.1.4.  Trickle Multicast Forwarding

   Trickle Multicast Forwarding [I-D.ietf-roll-trickle-mcast] is a
   multicast routing protocol suitable for LLNs, that uses the Trickle
   algorithm as a basis.  It is a simple protocol in the sense that no



Rahman & Dijk           Expires November 17, 2011              [Page 18]


Internet-Draft        Group Communication for CoAP              May 2011


   topology maintenance is required.  It can deal especially well with
   situations where the node density is a-priori unknown.

   Nodes from anywhere in the LLN can be the multicast source, and nodes
   anywhere in the LLN can be multicast destinations.

   Assuming that all constrained nodes within an LLN participate in the
   Trickle Multicast algorithm, it is not required for multicast
   destinations (listeners) to announce their interest in a specific
   multicast address, e.g. by means of MLD or other means.  Instead, all
   multicast packets are stored and forwarded by all nodes.  Nodes that
   receive multicast packets they are not interested in, will only
   buffer these for a limited time until retransmission is allowed based
   on their Trickle timer.  These properties seem to make Trickle
   especially useful for cases where the multicast listener density is
   high and the number of distinct multicast groups relatively low.

4.2.1.5.  Other Route-Over Methods

   Other known multicast routing methods may be used in route-over
   configurations, for example flooding or other to be defined methods
   suitable for LLNs.  An important design consideration here is whether
   multicast listeners need to advertize their interest in specific
   multicast addresses, or not.  If so MLD is a possible option but also
   protocol-specific means (as in RPL) is an option.  See
   Section 4.2.1.3 for more options for advertizement.

4.2.2.  Single LLN with Backbone Topology

   A LLN may be connected via a Border Router (e.g. 6LBR) to a backbone
   network, on which multicast listeners and/or sources may be present.

4.2.2.1.  Mesh-Under Multicast Routing

   Because conceptually all nodes in the LLN are attached to a single
   link, a multicast packet originating in the LLN is delivered by the
   mesh routing algorithm to the 6LBR as well, although there is no
   guaranteed delivery.  The 6LBR may be configured to accept all
   multicast traffic from the LLN and then may forward such packets onto
   its backbone link.  Alternatively, the 6LBR may act in an MLD Router
   role on its backbone link and decide whether to forward a multicast
   packet or not based on information learnt from previous MLD Reports
   received on its backbone link.

   Conversely, multicast packets originating on the backbone network
   will reach the 6LBR if either the backbone is a single link (LAN) or
   multicast routing is enabled on the backbone.  Then, the 6LBR could
   simply forward all multicast traffic from the backbone onto the LLN.



Rahman & Dijk           Expires November 17, 2011              [Page 19]


Internet-Draft        Group Communication for CoAP              May 2011


   However, in practice this situation may lead to overload of the LLN
   caused by unnecessary multicast traffic.  Therefore the 6LBR SHOULD
   only forward traffic that one or more nodes in the LLN have expressed
   interest in, effectively filtering incoming LLN multicast traffic.

   To realize this "filter", nodes on the LLN may use MLD to announce
   their interest in specific multicast addresses to the 6LBR.  One
   option is for the 6LBR to act in an MLD Router role on its LLN
   interface.  However, this may be too much of a "burden" for
   constrained nodes.  For example, an MLD Router usually sends out
   periodic multicast queries to probe for multicast listening state.
   To mitigate this the parameters of MLD could be tuned specifically to
   LLN situations.

4.2.2.2.  RPL Multicast Routing

   First, we consider the case of a multicast source on the backbone
   network with one or more multicast listeners on the RPL LLN.
   Typically, the 6LBR would be the root of a DODAG so that the 6LBR can
   easily forward the multicast packet received on its backbone
   interface to the right RPL nodes in the LLN along this DODAG (based
   on previously DAO-advertized destinations).

   Second, a multicast source may be in the RPL LLN and listeners may be
   both on the LLN and on the backbone.  The source has to be a DODAG
   root in this case.  In order to correctly route multicast packets
   from the LLN onto the backbone, the 6LBR has to take part in the
   DODAG created by the multicast source (which is a different DODAG
   than the DODAG kept by the 6LBR, in case the source is not the 6LBR
   itself).

4.2.2.3.  RPL Routers with Non-RPL Hosts

   For the case that a RPL LLN contains non-RPL hosts, the solutions
   from the previous section can be used if in addition RPL routers
   implement MLD or "MLD like" functionality similar to as described in
   Section 4.2.1.3.

4.2.2.4.  Trickle Multicast Forwarding

   First, we consider the case of a multicast source on the LLN
   (supporting Trickle Multicast Forwarding) and multicast listeners
   that may be on the LLN and on the backbone.  As Trickle will
   eventually deliver all multicast packets also to the 6LBR, the 6LBR
   can then forward onto the backbone in the ways described earlier.

   Second, for the case of a multicast source on the backbone and
   multicast listeners on both backbone and/or LLN, the 6LBR needs to



Rahman & Dijk           Expires November 17, 2011              [Page 20]


Internet-Draft        Group Communication for CoAP              May 2011


   forward multicast traffic from the backbone onto the LLN.  Here, the
   potential problem of overloading the LLN with unneeded backbone
   multicast traffic appears again.  A possible solution to this is
   again to let all multicast listeners advertize their interest using
   MLD Report messages as described in Section 4.2.2.1.

4.2.2.5.  Other Route-Over Methods

   For other multicast routing methods used on the LLN, there are
   similar considerations to the ones in sections above: the need to
   filter multicast traffic coming into the LLN, the need for reporting
   multicast listener interest (e.g. with MLD) by constrained nodes, and
   the need for LLN routing such that MLD protocol messages can reach
   the 6LBR.

4.2.3.  Multiple LLN with Backbone Topology

   Next the case of a single backbone network with two or more LLNs
   attached to it via 6LBRs is considered.

   For the specific case that a source on a backbone network has to
   multicast to a very large number of destination located on many LLNs,
   the use of IGMP/MLD Proxying [RFC4605] with a leaf IGMP/MLD Proxy
   located in each 6LBR may be useful.  This method only is defined for
   a tree topology backbone network with the multicast source at the
   root of the tree.

4.2.4.  Conclusions

   For all network topologies that were evaluated, CoAP group
   communication can be in principle supported with IP Multicast, making
   use of existing protocols.  Also potential opportunities were
   identified for an "MLD-like" or "MLD-lightweight" protocol
   specifically for LLNs, which would interwork with regular MLD on the
   backbone network.

4.3.  HTTP/CoAP Interworking Aspects

   [ TBD: consider e.g.  HTTP unicast translated to CoAP multicast.
   Like before, but now using MLD for group joins on the LLN side. ]

4.4.  Implementation Considerations

   In this section various implementation aspects are considered such as
   required protocol implementations, additional functionality of the
   6LBR and backbone network equipment.





Rahman & Dijk           Expires November 17, 2011              [Page 21]


Internet-Draft        Group Communication for CoAP              May 2011


4.4.1.  MLD Implementation on LLNs

   [ TBD: consider here the complexity of MLD, and what aspects are
   needed/not needed for CoAP/LLN applications.  Will MLDv1 suffice?
   What to do with options like 'source specific' and include/exclude.
   Do we need limits on number of records per packet?  Do we need a
   higher reliability setting?  Potential input for an "MLD-light for
   LLNs" protocol. ]

   [ TBD: consider MLD is geared to a fairly dynamic situation with
   multicast listeners coming and going.  Perfect for the general
   internet, but does this make sense in a LLN?  For example in many of
   our building control applications, most multicast groups can be
   expected to remain constant over longer periods of time (like many
   months).]

4.4.2.  6LBR Implementation

   To support mixed backbone/LLN scenarios in group communication, it is
   recommended that a 6LowPAN Border Router (6LBR) will act as an MLD
   router on the backbone link.  Alternatively, a 6LBR can be configured
   to act as an MLD multicast listener on the backbone link, with a
   separate MLD router also present on the backbone link.

4.4.3.  Backbone Multicast Infrastructure

   [TBD: add a note about IPv6 readiness of backbone routing/switching
   equipment.  And on IPv4 backbones: consider this as out of scope. ]

   The availability of, and requirements for, IP multicast support may
   depend on the specific installation use case.  For example, the
   following cases may be relevant for new IP based building control
   installations:
   1.  System deployed on existing IP (Ethernet/WiFi/...)
       infrastructure, shared with existing IP devices (PCs)
   2.  Newly designed & deployed IP (Ethernet/WiFi/...) infrastructure,
       to be shared with other IP devices (PCs)
   3.  Newly designed & deployed IP (Ethernet/WiFi/...) infrastructure,
       exclusively used for building control.
   Besides physical separation the building control backbone can be
   separated from regular (PC) infrastructure by using a different VLAN.
   A typical corporate installation will have many LAN switches and/or
   routing switches, which pass through multicast traffic but on the
   other hand do not support acting in the Router role of MLD/IGMP.
   Perhaps for case 2) and 3) above it is acceptable to add a MLD/IGMP
   capable router somewhere in the network, while for case 1) this may
   not be the case.




Rahman & Dijk           Expires November 17, 2011              [Page 22]


Internet-Draft        Group Communication for CoAP              May 2011


   [TBD: consider the influence of WiFi based backbone networks.  What
   if 6LBRs are at the same time also WiFi routers?  What if 6LBRs have
   an Ethernet connection to legacy WiFI routers?  Check if equivalent
   with Ethernet backbone.]


5.  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)
   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]



Rahman & Dijk           Expires November 17, 2011              [Page 23]


Internet-Draft        Group Communication for CoAP              May 2011


   and RPL [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).

   [ TBD: There was a suggestion from the Prague meeting to take a look
   at 802.1ae as it has a good architectural model for group key
   management. ]


6.  IANA Considerations

   This document makes no request of IANA.


7.  Conclusions

   Consider the proposals for group communication described in this
   draft for incorporation into the overall CoAP protocol specification.


8.  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.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, August 2002.




Rahman & Dijk           Expires November 17, 2011              [Page 24]


Internet-Draft        Group Communication for CoAP              May 2011


   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, August 2002.

   [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.

   [RFC4286]  Haberman, B. and J. Martin, "Multicast Router Discovery",
              RFC 4286, December 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.

9.2.  Informative References

   [I-D.cheshire-dnsext-dns-sd]
              Cheshire, S. and M. Krochmal, "DNS-Based Service



Rahman & Dijk           Expires November 17, 2011              [Page 25]


Internet-Draft        Group Communication for CoAP              May 2011


              Discovery", draft-cheshire-dnsext-dns-sd-10 (work in
              progress), February 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-6lowpan-nd]
              Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
              Discovery Optimization for Low-power and Lossy Networks",
              draft-ietf-6lowpan-nd-15 (work in progress),
              December 2010.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-06 (work in progress), May 2011.

   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-04 (work in progress),
              May 2011.

   [I-D.ietf-core-observe]
              Hartke, K. and Z. Shelby, "Observing Resources in CoAP",
              draft-ietf-core-observe-02 (work in progress), March 2011.

   [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-03 (work in progress),
              March 2011.

   [I-D.castellani-core-http-coap-mapping]
              Castellani, A. and S. Loreto, "Best Practice to map HTTP



Rahman & Dijk           Expires November 17, 2011              [Page 26]


Internet-Draft        Group Communication for CoAP              May 2011


              to COAP and viceversa",
              draft-castellani-core-http-coap-mapping-01 (work in
              progress), March 2011.

   [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-19 (work in
              progress), March 2011.

   [I-D.ietf-roll-trickle-mcast]
              Hui, J. and R. Kelsey, "Multicast Forwarding Using
              Trickle", draft-ietf-roll-trickle-mcast-00 (work in
              progress), April 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/
              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>.


Authors' Addresses

   Akbar Rahman (editor)
   InterDigital Communications, LLC

   Email: Akbar.Rahman@InterDigital.com


   Esko Dijk (editor)
   Philips Research

   Email: esko.dijk@philips.com







Rahman & Dijk           Expires November 17, 2011              [Page 27]