China Mobile

32 Xuanwumen West Street Beijing 100053 China lizhiqiangyjy@chinamobile.com

China Mobile

32 Xuanwumen West Street Beijing 100053 China duzongpeng@chinamobile.com

Centec Networks

Suzhou 215000 China chengw@centec.com

Centec Networks

Suzhou 215000 China wangjj@centec.com

Centec Networks

Suzhou 215000 China zhanggy@centec.com

Routing BIER BIER Multicast Scalability Data Plane Hardware Forwarding This document describes an optimized data plane forwarding architecture for Bit Index Explicit Replication (BIER). The standard BIER forwarding procedures, as conceptually described in RFC 8279, imply a per-bit evaluation of the BitString against the Bit Index Forwarding Table (BIFT) on each Bit Forwarding Router (BFR). When the BitStringLength is large (e.g., 256 bits or more), this conceptual model presents implementation challenges for high-speed ASIC/NPU forwarding engines in terms of processing latency and hardware table resources. This document defines two conceptual data structures -- a Replication Member Table and an Interface BitMask Table -- that decouple the multicast replication decision from per-bit BitString parsing. The resulting forwarding pipeline operates in time proportional to the number of egress interfaces rather than the BitString length, enabling deterministic and scalable hardware processing. This mechanism is semantically equivalent to the forwarding procedures of RFC 8279 and does not modify the BIER encapsulation or introduce new protocol signaling.

Introduction Bit Index Explicit Replication (BIER) provides a stateless multicast forwarding architecture that eliminates the need for per-flow state in transit routers and for explicit multicast tree-building protocols. In BIER, the ingress router (BFIR) encapsulates multicast data packets with a BIER header that contains a BitString indicating the set of destination Bit-Forwarding Egress Routers (BFERs). As BIER deployments scale to larger domains, multi-tenant data centers, and AI/ML cluster environments, the required BitStringLength (BSL) increases significantly. Section 6.5 provides a conceptual forwarding pseudocode that iterates over each set bit in the BitString to determine the forwarding next-hop (BFR-NBR) and the per-neighbor Forwarding BitMask (F-BM). While RFC 8279 explicitly notes that this is a conceptual description and implementations may optimize the process, no standardized optimized architecture has been defined to guide hardware implementors. This document fills this gap by defining a decoupled forwarding pipeline architecture that separates "determining which egress interfaces need packet copies" from "filtering the BitString for each copy." The key insight is that the number of distinct egress interfaces on a BFR is typically much smaller than the BitStringLength (e.g., 4-16 interfaces vs. 256+ bits), making interface-centric processing significantly more efficient for hardware implementation. The mechanism described herein is semantically equivalent to the standard BIER forwarding procedures of RFC 8279 -- for any given input BitString, both approaches produce identical forwarding outcomes (same set of egress interfaces with the same per-interface BitStrings). This document does not modify the BIER encapsulation format defined in and does not introduce any new protocol signaling.

Terminology 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 BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms as defined in and :

BFR:

Bit Forwarding Router.

BFIR:

Bit-Forwarding Ingress Router.

BFER:

Bit-Forwarding Egress Router.

BFR-NBR:

A BFR that is a neighbor of the current BFR in the BIER forwarding topology.

BIFT:

Bit Index Forwarding Table, as defined in .

BIFT-id:

An identifier for a BIFT entry as defined in . In MPLS encapsulation, this corresponds to an MPLS label value that implicitly encodes the <SD, SI, BSL> tuple.

BitString (BS):

A string of bits in the BIER header indicating the set of destination BFERs.

F-BM (Forwarding BitMask):

A bitmask associated with an egress interface, representing the logical OR of all BFR-id bit positions of downstream BFERs reachable via that interface.

This document introduces the following new terms:

Replication Group Identifier:

A conceptual identifier derived from the BIER packet header's BIFT-id, used to index the Replication Member Table. In practice, it MAY be identical to the BIFT-id.

Replication Member Table (RMT):

A conceptual data structure that maps a Replication Group Identifier to a list of egress interface identifiers.

Interface BitMask Table (IBMT):

A conceptual data structure that maps an egress interface identifier to the corresponding F-BM for that interface.

Problem Statement The conceptual forwarding pseudocode in Section 6.5 describes a process where each set bit in the incoming BitString is evaluated individually to determine the appropriate BFR-NBR and the associated F-BM. While this provides a clear and correct algorithmic specification, direct hardware implementation of this per-bit iteration model presents the following challenges in large-scale deployments: First, processing latency scales with BitString length. When BSL is 256 or larger, scanning each bit position -- whether sequentially or in parallel -- imposes a processing cost that grows linearly with BSL. For line-rate forwarding of high-throughput multicast flows on 100GE or 400GE interfaces, this can become a significant constraint on forwarding engine design. Second, hardware table resources scale with BitString length. A standard BIFT maintains one entry per BFR-id (i.e., per bit position), each containing a BFR-NBR identifier and a full-length F-BM. For BSL=256 and a single <SD, SI> combination, this requires 256 table entries, each storing a 256-bit F-BM, consuming substantial TCAM or SRAM resources. In resource-constrained edge routers or densely populated data center environments supporting multiple Sub-Domains and Set Identifiers, the aggregate table size can become prohibitive.

Architecture Overview The optimized forwarding architecture decomposes BIER packet processing into two decoupled phases, each served by an independent conceptual lookup table. The following diagram illustrates the high-level forwarding pipeline: {IF1,..,IFn} | +------------------------------+ | +------------+------------+ | | | v v v +--------+ +--------+ +--------+ | Copy 1 | | Copy 2 | | Copy N | | -> IF1 | | -> IF2 | | -> IFN | +---+----+ +---+----+ +---+----+ | | | v v v +-----------+ +-----------+ +-----------+ | Phase 2: | | Phase 2: | | Phase 2: | | BS AND | | BS AND | | BS AND | | IBMT[IF1] | | IBMT[IF2] | | IBMT[IFN] | +-----------+ +-----------+ +-----------+ | | | v v v +------------+ +------------+ +------------+ | !=0: Fwd | | !=0: Fwd | | !=0: Fwd | | ==0: Drop | | ==0: Drop | | ==0: Drop | +------------+ +------------+ +------------+ ]]> Phase 1 (Replication Lookup) determines which egress interfaces require a copy of the packet, based solely on the BIFT-id. This is independent of the specific BitString content in the received packet. Phase 2 (BitString Isolation) performs a single bitwise AND operation per egress interface to compute the filtered BitString for each copy. Copies with a resulting zero BitString are discarded. The processing complexity of this pipeline is O(NumEgressInterfaces) for both phases combined, compared to O(BitStringLength) for the per-bit iteration model. In typical network topologies, a BFR has 2 to 16 egress interfaces, while BSL may be 256, 512, or larger.

Conceptual Data Structures

Replication Member Table (RMT) A compliant BFR MUST maintain a conceptual Replication Member Table that maps each Replication Group Identifier to the set of egress interfaces that have at least one downstream BFER reachable through them. The RMT is populated by the BIER control plane based on the network topology and BIFT computation results. The control plane MUST derive the egress interface list by identifying all unique BFR-NBRs present in the BIFT entries for the corresponding <SD, SI, BSL> and mapping each BFR-NBR to its associated egress interface. The size of the RMT is O(N_groups), where N_groups is the number of distinct Replication Group Identifiers (i.e., distinct <SD, SI, BSL> tuples in use). Each entry contains a list of at most O(N_interfaces) egress interface identifiers.

Interface BitMask Table (IBMT) A compliant BFR MUST maintain a conceptual Interface BitMask Table that maps each egress interface to the Forwarding BitMask (F-BM) representing all downstream BFERs reachable via that interface. For each egress interface IF_k, the F-BM is computed as the bitwise OR of all bit positions corresponding to BFERs whose shortest path (or engineered path, in the case of BIER-TE) from this BFR traverses IF_k. Formally: F-BM(IF_k) = OR of { bit(BFR-id_j) } for all BFER_j where BIFT[BFR-id_j].BFR-NBR is reachable via IF_k. The IBMT MUST be updated by the control plane whenever the BIER topology or BIFT entries change. The size of the IBMT is O(N_interfaces), where each entry stores one F-BM of BitStringLength bits. Note: When the BFR participates in multiple Sub-Domains or supports multiple <SI, BSL> combinations, the IBMT entries MAY be scoped per <SD, BSL> or may use a single aggregate F-BM if the interface-to-downstream-BFER mapping is consistent across all applicable contexts. The specific scoping strategy is an implementation choice.

Forwarding Procedures Upon receiving a valid BIER packet, a compliant BFR implementing this architecture MUST execute the following deterministic procedures in its data plane:

Step 1: Replication Group Resolution The BFR extracts the BIFT-id from the received BIER packet header as specified in . The BFR derives the Replication Group Identifier from the BIFT-id and queries the RMT to obtain the associated list of egress interface identifiers {IF_1, IF_2, ..., IF_n}. If no matching entry exists in the RMT, the BFR MUST discard the packet and SHOULD log an error.

Step 2: Interface-Level Replication The BFR generates an independent packet replica for each egress interface in the list obtained in Step 1. At this stage, the BFR MUST NOT modify the BitString in any of the replicas. All replicas carry the original BitString from the received packet.

Step 3: Egress BitString Isolation For each packet replica destined to egress interface IF_k, the BFR queries the IBMT to retrieve the F-BM associated with IF_k. The BFR MUST compute: BitString_new = BitString_original AND F-BM(IF_k)

Step 4: Forwarding Decision For each replica:

• If BitString_new is zero (all bits clear), the BFR MUST discard the replica. This prevents forwarding packets to interfaces that have no relevant downstream BFERs for the current packet, avoiding unnecessary bandwidth consumption and potential forwarding anomalies.
• If BitString_new is non-zero, the BFR MUST overwrite the BIER header's BitString field with BitString_new and transmit the replica via egress interface IF_k. The remaining BIER header fields (including BIFT-id) are updated according to the standard procedures of and (e.g., BIFT-id label swap in MPLS encapsulation, TTL decrement).

Forwarding Example Consider BFR-A with three egress interfaces in a BIER domain using BSL=8 for simplicity of illustration: BFR-A's RMT (for the relevant Replication Group): BFR-A's IBMT: Scenario: BFR-A receives a BIER packet with BitString = 00101010 (destinations: BFR-ids 2, 4, 6). {IF1, IF2, IF3} Step 2: Create 3 replicas Step 3 and 4: Replica 1 (IF1): 00101010 AND 00000011 = 00000010 Non-zero -> Forward with BS=00000010 Replica 2 (IF2): 00101010 AND 00001100 = 00001000 Non-zero -> Forward with BS=00001000 Replica 3 (IF3): 00101010 AND 00110000 = 00100000 Non-zero -> Forward with BS=00100000 ]]> Now consider BitString = 00101000 (destinations: BFR-ids 4, 6 only): DISCARD (no BFERs via IF1) Replica 2 (IF2): 00101000 AND 00001100 = 00001000 Non-zero -> Forward with BS=00001000 Replica 3 (IF3): 00101000 AND 00110000 = 00100000 Non-zero -> Forward with BS=00100000 ]]> In the second scenario, the replica for IF1 is correctly discarded since no destination BFERs are reachable via IF1, demonstrating the isolation property of the architecture.

Relationship to RFC 8279 Forwarding Procedures The forwarding mechanism described in this document is semantically equivalent to the conceptual forwarding procedures defined in Section 6.5. Both approaches produce identical forwarding results for any given input BitString: the same set of egress interfaces receive packet copies, and each copy carries the same filtered BitString. The difference lies in the iteration strategy. iterates over bit positions (BFR-ids), grouping bits by their associated BFR-NBR. This document's approach pre-computes the bit-to-interface grouping into the RMT and IBMT, and iterates over egress interfaces instead. Since the number of egress interfaces (typically 2-16) is much smaller than the BitStringLength (typically 64-1024), this approach reduces the per-packet processing complexity from O(BSL) to O(N_interfaces). A BFR implementing the architecture described in this document MUST produce forwarding results that are bit-for-bit identical to those produced by a correct implementation of Section 6.5. Any deviation constitutes a forwarding error.

Security Considerations This document does not introduce new security considerations beyond those already discussed in and . The forwarding architecture described herein is semantically equivalent to the standard BIER forwarding procedures and processes the same BIER header fields. No new protocol signaling or encapsulation formats are introduced. The RMT and IBMT are populated by the BIER control plane and are subject to the same security considerations as the BIFT. Unauthorized modification of RMT or IBMT entries could result in incorrect packet replication or delivery to unintended interfaces. Implementations SHOULD protect these data structures with the same access control mechanisms used for BIFT entries.

IANA Considerations This document has no IANA actions. The mechanism defined in this document is a local implementation optimization for BIER forwarding. It does not define new protocol fields, encapsulation formats, or registry entries. The Replication Member Table and Interface BitMask Table are conceptual data structures internal to a BFR and do not require any protocol-level identifier allocation.

References Normative References Informative References

Acknowledgements The authors would like to thank the members of the BIER Working Group for their ongoing work on BIER scalability and deployment.