MoFRR Path Liveness for Network Failures

Abstract

This document discusses an operational gap in Multicast-Only Fast Reroute when failures occur inside an upstream multicast path but do not cause a visible RIB or RPF change at the merge point. The document motivates the need for a scalable path-liveness mechanism that can detect such hidden multicast delivery failures without requiring expensive per-flow packet monitoring.¶

1. Problem Statement

[RFC7431] describes Multicast-Only Fast Reroute (MoFRR). In MoFRR, a merge point joins a multicast tree through both a primary Upstream Multicast Hop (UMH) and a secondary UMH. Multicast packets may be received on both paths, but the merge point accepts and forwards traffic from only one active RPF path. When failure is detected on the primary path, local repair is performed by switching packet acceptance to the secondary path.¶

One common operational model is RIB-based MoFRR, where the merge point uses changes in source reachability, route state, or RPF information to determine that the primary path should no longer be used. This model can provide fast repair when the failure changes the merge point's route or RPF selection. However, it does not detect all multicast delivery failures. In particular, a failure can occur inside the upstream primary multicast path while the merge point's RIB continues to show the same primary next hop toward the source.¶

                         Source / FHR
                              S
                              |
                             FHR
                           /     \
                 primary /       \ secondary
                         /         \
                       P4           B4
                      /  \         /  \
                     /    \       /    \
                   P2      P3   B2      B3
                    \      /     \      /
                     \    /       \    /
                       P1           B1
                         \         /
                          \       /
                           \     /
                             LHR
                              |
                           Receiver

        Primary RPF at LHR:   toward P1
        Secondary RPF at LHR: toward B1

        Example hidden failure:
             link P2--P4 fails, or node P2 fails.

Figure 1 illustrates the problem. The last-hop router (LHR), acting as the MoFRR merge point, has two upstream multicast paths toward the source or first-hop router (FHR). The LHR joins both paths and selects the path through P1 as primary and the path through B1 as secondary. The primary and secondary paths are both internally redundant, forming diamond-shaped topologies above the LHR.¶

If the LHR-facing primary link or the primary next hop P1 fails, the failure is visible to the LHR and RIB-based MoFRR can react. However, if an internal link or node in the primary diamond fails, such as the P2--P4 link or node P2, the multicast packets on the primary branch may stop reaching the LHR even though the LHR still has the same RIB route and the same primary RPF next hop toward the source. From the LHR's RIB perspective, source reachability has not changed. Therefore, a RIB-based trigger may not switch packet acceptance from the primary RPF path to the already-joined secondary RPF path.¶

In this condition, the secondary path may still be receiving valid multicast packets, but those packets are discarded because the LHR has not changed its active RPF path. The result is multicast traffic loss despite the existence of a working secondary MoFRR path. The underlying issue is that RIB-based liveness does not always imply multicast data-plane liveness for the selected primary path.¶

Flow-based MoFRR can address this class of failure by monitoring packet arrival for each multicast flow and switching to the secondary path if packets are not received on the primary path within a configured time interval. This can detect hidden primary-path delivery failures, but it requires per-flow packet tracking in the forwarding hardware or fast path. In large IPTV or multicast deployments with many active (S,G) flows, maintaining timers and packet-arrival state for each flow can be expensive and may not scale well.¶

There is therefore a need to explore a scalable mechanism for MoFRR path liveness that can detect upstream multicast delivery failures that are hidden from the merge point's RIB, while avoiding the operational and hardware cost of continuous per-flow packet monitoring. Such a mechanism would complement the MoFRR procedures described in [RFC7431] by improving failure detection in topologies where source reachability remains stable but multicast delivery on the active primary path has failed.¶

2. Requirements Language

To be added.¶

3. Terminology

To be added.¶

4. Applicability

To be added.¶

5. Protocol Overview

To be added.¶

6. Path Liveness Signaling

To be added.¶

7. Router Behavior

To be added.¶

8. Relationship to RFC7431

To be added.¶

9. Security Considerations

To be added.¶

11. Open Issues

To be added.¶

12. Acknowledgements

To be added.¶

13. Informative References

[RFC7431]

Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, <https://www.rfc-editor.org/info/rfc7431>.