Background

SPT setup relies on unicast routes. If a link or node failure occurs, a new SPT can be set up only after unicast routes are converged. This process is time-consuming and may cause severe multicast traffic loss.

PIM FRR resolves these issues. It allows a device to search for a backup FRR route based on unicast routing information and send the PIM Join message of a multicast receiver along both the primary and backup routes, setting both primary and backup SPTs. The cross node of the primary and backup links can receive one copy of a multicast flow from each of the links. Each device's forwarding plane permits the multicast traffic on the primary link and discards that on the backup link. However, the forwarding plane starts permitting multicast traffic on the backup link as soon as the primary link fails, thus minimizing traffic loss.

NOTE:

PIM FRR supports fast SPT switchovers only in IPv4 PIM-SSM or PIM-SM. In extranet scenarios, PIM FRR supports only source VPN, not receiver VPN entries.

Implementation

PIM FRR implementation involves three steps:

1. Setup of primary and backup SPTs for a multicast receiver

   Each PIM-SM/PIM-SSM device adds the inbound interface information to the (S, G) entry of the receiver, and then searches for a backup FRR route based on unicast routing information. After a backup FRR route is discovered, each device adds the backup route's inbound interface information to the (S, G) entry so that two routes become available from the source to the multicast group requested by the receiver. Each device then sends a PIM Join message along both the primary and backup routes to set up two SPTs. Figure 4-16 shows the process of setting up two SPTs for a multicast receiver.

   Figure 4-16 Setup of primary and backup SPTs for a multicast receiver
   

2. Fault detection and traffic protection

   After the primary and backup SPTs are set up, each multicast device on the primary link receives two copies of a multicast flow. Their forwarding planes permit the multicast traffic on the primary link and discard that on the backup link. If the primary link or a node on the primary link fails, the forwarding plane starts permitting the traffic on the backup link as soon as it detects the failure. Table 4-4 describes PIM FRR implementation before and after link or node failure occurs.

   Table 4-4 PIM FRR implementation before and after a link or node failure occurs

   Failure Type	Before a Failure Occurs	After a Failure Occurs
   Local primary link	In Figure 4-17, Device A permits the multicast traffic on the primary link and discards that on the backup link. Figure 4-17 PIM FRR implementation before a local primary link failure occurs	In Figure 4-18, Device A starts permitting multicast traffic on the backup link (Device B -> Device D -> Device A) as soon as the local primary link fails. Figure 4-18 PIM FRR implementation after a local primary link failure occurs
   Node	In Figure 4-19, Device A permits the multicast traffic on the primary link and discards that on the backup link. Figure 4-19 PIM FRR implementation before a node failure occurs on the primary link	In Figure 4-20, Device A starts permitting multicast traffic on the backup link (Device C -> Device D -> Device A) as soon as Device B fails on the primary link. Figure 4-20 PIM FRR implementation after a node failure occurs on the primary link
   Remote primary link	In Figure 4-21, Device A permits the multicast traffic on the primary link and discards that on the backup link. Figure 4-21 PIM FRR implementation before a remote primary link failure occurs	In Figure 4-22, Device A starts permitting multicast traffic on the backup link (Device C -> Device D -> Device A) as soon as Device A detects the remote primary link failure. Figure 4-22 PIM FRR implementation after a remote primary link failure occurs

3. Traffic switchback

   After the link or node failure is resolved, PIM detects a route change at the protocol layer, starts route switchback, and then smoothly switches traffic back to the primary link.

PIM FRR in Scenarios Where IGP FRR Cannot Fulfill Backup Root Computation Independently

PIM FRR relies on IGP FRR to compute both primary and backup routes. However, a live network may encounter backup route computation failures on some nodes due to the increase of network nodes. Therefore, if IGP FRR cannot fulfill route computation independently on a network, deploy IP FRR to work jointly with IGP FRR. The following example uses a ring network.

Figure 4-23 PIM FRR on a ring network

NOTE:

In a PIM FRR scenario on a ring network, the intermediate devices between a multicast source and receivers must be Huawei devices and configured with PIM FRR.

On the ring network shown in Figure 4-23, Device C connects to a multicast receiver. The primarily multicast traffic link for this receiver is Device C -> Device B -> Device A. To compute a backup route for the link Device D -> Device C, IGP FRR requires that the cost of link Device D -> Device A be less than the cost of link Device C -> Device A plus the cost of link Device D -> Device C. That is, the cost of link Device D -> Device E -> Device F -> Device A must be less than the cost of link Device C -> Device A plus the cost of link Device D -> Device C. This ring network does not meet this requirement; therefore, IGP FRR cannot compute a backup route for link Device D -> Device C.

Before a link or node failure occurs, Device C permits the multicast traffic on the primary link and discards that on the backup link. After a link or node failure occurs, Device C starts permitting the multicast traffic on the backup link as soon as it detects the failure.

Benefits

PIM FRR helps improve the reliability of multicast services and minimize service loss for users.