[core] Fw: group-comm comments

["weigengyu" <[e-mail]>]

Hi, Perter,

Comments inlines.

> It involved a limited number of receivers which are not too far removed 
> from the source.
In a hospital, it does.
But if one healthcare center or clinical monitors many servers across a
residence community,
the number of servers may be more than ten thausands or one handred
thausands.

> You would look for a 2-phase commit style of multicast, I expect.
> Only when all receivers received the message, can commit take place 
> otherwise, abort.
> Is that correct?
The considered usecase includes collecting data request (1-to-N)  and
responses (N x [1-to-1]).
That is something different from two-phase commit which is a typical
database consistency algorithm in distributed systems.

> This is a very different approach from the MPL one or the video streaming 
> one.
Something like, I think.
I think that the proxy-based approach would be an alternative in the
environments like CoRE.

While  the reliable multicast could provide by transport layer or
application layer,
I do not think the transport layer reliable multicast is suitable for CoRE.

Regards,

Gengyu

> Network Technology Center,
> School of Computer
> Beijing University of Posts & Telecommunications

-----原始邮件----- 
From: peter van der Stok
Sent: Tuesday, November 05, 2013 11:34 PM
To: weigengyu
Cc: [e-mail] ; [e-mail]
Subject: Re: [core] group-comm comments

Hi Gengyu.

The medical case is a bit familiar to me.
It involved a limited number of receivers which are not too far removed
from the source.
You would look for a 2-phase commit style of multicast, I expect.
Only when all receivers received the message, can commit take place
otherwise, abort.
Is that correct?

This is a very different approach from the MPL one or the video
streaming one.

As far as I know algorithms exist, but I don't know about
standardization.

Peter


weigengyu schreef op 2013-11-05 05:19:
> Hi，Peter,
>
> Thank you for your reply.
>
>> Does that partially answer your question for wireless meshes?
> Yes.
>
> "With the choice of the density of MPL forwarders and the number of
> repetitions by MPL forwarders",
> could help provide the multicast capability near to reliable.
>
> While Unreliable multicast is requried for many senarios, the current
> groupcomm draft can meet these requirements.
>
> But there are really some senarios, such as mobile healthcare, in-home
> switch control etcs, that need the reliable multicast.
> I wish that the CoAP groupcomm might evole to cover the CoAP reliable
> multicast at next stage.
>
> regards,
>
> Gengyu
>
> Network Technology Center,
> School of Computer
> Beijing University of Posts & Telecommunications
>
>
> -----原始邮件----- From: peter van der Stok
> Sent: Monday, November 04, 2013 12:42 PM
> To: weigengyu
> Cc: Rahman, Akbar ; Core ; Dijk, Esko ; [e-mail]
> Subject: Re: [core] group-comm comments
>
> Hi Weigenyu,
>
> With the choice of the density of MPL forwarders and the number of
> repetitions by MPL forwarders it is possible to estimate the reliability
> of the MPL multicast as function of the single transmission failure rate
> under a range of network loads.
>
> Does that partially answer your question for wireless meshes?
>
> Peter
>
>
>
> weigengyu schreef op 2013-11-04 05:28:
>> Hi Akbar,
>>
>> Thank you for your reply.
>>
>>> Reliable multicast is not supported.
>>> We can perhaps make this more clear by adding a sentence in the Scope 
>>> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2).
>>
>> I belive it is required.
>> I have misunderstood that it provides unreliable multicast just for
>> the use case of Light Switch Control.
>>
>> And, I also want to ask the List,
>> has anyone considered or been interested in CoAP Reliable Groupcomm or
>> CoAP reliable multicast?
>>
>> Regards,
>>
>> Gengyu
>>
>> Network Technology Center
>> School of Computer
>> Beijing University of Posts & Telecommunications
>>
>>
>> -----原始邮件----- From: Rahman, Akbar
>> Sent: Sunday, November 03, 2013 10:56 PM
>> To: weigengyu
>> Cc: Core ; Dijk, Esko ; [e-mail]
>> Subject: RE: [core] group-comm comments
>>
>> Hi Gengyu,
>>
>>
>> Just some quick feedback.  The groupcomm draft assumes only unreliable
>> (i.e. not guaranteed) IP multicast.  This is specified in
>>
>> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.4
>> (see 1st paragraph)
>>
>> and
>>
>> http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-3.4
>> (see 3rd paragraph)
>>
>>
>> Reliable multicast is not supported.  We can perhaps make this more
>> clear by adding a sentence in the Scope
>> (http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-1.2).
>>
>>
>>
>> Thanks for your review,
>>
>>
>> Akbar
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of weigengyu
>> Sent: Saturday, November 02, 2013 9:16 AM
>> To: Dijk, Esko; [e-mail]
>> Cc: Core
>> Subject: Re: [core] group-comm comments
>>
>> Hi, Esko
>>
>> I would like to give some comments on the GROUP-COMM draft.
>>
>> There have use cases for reliable and unreliable multicast 
>> communications.
>> If this draft only for providing unreliable multicast over IP multicast, 
>> it
>> is OK;  just write it clearly.
>>
>> If the draft intends to have the reliable or partial multicast facility,
>> the dtaft needs to give what mechanisms can gurantte that.
>>
>> The draft should define mechnisms that the server can register its
>> capability of supporting multicast,
>> this may be put to RD server;
>> and wether to request reliable groupcomm shoule be the client's request.
>>
>>> To clarify: under the assumption that a server MAY respond to a 
>>> multicast
>>> request,
>> A mechanism is required to make the server registers its capability. i.e.
>> whether to support multicast;
>>
>>> and the client doesn't know a priori how many servers will respond to a
>>> multicast,
>> The client may lookup the information from the RD server (if the rerver's
>> registeration processe were possible);
>>
>>> (since there are no guidelines/rules for that), the safest thing to do 
>>> is
>>> not send the multicast in the first place.
>> If not first, when to make available?
>> So, whether it is required should be determined by the client request, 
>> and
>> there should have some authority or priority control to client.
>>
>>> Therefore the advice is to carefully control sending of multicast
>>> requests.
>> Not only to tell that, the draft should have clear descriptions about how
>> the protocol supports multicast requiests and/or reliable multicast when
>> required.
>>
>> regards,
>>
>> Gengyu
>>
>> Network Technology Center
>> School of Computer
>> Beijing University of Posts & Telecommunications
>>
>> -----原始邮件----- From: Dijk, Esko
>> Sent: Thursday, December 20, 2012 6:56 PM
>> To: [e-mail]
>> Cc: Core
>> Subject: Re: [core] group-comm comments
>>
>> 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:[e-mail]]
>> Sent: Thursday 20 December 2012 11:26
>> To: Dijk, Esko
>> Cc: [e-mail]; 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.
>>
>> 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:
>>>
>>> 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.
>> 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)
>>>
>>> 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
>>>
>>> 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)
>>>
>>> 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.
>> 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.”
>>> . 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.
>>>
>>> 7. “/comment invoking as many certificates?” ->
>>>  core-coap-13 now loosens the concept of authentication to also
>>> include other measures, not needing certificates.
>> 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:
>>>
>>>  - 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>
>>
>> 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.
>> So, adapt the use case and exclude this possibility.
>>>
>>> 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)
>> 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.
>>>  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.
>>
>> 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.
>>>  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’.
>>
>> see my worries at the beginning.
>>>
>>> Esko
>>>
>>> -----Original Message-----
>>>  From: peter van der Stok [mailto:[e-mail]]
>>>  Sent: Tuesday 18 December 2012 12:06
>>>  To: akbar rahman; Dijk, Esko; Core
>>>  Subject: group-comm comments
>>>
>>> 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/ [1].
>>>
>>>  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 [2]) 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: [e-mail]
>>>
>>> www: www.vanderstok.org [3]
>>>
>>> tel NL: [phone] F: [phone]
>>>
>>> -------------------------
>>>  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
>>
>> ________________________________
>> 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.
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>>
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core