<?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 include="reference.RFC.8300"?>

<rfc ipr="trust200902" docName="draft-thubert-roll-bier-02" category="std" updates="6282,6550,6775">

<?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"?>
<?rfc subcompact="yes"?>

<front>
  
    <title>RPL-BIER</title>

    <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization abbrev="Cisco">Cisco Systems, Inc</organization>
      <address>
         <postal>
            <street>Building D</street>
            <street>45 Allee des Ormes - BP1200 </street>
            <city>MOUGINS - Sophia Antipolis</city>
            <code>06254</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 497 23 26 34</phone>
         <email>pthubert@cisco.com</email>
      </address>
   </author>
   
   <!--
    
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization abbrev="Uni Bremen TZI">Universitaet 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>
-->
   <date/>
   <area>Routing</area>
   <workgroup>ROLL</workgroup>
    

<abstract>
<t>This specification extends RPL to provide unicast and multicast routing
   based on bitStrings such as used in Bit Index Explicit Replication and its
   source-routed Traffic Engineering variant, which correspond to RPL storing
   and Non-Storing Modes respectively. 
</t>
</abstract>


</front>

<middle>


<section anchor="introduction" title="Introduction">

<t>The design of Low Power and Lossy Networks (LLNs) is generally focused on
   saving energy, which is the most constrained resource of all. Other design
   constraints, such as a limited memory capacity, duty cycling of the LLN
   devices and low-power lossy transmissions, derive from that primary concern.
</t>


<t>The IETF produced the <xref target="RFC6550">"Routing Protocol for Low Power
   and Lossy Networks"</xref> (RPL) to provide routing services
   within such constraints. 
   In order to cope with lossy transmissions, RPL forms Direction-Oriented
   Directed Acyclic Graphs (DODAGs) that provide multiple forwarding solutions
   to most of the intermediate hops. 
   Because it is designed to adapt to fuzzy connectivity with lazy control, RPL
   can only provide a best effort routability, connecting most of the LLN nodes,
   most of the time.   
</t><t>
   RPL is a Distance-Vector protocol, which, compared to link-state protocols,
   limits the amount of topological knowledge that needs to be installed and 
   maintained in each node.
   RPL also leverages Routing Stretch to reduce further the amount of control
   traffic and routing state that is required to operate the protocol.
   Finally, broken routes may be fixed lazily and on-demand, based on dataplane
   inconsistency discovery, which avoids wasting energy in the proactive repair
   of unused paths.
</t>


<t>RPL enables various trade-offs between routing stretch, amount of
   routing state and packet size, with the introduction of different modes of
   operation (MOPs):
<list style="symbols">
    
<t>With Reactive Discovery of Point-to-Point (P2P) Routes (aka on-demand)
   <xref target="RFC6997"/><xref target="I-D.ietf-roll-aodv-rpl"/>,
   a limited number of routes are optimized on-demand, between select pairs of
   devices for which a service with some particular characteristics is needed.
</t><t>
   In Storing Mode of operation (aka Storing Mode), Multipoint to Point 
   (MP2P) routes from the LLN nodes to the root and Point to Multipoint (P2MP)
   routes from the root to the LLN nodes are optimized, but P2P routes
   between LLN nodes are stretched via a common parent. In Storing Mode, RPL
   requires that nodes maintain routing information for the maximum number of 
   child nodes in their sub-DODAG. If a network is composed of similar nodes,
   this means that each node should be able to store a number of routes that is
   in the order of the total number of nodes in the network. 
</t><t>
   In Non-Storing Mode of operation (aka Non-Storing Mode), MP2P and P2MP
   routes are also optimized, but downwards routes can only be computed by the
   root and P2MP forwarding relies on strict source-routing. This increases the
   size of the packets and limits the depth of the DODAG. The Non-Storing Mode
   also results in additional stretch for P2P routes, whereby all packets must
   transit via the root following the default route all the way up, to be then 
   source-routed down.
</t>
</list>
</t>
   
<t>In order to alleviate the issues above and improve the existing multicast
   operations, this specification introduces the use of bitStrings in RPL LLNs.
   BitStrings are already used in the art as a datapath analog to one or 
   more <xref target="RFC8200">IPv6</xref> addresses:
    
<list style="symbols">
    
<t>With the Bit Index Explicit Replication (BIER), introduced in the 
   <xref target="RFC8279">"BIER Architecture"</xref>, each
   it in a bitStrings represents a particular destination. This specification
   introduces a RPL-BIER Storing Mode that applies BIER operations to RPL
   Storing Mode.
</t><t>
   <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. With BIER-TE, each bit in a bitStrings represents a
   particular intermediate link. This specification introduces a RPL-BIER
   Non-Storing Mode that applies BIER-TE operations to RPL Non-Storing Mode.
</t>  
</list> 
</t> 
    
<t>This specification provides new signaling in RPL to enable RPL-BIER
   operations. In addition to classical bitStrings, this specification proposes
   an new technique that derives from Bloom Filters. This technique provides
   elasticity to the size of the bitString, which is not constrained to a 
   fixed number of entries, and a trade-off between the number of bits that are
   needed for routing and the chances to waste energy forwarding down a path
   where no target exist. The Bloom Filters mechanism applies to RPL-BIER in
   both modes of operations.
</t>
   
<t>In order to carry routing information in a concise fashion in a Low-Power
   Wireless Personal Area Network (6LoWPAN) for Route-Over use cases, the
   6LoWPAN adaptation layer framework <xref target="RFC4944"/>
   <xref target="RFC6282"/> was extended with the 6LoWPAN Routing Header
   (6LoRH) specification <xref target="RFC8138"/>, which uses the 6LoWPAN
   Paging Dispatch <xref target="RFC8025"/>. 
   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. A companion document to this, the
   <xref target="I-D.thubert-6lo-bier-dispatch">"6loRH for BitStrings"</xref>,
   specification, proposes new 6LoRH formats to enable the concise encoding of
   the BIER bitStrings and of the Bloom Filters described therein.
</t><t>
   In the current practice of LLN networks, the Non-Storing Mode is largely
   favored, because it does not place a restriction on how large a network
   formed of a particular device can become.
   One major benefit of introducing bitStrings is that the amount of state that
   is required for routing in Storing Mode is no more growing in the order of
   the total number of nodes in the network but linearly with the number of
   children attached to the RPL router. 
   In other words, the maximum number of children that a router is willing to 
   accept determines both the size of the Neighbor Cache for 6LoWPAN Neighbor
   Discovery (6LoWPAN ND)
   <xref target="RFC6775"/><xref target="I-D.ietf-6lo-rfc6775-update"/> and the
   size of the routing table that is required in RPL-BIER Storing Mode.
</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="RFC8279"/>. 
   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 byte in the BitString. 
   With this specification, a bitString maybe used to encode one or more
   unsigned integer(s) as a bit position in the bitString (bit-by-bit),
   or a Bloom filter.
</t>

</section>

<section anchor="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 and a 
   group identifier which enables a network to grow beyond the size of one
   bitString.
    </t><t>
   TBD Do we need entropy ? 
<!--vspace blankLines="100" /-->
</t>

</section>


<!--                               *****                     -->
<!--                               *****                     -->
<!--                               *****                     -->
<!--                               *****                     -->
<!--                               *****                     -->      
        

	
<section anchor="rplccmo" title="Extensions to RFC 6550">
<t>This specification introduces two new modes of operation for RPL, the
   RPL-BIER Non-Storing Mode which is discussed in <xref target="RBNS"/> and the
   RPL-BIER Storing Mode which is discussed in <xref target="RBS"/>. 
   A new Control Message Options (CMO) is introduced to transport the bitStrings
   in <xref target="BitStropt"/>.</t>
    
<section anchor="Biermops" title="RPL-BIER MOPs">

<t>In RPL-BIER modes of operation, one or more RPL Target Option are replaced 
   by a new BitString Information Option which represent the advertised target(s) by a combination of a bitString and control information. 
   
</t>

<section anchor="RBNS" title="RPL-BIER Non-Storing Mode">
<t>In Non-Storing RPL-BIER, a bit in classical BIER bit-by-bit bitStrings 
   (see <xref target="bierbstr"/>) or a set of bits in a Bloom Filter 
   (see <xref target="Badabloom"/>) is associated to a next-hop from the
   perspective of an intermediate router. RPL Non-Storing Mode DAO messages are
   used to advertise the relation between a target and its parent (transit) 
   directly to the root.
</t><t>
   If multiple Targets Options were to be placed consecutively to factorize a 
   Transit Information Option (TIO) in a classical RPL Non-Storing Mode DAO message, they are replaced by a single BIO with the aggregated bitString 
   that represents all these targets.
</t>
</section>


<section anchor="RBS" title="RPL-BIER Storing Mode">
<t>
   In RPL-BIER Storing Mode, a bit in classical BIER Bit-by-bit bitStrings 
   (see <xref target="bierbstr"/>) or a set of bits in a Bloom Filter 
   (see <xref target="Badabloom"/>) is associated to a final destination.
   RPL Storing Mode DAO messages are used to advertise recursively the targets
   to the parent(s) all the way to the root.
</t><t>
   The BitString Information Option(s) in the DAO message contain collectively
   an aggregated bitString that represents the advertising node and all of 
   its descendants. 
   Parents save the bitString per child, and use it to forward down the DODAG 
   as discussed in <xref target="bitfwd"/>.
</t><t>
   The Transit Information Option is not used. The lack of transit information
   is compensated by a more frequent transmission of DAO messages and a full 
   use of the RPL data plane loop avoidance and inconsistency detection 
   mechanisms (section 11.2 of  <xref target="RFC6550"/>), in collaboration 
   with a periodic 6LoWPAN ND (re)registration that maintains the 6LBR
   and the root aware of which devices are actually present in the network
   with the associated lifetime and sequence information.
</t>
</section>
</section>

<section anchor="BitStropt" title="BitString Information">
<t>Section 6.7 of <xref target="RFC6550"/> specifies optional CMOs to be placed
   in RPL messages such as the Destination Advertisement Object (DAO) message. 
   The RPL Target Option and the Transit Information Option (TIO) are such
   optional fields; the former indicates a node to be reached and the latter
   specifies a parent that can be used to reach that node. Options may be
   factorized; one or more contiguous TIOs apply to the one or more contiguous
   Target options that immediately precede the TIOs in the RPL message.
   </t>
   <t>This specification introduces a new CMO, the BitString Information option
   (BIO). A BIO is used as an alternate to one or more Target Option(s) in
   Storing and Non-Storing Mode DAOs using bit-by-bit bitStrings, and its format
   is as follows:
   </t> 
<figure anchor="BIO" title="BitString Information option format">
              <artwork>
     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 = 0x0B | Option Length | BitStringType |   Group ID    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                     BitString                              .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </artwork>
</figure>
	
<t>
<list hangIndent="16" style="hanging">
<t hangText="Option Type:">0x0B (to be confirmed by IANA)</t>
<t hangText="Option Length:">In bytes; variable, depending on the Type.</t>
<t hangText="BitString Type:">Indicates the size of the bitString field as 
   indicated in <xref target="RPLBIERtype"/> below.
</t>
</list>
</t>
<texttable  anchor="RPLBIERtype" style="all" suppress-title="true">
<ttcol align="center">BitString Type</ttcol>
                            <ttcol align="left">BitString Size</ttcol>
                   <c>15</c>               <c>  8 bits</c>
                   <c>16</c>               <c> 16 bits</c>
                   <c>17</c>               <c> 48 bits</c>
                   <c>18</c>               <c> 96 bits</c>
                   <c>19</c>               <c>160 bits</c>
</texttable>
<t>
<list hangIndent="16" style="hanging">
            
<t hangText="Group ID :">8-bit unsigned integer. The Group ID for
             the bit-by-bit bitString.</t>
<t hangText="BitString:">8 to 160 bits, depending on the Type.
</t>
</list>
</t>

<!--vspace blankLines="100" /-->
</section>
    
 


</section>


<!--                               *****                     -->
<!--                               *****                     -->
<!--                               *****                     -->
<!--                               *****                     -->
<!--                               *****                     -->

 
<section anchor="upd6lo" title="Updating the 6LoWPAN Framework">

<section anchor="upd6lond" title="Extensions to  RFC 6775">

<t>
   It is noted that RPL does not provide a Duplicate Address Detection (DAD)
   and relies on 6LoWPAN ND to ensure that addresses are unique within the network. For that purpose, a 6LoWPAN Border Router (6LBR) maintains the 
   list of addresses that are currently in use in the network that it serves.
   In the case of a RPL LLN, the 6LBR is typically collocated with the RPL 
   root, and serves the RPL DODAG. With 6LoWPAN ND<xref target="RFC6775"/>
   <xref target="I-D.ietf-6lo-rfc6775-update"/>,
   a Duplicate Address Request (DAR) / Duplicate Address Confirmation (DAC)
   exchange is used to perform the DAD operation .
   Scalability is achieved by federating multiple DODAGs with IPv6 Backbone 
   Routers (6BBRs) <xref target="I-D.ietf-6lo-backbone-router"/>.
</t><t>
   In that context, it makes sense to also leverage the 6LBR to ensure that a
   tuple (groupID, bitString) is assigned unequivocally to an IPv6 address for
   the bit-by-bit operation. This specification extends the role of a 6LBR to
   1) assign the tuple to the IPv6 address and 2) resolve an IPv6 address into a
   tuple. To achieve this, RFC 6775 is updated as follows:
<list style="symbols">
<t>
   A BIER Address Resolution (BAR) / BIER Address Confirmation (BAC) exchange 
   is introduced for the purpose of the bitString lookup operation 
   (see <xref target="bierbstralloc"/>). 
</t><t>
   A new Bit Position Option (BPO) is introduced to carry the corresponding bit position bitString in 6LoWPAN ND exchanges. The BPO is transported in
   BAC, NA and DAC messages in response to BAR, NS and DAR messages,
   respectively (see <xref target="Bitndopt"/>).
</t>
</list>
</t>

</section>

<section anchor="upd6lohc" title="Extensions to RFC 6282">
<t>
   This specification also extends the 6LoWPAN framework with the capability to
   transform an address into a tuple (Control field, bitString) as part of 
   the <xref target="RFC6282">6LoWPAN Header Compression</xref> (6LoWPAN HC). 
   Since the 6LBR and the Header Compression functions are typically 
   collocated, the latter may exploit local tables built by the former to
   map a destination IPv6 address into a bitString.
</t><t>
   In Storing Mode, P2P stretched routing via a common parent can be obtained
   if the destination is expressed as a tuple (Control field, bitString).
   This can be achieved with a BAR/BAC exchange with the 6LBR.
</t>

</section>

<section anchor="newnd" title="New Neighbor Discovery Options and Messages">
<t>In order to allocate and lookup a bitString, this specification 
   extends 6LoWPAN ND with the following new messages and formats.
</t>


<section anchor="Bitndopt" title="6LoWPAN ND Bit Position Option">
<t>The Bit Position Option (BPO) is intended to be used to return a bitString 
   and related information in 6LoWPAN ND BA, DAC and BAC messages with a Status of 0 indicating success, the NA and DAC messages transporting an 
   Address Registration Option (ARO) indicating the IPv6 address that is
   mapped with the bit position. Its format is as follows:
   </t> 
   
<figure anchor="bo" title="Bit Position Option format">
<artwork>
     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     |     Length    |   Group ID    | Bit Position  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reserved                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
	
<t> Option Fields
<list hangIndent="16" style="hanging">
<t hangText="Type:">38 (to be confirmed by IANA)</t>
<t hangText="Length:">8-bit unsigned integer.  The length of the
   option (including the type and length fields) in units of 8 bytes.
   The Length MUST be set to 1.</t>

<t hangText="Group ID:">8-bit unsigned integer. The GroupID for
             the bit-by-bit bitString.</t>
<t hangText="Bit Position:">8-bit unsigned integer. The offset in the
             the bit-by-bit bitString.</t>

</list>
</t>
   
<!--
<figure anchor="bo" title="Bit Position Option format">
<artwork>
     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     |     Length    | Control | rsv | Bit Position  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .            BitString (and optionally Padding)                 .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
	
<t> Option Fields
<list hangIndent="16" style="hanging">
<t hangText="Type:">38 (to be confirmed by IANA)</t>
<t hangText="Option Length:">8-bit unsigned integer.  The length of the
   option (including the type and length fields) in units of 8 bytes.</t>
<t hangText="bitStringType:">Indicates the type of the Control Field and 
   the size of the BitString field as shown in <xref target="NDBIERtype"/> 
   below.</t>
<t hangText="Control Field:">5-bit unsigned integer. The Group ID for
             the bit-by-bit bitString, or the Hash function Set ID.</t>
<t hangText="BitString:">8 to 160 bits, depending on the Type.</t>


<t hangText="Padding:">Completes the option to the next multiple of 8 octets.
   For instance, for a BitString Size of 16 bits, the Length is 1, and there
   are 16 bits of padding. For a BitString Size of 160 bits, the Length
   is 3 and there is no padding.</t>
</list>
</t>
<texttable anchor="NDBIERtype" style="all" suppress-title="true">
<ttcol align="center" width="13%">
   BitString Type</ttcol>
   <ttcol align="center">
                Encoding</ttcol>
               <ttcol align="center">Control field</ttcol>
                        <ttcol align="center" width="13%">BitString Size</ttcol>
   <c>15</c> <c>bit-by-bit  </c>  <c>Group ID            </c> <c>  8 bits</c>
   <c>16</c> <c>bit-by-bit  </c>  <c>Group ID            </c> <c> 16 bits</c>
   <c>17</c> <c>bit-by-bit  </c>  <c>Group ID            </c> <c> 32 bits</c>
   <c>18</c> <c>bit-by-bit  </c>  <c>Group ID            </c> <c> 96 bits</c>
   <c>19</c> <c>bit-by-bit  </c>  <c>Group ID            </c> <c>160 bits</c>
   <c>20</c> <c>Bloom filter</c>  <c>Hash function Set ID</c> <c>  8 bits</c>
   <c>21</c> <c>Bloom filter</c>  <c>Hash function Set ID</c> <c> 16 bits</c>
   <c>22</c> <c>Bloom filter</c>  <c>Hash function Set ID</c> <c> 32 bits</c>
   <c>23</c> <c>Bloom filter</c>  <c>Hash function Set ID</c> <c> 96 bits</c>
   <c>24</c> <c>Bloom filter</c>  <c>Hash function Set ID</c> <c>160 bits</c>
                   
</texttable>

-->
</section>

<section anchor="lookup" title="Address Mapping Message">
<t>For the multihop lookup exchanges between a 6LR that needs to perform a
   Header Compression including the bitString for the destination, and its 6LBR, which knows if the mapping exists and what it is, this specification
   introduces two new ICMPv6 message called the BIER Address Resolution 
   (BAR) and the BIER Address Confirmation (BAC).  We avoid reusing the NS
   and NA messages for this purpose, since these messages are not subject to
   the hop limit=255 check as they are forwarded by intermediate 6LRs.
</t><t>
   The BAR and BAC use the same ICMPv6 type value which this specification, allocates for a generic Address Mapping service, but use different Codes.
   This is done to save addressable space in the ICMPv6 type values which is
   getting crowded, and because it is expected that in the future, other 
   mapping techniques may be needed as well. 
</t><t>
   The Status field and Information Lifetime are not meaningful in the BAR 
   message. When and only when the BAC message carries a status of 0, indicating success, the Information Lifetime must contain valid information
   and the message must carry a <xref target="Bitndopt">Bit Position Option</xref>.
</t>
  
<figure title="Address Mapping Message format" anchor="BARBAC"><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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Status     |   Reserved    |     Information Lifetime      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Looked-up Address                       +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
]]></artwork></figure>

<t> Message Fields
<list hangIndent="16" style="hanging">
<t hangText="Type:">160 (to be confirmed by IANA)</t>
<t hangText="Code:">8-bit unsigned integer. 1 for BAR and 2 for BAC.
   Other values are reserved.</t>
<t hangText="Checksum::"> The ICMP checksum. See <xref target="RFC4443"/>.</t>
<t hangText="Status:">8-bit unsigned integer. Indicates the status of the 
   lookup in the BAC. See <xref target="status"/> below.</t>
</list>
</t>
<texttable  anchor="status" style="all" suppress-title="true">
<ttcol align="center">Status</ttcol>
              <ttcol align="center">Description</ttcol>
                   <c>0</c>      <c>Success</c>
                   <c>1</c>      <c>Looked-up Address not Found</c>
                   <c>2..255</c> <c>Allocated using Standards Action
                                    <xref target="RFC8126"/></c>
                   
</texttable>
<t>
<list hangIndent="16" style="hanging">
<t hangText="Information Lifetime:">16-bit unsigned integer.  The length of
   time in units of 60 seconds (relative to the time the packet is received)
   that this mapping information is valid.  A value of all zero
   bits (0x0) assumes a default value of 10,000 (~one week).</t>
<t hangText="Looked-up Address:">128-bit field.  Carries the IPv6 address that
   is being mapped.</t>
</list>

</t>

<!--vspace blankLines="100" /-->
</section>


</section>


</section>

<section anchor="Bitstr" title="BitString formats">

<t>This specification introduces two BitString formats, the bit-by-bit and the 
   Bloom Filter. 
</t>

<section anchor="bierbstr" title="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. In RPL-BIER Storing Mode, this is an IPv6 address as advertised in RPL Storing Mode DAO messages, whereas 
   in RPL-BIER Non-Storing Mode, this is a parent-child relationship as 
   advertised in RPL Non-Storing Mode DAO messages.
 </t><t>
   if every node in a large network is given one or more bits in a bit-by-bit 
   bitString, then the bitString may grow very large and lead to undesirably 
   large overhead in the data plane. 
   BIER allows to divide a potentially the very large abstract bitString into segments, aka groups, indexed by a groupID. 
 </t><t>
   In the protocol elements that use a bitString, only the relevant group(s)
   are transported, and the advertised bitString is in fact the segment that 
   corresponds to the groupID. It results that a bit position in the large 
   abstract bitString is advertised either as the tuple (groupID, segment) or
   the tuple (groupID, bit position within segment). 
   
 </t><t>
   For simplicity, when dealing with protocol elements, the specification uses the term bitString to refer to the tuple (groupID, segment) and a 
   bitwise operation between bitStrings is really a bitwise operation between
   segments of a same groupID.
   
 </t><t>
   TBD: do we allow multiple (groupID, bitString) tuples in one packet?
</t>

<section anchor="bierbstralloc" title="Allocating a Bit Position in a Bit-by-bit BitString">

<t>Several methods may be used to associate a bit in a biString to an IPv6
   address. In order to guarantee interoperability, this specification
   RECOMMENDS that all implementations provide at least the method described 
   therein.   
</t><t>
   With 6LoWPAN ND, a 6LoWPAN Node (6LN) registers with address(es) to one or 
   more 6LoWPAN Router <xref target="RFC6775"/> to perform Duplicate 
   Address Detection (DAD). As part of the DAD process, the 6LN validates 
   that a Global Unicast Address (GUA) or a Unique Local Address (ULA) is 
   effectively unique using a unicast DAR/DAC exchange with the 6LBR (this
   procedure is updated in <xref target="I-D.ietf-6lo-rfc6775-update"/>).
</t><t>
   In a network that supports this specification, the 6LBR maintains a 
   configurable number of groups (up to 32, indexed by groupID), and for each 
   group, it maintains a pool of free bit positions. Upon a new registration,
   the 6LBR selects a groupID and a free bit position and associates it to the
   IPv6 address.
</t><t>
   The bitString Size in any given group should be configurable. The policy for selecting the groupID for a new registration is left to implementation. 
   It is noted that in large networks that require multiple groups, associating
   groups with immediate children of the root may be an option to limit the
   number of groups that the RPL routers must be aware of.
</t><t>
   If the 6LBR accepts the registration, then it returns a DAC message with a
   status of 0 indicating success, adding
   a <xref target="Bitndopt" >6LoWPAN ND Bit Position Option</xref> to the DAC
   message to indicate the groupID and bit. 
</t><t>
   The 6LR maintains a binding cache entry (BCE) for the 6LN based on
   successful DAC messages. With this specification, the 6LR also stores the 
   matching between the address and the bitString and uses it for searching
   its children when forwarding packets in Non-Storing Mode (see
   <xref target="bitfwd"/>). 
</t><t>  
   If the 6LN child does not support the BIER encoding
   (e.g.<xref target="I-D.thubert-6lo-bier-dispatch"/>), then the packet is
   converted in a format that the child supports 
   (e.g.<xref target="RFC8138"/>). 
</t>


</section>

<section anchor="bierbstradv" title="Aggregation of Bit-by-bit BitStrings">

<t>BitStrings are aggregated by a 'OR' operation so that all the bits that
   are set in either bitString is set in the resulting bitString.
   In the concise form of a tuple (groupID, bitString), the aggregation is
   done on a group-by-group basis, between segments of a same group.

</t><t>
   In RPL-BIER Storing Mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL Storing Mode
   <xref target="RFC6550"/>.
   The <xref target="BIO">BitString Information option</xref> is used in
   replacement of the Target option. A DAO message contains one BIO per 
   group, and the parent that receives the messages associates the BIO
   information to the advertising child.
   In order to build a DAO message, the parent regenerates its own BIO, one 
   per group, by aggregating the bitStrings from all of its children with its 
   own, and places the resulting BIOs in the DAO message.
</t>

</section>

<section anchor="bitfwd" title="Forwarding Based on Bit-by-bit BitStrings">

<t>Forwarding is based on matching a bitString in a packet with those of   
   children. For unicast packets, only one matching child gets the packet. For 
   multicast packets, all matching children get a copy. Matches are found by
   scanning all children and performing bitwise operations as follows.
</t><t>  
   In order to search for a match, a reference bitString is initialized with
   the destination bitString in the packet.
   A match is found with a child if the bitwise 'AND' between the reference 
   bitString and the bitString stored for that child does not result
   in a NULL bitString of all zeroes.
</t><t>
   In Non-Storing Mode, a packet is copied to all matching children, which
   are found by trying all children.
</t><t>
   In Non-Storing Mode, if a child is selected for forwarding,
   then an 'XOR' operation is performed between the reference bitString
   and the bitString resulting from the 'AND' operation. If the 'XOR' operation
   does not result in a NULL bitString, denoting that more children should get
   the packet, then the result of the 'XOR' operation becomes the new 
   reference bitString and the search continues.
   The 'XOR' operation allows to stop the search loop as soon as all matches 
   are found; it also avoids forwarding twice to a same destination along
   different downwards path in the DODAG. 
</t>

</section>

<section anchor="bitrelm" title="Reliable Multicast based on Bit-by-bit BitStrings">
<t>Multicast from the root to a a collection of target 6LNs can be made
   reliable with the following operation:
</t><t> 
   A multicast packet is identified by a unique packetID which is also found 
   in the acknowledgments. The root signals the set of targets with a 
   destination bitString that has the bits set for each of them, and the
   message is forwarded as described on <xref target="bitfwd"/>.
</t><t> 
   Listeners acknowledge with an acknowledgment packet that contains the same
   information, the packetID and the bitString representing the listener. The
   bitStrings in acknowledgment packets are aggregated recursively on the way 
   back as indicated in <xref target="bierbstradv"/>.
</t><t>
   The root aggregates the bitStrings from its children into one
   acknowledgment bitString. It then checks that the acknowledgment bitString
   is correct, by and 'AND' operation with the destination bitString that 
   should result in the acknowledgment bitString. If this is not the case, bits
   that are set in the acknowledgment bitString and not in the destination 
   bitString are in the acknowledgment bitString.
</t><t>
   The root generates the bitString of the devices that did not acknowledge the
   multicast message by a bitwise 'XOR' operation between the destination 
   bitString and the acknowledgment bitString, and may use it to selectively 
   retry the multicast.
</t>
</section>

</section>
<section anchor="Badabloom" title="Bloom Filters">

<t>A Bloom Filter can be seen as an additional compression technique for the
   bitString representation. 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 anchor="hashfuncompu" title="Computing and Saving Bloom Filters">

</section>

<section anchor="bloomfwd" title="Forwarding based on Bloom Filters">

</section>

<section anchor="hashfundistalloc" title="Hash Functions Distribution">

<!--vspace blankLines="100" /-->
</section>


</section>
</section>


<section anchor="impl" title="Implementation Status">
<t>TBD</t>
</section>


<section anchor="security-considerations" title="Security Considerations">

<t>TBD</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

    <t>This document extends the IANA registry created by RFC 6550 for RPL
    Control Codes as follows:</t>

        <texttable title="RPL Control Codes">
          <ttcol align="center">Code</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>


          <c>0x0B</c>

          <c>bitString</c>

          <c>This document</c>
        </texttable>


    <t>This document is updating the registry created by RFC 6550 for the RPL
        3-bit Mode of Operation (MOP) as follows:
        </t>

        <texttable title="DIO Mode of operation">
          <ttcol align="center">MOP value</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>6</c>

          <c>RPL-BIER Non-Storing Mode of operation</c>

          <c>This document</c>

          <c>7</c>

          <c>RPL-BIER Storing Mode of operation</c>

          <c>This document</c>

        </texttable>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t></t>

</section>


  </middle>

    <back>
    <references title='Normative References'>
	  <?rfc include="reference.RFC.2119"?>
	  <?rfc include="reference.RFC.4443"?>
	  <?rfc include="reference.RFC.6550"?>
	  <?rfc include="reference.RFC.6775"?>
      <?rfc include="reference.RFC.8200"?>
      <?rfc include="reference.RFC.8279"?>
     
    </references>
    <references title='Informative References'>

	  <?rfc include="reference.RFC.4944"?>
	  <?rfc include="reference.RFC.7102"?>
	  <?rfc include="reference.RFC.8126"?>
	  <?rfc include="reference.RFC.7228"?>
	  <?rfc include="reference.RFC.8025"?>
	  <?rfc include="reference.RFC.8138"?>
      <?rfc include="reference.RFC.6282"?>
      <?rfc include='reference.I-D.ietf-roll-aodv-rpl'?>
      <?rfc include="reference.RFC.6997"?>
      <?rfc include='reference.I-D.thubert-6lo-bier-dispatch'?>
      <?rfc include='reference.I-D.bergmann-bier-ccast'?>
      <?rfc include='reference.I-D.eckert-bier-te-arch'?>
      <?rfc include='reference.I-D.ietf-6lo-rfc6775-update'?>
      <?rfc include='reference.I-D.ietf-6lo-backbone-router.xml'?>
       
      

    </references>
    </back>
</rfc>

