<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
     docName="draft-chen-bier-te-enc-04"
     ipr="trust200902">
  <front>
    <title abbrev="BIER-TE Encaps">BIER-TE Encapsulation with Multiple BitStrings</title>

     <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>hchen.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>

    <author fullname="Ran Chen" initials="R" surname="Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
      </address>
    </author>

    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <postal>
          <street>13101 Columbia Pike</street>
          <city>Silver Spring</city>
          <code>MD 20904</code>
          <country>USA</country>
        </postal>
        <phone> 301 502-1347</phone>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

     <author initials="A" fullname="Aijun Wang" 
            surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>
          <city>Beijing</city>
          <region> </region>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

   <author initials="Y" fullname="Yanhe Fan" 
            surname="Fan">
      <organization>Casa Systems</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>yfan@casa-systems.com</email>
      </address>
    </author>

   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

  <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>IBM Corporation</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2024"/>

    <abstract>
      <t>This document describes a  
         "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) 
         header, two levels of Bit Index Forwarding Tables (BIFTs) 
         and a forwarding procedure
         for efficiently processing BIER-TE packets with the header. 
         For a multicast packet with an explicit point-to-multipoint 
         (P2MP) path, which has multiple BitStrings,
         the packet with the header containing the BitStrings is replicated
         and forwarded statelessly along the path.</t>
    </abstract>

    <note title="Requirements Language">
      <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"/> <xref target="RFC8174"/> 
      when, and only when, they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
     <t><xref target="RFC9262"/> introduces Bit Index 
        Explicit Replication (BIER) Traffic/Tree Engineering (BIER-TE).
        It is an architecture for per-packet stateless explicit  
        point to multipoint (P2MP) multicast path/tree.</t>

     <t>A Bit-Forwarding Router (BFR) in a BIER-TE domain has 
        a BIER-TE Bit Index Forwarding Tables (BIFT).
        A BIER-TE BIFT on a BFR comprises a forwarding entry for 
        a BitPosition (BP) assigned to each of the adjacencies of the BFR. 
        If the BP represents a forward connected adjacency, 
        the forwarding entry for the BP forwards the multicast packet 
        with the BP to the directly connected BFR neighbor of the adjacency.
        If the BP represents a BFER (i.e., egress node) 
        or say a local decap adjacency,
        the forwarding entry for the BP decapsulates the multicast packet
        with the BP and passes a copy of the payload of the packet
        to the packet's NextProto within the BFR. </t>

     <t>
<xref target="RFC8296"/> defines the BIER header 
with one BitString with Default BitStringLength value of 256. 
        However, for a BIER-TE path from an ingress to
        multiple egresses (or say destinations),
        the bit positions representing the path 
        may not be in one BitString. 
        The existing BIER header does not work for the BIER-TE path
        with more than one BitString. </t>

     <t>This document proposes a solution for a BIER-TE header
        to resolve this issue. 
        The BIER-TE header can contain all the bit positions 
        of a BIER-TE path.
        These bit positions are encoded in one or more BitStrings. 
 
        The document presents an enhanced forwarding procedure for 
        efficiently processing the BIER-TE header
        with multiple BitStrings.</t>

    <section title="Terminology">
      <t>
      <list style="hanging" hangIndent="6">
       <t hangText="BIER:">Bit Index Explicit Replication.</t>
       <t hangText="BIER-TE:">BIER Traffic Engineering.</t>
       <t hangText="BFR:">Bit-Forwarding Router.</t>
       <t hangText="BFIR:">Bit-Forwarding Ingress Router.</t>
       <t hangText="BFER:">Bit-Forwarding Egress Router.</t>
       <t hangText="BFR-id:">BFR Identifier. 
          It is a number in the range [1,65535].</t>
       <t hangText="BFR-NBR:">BFR Neighbor.</t>

       <t hangText="BFR-prefix:">An IP address (either IPv4 or IPv6) of a BFR.</t>
       <t hangText="BIRT:">Bit Index Routing Table. 
          It is a table that maps from the BFR-id (in a particular sub-domain)
          of a BFER to the BFR-prefix of that BFER, and to the BFR-NBR 
          on the path to that BFER.</t>
       <t hangText="BIFT:">Bit Index Forwarding Table.</t>

       <t hangText="IGP:">Interior Gateway Protocol.</t>
       <t hangText="LSDB:">Link State DataBase.</t>
       <t hangText="OSPF:">Open Shortest Path First.</t>
       <t hangText="IS-IS:">Intermediate System to Intermediate System.</t>
       <t hangText="SI:">Set Identifier.</t>
       <t hangText="BP:">Bit Position.</t>

      </list></t>
    </section> <!-- Terminology -->

    </section> <!-- Introduction -->


   <section title="Example BIER-TE Path with Multiple BitStrings">
      <t>This section illustrates an example BIER-TE domain topology
         and a BIER-TE paths across the domain.
         The path has multiple sets of bit strings, 
         i.e., multiple BitStrings with different SIs 
         (or multiple BitStrings for short).
          The packet to be transported
         by this path must contains the
         multiple BitStrings in the header of the packet.
         If the header can contain only one BitString,
           the packet to be transported by the path cannot
           be delivered to the egresses of the path.
       </t>

      <section title="Example BIER-TE Topology">
        <t>An example BIER-TE topology for a BIER-TE domain is shown
           in <xref target="bier-top-1"/>.

           It has 9 nodes/BFRs A, B, C, D, E, F, G, H and I.
           Nodes/BFRs D, F, E, H and A are BFERs and have 
           local decap adjacency BitPositions 1, 2, 3, 4, and 5 respectively.
           For simplicity, these BPs are represented by (SI:BitString),
           where SI = 0 and BitString is of 8 bits. 
           BPs 1, 2, 3, 4, and 5 are represented by
           1 (0:00000001), 2 (0:00000010), 3 (0:00000100), 4 (0:00001000) 
           and 5 (0:00010000) respectively.

           <figure anchor="bier-top-1" 
           title="Example BIER-TE Topology">
  <artwork align="center"> <![CDATA[
                             6'      19'       20'   4 
                     /----------( G )---------------( H )
                    /          18'\               16'/
                   /               \17'             /
                  /               ( I )____________/    
                 /             14'/      15'     
                /                /                     
      8'   7'  /5'  3'     4'   /13'           12'     
( A )--------( B )------------( C )-----------------( D ) 1
  5            \1'              \9'   11'            /24'
                \                \                  /
                 \2'   21'   22'  \10'             /
                ( E )------------( F )____________/
                  3                2   23'          ]]></artwork>
</figure>

            The BitPositions for the forward connected adjacencies 
            are represented by i', where i is from 1 to 24. 
            In one option, they are encoded as (n+i), 
            where n is a power of 2 such as 32768.
            For simplicity, these BitPositions are represented 
            by (SI:BitString),
            where SI = (6 + (i-1)/8) and BitString is of 8 bits. 
            BitPositions i' (i from 1 to 24) are represented by
            1'(6:00000001), 2'(6:00000010), 3'(6:00000100), 4'(6:00001000), 
            5'(6:00010000), 6'(6:00100000), 7'(6:01000000), 8'(6:10000000),
            9'(7:00000001), 10'(7:00000010), . . . , 24'(8:10000000).</t>

        <t>For a link between two nodes X and Y, 
           there are two BitPositions for two forward connected adjacencies.
           These two forward connected adjacency BitPositions are assigned 
           on nodes X and Y respectively. 
           The BitPosition assigned on X is the forward connected 
           adjacency of Y.
           The BitPosition assigned on Y is the forward connected 
           adjacency of X.</t>

        <t>For example, for the link between nodes B and C in the figure,
           two forward connected adjacency BitPositions 3' and 4' are assigned
           to two ends of the link.
           BitPosition 3' is assigned on node B to B's end of the link. 
           It is the forward connected adjacency of node C.
           BitPosition 4' is assigned on node C to C's end of the link. 
           It is the forward connected adjacency of node B.</t>

      </section> <!-- Example BIER-TE Topology -->


      <section title="BIER-TE Path with Multiple BitStrings">
        <t>One BIER-TE path is the explicit multicast P2MP path from 
           ingress A to egresses D and F, traversing from A to B to C, and 
           from C to D and F.
           This path is represented by BPs as {7', 4', 12', 10', 1, 2},
           which is {7'(6:01000000), 4'(6:00001000), 
           12'(7:00001000), 10'(7:00000010), 1(0:00000001), 2(0:00000010)}.
           These six bit positions on the path are in three sets of
           bit strings with SI = 0, 6 and 7.</t>

        <t>Bit positions 1 and 2 are in the set with SI = 0, 
           which is (0:00000011).
           Bit positions 7' and 4' are in the set with SI = 6, 
           which is (6:01001000).
           Bit positions 12' and 10' are in the set with SI = 7,
           which is (7:00001010).
        </t>

        <t>At ingress A, the packet to be transported by the path
           must be encapsulated in a BIER-TE header containing
           all three sets of bit strings. These sets represent 
           the bit positions {7', 4', 12', 10', 1, 2} on the path.</t>

        <t>The packet with the BIER-TE header is delivered 
           from ingress A to BFR B 
           using bit position 7' with SI = 6 in the header.
           BFR B forwards the packet to BFR C 
           using bit position 4' with SI = 6 in the header. 
           BFR C forwards a copy of the packet to BFER D
           using bit position 12' with SI = 7 in the header and 
           another copy to BFER F 
           using bit position 10' with SI = 7 in the header.
           BFER D decapsulates the packet and sends the payload
           of the packet to the packet's nextproto within BFER D
           using bit position 1 with SI = 0 in the header.
           BFER F decapsulates the packet and sends the payload
           of the packet to the packet's nextproto within BFER F
           using bit position 2 with SI = 0 in the header.</t>

        <t>If a BIER-TE header can contain only one set of bit strings,
           the packet to be transported by the path cannot
           be delivered to the egresses of the path.
           At ingress A, three copies of the packet to be transported 
           by the path are produced. Each copy contains a header with
           a set of bit strings. 
           The first copy has a header with set of bit strings (0:00000011)
           for bit positions 1 and 2.
           The second copy has a header with set of bit strings (6:01001000)
           for bit positions 7' and 4'. 
           The third copy has a header with set of bit strings (7:00001010)
           for bit positions 12' and 10'.</t>

        <t>For the first copy, ingress A will drop it 
           since bit positions 1 and 2 are not any adjacency bit 
           position of A. 
           Similarly, ingress A will the third copy 
           since bit positions 12' and 10' are not any adjacency bit 
           position of A.</t>

        <t>For the second copy, ingress A sends it to BFR B
           using bit position 7' in the header. 
           After receiving the packet, BFR B sends the packet to
           BFR C  using bit position 4' in the header. 
           After receiving the packet, BFR C drops it since
           there is no bit position of BFR C 
           in the header of the packet.</t>

<!--
        <t>Another BIER-TE path is the explicit multicast P2MP path from 
           ingress A to egresses H and D, traversing from A to G to H and 
           from A to B to C to D.
           This path is represented by BPs as {26', 20', 7', 4', 12', 4, 1},
           which is {26'(9:00000010), 20'(8:00001000), 7'(6:01000000),
           4'(6:00001000), 12'(7:00001000), 4(0:00001000), 1(0:00000001)}.
           These seven bit positions on the path are in five sets of
           bit strings with SI = 0, 6, 7, 8 and 9.
           Bit positions 4 and 1 are in the set with SI = 0.
           Bit positions 7' and 4' are in the set with SI = 6.
           Bit positions 12' is in the set with SI = 7.
           Bit positions 20' is in the set with SI = 8.
           Bit positions 26' is in the set with SI = 9.

           There are 
           The forwarding behaviors in normal operations.
        </t>
       <t>For a multicast packet with the path on BFR A,
           A sends the packet to G and B according to 
           the forwarding entries for 26' and 7' in A's extended BIER-TE BIFT
           respectively. 
           The packet received by G and B contains path {20', 4', 12', 4, 1}.
        </t>

        <t>After receving the packet from A, G forwards the packet to H
           according to forwarding entry for 20' in its extended BIER-TE BIFT.
           The packet received by H contains path {4', 12', 4, 1}.

           After receving the packet from A, B forwards the packet to C
           according to forwarding entry for 4' in its extended BIER-TE BIFT.
           The packet received by C contains path {20', 12', 4, 1}.
        </t>

        <t>After receving the packet from G, H decapsulates the packet
           and passes a copy of the payload 
           of the packet to the packet's NextProto
           according to forwarding entry for 4 in its extended BIER-TE BIFT.

           After receving the packet from B, C forwards the packet to D 
           according to forwarding entry for 12' in its extended BIER-TE BIFT.
           The packet received by D contains path {20', 4, 1}.
        </t>

        <t>After receving the packet from C, D decapsulates the packet
           and passes a copy of the payload 
           of the packet to the packet's NextProto
           according to forwarding entry for 1 in its extended BIER-TE BIFT.
        </t>
-->
      </section> <!-- BIER-TE Paths with Multiple BitStrings -->

<!--
     <section title="Extensions to BIER Header">
      <t>The existing BIER header contains only one set of bit strings
         and BIFT-id. The BIFT-id indicates the BIFT that 
         corresponds to a particular combination of 
         sub-domain (SD), bit string length (BSL), and 
         set identifier (SI). 
         The format of the BIER header is shown in
         <xref target="bier-header"/>. </t>

<t>
<figure anchor="bier-header" 
        title="BIER Header">
  <artwork align="center"> <![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              BIFT-id                  |  TC |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble |  Ver  |  BSL  |              Entropy                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|Rsv|    DSCP   |   Proto   |             BFIR-id           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 BitString (first 32 bits)                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 BitString (last 32 bits)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>

<t>
      <list style="hanging" hangIndent="6">
       <t hangText="TC:">The "Traffic Class" field in 
                   <xref target="RFC5462"/> has its usual meaning in
                   an MPLS label stack entry.</t>
       <t hangText="S:">
When a BIER packet is traveling through an MPLS network, the
high-order 20 bits of the initial four octets of the BIER
encapsulation contain an MPLS label in the BIFT-id field. These
four octets are treated as the final entry in the packet's MPLS
label stack. Hence, the S bit (see <xref target="RFC3032"/>) 
MUST be set to 1.
If there are any MPLS label stack entries immediately preceding
the BIER encapsulation, the S bit of those label stack entries
MUST be set to 0.</t>
       <t hangText="TTL:">
This is the usual MPLS "Time to Live" field in <xref target="RFC3032"/>. 
When a BIER packet is received, its "incoming TTL" (see below) is taken
from this TTL field.
When a BIER packet is forwarded to one or more BFR adjacencies,
the BIER-MPLS label carried by the forwarded packet MUST have a
TTL field whose value is one less than that of the packet's
incoming TTL.</t>
       <t hangText="Nibble:">
This field is set to the binary value 0101; this ensures that the
MPLS ECMP logic will not confuse the remainder of the BIER header
with an IP header or with the header of a pseudowire packet. In
an MPLS network, if a BFR receives a BIER packet with any other
value in the first nibble after the label stack, it SHOULD discard
the packet and log an error.</t>
       <t hangText="Ver:">
This 4-bit field identifies the version of the BIER header. 
<xref target="RFC8296"/>
specifies version 0 of the BIER header. If a packet is
received by a particular BFR and that BFR does not support the
specified version of the BIER header, the BFR MUST discard the
packet and log an error.
The value 0xF is reserved for experimental use; that value
MUST NOT be assigned by any future IETF document or by IANA.</t>
       <t hangText="BSL:">This 4-bit field encodes the length 
in bits of the BitString.</t>
       <t hangText="Entropy:">
This 20-bit field specifies an "entropy" value that can be used
for load-balancing purposes. The BIER forwarding process may do
equal-cost load balancing, in which case the load-balancing
procedure MUST choose the same path for any two packets that have
the same entropy value and the same BitString.</t>
       <t hangText="OAM:">
By default, these two bits are set to 0 by the BFIR and are not
modified by other BFRs. These two bits have no effect on the path
taken by a BIER packet and have no effect on the quality of
service applied to a BIER packet.</t>
       <t hangText="Rsv:">
These two bits are currently unused. They SHOULD be set to 0 upon
transmission and MUST be ignored upon reception.</t>
       <t hangText="DSCP:">
By default, this 6-bit field is not used in MPLS networks. The
default behavior is that all six bits SHOULD be set to 0 upon
transmission and MUST be ignored upon reception.</t>
       <t hangText="Proto:">
This 6-bit "Next Protocol" field identifies the type of the
payload. (The "payload" is the packet or frame immediately
following the BIER header.) IANA has created a registry called
"BIER Next Protocol Identifiers". This field is to be populated
with the appropriate entry from that registry.</t>
       <t hangText="BFIR-id:">
By default, this is the BFR-id of the BFIR, in the SD to which the
packet has been assigned. The BFR-id is encoded in the 16-bit
field as an unsigned integer in the range [1,65535].</t>
       <t hangText="BitString:">
This field holds the BitString that, together with the packet's SI
and SD, identifies the destination BFERs for this packet. Note
that the SI and SD for the packet are not carried explicitly in
the BIER header, as a particular BIFT-id always corresponds to a
particular SI and SD.</t>
      </list>
         </t>
-->
     <!-- </section> --> <!-- Extensions to BIER Header -->

    </section> <!-- Example Application of Current BIER-TE -->


     <section title="Extensions for Multiple BitStrings">
      <t>This section describes a BIER-TE header containing 
         multiple BitStrings with different SIs 
        (or multiple BitStrings for short), 
         two levels of BIFTs for efficient processing 
         the packets with the BIER-TE header, 
         and a forwarding procedure for handling the packets
         using the two levels of BIFTs.</t>

     <section title="BIER-TE Header with Multiple BitStrings">

      <t>A BIER-TE header needs to contain
         multiple sets of bit strings 
         (i.e., multiple BitStrings with different SIs)
         for a BIER-TE path. 
         In one option, 
         they are represented by 
         n indicating the number of BitStrings, and 
         a pair of SI and BitString for each of 
         the n sets of bit strings:
         SI-1, BitString-1; SI-2, BitString-2; ...; SI-n, BitString-n.
          </t>
<t><xref target="bier-te-header1"/> illustrates a format
of a BIER-TE header having multiple BitStrings.

<figure anchor="bier-te-header1" 
        title="A Format of BIER-TE Header">
  <artwork align="center"> <![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               BIFT-id                 |  TC |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble |  Ver  |  BSL  |              Entropy                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|M|R|    DSCP   |   Proto   |             BFIR-id           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        n      |
+-+-+-+-+-+-+-+-+
|     SI-1      | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    BitString-1                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                ......                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     SI-n      | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    BitString-n                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
      <list style="hanging" hangIndent="6">
       <t hangText="BIFT-id:">This field indicates a BIFT.</t>
<!--
       <t hangText="TC:">The "Traffic Class" field in 
                   <xref target="RFC5462"/> has its usual meaning in
                   an MPLS label stack entry.</t>
       <t hangText="S:">
When a BIER packet is traveling through an MPLS network, the
high-order 20 bits of the initial four octets of the BIER
encapsulation contain an MPLS label in the BIFT-id field. These
four octets are treated as the final entry in the packet's MPLS
label stack. Hence, the S bit (see <xref target="RFC3032"/>) 
MUST be set to 1.
If there are any MPLS label stack entries immediately preceding
the BIER encapsulation, the S bit of those label stack entries
MUST be set to 0.</t>
       <t hangText="TTL:">
This is the usual MPLS "Time to Live" field in <xref target="RFC3032"/>. 
When a BIER packet is received, its "incoming TTL" (see below) is taken
from this TTL field.
When a BIER packet is forwarded to one or more BFR adjacencies,
the BIER-MPLS label carried by the forwarded packet MUST have a
TTL field whose value is one less than that of the packet's
incoming TTL.</t>
       <t hangText="Nibble:">
This field is set to the binary value 0101; this ensures that the
MPLS ECMP logic will not confuse the remainder of the BIER header
with an IP header or with the header of a pseudowire packet. In
an MPLS network, if a BFR receives a BIER packet with any other
value in the first nibble after the label stack, it SHOULD discard
the packet and log an error.</t>
       <t hangText="Ver:">
This 4-bit field identifies the version of the BIER header. 
<xref target="RFC8296"/>
specifies version 0 of the BIER header. If a packet is
received by a particular BFR and that BFR does not support the
specified version of the BIER header, the BFR MUST discard the
packet and log an error.
The value 0xF is reserved for experimental use; that value
MUST NOT be assigned by any future IETF document or by IANA.</t>
       <t hangText="BSL:">This 4-bit field encodes the length 
in bits of the BitString.</t>
       <t hangText="Entropy:">
This 20-bit field specifies an "entropy" value that can be used
for load-balancing purposes. The BIER forwarding process may do
equal-cost load balancing, in which case the load-balancing
procedure MUST choose the same path for any two packets that have
the same entropy value and the same BitString.</t>
       <t hangText="OAM:">
By default, these two bits are set to 0 by the BFIR and are not
modified by other BFRs. These two bits have no effect on the path
taken by a BIER packet and have no effect on the quality of
service applied to a BIER packet.</t>
-->
       <t hangText="M:">
This one bit flag is set to 1 for the header 
                   containing multiple sets of bit strings,
0 for for the header not
                   containing multiple sets of bit strings.</t>

       <t hangText="R:">
This R bit is currently unused. It SHOULD be set to 0 upon
transmission and MUST be ignored upon reception.</t>

<!--
       <t hangText="DSCP:">
By default, this 6-bit field is not used in MPLS networks. The
default behavior is that all six bits SHOULD be set to 0 upon
transmission and MUST be ignored upon reception.</t>
       <t hangText="Proto:">
This 6-bit "Next Protocol" field identifies the type of the
payload. (The "payload" is the packet or frame immediately
following the BIER header.) IANA has created a registry called
"BIER Next Protocol Identifiers". This field is to be populated
with the appropriate entry from that registry.</t>
       <t hangText="BFIR-id:">
By default, this is the BFR-id of the BFIR, in the SD to which the
packet has been assigned. The BFR-id is encoded in the 16-bit
field as an unsigned integer in the range [1,65535].</t>
-->

       <t hangText="n:"> It indicates the number of sets of 
          bit strings in the header.</t>

       <t hangText="SI-1:">It is the set identifier of the first (1-th)
          bit string. </t>
       <t hangText="BitString-1:">It is the first (1-th)
          bit string. The length of the bit string is indicated by
          BSL.</t>

       <t hangText="SI-n:">It is the set identifier of the n-th
          bit string. </t>
       <t hangText="BitString-n:">It is the n-th
          bit string. The length of the bit string is indicated by
          BSL.</t>
      </list>
         </t>

      <t>The other fields are the same as those in 
<xref target="RFC8296"/>. </t>
     </section> <!-- BIER-TE Header with Multiple BitStrings -->


     <section title="Two Levels of BIFTs">
      <t>A BFR has two levels of BIFTs for BIER-TE.
         At the top or first level, there is one BIFT.
         The structure of this BIFT is shown in
         <xref target="struct-top-bift"/>.
         This top level BIFT has an entry for every 
         set identifier (SI). 
         The entry contains: 
      <list style="hanging" hangIndent="6">
       <t hangText=" o BitString:">The bit string (i.e., the 
          adjacency bit positions) of the BFR in the set
          indicated by SI.</t>

     <t hangText=" o Pointer to 2nd Level BIFT:">Pointer to the 
          second level BIFT for the bit string of the BFR
          in the set indicated by SI.
          If the bit string is all zeros, 
          there is no second level BIFT for it and 
          the pointer is NULL.</t>
      </list>
         </t>
<t>
<figure anchor="struct-top-bift" 
        title="Structure of Top Level BIFT">
  <artwork align="center"> <![CDATA[
         +--------------+--------------+
   SI    |  BitString   |Pointer to    |
 (Index) |(Adjacency BP)|2nd Level BIFT|
         +==============+==============+
    0    |  xxxxxxxxxx  | xxxxxxxx     |
         +--------------+--------------+
    1    |  xxxxxxxxxx  | xxxxxxxx     |
    .    +--------------+--------------+
    :                 . . . . . .
   ]]></artwork>
</figure>
</t>

      <t>For example, the top level BIFT on BFR E is illustrated in
         <xref target="top-bift-bfr-e"/>.
         There are 9 sets of bit strings in total in the
         BIER-TE network in 
         <xref target="bier-top-1"/>.
         So, the BIFT has 9 entries. 
      </t>

<t>
<figure anchor="top-bift-bfr-e" 
        title="Top Level BIFT on BFR E">
  <artwork align="center"> <![CDATA[
       +--------------+--------------+
  SI   |  BitString   |Pointer to    |
       |(Adjacency BP)|2nd Level BIFT|
       +==============+==============+
   0   |00000100 (3)  | ->BIFT4-SI-0 |
       +--------------+--------------+
   1   |00000000      | NULL         |
       +--------------+--------------+
   2   |00000000      | NULL         |
       +--------------+--------------+
   3   |00000000      | NULL         |
       +--------------+--------------+
   4   |00000000      | NULL         |
       +--------------+--------------+
   5   |00000000      | NULL         |
       +--------------+--------------+
   6   |00000001 (1') | ->BIFT4-SI-6 |
       +--------------+--------------+
   7   |00000000      | NULL         |
       +--------------+--------------+
   8   |00001000 (22')| ->BIFT4-SI-8 |
       +--------------+--------------+
]]></artwork>
</figure>
         </t>

      <t>The first entry is for the set of bit string 
         (i.e., adjacency bit positions) with SI = 0.
         It contains: 
      <list style="hanging" hangIndent="6">
       <t hangText=" o BitString = ">00000100. It indicates the
           local decap adjacency Bit Position 3 of BFR E.</t>

     <t hangText=" o Pointer to 2nd Level BIFT = ">-&gt;BIFT4-SI-0.
          It is a pointer to the second level BIFT 
          for the bit string with SI = 0.</t>
      </list>
      </t>

      <t>The second entry is for the set of bit string 
         (i.e., adjacency bit positions) with SI = 1.
         It contains 00000000 and NULL for BitString 
         and Pointer to 2nd Level BIFT respectively.
         BitString = 00000000 means that BFR E has no
         adjacency bit position in the set with SI = 1.
      </t>
      <t>The 3-th to 6-th entries and the 8-th entry are 
         similar to the second entry.</t>

      <t>The 7-th entry is for the set of bit string 
         (i.e., adjacency bit positions) with SI = 6.
         It contains: 
      <list style="hanging" hangIndent="6">
       <t hangText=" o BitString = ">00000001. It indicates the
          forward-connected adjacency Bit Position 1' of BFR E.</t>

     <t hangText=" o Pointer to 2nd Level BIFT = ">-&gt;BIFT4-SI-6.
          It is a pointer to the second level BIFT 
          for the bit string with SI = 6.</t>
      </list> </t>

      <t>The 9-th entry is for the set of bit string 
         (i.e., adjacency bit positions) with SI = 8.
         It contains: 
      <list style="hanging" hangIndent="6">
       <t hangText=" o BitString = ">00001000. It indicates the
          forward-connected adjacency Bit Position 22' of BFR E.</t>

     <t hangText=" o Pointer to 2nd Level BIFT = ">-&gt;BIFT4-SI-8.
          It is a pointer to the second level BIFT 
          for the bit string with SI = 8.</t>
      </list> </t>

      <t>
         A second level BIFT for the bit string identified by a SI
         contains the entries for the adjacency bit positions
         (or say bit string) in the set identified by the SI.

         Its structure is shown in 
          <xref target="struct-bift4-si"/>. 
         It is the same as the 
         BIFT in <xref target="RFC9262"/>.</t>
<t>
<figure anchor="struct-bift4-si" 
        title="Structure of Second Level BIFT for SI">
  <artwork align="center"> <![CDATA[
+--------------+--------------+------------+
|  BitString   |    Action    |  BFR-NBR   |
|(Adjacency BP)|              | (Next Hop) |
+==============+==============+============+
| xxxxxxxx     | xxxxxxxx     |  xxxxxxxx  |
+--------------+--------------+------------+
]]></artwork>
</figure>
</t>

      <t>For example, BFR E has three adjacency bit positions:
         3, 1' and 22'. They are in the three sets of bit strings 
         identified by SI = 0, 6 and 8 respectively.
         So, BFR E has three second level BIFTs: 
         BIFT for SI = 0, BIFT for SI = 6 and BIFT for SI = 8.
         These BIFTs are illustrated in 
         <xref target="bift4-si-0-bfr-e"/>,
         <xref target="bift4-si-6-bfr-e"/> and 
         <xref target="bift4-si-8-bfr-e"/>. </t>
<t>
<figure anchor="bift4-si-0-bfr-e" 
        title="BIFT for SI = 0 on BFR E">
  <artwork align="center"> <![CDATA[
+--------------+--------------+------------+
|  BitString   |    Action    |  BFR-NBR   |
|(Adjacency BP)|              | (Next Hop) |
+==============+==============+============+
|00000100 (3)  | local-decap  |            |
+--------------+--------------+------------+
]]></artwork>
</figure>
         </t>

<t>
<figure anchor="bift4-si-6-bfr-e" 
        title="BIFT for SI = 6 on BFR E">
  <artwork align="center"> <![CDATA[
+--------------+--------------+------------+
|  BitString   |    Action    |  BFR-NBR   |
|(Adjacency BP)|              | (Next Hop) |
+==============+==============+============+
|00000001 (1') | fw-connected |     B      |
+--------------+--------------+------------+
]]></artwork>
</figure>
         </t>

<t>
<figure anchor="bift4-si-8-bfr-e" 
        title="BIFT for SI = 8 on BFR E">
  <artwork align="center"> <![CDATA[
+--------------+--------------+------------+
|  BitString   |    Action    |  BFR-NBR   |
|(Adjacency BP)|              | (Next Hop) |
+==============+==============+============+
|00001000 (22')| fw-connected |     F      |
+--------------+--------------+------------+
]]></artwork>
</figure>
         </t>

      <t>In another example, BFR B has four adjacency bit positions:
         2', 4', 6' and 8'. They are in the same set of bit strings 
         identified by SI = 6.
         So, BFR B has one second level BIFT: 
         BIFT for SI = 6.
         This BIFT is illustrated in 
         <xref target="bift4-si-6-bfr-b"/>.</t>

<t>
<figure anchor="bift4-si-6-bfr-b" 
        title="BIFT for SI = 6 on BFR B">
  <artwork align="center"> <![CDATA[
+--------------+--------------+------------+
|  BitString   |    Action    |  BFR-NBR   |
|(Adjacency BP)|              | (Next Hop) |
+==============+==============+============+
|00000010 (2') | fw-connected |     E      |
+--------------+--------------+------------+
|00001000 (4') | fw-connected |     C      |
+--------------+--------------+------------+
|00100000 (6') | fw-connected |     G      |
+--------------+--------------+------------+
|10000000 (8') | fw-connected |     A      |
+--------------+--------------+------------+
]]></artwork>
</figure>
         </t>

      <t>The top level BIFT on BFR B is shwon in
         <xref target="top-bift-bfr-b"/>.
         There are 9 sets of bit strings in total in the
         BIER-TE network in 
         <xref target="bier-top-1"/>.
         So, the BIFT has 9 entries. 
      </t>

<t>
<figure anchor="top-bift-bfr-b" 
        title="Top Level BIFT on BFR B">
  <artwork align="center"> <![CDATA[
       +--------------+--------------+
  SI   |  BitString   |Pointer to    |
       |(Adjacency BP)|2nd Level BIFT|
       +==============+==============+
   0   |00000000      | NULL         |
       +--------------+--------------+
   1   |00000000      | NULL         |
       +--------------+--------------+
   2   |00000000      | NULL         |
       +--------------+--------------+
   3   |00000000      | NULL         |
       +--------------+--------------+
   4   |00000000      | NULL         |
       +--------------+--------------+
   5   |00000000      | NULL         |
       +--------------+--------------+
   6   |10101010      | ->BIFT4-SI-6 |
       +--------------+--------------+
   7   |00000000      | NULL         |
       +--------------+--------------+
   8   |00000000      | NULL         |
       +--------------+--------------+
]]></artwork>
</figure>
</t>
      <t>The 7-th entry is for the set of bit string 
         (i.e., adjacency bit positions) with SI = 6.
         It contains: 
      <list style="hanging" hangIndent="6">
       <t hangText=" o BitString = ">10101010. It indicates the
          forward-connected adjacency Bit Position 2', 4', 6' 
          and 8' of BFR B.</t>

     <t hangText=" o Pointer to 2nd Level BIFT = ">-&gt;BIFT4-SI-6.
          It is a pointer to the second level BIFT 
          for the bit string with SI = 6.</t>
      </list>
      </t>

      <t>The other entries are for the sets of bit strings 
         (i.e., adjacency bit positions) with SI other than 6.
         Each of them contains 00000000 and NULL for BitString 
         and Pointer to 2nd Level BIFT respectively.
         BitString = 00000000 means that BFR B has no
         adjacency bit position in the set with SI other than 6.
      </t>
     </section> <!--  Two Levels of BIFTs -->


     <section title="Forwarding Procedure">
      <t>For a packet with a BIER-TE header containing
         multiple BitStrings with different SIs,
         after receiving the packet,
         a BFR checks each BitString to see if
         it has any adjacency bit positions 
         of the BFR.</t>
 
      <t>If a BitString contains an adjacency 
         bit position of the BFR,
         the BFR processes the packet according to
         the adjacency bit position.
         If the adjacency bit position is a forward-connected 
         adjacency, the BFR forwards a packet copy to
         the adjacency. 
         If the adjacency bit position is a local decap 
         adjacency, the BFR sends the packet payload to
         the packet's NextProto within the BFR. 
         This is the same as the existing behavior.
         </t>

      <t>For a BitString identified by SI-i and BitString-i,
         the BFR determines if it contains an adjacency 
         bit position of the BFR using the top level BIFT.
         The BFR gets its adjacency bit positions in the set SI-i
         from the BIFT and checks if BitString-i and the bit positions 
         have the same bit with value 1.
         This can be achieved by checking if 
         BIFT[SI-i][0] AND BitString-i is not zero, 
         where BIFT[SI-i][0] is the adjacency bit positions of the BFR
         in the set SI-i, AND is bit wise logical and.</t>

      <t>When BitString-i contains an adjacency 
         bit position of the BFR, 
         the BFR processes the packet  
         using the second level BIFT for its adjacency bit positions
         in the BitString identified by SI-i.
         The BFR gets the second level BIFT from the top level BIFT
         using SI-i. The second collumn of the row with index SI-i 
         in the top level BIFT (i.e., BIFT[SI-i][1]) stores
         a pointer to the second level BIFT.</t>

      <t>For each adjacency bit position of the BFR in the BitString,
         the BFR processes the packet  
         using the second level BIFT pointed by BIFT[SI-i][1]
         in the same way as the existing one.</t>

      <t>The procedure for processing a BIER-TE packet 
         is described in Pseudo code in
         <xref target="proc4-new-header-ebift"/>.</t>

<t>
<figure anchor="proc4-new-header-ebift" 
        title="Forwarding Procedure for Processing BIER-TE Packet">
  <artwork> <![CDATA[
Packet = the packet received by BFR;
FOR i = 1 to n {// n in header is number of BitStrings
   T = BIFT[SI-i][0] & BitString-i;
   IF (T) {//has an adjacency BP of BFR
       BIFT4-SI-i = BIFT[SI-i][1]; //Get second level BIFT
       get m; //m: number of adjacency BPs in set SI-i or BIFT4-SI-i
       FOR (j = 1; T && j < m; j++) {//for each BP of BFR in set SI-i
          IF (T & BIFT4-SI-i[j][0]) {//has adjacency BP at j
             IF (BIFT4-SI-i[j][1] == fw-connected){//fw-connected adj
                 send a packet copy to BIFT4-SI-i[j][2];
             } ELSE IF (BIFT4-SI-i[j][1] == local-decap) {//decap adj
                 send packet payload to multicast overlay;
             }
             T = T & ~(BIFT4-SI-i[j][0])//Clear T's corresponding bit
          }
       }
   }
}]]></artwork>
</figure> </t>

     </section> <!-- Forwarding Procedure -->

     </section> <!-- Extensions for Multiple SIs -->



    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>No requirements for IANA.</t>
    </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank people
      for their comments to this work.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.9262"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.8296"?>
      <?rfc include="reference.RFC.3032"?>
      <?rfc include="reference.RFC.5462"?>
    </references>

  </back>

</rfc>
