IPv6-Based BIERin6 Multicast Technology and Standards

2022-03-24 Author:By Zhang Zheng, Wei Yuehua Click:
IPv6-Based BIERin6 Multicast Technology and Standards - ztetechnologies
The browser version you are accessing is too low. To provide better experience, it is recommended that you upgrade the browser toEdgeBrowserOr, it is recommended.GoogleBrowser

IPv6-Based BIERin6 Multicast Technology and Standards

Release Date:2022-03-24  Author:By Zhang Zheng, Wei Yuehua  Click:

Brief Introduction to BIER
Bit indexed explicit replication (BIER) is a new protocol, and IEEE has assigned Ethertype 0xAB37 for BIER. For the first time BIER decouples multicast services from multicast forwarding, so that multicast can be truly based on hierarchical architecture. There is no multicast state in the network. The intermediate forwarding nodes do not need to perceive multicast services, but only need to forward them based on the network topology. As a result, multicast services are no longer restricted by the capabilities of intermediate forwarding nodes, and can fully meets the needs of current and future multicast services.

Three Phases of Developing Multicast Technology
The multicast technology has a history of over 30 years. In the current network, protocol independent multicast-sparse mode (PIM-SM) is the most widely used multicast technology. However, tight coupling between multicast services and multicast forwarding and slow convergence of protocol signaling make PIM-SM difficult to meet the needs of soaring multicast services in the future network.
In recent years, with the gradual development of multicast virtual private network (MVPN), the multicast architecture has begun to evolve to a hierarchical architecture. Multipoint extensions for LDP (MLDP) and point-to-multipoint traffic engineering (P2MP-TE) decouple multicast services from multicast forwarding to some extent, so that they no longer have one-to-one relationships. However, they still have requirements for transport capabilities of the intermediate node tunnels in the network. In addition, like PIM protocol, MLDP and P2MP-TE need to establish and update tunnels based on the interaction of their own protocol signaling. Therefore, when the network topology changes, they need to converge based on their own protocol signaling after routing convergence, and the convergence time is still more than seconds, which cannot meet the requirements of high-reliability multicast services.
BIER completely decouples multicast services from multicast forwarding and achieves a hierarchical architecture of multicast technology. It only needs to build the BIER multicast forwarding layer by using the routing protocols like interior gateway protocol (IGP). When there is a node or link failure in the network, it completes the convergence of the BIER forwarding table as IGP converges, and the convergence time can reach a millisecond level. Moreover, the fast reroute (FRR) and loop-free alternate (LFA) functions of IGP can be inherited. With the two functions of the unicast technology, it not only meets the requirements of ever-increasing multicast services but also serves high-reliability multicast services.

Hierarchical BIER Architecture
The innovative hierarchical architecture of BIER divides the multicast network into the multicast overlay layer, BIER multicast forwarding layer, and routing underlay layer, completely overcoming the disadvantages of tight coupling between traditional multicast services and multicast forwarding (Fig. 1).

Multicast services are identified only by the multicast overlay layer on network edge devices. The multicast overlay layer can be implemented by dynamic protocols or the SDN controller, and is totally independent of multicast forwarding. The multicast forwarding transport layer is the unique forwarding layer of BIER. Its innovative data plane can implement topology-based multicast forwarding without the need for signaling extension overhead. The routing underlay layer is used to construct the BIER forwarding table, and can be implemented merely by routing protocol like IGP extensions. If there are nodes that do not support BIER forwarding in the network, they can be easily bypassed through IGP routing computation.

IPv6 has become a major trend of global network deployment. With the growing number of users supported by IPv6 and the increasing wireless access rate brought by 5G, the traffic in the network is growing explosively. Forwarding multicast flows efficiently and stably in the IPv6 network is an important issue in network development. To achieve this goal, the BIER working group of Internet Engineering Task Force (IETF) has spent many years on research. The mainstream manufacturers have compared and verified various possible implementation solutions, and finally decided to adopt the BIERin6 solution as the only international standard of BIER IPv6.
BIERin6 is a combination of BIER and IPv6. It is flexible and efficient, provides optimal forwarding performance of network equipment, and perfectly supports end-to-end service implementation. In the migration period of deployment, the old equipment in the network does not need to be upgraded in any form, which greatly reduces the difficulty of BIER deployment and accelerates the deployment pace. 
The data plane encapsulation on the BIER forwarding layer inherits the hierarchical characteristics of the BIER technology. Each layer is completely decoupled, independent of each other, and has its own features.
The outermost encapsulation is underlay encapsulation. In BIERin6, the encapsulation at this layer is the simplest IPv6 header, and the next header field in the IPv6 header is directly set to the value that represents the BIER protocol.
BIER header is the core layer that implements BIER forwarding. This part does not change with the outermost encapsulation. Multicast forwarding is completely implemented by this core layer and has nothing to do with other layers.
The innermost layer is the payload of BIER, which carries multicast overlay packets corresponding to overlay multicast services. Multicast services can be carried on this layer no matter in L2 or L3, in IPv4 or IPv6, or in MPLS. During the multicast forwarding, this layer does not need to be identified and perceived by intermediate forwarding devices, but is only managed by network edge devices.
When multicast overlay packets enter the BIER domain, the ingress device encapsulates the BIER header and IPv6 header according to the egress device corresponding to the multicast overlay packets. The intermediate device in the network forwards the packets based on the BIER and IPv6 headers. When the packets arrive at the egress device, the egress device decapsulates the IPv6 and BIER headers and then continues to forward the packets to the receiver. If there is a node in the network that does not support BIER forwarding, like node B in Fig. 2, IGP path computation will directly skip this node. When the previous hop of this node encapsulates the IPv6 header, it sets the destination address (DA) to the IPv6 address of the next-hop node that supports BIER forwarding. In this way, seamless forwarding can be achieved without any upgrade requirement for node B.

SRv6-Based Cross-Node Interoperability
Segment routing over IPv6 (SRv6) is a technology that forwards the packets through the preset path based on the new IPv6 extension headers. When the BIER technology is deployed in an IPv6 network, if some domains do not support BIER forwarding, the SRv6 technology can be used to traverse the specified path. BIERin6 can be used together with the IPv6 segment routing header (SRH) for traversal. The traversed device does not need to identify the BIER header.

As shown in Fig. 3, the key node R2 in the network does not support BIER forwarding, but supports SRv6. To ensure that packets can be forwarded to BFER3 along the path where R2 is located, BFIR1 in the figure serves as the ingress node. Besides encapsulating BIERin6 packets that can reach the egress nodes BFER1 and BFER2, it is also necessary to encapsulate the BIER packets that contain the IPv6 SRH path of the R2 node to ensure that they can reach the egress node BFER3. According to the principle defined by RFC8200 (IPv6 Specification), the ingress node BFIR1 encapsulates the SRH route extension header after the IPv6 header, and then encapsulates the multicast packets carried by the BIER header. When the packets arrive at the R2 node, the R2 node processes the packets according to the SRH processing flow, and forwards the packets to BFER3 without additional judging or processing the BIER header.

Implementation of Various Services
BIERin6 fully inherits the features of BIER and supports various multicast services. It seamlessly adapts to global IPv4/IPv6 multicast, L2 multicast, BUM of EVPN, and MVPN services.
The high expansibility of MP-BGP makes it easy to extend and adapt to various multicast services. All public network services are forwarded by BIER. The services are isolated from each other and do not interfere with each other. All services are encapsulated and decapsulated on edge PE nodes (Fig. 4). Even for global multicast services, the intermediate node does not need to be aware of them at all.

The security of multicast services can also be guaranteed by PE. After being encrypted by security means, the multicast service is encapsulated into the BIERin6 header as the payload of the BIERin6 packet and then forwarded. If the packet is large and needs to be fragmented, similar to security, the service packet is fragmented first and then encapsulated into the BIERin6 header. In this way, the security and fragmentation is only processed on the ingress and egress PEs. The intermediate node only needs to forward the packet to the destination PE along the BIER path, without any impact on its performance. 

Supporting New Programmability of Services
BIERin6 also supports new programmability of MVPN and EVPN services. It inserts the multicast service segment identifier between the BIER header and the subsequent service packet to realize network programmability.
Due to the hierarchical architecture of BIERin6, the multicast service segment identifier has no impact on the forwarding, encapsulation and resolution of BIER packets at all, and there are no customization requirements for the outermost underlay encapsulation. The egress node decapsulates the packets layer by layer. After removing the IPv6 outer layer encapsulation and the BIER header, it can directly resolve this identifier and decide the subsequent service forwarding action according to the identifier. The overall flow is smooth and clear.

To sum up, BIERin6 is the best solution for BIER deployment in the IPv6 scenario. It fully leverages the advantages of hierarchical BIER architecture and works with SRv6 to skip nodes in specified paths. In the transition scenarios, BIERin6 does not require any upgrade of other devices. Because it is easy to implement and deploy, BIERin6 is the best way to implement BIER in the IPv6 network.