One document matched: draft-dijk-core-groupcomm-misc-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC4605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4605.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.rahman-core-groupcomm SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rahman-core-groupcomm.xml">
<!ENTITY I-D.ietf-core-groupcomm SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-groupcomm.xml">
<!ENTITY I-D.vanderstok-core-bc SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vanderstok-core-bc.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-dijk-core-groupcomm-misc-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Miscellaneous CoAP Group Communication">Miscellaneous CoAP Group Communication Topics</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Esko Dijk" initials="E.O." surname="Dijk" role="editor">
<organization> Philips Research </organization>
<address>
<email> esko.dijk@philips.com </email>
</address>
</author>
<author fullname="Akbar Rahman" initials="A." surname="Rahman" role="editor">
<organization> InterDigital Communications, LLC </organization>
<address>
<email> Akbar.Rahman@InterDigital.com </email>
</address>
</author>
<date year="2012"/>
<area>Applications</area>
<workgroup>CoRE Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>CoRE</keyword>
<keyword>multicast</keyword>
<keyword>group communication</keyword>
<keyword>miscellaneous</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document contains miscellaneous text around the topic of group communication for
the Constrained Application Protocol, CoAP <xref target="I-D.ietf-core-coap"/>. The first
part of the document (<xref target="groupcomm-solutions"/>) contains, for reference, text that was removed from the Group
Communication for CoAP <xref target="I-D.ietf-core-groupcomm"/> draft and its predecessor <xref target="I-D.rahman-core-groupcomm"/>. The second part of
the document (<xref target="new-topics"/>) contains text and/or functionality that may be considered for inclusion in
<xref target="I-D.ietf-core-groupcomm"/> or otherwise may be input to future standardization in
the CoRE WG.
</t>
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Group Communication Solutions" anchor="groupcomm-solutions">
<!-- section anchor="sec-3.1" title="Overview" -->
<t>
This section includes the text that describes the solutions of IP multicast, overlay multicast, and application layer
group communication which were removed from <xref target="I-D.rahman-core-groupcomm"/> version 07 when the text was
transferred to <xref target="I-D.ietf-core-groupcomm"/>.
</t>
<!-- section anchor="sec-3.3.5" title="IP Multicast Transmission Methods" -->
<section title="IP Multicast Transmission Methods">
<section title="Serial unicast">
<t>
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.
</t>
</section>
<section title="Unreliable IP Multicast">
<t>
The CoRE WG charter specified support for non-reliable IP multicast. In
the current CoAP protocol design <xref target="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.
</t>
</section>
<section title="Reliable IP Multicast">
<t>
[TBD: This is a difficult problem. Need to investigate the benefits of repeating
MGET and MPUT requests (saturation) to get "Pretty Good Reliability". Use
the same MID or a new MID for repeated requests? Carsten suggests the use
of bloom filters to suppress duplicate responses.
</t><t>
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 <xref target="I-D.ietf-core-coap" /> section 4.2.
]
</t><t>
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
<xref target="I-D.vanderstok-core-bc" />:
<list style="symbols">
<t>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.
</t><t>
Integrity - destination receives m at most once from sender and
only if sender sent m to a group including destination.
</t><t>
Agreement - If a correct destination of g receives m, then all
correct destinations of g receive m.
</t><t>
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.
</t>
</list>
There are various approaches to achieve reliability, such as
</t><t>
<list style="symbols">
<t>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.</t>
<t>Route redundancy </t>
<t>Source node transmits multiple times (destinations do not respond) </t>
</list>
</t>
</section>
</section>
<!-- section anchor="sec-3.4" title="Overlay Multicast" -->
<section title="Overlay Multicast" anchor="OverlayMulticast">
<t> 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 to end devices. MLD (<xref target="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"
<xref target="RFC4605" /> be used as a basis for an overlay multicast solution for CoAP.
</t><t>
Specifically, a CoAP proxy <xref target="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 <xref target="RFC4605" /> functionality.
</t><t>
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.
</t>
</section>
<section title="CoAP Application Layer Group Management" anchor="AppGroupMgmt">
<t>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.
</t>
<t>
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.
</t>
<t>
The following group management primitives are in general useful:
<list style="symbols">
<t>discover groups;</t>
<t>query group properties (e.g. related resource descriptions);</t>
<t>create a group;</t>
<t>remove a group;</t>
<t>add a group member;</t>
<t>remove a group member;</t>
<t>enumerate group members;</t>
<t>security and access control primitives.</t>
</list>
</t>
<t>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.
</t><t>
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.
</t><t>
[ 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.
]
</t><t>
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.
</t><t>
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 <xref target="fig-header-options"/>:
</t>
<figure anchor="fig-header-options" title="CoAP Header Options for Group Management" align="center">
<artwork>
<![CDATA[
+------+-----+---------------+--------------+--------+--------------+
| 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 | |
+------+-----|---------------+--------------+--------+--------------+
]]>
</artwork>
</figure>
<t>
<vspace blankLines='1' />
<xref target="fig-coap-msg-group-mgt"/> illustrates how a node can join or leave a group using the
Header Options in a CoAP message:
</t>
<figure anchor="fig-coap-msg-group-mgt" title="CoAP Message for Group Management" align="center">
<artwork>
<![CDATA[
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
<vspace blankLines='1' />
Header Fields for the above example:
</t><t>
Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by
implementation as defined by the CoAP specification.
</t><t>
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.
</t><t>
OC: 4-bit unsigned integer for Option Count. For this example, the
value should be "3" since there are three option fields.
</t><t>
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.
</t><t>
Message ID: 16-bit value assigned by the source to
uniquely identify a pair of Request and Response.
</t><t>
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 <xref target="fig-coap-msg-group-mgt"/>, 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.
</t><t>
An alternative solution to using Header Options (explained above) is to use
designated parameters in the query part of the URI in the Proxy-URI field of
a POST (TBD: or PUT?) request to a Proxy's group management service resource
advertized by DNS-SD. For example, to join group1 and leave group2:
<figure>
<artwork>
coap://proxy1.bld2.example.com/groupmgt?j=group1&l=group2
</artwork>
</figure>
</t>
</section>
</section>
<section title="Miscellaneous Topics" anchor="new-topics">
<t>This section is a placeholder to add miscellaneous text, topics or proposals related to CoAP group communication
in future versions of this document.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to all CoRE WG members who participated in the IETF 82 discussions, which
was the trigger to initiate this document.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security aspects of group communication for CoAP are discussed in <xref target="I-D.ietf-core-groupcomm"/>. The
current document contains no new proposals yet, for which security considerations have to be analyzed here.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2119;
&RFC3810;
&RFC4605;
&I-D.ietf-core-coap;
</references>
<references title="Informative References">
&I-D.rahman-core-groupcomm;
&I-D.ietf-core-groupcomm;
&I-D.vanderstok-core-bc;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:24:14 |