Multicast Using Bit Index Explicit Replication (BIER)
Extracted elements (31)
BIER defines multiple addressing sub-domains within a BIER domain to support the use of different routing underlays, different BitStringLengths, or different traffic engineering policies for different classes of multicast traffic without requiring separate routing domains.
BIER eliminates the need for per-flow state at transit BFRs and explicit multicast tree-building protocols. The set of egress routers is explicitly encoded in the packet header as a BitString, so transit BFRs need only maintain per-neighbor state (the BIFT) rather than per-flow state, resulting in a considerable simplification of multicast operations.
BIER inherently prevents duplicate packet delivery: when a packet is replicated, no two copies share a BFER in their BitStrings, and a BFER clears its own bit before forwarding. This eliminates the need for an RPF (Reverse Path Forwarding) check that conventional IP multicast requires.
The SI (Set Identifier) field was introduced to allow BIER to scale beyond the number of BFERs representable in a single BitString. When a domain has more BFERs than bits in the BitString, the BFIR creates one copy of the packet per SI-subset, each with its own SI value and a BitString covering only the BFERs in that subset.
Two ECMP procedures are defined: non-deterministic (Section 6.7.1), which minimizes packet replications but makes a packet's path to a BFER dependent on which other BFERs are also receiving the flow; and deterministic (Section 6.7.2), which uses multiple BIFTs indexed by entropy hash to make each path independent of other destinations, at the cost of more memory and potentially more replications.
A BIER-encapsulated packet cannot pass directly from one BIER domain to another; at the boundary it must be decapsulated and passed to the multicast flow overlay. The flow overlay then re-encapsulates it as a new BIER packet if the packet needs to traverse a second BIER domain.
The BitStringLength Compatibility Check verifies that every BFR in a sub-domain has advertised support for the Imposition BitStringLength a BFIR intends to use. Failure indicates potential black holes; when it fails, the BFIR SHOULD log an error and may either proceed with the provisioned BitStringLength or fall back to a default BitStringLength that passes the check.
When a BFIR encounters a BitStringLength mismatch (next-hop BFR does not support the packet's BitStringLength), the BFR has three options: (1) discard, (2) re-encapsulate with a supported BitStringLength (potentially creating additional copies), or (3) treat the next-hop BFR as non-BIER and apply the procedures of Section 6.9. There is no signaling to advertise which option a BFR will use.
When a BIER domain contains nodes that do not support BIER, a BFR constructs a modified BIER-SPF tree by removing non-BFR child nodes and re-parenting their children directly under the BFR. Packets are then tunneled (e.g., via MPLS unicast tunnel) to BFR-NBRs that are not Layer-2 adjacent, allowing BIER to operate in mixed-capability networks.
A BIER domain MUST contain at least one sub-domain (the default sub-domain, sub-domain 0). If a BIER domain contains more than one sub-domain, each BFR MUST be provisioned to know the set of sub-domains to which it belongs.
Every BFR MUST support SI values in the range [0,15] and MAY support [0,255]. To support transitions between BitStringLengths, every BFR MUST be capable of simultaneously using two different Disposition BitStringLengths.
Every BIER encapsulation specification MUST define a default BitStringLength. Every BFIR MUST be capable of using that default as its Imposition BitStringLength, and every BFR/BFER MUST be capable of using it as a Disposition BitStringLength. A BFR that can use a given BitStringLength as an Imposition BitStringLength MUST also support it as a Disposition BitStringLength.
For each sub-domain to which a BFR belongs and in which it may act as BFIR or BFER, the BFR MUST be provisioned with a BFR-id that is unique within that sub-domain. Each BFR MUST also be assigned a single BFR-prefix per sub-domain, which MUST be routable in that sub-domain.
If a BFR detects that two different BFRs have advertised the same BFR-id for the same sub-domain, it MUST log an error and MUST NOT encode that duplicate BFR-id in any BIER encapsulation. A BFR that has not yet advertised its own BFR-id but sees a conflicting advertisement SHOULD log an error and MUST NOT advertise its own ownership of that BFR-id while the conflicting advertisement is extant.
It is RECOMMENDED that BFR-ids be assigned densely from the numbering space (e.g., [1,N] for N BFERs) to minimize the number of SIs required and maximize the number of BFERs representable in a single BitString. It is also RECOMMENDED that the BFR-prefix be a loopback address.
The sub-domain assigned to a BIER-encapsulated packet MUST NOT be changed while the packet is in transit through the BIER domain. The BFIR assigns the sub-domain when it applies the BIER header, and that assignment is fixed for the packet's lifetime in the domain.
When a BFER also forwards copies of the packet within the BIER domain, the bit representing the BFER's own BFR-id MUST be clear in all forwarded copies. This prevents duplicate delivery.
When a packet is forwarded to a BFR-NBR connected via multiple parallel interfaces, any entropy field in the BIER encapsulation SHOULD be respected: two packets with the same entropy value SHOULD be sent on the same interface. Packets of a given flow SHOULD NOT be split among multiple ECMP paths.
When unicast traffic to a BFR-NBR uses a bypass tunnel, BIER-encapsulated multicast traffic to that BFR-NBR SHOULD also use that tunnel, so that existing fast-reroute schemes apply to multicast traffic as well. The BIER packet SHOULD NOT inherit TTL from the tunnel encapsulation; TTL processing SHOULD follow the Pipe Model of RFC 3443.
A BFR Identifier (BFR-id) is a positive integer in the range [1,65535] that uniquely identifies a BFR within a given sub-domain. Value 0 is not a legal BFR-id and, if advertised, MUST be interpreted as meaning the advertising BFR has no BFR-id in that sub-domain. Only BFRs that function as BFIR or BFER require a BFR-id.
A BFR-prefix is an IP address (IPv4 or IPv6) assigned to a BFR for a given sub-domain; it is recommended to be a loopback address and must be routable within the sub-domain. All BFR-prefixes within a given sub-domain must belong to the same address family.
A BIER domain is divided into one or more sub-domains, each identified by a sub-domain-id in the range [0,255]. Sub-domain 0 is the mandatory default sub-domain. Each sub-domain is associated with a single routing underlay, and a BFR may belong to multiple sub-domains with potentially different BFR-ids and BFR-prefixes in each.
A Bit-Forwarding Router (BFR) is any router in a BIER domain that supports BIER forwarding. A multicast packet enters the domain at a Bit-Forwarding Ingress Router (BFIR), is replicated and forwarded by transit BFRs, and exits at one or more Bit-Forwarding Egress Routers (BFERs). A single BFR may simultaneously act as BFIR, transit BFR, and BFER for different packets.
The Bit Index Forwarding Table (BIFT) is derived from the BIRT by combining rows with the same SI and BFR-NBR via bitwise OR of their BitStrings to produce a Forwarding Bit Mask (F-BM). Each BIFT entry maps a BFR-id to an F-BM and a BFR-NBR. The BIFT is programmed into the data plane and is sub-domain-specific.
The Bit Index Routing Table (BIRT) maps from a BFER's BFR-id (in a specific sub-domain) to that BFER's BFR-prefix and the BFR-NBR (next-hop BFR neighbor) on the path to that BFER. The BIRT is sub-domain-specific and is derived from advertised BFR-prefix/BFR-id information combined with the routing underlay.
The three-layer BIER architecture consists of: (1) the routing underlay, which establishes adjacencies and computes best paths (typically an IGP); (2) the BIER layer, which handles encapsulation, forwarding, and advertisement of BFR-ids and BFR-prefixes; and (3) the multicast flow overlay, which determines the set of BFERs for incoming multicast flows and how BFERs dispatch decapsulated packets.
BIER inherits the security properties of the multicast flow overlay and the routing underlay with which it is paired. It does not define any BIER-specific authentication, integrity, or confidentiality mechanisms; security must be provided at the overlay and underlay layers.
If a BIER encapsulation header is modified in transit (through error or malicious action) so that the SI or BitString differs from the BFIR's intention, the packet is likely to be misdelivered — sent to unintended BFERs or not sent to intended ones. Protecting the integrity of the BIER header therefore requires mechanisms provided by the encapsulation or by the routing underlay.
The BIER forwarding procedure iterates over set bits in the packet's BitString. For each lowest set bit k: if k identifies the local BFR, deliver a copy to the multicast flow overlay and clear bit k; otherwise, look up entry k in the BIFT to get F-BM and BFR-NBR, copy the packet with BitString AND'd by F-BM, forward the copy to BFR-NBR, and update the original BitString by AND'ing with ~F-BM. The loop terminates when the BitString is all zeros.
BFR-id N is encoded in a BIER packet as: SI = integer part of (N-1)/BitStringLength; bit position = ((N-1) modulo BitStringLength)+1. Multiple BFR-ids sharing the same SI can be combined into a single BitString via bitwise OR. Different deployments may use different BitStringLengths.
The BIER header contains a BitString field and a Set Identifier (SI). Each bit in the BitString represents one BFER; if a packet has SI=n and bit k set, it must be delivered to the BFER with BFR-id = n*BitStringLength+k. The least significant (rightmost) bit is bit 1 and the most significant is bit BitStringLength.