A survey of IP and multiprotocol label switching fast reroute schemes

Computer Networks 51 (2007) 1882–1907 www.elsevier.com/locate/comnet

A survey of IP and multiprotocol label switching fast reroute schemes Alex Raj a, Oliver C. Ibe

b,*

a

b

Cisco Systems, Inc., 1414 Massachusetts Avenue, Boxborough, MA 01719, United States Department of Electrical and Computer Engineering, University of Massachusetts, Lowell, MA 01854, United States Received 5 December 2005; received in revised form 6 June 2006; accepted 21 September 2006 Available online 19 October 2006 Responsible Editor: M. Smirnow

Abstract One of the desirable features of any network is its ability to keep services running despite a link or node failure. This ability is usually referred to as network resilience and has become a key demand from service providers. Resilient networks recover from a failure by repairing themselves automatically by diverting traffic from the failed part of the network to another portion of the network. This traffic diversion process should be fast enough to ensure that the interruption of service due to a link or node failure is either unnoticeable or as small as possible. The new path taken by a diverted traffic can be computed at the time a failure occurs through a procedure called rerouting. Alternatively the path can be computed before a failure occurs through a procedure called fast reroute. Much attention is currently being paid to fast reroute because service providers who are used to the 50-ms failure recovery time associated with SONET networks are demanding the same feature from IP and MPLS networks. While this requirement can easily be met in SONET because it operates at the physical layer, it is not easily met in IP and MPLS networks that operate above the physical layer. However, over the last few years, several schemes have been proposed for accomplishing 50-ms fast reroutes for IP and MPLS networks. The purpose of this paper is to provide a survey of the IP fast reroute and MPLS fast reroute schemes that have been proposed.  2006 Elsevier B.V. All rights reserved. Keywords: MPLS networks; IP fast reroute; Protection switching; Micro-loop prevention; Loop-free alternate; U-turn alternate

1. Introduction One of the desirable features of any network is its ability to keep services running despite a link or node failure. This ability of a network to keep services running despite a failure is usually referred to as network resilience and has always been a key *

Corresponding author. Tel.: +1 978 934 3118. E-mail address: [email protected] (O.C. Ibe).

attribute for a network infrastructure. Service providers commonly advertise availability numbers for business services. If they fail to meet the advertised availability numbers, the providers are likely to pay penalties to their customers. Resilient networks recover from a failure by repairing themselves automatically by diverting traffic from the failed part of the network to another part of the network. This traffic diversion process should be fast enough to ensure that the interruption of service due to a link

1389-1286/$ - see front matter  2006 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2006.09.010

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

or node failure is either unnoticeable or as small as possible. The new path taken by the diverted traffic can be either computed at the time failures occur or before failures. The first method of traffic diversion in which a new path is established for traffic restoration after the occurrence of a fault is called restoration or reroute. The other method of traffic diversion in which a backup path is pre-established for traffic restoration before the occurrence of a fault is called protection switching or fast reroute. Fast reroute mechanisms provide decreased interruption of service compared to non-pre-planned schemes. However, they may introduce additional complexity and consume valuable resources, such as extra connectivity and computational cycles to compute backup paths. A major challenge in an IP network [36] is for the nodes to converge on a common view of the new topology after a node or link failure has occurred. During this process, which is referred to as a routing transition, packet delivery between certain source– destination pairs may be disrupted. This is due to the time it takes for the topology change to be propagated around the network, plus the time it takes each node to determine and then update the forwarding information base (FIB) for the affected destinations. FIB maintains the forwarding information derived from the IP routing table. Thus, when routing or topology changes occur in the network, the routing table is updated, and those changes are reflected in the FIB. During a routing transition, packets may be lost because of the continuing attempts to use the failed component, and also as a result of the formation of forwarding loops called micro-loops. Micro-loops arise from the inconsistent FIBs that occur as a result of the difference in time taken by nodes to execute the routing transition process. Thus, while a node closer to the failed component can quickly revise its routes to work around the failure, a node that is farther away will take a much longer time to react to the failure, and this leads to inconsistencies that give rise to forwarding loops. Although service failures caused by routing transitions are largely hidden by higher-level protocols that retransmit the lost data, new Internet services are emerging that are very sensitive to the packet disruption that occurs during a transition. For the routing transition to be transparent to such users, it should be as short as possible. The best-case scenario is for the routing transitions to be completed in zero time with no packet loss. Transient microloops are common in current IP networks. How-

1883

ever, because there is no strict time imposed on the normal reroute, transient micro-loops are not an issue for the normal reroutes. Service providers are used to the fact that the Synchronous Optical Network (SONET) standards specify that the service interruption time should not exceed 50 ms, which is short enough for the outage to be unnoticeable by customers who participate in a live conversation where voice is carried over a SONET network. This has motivated Layer 3 designers of fast reroute schemes to aim at solving the reroute traffic loss issues, including micro-loops, in no more than 50 ms. Rerouting in SONET occurs at the physical layer, which is fast but requires extra dedicated fiber. On the other hand, current IP rerouting does not satisfy the 50-ms failure recovery requirement. Over the last few years, several schemes have been proposed for accomplishing the 50-ms fast reroutes for IP and Multiprotocol Label Switching (MPLS) networks [31]. These have come to be known as IP fast reroute (FRR) and MPLS fast reroute schemes, respectively. MPLS networks use two interior gateway protocols (IGPs), namely Label Distribution Protocol (LDP) and Resource Reservation Protocol (RSVP) Traffic Engineering (TE) protocol. Since the fast reroute procedures are defined in the Layer 3, each of these MPLS protocols requires its own fast reroute scheme. The purpose of this paper is to provide a survey of the IP fast reroute and MPLS fast reroute schemes that have been proposed. The paper is organized as follows. Section 2 provides an overview of MPLS. Section 3 discusses different types of micro-loops. Section 4 discusses MPLS Traffic Engineering fast reroute schemes. Section 5 discusses IP fast reroute schemes. Section 6 discusses MPLS LDP fast reroute schemes that use IP fast reroute. Finally, concluding remarks are made in Section 7. 2. MPLS overview MPLS capabilities enhance the services provided by IP networks by providing strict quality of service (QoS) and traffic engineering. Traffic engineering gives network operators a great deal of flexibility to divert and route traffic around link failures and congestion points in a network. In an MPLS network, incoming traffic is assigned a ‘‘label’’ by a label edge router (LER). Traffic is forwarded along a label switched path (LSP) where each label switch router (LSR) makes forwarding decisions based

1884

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

solely on the contents of the label. At each hop, the LSR removes the existing label from a packet and applies a new label, which tells the next hop how to forward the packet. Label switched paths can be established either automatically or by network operators for a variety of purposes, such as to guarantee a certain level of performance, to route around network congestion, or to create IP tunnels for virtual private networks. An LSP can be established that crosses multiple Layer 2 transports, such as ATM, Frame Relay or Ethernet. Thus, one of the true promises of MPLS is the ability to create end-to-end circuits, with specific performance characteristics, across any type of transport medium, eliminating the need for overlay networks or Layer 2-only control mechanisms. MPLS label switching methods allow routers to make forwarding decisions based on the contents of a simple label, rather than by performing a complex route lookup based on destination IP address. However, this initial justification for technologies such as MPLS is no longer perceived as the main benefit because Layer 3 switches (or ASIC-based routers) are able to perform route lookups at sufficient speeds to support most interface types. MPLS is normally built with a scalable IP control plane and technology-independent data plane. It is used with IP packet routers, ATM switches and optical switches in the data plane. This helps in keeping the benefits of all these data plane technologies while building a large scalable network. The above observation notwithstanding, MPLS brings many other benefits to IP-based networks, and these include: • IP Virtual Private Networks (VPNs) – Using MPLS, service providers can create Layer 3 IP VPNs in their networks, with private route and forwarding tables. • Layer 2 Transport – New standards being defined by the IETF’s PWE3 and PPVPN working groups allow service providers to carry Layer 2 services, including Ethernet, Frame Relay and ATM, over an IP/MPLS core. • MPLS Traffic Engineering (TE) – This employs the constraint-based routing in which the path for a traffic flow is the shortest path that meets the resource requirements or constraints of the traffic flow. • MPLS TE Fast ReRoute (FRR) – This mechanism routes traffic around network outages using a pre-determined path and provides telecommu-

nications networks the same 50-ms protection as SONET. Thus, it is a mechanism that is used to protect MPLS TE LSPs from link and node failures by locally repairing the LSPs at the point of failure, allowing data to continue to flow on them while their headend routers attempt to establish new end-to-end LSPs to replace them. A backup path that bypasses only a single link of the primary path provides link protection, and a backup path that bypasses a single node of the primary path provides node protection. Therefore, the flexibility of MPLS enables modern networks to achieve next-generation Layer 2 and Layer 3 VPNs, better QoS, and scalable control plane for optical networks. MPLS uses two signaling protocols to establish and maintain the label bindings between MPLS nodes in the IGP and hence set up LSPs within an MPLS network. These are • Resource Reservation Protocol (RSVP) Traffic Engineering (TE), which is used to establish MPLS LSPs when there are traffic engineering requirements. Thus, it is primarily used to provide QoS and load balancing across the network core. It uses MPLS tunnels that forward the traffic along the explicit path. The tunnel explicit path can be provisioned, or it can be automatically computed using the constraint-based shortest path first (CSPF) calculations. In RSVP-TE fast reroute, when the failure occurs on the Packet over SONET (POS) network, the traffic is routed to the backup tunnel within 50 ms. The RSVP-TE fast reroute time or data loss is comparable to the SONET automatic protection switching (APS). Service providers prefer the RSVP-TE fast reroute over SONET APS protection because RSVP-TE does not require additional expensive fiber for protection. RSVP-TE fast reroute has been used in MPLS service provider networks for many years. • MPLS Label Distribution Protocol (LDP), which is used for setting up LSPs based on IP routes. LDP provides automatic MPLS tunnels according to IP routes with MPLS label encapsulation. Unlike RSVP-TE, LDP does not have the capability of source routing and directed forwarding. The LDP LSP always follows the IP route. Because LDP is simple and easy to configure and manage, most service providers use LDP for their network core.

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

1885

3. Fast reroute and micro-loops

3.1. Multiple path loops or FRR loops

As discussed earlier, IP reroute goes through a few processes, such as failure detection, forwarding path removal, failure advertisement to remote devices, path computation, and new path installation. Depending upon the number of network prefixes, router architecture, and processor speeds, the failure notification, forwarding path removal and new path installation may take anywhere from a few milliseconds to several hundred seconds. The above procedures need to be modified to take no more than 50 ms when fast reroute is used, regardless of the number of network prefixes, architecture, and processor speed. In the first instance, fast reroute provides a very rapid repair path that prevents any further packet loss from dropped traffic. But then in most cases, it reconverges the network on the new topology. This would normally be accompanied by micro-loops that would cause further traffic disruption. Thus, to achieve fast reroute in 50 ms or less, it is necessary to avoid all the micro-loops. In a fast reroute mechanism, a loop-free backup path is pre-computed along with the normal path computation for every destination. The backup path must be loop free with itself and with other backup paths. The loop between multiple backup paths or a backup path and the routed path is called multipath loop or FRR-loop. A fast failure detection mechanism is used on the local device to detect failures in a few milliseconds. When a failure is detected, the backup path is invoked and traffic is forwarded using the pre-computed backup path. Then the node propagates the local failure to the remote nodes. When the failure is known by a node, it recomputes the path to the destination. In the connectionless IP network, each node computes and installs the forwarding entries independently. During the convergence, if some devices in a network have old forwarding entries and other devices have new forwarding entries, the forwarding entries could point to each other and form a loop. As discussed earlier, these FIB-inconsistency related forwarding loops are called microloops.

The looping backup path can be created in many ways. The following examples illustrate different cases where the backup path could be looping. Fig. 1 shows the forwarding loop when two linkprotecting backup paths pointing to each other are used during a node failure. In this topology, when router R3 fails, routers R1 and R2 use their linkprotecting backup paths for the node failure. The backup path for R1 calls for R1 to forward traffic destined for D to R2 when R3 fails, and the backup path for R2 calls for R2 to forward traffic destined for D to R1 when R3 fails. These two link-protecting backup paths create the forwarding FRR loop {R1, R2, R1, R2, . . .}. This is a direct FRR loop. The above example shows a forwarding loop with only two backup paths. It is also possible to have forwarding loops with multiple backup paths, as illustrated in Fig. 2. In this case, when R3 fails, R1 uses its backup path and sends the traffic to R2. Since R2’s routed path failed due to the same R3 failure, R2 uses its backup path and forwards the traffic to R4. Similarly at R4, R3’s failure causes it to use its backup path to R5, which uses its routed path and forwards the traffic back to R1, thereby causing the forwarding FRR loop {R1, R2, R4, R5, R1, R2, . . .}. This is an indirect FRR loop. The above failure could be characterized as multiple related failures. Links (R1–R3), (R2–R3) and (R4–R3) fail when the node R3 fails. When only link protection is available (as opposed to link and node protection), the node must distinguish between the link and node failures and use the link protection only during the link failures. By link protection we mean that when a link fails, there exists a loopfree backup path to protect that failure. Similarly, by node protection we mean that when a node fails,

R1

R2

R3 Routed path Backup path

Thus, we see that during FRR, loops can be created in two ways: • Multiple path loops or FRR loops. • FIB inconsistency micro-loops.

D Fig. 1. Node failure and direct FRR loop.

1886

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

R1

R5

R2

R2

R1

Switch L

Backup path Routed path

R3 R4

D

Routed path Backup path

D

Figure 3 Fig. 3. Link (R1–L) failure.

Fig. 2. Node failure and indirect FRR loop.

there exists a loop-free backup path to protect that failure. The links sharing the same risk are defined as a Shared Risk Link Group (SRLG). When the backup path is computed, this SRLG information must be included in the backup path computation to avoid loops. The SRLG is commonly associated used with optical link bundles. Multiple optical fibers are bundled in a single physical transport during the optical cable installation. When the optical cable is damaged, it affects all the fibers traveling in that bundle. For example, in Fig. 2 the links (R1–R3), (R2–R3), and (R4–R3) could be fibers on the same optical transport bundle. When there is a cut in this bundle, it creates multiple related failures, as in the case of the R3 failure. The router R3 failure can also be considered as an SRLG’s failure to compute a loop-free backup path. This type of fiber bundle or single-point-of-failure information must also be considered during the loop-free backup path computation to avoid loops. When there is a Layer 2 switch between the Layer 3 devices, only the local device directly attached to the failure can detect the link failure. Until the remote device detects the failure, the traffic is dropped. Therefore, when there is a Layer 2 switch between the Layer 3 devices, other fast failure-detection procedures, such as Bidirectional Forwarding Detection (BFD) [19] or protocol-specific fast hello, must be used. BFD is a protocol used to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, logical sub-interfaces, data link(s), and, if possible, the forwarding engines themselves, with potentially very low latency. BFD operates independently of media, data protocols, and routing protocols. In Non-Broadcast Multiple Access (NBMA) networks, such as local area networks (LANs), there

are two possible types of failures: failure of a link between a Layer 3 router and the Layer 2 switch, and failure of the Layer 2 switch. In the LAN environment shown in Fig. 3, when the link connecting R1 to the switch L fails, R1 uses the backup path to R2. This is similar to the router case if the link has a single neighbor. If the link is connecting multiple neighbors using Virtual LAN (VLAN) interfaces, then the collection of VLANs on a link can be considered as a shared risk link group, and SRLG-based backup path computation should be used to compute the backup path. In Fig. 4, when the switch L fails, R1 sends the traffic to R2 and R2 sends it back to R1, thereby creating a loop. This is similar to the router failure shown in Fig. 2. However, the node failure mechanism used in the routers cannot be used on the switch L. Fast reroute mechanisms normally use link-state topology to compute the backup path. In the linkstate topology, routers in one area do not have knowledge of the topologies of other areas. This limited knowledge may limit the use of inter-area

R1

R2

Switch L Backup path Routed path D

Figure 4 Fig. 4. Switch L failure.

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

1887

R6 Routed Path

Area 1

Computed backup path Actual backup path ABR1

ABR2 R1 R5 Area 0

R2 R3

D R4

Fig. 5. Inter-area backup path loop.

IGP. Since this external destination D is reachable via two or more nodes, it is referred as a multihomed (or multihoming) prefix. Multihoming prefixes and their backup paths can also create forwarding loops. Fig. 6 shows multihoming networks and their associated link failure. In Fig. 6, when the link (R3–D) fails, R3 forwards the traffic to node R1. If R1 does not know about the failure or if the backup path traffic is not differentiated or tunneled through R1, it forwards it back to R3 creating the forwarding loop {R3, R1, R3, R1, . . .}. Fig. 7 shows multihoming networks and their associated node failures. In Fig. 7, the failure of node D can create a loop between R3 and R4. If these nodes are external nodes, the ‘‘node’’ versus ‘‘link’’ failure may not be detected and thus causes the forwarding loop. In this case, both R3 and R4 detect the link failure and use their backup paths, thereby causing the forwarding loop {R3, R1, R2, R4, R2, R1, R3, . . .}. In some cases, there may be a network separating this multihoming device, which may make it difficult to detect the node failure. In the case of external

backup paths and reduce the protection coverage for the inter-area backup paths. Fig. 5 shows an inter-area backup path loop. In this topology, when the next hop link to D fails, router R5 takes the computed backup path {R5, ABR1, R1, R2, R3, R4, D}. Assume that ABR1 has a different path {ABR1, R6, ABR2, R5, D} to the destination D that is different from the path that R5 thinks ABR1 would use based on R5’s limited view of the topology. Thus when the rerouted traffic arrives at ABR1, the traffic is forwarded to R6, ABR2 and R5 thereby creating the forwarding loop {R5, ABR1, R6, ABR2, R5, . . .}. As we can see, there may be multiple devices between R5 and ABR1. Therefore, a backup path computation mechanism must consider this type of inter-area backup path loop and avoid the forwarding loop. In Fig. 6, external node D is connected to both R3 and R4. The interior gateway protocol used within an autonomous system does not have the visibility of this node D. The routers R3 and R4, which are connected to this external node, advertise the reachability of this node D to the routers in the R2

R1

R3

R4

Actual backup path Routed path Backup path

External device D

D Fig. 6. Multihoming link failure.

1888

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

R1

R2

R3

R4 Actual backup path Routed path Backup path

External device D

D Fig. 7. Multihoming node failure.

during a fast reroute. When the backup path travels through the ECMP path, the backup path computation procedure must ensure that none of the ECMP paths makes any forwarding loops during the fast reroute when the backup path is used. For example, in Fig. 8, if all the links have a cost of 1 unit or the routing metric is the hop count, then R1 has three ECMP paths to D, which are {R1, R4, R5, D}, {R1, R6, R3, D} and {R1, R2, R3, D}. R3 has the link (R3–D) protecting backup path {R3, R2, R1, R4, R5, D}. When the link (R3–D) failure occurs, this backup path {R3, R2, R1, R4, R5, D} is used and traffic is sent up to R1. R1 load balances the traffic on its three ECMP paths {R1, R4, R5, D}, {R1, R6, R3, D} and {R1, R2, R3, D}. Unlike the multicast Reverse Path Forwarding (RPF) [48], in the unicast routing, the incoming interface is not checked for loops. When R1 load balances the FRR backup traffic between the ECMP paths, it creates the forwarding loop {R3, R2, R1, R6, R3, . . .} and the forwarding loop {R3, R2, R1, R2, R3, . . .} as shown in Fig. 8. Therefore, the each fast reroute mechanism must take special consider-

nodes, even though a device has multiple links, it may not have fast reroute capability, and this could cause more data loss. Additionally, in the following cases, the same prefix could be attached to two or more routers: • The subnet present on a link is advertised from both ends of the link. • Prefixes are propagated from one routing domain to another by multiple routers. • Prefixes are advertised from multiple routers to provide resilience in the event of the failure of one of the routers. The backup path computation must consider these cases when it computes the loop-free backup path. Backup path calculation must also consider topologies that use equal-cost multipaths (ECMP) in the backup path. ECMP is a routing technique for routing packets along multiple paths of equal cost. ECMP paths need to be given a special consideration. In the absence of an ECMP-specific procedure, ECMP paths in a network can create loops

R6

R1

R2

Routed path Computed backup path Actual backup path R3

D R3

R4

R5

Fig. 8. ECMP and partial loops.

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

ation for the backup path’s downstream ECMP paths to avoid forwarding loops.

1889

R5 R2

R1

3.2. FIB inconsistency micro-loops In a connectionless IP network, routers do not set up end-to-end paths before sending their traffic. Instead, each router makes its own forwarding decisions based on its FIB. Each router in the network removes a path when a failure is detected on the path, computes a new path, and installs the new path independently of the other routers in the network. Thus, temporarily the forwarding information base on these routers may not be consistent. This ‘‘FIB inconsistency’’ can cause forwarding loops during a reroute. FIB inconsistency-based micro-loops are acceptable in normal IP rerouting because there is no timing restriction for the normal reroute. Also the duration of the disruption caused by the micro-loop is less than that caused by the reconvergence. So the additional delay caused by micro-loops is ignored in the normal IP rerouting. However, micro-loops are not acceptable during fast reroute. Therefore, micro-loops related to FIB inconsistencies must be eliminated during fast reroute to minimize the data loss. During fast reroute, when a link-down event occurs, the local node detects the failure and enables the backup path. The routing protocol then propagates the link failure to the remote nodes. However, each node may receive the failure notification at a different time, depending upon its location. Also, each node may take a different amount of time to compute and install the path independently. Therefore, for some period of time, some of the nodes may have a new path installed and others may have the old path installed. This means that the linkdown event can lead to the formation of microloops. For example, consider Fig. 9. Before the failure of link (R1–R3), node R5’s next hop for destination D is R1. But when the link (R1–R3) fails, traffic from both R1 and R5 is forwarded on the backup next-hop R2. If routing at R1 converges and the new next hop is R5, and the routing at R5 converges and the next hop is R4, then we have a stable system. However, if R1 converges before R5 and the new next hop at R1 is R5, R5 continues to use the old path information with R1 as the next hop, R5 will continue to forward the traffic from R1 back to R1, thereby causing the ‘‘FIB inconsistency’’ micro-loop {R1, R5,

R3 R4 Micro loop Routed path

D

Fig. 9. Link down: before convergence.

R1’s new routed path R5 R2

R1

R3 R4 Micro loop D

Routed path

Fig. 10. Link-down micro-loop: R1 converged and R5 is not converged.

R1, R5, . . .}, as shown in Fig. 10, until routing at R5 and its downstream nodes converges. Similarly, FIB inconsistency micro-loops can also occur during a link-up event. In Fig. 11, when the link (R3–R4) comes back up, the different convergence times at different routers can create linkup FIB inconsistency micro-loops. When the link (R3–R4) comes up, the ‘‘link-up’’ event is propagated to all the nodes in the network. Every router in the network recomputes the path to its destinations and installs the forwarding entries. In Fig. 11, the initially routed path at R4 follows the path {R2, R1, R3, D}. If the link between R4 and R3 comes back up, the routed path at R1 changes back to {R2, R4, R3, D} because of the high cost of link (R1–R3). In Fig. 12, if R1 converges before R2, R1 sends the traffic to R2. Because routing at R2 has not converged, R2 still points back to R1. The traffic is

1890

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

R1

R2

100 R3

New link R4

D Fig. 11. Link-up: before convergence.

R1’s new routed path R1

R2

100 R3 R4 Micro loop D

Routed path

Fig. 12. Link-up micro-loop: R1 converged and R2 is not converged.

forwarded back to R1, thereby causing the link-up micro-loop {R1, R2, R1, R2, . . .}, as shown in the figure. 4. MPLS traffic engineering fast reroute MPLS Traffic Engineering (TE) refers to the process of selecting the paths for the traffic in order to balance the traffic load on the various links, routers, and switches in the network in order to meet some desire QoS. Traffic engineering is most important in networks where multiple paths are available. MPLS TE Fast Reroute is a mechanism for protecting TE LSPs from link and node failures by locally repairing the LSPs at the point of failure, allowing data to continue to flow on them while their headend routers attempt to establish new end-to-end LSPs to replace them. FRR locally repairs the pro-

tected LSPs by rerouting them over backup tunnels that bypass failed links or nodes. MPLS TE Fast Reroute [47] uses the RSVP [32,40] protocol to distribute labels and bandwidth information for the tunnel LSP. TE tunnel LSP is computed using Constraint-based Shortest Path First (CSPF) with the link state protocols such as OSPF [24,27,30,42] and ISIS [25,26,28,41]. Once the explicit path for the tunnel is computed it is signaled using RSVP. The TE tunnel LSP [39] is a unidirectional path established from source to destination with a tunnel interface. The TE tunnel is an interface, just like any other software interface. The difference lies in the fact that the tunnel interface can make the neighbor relation between any source and destination in the network. The tunnel neighbor does not need to be directly connected with a physical link. This allows other protocols, such as routing protocols and LDP, to run over this tunnel interface. Once the primary tunnel is established between the source and destination, routing is enabled over the tunnel interface by advertising the tunnel interface to routing. Routing uses this tunnel as a regular wire between the source and destination and installs the routes going over the tunnel in the routing table using auto route announce configuration. If LDP is enabled on the tunnel interface, then LDP labels are distributed for the network prefixes or forwarding equivalence classes (FECs) going over the tunnel. 4.1. Link protection Link protection enables all traffic carried by LSPs that traverse a failed link to be rerouted around the failure. The reroute decision is completely controlled locally by the router interfacing the failed link. The backup tunnel that bypasses only a single physical link of the LSP path provides link protection. This is referred to as a next-hop (NHOP) backup tunnel because it terminates at the LSP’s next-hop bypassing the point of failure. The start of the bypass tunnels is the point of local repair (PLR), which is the headend of the protected link. The bypass tunnel terminates downstream of the PLR on the node that represents the end of the bypassed link on the primary LSP. Each bypass tunnel provides 1:N local protection; that is, each bypass tunnel can protect one or more links depending on where it has been configured. The protected primary LSPs are stacked over the bypass tunnel to redirect their traffic around the

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

failure. The bypass tunnel naturally protects all LSPs that share the bypassed link (the LSP segment from the PLR to the downstream node) and that have requested protection. In this case, the physical interface is protected with a backup tunnel interface. This interface-level protection helps hide the LSPs traveling inside the tunnel. Fig. 13 illustrates an NHOP backup tunnel {R1, Rb, R2}, which protects the link (R1–R2) in the primary tunnel {R1, R2, R3, R4}. When link (R1–R2) is operational, both control plane and data plane traffic goes through the link (R1–R2). The NHOP backup tunnel is not used during normal operation. When the link (R1–R2) fails, the PLR R1 forwards all the primary tunnel traffic to the NHOP backup tunnel within 50 ms. There are two mechanisms that cause routers to switch LSPs onto their backup tunnels: • Interface down notification. • RSVP Hello neighbor down notification.

1891

When a router’s link or neighboring node fails, the router often detects this failure by an interface down notification. When a router notices that an interface has gone down, it switches LSPs going out of that interface onto their respective backup tunnels. RSVP Hellos can also be used to trigger FRR. If RSVP Hellos are configured on an interface, messages are periodically sent to the neighboring router. If no response is received, Hellos declare that the neighbor is down. This causes any LSPs going out that interface to be switched to their respective backup tunnels. During a fast reroute, the primary tunnel stays up even after the failure. The primary tunnel stays up during the failure. Therefore, Layer 3 protocols, such as IP routing and LDP, do not detect any change due to the failure. There is no down event for these Layer 3 protocols from the tunnel interface. However, the routing protocol, which is running on the physical link (R1–R2), detects the

Rb R1

R3

R2

R4

Prefix D

Tunnel from R1 to R4 LDP, Routing

PATH Tunnel int (R1-Rb-R2)

PATH

RESERVATION int (R2-Rb-R1)

RESERVATION

PATH PATH

RESERVATION

RESERVATION

NHOP Tunnel from R1 to R2

Fig. 13. NHOP tunnel after failure.

PATH

RESERVATION

1892

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

physical link down event and floods the failure to the entire network. The headend of the tunnel is notified of the link failure through the IGP or through RSVP; the headend then attempts to establish a new LSP that bypasses the failure. Therefore, when the tunnel headend router detects this failure, it will check whether this tunnel is part of FRR. If it is, then it will hold the link failure and will not bring down or tear down the tunnel but it will trigger a reoptimization event. During the reoptimization, it computes a new path for the primary tunnel, avoiding the link (R1–R2) and signals the new primary tunnel and follows the make-before-break procedure to avoid the traffic loss during the link-up event. Makebefore-break means that the old backup path will be deleted only after a new routed path is established and the router has started using the new path. Thereafter the traffic takes the new primary tunnel. 4.2. Node protection MPLS TE FRR can also provide node protection for LSPs. Backup tunnels that bypass next-hop nodes along LSP paths are called next–next-hop (NNHOP) backup tunnels because they terminate at the node following the next-hop node of the LSP paths. If a node along the path fails, node protection enables the node upstream of the failure to reroute the LSPs and their traffic around the failed node to the next–next-hop. The only difference between link and node protection is the backup path termination point. In the link protection case, the backup path is terminated at the next hop. In the node protection case, the backup path is terminated at the next–next-hop. All the other mechanisms are the same for both node and link protection. NNHOP backup tunnels also provide protection from link failures because they bypass the failed link as well as the node. The CSPF backup path computation finds a loop-free backup path. The backup paths terminate on the NHOP or NNHOP downstream node; therefore, the loop between the backup paths can be mostly eliminated if the tunnels are carefully provisioned. The TE fast reroute procedure during the link-down event and the TE make-before-break procedure during the link-up event eliminate the link-down and link-up related transient microloops. Therefore, TE FRR helps in safely achieving fast reroute in 50 ms or less.

There are two flavors of TE Fast Reroute [43]: • Facility backup. • One-to-one backup. In the facility backup model, for each protected network element a backup path is set up before failure. The number of backup tunnels required for link protection is equal to one for each direction of the link that is being protected. The number of backup tunnels required for the node protection is equal to N, where N is the number of next–next-hops for each LSR. Facility backup is also called the manyto-one backup because it uses one LSP to back up a bunch of LSPs. This means that it has less states with label stacking. However, it requires configuring the backup LSPs. In the one-to-one backup model, for each fast reroutable TE tunnel LSP using one-to-one backup method, a separate diversely routed TE LSP is set up at each hop that terminates at the tail-end LSR. The number of backup or detour LSPs required is a function of the number of fast reroutable TE LSPs and the network diameter. In this case, merging rules can help reduce the number of detour LSPs in the network. The advantages of this model are that it is more flexible, and it is simple to configure. Unfortunately, it has limited scalability in large networks. The benefits of the TE fast reroute include the following: • It provides fast recovery time equivalent to that of SONET-SDH/optical protection. • It provides bandwidth, propagation delay and jitter protection for a link, SRLG or node failure. However, TE fast reroute also has some drawbacks, which include: • It requires configuring and setting up several backup TE LSPs, which can be time-consuming in large networks. • As stated earlier, the one-to-one backup path fast reroute procedure has limited scalability in large networks. Currently, most of the MPLS devices already support TE FRR. In any FRR scheme, the most difficult part of the implementation is the forwarding plane. Thus, it is important to keep the forwarding plane simple and reusable. Therefore, the desirable thing is for the following IP fast reroute

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

procedures to reuse as much of the existing forwarding infrastructure as possible.

1893

– Shared Risk Link Group; – Multiple simultaneous unrelated failures. • Addressing symmetric and asymmetric network configurations.

5. IP fast reroute When a router with FRR detects a failure, it uses a set of repair paths in place of the failed component [4], and continues to use these repair paths until the completion of the routing transition. Only routers adjacent to the failed component are immediately aware of the nature of the failure. The remote devices detect this failure through normal failure propagation procedures. Once the routing transition has been completed, the router has no further use for the repair paths because all routers in the network have revised their forwarding path and the failed link has been eliminated from this new path. Recall that TE FRR uses techniques such as explicit source-routed end-to-end tunnel, backup tunnel to NHOP or NNHOP, protocol neighbor over the tunnel, and make-before-break to address both the FRR loops and micro-loops issues. Unlike TE, IP does not have explicit source-routed tunnels and protocol neighbors over the tunnel capabilities. The goal of IP FRR is not to create such capabilities in the IP network. Instead, it attempts to create an alternate FRR with the existing IP functionalities and characteristics. This assumption makes it very difficult to achieve FRR in an IP network. Since IP does not have the features that are available in the MPLS TE, the following issues need to be addressed if IP FRR is to be achieved: • Computing a loop-free backup path. • Detecting multipath FRR loops – Direct FRR loop detection; – Indirect FRR loop detection. • Preventing FRR looped path usage or breaking FRR loops. • Addressing IP-specific FRR cases – Equal Cost MultiPath; – Multihoming; – Non-Broadcast Multiple Access; – Inter-Area. • Preventing FIB inconsistency-related microloops – Link-down micro-loop; – Link-up micro-loop; – Multiple changes and micro-loops. • Addressing multiple related and unrelated failures

In IP fast reroute, many backup path computational procedures are defined and published through the IETF. Some of these procedures have some flaws in them or inadequately address the issues discussed in the previous sections. Therefore, these procedures are not discussed in this survey. The IETF IP FRR group and some service providers requested a non-RSVP TE-based IP FRR mechanism. Even though some of the proposals fulfill all the above FRR requirements specified in the previous section, they use RSVP-TE functionalities to achieve fast reroute. These procedures are also not considered in the IETF. In order to limit the scope of this paper, we only discuss the details of the procedures and techniques that are being considered in the IETF routing working group. 5.1. IP FRR backup path procedures and their FRR loop handling Non-transient FRR loops can be prevented if loop-free backup path computational procedures and FRR loop detection procedures are used. The backup path computational procedure must consider the FRR loop when computing the backup path, as discussed in the previous section. The ‘‘neighbors shortest path’’ (NSP) backup-path computational algorithm [20] was the first proposed scheme for computing an IP fast reroute backup path in IETF. Subsequently, many other backuppath computational procedures [10–15] were proposed in the IETF. The following IP FRR backup path computational procedures are under consideration in the IETF: • • • •

Loop-free alternate, U-turn alternate, IP fast-reroute using tunnels, Tunnel to notvia addresses.

Among these backup path computational procedures, the loop-free alternate (LFA) procedure is considered to be the simplest procedure to implement and the most computationally scalable. Therefore, this procedure is considered to be the baseline procedure for IP fast reroute backup path calculation. By baseline procedure we mean that when a node

1894

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

supports the IP FRR, this LFA procedure is used first to compute the backup path. In the absence of LFA backup path, nodes can use other advanced backup path computational procedures. The LFA procedure cannot achieve 100% protection coverage. Protection coverage means that when a link or node fails, there exists a loop-free backup path to protect that failure. Simulations show that the LFA procedure has close to 80% protection coverage [49]. This means that 80% of the failures can be addressed by the LFA backup path computational procedures. However, the coverage is highly topology dependent. To address the remaining 20% protection coverage, additional advanced backup-path computational procedures, such as U-turn alternate, IP fast reroute using tunnels, and notvia tunnel procedures are proposed. The following sections provide detailed description of these procedures. Among the advanced IP FRR procedures, the tunnel-based procedures provide greater control of the repair path. However, this is achieved at a price because IP tunnels are created with extra encapsulation on the IP packet. Different types of IP tunnels use different encapsulations, and these tunnels are usually provisioned or signaled. Therefore, tunnels need extra encapsulation processing and extra payload. The tunnel can be either an IP tunnel or LDP tunnel. Some of the traffic types need tunneling, even in the absence of IP FRR. For example, Layer 3 VPN traffic needs either an MPLS or L2TPv3 [23] tunnel. In this case, the additional tunnel can be the same MPLS or L2TPv3 type tunnel for IP FRR. Most tunnel-based IP FRR procedures do not require any changes in the forwarding data plane. If the LDP tunnels are used for IP FRR backup path tunnels, it is also possible to achieve LDP FRR with the same backup paths. 5.1.1. IP FRR using loop-free alternate A loop-free alternate backup path must not contain a node that the traffic has already visited. A loop-free alternate is a next-hop that is not a primary next-hop. Also, the shortest path to the destination from the alternate neighbor must not go back through the upstream router that forwarded the traffic or any upstream router that could forward it back. 5.1.1.1. Loop-free criterion. A neighbor N can provide a loop-free alternate (LFA) path for source node S and destination node D if [16]: Dopt ðN; DÞ < Dopt ðN; SÞ þ Dopt ðS; DÞ;

where Dopt(N, D) is the shortest path from router’s interior gateway protocol neighbor N to the destination D, Dopt(S, D) is the shortest distance from the calculating source router S to the destination D, and Dopt(N, S) is the shortest distance from the router’s IGP neighbor N to itself S. A sub-set of loop-free alternates are downstream paths, which must meet the more restrictive condition of downstream path criterion. 5.1.1.2. Downstream path criterion. A neighbor N can provide an LFA downstream path if Dopt ðN; DÞ < Dopt ðS; DÞ: A path satisfying this condition is also known as downstream path or feasible alternate. For link protection, the LFA algorithm avoids the pseudo-node (if any) on the primary next hop from the computing router to the next hop router. A pseudo-node is a broadcast link with zero-cost links connecting it to other nodes. Strictly they are zero cost from the pseudo-node, but non-zero to the pseudo-node. In Fig. 14, link (R4–D) is a high-cost link. Therefore, R2 has a routed path {R2, R4, R3, D}. In the figure, for the link (R1–R3) protection, the alternate path must avoid the point of local repair (PLR) node R1. As defined earlier, a PLR is a router that detects the local failure and installs the FRR computed backup path. The routed path from R2 to D avoids the PLR node R1. This satisfies the LFA condition. Therefore, R1 can use the LFA backup path {R2, R4, R3, D} for link (R1–R3) protection at R1. Fig. 14 shows this link-protecting backup path for the link (R1–R3). In this case, R4’s direct link (R4–D) is a higher cost link, so the traffic goes through the next hop R3 to get to D. For LFA node protection, the node simply avoids the primary next-hop neighbor. Fig. 15 shows the node-protecting backup path for node R3. An FRR loop can occur when a link-protecting backup path is used for node protection, as shown in Figs. 1 and 2. Therefore, a loop-free link-protecting alternate can create a FRR loop when a node failure occurs. LFA requires that the link-protecting alternate be downstream path Dopt(N, D) < Dopt (S, D). This generally avoids the potential for these loops. However, this may substantially reduce coverage. Alternatively, other node protection procedures, such as Non-Stop Routing (NSR) [44] or Graceful Restart (GR) [45] can be used for the

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

1895

R2

R1

R3

R4

Actual backup path Routed path Backup path

3 D Fig. 14. LFA link failure handling.

R2

R1

R3

Actual backup path Routed path Backup path

R4

D Fig. 15. LFA node failure handling.

node protection. A node operating in NSR mode recovers all its state information from a local database after the restart. Hence, neighbors do not know about the node restart. A node operating in GR mode recovers some or all the information from its neighbors after the restart. Therefore, neighbors are aware of the restart and they participate in the recovery. In these models, the forwarding plane has not failed, and hence it can forward normally. It is only the control plane that has failed, and the control plane is reconstructed without disturbing the forwarding plane. In both modes, it is possible to handle the node failures with little or no traffic loss, depending upon the hardware. Similarly, if there is an SRLG failure and the backup path does not protect against that SRLG failure, then forwarding FRR loops can occur. This can happen when the actual failure is more extensive than the computed backup-path protection. The LFA procedure normally requires one shortest path first (SPF) rooted at each neighbor of S, plus one reverse SPF rooted at S. Additional SPFs are required for handling SRLGs. An LFA backup path can only address the SRLG protection for the area within which it is computed. If an SRLG contains links from multiple areas, it is possible

for traffic to leave one area and then be forwarded across a path that includes the SRLG in the next area. The loop-free alternate has the following restrictions [46] and capability limitations: • Loop-free alternates must not be used in the OSPF [24,29] backbone area if there are any virtual links configured, unless for each area that a virtual link transits, there is a full mesh of virtual links between all area border routers (ABRs) in that area. • Loop-free alternates must not be used in an OSPF area that contains more than one alternate ABR. • Loop-free alternates must not be used for autonomous system (AS) external routes or autonomous system border routers (ASBR) routes in a non-backbone area of a network where there exists an ABR that is announced as an ASBR in multiple non-backbone areas and there exists another ABR that is in at least two of the same non-backbone areas. • Loop-free alternates must not be used in a nonbackbone area of a network for AS external routes, where an AS external prefix is advertised

1896

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

10

R1

Primary Next hop U-turn Alternate Next hop

R2

U-turn alternate 10 5

D 5

S

5

P Fig. 16. U-turn alternate.

with the same type of external metric by multiple ASBRs that are in different non-backbone areas, with a forwarding address of 0.0.0.0 or by one or more ASBRs with forwarding addresses in multiple non-backbone areas when an ABR exists simultaneously in two or more of those nonbackbone areas. • This mechanism does not work in ring topologies and only works for the networks such as triangles of nodes. This is because this only provides the repairs with a range of 1 or 2 hops. • This is a partial solution and only works for very limited topologies. However, with this topology dependency, a network can be carefully constructed to provide a good repair coverage. But the failure of a single link or node can convert the network into one with poor coverage for subsequent failures. In summary, when only the downstream paths are used as backup paths, FRR loops may be eliminated in the LFA. This further reduces the protection coverage severely for the LFA procedure. Thus, LFA is not a complete solution. 5.2. IP FRR using U-turn alternate The existence of suitable loop-free alternate backup path is topology dependent. Therefore, a second type of alternate path, known as a U-turn alternate backup path, is defined. As the name suggests, U-turn alternate allows packets to travel back on the same link two times. This procedure needs a special mechanism that allows this U-turn forwarding. U-turn alternate [6,38] is an alternate next-hop of source S that goes to a neighbor N whose primary next-hop is S and whose alternate neighbor does not go back through the router S. The topol-

ogy in Fig. 16 is an example where there is no loop-free alternate from S to D, but there is a U-turn alternate. In Fig. 16, there is no loop-free alternate for S to use to reach D. This is because the link costs are such that R1 uses S as its primary neighbor; therefore if S were to send the traffic to R1 when router P fails, it would loop back to S. If both S and R1 support the mechanisms defined in this U-turn alternate procedure, then S could use R1 as a U-turn alternate. Thus, S could send traffic to R1 and R1 would forward it to R2, and R2 would then forward it to D. Here, R2 is R1’s loop-free node-protecting alternate. When there are no loop-free alternates, all of S’s remaining non-primary neighbors send traffic for D back to S, either directly or indirectly. One of S’s non-primary neighbors might have a loop-free node-protecting alternate that could be utilized if the previous hop neighbor R1 can identify a packet as a U-turn packet. Previous hop neighbor R1 can indicate its ability to correctly identify incoming U-turn packets on each Layer 3 interface; such an interface is said to be U-turn recipient capable. R1 sends U-turn packets to R1’s loop-free node-protecting alternate only if the packet is received from a primary neighbor for that destination. There are two methods used in the U-turn alternate procedure for identifying a packet as a U-turn packet. These methods are • Implicit U-turn packet identification. • Explicitly marked U-turn packet identification. A router supporting the U-turn procedure must support one of these two methods for identifying U-turn packets. This capability also needs to be negotiated between the Layer 3 neighbors.

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

Implicit U-turn packet identification requires no modification to the packets sent into the U-turn alternate. Consider an interface or subinterface that is identified as being able to identify received U-turn packets. Assume that the router receives a packet for destination D from the primary neighbor to whom the router would normally forward the packet. Then the router locally identifies the packet as a U-turn packet and forwards it on the loop-free alternate. In essence, this breaks the single-hop forwarding loops. This procedure normally requires a special interface-specific reverse path forwarding verification, similar to the one used in the multicast routing. Explicitly marked U-turn packet identification requires that the router directing the packet to the U-turn alternate mark the U-turn packets explicitly as such. Explicitly marking U-turn traffic has the following disadvantages, which could be viewed as advantages for the implicit U-turn traffic: • A marking method must be selected. This marking needs to be below Layer 3 since there are no available bits for this purpose in the IPv4 header. • In some cases, implicit U-turn marking mitigates loops that form by detecting the loop and forwarding packets to a loop-free node-protecting alternate. This capability is lost when packets are explicitly marked. There are a number of ways to mark U-turn packets. For example, this could be done at Layer 2 by using different PPP types, Ethernet types, etc. The simplest mechanism that can apply, regardless of the Layer 2 technology, is to use a well-known MPLS label, referred to as a U-turn Label. The following procedure provides the U-turn alternate path selection algorithm: For each destination D, the following criteria apply: 1. Neighbor N has indicated that it can break Uturns for traffic coming in an interface. 2. Neighbor N has a loop-free node-protecting alternate to reach the destination D and it avoids the router S’s primary neighbor P. 3. If a loop-free node-protecting alternate is available, select it for use. 4. If not, pick among loop-free link-protecting alternates and U-turn alternates as desired. U-turn alternate procedure has the following requirements and limitations:

1897

• The U-turn alternate procedure considers only single hop U-turns. When the U-turn is performed, the receiving node must have an LFA path to the destination. Otherwise the neighbor cannot be used as a U-turn neighbor. Therefore, the protection coverage is still topologydependent. • U-turn alternates require a link capability subTLV (Type Length Value) signaling extension for both ISIS [7] and OSPF [8]. • The computational complexity of the U-turn alternate is on the order of alternate capable neighbors, O(alternate-capable neighbors). • Packets sent to the alternate next-hop require adding a single U-turn label. This needs to be removed at the next hop. • Forwarding look-up complexity is comparable to the mechanisms, such as Reverse Path Forwarding (RPF), Virtual Route Forwarding (VRF), Policy-based forwarding, used in the forwarding. However, this requires a change in existing forwarding paradigm, which makes it difficult to retrofit to existing hardware. • When an LFA-based backup path is available, this procedure always uses the LFA-based backup paths. Therefore, this procedure requires an LFA backup path computational procedure also. This means that most of the limitations that are applicable to an LFA procedure are also applicable to U-turn procedures. • This mechanism does not work in the ring topologies and only works for the networks such as triangles of nodes. This is because it only provides the repairs with a range of 1 or 2 hops. This procedure only provides limited protection coverage. The current coverage results are based on specific topologies. • This is a partial solution and only works for limited topologies. The main reason that people want fast-reroute is to give a service guarantee. The problem with partial repair coverage is that you can only make this guarantee to a subset of your customers, and it is quite difficult to predict which subset this is, and that may change with small changes to the topology. It is also quite hard to manipulate the topology to give good coverage to a specific customer. The loop-free alternate (LFA) procedure by itself does not provide adequate coverage for the traffic between all the source–destination pairs. As with loop-free alternates, the existence of suitable U-turn

1898

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

alternates is also topology dependent. However, simulations with various service provider networks have shown that the combined LFA and U-turn procedures extend the protection coverage above that seen with just LFA procedure. Since this procedure also does not address all the topologies, this is not sufficient solution for deploying the IP fast reroute. 5.3. IP fast-reroute using tunnels This procedure uses IP tunnels for achieving limited directed forwarding [3]. The directed forwarding refers to the ability at the tunnel end point (decapsulation point) to specify which next-hop should be used for forwarding the native packet, rather than the normal one indicated by a lookup of the destination address in the FIB. Therefore, directed forwarding permits a router to specify the tunnel egress where to forward traffic. This tunnel encapsulation could be an MPLS label encapsulation. When IP or MPLS tunnels are used as repair paths, the repair strategies described in this procedure operate on the basis that if a packet can somehow be sent to the other side of the failure or can be dropped at a point where it can reach the other side, it will subsequently proceed towards its destination exactly as if it had traversed the failed component, as shown in Fig. 17. Creating a repair path from S to E may require a packet to traverse an unnatural route. If a suitable natural path starts at a neighbor, then S can force the packet directly there. If this is not the case, then S may create one by using a tunnel to carry the packet to a point in the network where there is a real loop-free alternate. Note that the tunnel does not have to go from S to E; it can terminate at any router in the network, provided that S can be sure that the packet will proceed correctly to its destination from that router. Since it is not easy for a router

to immediately distinguish between a link failure and the failure of its neighbor, repair paths are calculated in anticipation of adjacent router failure. There are number of IP tunnel mechanisms that may be used to fulfill the requirements of this design. Suitable candidates include IP-in-IP [21], GRE [22] and L2TPv3 [23]. The selection of the specific tunneling mechanism and any necessary enhancements used to provide a repair path is outside the scope of this paper. Repair paths are pre-computed in anticipation of later failures so they can be promptly activated when a failure is detected. Three types of repair paths are used to achieve the repair: 1. Equal cost path-split; 2. Loop-free Alternate; 3. Tunnel. The operation of equal cost path-split and loopfree alternate is described in [16]. A tunneled repair path tunnels traffic to some staging point from which it will travel to its destination using normal forwarding without looping back. The repair path can be thought of as providing a virtual link, originating at a router adjacent to a failure, and diverting traffic around the failure. This is equivalent to providing a virtual loop-free alternate to supplement the physical loop-free alternates. In general, the properties that are required of tunnel endpoints are • The end point must be reachable from the tunnel source without traversing the failed link. • When released, tunneled packets will proceed toward their destination without being attracted back over the failed link or node. For source router S that is trying to determine tunneled repair paths around a neighboring router E, the set of potential tunnel end points includes

10 R1

Primary Next hop

R2

Alternate path 5 5 D

Tunnel S

5 E Fig. 17. Link repair with tunnels.

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

all the routers that can be reached from S using normal forwarding without traversing the failed link S– E. This is termed the ‘‘F-space’’ of S with respect to the failure of E. The set of possible release points can be determined by computing the set of routers that can reach the repair path target without traversing the failed link. This is termed the ‘‘G-space’’ of the target with respect to the failure. The G-space can be obtained by computing a reverse shortest path tree (rSPT) rooted at the repair path target, with the sub-tree that traverses the failed link (or node) excised. The rSPT uses the cost towards the root rather than from it and yields the best paths towards the root from other nodes in the network. The intersection of the target’s G-space with S’s F-space includes all the possible release points for any repair path not employing directed forwarding. IP fast-reroute using tunnels has the following requirements and limitations: • A tunnel-based backup procedure requires the following enhancements to routing protocols: 1. The ability to advertise IP FRR capability. 2. The ability to advertise tunnel endpoint capability. 3. The ability to advertise directed forwarding identifiers. • Multiple concurrent failures other than those that occur due to the failure of a single router are not addressed. • Shared risk group protection is not considered. However, this procedure can trivially be trimmed to exclude SRLG traversals. But the resultant connectivity may require a secondary repair analysis. • Because the mechanisms described here rely on complete topological information from the link state routing protocol, they will only work within a single link state flooding domain. • Reverse Path Forwarding (RPF) checks cannot be used in conjunction with IP FRR. This is because the use of tunnels may result in packets arriving over different interfaces than expected. • This procedure requires one reverse SPF (rSPF) path per neighbor and one rSPF path per neighbor’s neighbor. • Multiple encapsulations may be required: 1. A directed forwarding label; 2. An IP header to reach final waypoint; 3. A second IP header to get to the middle waypoint;

1899

4. More waypoints may be required for SRLG and node protection; 5. An extra tunnel for multihomed prefixes. • This procedure requires the ability to remove IP headers and perform two lookups. Some of this can be mitigated by the use of MPLS penultimate hop popping.

5.4. IP FRR using tunnel to notvia addresses In its simplest form, this repair mechanism works by assigning an additional address to each interface in the network. This additional address is called the notvia address. The semantics of a notvia address are that a packet addressed to a notvia address must be delivered to the router with that address, not via the neighboring router on the interface to which that address is assigned [2]. To repair a failure, the repairing router encapsulates the packet to a notvia address of the router interface on the far side of the failure. The routers on the repair path then know to which router they must deliver the packet, and which network component they must avoid. For example, assume that S has a packet for destination D that it would normally send via P and B, and that S suspects that P has failed. S encapsulates the packet to Bp, the interface of B that connects to P. The path from S to Bp is the shortest path from S to B, not going via P. If the network contains a path from S to B that does not use router P, then the packet will be successfully delivered to B. When the packet addressed to Bp arrives at B, B removes the encapsulation and forwards the repaired packet towards its final destination. This is illustrated in Fig. 18. Note that a packet may back track after the encapsulation is removed. However, because the de-encapsulating router is always closer to the packet’s destination than the encapsulating router, the packet will not loop. The notvia repair mechanism requires that all routers on the path from S to B, as shown in Fig. 18, have a route to Bp. They can calculate this by failing node P, running an SPF, and finding the shortest route to B. Unfortunately, a router has no simple way of knowing whether it is on the shortest path for any particular repair. It is therefore necessary for every router to calculate the path it would use during a router failure. In other words, again with reference to Fig. 18, some router X will consider each router in turn to be P, fail P, and then calculate its own route to each of the notvia P addresses advertised

1900

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

A

Bp is the address to use to get a packet to B notvia P Backup path

Ap Pa

S

P

D Pb Bp

Sp

B

Ps

Normal path

Pc

Cp

C C

Fig. 18. Tunnel to notvia address.

by the neighbors of P. That is, X calculates its route to Sp, Ap, Bp, and Cp, in each case, not via P. To calculate the repair paths a router has to calculate (n  1) SPFs, where n is the number of routers in the network. This is expensive to compute. However, the problem is amenable to a solution in which each router X proceeds as follows. X first calculates the base topology when all the routers are functional and determines its normal path to all notvia addresses. Then, it fails router P and performs an incremental SPF. Incremental SPF allows the system to recompute only the affected part of the tree. Recomputing only a portion of the tree rather than the entire tree results in faster convergence and saves CPU resources. Therefore, incremental SPF is more efficient than the full SPF algorithm, thereby allowing the network to converge faster on a new routing topology in reaction to a network event. This incremental calculation is terminated when all of the notvia P addresses are attached to the Shortest Path Tree (SPT). X then reverts to the base topology and repeats the process of failing each router P. Although a router has to calculate the repair paths for (n  1) failures, the computational effort is much less than (n  1) SPFs. Some of the limitations of the tunnel to notvia address scheme include the following: • SRLG failures and some topology-specific failures may require more than one notvia tunnel encapsulation, depending upon the SRLG failure and topology. In general a path notvia an SRLG

•

•

•

•

•

will be a single tunnel, but in some cases, once you have gotten around one SRLG member you will need to repair around another, so you get two sequential repairs. There are scalability concerns based on the number of notvia addresses and FECs required. For instance, as described in the draft [2], it is basically the number of unidirectional links in the topology. This ignores the extras for broadcast links. To fully and certainly provide SRLG protection, each router would need to advertise a notvia address for every unidirectional link into every neighbor of that router. This would result in (K * L) additional addresses, where K is the average number of neighbors and L is the number of unidirectional links in the topology. SRLGs can be fully addressed, but since SRLGs can be arbitrarily complex, so can the computational complexity required in addressing them. Also, a sufficiently complex SRLG failure could partition the network, in which case no repair is possible for any method. The idea of doing failure diagnosis using BFD may not be possible for SRLG failures. The solution may be a complex solution. This procedure requires advertising the notvia address and its association. For IS–IS it is pretty straightforward. For OSPF, by its very nature, it may be a little trickier. A more complex algorithm is required to cover all the cases and make all the computation feasible.

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

1901

Even though the notvia tunnel procedure has some deficiencies, at a high level it seems to be better than the other competing procedures.

is possible to have a solution that is common to all types of backup paths. FIB inconsistency micro-loops have the following properties:

5.5. IP FRR FIB inconsistency micro-loop handling

• Independent decisions can cause micro-loops. • Loops may occur between pairs of nodes or cycles of nodes.

Up until now we have considered various backup-path computational procedures and their FRR loop handling. In this section, we consider transient micro-loops related to distributed computing and forwarding database inconsistencies. Transient micro-loops are formed during the periods when a network is reconverging following a topology change, and are caused by inconsistent FIBs in the routers. In the network, FIB inconsistency can result from the following events [34]: 1. 2. 3. 4. 5.

Component failure, Component repair, Management withdrawal of a component, Management insertion of a component, Management change of link cost (either positive or negative), 6. External cost change, such as changing external gateway as a result of a BGP change, 7. An SRLG failure. In each case, a component may be a link or a router. As stated earlier, micro-loops may occur over a single link between a pair of routers that have each other as the next hop for a prefix. They may also form when a cycle of routers is configured such that each router has the next router in the cycle as the next hop for a given prefix [1]. Cyclic micro-loops always include at least one link with an asymmetric cost, and/or at least two symmetric cost link cost changes [1]. Both FRR loops and micro-loops have two undesirable side-effects: congestion and repair starvation. A looping packet consumes bandwidth until it escapes as a result of the resynchronization of the FIBs or until its time to live (TTL) expires. This transiently increases the traffic over a link by as much as 128 times [1], and may cause the link to be congested. As a result of this, ‘‘innocent’’ traffic using the link experiences increased latency and is liable to congestive packet loss. FIB inconsistency is usually independent of the backup path computation procedure. Therefore, it

The following solutions have been proposed for handling micro-loops [1]: • Incremental cost change; • Ordered SPF or Ordered FIB installation (OFIB); • Synchronized FIB installation; • Tunnel-based approach – Single tunnel per router; – Distributed tunnels; • Path-locking via safe neighbors (PLSN); • Loop-less Interface Specific forwarding (LISF). In the incremental cost change procedure [1], when a link fails, the cost of the link is generally changed from its assigned metric to ‘‘infinity’’. However, if the link cost is increased in suitable increments, and the network is allowed to stabilize before the next cost increment is advertised, then no micro-loops form. Once the link cost has been increased to a value greater than that of the lowest alternative cost around the link, the link may be disabled without causing a micro-loop. Even though the procedure is simple, incremental cost change cannot be used because of its excessively long network convergence time [18]. In the ordered SPF procedure [1], a strict ordering ensures that nodes closer to the root always process the failure after any nodes further away. Hence, micro-loops are prevented. When the failure has been announced, each router waits a multiple of some time delay value. The multiple is determined by the node’s position in the reverse spanning tree, and the delay value is chosen to guarantee that a node can complete its processing within this time. This imposes a delay that is bounded by the network diameter. The ordered SPF mechanism requires all nodes in the domain to operate according to these procedures, and the presence of non-cooperating nodes can give rise to loops for any traffic that traverses them. Without additional mechanisms, these loops could remain in place for a significant time. In

1902

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

ordered SPF or ordered FIB installation, for any link or node change, the scheme finds a safe ordering for FIB installation. Each router computes its ‘‘rank’’ with respect to the change. Delays for the installation time are proportional to its rank. Theoretically, ordered FIB installation has the advantage that it provides complete coverage for all microloops, including those that are due to asymmetric link cost [18]. This method also works with SRLGs; however, this may require different delays for different sets of prefixes. The disadvantage of ordered FIB installation is that the worst-case network convergence time depends on the diameter of the network and this can be quite long. More details can be found in [50], which proposes a mechanism to prevent transient loops during non-urgent topology changes by ordering the FIB updates on routers in networks that use link state routing protocols. In synchronized FIB installation approach [1], there would be two FIBs, a new and old FIB on each device. In this case, FIB inconsistency is removed with a synchronized action throughout the network, to switch from the old to the new FIB. The FIB swap time can be signaled or computed based on synchronized network time protocol (NTP). Even though this procedure is conceptually simple with minimal signaling, it has drawbacks that include strong implementation constraints, dependence on NTP, and the fact that traffic loss due to loops would only be minimized and not eliminated [18]. The single tunnel per router mechanism [1] works by creating an overlay network using tunnels whose paths are not affected by the topology change and carrying the traffic affected by the change in that new network. Distributed Tunnels [1] procedure is similar to the single tunnel per router approach, except that all micro-loop preventing routers calculate a set of link failure paths. The attractive properties of this method include its ability to cover all cases, and independence of transition time from the size of the network. On the other hand, this method requires modifications to the routing protocol to support ‘‘covert’’ topology change announcement. Also, using tunneling introduces different operational and security considerations, and the distributed version of the method involves relatively higher level of complexity. In the path locking via safe neighbor procedure [1], the safe neighbor is computed to be used as a transitional next-hop. A safe neighbor is a neighbor that is loop-free on the old topology and is on a

downstream path on new topology. If two neighboring routers do not have a safe neighbor, a micro-loop can form on that link and local microloops are also possible with non-supporting routers. The path locking via safe neighbor first installs a safe neighbor as primary next-hop. The scheme has a fixed convergence time, regardless of network size. Also, it works regardless of the topology changes that have occurred, which means that it provides SRLG protection. However, the coverage is dramatically reduced with SRLGs. Analysis of existing networks shows that with the scheme about 90% of the potential two-hop micro-loops are eliminated [17,18]. The disadvantages of path locking via safe neighbors are as follows: • It does not provide 100% micro-loop prevention coverage. • It requires per prefix installation of repair paths in the FIB. Therefore, it is only suitable for the basic LFA and U-turn procedures. • As with the basic IP FRR mechanism, increasing redundancy in network topology can be used to increase micro-loop coverage. However, without 100% coverage, even traffic that is micro-loop free may suffer congestion or loss due to the traffic across a link that is not micro-loop free. • It may reduce the protection coverage. When using PLSN in conjunction with U-turns or one of the non-100% coverage repair solutions, then approximately 20% of the traffic that would be correctly repaired will be disrupted by microloops, thus effectively negating the repairs in those cases. • Prevention of multihop micro-loops in networks with asymmetric link costs requires a stricter neighbor safety condition (downstream path before topology change), which reduces the coverage below the anticipated 90%. In theory, path locking can be augmented in a number of ways (requiring a different forwarding mechanism) to provide 100% coverage. However, in practice it is not clear how it can be done. The procedures to handle the advanced backup path calculation are not defined at this time. As stated earlier, the main reason that service providers want fast-reroute is to give a service guarantee and sell different services. The problem with partial coverage is that you can only make this guarantee to a subset of destinations, and it is quite difficult to predict which subset this is, and that may change

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

with small changes to the topology. It is also quite hard to manipulate the topology to give good coverage to a specific customer. This makes it very difficult to sell service guarantees to different customers. When all the routers in a network have the same view of the network, there would be no forwarding loop. It is only in the presence of discrepancies in the views of different routers that a packet might be caught in a loop. However, in such a case, under interface-specific forwarding, the packet would have arrived through an unusual interface of at least one of the routers involved in the loop. So, a forwarding loop can be avoided if the packet were to be discarded in such a scenario rather than forwarded to the usual next hop. This approach of avoiding forwarding loops by selectively discarding packets that arrive through unusual interfaces is referred to as Loop-less Interface Specific forwarding (LISF) [35]. The procedure is not suitable for most fast reroute mechanisms because usually in the fast reroute mechanism the remote receiving router does not know about the ingress interface during the fast reroute and discarding the packets defeats the purpose. Most of the above mechanisms require one or more convergence delay timers that must have a duration that is consistent throughout the routing domain. This time is the worst case time that any

1903

router will take to calculate backup path, and to make the necessary changes to the FIB. The timer synchronization mechanism must have the following properties [9]: • The convergence delay time must be consistent for all routers that are converging on the new topology. • The convergence delay time must be the highest delay required by any router in the new topology. • The mechanism must increase the delay when a new router is introduced to the network that requires a higher delay than is currently in use. • When the router that had the longest delay requirements is removed from the topology, the convergence delay timer value must, within some reasonable time, be reduced to the longest delay required by the remaining routers. • It must be possible for a router to change the convergence delay timer value that it requires. • A router that is in multiple routing areas or is running multiple routing protocols may signal a different loop-free convergence delay for each area and for each protocol. A router that dynamically determines its proposed timer value must do so in such a way that it does not cause the synchronized value to continually

Table 1 Micro-loop solution summary Procedure

Pros

Cons

Delay (in FIB compute/ install)

Incremental cost change

Only local router needs to support the procedure

Unacceptable delay (bounded, but can be very high)

Unacceptably high (bounded by maximum metric used)

Ordered SPFs

Control plane procedure

SRLGs require destination-based decision. Multivendor implementation differences may cause loop problems. Traffic loops minimized not eliminated

High (bounded by network diameter)

Synchronized FIB installation

This procedure looks simple

Implementation is not trivial. Synchronization variances may cause loops. NTP dependence and resolution issues. Traffic loops are minimized not eliminated

Minimal

Tunnel-based approach

Network size has little or no impact

This procedure requires routing protocol changes to support ‘‘covert’’ topology change announcement. Also, tunnel introduces different complexity, operational and security concerns

Minimal

Path Locking via safe neighbors (PLSN)

Deals with SRLGs and uncorrelated changes

Completeness depends on additional forwarding mechanisms. It is not clear if this procedure eliminates micro-loops in all IP FRR mechanisms

Comparatively small

Loop-less Interface specific forwarding (LISF)

Looks simple

This is not suitable for most fast reroute mechanisms. The reroute receiving router does not know about the ingress interface during fast reroute

Comparatively small

1904

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

fluctuate. This capability can be negotiated with OSPF type-10 opaque LSA or ISIS capability [33]. Table 1 is a summary of the micro-loop solution schemes discussed earlier. 6. LDP fast reroute using IP FRR LDP follows the IP path and establishes the label switched path. Therefore, LDP FRR backup path can follow the IP FRR backup path. Currently there is no detailed description for LDP FRR procedure. This paper provides a possible high-level LDP FRR procedure. The general thought is that, because the LDP traffic always follows the path specified by the IGP routing, the LDP FRR traffic can also follow the IP FRR backup path. To do so, it is necessary for LDP to have the appropriate labels available for the alternate path so that the appropriate LDP FRR rewrite can be installed in the forwarding plane before the failure occurs. For a normal routed path, the remote label from the route next-hop is used in the LDP rewrite as usual. The backup path remote label depends upon the backup procedure used.

6.1. LDP FRR using loop-free alternate backup paths In the LFA backup path procedure, IP FRR provides the backup next-hop. A label switched router (LSR) running LDP must distribute its labels for the FECs it can provide to all its neighbors regardless of whether or not they are upstream. Additionally, LDP must use liberal label retention mode to store labels that correspond to neighbors that are not currently the primary neighbor. Similarly, LDP should be in downstream unsolicited mode. As shown in Fig. 19, in downstream unsolicited (DU) label advertisement mode, label mapping advertisements for all routes may be received from all LDP peers. When using liberal label retention mode, every label mapping received from a peer LSR is retained, regardless of whether the LSR is the next hop for the advertised mapping or not. For example, in Fig. 19, R1 retains the remote labels L2 and Lb, R2 retains the remote labels L3 and L1, R3 retains the remote labels L2, L4 and Lb, and R4 retains the remote label L3. In this case, a primary path for the destination prefix D is {R1, R2, R3, R4}, and the LFA computes the

Rb High cost link Backup LSP

R2

R1

R3

R1

Normal LSP

Independent control









Prefix D





Liberal Label Retention At R1 FEC D: Local Label: L1 Remote Label: L2 Lb

At R2 FEC D: Local Label: L2 Remote Label: L3 L1

At R3 FEC D: Local Label: L3 Remote Label: L4 L2 Lb

Fig. 19. LDP FRR using IP FRR.

At R4 FEC D: Local Label: L4 Remote Label: L3

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

backup next-hop Rb. In Fig. 19, the primary path R1 uses label L2 from R2 and the backup path R1 uses label Lb from Rb. Before the failure, R1 uses the routed path rewrite hFEC D ! L2, int(R1–R2)i. After the failure, if R1 is the point of local repair, it uses the backup path rewrite hFEC D ! Lb, int(R1–Rb)i. 6.2. LDP FRR using U-turn alternate backup paths When using a U-turn alternate backup path, the corresponding LDP FRR procedure depends on which U-turn identification procedure is used. If implicit U-turn packet identification is used, then the same LFA procedure can be generally used. Additionally, an MPLS RPF verification procedure or any other implicit U-turn packet identification procedure must be used. If explicitly marked U-turn packet identification is used, then an additional special label needs to be distributed, configured or allocated. 6.3. LDP FRR using tunnels When using LDP tunnels for the IP FRR backup paths, LDP helps to some extent by providing the MPLS tunnel capability by nature. LDP tunnels are made by distributing the local label from the tunnel tail-end and using that label as a second-level label. LDP tunnels forward packets with their toplevel IGP labels from the tunnel headend to the tail-end penultimate hop. At the penultimate hop, the top-level IGP label is popped and the secondlevel label from the tunnel tail-end reaches the tailend [37]. The LDP tunnel tail-end node uses this label to switch the packets towards the destination in the routed path. Therefore, the packet uses the top-level IGP label to reach the tunnel endpoint and uses the second-level label to forward the packet from the tunnel tail-end to the destination. In the NHOP LDP tunnels, the tail-end local label is distributed normally in the current LDP procedure. However, for the NNHOP tunnel tail-end local label distribution, a new mechanism is needed. In this procedure, getting the NNHOP second-level label from the tunnel tail-end is not trivial. If the tunnel tail-end always terminates at NNHOP, then the NNHOP label distribution procedure specified in the draft [5] can be used. Even though there appears to be a procedure [5] for distributing these NNHOP local labels, there are some implementation concerns with

1905

NNHOP local label distribution for the tunnels. If the tunnel is not terminated at the NNHOP, then targeted LDP sessions are required to distribute a local label from the tail-end node. 6.4. LDP FRR using tunnel to notvia address Notvia addresses are IP addresses, and LDP will distribute labels for them in the usual way [2]. The notvia repair mechanism may therefore be used to provide fast reroute in an MPLS network by first pushing the label, which the repair endpoint uses to forward the packet, and then pushing the label corresponding to the notvia address needed to effect the repair. Referring once again to Fig. 18, if S has a packet destined for D that it must send via P and B, S first pushes B’s label for D. S then pushes the label that its next hop to Bp needs to reach Bp. Note that in an MPLS LDP network it is necessary for S to have the repair endpoint’s label for the destination. When S is effecting a link repair it already has this. In the case of a node repair, S either needs to set up a targeted LDP session with each of its neighbor’s neighbors, or it needs to use the next-next hop label distribution mechanism proposed in [5]. Where an extended SRLG is being repaired, S must determine which routers its traffic would traverse on egress from the SRLG, and then establish targeted LDP sessions with each of those routers. Current IP FRR backup procedures address only some of the backup path-related FRR loops. Microloops related to FIB inconsistencies for MPLS LDP FRR are not fully analyzed and not addressed at this time, as in the case of IP FRR.

7. Conclusion IP FRR and LDP FRR have come long way from a concept to a solution. Currently issues in both IP FRR and LDP FRR are becoming better understood. As the issues are becoming clearer, better solutions for the backup-path computations that address FRR loops are being proposed. FRR issues and solutions are very complicated. The proposed solutions are still being analyzed for transient micro-loops, FRR loops, memory, message, and CPU processing scalability. With a service offering in mind, a complete 100% protection coverage of repairs, FRR loops prevention and micro-loop prevention are goals worth striving for even if it requires some additional

1906

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907

complexity. This additional complexity must only be permitted in the control plane. The data plane complexity must not be increased. The number of nodes in the current largest service provider network is around 4000 nodes. The traffic in the service provider’s networks is doubling every year. The IP FRR procedures must scale to at least 10,000-node to 12,000-node networks. If there are 10 numbered interfaces at each node, then there will be 10 prefixes at each node. Therefore, these IP and LDP FRR procedures must scale to 120,000 prefixes in the network. If the service provider is using optical core, then the number of Layer 3 neighbors or Layer 3 protocol peers to a node could be on the order of fifties or hundreds. The IP FRR procedure must take scalability into consideration to make sure that the solution scales in any service provider’s network. Although FRR procedures assume that multiple unrelated failures are out of scope, these failures need to be analyzed to make sure that they do not create any severe problems in the network. Another important issue is operational complexity. TE FRR provides a complete view of the endto-end tunnel path for both primary and backup paths from the PLR. It is not clear that it is possible to view both primary and backup paths in various IP FRR procedures in different cases. For successful deployment of IP or LDP FRR, the above issues must be addressed. Disclaimer The information presented in this survey paper does not represent the views of Cisco Systems. The authors are solely responsible for its accuracy. References [1] S. Bryant, M. Shand, A Framework for Loop-free Convergence, Internet draft, draft-bryant-shand-lf-conv-frmwk01.txt, June 2005, work in progress. [2] S. Bryant, M. Shand, IP Fast Reroute Using Notvia Addresses, draft-bryant-shand-ipfrr-notvia-addresses-00.txt, March 2005, work in progress. [3] S. Bryant, M. Shand, C. Filsfils, S. Previdi, et al., IP Fast Reroute using tunnels, draft-bryant-ipfrr-tunnels-02.txt, work in progress. [4] M. Shand, IP Fast-reroute Framework, , October 2004, work in progress. [5] N. Shen, E. Chen, A. Tian, Discovering LDP Next-Nexthop Labels, , November 2005, work in progress.

[6] A. Atlas, U-turn Alternate for IP/LDP Fast-Reroute, , work in progress. [7] A. Atlas, R. Torvi, C. Martin, ISIS Extensions for Signaling Local Protection Capabilities, , October 2004, expired. [8] A. Atlas, R. Torvi, G. Choudhury, C. Martin, B. Imhoff, D. Fedyk, OSPFv2 Extensions for Link Capabilities and IP/ LDP Local Protection, draft-atlas-ospf-local-protect-cap01.txt, October 2004, expired. [9] S. Bryant, M. Shand, A. Atlas, Synchronization of Loop Free Timer Values, draft-atlas-bryant-shand-lf-timers-00.txt, July 2005, work in progress. [10] N. Venkata, IP Fast Reroute using Stitched Shortest Paths Algorithm, draft-venkata-ipfrr-sspa-00.txt, work in progress. [11] N. Venkata, IP Fast Reroute using Multiple Path Algorithm (MPA), draft-venkata-ipfrr-mpa-00.txt, June 2004, expired. [12] S. Shaoling et al., A Mini-FRR (Fast Rerouting) Mechanism for IP/MPLS Network, draft-defeng-mpls-mini-fast-rerouting-00.txt, February 2005, expired. [13] S. Naiming, IP Traffic Engineering with Route Switched Path (RSPs), draft-shen-ip-te-rsp-03.txt, October 2004, expired. [14] N. Shen, P. Pan, Nexthop Fast ReRoute for IP and MPLS, draft-shen-nhop-fastreroute-01.txt, July 2004, expired. [15] J. Albert et al., Fast Reroute using Alternative Shortest Paths, draft-tian-frr-alt-shortest-path-01.txt, July 2004, expired. [16] A. Atlas, Basic Specification for IP Fast-Reroute: Loop-free Alternates, draft-ietf-rtgwg-ipfrr-spec-base-04.txt, work in progress. [17] Z. Alex, Analysis and Minimization of Microloops in Linkstate Routing Protocols, draft-ietf-rtgwg-microloop-analysis-00.txt, July 2005, work in progress. [18] Z. Alex, Micro-loop prevention DT report, e-mail message to RTGWG mailing list, 22 Feb 2005, http://www.ietf.org/ mail-archive/web/rtgwg/current/msg00470. [19] D. Katz, D. Ward, Bidirectional Forwarding Detection, draft-ietf-bfd-base-00.txt, work in progress. [20] S. Kini, Y. Yang, Traffic restoration in link state protocols using neighbor’s shortest path, May 2002. [21] W. Simpson, RFC-1853, IP in IP Tunneling, October 1995. [22] S. Hanks et al., RFC-1701, Generic Routing Encapsulation (GRE), October 1994. [23] T. Lau, M. Townsley, I. Goyret, Layer two tunneling protocol-Version 3 (L2TPv3), RFC 3931, March 2005. [24] J. Moy, OSPF Version 2, STD 54, RFC 2328, April 1998. [25] T. Li, T. Przygienda, H. Smit, Domain-wide Prefix Distribution with Two-Level IS-IS, RFC 2966, October 2000. [26] R. Callon, Use of OSI IS–IS for routing in TCP/IP and dual environments, RFC 1195, December 1990. [27] K. Kompella, Y. Rekhter, OSPF Extensions in Support of Generalized Multiprotocol Label Switching, draft-ietfccamp-ospf-gmpls-extensions-12, October 2003, work in progress. [28] K. Kompella, Y. Rekhter, IS–IS Extensions in Support of Generalized MPLS, draft-ietf-isis-gmpls-extensions-19, October 2003, work in progress. [29] A. Zinin, A. Lindem, D. Yeung, Alternative Implementations of OSPF Area Border Routers, RFC 3509, April 2003.

A. Raj, O.C. Ibe / Computer Networks 51 (2007) 1882–1907 [30] R. Coltun, The OSPF Opaque LSA Option, RFC 2370, July 1998. [31] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, LDP Specification, RFC 3036, January 2001. [32] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, December 2001. [33] J.P. Vasseur et al., IS–IS extensions for advertising router information, draft-ietf-isis-caps-03.txt, work in progress. [34] S. Bryant, M. Shand, Applicability of Loop-free Convergence, draft-bryant-shand-lf-applicability-00.txt, June 2005, work in progress. [35] P. Francois, O. Bonaventure, Avoiding transient loops during IGP convergence IEEE INFOCOM 2005, March 2005, Miami, FL, USA. [36] RFC-791, Internet Protocol Specification, September 1981. [37] E. Rosen et al., RFC-3032, MPLS Label Stack Encoding, January 2001. [38] A. Atlas et al., IP MIB for IP Fast-Reroute, draftatlas-rtgwg-ipfrr-ip-mib-01, 20 February 2005, work in progress. [39] D. Awduche et al., Requirements for Traffic Engineering Over MPLS, RFC 2702, September 1999. [40] R. Braden et al. (Ed.), Resource ReSerVation protocol (RSVP) version 1 functional specification, RFC2205, September 1997. [41] H. Smit et al., Intermediate System to Intermediate System (IS–IS) Extensions for Traffic Engineering (TE), RFC 3784, June 2004. [42] D. Katz, Traffic Engineering (TE) Extensions to OSPF Version 2, RFC 3630, September 2003. [43] V. Jean-Philippe et al., Network Recovery: Protection and Restoration of Optical SONET-SDH, IP and MPLS, Morgan Kaufman Publishers, 2004. [44] K. Hadriel, Non Stop Routing Technology, http://www.avici.com/technology/whitepapers/reliability_series/nsrtechnology.pdf, 2002. [45] N. Matt, Is graceful restart the best way to ensure IP reliability? Yes, www.networkworld.com/columnists/2004/ 071904faceoffyes.html, July 2004. [46] A. Atlas, OSPF Applicability for LFAs, http://www1.ietf.org/mail-archiveweb/rtgwg/current/msg00517.html, May 2005. [47] V. Sharma et al., Framework for Multiprotocol Label Switching (MPLS)-based Recovery, http://www.ietf.org/rfc/ rfc3469.txt, February 2003. [48] IP multicast technology overview, http://www.cisco.com/ univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr.htm, 12 September 2002. [49] A. Atlas, U-Turn Alternates for IP/LDP Local Protection, www3.ietf.org/proceedings/05mar/slides/rtgwg-1/rtgwg-1.ppt, August 2004. [50] P. Francois, O. Bonaventure, M. Shand, S. Previdi, S. Bryant, Loop-free convergence using ordered FIB updates, draft-francois-ordered-fib-00.txt, July 2005.

1907

Alex E. Raj is a software architect at Cisco Systems with a primary focus on MPLS technologies. During the last 9 years at Cisco Systems and previously at Cabletron Systems, he has been involved in developing several software architectures as well as in the design and implementation of ATM, packet MPLS, cell-mode MPLS, Fast Reroute and High Availability systems. He also worked on the MPLS deployment phases in planning for many large-scale WAN service provider networks. He has filed several patents in the areas of LAN switching, MPLS, multicast routing and Fast Reroute, and has coauthored a few IETF drafts in the areas of High Availability and ATM MPLS networks. He received the ME degree in electronics and control from Birla Institute of Technology and Science, Pilani, India, and the MS and D.Eng degrees in Electrical Engineering from the University of Massachusetts, Lowell.

Oliver C. Ibe is a Professor of Electrical Engineering at the University of Massachusetts, Lowell. Prior to joining the university, he spent 16 years in the telecommunication industry in different capacities including being the Chief Technology Officer and cofounder of Sineria Networks and the director of network architecture at both Spike Broadband Systems and Adaptive Broadband Corporation. He was a PostDoctoral Research Fellow at the IBM Thomas J. Watson Research Center; an Assistant Professor of Computer Science at the Georgia Institute of Technology; and a Visiting Scientist at the Laboratory for Information and Decision Systems, Massachusetts Institute of Technology (MIT). He was the managing editor of Computer Networks and ISDN Systems, the predecessor of Computer Networks, from 1984 to 1987. He received the ScD and SM degrees in Electrical Engineering from MIT, the MBA from Northeastern University, and the B.Sc. degree in Electrical Engineering from the University of Nigeria. He is the author of four network technology books: Essentials of ATM Networks and Services (Addison Wesley, 1997), Remote Access Networks and Services (John Wiley, 1999), Converged Network Architectures: Delivering Voice and Data over IP, ATM and Frame Relay (John Wiley, 2002), and Fixed Broadband Wireless Access Networks and Services (John Wiley, 2002). His latest book is Fundamentals of Applied Probability and Random Processes (Elsevier Academic Press, 2005). He is a senior member of the IEEE. His current research interests are in the areas of mobile and wireless communication, MPLS network protection and restoration, stochastic systems modeling, and bioinformatics.