Multicast Redundant Ingress Router Failover

The multicast redundant ingress router failover is an important issue in multicast deployment. This document tries to do a research on it in the multicast domain. The Multicast Domain is a domain which is used to forward multicast flow according to specific multicast technologies, such as PIM (), BIER (), P2MP TE tunnel (), MLDP (), etc. Static configuration, AMT () and SR P2MP Policy () may be used as well. The domain may or may not connect the multicast source and receiver directly. The ingress router is close to the multicast source. The ingress router may be directly connected to the multicast source, or there may be multiple hops between the ingress router and the multicast source. In a multicast domain, the ingress router is the router closest to the multicast source. It is also called the first hop router in PIM, or the BFIR in BIER, or the ingress LSR in P2MP TE tunnel or MLDP. The failover function between the multicast source and the ingress router can be achieved by many ways, and it is not included in this document. The egress router is close to the multicast receiver. The egress router may be directly connected to the multicast receiver, or there may be multiple hops between the egress router and the multicast receiver. In a multicast domain, the egress router is the router closest to the multicast receiver. It is also called the last hop router in PIM, or the BFER in BIER, or the egress LSR in P2MP TE tunnel or MLDP. This document doesn't discuss the details of these technologies. This document discusses the general redundant ingress router failover ways in the multicast domain. This document discusses the global multicast and Service Provider Network MVPN use case with redundant ingress PE nodes upstream multicast hop (UMH) and failover from primary to standby UMH in the multicast domain. This document analyzes the specifications for Multicast VPN Fast Upstream Failover () and the Ingress PE Standby Modes and the benefits of each mode.

The following abbreviations are used in this document: IR: The ingress router closest to the multicast source in the multicast domain. ER: The egress router closest to the multicast receiver in the multicast domain. SIR: The IR responsible for sending multicast flows, or the IR whose flows are received by the ER, is called Selected-IR, or SIR for short. BIR: IR is not responsible for sending multicast flows, or the flow from IR is not accepted by ER, but once SIR fails, IR will replace the role of SIR. This IR is called Backup-IR, or BIR for short.

Typically, a multicast source is connected to two IRs directly or through multiple hops to avoid single node failure. As shown in Figure 1, there are two IRs close to the multicast source. These two IRs are UMH (Upstream Multicast Hop) candidates for ER. The two IRs obtain multicast flows from the multicast source. How to forward the multicast flows to the ER varies according to the technology deployed in the multicast domain. For example, for the PIM used in this domain, two PIM trees can be built with the two IRs as roots. The IR cooperates with other routers in the multicast domain, such as the ER, to minimize multicast flow packet loss during IR switchover.

Some failures may occur in the domain, such as link failure and node failure. If the failed link or node is located on the multicast flow forwarding path, multicast flow packets may be lost. If there are multiple paths from IR to ER, there is no need to switch IR when some nodes or links fail. When PIM is used as the multicast forwarding protocol in a domain, a forwarding tree of (S, G) or (*, G) is pre-built. When a node or link in the forwarding tree fails, the tree is partially rebuilt. When BIER is used as the multicast forwarding protocol within the domain, when a node or link fails, there is no need to rebuild the forwarding tree, and BIER forwarding is restored as the IGP routing converges. When P2MP TE tunnels or MLDP are used as multicast forwarding protocols in a domain, forwarding LSPs are pre-established. When a node or link in the LSP fails, the LSP may be partially rebuilt. When a static multicast tree or SR P2MP policy is used in a domain, the controller needs to recalculate a new forwarding path to bypass the failed node or link. In some cases, there are some critical nodes or links in the network. Due to the failure of critical nodes or links, the multicast path cannot be restored. The IR needs to be switched.

For example, in Figure 2, there is only one path in some areas of the network. IR1 and Rx are key nodes in the domain. When IR1 or Rx fails, there is no other path between IR1 and ER. When PIM is used in the domain, Rm and Rn can select Ry as the upstream node, send Join messages, and build a new tree with IR2 as the root. When BIER is used in the domain, IR2 should be responsible for the forwarding role and forward flow to ER. When P2MP TE tunnel or MLDP is used in the domain, LSP initiated from IR2 can be built and replace the LSP initiated from IR1 when the LSP used does not work. When static multicast tree or SR P2MP policy is used in the domain, the controller should let IR2 forward multicast flow to ER.

For successful IR switchover, some method should be used to monitor IR node failures or path failures between IR and ER, and once failures occur, IR can switchover. Either BFD or PING method can be used. BFD can be used for all deployments. Multipoint BFD can also be used for failure detection between IR and ER. BFD for MPLS LSP can be used for P2MP TE tunnel or MLDP deployments. BIER BFD can be used for BIER deployments. IPv4 PING and IPv6 PING can also be used for all deployments. LSP-Ping can be used for P2MP TE tunnel or MLDP deployment. BIER PING can be used for BIER deployment. BIR and ER can easily detect SIR node and path failures through BFD and PING methods. If monitoring is done between SIR and ER, it is a challenge to quickly trigger a switch when BIR needs to start forwarding multicast flows. If monitoring is between BIR and SIR, the path between BIR and SIR may fail, but the path is not the path from SIR to ER, and BIR may mistakenly trigger a switch, which will generate unnecessary duplicate flow. In this case, ER must support selective reception and be compatible with IR switch errors. In order to minimize false switches, the reliability of SIR/BIR detection needs to be enhanced, such as using redundant reliable paths for detection. Multicast VPN Fast Upstream Failover defines a mechanism to detect the state of P-Tunnel X-PMSI A-D routes using P2MP BFD with a new advertised BGP attribute called the BFD discriminator optional transitive attribute. Multicast VPN Fast Upstream Failover defines a new "Standby PE" BGP community where the downstream PE initiates and sends a "Standby BGP C-multicast route" with the standby upstream PE UMH route RT import EC, which constructs the NLRI using the standby upstream PE UMH route's RD to identify the standby upstream PE.

If there are multiple IRs that can act as UMHs, and if an IR fails, there is no other path from the IR to the ER, and the IR needs to be switched. Multicast IR protection usually has three alternate modes. has some descriptions of this. This document discusses the details of these three modes here. When an ER discovers a node or path failure, it may send a request to the upstream router or IR. The request from the ER may be PIM tree construction, or BIER overlay protocol signaling, or LSP construction, or some other way to let the IR know whether to forward the multicast flow.

In cold root standby mode, ER selects a SIR, such as IR1 in Figure 1, as the SIR and signals it to get the multicast flow. When ER finds that the SIR is down, or ER finds that it cannot receive the flow from IR1, ER signals IR2 to get the multicast flow. For IR, IR (including SIR and BIR) only performs the normal operation of forwarding the flow according to ER's request. For ER, ER must select an IR as the SIR and signal it. When SIR fails or the path between SIR and ER fails, ER must signal BIR to get the flow. For intermediate routers, they know nothing about the role of IR, they just do packet forwarding. There is no duplicate packet in the domain. If an IR switchover occurs, the ER detects the SIR failure and signals the BIR. Packet loss occurs during the signaling process until the ER receives the flow from the BIR.

In warm root standby mode, ER signals IR1 and IR2. If IR1 is SIR, IR1 forwards flow to ER. BIR (such as IR2) shall not forward flow to ER until SIR fails. For IR, IR should play the role of SIR or BIR. BIR shall not forward flow to ER. When SIR fails or the path between SIR and ER fails, BIR must start forwarding flow to ER. But it is difficult to know the path failure by BIR itself, some method should be taken to let BIR get the failure notification. For ER, ER does not choose SIR or BIR. ER just signals to both of them. For intermediate routers, they have no idea about the role of IR, they just do packet forwarding. There are no duplicate packets in the domain. In case of IR switching, the BIR detects the SIR failure and switches to the SIR. There is packet loss during IR switching. In some deployments, the SIR and BIR may be responsible for different multicast flows. For a particular multicast flow, the SIR may be IR1 and for another multicast flow, the SIR may be IR2. So two IRs can share the multicast forwarding load. Another possible deployment is that two IRs can be responsible for different ERs for one multicast flow. For example, IR1 sends some multicast flows to ERs and IR2 sends some other multicast flows to ERs. If IR1 detects a failure among IR1 and ERs, IR1 may notify IR2 to take over the responsibility of forwarding the multicast flows to ERs that previously sent by IR1.

In hot-root standby mode, the ER signals to both IRs. Both IRs send flows to the ER. The ER must discard duplicate flows from one of the IRs. In this case, there is no SIR or BIR. Only the ER knows which IR is the SIR. For the IR, the IR does not need to know the role of the SIR or BIR, the IR just forwards flows based on the request received from the ER. For the ER, the ER signals both IRs for flows. And the ER must discard duplicate flows from the backup BIR. When the SIR fails or the path between the SIR and the ER fails, the ER must switch forwarding planes to forward flow packets from the BIR. It should be noted that ER may choose different SIR or BIR for different multicast flows. For intermediate routers, they do not know the role of IR, they only do packet forwarding. There is duplicate packet forwarding within the domain. In the case of IR switching, ER detects SIR failure. Since there are duplicate flow packets arriving at ER, ER just switches to forwarding the flow from BIR. There may be packet loss during switching.

The following table is a simple comparison of the three modes. "SIR failover" means that the SIR fails or the path between the SIR and the ER fails. role Cold Mode Warm Mode Hot Mode IR Forwards flow based on ER's request. Acting as either SIR or BIR, BIR must not forward flow to ER until SIR fails over. Does not need to know SIR or BIR role, just forwards flow based on ER's request. ER Must select an IR as SIR to signal request, signals BIR to request flow when SIR fails over. Does not select SIR or BIR, just signals both of them. Signals both SIR and BIR. Drops duplicate flow from BIR until SIR fails over. Intermediate routers Know nothing about SIR or BIR. Do not forward duplicate flow. Know nothing about SIR or BIR. Do not forward duplicate flow. No knowledge of SIR or BIR. Forward duplicate flow. Cold root standby mode is the easiest to implement, but has the longest convergence time. Hot root standby mode has the least packet loss, but there are duplicate packet forwardings within the domain, which consumes more bandwidth. Warm root standby mode has a moderate packet loss rate and convergence time, but it is difficult for the BIR to know about the failure between the SIR and ER. The hot root standby mode described in Section 5 is the best UMH protection mechanism. There can be duplicate packet forwardings within the domain, and these packets will be discarded according to Section 6 and Section 9.1. Hot root standby mode is the best recommended method for MVPN fast failover optimization. For network administrators, the most appropriate standby mode should be selected based on the network deployment.

This document does not have any requests for IANA allocation.

This document adds no new security considerations.