Miscellaneous CoAP Group Communication Topics
draft-dijk-core-groupcomm-misc-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Esko Dijk , Akbar Rahman | ||
| Last updated | 2012-01-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dijk-core-groupcomm-misc-00
CoRE Working Group E. Dijk, Ed.
Internet-Draft Philips Research
Intended status: Informational A. Rahman, Ed.
Expires: July 16, 2012 InterDigital Communications, LLC
January 13, 2012
Miscellaneous CoAP Group Communication Topics
draft-dijk-core-groupcomm-misc-00
Abstract
This document contains miscellaneous text around the topic of group
communication for the Constrained Application Protocol (CoAP). The
first part contains, for reference, text that was removed from the
Group Communication for CoAP draft. The second part describes group
communication and multicast functionality that may be input to future
standardization in the CoRE WG.
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 July 16, 2012.
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
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
Dijk & Rahman Expires July 16, 2012 [Page 1]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Group Communication Solutions . . . . . . . . . . . . . . . . . 3
2.1. IP Multicast Transmission Methods . . . . . . . . . . . . . 3
2.1.1. Serial unicast . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Unreliable IP Multicast . . . . . . . . . . . . . . . . 3
2.1.3. Reliable IP Multicast . . . . . . . . . . . . . . . . . 3
2.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . . 4
2.3. CoAP Application Layer Group Management . . . . . . . . . . 5
3. Miscellaneous Topics . . . . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Dijk & Rahman Expires July 16, 2012 [Page 2]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
1. Introduction
This document contains miscellaneous text around the topic of group
communication for the Constrained Application Protocol, CoAP
[I-D.ietf-core-coap]. The first part of the document (Section 2)
contains, for reference, text that was removed from the Group
Communication for CoAP [I-D.ietf-core-groupcomm] draft and its
predecessor [I-D.rahman-core-groupcomm]. The second part of the
document (Section 3) contains text and/or functionality that may be
considered for inclusion in [I-D.ietf-core-groupcomm] or otherwise
may be input to future standardization in the CoRE WG.
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 RFC 2119 [RFC2119].
2. Group Communication Solutions
This section includes the text that describes the solutions of IP
multicast, overlay multicast, and application layer group
communication which were removed from [I-D.rahman-core-groupcomm]
version 07 when the text was transferred to
[I-D.ietf-core-groupcomm].
2.1. IP Multicast Transmission Methods
2.1.1. Serial unicast
Even in systems that generally support IP Multicast, there may be
certain data links (or transports) that don't support IP multicast.
For those links a serial unicast alternative must be provided. This
implies that it should be possible to enumerate the members of a
group, in order to determine the correct unicast destinations.
2.1.2. Unreliable IP Multicast
The CoRE WG charter specified support for non-reliable IP multicast.
In the current CoAP protocol design [I-D.ietf-core-coap], unreliable
multicast is realized by the source sending Non-Confirmable messages
to a multicast IP address. IP Multicast (using UDP) in itself is
unreliable, unless specific reliability features are added to it.
2.1.3. Reliable IP Multicast
[TBD: This is a difficult problem. Need to investigate the benefits
of repeating MGET and MPUT requests (saturation) to get "Pretty Good
Reliability". Use the same MID or a new MID for repeated requests?
Dijk & Rahman Expires July 16, 2012 [Page 3]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
Carsten suggests the use of bloom filters to suppress duplicate
responses.
One could argue that non-idempotent operations (POST) cannot be
supported without a *truly* reliable multicast protocol. However, is
this the case? If a multicast POST request is sent repeatedly with
the same Message ID (MID), then CoAP nodes that already received it
once will ignore duplicates. Sending with Message ID is supported in
CoAP for Non-Confirmable messages (thus including multicast messages)
as per [I-D.ietf-core-coap] section 4.2. ]
Reliable multicast supports guaranteed delivery of messages to a
group of nodes. The following specifies the requirements as was
proposed originally in version 01 of [I-D.vanderstok-core-bc]:
o Validity - If sender sends a message, m, to a group, g, of
destinations, a path exists between sender and destinations, and
the sender and destinations are correct, all destinations in g
eventually receive m.
o Integrity - destination receives m at most once from sender and
only if sender sent m to a group including destination.
o Agreement - If a correct destination of g receives m, then all
correct destinations of g receive m.
o Timeliness - For real-time control of devices, there is a known
constant D such that if m is sent at time t, no correct
destination receives m after t+D.
There are various approaches to achieve reliability, such as
o Destination node sends response: a destination sends a CoAP
Response upon multicast Request reception (it SHOULD be a Non-
Confirmable response). The source node may retry a request to
destination nodes that did not respond in time with a CoAP
response.
o Route redundancy
o Source node transmits multiple times (destinations do not respond)
2.2. Overlay Multicast
An alternative group communication solution (to IP Multicast) is an
"overlay multicast" approach. We define an overlay multicast as one
that utilizes an infrastructure based on proxies (rather than an IP
router based IP multicast backbone) to deliver IP multicast packets
Dijk & Rahman Expires July 16, 2012 [Page 4]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
to end devices. MLD ([RFC3810]) has been selected as the basis for
multicast support by the ROLL working group for the RPL routing
protocol. Therefore, it is proposed that "IGMP/MLD Proxying"
[RFC4605] be used as a basis for an overlay multicast solution for
CoAP.
Specifically, a CoAP proxy [I-D.ietf-core-coap] may also contain an
MLD Proxy function. All CoAP devices that want to join a given IP
multicast group would then send an MLD Join to the CoAP (MLD) proxy.
Thereafter, the CoAP (MLD) proxy would be responsible for delivering
any IP multicast message to the subscribed CoAP devices. This will
require modifications to the existing [RFC4605] functionality.
Note that the CoAP (MLD) proxy may or may not be connected to an
external IP multicast enabled backbone. The key function for the
CoAP (MLD) proxy is to distribute CoAP generated multicast packets
even in the absence of router support for multicast.
2.3. CoAP Application Layer Group Management
Another alternative solution (to IP Multicast and Overlay Multicast)
is to define CoAP application level group management primitives.
Thus, CoAP can support group management features without need for any
underlying IP multicast support.
Interestingly, such group management primitives could also be offered
even if there is underlying IP multicast support. This is useful
because IP multicast inherently does not support the concept of a
group with managed members, while a managed group may be required for
some applications.
The following group management primitives are in general useful:
o discover groups;
o query group properties (e.g. related resource descriptions);
o create a group;
o remove a group;
o add a group member;
o remove a group member;
o enumerate group members;
Dijk & Rahman Expires July 16, 2012 [Page 5]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
o security and access control primitives.
In this proposal a (at least one) CoAP Proxy node is responsible for
group membership management. A constrained node can specify which
group it intends to join (or leave) using a CoAP request to the
appropriate CoAP Proxy. To Join, the group name will be included in
optional request header fields (explained below). These header
fields will be included in a PUT request to the Proxy. The Proxy-URI
is set to the Group Management URI of the Proxy (found previously
through the "/.well-known/" resource discovery mechanism). Note that
in this solution also CoAP Proxies may exist in a network that are
not capable of CoAP group operations.
Group names may be defined as arbitrary strings with a predefined
maximum length (e.g. 268 characters or the maximum string length in a
CoAP Option), or as URIs.
[ TBD: how can a client send a request to a group? Does it only need
to know the group name (string or URI) or also an IP multicast
address? One way is to send a CoAP request to the CoAP Proxy with a
group URI directly in the Proxy-URI field. This avoids having to
know anything related to IP multicast addresses. ]
This solution in principle supports both unreliable and reliable
group communication. A client would indicate unreliable
communication by sending a CoAP Non-Confirmable request to the CoAP
Proxy, or reliable communication by sending a CoAP Confirmable
request.
It is proposed that CoAP supports two Header Options for group "Join"
and "Leave". These Options are Elective so they should be assigned
an even number. Assuming the Type for "join" is x (value TBD), the
Header Options are illustrated by the table in Figure 1:
+------+-----+---------------+--------------+--------+--------------+
| Type | C/E | Name | Data type | Length | Default |
|------+-----+---------------+--------------+--------+--------------+
| | | | | | |
| x | E | Group Join | String | 1-270 | "" |
| | | | | B | |
| x+2 | E | Group Leave | String | 1-270 | "" |
| | | | | B | |
+------+-----|---------------+--------------+--------+--------------+
Figure 1: CoAP Header Options for Group Management
Dijk & Rahman Expires July 16, 2012 [Page 6]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
Figure 2 illustrates how a node can join or leave a group using the
Header Options in a CoAP message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | OC | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delta |length | Join Group A (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |length | Join Group B (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |length | Leave Group C (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CoAP Message for Group Management
Header Fields for the above example:
Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by
implementation as defined by the CoAP specification.
T: 2-bit unsigned integer for CoAP Transaction Type. Either '0'
Confirmation or '1' Non-Confirmable can be used for group "join" or
"leave" request.
OC: 4-bit unsigned integer for Option Count. For this example, the
value should be "3" since there are three option fields.
Code: 8-bit unsigned integer to indicate the Method in a Request or a
Response Code in a Response message. Any Code can be used so the
group management can be piggy-backed in either Request or Response
message.
Message ID: 16-bit value assigned by the source to uniquely identify
a pair of Request and Response.
CoAP defines 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 2, delta will be x. In the
second header option, it is also a group join so the delta is 0. The
third header option is a group leave so the delta is 2.
An alternative solution to using Header Options (explained above) is
to use designated parameters in the query part of the URI in the
Dijk & Rahman Expires July 16, 2012 [Page 7]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
Proxy-URI field of a POST (TBD: or PUT?) request to a Proxy's group
management service resource advertized by DNS-SD. For example, to
join group1 and leave group2:
coap://proxy1.bld2.example.com/groupmgt?j=group1&l=group2
3. Miscellaneous Topics
This section is a placeholder to add miscellaneous text, topics or
proposals related to CoAP group communication in future versions of
this document.
4. Acknowledgements
Thanks to all CoRE WG members who participated in the IETF 82
discussions, which was the trigger to initiate this document.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
Security aspects of group communication for CoAP are discussed in
[I-D.ietf-core-groupcomm]. The current document contains no new
proposals yet, for which security considerations have to be analyzed
here.
7. References
7.1. Normative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Dijk & Rahman Expires July 16, 2012 [Page 8]
Internet-Draft Miscellaneous CoAP Group Communication January 2012
[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.
7.2. Informative References
[I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-00 (work in progress),
January 2012.
[I-D.rahman-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-rahman-core-groupcomm-07 (work in progress),
October 2011.
[I-D.vanderstok-core-bc]
Stok, P. and K. Lynn, "CoAP Utilization for Building
Control", draft-vanderstok-core-bc-05 (work in progress),
October 2011.
Authors' Addresses
Esko Dijk (editor)
Philips Research
Email: esko.dijk@philips.com
Akbar Rahman (editor)
InterDigital Communications, LLC
Email: Akbar.Rahman@InterDigital.com
Dijk & Rahman Expires July 16, 2012 [Page 9]