Subject: [core] group-comm comments

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Dec 2012 12:05:54 +0100

Hi Akbar and Esko,

I had promised to review, comment the group comm draft.
Below the commented text.

I have not gone very detailed with my comments. I hope that it is clear 
from  my comments that a reorganization of the draft and a review of the 
uses cases are necessary to get a clearer picture of the feasibility of 
group comm in the context of Coap.

Especialy difficult to understand for me were:

- the use case network configuration
- the forming and enabling of groups
- use of responses

Hope this helps.

Greetings,

peter

_____________________________________________________________________________________________________
Abstract

    CoAP is a RESTful transfer protocol for constrained devices.  It is
    anticipated that constrained devices will often naturally operate in
    groups (e.g. in a building automation scenario all lights in a given
    room may need to be switched on/off as a group).  This document
    defines how the CoAP protocol should be used in a group 
communication
    context.  An approach for using CoAP on top of IP multicast is
    detailed for both constrained and un-constrained networks.  Also,
    various use
/s causes /s cases/
    and corresponding protocol flows are provided to
    illustrate important concepts.  Finally, guidance is provided for
    deployment in various network topologies.

Status of this Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six 
months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on April 22, 2013.

Copyright Notice

    Copyright (c) 2012 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of

Rahman & Dijk            Expires April 22, 2013                 [Page 
1]

Internet-Draft        Group Communication for CoAP          October 
2012

    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
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

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

    This document assumes readers are familiar with the terms and
    concepts that are used in [I-D.ietf-core-coap].  In addition, this
    document defines the following terminology:

    Group Communication
       A source node sends a single message which is delivered to
       multiple destination nodes, where all destinations are identified
       to belong to a specific group.  The source node may
/remove or may not
       be
       part of the group.  The underlying mechanism for group
       communication is assumed to be multicast based.
/remove
	The network where
       the group communication takes place can be either a constrained 
or
       a regular (un-constrained) network/
/comment not sure about the meaning and consequences

    Multicast
       Sending a message to multiple destination nodes
/s simultaneously./
/s with one network invocation /

       There are various options to implement multicast including layer 
2
       (Media Access Control) or layer 3 (IP) mechanisms.

    IP Multicast
       A specific multicast 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].

    Low power and Lossy Network (LLN)
       Low power and Lossy Network (LLN): A type of constrained network
       where the devices are interconnected by a variety of low power,
       lossy links such as IEEE 802.15.4, Bluetooth,
<not so constrained> WiFi, wired </>
	or low
       power power-line communication links.

2.  Introduction

2.1.  Background

    The Constrained Application Protocol (CoAP) is an application
    protocol (analogous to HTTP) for resource constrained devices
    operating in an IP network [I-D.ietf-core-coap].  Constrained 
devices
    can be large in number, but are often highly correlated to each 
other
    (e.g. by type or location).  For example, all the light switches in 
a
    building may belong to one group and all the thermostats may belong
    to another group.  Groups may be composed by function.  For example,

Rahman & Dijk            Expires April 22, 2013                 [Page 
3]

Internet-Draft        Group Communication for CoAP          October 
2012

    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 preconfigured
/add before deployment
     or dynamically
    formed
/add during operation
   .  If information needs to be sent to or received from a group
    of devices, group communication mechanisms can improve efficiency 
and
    latency of communication and reduce bandwidth requirements for a
    given application.  HTTP does not support any equivalent
    functionality to CoAP group communication.

2.2.  Scope

    In this draft, we address the issues related to CoAP group
    communication in detail, with use cases, recommended approaches and
    analysis of the impact to the CoAP protocol and to implementations.
/add the use of group communication for mDNS is out of scope.
    The guiding principle is to apply wherever possible existing IETF
    protocols to achieve group communication functionality.  In many
    cases the contribution of this document lies in explaining how
    existing mechanisms may be used to
/remove together
    fulfill CoAP group
    communication needs for specific use cases.

2.3.  Potential Solutions for Group Communication

    The classic concept of group
/s communications /s communication
    is that of a single
    source distributing content to multiple destination recipients that
    are all part of a group.  Before content can be distributed, there 
is
    a separate process to form the group.  The source may be either a
    member or non-member of the group.

    Group communication solutions have evolved from "bottom" to "top",
    i.e., from layer 2 (Media Access Control broadcast/multicast) and
    layer 3 (IP multicast) to application layer group communication, 
also
    referred to as application layer multicast.  A study published in
    2005 [Lao05] identified new solutions in the "middle" (referred to 
as
    overlay multicast) that utilize an infrastructure based on proxies.

    Each of these classes of solutions may be compared [Lao05] using
    metrics such as link stress and level of host complexity
    [Banerjee01].  The results show for a realistic internet topology
    that IP Multicast is the most resource-efficient, with the downside
    being that it requires
/s the most /s more organizational
    effort to deploy in the
    infrastructure.  IP Multicast is the solution adopted by this draft
    for CoAP group communication.

3.  CoAP Group Communication Based On IP Multicast

Rahman & Dijk            Expires April 22, 2013                 [Page 
4]

Internet-Draft        Group Communication for CoAP          October 
2012

3.1.  IP Multicast Background

    IP Multicast routing 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 routing is not widely
    deployed on the general Internet.  However, IP Multicast is very
    popular in specific deployments such as in enterprise networks (e.g.
    for video conferencing), smart home networks (e.g.  UPnP/mDNS) and
    carrier IPTV deployments.  The packet economy and minimal host
    complexity of IP multicast make it attractive for group 
communication
    in constrained environments.  Therefore IP multicast is the
    recommended underlying mechanism for CoAP group communication, and
    the approach assumed in this document.

    To achieve IP multicast beyond a subnet, an IP multicast routing
    protocol needs to be active on routers.  The RPL protocol [RFC6550]
    for example is able to route multicast traffic in constrained LLNs.
    While PIM-SM [RFC4601] is often used for multicast routing in un-
    constrained networks.

    IP multicast can also be run in a Link-Local (LL) scope.  This means
    that there is no routing involved and an IP multicast message is 
only
    received
/s on the network /s over the
     link on which it was sent.

3.2.  CoAP Group Definition and Naming

    A group is defined as a set of CoAP endpoints, where each endpoint 
is
    configured to receive a multicast CoAP request that is sent to the
    group's associated IP multicast address.  The group MAY have more
    than one associated IP multicast address.  An endpoint MAY be a
    member of multiple groups.  Group membership of an endpoint MAY
    dynamically change over time.  The group MAY be identified by a 
Group
    Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string
    of a Group FQDN.  The Group FQDN can be uniquely mapped to a site-
    local or global multicast IP address via DNS resolution.

    A CoAP multicast request that addresses a group includes a Group URI
    as the request URI.  A Group URI has the scheme 'coap' and includes
    in the authority part either a group IP address
/add + optional port
     or a hostname
/add + optional port
    that
    can be resolved to the group IP address (e.g., a Group Name or Group
    FQDN).  Group URIs MUST follow the URI syntax [RFC3986].

    A CoAP
/s node /s end-point
    becomes a group member by listening for CoAP messages on
    the group's IP multicast address, assuming the default CoAP UDP 
port.
    Note that a non-default UDP port MAY be specified for the group; in
    which case implementers MUST ensure that all group members are
    configured to use this same port.

Rahman & Dijk            Expires April 22, 2013                 [Page 
5]

Internet-Draft        Group Communication for CoAP          October 
2012

    Examples of hierarchical group naming (and scoping) for a building
    control application are shown below.

      URI authority                  Targeted group
      all.bldg6.example.com          "all nodes in building 6"
      all.west.bldg6.example.com     "all nodes in west wing, building 
6"
      all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing,
                                      building 6"
      all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1,
                                      west wing, building 6"

    Reverse mapping (from IP multicast address to group FQDN) is
    supported using the reverse DNS resolution technique
    ([I-D.vanderstok-core-dna]).

3.3.  Group Discovery and Member Discovery

    CoAP defines a resource discovery capability, but does not yet
    specify how to discover groups (e.g. find a group to join or send a
    multicast message to) or to discover members of a group (e.g. to
    address selected group members by unicast).  These topics are
    elaborated in more detail in [I-D.vanderstok-core-dna] including
    examples for using DNS-SD and CoRE Resource Directory.

3.3.1.  DNS-SD

    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 and/or a PTR 
record
    with the name _coap._udp.<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.

Rahman & Dijk            Expires April 22, 2013                 [Page 
6]

Internet-Draft        Group Communication for CoAP          October 
2012

    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.2.  CoRE Resource Directory

    CoRE Resource Directory [I-D.shelby-core-resource-directory] defines
    the concept of a Resource Directory (RD) server where CoAP servers
    can register their resources offered and CoAP clients can discover
    these resources by querying the RD server.  RD syntax can be mapped
    to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping],
    such that the above approach can be reused for group discovery and
    group member discovery.

  /remove  Specifically, the Domain (d) parameter can be set to the 
group URI by
    an end-point registering to the RD.  If an end-point wants to join
    multiple groups, it has to repeat the registration process for each
    group it wants to join.
/end remove
/comment d parameter semantics not clear

3.4.  Group Resource Manipulation

    Group communications SHALL only be used for idempotent methods (i.e.
    CoAP GET, PUT, DELETE).  The CoAP messages that are sent via
    multicast SHALL be Non-Confirmable.

    A unicast response per server MAY be sent back to answer the group
    request (e.g. response "2.05 Content" to a group GET request) taking
    into account the congestion control rules defined in
    [I-D.ietf-core-coap].  The unicast responses may be a mixture of
    success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes
    depending on the individual server processing result.

    Group communications SHALL NOT be used for non-idempotent methods
    (i.e.  CoAP POST).  This is because not all group members are
    guaranteed to receive the multicast request, and the sender can not
    readily find out which group members did not receive it.

    All nodes in a given group SHOULD receive the same request
/remove with high probability.
/comment I don't see where probability comes in.
    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.

    Therefore, some measures must be present to ensure uniformity in 
port
    number and resource names/locations within a group.  This document
    proposes the following measures:

Rahman & Dijk            Expires April 22, 2013                 [Page 
7]

Internet-Draft        Group Communication for CoAP          October 
2012

    o  All CoAP multicast requests MUST be sent either to the default
       CoAP UDP port (i.e. default Uri-Port as defined in
       [I-D.ietf-core-coap]), or to a port number obtained via a service
       discovery lookup operation as a valid CoAP port for the targeted
       multicast group.

    o  All CoAP multicast requests SHOULD operate only on URIs (links)
       which were
/s retreived /s retrieved
       either from a "/.well-known/core" lookup on
       at least one group member node, or from an equivalent service
       discovery lookup which returns either the resources supported by
       all group members or resources supported by one particular group
       member.
/comment so setting a multicast address in a source at installation is 
forbidden?

3.5.  Configuring Group Membership In Endpoints

    In some use cases, the group membership of endpoints needs to be
    configurable after the network has been deployed.  Example use cases
    can be found in building control: a commissioning tool determines to
    which groups a light or sensor node belongs, and writes this
    information to all nodes, which can subsequently join the correct
    group.

    To achieve smoother interoperability between nodes/endpoints from
    different manufacturers, it is proposed here to define an OPTIONAL
    standardized RESTful means of configuring CoAP endpoints with
    relevant group information.

    CoAP endpoints implementing this mechanism MUST support a
    discoverable "Group Configuration" resource of resource type (rt)
    [RFC6690] "core.gp".  This resource (and perhaps its sub-resources,
    TBD) are used to manage group membership.  Three design options for
    this mechanism are presented here as a placeholder (TBD).

    Design 1: use CoRE link format payloads to communicate group
    membership to endpoints.  (TBD Not clear how this should be
    realized.)
/comment, not clear what you mean either. Remove design 1 in this state

    Design 2: use a JSON type resource.  For example, a GET on the
    "core.gp" resource returns a JSON array of group objects.

       Req: GET /gp
       Res: 2.05 Content (Content-Format: application/json)
       [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com",
           "ip": "ff05::4200:f7fe:ed37:14ca" }
       ]

    where "n" defines the Group FQDN and "ip" defines the associated
    multicast IP address.  As a next example, the same endpoint can be

Rahman & Dijk            Expires April 22, 2013                 [Page 
8]

Internet-Draft        Group Communication for CoAP          October 
2012

    added to another group by a POST on the resource with a JSON group
    object:

       Req: POST /gp (Content-Format: application/json)
       { "n": "floor1.west.bldg6.example.com",
         "ip": "ff05::4200:f7fe:ed37:14cb" }
       Res: 2.04 Changed

    Design 3: define named sub-resources, each sub-resource representing
    a group membership.  The payload of the sub-resource may be JSON or 
a
    simple pre-defined format.  Or alternatively, information is 
provided
    via POST with query parameters.

/comment are these mutually exclusive designs?
/comment design 2 without JSON is als possible
/comment design with SRV and TXt records is also possible
/comment there are 2 ways: (1) the node queries to which group it 
belongs
/comment  (2) an instalation tools instructs the node to which groups 
it belongs
/comment not clear in text that this choice exists or that a choice was 
made.

3.6.  Congestion Control

    Multicast CoAP requests may result in a multitude of replies from
    different nodes, potentially causing congestion.  Therefore sending
    multicast
/s requests /s replies
     should be conservatively controlled.

    The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific
    congestion risks through the following measures:

    o  A server MAY choose not to respond to a multicast request if
       there's nothing useful to respond (e.g. error or empty response).

    o  A server SHOULD limit the support for multicast requests to
       specific resources where multicast operation is required.

    o  A multicast request MUST be Non-Confirmable.
/comment what about the reply?

    o  A server does not respond immediately to a multicast request, but
       SHOULD first wait for a time that is randomly picked within a
       predetermined time interval called the Leisure.

    o  A server SHOULD NOT accept multicast requests that can not be
       authenticated.
/comment invoking as many certificates?

    Additional guidelines to reduce congestion risks are:

    o  A server in an LLN should only support multicast GET for 
resources
       that are small, e.g.
/remove for an LLN that could mean
       the payload of the
       response fits into a single link-layer frame.

    o  A server can minimize the payload length in response to a
       multicast GET on "/.well-known/core" by using hierarchy in
       arranging link descriptions for the response.  An example of this
       is given in Section 5 of [RFC6690].

Rahman & Dijk            Expires April 22, 2013                 [Page 
9]

Internet-Draft        Group Communication for CoAP          October 
2012

    o  Preferably IP multicast with link-local scope should be used,
       rather than global or site-local.

    o  The Hop Limit field in the IPv6 packet should be chosen as low as
       possible (if the CoAP/IP stack allows setting of this value.  TBD
       - discuss whether this guideline is relevant/realistic in CoAP
       context)

3.7.  CoAP Multicast and HTTP Unicast Interworking

/comment a reference will suffice

    CoAP supports operation over UDP multicast, while HTTP does not.  
For
    use cases where it is required that CoAP group communication is
    initiated from an HTTP end-point, it would be advantageous if the
    HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group
    communication based on IP multicast.
/remove One possible way of operation
/remove    of such HTTP-CoAP Proxy is illustrated in Figure 1.
    Note that this
    topic is covered in more detail in
    [I-D.castellani-core-advanced-http-mapping].

/remove

            CoAP    Mcast    CoAP    Mcast   HTTP-CoAP           HTTP
           Node 1   Rtr1    Node 2    Rtr2    Proxy             Node 3
             |       |         |       |       |                   |
             |MLD REQUEST      |       |       |                   |
             |(Join Group X)   |       |       |                   |
             |--LL-->|         |       |       |                   |
             |       |         |MLD REQUEST    |                   |
             |       |         |(Join Group X) |                   |
             |       |         |--LL-->|       |                   |
             |       |         |       |       |  HTTP REQUEST     |
             |       |         |       |       |    (URI to        |
             |       |         |       |       |   unicast addr)   |
             |       |         |       |       |< -----------------|
             |       |         |       |       |                   |
             |       |         |   Resolve HTTP Request-Line URI   |
             |       |         |   to Group X multicast address    |
             |       |         |       |       |                   |
             | CoAP REQUEST (to multicast addr)|                   |
             |< ------<---------<-------<------|                   |
             |       |         |       |       |                   |
             |                 |               |                   |
             |     (optional) CoAP RESPONSE(s) |                   |
             |                 |-------------->|                   |
             |-----------------|-------------->|   Aggregated      |
             |                 |               |  HTTP RESPONSE    |
             |                 |               |------------------>|
             |                 |               |                   |

Rahman & Dijk            Expires April 22, 2013                [Page 
10]

Internet-Draft        Group Communication for CoAP          October 
2012

           Figure 1: CoAP Multicast and HTTP Unicast Interworking

    Note that Figure 1 illustrates the case of IP multicast as the
    underlying group communications mechanism.  MLD denotes the 
Multicast
    Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a
    Link-Local multicast.

    A key point in Figure 1 is that the incoming HTTP Request (from node
    3) will carry a Host request-header field that resolves in the
    general Internet to the proxy node.  At the proxy node, this 
hostname
    and/or the Request-Line URI will then possibly be mapped (as 
detailed
    in [I-D.castellani-core-http-mapping]) and again resolved (with the
    CoAP scheme) to an IP multicast address.  This may be accomplished,
    for example, by using DNS or DNS-SD (Section 3.3).  The proxy node
    will then IP multicast the CoAP Request (corresponding to the
    received HTTP Request) via multicast routers to the appropriate 
nodes
    (i.e. nodes 1 and 2).

    In terms of the HTTP Response, Figure 1 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-advanced-http-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 is carried in the HTTP Request-Line (as defined
    in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the
    IP address of the Proxy.

/end remove

4.  Use Cases and Corresponding Protocol Flows

4.1.  Introduction

    The use of CoAP group communication is shown in the context of the
    following use cases and corresponding protocol flows:

    o  Discovery of Resource Directory: discovering the local CoRE RD
       which contains links (URIs) to resources stored on other servers
       [RFC6690].

Rahman & Dijk            Expires April 22, 2013                [Page 
11]

Internet-Draft        Group Communication for CoAP          October 
2012

    o  Lighting Control: synchronous operation of a group of 6LoWPAN
       [RFC4944] IPv6-connected lights

    o  Parameter Update: updating parameters/settings simultaneously in 
a
       large group of devices in a building/campus control
       ([I-D.vanderstok-core-bc]) application --- TBD

/ comment I suggest to remove Firmware Update and Groups status report
/comment the ones above are difficult enough, and I doubt that 
simultaneity
/comment (motivation of multicast) is involved here

    o  Firmware Update: efficiently updating firmware simultaneously in 
a
       large group of devices in a building/campus control
       ([I-D.vanderstok-core-bc]) application --- TBD suggests a
       multicast extension of core-block.

    o  Group Status Report: requesting status information or event
       reports from a group of devices in a building/campus control
       application --- TBD, may require reliable group communication to
       be feasible.

4.2.  Network Configuration

    We assume the following network configuration for all the use cases
    as shown in Figure 2:
/comment the configurations frighten me
/comment from completeness considerations I can imagine even more 
complex ones
/comment It might be useful if the practical impossibility of some 
configurations is high lighted

    o  A large room (Room-A) with three lights (Light-1, Light-2,
       Light-3) controlled by a Light Switch.  The devices are organized
       into two 6LoWPAN subnets.
/comment one subnet is enough for me

/remove

    o  Light-1 and the Light Switch are connected to a router (Rtr-1)
       which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a
       6LoWPAN Border Router (6LBR).

    o  Light-2 and the Light-3 are connected to another router (Rtr-2)
       which is also a CoAP Proxy, a CoAP RD and a 6LBR.

    o  The routers are connected to an IPv6 network backbone which is
       also multicast enabled.  In the general case, this means the
       network backbone and 6LBRs support a PIM based multicast routing
       protocol, and MLD for forming groups.  In a limited case, if the
       network backbone is one link, then the routers only have to
       support MLD-snooping (Appendix A) for the following use cases to
       work.

/end remove

/comment I can imagine that an central control is present on the 
backbone
/comment switch or sensor send unicast to central control
/comment central control sends multicast to multicast group within 
single lowpan

Rahman & Dijk            Expires April 22, 2013                [Page 
12]

Internet-Draft        Group Communication for CoAP          October 
2012

Network
                                                                 
Backbone
                                                                        
|
       ################################################                 
|
       #                                       Room-A #                 
|
       #         **********************               #                 
|
       #       **  LoWPAN-1 (subnet-1) **             #                 
|
       #     *                            *           #                 
|
       #    *     +----------+             *          #                 
|
       #   *      |  Light   |-------+      *         #                 
|
       #  *       |  Switch  |       |       *        #                 
|
       #  *       +----------+  +---------+  *        #                 
|
       #  *                     |  Rtr-1  
|-----------------------------|
       #  *                     +---------+  *        #                 
|
       #  *       +----------+        |      *        #                 
|
       #   *      |  Light-1 |--------+     *         #                 
|
       #    *     +----------+             *          #                 
|
       #     *                            *           #                 
|
       #       **                      **             #                 
|
       #         **********************               #                 
|
       #                                              #                 
|
       #                                              #                 
|
       #        **********************                #                 
|
       #       **  LoWPAN-2 (subnet-2) **             #                 
|
       #     *                            *           #                 
|
       #    *     +----------+             *          #                 
|
       #   *      |  Light-2 |-------+      *         #                 
|
       #  *       |          |       |       *        #                 
|
       #  *       +----------+  +---------+  *        #                 
|
       #  *                     |  Rtr-2  
|-----------------------------|
       #  *                     +---------+  *        #                 
|
       #  *       +----------+        |      *        #                 
|
       #   *      |  Light-3 |--------+     *         #                 
|
       #    *     +----------+             *          #                 
|
       #     *                            *           #                 
|
       #       **                      **             #                 
|
       #         **********************               #                 
|
       #                                              #                 
|
      #################################################                 
|
                                                                        
|
                                            +--------+                  
|
                                            |  DNS   
|------------------|
                                            | Server |
                                            +--------+

             Figure 2: Network Topology of a Large Room (Room-A)

Rahman & Dijk            Expires April 22, 2013                [Page 
13]

Internet-Draft        Group Communication for CoAP          October 
2012

4.3.  Discovery of Resource Directory

    The protocol flow for discovery of a RD for the given network (of
    Figure 2) is shown in Figure 3:

    o  The fixture for Light-2 is installed and powered on for the first
       time.

    o  Light-2 will then search for the local RD (RD-2) by sending out a
       GET request (with the "/.well-known/core?rt=core.rd" request URI)
       to the site-local "All CoAP Nodes" address.  In this case, the
       site is assumed to include all nodes in the subnet.

    o  This multicast message will then go to each node in subnet-2.
       However, only Rtr-2 (RD-2) will respond because the GET is
       qualified by the query string "?rt=core.rd".

    o  Note that the flow is shown only for Light-2 for clarity.  
Similar
       flows will happen for Light-1, Light-3 and the Light Switch when
       they are first powered on.

    The RD may also be discovered by other means such as by assuming a
    default location (e.g. on a 6LBR), using DHCP, anycast address, etc.
    However, these approaches do not invoke CoAP group communication so
    are not further discussed here.

    For other discovery use cases such as discovering local CoAP 
servers,
    services or resources group communication can be used in a similar
    fashion as in the above use case.  Both Link-Local (LL) and site-
    local discovery are possible this way.

/comment the RD discovery will be more complex when there is a router 
between light-2 and switch
/comment Via which RD will light switch discover light-2?
/comment additional reason to remove router from the multicast 
configuration

Rahman & Dijk            Expires April 22, 2013                [Page 
14]

Internet-Draft        Group Communication for CoAP          October 
2012

                                     Light      Rtr-1     Rtr-2   
Network
    Light-1   Light-2    Light-3     Switch    (RD-1)    (RD-2)  
Backbone
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     **********************************          |          |          |
     *   Light-2 is installed         *          |          |          |
     *   and powers on for first time *          |          |          |
     **********************************          |          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          | COAP NON (GET                             |          |
     |          |           /.well-known/core?rt=core.rd)   |          |
     |          |--------->-------------------------------->|          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          | COAP NON (2.05 Content                    |          |
     |          |         </rd>;rt="core.rd";ins="Primary") |          |
     |          |<------------------------------------------|          |
     |          |          |          |          |          |          |

        Figure 3: Resource Directory Discovery via Multicast Message

4.4.  Lighting Control

/comment I am confused about the use of protocols
/comment MLD is used to form groups, correct?
/comment but that was already done by enabling the MC address in the 
lights (point 2)
/comment There are several ways to set up groups, pointing them out and 
when to use them would be an asset.

    The protocol flow for a building automation lighting control 
scenario
    for the network (Figure 2) is shown in sequence in Figure 4,
    Figure 5, and Figure 6.  We assume the following steps occur before
    the illustrated flow:

    o  1) Startup phase: 6LoWPANs are formed.  IPv6 addresses assigned 
to
       all devices.  The CoAP network is formed.

    o  2) Commissioning phase (by applications): The IP multicast 
address
       of the group (Room-A-Lights) has been
/s set /s enable
       in all the Lights.  The
       URI of the group (Room-A-Lights) has been
/s set /s resolved
       in the Light Switch.

    o  3) The indicated MLD Report messages are link-local multicast.  
In
       each LoWPAN, it is assumed that a multicast routing/forwarding
       protocol in 6LRs will then propagate the Join information
       contained in the MLD Report over multiple hops to the 6LBR.

/comment Don't see the need

Rahman & Dijk            Expires April 22, 2013                [Page 
15]

Internet-Draft        Group Communication for CoAP          October 
2012

                                     Light      Rtr-1     Rtr-2   
Network
    Light-1   Light-2    Light-3     Switch    (CoAP     (CoAP   
Backbone
     |          |          |          |         Proxy)    Proxy)       |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     | MLD Report: Join    |          |          |          |          |
     | Group (Room-A-Lights)          |          |          |          |
     |---LL------------------------------------->|          |          |
     |          |          |          |          |MLD Report: Join     |
     |          |          |          |          |Group (Room-A-Lights)|
     |          |          |          |          |---LL--------------->|
     |          |          |          |          |          |          |
     |          | MLD Report: Join    |          |          |          |
     |          | Group (Room-A-Lights)          |          |          |
     |          |---LL------------------------------------->|          |
     |          |          |          |          |          |          |
     |          |          | MLD Report: Join    |          |          |
     |          |          | Group (Room-A-Lights)          |          |
     |          |          |---LL-------------------------->|          |
     |          |          |          |          |          |          |
     |          |          |          |          |MLD Report: Join     |
     |          |          |          |          |Group (Room-A-Lights)|
     |          |          |          |          |          |---LL---->|
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |

                 Figure 4: Joining Lighting Groups Using MLD

/comment possibly remove from text, or do separate section on use of 
MLD
/comment anyway separating commissioning from operation in separate 
sections is a good idea.

/comment the proxies are a complication in the picture not elaborated 
in the text.
/comment the subject of proxies is another one, to be treated 
elsewhere.
/comment also for proxies the do's and don't's from a simple 
performance perspective will be interesting

Rahman & Dijk            Expires April 22, 2013                [Page 
16]

Internet-Draft        Group Communication for CoAP          October 
2012

                                     Light      Rtr-1     Rtr-2   
Network
    Light-1   Light-2    Light-3     Switch    (CoAP     (CoAP   
Backbone
     |          |          |          |         Proxy)    Proxy)       |
     |          |          |          |          |          |          |
     |          |          ***********************          |          |
     |          |          *   User flips on     *          |          |
     |          |          *   light switch to   *          |          |
     |          |          *   turn on all the   *          |          |
     |          |          *   lights in Room A  *          |          |
     |          |          ***********************          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          |          | COAP NON (PUT       |          |          |
     |          |          |           Proxy-URI |          |          |
     |          |          |           URI for Room-A-Lights           |
     |          |          |           Payload=turn on lights)         |
     |          |          |          |--------->|          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          |          |          |     Request DNS resolution of  |
     |          |          |          |     URI for Room-A-Lights      |
     |          |          |          |          |-------------------->|
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          |          |          |     DNS returns: AAAA          |
     |          |          |          |     Group (Room-A-Lights)      |
     |          |          |          |     IPv6 multicast address     |
     |          |          |          |          |<--------------------|
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          |          |          COAP NON (Put                    |
     |          |          |          |         URI Path               |
     |          |          |          |         Payload=turn on lights)|
     |          |          |          |    Destination IP Address =    |
     |          |          |          |       IP multicast address     |
     |          |          |          |       for Group (Room-A-Lights)|
     |          |          |          |    Originating IP Address =    |
     |          |          |          |        RTR-1                   |
     |          |          |          |          |-------------------->|
     |<------------------------------------------|          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |<---------|
     |          |<---------|<-------------------------------|          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |

            Figure 5: Sending Lighting Control Multicast Message

Rahman & Dijk            Expires April 22, 2013                [Page 
17]

Internet-Draft        Group Communication for CoAP          October 
2012

                                     Light      Rtr-1     Rtr-2   
Network
    Light-1   Light-2    Light-3     Switch    (CoAP     (CoAP   
Backbone
     |          |          |          |         Proxy)    Proxy)       |
     |          |          |          |          |          |          |
     ***********************          |          |          |          |
     *   Lights in Room-A  *          |          |          |          |
     *   turn on (nearly   *          |          |          |          |
     *   simultaneously)   *          |          |          |          |
     ***********************          |          |          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |     COAP NON (2.04 Changed)    |          |          |          |
     |------------------------------------------>|          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          COAP NON (2.04 Changed)          |          |          |
     |          |------------------------------->|          |          |
     |          |          |          |          |          |          |
     |          |          |          |          |          |          |
     |          |        COAP NON (5.00 Internal Server Error)         |
     |          |          |-------------------->|          |          |
     |          |          |          |          |          |          |
     |          |          |          ******************************   |
     |          |          |          *      Rtr-1 as CoAP Proxy   *   |
     |          |          |          *  |   sends the individual  *   |
     |          |          |          *  |   responses back to     *   |
     |          |          |          *  v   originator            *   |
     |          |          |          ******************************   |
     |          |          |          |          |          |          |
     |          |          |    COAP NON (2.04 Changed)     |          |
     |          |          |          |<---------|          |          |
     |          |          |          |          |          |          |
     |          |          |    COAP NON (2.04 Changed)     |          |
     |          |          |          |<---------|          |          |
     |          |          |          |          |          |          |
     |          |          |    COAP NON (5.00 Internal Server Error)  |
     |          |          |          |<---------|          |          |
     |          |          |          |          |          |          |

      Figure 6: Sending Lighting Control Response to Multicast Message

    NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy,
    returns multiple individual CoAP responses to the client.  Each
    response echoes the Token of the client's request.  The client can
    identify the original source of each response by ...TBD.

/comment WHY are the multicast destinations sending back results?
/comment I thought that you wanted MC messages to be non confirmable
/comment sending responses seems to contradict this .
/comment please remove sending back of responses.
/comment one may assume that the MC algorithm within the lowpan is 
reliable (all destinations receive the message)
/comment anyway MPL comes close enough to the reliability requirement 
given a specifiable range of configurations

___________________________________________________________________________________________________________________________
-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 19 Dec 2012 13:24:42 +0000

Hi Peter,

still a fair number of comments! I would agree with most. Below I have selected some which we should discuss further, or ones I don’t agree with:

1.  Group communication definition ->
Why can't a source node be part of the group that it sends to? E.g. combined sensor+luminaire use case. The IP stack would deliver sent multicast CoAP requests also to the local application if it is subscribed to the multicast IP address.

2.  I don’t see why we should add “the use of group communication for mDNS is out of scope.” ->
mDNS obviously is not CoAP, and the document should define the scope anyway clearly as CoAP group communication. So we don’t have to list any other protocols than CoAP.

3.  “so setting a multicast address in a source at installation is forbidden?” ->
No, that should not be forbidden :)  It should also be possible to set a CoAP path and/or port at installation time. That means the two presented measures have to change or be removed.

4.  “there are 2 ways: (1) the node queries to which group it belongs or (2) an instalation tools instructs the node to which groups” ->
Good point. (2) has been chosen because it works without relying on a service to query (e.g. DNS or RD). Is that sufficient argumentation? The mechanism is optional in any case so it does not block others from defining a DNS or RD variant.

5.  “/s requests /s replies” ->
multicast replies (if you mean responses) do not exist in CoAP. It’s about requests that should be carefully controlled since they generate unicast responses.

6.  “/comment what about the reply?” ->
based on core-coap “If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well.” . Do you think we should quote this from the core-coap spec?

7.  “/comment invoking as many certificates?” ->
core-coap-13 now loosens the concept of authentication to also include other measures, not needing certificates.

8.  Network configuration: 2 subnets vs 1 ->
maybe a one-subnet configuration is worth adding?  Here an overview of present/absent use cases:

- Link-local CoAP multicast with responses: Present, Appendix A of core-coap
- Site-local CoAP multicast, single subnet: <missing>
- Site-local CoAP multicast, multi subnet, with or without responses (in the new -04 groupcomm): Present
- Global     CoAP multicast, single or multi subnet, with or without responses: <missing> / dependency on IANA IPv6 allocation
- any configurations with a central controller on the backbone multicasting: <missing>

9.  “It might be useful if the practical impossibility of some configurations is high lighted” ->
any thoughts, which would be impossible?

10.“the RD discovery will be more complex when there is a router between light-2 and switch” ->
yes, there are issues in RD/discovery especially when more than one is present in a network.

11.“additional reason to remove router from the multicast configuration”->
hmm, I think that we should opt for having a single RD in the system to avoid complexity. Routers are ok. (One of our goals is to define how CoAP groupcomm works even across routers)

12.“MLD is used to form groups, correct? but that was already done by enabling the MC address in the lights (point 2)” ->
Step 1 is putting the MC address in the lights, then step 2 is the Lights use MLD to *advertize* this address to any MLD-enabled Routers present link-local.
So MLD is not a commissioning-time protocol but runs all the time during operation.
Note that in groupcomm -04 we will remove MLD in the basic use case and present it as an option later.

13.“WHY are the multicast destinations sending back results?” ->
we remove responses in the new -04 groupcomm. They are presented as an optional thing that servers can do.
CoAP servers normally MUST respond to a request with a response (core-coap-13) but an exception is now made for multicast where a server MAY choose not to. This choice is completely independent from confirmable/non-confirmable. Non-confirmable only means that an ACK must not be sent. And an ACK is something different from a CoAP response.
Agree that a protocol like MPL comes very close to ‘reliable multicast’.

Esko

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: Tuesday 18 December 2012 12:06
To: akbar rahman; Dijk, Esko; Core
Subject: group-comm comments

Hi Akbar and Esko,

I have not gone very detailed with my comments. I hope that it is clear from  my comments that a reorganization of the draft and a review of the uses cases are necessary to get a clearer picture of the feasibility of group comm in the context of Coap.

- use of responses

Hope this helps.

Greetings,

peter

Abstract

    defines how the CoAP protocol should be used in a group communication

    various use

/s causes /s cases/

Status of this Memo

    Internet-Drafts are draft documents valid for a maximum of six months

Copyright Notice

1]

2012

    carefully, as they describe your rights and restrictions with respect

    Group Communication

/remove or may not

       be

/remove

      The network where

or

    Multicast

/s simultaneously./

2

    IP Multicast

       Architecture" [RFC4291].

      or low

2.  Introduction

2.1.  Background

devices

other

a

3]

2012

"all

/add before deployment

     or dynamically

    formed

/add during operation

and

2.2.  Scope

/remove together

    fulfill CoAP group

    is that of a single

is

also

as

    being that it requires

    effort to deploy in the

4]

2012

communication

    constrained networks.

only

    received

is

Group

/add + optional port

     or a hostname

/add + optional port

    that

    A CoAP

/s node /s end-point

port.

5]

2012

6"

                                      building 6"

                                      west wing, building 6"

3.3.1.  DNS-SD

enable

end-point

record

as

6]

2012

    group member discovery.

group URI by

    group it wants to join.

/end remove

the

    different nodes.

port

7]

2012

       multicast group.

       which were

       member.

forbidden?

    group.

    realized.)

       Req: GET /gp

       ]

8]

2012

    object:

       Res: 2.04 Changed

a

provided

belongs

it belongs

made.

3.6.  Congestion Control

    multicast

/s requests /s replies

       authenticated.

resources

       that are small, e.g.

       the payload of the

9]

2012

       context)

For

    Note that this

/remove

             |       |         |       |       |                   |

             |MLD REQUEST      |       |       |                   |

             |(Join Group X)   |       |       |                   |

             |--LL-->|         |       |       |                   |

             |       |         |MLD REQUEST    |                   |

             |       |         |(Join Group X) |                   |

             |       |         |--LL-->|       |                   |

             |       |         |       |       |  HTTP REQUEST     |

             |       |         |       |       |    (URI to        |

             |       |         |       |       |                   |

             |       |         |       |       |                   |

             |       |         |       |       |                   |

             |                 |               |                   |

             |                 |-------------->|                   |

             |                 |               |  HTTP RESPONSE    |

             |                 |               |                   |

10]

2012

Multicast

    Link-Local multicast.

hostname

detailed

nodes

    (i.e. nodes 1 and 2).

CoAP

can

[RFC2616].

    filtering."

    IP address of the Proxy.

/end remove

4.1.  Introduction

       [RFC6690].

11]

2012

a

simultaneity

a

       be feasible.

    as shown in Figure 2:

complex ones

/remove

       work.

/end remove

backbone

single lowpan

12]

2012

Network

Backbone

|

|

       #                                       Room-A #

|

|

|

       #     *                            *           #

|

       #    *     +----------+             *          #

|

|

       #  *       |  Switch  |       |       *        #

|

|

       #  *                     |  Rtr-1

       #  *                     +---------+  *        #

|

       #  *       +----------+        |      *        #

|

|

       #    *     +----------+             *          #

|

       #     *                            *           #

|

       #       **                      **             #

|

|

       #                                              #

|

       #                                              #

|

|

|

       #     *                            *           #

|

       #    *     +----------+             *          #

|

|

       #  *       |          |       |       *        #

|

|

       #  *                     |  Rtr-2

       #  *                     +---------+  *        #

|

       #  *       +----------+        |      *        #

|

|

       #    *     +----------+             *          #

|

       #     *                            *           #

|

       #       **                      **             #

|

|

       #                                              #

|

|

|

                                            +--------+

|

                                            |  DNS

|------------------|

                                            | Server |

                                            +--------+

13]

2012

       time.

Similar

servers,

configuration

14]

2012

                                     Light      Rtr-1     Rtr-2

Network

Backbone

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          | COAP NON (GET                             |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

4.4.  Lighting Control

lights (point 2)

scenario

    the illustrated flow:

to

address

/s set /s enable

       in all the Lights.  The

/s set /s resolved

       in the Light Switch.

In

15]

2012

                                     Light      Rtr-1     Rtr-2

Network

Backbone

     |          |          |          |         Proxy)    Proxy)       |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |---LL---->|

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

MLD

sections is a good idea.

in the text.

elsewhere.

16]

2012

                                     Light      Rtr-1     Rtr-2

Network

Backbone

     |          |          |          |         Proxy)    Proxy)       |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |           Proxy-URI |          |          |

     |          |          |          |--------->|          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

    |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          COAP NON (Put                    |

     |          |          |          |         URI Path               |

     |          |          |          |        RTR-1                   |

     |          |          |          |          |          |          |

     |          |          |          |          |          |<---------|

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

17]

2012

                                     Light      Rtr-1     Rtr-2

Network

Backbone

     |          |          |          |         Proxy)    Proxy)       |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          |          |          |          |

     |          |          |          *  v   originator            *   |

     |          |          |          |          |          |          |

     |          |          |          |<---------|          |          |

     |          |          |          |          |          |          |

     |          |          |          |<---------|          |          |

     |          |          |          |          |          |          |

     |          |          |          |<---------|          |          |

     |          |          |          |          |          |          |

--

Peter van der Stok

mailto: [email-masked]<mailto:[email-masked]>

www: www.vanderstok.org<http://www.vanderstok.org>

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: peter van der Stok <[email-masked]>
Date: Thu, 20 Dec 2012 11:26:25 +0100

Hi Esko,

thanks for your reactions. I will group my answers, to better explain 
my points on the return of packets to MC senders.

1) Return of packets to multicast

As I understand the multicast message is preferably sent with no 
confirmation (ack) because the return of all the acks may overwhelm the 
network and the sender of the multicast.
The acknowledgement is not needed for MPL as the protocol has all the 
machinery to assure that all destinations receive it,
(given constraints on network load and configuration density and size).

Supposing an ack is needed, then it would be advisable to staffle the 
responses and an additional acknowledgement protocol could be added to 
the multicast protocol. The same is true if a message is returned (as in 
the case of mDNS).

One can then wonder whether the application protocol (e.g. mDNS) should 
take care of the staffled response or that an additional protocol needs 
to be specified.
I have no opinion on the choice, but see the need for the one or the 
other. Coming with a recommendation (explanation) on the subject of 
returning responses (acks) would be my recommendation for the GroupComm 
document.

Below some reactions on your reactions. Hope this helps to clarify 
misunderstandings.

Peter

Dijk, Esko schreef op 2012-12-19 14:24:
> Hi Peter,
> 
> still a fair number of comments! I would agree with most. Below I
> have selected some which we should discuss further, or ones I don’t
> agree with:
> 
>  Why can't a source node be part of the group that it sends to? E.g.
> combined sensor+luminaire use case. The IP stack would deliver sent
> multicast CoAP requests also to the local application if it is
> subscribed to the multicast IP address.
source can of course be member of destination group.
source may be part of the group (remove the "or may be not" part of the 
phrase)
>  mDNS obviously is not CoAP, and the document should define the scope
> anyway clearly as CoAP group communication. So we don’t have to list
> any other protocols than CoAP.
See my answer on return of packets. I wanted a clear statement on (NOT) 
specifying how applications handle the return of MC responses.

>  No, that should not be forbidden :) It should also be possible to
> set a CoAP path and/or port at installation time. That means the two
> presented measures have to change or be removed.
No comment
> 
> 4. “there are 2 ways: (1) the node queries to which group it belongs
> or (2) an instalation tools instructs the node to which groups” ->
>  Good point. (2) has been chosen because it works without relying on
> a service to query (e.g. DNS or RD). Is that sufficient argumentation?
> The mechanism is optional in any case so it does not block others from
> defining a DNS or RD variant.
I would point out both variants and mention that the draft focusses on 
(2)
>  multicast replies (if you mean responses) do not exist in CoAP. It’s
> about requests that should be carefully controlled since they generate
> unicast responses.
Then I do not understand the text, because "request", "reply" and 
"response" are overloaded in my mind.
>  based on core-coap “If the request message is Non-confirmable, then
> the response SHOULD be returned in a Non-confirmable message as well.”
> . Do you think we should quote this from the core-coap spec?
As explained above The subject of returning packets to the MC sender 
needs careful consideration.
the response being NOn-confirmable does not solve a lot I am afraid.
>  core-coap-13 now loosens the concept of authentication to also
> include other measures, not needing certificates.
No comment
>  - Global CoAP multicast, single or multi subnet, with or without
> responses: <missing> / dependency on IANA IPv6 allocation

Again, the draft should go for the most frequent use cases and not try 
to be complete.
Actually explicitly excluding use cases looks ineresting to me.
>  any thoughts, which would be impossible?
During the coap meeting in Atlanta, Cullen Jennings presented some 
horrifying examples, as far as I remember.

>  yes, there are issues in RD/discovery especially when more than one
So, adapt the use case and exclude this possibility.
>  hmm, I think that we should opt for having a single RD in the system
> to avoid complexity. Routers are ok. (One of our goals is to define
> how CoAP groupcomm works even across routers)
Looking forward to the supporting protocol.
> 
> 12.“MLD is used to form groups, correct? but that was already done by
> enabling the MC address in the lights (point 2)” ->
>  Step 1 is putting the MC address in the lights, then step 2 is the
> Lights use MLD to *ADVERTIZE* this address to any MLD-enabled Routers
> present link-local.

Sounds good. The point is not to add protocols because they exist but 
because they are needed.
>  CoAP servers normally MUST respond to a request with a response
> (core-coap-13) but an exception is now made for multicast where a
> server MAY choose not to. This choice is completely independent from
> confirmable/non-confirmable. Non-confirmable only means that an ACK
> must not be sent. And an ACK is something different from a CoAP
> response.

see my worries at the beginning.
> I have not gone very detailed with my comments. I hope that it is
> clear from my comments that a reorganization of the draft and a review
> of the uses cases are necessary to get a clearer picture of the
> feasibility of group comm in the context of Coap.
> 
>  Drafts is at http://datatracker.ietf.org/drafts/current/ [1].
> 
>  (http://trustee.ietf.org/license-info [2]) in effect on the date of
> 
> www: www.vanderstok.org [3]
> 
> -------------------------
>  The information contained in this message may be confidential and
> legally protected under applicable law. The message is intended solely
> for the addressee(s). If you are not the intended recipient, you are
> hereby notified that any use, forwarding, dissemination, or
> reproduction of this message is strictly prohibited and may be
> unlawful. If you are not the intended recipient, please contact the
> sender by return e-mail and destroy all copies of the original
> message.
> 
> 
> Links:
> ------
> [1] http://datatracker.ietf.org/drafts/current/
> [2] http://trustee.ietf.org/license-info
> [3] http://www.vanderstok.org

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 20 Dec 2012 10:56:03 +0000

Thanks Peter,

I would agree we need to include guidelines on returning of responses to CoAP multicast requests. (Note the CoAP spec ensures that a CoAP server will never ACK a multicast but that does not help a thing if it still sends a response packet...) I'll make a ticket for this. If anyone disagrees we'll hear it.

> Then I do not understand the text, because "request", "reply" and "response" are overloaded in my mind.
To clarify: under the assumption that a server MAY respond to a multicast request, and the client doesn't know a priori how many servers will respond to a multicast, (since there are no guidelines/rules for that), the safest thing to do is not send the multicast in the first place. Therefore the advice is to carefully control sending of multicast requests.

Esko

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: Thursday 20 December 2012 11:26
To: Dijk, Esko
Cc: [email-masked]; akbar rahman; Core
Subject: RE: group-comm comments

Hi Esko,

thanks for your reactions. I will group my answers, to better explain my points on the return of packets to MC senders.

As I understand the multicast message is preferably sent with no confirmation (ack) because the return of all the acks may overwhelm the network and the sender of the multicast.
The acknowledgement is not needed for MPL as the protocol has all the machinery to assure that all destinations receive it, (given constraints on network load and configuration density and size).

Supposing an ack is needed, then it would be advisable to staffle the responses and an additional acknowledgement protocol could be added to the multicast protocol. The same is true if a message is returned (as in the case of mDNS).

One can then wonder whether the application protocol (e.g. mDNS) should take care of the staffled response or that an additional protocol needs to be specified.
I have no opinion on the choice, but see the need for the one or the other. Coming with a recommendation (explanation) on the subject of returning responses (acks) would be my recommendation for the GroupComm document.

Below some reactions on your reactions. Hope this helps to clarify misunderstandings.

Peter

Dijk, Esko schreef op 2012-12-19 14:24:
> Hi Peter,
>
> still a fair number of comments! I would agree with most. Below I have
> selected some which we should discuss further, or ones I don’t agree
> with:
>
>
> 2. I don’t see why we should add “the use of group communication for
> mDNS is out of scope.” ->  mDNS obviously is not CoAP, and the
> document should define the scope anyway clearly as CoAP group
> communication. So we don’t have to list any other protocols than CoAP.
See my answer on return of packets. I wanted a clear statement on (NOT) specifying how applications handle the return of MC responses.

>
> 3. “so setting a multicast address in a source at installation is
> forbidden?” ->  No, that should not be forbidden :) It should also be
> possible to set a CoAP path and/or port at installation time. That
> means the two presented measures have to change or be removed.
No comment
> Good point. (2) has been chosen because it works without relying on a
> service to query (e.g. DNS or RD). Is that sufficient argumentation?
> about requests that should be carefully controlled since they generate
Then I do not understand the text, because "request", "reply" and "response" are overloaded in my mind.
>
> 6. “/comment what about the reply?” ->  based on core-coap “If the
> request message is Non-confirmable, then the response SHOULD be
> returned in a Non-confirmable message as well.”
As explained above The subject of returning packets to the MC sender needs careful consideration.
the response being NOn-confirmable does not solve a lot I am afraid.
No comment
>
> 8. Network configuration: 2 subnets vs 1 ->  maybe a one-subnet
> configuration is worth adding? Here an overview of present/absent use
> cases:
>

Again, the draft should go for the most frequent use cases and not try to be complete.
Actually explicitly excluding use cases looks ineresting to me.
>
> 9. “It might be useful if the practical impossibility of some
> configurations is high lighted” ->  any thoughts, which would be
> impossible?
During the coap meeting in Atlanta, Cullen Jennings presented some horrifying examples, as far as I remember.

>
> 10.“the RD discovery will be more complex when there is a router
> between light-2 and switch” ->  yes, there are issues in RD/discovery
> especially when more than one is present in a network.
>
> 11.“additional reason to remove router from the multicast
> configuration”->  hmm, I think that we should opt for having a single
> RD in the system to avoid complexity. Routers are ok. (One of our
> goals is to define how CoAP groupcomm works even across routers)
> enabling the MC address in the lights (point 2)” ->  Step 1 is putting
> the MC address in the lights, then step 2 is the Lights use MLD to
> *ADVERTIZE* this address to any MLD-enabled Routers present
> link-local.

Sounds good. The point is not to add protocols because they exist but because they are needed.
>
> 13.“WHY are the multicast destinations sending back results?” ->  we
> remove responses in the new -04 groupcomm. They are presented as an
> optional thing that servers can do.

> ______________________________________________________________________
> _____________________________________________________
>
>
> --
>
> Peter van der Stok
>