11. BIER
11.1. BIER Overview
Bit Indexed Explicit Replication (BIER) architecture allows optimal forwarding of multicast packets without requiring a legacy multicast protocol to build multicast trees or for intermediate routers to maintain any per-multicast flow state. This provides a simplified control plane since BIER information is distributed using underlay IGP.
The following terms are used in BIER:
- Bit Forwarding Router (BFR) — A BFR is a router supporting BIER with a unique BFR prefix and optionally, a BIER ID assigned by the operator. A BFR establishes BFR adjacencies (IGP or SDN-programmed), computes the BIER routing table, and forwards or replicates BIER packets.
- BIER domain and sub-domain — A BIER domain is a connected set of BFRs, each with a unique BFR ID. A BIER domain can be divided into sub-domains for scalability without a linear increase in size of the BIER header. For example, in IS-IS, a BIER sub-domain is IS-IS multi topology, where ipv4-unicast is a single sub-domain and ipv4-multicast is another sub-domain.Sub-domains provide minimum traffic engineering and separation of services.
- Bit Forwarding Ingress Router (BFIR) — A BFIR is the first PE in a BIER domain entered by a multicast packet. The BFIR adds a BIER header and forwards the packet using the BIER routing table.
- Bit Forwarding Egress Router (BFER) — A BFER is the last PE that processes a BIER packet in a BIER domain. The BFER removes the BIER header before forwarding the packet. This is the only PE that requires a BIER ID as it is a PE with receiver connectivity.
- Transit Bit Forwarding Router (transit BFR): A transit BFT is a router in the BFR domain that is not a BFIR or a BFER that forwards the packet using the best path.
SR OS does not support multicast MPLS packets over an IGP shortcut. This includes BIER MPLS encapsulation. IGP shortcuts can be configured on SR OS for unicast and installed in the RIB or FIB, but BIER will not be resolved over the IGP shortcut. If an IGP shortcut is used for unicast resolution, an IPv4-multicast MT can be used to create a separate MT for BIER without the IGP shortcut.
11.1.1. BIER Hardware
BIER is only supported on FP4 network interfaces. BIER is not supported FP3 or earlier cards, or on access interfaces.
If a chassis has a mix of FP3 and FP4 network ports, BIER is signaled on all FP3 and FP4 interfaces which are part of the IS-IS. From a control plain perspective, BIER TLVs will be advertised using IS-IS on FP3 and FP4 interfaces. The BIER forwarding table will not be downloaded to FP3 cards. As such, there will be no BIER packet forwarding or processing on these cards. If IGP chooses FP3 L3 interfaces, there will be BIER forwarding issues. An event log is generated if an FP3 is part of the BIER sub-domain.
11.1.2. BIER ECMP
BIER supports ECMP/LAG. SR OS only uses the smallest IP address in the ECMP/LAG group to resolve the BFRs.
After an ECMP switch, IGP must download the BIER forwarding table to the new interface or card so BIER ECMP does not have a sub-millisecond recovery. The recovery time is inline with IGP convergence time.
11.1.3. BIER Redundancy and Resiliency
SR OS does not support LFA/TI-LFA for BIER. When there is a failure on the primary next-hop, even if there is a protection next-hop (LFA/TI-LFA), BIER does not switch to the protection next-hop. After the failure, BIER waits for IGP to converge and a new next-hop to be available, which means that traffic interruption is equal to the IGP convergence time. LFA is still configurable when BIER is enabled and can be used for other IP and MPLS functionality.
11.1.4. BIER Layers
A multicast BIER network can be divided into three layers:
- routing underlay (IGP)
- establishes BIER adjacencies based on BIER configuration
- populates BIER routing table (best path reachability)
- provides routing-underlay-based redundancy and convergence, ECMP
- BIER layer (BIER routing table, BIER header)
- advertises and configures the BFR prefix and BIER ID (bitmask bit) for BIER routers
- imposes a new BIER header (bitmask: "OR" for receiver PEs based on their BIER IDs as dictated by multicast flow overlay)
- forwards multicast traffic using the BIER header and BIER routing table
- prevents loops and duplication by using bitmask manipulation and removing the bits for PEs that are not reachable using the L3 interface next hop
- multicast flow overlay (MVPN, BGP)
- uses MP-BGP to distribute and discover the endpoints (RFC-6513 and RFC-6514)
11.1.5. Implementation
Figure 12 shows multicast with BIER deployed. IGP is used as the routing underlay, and MP-BGP for NG-MVPN is used as the multicast flow overlay. The BFIR is the source PE-1, BFERs 2, 256, and 257 are receiver PEs, and the remaining routers are BFRs. All routers have their BIER prefix assigned and, additionally, the BFERs have BIER BFR-IDs assigned.
A BFR prefix is a unicast routable IP address (either IPv4 or IPv6) that is either a system loopback or a loopback interface. BFR prefixes are unique within a BIER domain.
A BFR ID is a unique number assigned to BFERs and BFIRs that is used to build the BIER bitmask used to forward packets. BIER IDs should be allocated as a continuous set of IDs starting at 1 to ensure a minimum number of sets are required to achieve multicast BIER connectivity. Sets allow scaling of BIER beyond the bitmask length supported; however, sets require a separate copy of the multicast packet to be forwarded on the same link which may result in unwanted replication.
Figure 12: BIER High-level IGP and Overlay
11.1.5.1. BIER Sub-domains
Each BIER domain can be divided into sub-domains. A BIER domain supports sub-domains numbered from 0 to 255. Each BIER domain must contain at least one sub-domain, and sub-domain 0 is the default. If a BIER domain contains more than one sub-domain, each BFR in the domain must be provisioned with the set of sub-domains to which it belongs.
A BIER domain is an IGP area, and sub-domains are the different topologies within that area. In IS-IS and OSPF each topology must also have its own sub-domain ID. For example, in IS-IS a sub-domain is an IS-IS multi-topology. SR OS supports two sub-domains in IS-IS: IPv4-multicast and IPv4-unicast MTs. A sub-domain creates the least traffic engineering in a BIER domain. A user can use separate L3 interfaces into IPv4-unicast MT and a set of disjointed interfaces into the IPv4-multicast MT. This creates separation and traffic engineering for different multicast streams.
For each sub-domain to which a given BFR belongs, if the BFR is capable of acting as a BFIR or a BFER, it must be provisioned with a BFR ID that is unique within the sub-domain. If a given BFR belongs to more than one sub-domain, it may have a different BFR ID for each sub-domain but this is not required.
11.1.5.2. BIER Set IDs
To increase scalability of BIT String Length (BSL), routers can be grouped into BIER sets.
The BSL dictates how many BFRs can be represented in a BIER set. Each BIER set can contain as many routers as the length of BSL, and it is represented by a BIER Set ID (SI). The Set Id is part of the packet and represented as <SI:Bit Position>. Figure 13 shows an example set with a BSL of 4.
Figure 13: BIER Set
The BFR ID is programmed into <SI, Bit Position> based on the network BSL.
SI = (BFR-ID – 1)/BSL
BP = ((BFR-ID – 1) mod BSL)+1
For example: BSL 4 and BFR-ID 6 = <SI=1, BP=2>.
BIER works well in an IP TV deployment where the network is in a spine and leaf deployment. SR OS supports 16 set IDs in this type of deployment where there is no packet duplication at the spine.
- The SHO can be connected to as many as 16 VHOs.
- Each tree can have 256 LEAFs without packet duplication.
- Each leaf can have as many hosts on it as the number of supported IGMP/MLD hosts
11.1.5.3. BIER Encapsulation
SR OS supports BIER MPLS encapsulation.
11.1.5.3.1. BIER MPLS Encapsulation
The BIER MPLS labels are downstream-assigned MPLS labels that are unique only to the BFR that advertises them. BIER MPLS labels can be advertised using IGP (IS-IS) extension sub-TLVs or BGP extension sub-TLVs.
Penultimate Hop Popping (PHP) is not supported by BIER-MPLS labels as the labels are used to identify the BIER forwarding table that packets need to be looked up in.
Figure 14 shows the BIER MPLS encapsulation label.
Figure 14: BIER MPLS Encapsulation
A BIER MPLS label is bound to the forwarding element class. A BIER label is assigned per BIER <SD, <BSL, SI>>. The SR OS supports only a BSL of 256.
Labels are chosen from the first available label in the label pool, and are only allocated locally when IGP advertises the BIER sub-TLVs.
When a packet arrives on a BFR the BIER forwarding table is identified using the MPLS label. BIER forwarding is then completed using the BIER header.
11.1.5.4. BIER Forwarding Tables
A BIER forwarding table is built based on the combination of:
- Set ID (SI)
- BIER String Length (BSL)
- Sub Domain (SD)
and saved in the format <SD, BSL, SI>. Figure 15 shows an example of how forwarding tables are built.
Figure 15: BIER Forwarding Tables
For example, if there are 2 SDs and there are 256 PEs in each SD, there will be two forwarding tables, one for each SD. One for <SD=0, BSL=256, SI=0> and the other for <SD=1, BSL=256, SI=0>.
Similarly, if there are 512 PEs in an SD and the BSL is 256, there will be two forwarding tables, one for <SD=0, BSL=256, SI=0> and the other for <SD=0, BSL=256, SI=1>
An MPLS label is assigned locally for each BIER routing table, and advertised.
11.1.5.5. BIER IS-IS Sub-TLVs
BFRs establish BIER adjacencies through IS-IS and exchange their BFR prefixes and BIER IDs as well as transport-related information. IS-IS can be used to exchange the information. Figure 16 shows the IS-IS extensions for BIER and Figure 17 shows a BIER MPLS sub-sub-TLV.
Figure 16: BIER IGP Sub-TLV
Figure 17: BIER MPLS Sub-Sub-TLV
In IS-IS, a new BIER sub-TLV is advertised as part of extended prefix opaque LSA carrying the BFR IP address (loopback) and supported BIER bitmask length for this BFR (multiple TLVs are used to convey support for multiple bitmask lengths). In addition, when MPLS encapsulation is used, a BIER MPLS encapsulation sub-TLV is included that contains the label range used for BIER. The label ranges advertised within the area are unique to a BFR and are used to identify the BIER forwarding context.
Based on the information exchanged, IGP creates a BIER routing table (unicast SPF) to reach each BFER that can be used to route BIER packets. The routing table specifies the shortest unicast path to reach each BFER through (BFERs bitmask, next-hop BFR)-tuples.
BIER sub-TLVs having the wrong length or illegal encoding are ignored and no error is raised. All other sub-TLV or sub-sub-TLV validation is done by the BIER module.
11.1.5.6. IS-IS BIER Support
IS-IS supports multiple levels and BIER is supported under each level using the following rules.
- If the ABR is not a BFIR or BFER, the BIER sub-TLV must be leaked between different levels (areas) at the ABR. A BIER template without a BFR ID must be on both levels.
- The ABR can support BFIR and BFER functionality. ABR does not support BIER header stitching.
- A single area can have level 1 and level 2. In this case, the same template can be programmed on both levels.
11.1.5.7. IS-IS Multi-topologies
IS-IS supports multi-topologies (MT), such as ipv4-unicast, ipv4-multicast, ipv6-unicast, and ipv6-multicast. SR OS supports ipv4-unicast and ipv4-multicast MTs for BIER.
A sub-domain is supported within only one topology. The mapping is indicated by the pair <MT,SD>.
For example, the following combination of <MT, SD>, where MT 0 is IPv4 Unicast and MT 3 is IPv4 multicast, are valid:
<MT=0, SD=0>
<MT=0, SD =1>
<MT=0, SD =2>
However, this combination, where MT 0 is IPv4 Unicast and MT 3 is IPv4 multicast, is invalid because an SD belongs to more than one MT:
<MT=0, SD=0>
<MT=3, SD=0>
IPv4-multicast imports routes into the multicast RTM and ipv4-unicast imports routes into the unicast RTM.
A BIER forwarding table (BIFT) is identified using a label. A BIER label is assigned per (<MT,SD>, SI, BSL) and as such, different MTs point to different BIFTs.
The MT can be used to engineer multicast and BIER routes separately from unicast routes.
11.1.5.8. BIER Intra-AS Solution
For intra-AS solutions, ensure that the ABR loopback interface used as the BIER prefix is included in both Level 1 and Level 2, otherwise the BIER prefix is not resolved at the level into which the route was leaked.Nokia recommends having the loopback interface used as the BIER prefix in Level1/Level2 for intra-AS solutions, which is the default configuration for SR OS.
11.1.5.9. BIER Forwarding
Figure 18 shows that IGP builds the BIFT using IGP. Each node also builds its LTN table based on IGP-advertised MPLS labels.
Figure 18: BIER Forwarding
The BFIR PE (root) has the full BIFT and the corresponding MPLS LTN table.
MP-BGP (multicast overlay) signals each PE interested in a specific customer (S,G) from LEAF PEs to the root PE.
Each PE belongs to a BIER sub-domain based on the IGP multi-topology configuration. For example, PE257 and PE256 are part of the IPv4 unicast topology, while PE2 and PE256 are part of the IPv4 multicast topology.
When the root PE wants to forward a multicast stream, for example a stream for C(S3,G3), it looks up the appropriate PEs in the BIFT. The appropriate SI:BitPosition is assigned a logical “OR” operation to build a single BitString. In this example, BFER-B is assigned 0:0010, BFER-C is assigned 0:0100 and BFER-D is assigned 0:1000, so the "OR" of the two PEs BIFT results in 0:1110 SI:BitString.
The MPLS label (1001) for (SD0,SI0,BSL256) is appended to the BIER BitString and forwarded to BFR-F.
The BFR-F, which has label 1001 as its local label, pops the label and maps the label to the SD0, SI0, BSL256 BIER forwarding table. It then looks up the BIFT for BFER-B, C, and D, and assigns the new SI:BitString of 0:0110 for BFER-B and BFER-C and forwards the packet to BFR-E. In addition, it builds the 0:1000 bit string for BFER-D and forwards the packet to BFER-D. It then looks up the appropriate label for the BFR-E and BFER-D and appends the corresponding label before forwarding the BIER packet.
11.1.5.9.1. BIER FIB Packet Handling
Figure 19 shows how BIER packets are handled in the FIB.
Figure 19: BIER FIB Packet Handling
- When a BIER packet arrives, the PE checks the label and finds the BIFT for that label and then pops the label.
- For the incoming BIER header, it walks the bit index and finds the first entry in the BIFT for that bit position.
- Using a logical “AND”, the BIER header is combined with the BIFT bit-mask and forwarded to the neighbor. If there are multiple neighbors, the BIFT is programmed with a single entry, the neighbor with the smallest IP address.
- Using a logical “NOT” on the BIFT bit-mask entry, the PE finds out which bits remain to be processed.
- Repeat the process until all the BIER header’s bits are processed.
11.1.5.10. BIER MVPN
BIER MVPN uses MP-BGP as an overlay to signal MVPN. It uses RFC 6514 the same way P2MP RSVP-TE.
BIER MVPN introduces a new tunnel type of BIER (0x0B).
BIER PMSI will replace PIM, mLDP, and RSVP-TE P2MP in the core. There is no PMSI per (C-S, C-G), PMSI is used to reach all PE nodes interested in the C-Flow.
The VC label represents the VRF. Within the VRF, the payload IP header (C-S,C-G) will find the OIF based on PIM, IGP, and MLD states.
When a root PE (BFIR) receives a multicast packet and determines that the packet needs to be forwarded to the appropriate BFERs, the source PE encapsulates the multicast packet in a BIER header as described in BIER Encapsulation. The root PE adds the appropriate VC label advertised by MP-BGP and PTA and forwards it to the BIER domain.
Figure 20 shows the BIER MVPN packet format.
Figure 20: BIER MVPN Packet Format
The original packet has a VC label identifying the VRF added first, then the packet (MPLS payload) is forwarded using BIER PMSI by adding a BIER header identifying the BFERs and BIER label learned using IGP from the next-hop router, as described in BIER Forwarding. Finally, when the packet arrives on the BFER, the BIER label is stripped, the BIFT is used to identify whether the packet needs to be handled by a corresponding VRF (since the bit in the header corresponds to the BFER BFR-ID). The BFER strips the BIER header, uses the VC label to identify the VRF instance, strips the VC label, and forwards the packet according to the legacy multicast protocols configured on the SAPs of the MVPN (for example, PIM, IGMP, and MLD OIFs).
SR OS supports BIER as I-PMSI and S-PMSI. By default, all (C-S, C-G) are forwarded using I-PMSI. If a throughput threshold is configured in MVPN and that threshold is surpassed by a (C-S, C-G), then the traffic for that stream is switched from I-PMSI to S-PMSI. BIER uses standard NG-MVPN signaling for S-PMSI and uses leaf AD routes from the leaf PEs to set up S-PMSI to the corresponding leaf that is interested in a specific (C-S, C-G).
The BIER MVPN configuration is as follows.
11.1.5.10.1. BIER MVPN IPv4 and IPv6
BIER MVPN only generates a single VC label and PMSI for IPv4 or IPv6 traffic belonging to the same VRF.
The BIER header protocol is set to "mpls packet with upstream-assigned label". This label is the VC label identifying the VRF that the packet belongs to. After finding the VRF and removing the VC label, a second lookup on the IP header identifies the packet address family (IPv4 or IPv6). Based on the destination IP, which is the multicast group address, the packet is forwarded out the appropriate MVPN OIF SAPs.
11.1.5.10.2. BIER MVPN Sub-domain
An MVPN belongs to a single sub-domain (SD). An SD is assigned to the PMSI of the MVPN, and forces the MVPN to resolve the BGP nexthop within that SD. Both I-PMSI and S-PMSI must be configured with the same SD. Different MVPNs can belong to different SDs. For example, mvpn-1 can belong to SD 0 which is an IPv4 unicast MT and mvpn-2 can belong to SD 1 which is an IPv4 multicast MT. This allows different MVPNs to be traffic engineered between different SDs or IS-IS MTs as needed.
11.1.5.10.3. BIER Templates
A BIER template can be created under the configure>router context and provides a centralized BIER configuration where the operator can configure all the BIER parameters. The BIER template contains the sub-domain to multi-topology mapping and other BIER configurations, such as the BFR ID and BIER prefix.
Each sub-domain can contain a single IGP multi-topology (MT). Currently, SR OS only supports MT for IS-IS but not for OSPF.
A BIER template can contain many MTs and SDs. Each SD has its own BIER prefix and BFR ID and can belong to a different MT. The default MT is ipv4-unicast MT.
A sample BIER template:
After a template is configured it can be assigned to a corresponding IGP protocol. The IGP protocol chooses the first <SD, MT> that matches its own configured MT. For example, if the IS-IS has an MT of IPv4-multicast for the example BIER template, it will use the sub-domain 1 configuration. It will build its BIER forwarding table base on SD 1 SI, BSL and use the BIER prefix configured under sub-domain 1 for its IGP sub-TLVs.