BIERv6 Forwarding Plane Fundamentals
Network Architecture and Related Concepts
Figure 1 shows the architecture of a BIERv6 network.
Table 1 describes the key concepts involved in the BIERv6 network.
Concept |
Description |
|---|---|
Domain |
A network domain in which multicast data packets are forwarded using BIERv6. A domain can contain one or a maximum of eight sub-domains. |
Sub-domain |
As a subset of a domain, a sub-domain (SD) is an area where multicast data packets are forwarded using BIERv6, and can contain a maximum of 65535 destination nodes (BFERs) for multicast packets. Each sub-domain can contain one or more IGP areas. It can also contain multiple ASs in an inter-AS static traversal scenario. An IGP area can belong to one or more sub-domains. |
BFR, BFIR, and BFER |
Bit forwarding routers (BFRs) are nodes that forward packets according to the BIERv6 process. A bit forwarding ingress router (BFIR) is an ingress router through which multicast packets enter a sub-domain. A bit forwarding egress router (BFER) is an egress router through which multicast packets leave a sub-domain. Both the BFIR and BFER are BFRs, and they are edge nodes in a BIERv6 sub-domain. |
BFR-ID |
A BFR-ID is an ID manually configured for a BFR. It is an integer ranging from 1 to 65535 and must be configured for each BFER. The BFR-ID is used to calculate the set ID and BitString in the BIERv6 packet header. The set ID is carried in the BIFT-ID field in the BIERv6 packet header. |
When planning sub-domains, ensure that the BFIR and all the BFERs to which the multicast traffic received by the BFIR is to be sent reside in the same sub-domain. This is necessary because sub-domain stitching is currently not supported. To facilitate management and improve the forwarding efficiency on a multicast network, you are advised to plan sub-domains based on the suggestions provided in Table 2.
Network Type |
Suggestion |
|---|---|
Single-AS small- and medium-sized network |
Plan only one sub-domain, with all IGP areas in it. |
Single-AS large-scale network |
The solutions are as follows: Plan only one sub-domain, with all IGP areas in it. In addition, set BFR-IDs and BSLs so that the BFERs in the same IGP area have the same set ID. This helps to improve forwarding efficiency. The concept and calculation formula of a set ID are described in the following section. |
Single-AS multi-topology network |
Plan sub-domains in one domain based on the number of topologies, with each topology corresponding to one sub-domain. |
Multi-AS large-scale network |
Inter-AS static traversal must be deployed. The sub-domain planning solutions are as follows: Plan only one sub-domain, with all ASs in it. In addition, set BFR-IDs and BSLs so that the BFERs in the same AS have the same set ID. This helps to improve forwarding efficiency. The concept and calculation formula of a set ID are described in the following section. |
Mapping Among a BFR-ID, Set ID, and BitString
Each bit in a BIERv6 BitString represents a destination node of a multicast packet. The BitString length (BSL) is limited to a maximum of 256 bits, which cannot meet the requirements of large-scale network deployment. To solve this problem, BIERv6 introduces the set concept.
A set is a group of BFRs. The maximum number of BFRs that a set can contain must not exceed the BSL. In cases where the destination nodes of a multicast packet reside in different sets, the BFIR replicates the multicast packet based on the number of sets to which these destination nodes belong. The BFIR then places the corresponding set IDs into the BIFT-ID field in each BIERv6 packet header, and forwards the copies separately according to the BIERv6 process.
After a BSL is configured on a BIERv6 network, the BFR-ID of each BFER is automatically mapped to a bit (referred to as a bit position) in the BitString and the set ID of each BFER is calculated. The bit position and set ID of each BFER are calculated as follows:
Bit position = (BFR-ID – 1) mod BSL + 1
Set ID = int [ (BFR-ID – 1)/BSL ]
In the preceding formulas, mod indicates a modulo operation, and int rounds down to the nearest integer. Figure 2 shows an example of the mapping among BFR-IDs, a 256-bit BitString, and set IDs.
A set ID and BitString together uniquely identify the destination nodes of each multicast packet in a sub-domain. In cases where the destination nodes of a multicast packet reside in two or more sets, the BFIR replicates the multicast packet based on the number of sets to which these destination nodes belong. On the network shown in Figure 3, the BSL is 256 bits. If the destination nodes of a multicast packet are BFER 1 (with BFR-ID 1) and BFER 2 (with BFR-ID 2), the BFIR needs to send only one packet copy, in which the set ID is 0 and the BitString is ...11 (in this example, ... indicates 254 consecutive 0s). If the destination nodes of a multicast packet are BFER 1 (with BFR-ID 1) and BFER 257 (with BFR-ID 257), the BFIR needs to send two packet copies: one in which the set ID is 0 and the BitString is ...01, and the other in which the set ID is 1 and the BitString is ...01.
Planning BSLs and BFR-IDs properly can reduce the number of multicast packet copies and improve the forwarding efficiency on the multicast network. When planning BSLs and BFR-IDs, you are advised to adhere to the following guidelines:
- Denseness: Set the maximum BFR-ID as the number of BFERs in a sub-domain to deploy as few sets as possible. For example, if a sub-domain contains up to 256 BFERs, allocate BFR-IDs to the BFERs within the range of 1 to 256. Similarly, if the sub-domain contains up to 512 BFERs, allocate BFR-IDs to the BFERs within the range of 1 to 512.
- Uniqueness: Ensure that each BFR-ID is unique in a sub-domain.
- Region: Allocate the BFERs in the same region to the same set.
- Necessity: Allocate BFR-IDs only for BFERs. If a BFIR also functions as a BFER, you also need to configure a BFR-ID for it. For a BFIR-only node (functioning as a BFIR but not a BFER), it does not need to be configured with a BFR-ID.
- Evolvability: Reserve some IDs in each set for future network expansion.
BitString-based Multicast Packet Forwarding
After a BIERv6 network is configured, devices encapsulate the information required for BIERv6 path calculation into the TLVs defined in IS-ISv6 for BIERv6 and flood the TLVs across the network. Based on this information, BIERv6 bit index forwarding tables (BIFTs) that contain BitString information are generated. A BIFT-ID consists of a 4-bit BSL, 8-bit sub-domain ID, and 8-bit set ID, indicating that a BIFT of a BFR is specific to a triplet of <BSL, sub-domain ID, set ID>. For details about IS-ISv6 for BIERv6 and BIFT, see BIERv6 Control Plane Fundamentals.
Each BFR on a BIERv6 network identifies the BitString in a received multicast packet, and then performs packet replication and forwarding based on the corresponding BIFT. Figure 4 shows the forwarding process.
After receiving a multicast packet, each BFR performs the following operations:
- The BFR identifies that the destination address of the packet is the local End.BIER SID and initiates BIERv6 processing.
- The BFR identifies the BIFT-ID and BitString in the packet, and then locates the corresponding BIFT according to the BIFT-ID.
- The BFR reads the first line in the BIFT and performs a bitwise AND operation between the forwarding bitmask (F-BM) in this line and the BitString of the packet to obtain a new BitString.
- The BFR performs one of the following actions based on the calculation result:
- If the new BitString is 0 (all the bit positions are 0), the BFR does not replicate the packet or send a copy to the BFR-neighbor (BFR-NBR).
- If the new BitString is not 0 and the BFR-neighbor is not the BFR, the BFR replicates the packet and replaces the current BitString with the new BitString in the packet copy. It also places the End.BIER SID of the BFR-neighbor in the destination address field of the packet copy, and then forwards the packet copy to the BFR-neighbor.
- If the new BitString is not 0 and the BFR-neighbor is the BFR, the BFR replicates the packet and checks whether the bit position with the value of 1 in the new BitString represents the BFR itself. If the bit position with the value of 1 in the new BitString represents the BFR itself, the BFR removes the BIERv6 header from the packet copy and forwards the packet out of the BIERv6 network. Otherwise, the BFR discards the packet copy.
- The BFR checks the rest of the lines in the BIFT one by one and performs corresponding operations.