Modernize Your Multicast Forwarding with Bit Index Explicit Replication (BIER)
By Manomugdha Biswas | Popular multicast services like IPTV, multicast VPN (MVPN), and 4k broadcast video services heavily depend on the multicast forwarding in the network. Multicast forwarding is complex and resource-intensive. In a multicast network, each specific flow requires the construction of a dedicated path tree and each node forwards the packet following the tree. This requires transit nodes to maintain state on a per-flow basis and to participate in multicast-specific tree building. Different multicast tree-building protocols used today include mLDP-P2MP and RSVP-TE P2MP. These protocols have their own complexity, resource requirement, and multicast tree maintenance in the network, making multicast very expensive in terms of resources.
Bit index explicit replication (BIER) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree-building protocols. Overall, it makes multicast much simpler and lighter. The ingress router of the BIER domain adds a "BIER header" to a multicast data packet. The BIER header identifies the packet's egress nodes to which the packet must be delivered. Each possible egress node is represented by a single bit within a BitString in the BIER header. Each packet can then be forwarded along the unicast shortest path from the ingress node to the egress nodes. Thus, there are no per-flow forwarding entries. Nodes only maintain a forwarding table called bit index forwarding table (BIFT). The data packet itself carries egress information in it and a BIER forwarding Router (BFR) forwards the packet based on the information in the data packet. The idea is similar to Segment Routing in unicast. Let’s have a deeper look of BIER now.
The BFR residing at the ingress edge of the BIER domain is called BFR ingress router (BFIR). The BFR residing at the egress edge is called BFR egress router (BFER). BFIR can be treated as BFER at the same time for a traffic flow in the opposite direction. Each edge BFR is identified by a 2 octets unique number called BFR-Id. Each edge BFR is also assigned a BFR-Prefix that is unique within a domain. This BFR-Prefix is distributed by interior gateway protocol (IGP) to populate the BIER forwarding table (BIFT).
Let’s consider the following topology to understand this technology and how it works.
Figure 1: BIER Topology
In this topology, which I’ll refer to throughout this blog, 6 BFRs belong to the BIER domain. BFR-A is BFIR with BFR-Id 4 and BFR-D, BFR-F, and BFR-E are BFERs with BFR-Id 1, 2 and 3 respectively.
When a multicast packet from the customer site arrives at BFIR (BFR-A), BFIR encapsulates the packet in a "BIER header" with the BitString having the bit’s set for corresponding destination BFR (BFER) BFR-Id.
Figure 2. BIER Header
The number of BFERs to which a given packet can be multicast is limited only by the length of the BitString in the BIER header. Different deployments can use different BitString lengths (BSL). It is possible that some deployments would have more BFERs in a given sub-domain than there are bits in the BitString. To accommodate this case, the BIER encapsulation includes both the BitString and a "Set Identifier" (SI). It is the BitString and the SI together that determine the set of BFERs to which a given packet would be delivered.
We now talk about four fields (BIFT-id, Nibble, BSL, and BitString) of the BIER header that help to forward packet through an MPLS network. All other fields are self-explanatory.
Figure 3. BIER header fields used to forward in an MPLS network
BIFT-id is an MPLS label. This MPLS label is provided by the IGP protocol (ISIS-SR/OSPF-SR). Nibble (0101) is used to identify BIER data packet after the MPLS header. The BitString contains the BFERs information.
BFIR retrieves the BIER Label from the IGP, inserts it into the BIER header, and transmits it over the wire. To provide the NgMVPN service using BIER, BFIR can use I-PMSI/S-PMSI of NgMVPN to determine the egress routers interested for a particular flow (S,G). And can use ISIS-SR/OSPF-SR to retrieve BIFT-Id (MPLS Label) by using a tuple of <SD, BSL, SI>. For MVPN use case, the MPLS label carries three implicit bits of information (SD, SI, and BSL). IGP (ISIS-SR/OSPF-SR) exchanges this information, along with BFR-Prefix and BFR-Id, among BFRs. All this information helps to build Bit Index Routing Table (BIRT) and then BIFT table is derived from BIRT table.
BIER is a new technology that needs thorough testing. The capability to process a BIER header and make a forwarding decision is typically done in hardware. The BIER information exchanged through IGP and NgMVPN are software implementations. It is very important to validate, under realistic conditions and scale, to understand the overall functionalities and performance of a BIER solution.
Ixia is actively engaged in continually developing leading technologies to support our customers. We offer a comprehensive BIER test package to help test devices and systems in many ways.
HOW IXNETWORK EFFECTIVELY TESTS ANY BIER DUT
Ixia IxNetwork can simulate BFR and BIER networks to test a device under test (DUT) as BFR in various roles. Below are couple of examples.
- Test Hardware BIER Header Processing: IxNetwork has a flexible packet builder with rich library of templates for various protocol header encapsulation. Objective is to help users to craft raw BIER streams with built-in BIER header template to validate hardware implementation before any software integration.
- Test BIER Functionality as Ingress Router (BFIR-A): IxNetwork will generate native multicast traffic from outside a BIER domain and will send traffic to a DUT (ingress PE). Ixia will simulate two or more BFER (egress PE) as the destination. Objective is to verify that the DUT encapsulates the incoming packet properly and forwards data packets correctly on all destination Ixia port(s).
- Test BIER Functionality as Egress Router (BFER-D, F, E in the diagram): IxNetwork will simulate the traffic source plus BIER ingress routers + P routers and will be connected to the DUT (egress PE). It will also simulate traffic receiver (CE). Objective is to verify that the DUT processes the received BIER encapsulated packet properly and forwards the de-capsulated packet properly to all IxNetwork-simulated receivers.
- Test BIER Functionality as Transit Router (BFR-B, C): IxNetwork will simulate the traffic source, BFIR, and P routers and will be connected to the DUT (P router). It will also simulate multiple BFERs (egress PEs), which will be the receivers. Objective is to verify that the DUT processes the received BIER encapsulated packet properly, consult the BIFT table correctly, and forwards the encapsulated packet properly to all IxNetwork receiver(s).
- Test BIER Segmented P Tunnel Functionality: The DUT is both the BFER and BFIR at the same time. Objective is to verify that the DUT can inter-communicate between two different BIER sub-domains simultaneously.
- Test BIER Functionality as BFR Having One or More Non-BIER-Capable Neighbor(s): Objective is to verify that the DUT can handle non-BIER capable neighbor(s) in the BIER domain.
Let’s illustrate use-case 3, Test BIER Functionality as Transit Router (BFR-B, C), considering BFR-B as the DUT. Let’s assume that BFERs D and E are interested in the flow injected at BFIR-A. BFIR-A (simulated on IxNetwork port) constructs the BitString as 0101 and injects traffic to the DUT (BFR-B). BFR-B replicates data packets and modifies the BitString as shown in the figure below. IxNetwork can measure the received traffic characteristics from E and D both.
Figure 4. BFR-B replcating data packets and modifying the BitString
SIMULATION IN IXNETWORK
The visual configuration in IxNetwork when Ixia simulates the traffic source, BFIR, and P routers will look as below and packet encapsulation at different points in the network is also shown.
Figure 5. IxNetwork UI showing simulation of traffic source, BFIR, and P routers
IxNetwork has an extensive implementation of BIER testing, covering BIER encapsulation, IGP enhancement, automatic traffic construction, statistics, and lot more. It has become extremely effective to test and measure all aspects of a BIER DUT.