One document matched: draft-bergmann-bier-ccast-02.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<rfc ipr="trust200902" docName="draft-bergmann-bier-ccast-02" category="std">
<front>
<title abbrev="Constrained-Cast">Constrained-Cast: Source-Routed Multicast for RPL</title>
<author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63904</phone>
<email>bergmann@tzi.org</email>
</address>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email>
</address>
</author>
<author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63906</phone>
<email>gerdes@tzi.org</email>
</address>
</author>
<author initials="H." surname="Chen" fullname="Hao Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>12, E. Mozhou Rd</street>
<city>Nanjing</city>
<code>211111</code>
<country>China</country>
</postal>
<phone>+86-25-5662-7052</phone>
<email>philips.chenhao@huawei.com</email>
</address>
</author>
<date year="2016" month="October" day="05"/>
<area>Applications</area>
<abstract>
<t>This specification defines a protocol for forwarding multicast traffic
in a constrained node network employing the RPL routing protocol in
non-storing mode.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>As defined in <xref target="RFC6550"/>, RPL Multicast assumes that the RPL network
operates in Storing Mode. Multicast DAOs are used to indicate
subscription to multicast address to a parent; these DAOs percolate up and create bread-crumbs.
This specification, although part of RFC 6550, appears to be
incomplete and untested.
More importantly, Storing Mode is not in use in constrained node
networks outside research operating environments.</t>
<t>The present specification addresses multicast forwarding for RPL
networks in the much more common Non-Storing Mode. Non-Storing is
based on the root node adding source-routing information to downward
packets. Evidently, to make this work, RPL multicast needs to
source-route multicast packets. A source route here is a list of
identifiers to instruct forwarders to relay the respective IP
datagram.</t>
<t>As every forwarder in an IP-based constrained node network has at
least one network interface, it is straight-forward to use the address
of an outgoing interface as identifiers in this
source-route. (Typically, this is a globally unique public address of
the node’s only network adapter.)</t>
<t>The source-route subsets the whole set of potential forwarders
available in the RPL DODAG to those that need to forward in order to
reach known multicast listeners.</t>
<t>Including an actual list of outgoing interfaces is rarely applicable,
as this is likely to be a large list of 16-byte IPv6 addresses.
Even with <xref target="RFC6554"/> style compression, the size of the list becomes
prohibitively quickly.</t>
<section anchor="terminology" title="Terminology">
<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 RFC 2119 <xref target="RFC2119"/>.</t>
<t>In this specification, the term “byte” is used in its now customary
sense as a synonym for “octet”.</t>
<t>All multi-byte integers in this protocol are interpreted in network
byte order.</t>
</section>
</section>
<section anchor="the-bier-approach" title="The BIER Approach">
<t>Bit-Indexed Explicit Replication <xref target="I-D.ietf-bier-architecture"/>
lists all egress routers in a bitmap included in each multicast
packet. This requires creating a mostly contiguous numbering of all
egress routers; more importantly, BIER requires the presence of a
network map in each forwarders to be able to interpret the bitmap and
map it to a set of local outgoing interfaces.</t>
</section>
<section anchor="the-constrained-cast-approach" title="The Constrained-Cast Approach">
<t>Constrained-Cast employs Bloom Filters <xref target="BLOOM"></xref> as a compact representation of
a match or non-match for elements in a large set:
Each element to be included is hashed with multiple hash functions;
the result is used to index a bitmap and set the corresponding bit.
To check for the presence of an element, the same hash functions are
applied to obtain bit positions; if all corresponding bits are set,
this is used to indicate a match.
(Multiple hash functions are most easily obtained by adding a varying
seed value to a single hash algorithm.)</t>
<t>By including a bloom filter in each packet that matches all outgoing
interfaces that need to forward the packet, each forwarder can
efficiently decide whether (and on which interfaces) to forward the packet.</t>
</section>
<section anchor="false-positives" title="False Positives">
<t>Bloom filters are probabilistic. A false positive might be
indicating a match where the bits are set by aliasing of the hash
values.
In case of Constrained-Cast, this causes spurious transmission and
wastes some energy and radio bandwidth.
However, there is no semantic damage (hosts still filter out unneeded multicasts).
The total waste in energy and spectrum can be visualized as the
false-positive-rate multiplied by the density of the RPL network.
A network can easily live with a significant percentage of false positives.
By changing the set of hash functions (i.e., seed) over time, the
root can avoid a single node with a false positive to become an
unnecessary hotspot for that multicast group.</t>
</section>
<section anchor="protocol" title="Protocol">
<t>The protocol uses DAO-like “MLAO” messages to announce membership to
the root as specified in <xref target="mlao"/>.</t>
<t>For downward messages, the root adds a new routing header that
includes a hash function identifier and a seed value; another one of
its fields gives the number of hash functions (k) to ask for k
instances of application of the hash function, with increasing seed.
The format of the new routing header is specified in <xref target="rh"/>.</t>
<t>Typical sizes of the bloom filter bitmap that the root inserts into
the packet can be 64, 128, or 256 bit, which may lead to acceptable
false positive rates if the total number of forwarders in the 10s and
100s. (To do: write more about the math here. Note that this number
tallies forwarding routers, not end hosts.)</t>
<t>A potential forwarder that receives a multicast packet adorned with a
constrained-cast routing header first checks that the packet is marked
with a RPL rank smaller than its own (loop prevention). If yes, it
then forwards the packet to all outgoing interfaces that match the
bloom filter in the packet.</t>
<section anchor="mlao" title="Multicast Listener Advertisement Object (MLAO)">
<t>The header format of the MLAO is depicted in
<xref target="target-option"/>. The basic structure of the MLAO message is similar
to the RPL Destination Advertisement Object (DAO). In particular, it
starts with RPL ICMP base header with a type value of 155 and the code
{IANA TBD1} (MLAO), followed by the Checksum, RPLInstanceID, parameters and
flags as in a DAO. <!-- WHAT? -->
<!-- A sequence number allows ordering of MLAOs -->
<!-- generated by a sender. --></t>
<figure title="RPL Target Option for MLAO" anchor="target-option"><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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| Group Address |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The group address field indicates the group that the sender of the MLAO is
interested in. This field usually contains a 128 bit IPv6 multicast
group address. Shorter group identifiers could be used together with a
protocol for explicit creation of groups. The MLAO message must have
at least one RPL target option to specify the address of the listener
that has generated the MLAO. The message is directed to the global
unicast address of the DODAG root and travels upwards the routing tree.</t>
<t><list style="hanging">
<t hangText='Note:'>
It has been suggested to use the RPL Transit Option (Type 0x06)
instead as it is used in Non-Storing mode to inform the DODAG root
of path attributes. Specifically, this option can be used to limit
the subscription by providing a proper Path Lifetime.</t>
</list></t>
</section>
<section anchor="rh" title="Routing Header">
<figure title="Routing header" anchor="rh-format"><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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Func set | Modulus |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Filter data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style="hanging">
<t hangText='Routing Type:'>
{IANA TBD2} 253</t>
<t hangText='Segments Left:'>
This value is always 0, so network nodes that do not support this
routing header do not generate ICMP6 error messages.</t>
<t hangText='Sequence Number:'>
16 bits sequence number. The number space is unique for a sequence
of multicast datagrams for a specific group that arrive at the DAG
root on their way up. The DAG root increments the number for each
datagram it sends down the respective DODAG.</t>
<t hangText='Func set:'>
The set of hash functions used to generate the Filter data value.</t>
</list></t>
<t>Note: As the function set contains a combination of several distinct
hash functions, it is currently unclear if 8 bits number space is
large enough.</t>
<t><list style="hanging">
<t hangText='Modulus:'>
The modulus that is used by the hash functions, minus 64 (the
minimum filter data size that can be used). The DAG root chooses the
modulus (and thus the filter data size) to achieve its objectives
for false positive rates (<xref target="false-positives"/>).</t>
<t hangText='Filter data:'>
A bit field that indicates which nodes should relay this multicast
datagram. The length of this field is a multiple of 8 bytes. The
actual length is derived from the contents of the field Header Ext
Length.</t>
</list></t>
<t>Note: The modulus could be derived from the length of the filter data
which is known from the extension header size. On the other hand,
keeping a separate record of the modulus means that the DAG root could
leave out 8-byte multiples of trailing zero bits if they happen to
occur. But then, a modulus that leaves 8-byte sequences of zero bits
in the filter is probably too large.</t>
</section>
</section>
<section anchor="implementation" title="Implementation">
<t>In 2013, Constrained-Cast was implemented in Contiki. It turns out
that forwarders can compute the hash functions once for their outgoing
interfaces and then cache them, simply bit-matching their outgoing
interface hash bits against the bloom filter in the packet (a match is
indicated when all bits in the outgoing interface hash are set in the
bloom filter).</t>
<t>The Root computes the tree for each multicast group, computes the
bloom filter for it, caches these values, and then simply adds the
bloom filter routing header to each downward packet. For adding a new
member, the relevant outgoing interfaces are simply added to the bloom
filter. For removing a leaving member, however, the bloom filter
needs to be recomputed (which can be sped up logarithmically if
desired).</t>
</section>
<section anchor="benefits" title="Benefits">
<t>Constrained-Cast:</t>
<t><list style="symbols">
<t>operates in Non-Storing Mode, with the simple addition of a
membership information service;</t>
<t>performs all routing decisions at the root.</t>
</list></t>
<t>Further optimizations might include using a similar kind of bloom
filter routing header for unicast forwarding as well (representing,
instead of the outgoing interface list, a list of children that
forwarding parents need to forward to).</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>The following registrations are done following the procedure specified
in <xref target="RFC6838"/>.</t>
<t>Note to RFC Editor: Please replace all occurrences of “&SELF;” with
the RFC number of this specification and “IANA TBD1” with the code
selected for TBD1 below and “IANA TBD2” with the value selected for
TBD2 below.</t>
<section anchor="icmpv6-parameter-registration" title="ICMPv6 Parameter Registration">
<t>IANA is requested to add the following entry to the Code fields of the
RPL Control Codes registry:</t>
<texttable>
<ttcol align='center'>Code</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBD1</c>
<c>MLAO</c>
<c>&SELF;</c>
</texttable>
</section>
<section anchor="ipv6-routing-type-registration" title="IPv6 Routing Type Registration">
<t>IANA is requested to add the following entries to the IPv6 Routing
Types registry:</t>
<texttable>
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBD2</c>
<c>CCast Routing Header</c>
<c>&SELF;</c>
</texttable>
</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>Thanks to Yasuyuki Tanaka for valuable comments.</t>
<t>This work has been supported by Siemens Corporate Technology.</t>
<!-- LocalWords: Datagram CoAP CoRE DTLS DCAF DCAF's introducer URI
-->
<!-- LocalWords: namespace Verifier JSON timestamp timestamps PSK
-->
<!-- LocalWords: decrypt UTC decrypted whitespace preshared HMAC
-->
<!-- LocalWords: multicast RPL DAOs DODAG IPv multicasts DAO MLAO
-->
<!-- LocalWords: datagrams datagram Contiki logarithmically unicast
-->
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC6550' target='http://www.rfc-editor.org/info/rfc6550'>
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
<author initials='T.' surname='Winter' fullname='T. Winter' role='editor'><organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert' role='editor'><organization /></author>
<author initials='A.' surname='Brandt' fullname='A. Brandt'><organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='R.' surname='Kelsey' fullname='R. Kelsey'><organization /></author>
<author initials='P.' surname='Levis' fullname='P. Levis'><organization /></author>
<author initials='K.' surname='Pister' fullname='K. Pister'><organization /></author>
<author initials='R.' surname='Struik' fullname='R. Struik'><organization /></author>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'><organization /></author>
<author initials='R.' surname='Alexander' fullname='R. Alexander'><organization /></author>
<date year='2012' month='March' />
<abstract><t>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6550'/>
<seriesInfo name='DOI' value='10.17487/RFC6550'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='I-D.ietf-bier-architecture'>
<front>
<title>Multicast using Bit Index Explicit Replication</title>
<author initials='I' surname='Wijnands' fullname='IJsbrand Wijnands'>
<organization />
</author>
<author initials='E' surname='Rosen' fullname='Eric Rosen'>
<organization />
</author>
<author initials='A' surname='Dolganow' fullname='Andrew Dolganow'>
<organization />
</author>
<author initials='T' surname='Przygienda' fullname='Tony Przygienda'>
<organization />
</author>
<author initials='S' surname='Aldrin' fullname='Sam Aldrin'>
<organization />
</author>
<date month='July' day='18' year='2016' />
<abstract><t>This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. Elimination of the per- flow state and the explicit tree-building protocols results in a considerable simplification.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-bier-architecture-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-bier-architecture-04.txt' />
</reference>
<reference anchor="BLOOM" target="http://doi.acm.org/10.1145/362686.362692">
<front>
<title>Space/time trade-offs in hash coding with allowable errors</title>
<author initials="B.H." surname="Bloom" fullname="Burton H. Bloom">
<organization></organization>
</author>
<date year="1970"/>
</front>
<seriesInfo name="ISSN" value="0001-0782"/>
<seriesInfo name="ACM Press" value="Communications of the ACM vol 13 no 7 pp 422-426"/>
</reference>
<reference anchor='RFC6554' target='http://www.rfc-editor.org/info/rfc6554'>
<front>
<title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></author>
<author initials='V.' surname='Manral' fullname='V. Manral'><organization /></author>
<date year='2012' month='March' />
<abstract><t>In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6554'/>
<seriesInfo name='DOI' value='10.17487/RFC6554'/>
</reference>
<reference anchor='RFC6838' target='http://www.rfc-editor.org/info/rfc6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<date year='2013' month='January' />
<abstract><t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:00:31 |