Average coverage on common networks (that is strongly dependent on the topology) shows variations from 60 to 90%. Indeed, when a link or a node fails, only the neighbors of the failure are initially aware that the failure has occurred and only neighboring node to the failure repair the failure. These repairing routers have to steer datagrams to their destinations despite the fact that most other routers in the network are unaware of the nature and the location of the failure. A common limitation in most of the base LFA mechanism is an inability to indicate the identity of the failure and to explicitly steer the repaired datagram round the failure. Consequently, the extent to which this limitation affects the repair coverage is topology dependent. An advanced LFA solution consists in sequencing the FIB updates either spatially (topologically ordered FIB update from far-end to the near-end neighbor contiguous to the failure) or temporally (timely synchronized FIB updates). For instance, ordered FIB update provides 100% loop-free convergence at the expense of a FIB update time proportional to R x MAX_FIB, where, R is the max (hop) length among paths to edge r used to reach destination t (downstream SPF neighbor prior to the failure) and MAX_FIB is a net-work-wide constant that reflects the maximum time T max required to update a FIB irrespective of the change required. Hence, degrades proportionally to the path length i.e. FIB updates are actually committed at the near-end after reception of a completion message traveling back from the source of max (hop) length among path to edge r used to reach destination t. This solution is not considered outside network maintenance operation as it suffers from slow activation (PUJARI and PRASANNA n.d.) ( Pal and Devi 2013).
Figure 2.2.2 Equal Cost Multiple Paths (ECMP)
As shown in Figure 2.2.2, the next-hop from S towards D along the shortest path is R2. When link S â’ R2 is down, the second shortest path from S is via R1. However, R1 does not know anything about the failure, and its shortest path to D is through S; hence, it cannot be used as a backup next-hop as it would pass packets back to S. Instead, S forwards packets towards R3 in order to avoid the loop. In case the weight of link S â’ R3 was 1, LFA would not be able to find an alternate path to D. These are alternative paths that are longer than the primary path, but still provide loop-free routing to the destination. Such a path exists when a direct neighbor (N) of the detecting node (S) has a path to the destination which can be guaranteed to not tra-verse the failure, i.e. the failed link or node is not included in the alternative path. IP Fast Reroute specifies a condition for Link-protecting alternates and a more restrictive condition for Node-protecting alternates.
2.2.3 Multi-Protocol Label Switching
In , Iselt et al. establish virtual links in the network using Multi-Protocol Label Switching (MPLS) with a specific cost that would enable every node in the network to have equal-cost multi-paths to a destination node. Narvaez et al. develop a method that relies on multi-hop repair paths to route around a failed link. This approach requires message exchanges among nodes within a local neighborhood around the failed link, in order to avoid looping and achieve local re- convergence of routing table. Reichert et al.  propose a routing scheme named O2, where all routers have two or more valid loop-free next hops to any destination. However, the technique does not guarantee single link failure recovery in any two-edge connected network. The IETF community is also showing interest in a solution for fast rerouting in IP networks. Shand and Bryant  present a framework for IP fast reroute, where they mention three candidate solutions for IP fast reroute that all have gained considerable attention. These are multiple routing configurations (MRC) , failure insensitive routing (FIR) , , and tunneling using Not-via addresses (Not-via) . The common feature of all these approaches is that they employ multiple routing tables. However, they differ in the mechanisms employed to identify which routing table to use for an incoming packet (Odom and Beasley 2012) (Balachander, Rajaseka and Arulprakash 2013).
2.2.4 Multiple Routing Configurations
The main idea of MRC is to use the network graph and the associated link weights to produce a small set of backup network configurations. The link weights in these backup Configurations are manipulated so that for each link and node failure, and regardless of whether it is a link or node failure, the node that detects the failure can safely forward the incoming packets towards the destination on an alternate link. MRC assumes that the network uses shortest path routing and destination based hop-by-hop forwarding .According to Amund Kvalbein, Multiple Routing Configurations (MRC) is a proactive and local protection mechanism that allows recovery in the range of milliseconds. MRC is based on building a small set of backup routing configurations that are used to route traffic on alternate paths after a failure. The observation is that if all links attached to a particular node are given sufficiently high link weights, traffic will never be routed through that node. The failure of that node will then affect traffic that acts as a source node at or destined for the node itself. According to T.Cicic, the Internet takes an increasingly central role in our communications infrastructure; the slow convergence of routing protocols after a network failure becomes a growing problem. To assure fast recovery from link and node failures in IP networks, we present a new recovery scheme called Multiple Routing Configurations (MRC) (Kvalbein, Hansen and ËCiËciÂ´, et al. 2009) ( Anji Kumar and Prasad 2011) (Kvalbein, Hansen and ËCiËciÂ´, et al. 2009) ( Thakkar 2014). MRC is based on keeping additional routing information in the routers, and allows packet forwarding to continue on an alternative output link immediately after the detection of a failure. It can be implemented with only minor changes to existing solution. In present MRC, and analyze its performance with respect to scalability, backup path lengths, and load distribution after a failure. We also show how an estimate of the traffic demands in the network can be used to improve the distribution of the recovered traffic, and thus reduce the chances of congestion when MRC is used (Balachander, Rajaseka and Arulprakash 2013).