• Section 2 introduces BIER-TE with two forwarding examples, followed by an introduction to the new concepts of the BIER-TE (overlay) topology, and finally a summary of the relationship between BIER and BIER-TE and a discussion of accelerated hardware forwarding.
• Section 3 describes the components of the BIER-TE architecture: the multicast flow overlay, the BIER-TE layer with the BIER-TE control plane (including the BIER-TE controller), the BIER-TE forwarding plane, and the routing underlay.
• Section 4 specifies the behavior of the BIER-TE forwarding plane with the different types of adjacencies and possible variations of BIER-TE forwarding pseudocode, and finally the mandatory and optional requirements.
• Section 5 describes operational considerations for the BIER-TE controller, primarily how the BIER-TE controller can optimize the use of BPs by using specific types of BIER-TE adjacencies for different types of topological situations. It also describes how to assign bits to avoid loops and duplicates (which, in BIER-TE, does not come "for free"). Finally, it discusses how "Set Identifiers" (SIs), "subdomains" (SDs), and BFR-ids can be managed by a BIER-TE controller; examples and a summary are provided.
• Appendix A concludes this document; details regarding the relationship between BIER-TE and "Segment Routing" (SR) are discussed.

1. BIER-TE inherits the following aspects from BIER unchanged:

   1.a

   The fundamental purpose of per-packet signaled replication and delivery via a BitString.

   1.b

   The overall architecture, which consists of three layers: the flow overlay, the BIER(-TE) layer, and the routing underlay.

   1.c

   The supported encapsulations [RFC 8296].

   1.d

   The semantics of all BIER header elements [RFC 8296] used by the BIER-TE forwarding plane, other than the semantic of the BP in the BitString.

   1.e

   The BIER forwarding plane, except for how bits have to be cleared during replication.
2. BIER-TE has the following key changes with respect to BIER:

   2.a

   In BIER, bits in the BitString of a BIER packet header indicate a BFER, and bits in the BIFT indicate the BIER control plane's calculated next hop towards that BFER. In BIER-TE, a bit in the BitString of a BIER packet header indicates an adjacency in the BIER-TE topology, and only the BFR that is the upstream of that adjacency has its BP populated with the adjacency in its BIFT.

   2.b

   In BIER, the implied reference options for the core part of the BIER layer control plane are the BIER extensions for distributed routing protocols. These include IS-IS and OSPF extensions for BIER, as specified in [RFC 8401] and [RFC 8444], respectively.

   2.c

   The reference option for the core part of the BIER-TE control plane is the BIER-TE controller. Nevertheless, both the BIER and BIER-TE BIFTs' forwarding plane state could equally be populated by any mechanism.

   2.d

   Assuming the reference options for the control plane, BIER-TE replaces in-network autonomous path calculations with explicit paths calculated by the BIER-TE controller.
3. The following elements/functions described in the BIER architecture are not required by the BIER-TE architecture:

   3.a

   "Bit Index Routing Tables" (BIRTs) are not required on BFRs for BIER-TE when using a BIER-TE controller, because the controller can directly populate the BIFTs. In BIER, BIRTs are populated by the distributed routing protocol support for BIER, allowing BFRs to populate their BIFTs locally from their BIRTs. Other BIER-TE control plane or management plane options may introduce requirements for BIRTs for BIER-TE BFRs.

   3.b

   The BIER-TE layer forwarding plane does not require BFRs to have a unique BP; see Section 5.1.3. Therefore, BFRs may not have a unique BFR-id; see Section 5.3.3.

   3.c

   Identification of BFRs by the BIER-TE control plane is outside the scope of this specification. Whereas the BIER control plane uses BFR-ids in its BFR-to-BFR signaling, a BIER-TE controller may choose any form of identification deemed appropriate.

   3.d

   BIER-TE forwarding does not require the BFIR-id field of the BIER packet header.
4. Co-existence of BIER and BIER-TE in the same network requires the following:

   4.a

   The BIER/BIER-TE packet header needs to allow the addressing of both BIER and BIER-TE BIFTs. Depending on the encapsulation option, the same SD may or may not be reusable across BIER and BIER-TE. See Section 4.3. In either case, a packet is always forwarded only end to end via BIER or via BIER-TE ("ships in the night" forwarding).

   4.b

   BIER-TE deployments will have to assign BFR-ids to BFRs and insert them into the BFIR-id field of BIER packet headers, as does BIER, whenever the deployment uses (unchanged) components developed for BIER that use BFR-ids, such as multicast flow overlays or BIER layer control plane elements. See also Section 5.3.3.

1. BIER-TE topology control: During initial provisioning of the network and/or during modifications of its topology and/or services, the protocols and/or procedures to establish BIER-TE BIFTs:

   1.a

   Determine the desired BIER-TE topology for BIER-TE subdomains: the adjacencies that are assigned to BPs. Topology discovery is discussed in Section 3.2.1.1, and the various aspects of the BIER-TE controller's determinations regarding the topology are discussed throughout Section 5.

   1.b

   Determine the per-BFR BIFT from the BIER-TE topology. This is achieved by simply extracting the adjacencies of the BFR from the BIER-TE topology and populating the BFR's BIFT with them.

   1.c

   Optionally assign BFR-ids to BFIRs for later insertion into BIER headers on BFIRs as BFIR-ids. Alternatively, BFIR-ids in BIER packet headers may be managed solely by the flow overlay layer and/or be unused. This is discussed in Section 5.3.3.

   1.d

   Install/update the BIFTs into the BFRs and, optionally, BFR-ids into BFIRs. This is discussed in Section 3.2.1.1.
2. BIER-TE tree control: During network operations, protocols and/or procedures to support creation/change/removal of overlay flows on BFIRs:

   2.a

   Process the BIER-TE requirements for the multicast overlay flow: BFIRs and BFERs of the flow as well as policies for the path selection of the flow. This is discussed in Section 3.5.

   2.b

   Determine the BitStrings and, optionally, entropy. BitStrings are discussed in Sections [3.2.1.2], [3.5], and [5.3.4]. Entropy is discussed in Section 4.2.3.

   2.c

   Install state on the BFIR to impose the desired BIER packet header(s) for packets of the overlay flow. Different aspects of this point, as well as the next point, are discussed throughout Section 3.2.1 and in Section 4.3. The main component responsible for these two points is the multicast flow overlay (Section 3.1), which is architecturally inherited from BIER.

   2.d

   Install the necessary state on the BFERs to decapsulate the BIER packet header and properly dispatch its payload.

• A BIER-TE controller.
• BFR data models and protocols to communicate between the controller and BFRs in support of BIER-TE topology control (see the list under "BIER-TE topology control"), such as YANG/NETCONF/RESTCONF [RFC 7950] [RFC 6241] [RFC 8040].
• BFR data models and protocols to communicate between the controller and BFIRs in support of BIER-TE tree control (see Section 3.2, point 2.), such as BIER-TE extensions for [RFC 5440].

1. On a BFIR, imposition of the BIER header for packets from overlay flows. This is driven by state established by the BIER-TE control plane, the multicast flow overlay as explained in Section 3.1, or a combination of both.
2. On BFRs (including BFIRs and BFERs), forwarding/replication of BIER packets according to their SD, SI, "BitStringLength" (BSL), BitString, and, optionally, entropy fields as explained in Section 4. Processing of other BIER header fields, such as the "Differentiated Services Code Point" (DSCP) field, is outside the scope of this document.
3. On BFERs, removal of the BIER header and dispatching of the payload according to state created by the BIER-TE control plane and/or overlay layer.

   void ForwardBitMaskPacket_withTE (Packet)
   {
       SI=GetPacketSI(Packet);
       Offset=SI*BitStringLength;
       for (Index = GetFirstBitPosition(Packet->BitString); Index ;
            Index = GetNextBitPosition(Packet->BitString, Index)) {
           F-BM = BIFT[Index+Offset]->F-BM;
           if (!F-BM) continue;                            [3]
           BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
           PacketCopy = Copy(Packet);
           PacketCopy->BitString &= F-BM;                  [2]
           PacketSend(PacketCopy, BFR-NBR);
           // The following must not be done for BIER-TE:
           // Packet->BitString &= ~F-BM;                  [1]
       }
   }

1. The F-BMs of all BIFT BPs without an adjacency have all their bits clear. This will cause [3] to skip further processing of such a BP.
2. All BIFT BPs with an adjacency (with the DNC flag clear) have an F-BM that has only those BPs set for which this BFR does not have an adjacency. This causes [2] to clear all bits from PacketCopy->BitString for which this BFR does have an adjacency.
3. [1] is not performed for BIER-TE. All bit clearing required by BIER-TE is performed by [2].

1. This pseudocode eliminates per-bit F-BMs, therefore reducing the size of BIFT state by SI*BSL² and eliminating the need for per-packet-copy BitString masking operations, except for adjacencies with the DNC flag set:

   1.a

   AdjacentBits[SI] are bit positions with a non-empty list of adjacencies in this BFR BIFT. This can be computed whenever the BIER-TE controller updates (adds/removes) adjacencies in the BIFT.

   1.b

   The BFR needs to create packet copies for these adjacent bits when they are set in the packets BitString. This set of bits is calculated in PktAdjacentBits.

   1.c

   All bit positions for which the BFR creates copies have to be cleared in packet copies to avoid loops. This is done by masking the BitString of the packet with ~AdjacentBits[SI]. When an adjacency has DNC set, this bit position is set again only for the packet copy towards that bit position.
2. BIFT entries may contain more than one adjacency in support of specific configurations, such as a hub and multiple spokes (Section 5.1.5). The code therefore includes a loop over these adjacencies.
3. The ECMP() adjacency is also shown in the figure. Its parameters are a seed and "ListOfAdjacencies", from which one is picked.
4. The forward_connected(), forward_routed(), and local_decap() adjacencies are shown with their parameters.

 void ForwardBitMaskPacket_withTE (Packet)
 {
     SI = GetPacketSI(Packet);
     Offset = SI * BitStringLength;
     // Determine adjacent bits in the packets BitString
     PktAdjacentBits = Packet->BitString & AdjacentBits[SI];

     // Clear adjacent bits in the packet header to avoid loops
     Packet->BitString &= ~AdjacentBits[SI];

     // Loop over PktAdjacentBits to create packet copies
     for (Index = GetFirstBitPosition(PktAdjacentBits); Index ;
          Index = GetNextBitPosition(PktAdjacentBits, Index)) {
         for adjacency in BIFT[Index+Offset]->Adjacencies {
             if(adjacency.type == ECMP(ListOfAdjacencies,seed) ) {
                 I = ECMP_hash(sizeof(ListOfAdjacencies),
                               Packet->Entropy,seed);
                 adjacency = ListOfAdjacencies[I];
             }
             PacketCopy = Copy(Packet);
             switch(adjacency.type) {
                 case forward_connected(interface,neighbor,DNC):
                     if(DNC)
                         PacketCopy->BitString |= 1<<(Index-1);
                     SendToL2Unicast(PacketCopy,interface,neighbor);

                 case forward_routed({VRF,}l3-neighbor):
                     SendToL3(PacketCopy,{VRF,}l3-neighbor);

                 case local_decap({VRF},neighbor):
                     DecapBierHeader(PacketCopy);
                     PassTo(PacketCopy,{VRF,}Packet->NextProto);
             }
         }
     }
 }

1. P2P links require only one BP (Section 5.1.1).
2. All leaf BFERs can share a single local_decap() BP (Section 5.1.3).
3. A LAN with N BFRs needs at most N BPs (one for each BFR). It only needs one BP for all those BFRs that are not redundantly connected to multiple LANs (Section 5.1.4).
4. A hub with P2P connections to multiple non-leaf BFER spokes can share one BP with all of the spokes if traffic can be flooded to all of those spokes, e.g., because of no bandwidth concerns or dense receiver sets (Section 5.1.5).
5. Rings of BFRs can be built with just two BPs (one for each direction), except for BFRs with multiple ring connections -- similar to LANs (Section 5.1.6).
6. ECMP() adjacencies to N neighbors can replace N BPs with one BP. Multihop ECMP can avoid polarization through different seeds of the ECMP algorithm (Section 5.1.7).
7. Forward_routed() adjacencies permit "tunneling" across routers that are either BIER-TE capable or not BIER-TE capable where no traffic steering or replications are required (Section 5.1.8).
8. A BP can generally be reused across a set of nodes where it can be guaranteed that no path will ever need to traverse more than one node of the set. Depending on the scenario, this may limit the feasible path steering options (Section 5.1.9).

1. permit explicit path steering across every single hop (which requires more bits), or
2. reduce the number of required bits by exploiting optimizations such as unicast (forward_routed()), ECMP(), or flood (DNC) over "uninteresting" sub-parts of the topology, e.g., parts where, for path steering reasons, different trees do not need to take different paths.

"Independent branches":

For a given flow overlay instance, the branchesfrom a BFIR to every BFER are calculated by the BIER-TE controller to beindependent of the branches to any other BFER. Shortest path trees are the most commonexamples of trees with independent branches.

"Interdependent branches":

When a BFER is added to or deleted from a particulardistribution tree, the BIER-TE controller has to recalculate the branches to other BFERs,because they may need to change. Steiner trees are examples of interdependent branch trees.

1. BIER and BIER-TE have different BFR-ids in the same subdomain. This allows higher replication efficiency for BIER because the BIER BFR-ids can be assigned sequentially, while the BitStrings for BIER-TE will also have to assign the additional bits for the topology adjacencies. There is no relationship between a BFR BIER BFR-id and its BIER-TE BFR-id.
2. BIER and BIER-TE share the same BFR-id. The BFR-ids are assigned as explained above for BIER-TE and simply reused for BIER. The replication efficiency for BIER will be as low as that for BIER-TE in this approach.

bia:

(b)it (i)ngress (a)

bib:

(b)it (i)ngress (b)

bea:

(b)it (e)gress (a)

beb:

(b)it (e)gress (b)

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8279]

IJ. Wijnands, E. Rosen, A. Dolganow, T. Przygienda, and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.

[RFC8296]

IJ. Wijnands, E. Rosen, A. Dolganow, J. Tantsura, S. Aldrin, and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018,
<https://www.rfc-editor.org/info/rfc8296>.

[BIER-MCAST-OVERLAY]

Futurewei Technologies Inc., D. Trossen, A. Rahman, C. Wang, and T. Eckert, "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Internet-Draft draft-ietf-bier-multicast-http-response-06, July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-multicast-http-response-06>.

[BIER-TE-PROTECTION]

University of Tuebingen, T. Eckert, G. Cauchie, W. Braun, and M. Menth, "Protection Methods for BIER-TE", Internet-Draft draft-eckert-bier-te-frr-03, March 2018,
<https://datatracker.ietf.org/doc/html/draft-eckert-bier-te-frr-03>.

[BIER-TE-YANG]

China Telecom, Z. Zhang, C. Wang, R. Chen, F. Hu, M. Sivakumar, and H. Chen, "A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Internet-Draft draft-ietf-bier-te-yang-05, May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-te-yang-05>.

[Bloom70]

B. H. Bloom, "Space/time trade-offs in hash coding with allowable errors", DOI 10.1145/362686.362692, July 1970,
<https://dl.acm.org/doi/10.1145/362686.362692>.

[CONSTRAINED-CAST]

Huawei Technologies, O. Bergmann, C. Bormann, S. Gerdes, and H. Chen, "Constrained-Cast: Source-Routed Multicast for RPL", Internet-Draft draft-ietf-roll-ccast-01, October 2017,
<https://datatracker.ietf.org/doc/html/draft-ietf-roll-ccast-01>.

[ICC]

M. J. Reed, M. Al-Naday, N. Thomos, D. Trossen, G. Petropoulos, and S. Spirou, "Stateless multicast switching in software defined networks", DOI 10.1109/ICC.2016.7511036, May 2016,
<https://ieeexplore.ieee.org/document/7511036>.

[NON-MPLS-BIER-ENCODING]

IJ Wijnands, M Mishra, X Xu, and H Bidgoli, "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation", Internet-Draft draft-ietf-bier-non-mpls-bift-encoding-04, May 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-non-mpls-bift-encoding-04>.

[RCSD94]

H. Zhang, and D. Ferrari, "Rate-Controlled Service Disciplines", DOI 10.3233/JHS-1994-3405, October 1994,
<https://content.iospress.com/articles/journal-of-high-speed-networks/jhs3-4-05>.

[RFC4253]

T. Ylonen, and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006,
<https://www.rfc-editor.org/info/rfc4253>.

[RFC4456]

T. Bates, E. Chen, and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.

[RFC4655]

A. Farrel, J.-P. Vasseur, and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.

[RFC5440]

JP. Vasseur, and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.

[RFC6241]

R. Enns, M. Bjorklund, J. Schoenwaelder, and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.

[RFC6242]

M. Wasserman, "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.

[RFC7589]

M. Badra, A. Luchuk, and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>.

[RFC7752]

H. Gredler, J. Medved, S. Previdi, A. Farrel, and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.

[RFC7950]

M. Bjorklund, "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.

[RFC7988]

E. Rosen, K. Subramanian, and Z. Zhang, "Ingress Replication Tunnels in Multicast VPN", RFC 7988, DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>.

[RFC8040]

A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.

[RFC8253]

D. Lopez, O. Gonzalez de Dios, Q. Wu, and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.

[RFC8345]

A. Clemm, J. Medved, R. Varga, N. Bahadur, H. Ananthakrishnan, and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018,
<https://www.rfc-editor.org/info/rfc8345>.

[RFC8401]

L. Ginsberg, T. Przygienda, S. Aldrin, and Z. Zhang, "Bit Index Explicit Replication (BIER) Support via IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
<https://www.rfc-editor.org/info/rfc8401>.

[RFC8402]

C. Filsfils, S. Previdi, L. Ginsberg, B. Decraene, S. Litkowski, and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018,
<https://www.rfc-editor.org/info/rfc8402>.

[RFC8444]

P. Psenak, N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, and S. Aldrin, "OSPFv2 Extensions for Bit Index Explicit Replication (BIER)", RFC 8444, DOI 10.17487/RFC8444, November 2018,
<https://www.rfc-editor.org/info/rfc8444>.

[RFC8556]

E. Rosen, M. Sivakumar, T. Przygienda, S. Aldrin, and A. Dolganow, "Multicast VPN Using Bit Index Explicit Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 2019,
<https://www.rfc-editor.org/info/rfc8556>.

[TE-OVERVIEW]

A Farrel, "Overview and Principles of Internet Traffic Engineering", Internet-Draft draft-ietf-teas-rfc3272bis-21, September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis-21>.

• relies on source routing (via a BitString), and
• only requires consideration of the "hops" either (1) on which replication has to happen or (2) across which the traffic should be steered (even without replication).

Toerless Eckert

Michael Menth

Gregory Cauchie