Several service providers, such as those providing multicast services, e.g., Video over Internet Protocol (VoIP), IP television (IPTV), etc., deliver multicast content from one or more head-end nodes (e.g., Points of Presence, or POPs) to one or more tail end nodes (e.g., several tail-end nodes per head-end node) over a point-to-multipoint (P2MP) tunnel. In one scenario, the head-end node receives the multicast traffic from a multicast network and transmits the multicast traffic onto the P2MP tunnel. Also, the tail-end node receives the tunneled traffic, and forwards the received traffic to another multicast network located at the tail-end node, for example, to reach end-user devices (client televisions, etc.). Notably, the P2MP tunnel, e.g., established using Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), offers a tunnel connection through the service provider's (and others') network, which, as those skilled in the art will understand, allows for various tunnel advantages to be achieved through the network, such as bandwidth reservation, etc.
One particular benefit of a tunnel is its ability to provide “Fast Reroute” (FRR) functionality to protect against intermediate node failure along a primary tunnel. That is, an FRR backup tunnel may be established to protect one or more nodes (or links) along the primary tunnel and, in the event the node (or link) fails, the point of local repair (PLR) quickly reroutes the primary tunnel traffic onto the backup tunnel to circumvent the failed element. However, because the FRR backup tunnel generally needs to intersect the primary tunnel (i.e., the backup tunnel generally starts and ends at the primary tunnel), failure protection is generally not available to a head-end node and a tail-end node of the tunnel.
For instance, for P2MP tunnels receiving multicast traffic, in the event that a head-end node of a primary P2MP tunnel fails, then a backup head-end node is configured to rerouted the multicast traffic onto a corresponding backup P2MP tunnel. This process may require cumbersome configuration (e.g., manual configuration) to determine the backup head-end node that may be suitable to assume the responsibility of the failed head-end node. Particularly, the backup P2MP tunnel has generally already been established (i.e., prior to failure) from the backup head-end node to each of one or more tail-end nodes originally receiving tunnel traffic from the failed head-end node. In addition, the primary and backup (and other possible backup) P2MP tunnels from the multicast network to the tail-end nodes inefficiently reserve resources (e.g., bandwidth) since the tunnels are computed separately, without consideration for shared resources (i.e., where the primary and backup tunnels utilize the same links/nodes).