One document matched: draft-thubert-6lo-bier-dispatch-01.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 1.0.20 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc ipr="trust200902" docName="draft-thubert-6lo-bier-dispatch-01" category="std">
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>
<front>
<title>A 6loRH for BitStrings</title>
<author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization abbrev="Cisco">Cisco Systems</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street> <street>400, Avenue de Roumanille</street> <street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author initials="Z." surname="Brodard" fullname="Zacharie Brodard" >
<organization abbrev="Ecole Polytechnique">Ecole Polytechnique</organization>
<address>
<postal>
<street>Route de Saclay</street>
<city>Palaiseau</city>
<code>91128</code>
<country>FRANCE</country>
</postal>
<phone>+33 6 73 73 35 09</phone>
<email>zacharie.brodard@polytechnique.edu</email>
</address>
</author>
<author initials="H." surname="Jiang" fullname="Hao Jiang">
<organization abbrev="Telecom Bretagne">Telecom Bretagne</organization>
<address>
<postal>
<street>2, rue de la Châtaigneraie</street>
<city> Cesson-Sévigné</city>
<code>35510</code>
<country>FRANCE</country>
</postal>
<phone>+33 7 53 70 97 34</phone>
<email>hao.jiang@telecom-bretagne.eu</email>
</address>
</author>
<author initials="G." surname="Texier" fullname="Geraldine Texier">
<organization abbrev="Telecom Bretagne">Telecom Bretagne</organization>
<address>
<postal>
<street>2, rue de la Châtaigneraie</street>
<city> Cesson-Sévigné</city>
<code>35510</code>
<country>FRANCE</country>
</postal>
<phone>+33 2 99 12 70 38</phone>
<email>geraldine.texier@telecom-bretagne.eu</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>6lo</workgroup>
<abstract>
<t>This specification extends the 6LoWPAN Routing Header to signal BitStrings
such as utilized in Bit Index Explicit Replication and its Traffic
Engineering variant.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The type of information that needs to be present in a packet inside the LLN
but not outside of the LLN varies with the routing operation, but there is
overall a need for an extensible compression technique that would simplify
the IP-in-IP encapsulation, when needed, and optimally compress existing
routing artifacts found in LLNs.</t>
<t>The <xref target="I-D.ietf-roll-routing-dispatch"> 6LoWPAN Routing Header
</xref> (6LoRH) specification is such a technique, that extends the 6lo
adaptation layer framework <xref target="RFC4944"/>,<xref target="RFC6282"/>
so as to carry routing information for Route-over use cases. The original
specification includes the formats necessary for RPL such as the Source Route
Header (SRH) and is intended to be extended for additional routing artifacts.
</t>
<t>The Bit Index Explicit Replication (BIER), as introduced in the <xref target=
"I-D.ietf-bier-architecture"> BIER Architecture </xref>, can be used as
an alternate artifact to route multicast as well as unicast traffic.
The <xref target="I-D.eckert-bier-te-arch">Traffic Engineering for Bit Index
Explicit Replication</xref> (BIER-TE) adds support for traffic engineering by
explicit hop-by-hop forwarding and loose hop forwarding of packets along a
unicast route.
</t>
<t>This specification provides additional formats for the 6LoRH compression to
carry BitStrings such as used for Bit Index Explicit Replication and its Traffic
Engineering variant (BIER and BIER-TE, respectively).</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”,
and “OPTIONAL” in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
<t>The Terminology used in this document is consistent with and incorporates
that described in <xref target="RFC7102">Terms Used in Routing for Low-Power
and Lossy Networks (LLNs).</xref>.
</t>
<t>Other terms in use in LLNs are found in <xref target="RFC7228">
Terminology for Constrained-Node Networks</xref>.</t>
<t>The term “byte” is used in its now customary sense as a synonym for
“octet”.
</t>
<t>"RPL", "RPL Packet Information" (RPI) and "RPL Instance" are defined in the
<xref target="RFC6550">RPL: IPv6 Routing Protocol for Low-Power and Lossy
Networks</xref> specification.
</t>
<t>The terms Bit-Forwarding Egress Routers (BFR), BFR-id and BitString are
defined in <xref target="I-D.ietf-bier-architecture"/>.
A BitString indicates a continuous sequence of bits indexed by an
offset in the sequence. The leftmost bit is bit 0 and corresponds to the
value 0x80 of the leftmost octet in the BitString.
</t>
</section>
<section anchor="BIER-6LoRH-applicability" title="Applicability">
<t>BIER and other bit-indexed methods that would leverage BitStrings will
generally require additional information in the packet to complement the
BitString. For instance, BIER has the concept of a BFR-id and an Entropy
value in the BIER header. Since those additional fields depend on the
bit-indexed method, they are expected to be transported separately from
the BitString. This specification concentrates on the BitString alone.
</t><t>
Within the scope of <xref target="I-D.finn-detnet-architecture">Deterministic
Networking </xref> (DetNet), the <xref target="I-D.dt-detnet-dp-alt"> DetNet
Data Plane Protocol and
Solution Alternatives</xref> document details how BIER-TE can be leveraged to
activate the Deterministic Networking Replication and Elimination functions
in a manner that is abstract to the data plane forwarding information.
An adjacency, which is represented by a bit in the BIER header, can be mapped
in the data plane to an Ethernet hop, a Label Switched Path, or it may
correspond to a loose or a strict IPv6 Source Routed Path.
</t><t>
In the context of LLNs, the <xref target="I-D.ietf-6tisch-architecture">
6TiSCH Architecture</xref> introduces the concept of a Track that is a
directional traffic-engineered path between a source and a destination.
A Track is indicated in a packet by a Source or Destination IPv6 Address and
a RPL Local Instance. The RPL Instance is carried in an IPv6 packet as part
of the RPL Packet Information (RPI), and a bit in the RPI indicates whether
the Instance is Local to the Source or the Destination Address. The RPI can
be compressed as a RPI 6LoRH header (RPI-6LoRH) as described in
<xref target="I-D.ietf-roll-routing-dispatch"/>.
</t><t>
The <xref target="I-D.thubert-6tisch-4detnet">6TiSCH requirements for DetNet
</xref> indicate that a 6TiSCH Track may leverage replication and elimination
as defined in DetNet. This specification enables this behavior as follows: if
a BIER-6LoRH is positioned right after a RPI-6LoRH, then the BitString in the
BIER-6LoRH applies to the context of the Track indicated by the source or
destination address of the packet and the local Instance ID associated to the
source or destination of the packet.
</t>
</section>
<section anchor="BIER-6LoRH-encoding" title="The BIER-6LoRH encoding">
<t>The BIER 6LoRH (BIER-6LoRH) is a Critical 6LoWPAN Routing Header that
provides a variable-size container for a BitString such as, a but not limited
to, a BIER BitString.
</t>
<t>The capability to parse the BIER BitString is necessary to forward the packet
so the Type cannot be ignored.
</t>
<figure title="The BIER-6LoRH" anchor="BIERLoRH"><artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|0| Control |6LoRHType 15-24| BitString |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
]]></artwork></figure>
<t>
This specification provides a 5-bit Control field that can be used to
encode information that is specific to the BitString. The type and size
of the BitString are encoded in the 6LoRHType.
</t>
<section anchor="BbB" title="The Bit-by-bit BitStrings">
<t>In the bit-by-bit case, each bit is mapped in an unequivocal fashion with a
single addressable resource in the network. This may rapidly lead to large
BitStrings, and BIER allows to divide a network into groups that partition
the network so that a given BitString is locally significant to one group
only. This specification uses the 5-bits Control field to encode the group.
</t><t>
When groups are used, it may be that a packet is sent to different groups at
the same time. In that case, multiple BIER-6LoRH headers can be prepended to
a same packet, each one for a different group. As the packet flows along the
multicast distribution tree, a BIER-6LoRH header that has no more destination
in a given branch may be removed to make the packet shorter.
</t>
</section>
<section anchor="Badabloom" title="Bloom Filters"><t>
A Bloom Filter can be seen as a compression technique for the BitString. A
Bloom Filter may generate false positives, which, in the case of BIER, result
in undue forwarding of a packet down a path where no listener exists.
</t><t>
As an example, the <xref target="I-D.bergmann-bier-ccast">Constrained-Cast
</xref> specification employs Bloom Filters as a compact representation of a
match or non-match for elements in a set that may be larger than the number
of bits in the BitString.
</t><t>
In the case of a Bloom Filter, a number of Hash functions must be run to
obtain a multi-bit signature of an encoded element. This specification uses
the 5-bits Control field to signal an Identifier of the set of Hash functions
being used to generate a certain BitString, so as to enable the migration
from a set of Hash functions to the next.
</t>
</section>
<section anchor="types" title="Types of BIER-6LoRH header">
<t>The Type of a BIER-6LoRH header indicates the size of words used to build the
BitString and whether the BitString is operated as an uncompressed bit-by-bit
mapping, or as a Bloom filter.
</t>
<figure title="The BIER-6LoRH Types" anchor="BIERLoRHtype"><artwork><![CDATA[
+---------+--------------+----------------------+----------------+
| Type | Encoding | Control field | BitString Size |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| 15 | bit-by-bit | Group ID | 8 bits |
| 16 | bit-by-bit | Group ID | 16 bits |
| 17 | bit-by-bit | Group ID | 32 bits |
| 18 | bit-by-bit | Group ID | 64 bits |
| 19 | bit-by-bit | Group ID | 128 bits |
+---------+--------------+----------------------+----------------+
| 20 | Bloom filter | Hash function Set ID | 8 bits |
| 21 | Bloom filter | Hash function Set ID | 16 bits |
| 22 | Bloom filter | Hash function Set ID | 32 bits |
| 23 | Bloom filter | Hash function Set ID | 64 bits |
| 24 | Bloom filter | Hash function Set ID | 128 bits |
+---------+--------------+----------------------+----------------+
]]></artwork></figure>
<t>In order to address a potentially large number of devices, the BitString may
grow very large. Yet, the maximum frame size for a given MAC layer may limit
the number of bits that can be dedicated to routing. With this specification,
a number of BIER-6LoRH headers of a same type (bit-by-bit or Bloom filter)
may be placed contiguously in the packet. This results in a larger BitString
that is the concatenation of the BitStrings in the individual headers in the
order they are appearing in the packet.
</t>
</section>
</section>
<section anchor="impl" title="Implementation Status">
<t>A research-stage implementation was developed at Cisco's Paris Innovation Lab
(PIRL) by Zacharie Brodard. It was implemented on OpenWSN open-source firmware
and tested on the OpenMote-CC2538 hardware. It implements the header types 15,
16, 17, 18 and 19 (bit-by-bit encoding without group ID) in order to allow a
BIER-TE protocol over IEE802.15.4e.
</t><t>
Links:
<list>
<t>
github: https://github.com/zach-b/openwsn-fw/tree/BIER
</t><t>
OpenWSN firmware: https://openwsn.atlassian.net/wiki/pages/viewpage.action?pageId=688187
</t><t>
OpenMote hardware: http://www.openmote.com/
</t>
</list>
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The security considerations of
<xref target="I-D.ietf-roll-routing-dispatch"/> apply.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document extends the IANA registry created by
<xref target="I-D.ietf-roll-routing-dispatch"/>
for the 6LoWPAN Routing Header Type,
and adds the following values:</t>
<t><list style='empty'>
<t>15..24 : BIER-6LoRH [RFCthis]</t>
</list></t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t></t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-roll-routing-dispatch'?>
<?rfc include="reference.RFC.4944"?>
<?rfc include="reference.RFC.6550"?>
<?rfc include="reference.RFC.7102"?>
<?rfc include="reference.RFC.7228"?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.6282"?>
<?rfc include='reference.I-D.bergmann-bier-ccast'?>
<?rfc include='reference.I-D.thubert-6tisch-4detnet'?>
<!--?rfc include='reference.I-D.thubert-6lo-bier-dispatch'?-->
<?rfc include='reference.I-D.eckert-bier-te-arch'?>
<?rfc include='reference.I-D.ietf-bier-architecture'?>
<?rfc include='reference.I-D.finn-detnet-architecture'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
<?rfc include='reference.I-D.dt-detnet-dp-alt'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 02:59:03 |