PIM FRR

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.

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 1 shows the process of setting up two SPTs for a multicast receiver.

   Figure 1 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 1 describes PIM FRR implementation before and after link or node failure occurs.

   Table 1 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 2, DeviceA permits the multicast traffic on the primary link and discards that on the backup link. Figure 2 PIM FRR implementation before a local primary link failure occurs	In Figure 3, DeviceA permits the multicast traffic on the backup link (DeviceB -> DeviceD -> DeviceA) immediately after the local primary link fails. Figure 3 PIM FRR implementation after a local primary link failure occurs
   Node	In Figure 4, DeviceA permits the multicast traffic on the primary link and discards that on the backup link. Figure 4 PIM FRR implementation before a node failure occurs on the primary link	In Figure 5, DeviceA permits the multicast traffic on the backup link (DeviceC -> DeviceD -> DeviceA) immediately after DeviceB fails on the primary link. Figure 5 PIM FRR implementation after a node failure occurs on the primary link
   Remote primary link	In Figure 6, DeviceA permits the multicast traffic on the primary link and discards that on the backup link. Figure 6 PIM FRR implementation before a remote primary link failure occurs	In Figure 7, DeviceA permits the multicast traffic on the backup link (DeviceC -> DeviceD -> DeviceA) immediately after Device A detects the remote primary link failure. Figure 7 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 8 PIM FRR on a ring network

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

On the ring network shown in Figure 8, DeviceC connects to a multicast receiver. The primarily multicast traffic link for this receiver is DeviceC -> DeviceB -> DeviceA. To compute a backup route for the link DeviceD -> DeviceC, IGP FRR requires that the cost of link DeviceD -> DeviceA be less than the cost of link Device C-> DeviceA plus the cost of link DeviceD -> DeviceC. That is, the cost of link DeviceD -> DeviceE -> DeviceF -> DeviceA must be less than the cost of link DeviceC -> DeviceA plus the cost of link DeviceD -> DeviceC. This ring network does not meet this requirement; therefore, IGP FRR cannot compute a backup route for link DeviceD -> DeviceC.

Before a link or node failure occurs, DeviceC permits the multicast traffic on the primary link and discards that on the backup link. After a link or node failure (between DeviceB and DeviceC for example) occurs, DeviceC permits the multicast traffic on the backup link immediately after detecting the failure.

• When a remote link fault occurs (for example, the link between DeviceA and DeviceB fails), the control plane of DeviceC cannot detect the fault. The master and backup inbound interfaces in PIM entries remain unchanged, and the forwarding plane switches traffic to the backup path.
• When multicast static routes are configured on two adjacent devices, the two devices both use the route passing each other as the primary route. In this case, link fault protection cannot be implemented, and multicast traffic cannot be received.
• The next-hop outbound interfaces of the primary and backup multicast static routes configured on two adjacent devices must be on the same link. For example, the next-hop outbound interface of the primary multicast static route configured on DeviceC must be on the same link as the next-hop outbound interface of the backup multicast static route configured on DeviceB. If there are multiple links between adjacent devices, you need to bind the links to the trunk interface.
• In the case of multi-ring cross, you need to specify the route towards the multicast source as the primary route when configuring the multicast static route for the multi-ring cross node.
• When adding a node to the network, you need to change the next hops of the multicast static routes on the upstream and downstream nodes.

Benefits

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

Limitations

PIM FRR has the following limitations:

• PIM FRR cannot be deployed in multicast extranet scenarios.
• PIM FRR can be deployed only on IPv4 networks.
• Node protection cannot take precedence over link protection in equal-cost multiple path (ECMP) scenarios, because IGPs cannot compute backup paths in ECMP scenarios.
• PIM FRR has the following limitations in non-ECMP scenarios:
  • On an IGP network with PIM FRR deployed, the IGP does not back up the information about the backup link. After a primary/backup link switchover occurs, the multicast backup link may be deleted during smooth data verification. As a result, traffic fails to be switched to the backup link, and rapid switchover cannot be implemented.
  • Only non-ECMP PIM FRR based on LFA FRR is supported. Non-ECMP PIM FRR based on remote FRR is not supported.
  • On a static route network with PIM FRR deployed, a local route to a neighboring device and the route from the neighboring device to the local device cannot be both configured as primary routes. Otherwise, multicast data fails to be received, and link protection cannot be implemented.
  • On a static route network with PIM FRR deployed, you need to modify the multicast static routes of the upstream and downstream devices and affected devices when a new node is added to the network.
• If PIM FRR deployment is based on LFA FRR, PIM FRR also has the limitations that IGP LFA FRR has.
• If PIM FRR deployment is based on LFA FRR, rapid primary/backup link switchover is not supported if the backup link is an ECMP one.
• Regardless of whether PIM FRR is enabled, primary and backup links cannot be generated for multicast traffic if the following conditions are met: A TE tunnel is configured, local MT is enabled, and the TE tunnel interface is the next hop interface of the route to the multicast source.
• On a network that uses multicast static routes, PIM FRR has the following limitations:
  • If load balancing is required, the load balancing modes of neighboring devices must be the same.
  • If a local device's neighboring device is the next hop of the primary link connected to a multicast source, the local device cannot respond to remote route faults. If a remote route fault occurs, multicast users fail to receive traffic. To resolve this issue, configure the next hop address as the multicast source address and a multicast static route as the backup route. (This method does not apply to networks with equal-cost routes. If equal-cost routes exist and an equal-cost route's next hop outbound interface is connected to two or more devices, change the route cost to eliminate equal-cost routes.
  • If loops exist on primary/backup links, PIM entries fail to be deleted even if users have left multicast groups and stopped requesting traffic.
• PIM FRR supports only PIM-SM SPT (S, G) entries. The backup path and PIM-SSM entries are generated only when multicast traffic is transmitted.
• PIM FRR cannot implement link protection in discontinuous multicast IPTV service scenarios.