CoRE A. Rahman, Ed.
Internet-Draft InterDigital Communications, LLC
Intended status: Informational October 14, 2010
Expires: April 17, 2011
Group Communication for CoAP
draft-rahman-core-groupcomm-00
Abstract
This is a working document intended to trigger discussion and develop
draft language for the CoAP protocol specification in the area of
group communication (including multicast functionality). Engineering
tradeoffs become more challenging in constrained environments,
therefore group communication is considered within the context of
adjacent topics that may impact or be impacted by design choices in
the subject area.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Rahman Expires April 17, 2011 [Page 1]
Internet-Draft Group Communication for CoAP October 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Problem Statement and Scope . . . . . . . . . . . . . . . 4
3. Multicast Solutions . . . . . . . . . . . . . . . . . . . . . 4
3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Group Addressing . . . . . . . . . . . . . . . . . . . 5
3.1.2. Group URIs . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3. Group Discovery . . . . . . . . . . . . . . . . . . . 5
3.1.4. Group Resource Manipulation . . . . . . . . . . . . . 6
3.1.5. Multicast Transmission Methods . . . . . . . . . . . . 7
3.1.6. Congestion Control . . . . . . . . . . . . . . . . . . 8
3.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 8
4. CoAP Level Group Management . . . . . . . . . . . . . . . . . 8
5. Alternate Group Transmission Methods . . . . . . . . . . . . . 10
5.1. Serial Unicast . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Unicast-to-Multicast . . . . . . . . . . . . . . . . . . . 10
6. CoAP and HTTP Interworking . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Rahman Expires April 17, 2011 [Page 2]
Internet-Draft Group Communication for CoAP October 2010
1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The following are definitions of terminologies used in this draft.
Multicast: A solution based on the use of multicast addresses as
defined in "IP Version 6 Addressing Architecture" [RFC4291].
Group Communication: One source node sends a CoAP message to more
than one destination node. The source and destination nodes can be
constrained or non-constrained nodes. This may include serial
unicast, multicast, or hybrid unicast-to-multicast solutions.
2. Introduction
2.1. Background
The CoRE working group is chartered to design and standardize a
Constrained Application Protocol (CoAP) for resource constrained
devices and networks [I-D.ietf-core-coap]. The requirements for CoRE
are documented in [I-D.shelby-core-coap-req].
In this draft, we focus and expand discussions on requirements
pertaining to multicast support, including:
REQ 9: CoAP will support a non-reliable IP multicast message to be
sent to a group of Devices to manipulate a resource on all the
Devices simultaneously. The use of multicast to query and
advertise descriptions must be supported, along with the support
of unicast responses.
Currently, the CoAP protocol [I-D.ietf-core-coap] supports unreliable
multicast using UDP. It defines the unreliable multicast operation
as follows:
"Multicast messages SHOULD be Non-Confirmable. If a Confirmable
multicast message is sent then retransmission MUST NOT be
performed. Furthermore, a destination end-point to a multicast
Confirmable message MUST only send an Acknowledgment if the
response code included indicates success (Code = 2XX) in order to
eliminate error code response floods."
Additional requirements were introduced in [I-D.vanderstok-core-bc]
driven by quality of experience issues in commercial lighting; the
Rahman Expires April 17, 2011 [Page 3]
Internet-Draft Group Communication for CoAP October 2010
need for large numbers of devices to respond with near simultaneity
to a command (multicast PUT), and for that command to be received
reliably (reliable multicast).
2.2. Problem Statement and Scope
In this draft, we expand the scope from unreliable multicast in the
current CoAP requirement to group communication, using either
(reliable or unreliable) multicast or unicast.
Machine-to-Machine (M2M) networks may contain groups of servers that
are highly correlated (e.g.,, by type or location). For example, all
smart meters in a region may belong to one group, and all light
switches in a building control system belong to another. Group
communication can increase the efficiency of communication and reduce
bandwidth requirements for a given application.
In the following sections, we address the issues related to group
communication in detail, with proposed solutions and analysis of
impacts to the CoAP protocol and implementations.
3. Multicast Solutions
The classic model of a multicast application is that of a single
source distributing content to many recipients. Multicast solutions
have evolved from "bottom" to "top", i.e., from the network layer (IP
multicast) to application layer multicast. A study published in 2005
identified new solutions in the "middle" (referred to as overlay
multicast) that utilize an infrastructure based on proxies [STUDY1].
Each of these classes of multicast solutions may be compared using
metrics such as link stress and level of host complexity [STUDY2].
The approach adopted here is to begin with IP multicast and present a
complete picture to introduce some key concepts, then expand to cover
more general scenarios such as group management and CoAP-to-HTTP
proxies.
3.1. IP Multicast
IP Multicast protocols have been evolving for decades, resulting in
proposed standards such as Protocol Independent Multicast - Sparse
Mode (PIM-SM) [RFC4601]. Yet, due to various technical and marketing
reasons, IP Multicast is not widely deployed on the Internet, leading
to alternative solutions for applications like interactive gaming and
publish/subscribe. However, the packet economy and minimal host
complexity of IP multicast make it worth investigating for intra-
domain group communication in constrained environments.
Rahman Expires April 17, 2011 [Page 4]
Internet-Draft Group Communication for CoAP October 2010
3.1.1. Group Addressing
The header compression proposal of 6LoWPAN [I-D.ietf-6lowpan-hc]
includes a format to support Unicast-Prefix-based IPv6 Multicast
Addresses such as [RFC3956], which is itself a scheme to simplify the
deployment of PIM-SM [RFC4601]. Since the use of header compression
for CoAP is highly desirable, we propose the use of this addressing
mode for IP multicast.
3.1.2. Group URIs
An approach to map group authorities onto multicast addresses using
DNS was proposed in [I-D.vanderstok-core-bc]. Examples of group URI
naming (and scope) for a building control application are shown
below:
//all.bldg6... "all nodes in building 6"
//all.west.bldg6... "all nodes in west wing, building 6"
//all.floor1.west.bldg6... "all nodes in floor 1, west wing, etc."
//all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1,
etc."
Group URIs MUST follow the approach of the URI structure defined in
[RFC3986]. The authority portion of the URI is used to identify a
node (or group) and the resulting DNS name is bound to a unicast or
(or multicast) address. Each example group URI shown above would be
mapped to a unique multicast IP addresses as defined in [RFC4291].
3.1.3. Group Discovery
[Need to describe how group naming/scoping as defined in the previous
section relates to group formation and discovery.]
CoAP defines a resource discovery capability but it is limited to
link-local scope; examples may be found in [I-D.ietf-core-coap]. A
service discovery capability is required to extend discovery to other
subnets, as originally proposed in [I-D.vanderstok-core-bc].
DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a
conventional way to configure DNS PTR, SRV, and TXT records to enable
enumeration of services such as CoAP nodes within subdomains. A
service is specified by a name of the form Instance.Type.Domain,
where the type for CoAP nodes is _coap._udp and the domain is a DNS
domain name that identifies a DNS zone as in the examples above. For
each CoAP end-point in the zone, a PTR record with the name
Rahman Expires April 17, 2011 [Page 5]
Internet-Draft Group Communication for CoAP October 2010
_coap._udp is defined and it points to an SRV record having the
Instance.Type.Domain name.
All CoAP nodes in a given subdomain may be enumerated by sending a
query for PTR records named _coap._udp to the authoritative server
for that zone. A list of SRV records is returned. Each SRV record
contains the port and host name (AAAA record) of a CoAP node. The IP
address of the node is obtained by resolving the host name. DNS-SD
also specifies an optional TXT record, having the same name as the
SRV record, which can contain "key=value" attributes. This can be
used to store information about the device, e.g., schema=DALI,
type=switch, group=lighting.bldg6, etc.
Another feature of DNS-SD is the ability to specify service subtypes
using PTR records. For example, one could represent all the CoAP
groups in a subdomain by PTR records with the name
_group._sub._coap.udp.
3.1.4. Group Resource Manipulation
Two forms of group resource manipulation must be supported. The
first is push (multicast PUT or MPUT for short) as e.g., "turn off
all the lights simultaneously". Logically, this is similar to
publishing a value to multiple subscribers. The second operation is
pull (multicast GET or MGET), which is essential for discovery during
comissioning and can be illustrated by the example "return all the
resources matching a .well-known URI". MGET should perhaps be
limited in scope to link-local multicast.
Conceptually, the result of a multicast GET or PUT should be the same
as if the client had unicast them serially (that is, a set of {URI,
representation} tuples). Practically, there are major benefits to
solving this problem:
- packet economy on constrained networks
- M2M resource discovery (solves the "chicken-and-egg" problem)
- apparent simultaneity of events (e.g., lighting applications)
For data links (or transports) that don't support IP multicast, a
serial unicast alternative must be provided. In either case it
should be possible to enumerate the members of a group. For links
that do support IP multicast, there are a few implications:
- All multicast requests MUST be sent to the well-known CoAP port
Rahman Expires April 17, 2011 [Page 6]
Internet-Draft Group Communication for CoAP October 2010
- All multicast requests SHOULD operate on /.well-known/core URIs
One question is whether the application (or middleboxes) need to be
aware that a request is intended for a group. A separate scheme as
proposed by [1998 Microsoft I-D ref] might be useful (e.g., "corem:"
vs. "core:").
3.1.5. Multicast Transmission Methods
3.1.5.1. Unreliable IP Multicast
The CoRE WG charter specified support of non-reliable multicast. In
the current CoAP protocol design [I-D.ietf-core-coap], unreliable
multicast is realized by the source sending non-confirmable messages.
3.1.5.2. Reliable IP Multicast
[This is a difficult problem. Need to investigate the benefits of
repeating MGET and MPUT requests (saturation) to get "Pretty Good
Reliability". Use the same TID or a new TID for repeated requests?
Carsten suggests the use of bloom filters to suppress duplicate
responses.
Note that non-idempotent operations (POST) cannot be supported
without a *truly* reliable multicast protocol.]
Reliable multicast supports guaranteed delivery of messages to a
group of nodes. The following specifies the requirements as was
proposed originally in [I-D.vanderstok-core-bc]:
Validity - If sender sends a message, m, to a group, g, of
destinations, a path exists between sender and destinations, and the
sender and destinations are correct, all destinations in g eventually
receive m.
Integrity - destination receives m at most once from sender and only
if sender sent m to a group including destination.
Agreement - If a correct destination of g receives m, then all
correct destinations of g receive m.
Timeliness - For real-time control of devices, there is a known
constant D such that if m is sent at time t, no correct destination
receives m after t+D.
There are various approaches to achieve reliability, such as
Rahman Expires April 17, 2011 [Page 7]
Internet-Draft Group Communication for CoAP October 2010
* Destination node sends acknowledgement: in CoAP, multicast
messages are confirmable when reliability is required.
* Route redundancy
* Source node transmits multiple times
3.1.6. Congestion Control
[In the case of MGET or Confirmable MPUT, servers should enforce a
random delay within TIMEOUT before sending responses. More
investigation required.]
CoAP requests may be multicast, resulting multitude of replies from
different nodes, potentially causing congestion.
[I-D.eggert-core-congestion-control] suggests to conservatively
control sending multicast request.
Various means can be implemented to prevent congestion.
Currently in the CoAP protocol, the MAX_RETRANSMIT value is set to 5
by default. It is suggested that two values are used separately for
retransmissions, one for unicast transmission between a single source
and sink. The current value of 5 is used for such transmission.
Another constant is defined for multicast or group communication.
The retransmission value for group transmission should be much lower,
such as 1.
3.2. Overlay Multicast
[Discuss proxy-based multicast solutions that eliminate the need for
router support, e.g., "IGMP/MLD Proxying" [RFC4605].]
4. CoAP Level Group Management
Constrained devices can be large in number, but highly correlated to
each other. For example, all the light switches in a building may
belong to one group and all the thermostats belong to another group.
All the smart meters in the same region can belong to one group as
well. Groups may be composed by function; for example, the group
"all lights in building one" may consist of the groups "all lights on
floor one of building one", "all lights on floor two of building
one", etc. Groups may be configured or dynamically formed.
The CoAP protocol needs to support CoAP group management features
independently of any underlying IP multicast support. For example, a
constrained node needs to be able to specify which group it intends
to join using a CoAP request by providing the group address.
Rahman Expires April 17, 2011 [Page 8]
Internet-Draft Group Communication for CoAP October 2010
The CoAP Proxy node would be responsible for group membership
management. It is proposed that CoAP supports two Header Options for
group "join" and "leave". These Options are Elective so they should
be assigned an even number. Assuming the Type for "join" is x (value
TBD), the Header Options are illustrated by the table in Figure 1:
+------+-----+---------------+--------------+--------+--------------+
| Type | C/E | Name | Data type | Length | Default |
|------+-----+---------------+--------------+--------+--------------+
| | | ... current Option Headers |.. | |
| | | | | |
| x | E | Group Join | String | 1-270 | "" |
| | | | | B | |
| x+2 | E | Group Leave | String | 1-270 | "" |
| | | | | B | |
+------+-----|---------------+--------------+--------+--------------+
Figure 1: CoAP Header Options for Group Management
Figure 2 illustrates how a node can join or leave a group using the
Header Options in a CoAP message:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | OC | Code | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delta |length | Join Group A (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |length | Join Group B (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |length | Leave Group C (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CoAP Message for Group Management
Header Fields for the above example:
Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by
implementation as defined by the CoAP specification.
T: 2-bit unsigned integer for CoAP Transaction Type. Either '0'
Confirmation or '1' Non-Confirmable can be used for group "join" or
Rahman Expires April 17, 2011 [Page 9]
Internet-Draft Group Communication for CoAP October 2010
"leave" request.
OC: 4-bit unsigned integer for Option Count. For this example, the
value should be "3" since there are three option fields.
Code: 8-bit unsigned integer to indicate the Method in a Request or a
Response Code in a Response message. Any Code can be used so the
group management can be piggy-backed in either Request or Response
message.
Transaction ID: 16-bit unsigned integer assigned by the source to
uniquely identify a pair of Request and Response.
CoAP defined a delta encoding for header options. The first delta is
the "Type" for group join in this specific example. If the type for
group join is x as illustrated in Figure 1, delta will be x. In the
second header option, it is also a group join so the delta is 0. The
third header option is a group leave so the delta is 2.
5. Alternate Group Transmission Methods
5.1. Serial Unicast
Unicast can also be used for the transmission of group messages.
When unicast is used, no IP multicast address is provided by the
application. Instead, the group URI must be expanded into unicast
addresses.
5.2. Unicast-to-Multicast
[Discuss how a unicast message can be converted by a proxy to a CoAP
multicast request as in Figure 3.]
6. CoAP and HTTP Interworking
Within the constrained network, an application protocol (e.g., CoAP)
usually runs over UDP for which IP multicast is supported. In a non-
constrained network (i.e. general Internet), HTTP over TCP is
typically used for which IP multicast is not naturally supported.
This causes the scenario below:
The traffic within the constrained network is multicast (such as
CoAP over UDP), and within the non-constrained network it is
unicast (such as HTTP over TCP)
Therefore the proxy node needs to have functionalities to support
Rahman Expires April 17, 2011 [Page 10]
Internet-Draft Group Communication for CoAP October 2010
interworking of unicast and multicast as illustrated in Figure 3:
CoAP CoAP CoAP/HTTP HTTP
Node 1 Node 2 Proxy Node 3
| | | |
| REQUEST | | |
| (Group Join) | | |
|-----------------|------------- >| |
| RESPONSE | | |
|< ---------------|---------------| |
| | | |
| | REQUEST | |
| | (Group Join) | |
| |------------- >| |
| | RESPONSE | |
| |< -------------| |
| | | |
| | | |
| | | HTTP REQUEST |
| | | (to unicast addr) |
| | |< -----------------|
| | | |
| | map destination |
| | to multicast address |
| | | |
| REQUEST (to multicast addr) | |
| |< -------------| |
|< ---------------|---------------| |
| | | |
| (optional) RESPONSE | |
| |------------- >| |
|-----------------|-------------->| |
| | | HTTP RESPONSE |
| | |----------------- >|
| | | |
Figure 3: Multicast and Unicast Interworking
7. Security Considerations
There is an IETF WG (msec) engaged in group security. Additionally,
the control plane of PIM-SM seems to require IPSec for its
operations. Any secure data transfers over IP multicast would seem
to require a group keying scheme. More investigation required.
Rahman Expires April 17, 2011 [Page 11]
Internet-Draft Group Communication for CoAP October 2010
8. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Conclusions
Consider the proposals for group communication described in this
draft for incorporation into the overall CoAP protocol specification.
10. Acknowledgements
Thanks to Peter Bigot, Carsten Bormann, Kerry Lynn, Guang Lu, Zach
Shelby, Peter van der Stok, Juan Carlos Zuniga and others for helpful
comments and discussions that have shaped this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
Rahman Expires April 17, 2011 [Page 12]
Internet-Draft Group Communication for CoAP October 2010
11.2. Informative References
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-06 (work in
progress), March 2010.
[I-D.eggert-core-congestion-control]
Eggert, L., "Congestion Control for the Constrained
Application Protocol (CoAP)",
draft-eggert-core-congestion-control-00 (work in
progress), June 2010.
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-13
(work in progress), September 2010.
[I-D.ietf-core-coap]
Shelby, Z., Frank, B., and D. Sturek, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-02
(work in progress), September 2010.
[I-D.rahman-core-sleeping]
Rahman, A., Zuniga, J., and G. Lu, "Sleeping and Multicast
Considerations for CoAP", draft-rahman-core-sleeping-00
(work in progress), June 2010.
[I-D.shelby-core-coap-req]
Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
Kelsey, "CoAP Requirements and Features",
draft-shelby-core-coap-req-01 (work in progress),
April 2010.
[I-D.vanderstok-core-bc]
Stok, P. and K. Lynn, "CoAP Utilization for Building
Control", draft-vanderstok-core-bc-01 (work in progress),
July 2010.
[STUDY1] Lao, L., Cui, J., Gerla, M., and D. Maggiorini, "A
Comparative Study of Multicast Protocols: Top, Bottom, or
In the Middle?", 2005, <http://www.cs.ucla.edu/NRL/hpi/
AggMC/papers/comparison_gi_2005.pdf>.
[STUDY2] Banerjee, B. and B. Bhattacharjee, "A Comparative Study of
Application Layer Multicast Protocols", 2001, <http://
wmedia.grnet.gr/P2PBackground/
a-comparative-study-ofALM.pdf>.
Rahman Expires April 17, 2011 [Page 13]
Internet-Draft Group Communication for CoAP October 2010
Author's Address
Akbar Rahman (editor)
InterDigital Communications, LLC
Email: Akbar.Rahman@InterDigital.com
Rahman Expires April 17, 2011 [Page 14]
