ENSURING RAPID RESTORATION IN JUNOS OS-BASED NETWORKS

Transcription

1 WHITE PAPER ENSURING RAPID RESTORATION IN JUNOS OS-BASED NETWORKS A Complete Convergence Solution Based on Local Repair, Loop Free Alternates, and Hierarchical Forwarding Copyright 0, Juniper Networks, Inc.

2 Table of Contents Executive Summary Introduction Network Convergence Overview Detecting the Failure Communicating the Failure Information Flooding Finding an Alternate Path Updating the Forwarding Plane The Task of Convergence Components of a Complete Convergence Solution Local Repair Loop Free Alternates Hierarchical FIB Indirect Next Hops Composite Next Hops Selector Next Hops BGP Add-Path Convergence Scenarios and Configurations Configuration : Core Node/Link Failure in an IP Network Configuration Example Configuration : Core Node in an MPLS/VPN Network Configuration Example Conclusion References End-to-End Service Restoration White papers About Juniper Networks Copyright 0, Juniper Networks, Inc.

3 Table of Figures Figure : The many factors that impact convergence Figure : Local repair enables traffic to be rerouted before global convergence occurs Figure : Traditional implementations require individual next-hop updates, slowing convergence Figure : With indirect next hops, only one update needs to be made Figure : Traditionally, next hops are assigned by VPN label, requiring multiple route updates in the event of failure Figure 6: Composite next hops split inner and outer label, enabling efficient use of indirect next hops for VPNs Figure 7: With selector next hops, selectors switch over from first label to second label quickly Figure 8: Hierarchical FIB (indirect, composite, and selector next hops) reduces the time it takes to update forwarding tables Figure 9: BGP restoration behavior without BGP Add-Path Figure : BGP restoration behavior with BGP Add-Path Figure : Sample network, core link failure Figure : Global convergence could take many seconds Figure : With LFA and hierarchical forwarding, a local repair () can be made, and global convergence () occurs more rapidly. Indirect next hop optimizes the convergence of a large number of route updates Figure : Default behavior in a core MPLS/VPN network Figure : LFA and hierarchical forwarding, enable a local repair (), and composite next hop optimizes the convergence of a large number of route updates Copyright 0, Juniper Networks, Inc.

4 Executive Summary As network reliability and uptime become increasingly important, service providers are focused on improving the speed of convergence in IP/MPLS networks. While many advances have been made, achieving rapid convergence only becomes more challenging as IP networks grow larger and more complex. This paper examines the many factors that contribute to convergence in large-scale networks, and the mechanisms available within Juniper Networks Junos operating system that are capable of speeding up the convergence process. This will be followed by examples that compare the convergence times using the new Junos OS features with those possible using other techniques. This paper is essential reading for network planners seeking to improve the availability of their IP/MPLS networks through more rapid convergence. Readers will gain an understanding of the processes that influence convergence and what can be done to optimize each process. They will also learn how Juniper Networks is leading the way toward sub- 0 ms convergence times. This paper assumes a basic understanding of IP protocols and MPLS/LDP. Introduction In the ongoing pursuit of improved network reliability and uptime, one of the most important considerations is reducing convergence time. Failures are bound to occur in even the most well designed networks, and the ability to recover from these failures rapidly and with minimal traffic loss is key to meeting the demands of today s services and subscribers. Network convergence is a complex process that increases in complexity as the network increases in size. In large-scale networks, end-to-end convergence often involves the restoration of a number of independent network protocols. A link failure in the core network, for example, will affect the protocols that run directly over it. But looking through a wider lens, those protocols might in turn affect other protocols that build upon them. A single link failure in the core can have adverse effects on many customers and end users who run services over a network. Therefore, to improve network convergence, a solution must consider all of the protocols and factors that can impact convergence not just a single protocol. Achieving the ultimate goal of end-to-end restoration in under 0 milliseconds will only be possible with a holistic approach that considers all aspects of the convergence process. To put this in perspective, it is first helpful to review exactly what comprises the convergence process. Network Convergence Overview The time it takes for a network to converge following a link or node failure can vary dramatically based on a number of factors, including network size, the protocols used, and network design. However, while each particular convergence event is different, the process of convergence is essentially consistent. There are four basic stages that are involved in a network convergence event, which typically occur in the following order:. Detecting the failure. Flooding of information. Finding the alternate path. Updating forwarding plane While each of these processes individually may seem to occur rapidly, it is important to review the effect of each on the convergence process to gain a better understanding of where the most improvements are possible. In the following sections, we will briefly review the effects each stage has on network convergence. Detecting the Failure There are different types of network events that can cause failures link failure, line card failure, router failure, administrative link removal, cost change, etc. Regardless of the cause, the first step in any convergence event is detecting the failure. There are many available failure detection mechanisms, some working at the link-layer level, some embedded in protocols, and others working independent of protocols. The best results are achieved by using a combination of multiple mechanisms. Using link-layer detection mechanisms such as loss of light (LOL) and bit error rate (BER) alarms is by far the fastest. The interrupt-driven nature of interface events in Junos OS software keeps detection time as low as a few milliseconds. However, not all failures can be detected at the link-layer level. Copyright 0, Juniper Networks, Inc.

5 Indirect link failures or unidirectional link issues that rely on interior gateway protocol (IGP) timers for failure detection can lead to significant network downtime. Although the timers are often tunable, setting them too low might cause side effects in other scenarios. For example, when graceful restart is enabled, the hold time ( times of hello timer) should be higher than the Routing Engine (RE) switchover time. Bidirectional Forwarding Detection (BFD) protocol is another common way to detect failures, and can be used to complement and enhance the previously described mechanisms. BFD is not attached to any specific media or protocol, so one of its advantages is the ability to work with a variety of network environments and topologies. The failure detection timers within BFD have shorter time limits than that of protocols such as OSPF, IS-IS, or BGP, providing faster detection. There are also other means to detect failures, including Operation, Administration, and Maintenance (OAM) connectivity check protocols such as Ethernet OAM, Point-to-Point Protocol (PPP) keepalives, ATM OAM alarm indication signal (AIS), etc. Which protocols an operator chooses to use will depend on the unique network design and requirements. When the failures are detected faster, networks can react to them sooner, and alternate paths can be selected more quickly, speeding up network convergence. Failure detection is probably the aspect of convergence that is best understood, and most networks are designed to detect failures within several milliseconds. Communicating the Failure Information Flooding Once a failure has been detected, the failure and the resulting topology change need to be communicated to other devices in the network. After a router detects link failures or topology changes, it needs to send important topology change updates to its neighbors, and it needs to react to the topology change updates that it receives from its neighbors in turn. These updates are sent through the network at the speed of light, so the time taken for devices in the network to receive updates depends on the network diameter and how close a particular device is located to the failure. Finding an Alternate Path After being notified of a failure event, devices on the network need to process the information and calculate an alternate path. For link state protocols such as IS-IS and OSPF, this means running a new shortest-path-first (SPF) calculation. For BGP, it means a new path selection calculation based on criteria such as weights, local preferences, AS_Path, etc. A common misconception here is that the SPF calculations add a significant amount of time to the convergence process. However, due to the advances in processor technology, this is no longer the case. With Juniper Networks latest Routing Engines, a full SPF calculation even with thousands of routers can be performed in a few milliseconds. Updating the Forwarding Plane Once an alternate path is found, the router needs to update its forwarding table commonly known as the forwarding information base (FIB) with the new next hop for all affected prefixes. Traditionally, the time this process consumes has directly correlated to the number of routes in the network and is bound to memory access time. In other words, the more prefixes that need updating, the longer the process will take. A core link failure might result in IGP reconvergence, which can affect tens or hundreds of thousands of BGP or routes. FIB update is a vendorspecific implementation and can be optimized to cut a significant amount of convergence time. For example, updating 00,000 routes can be optimized and reduced by tenfold. The graphic in Figure illustrates each of these processes, and shows the approximate times that each adds to the process of convergence. Failure detected (< ms) ms Topology change communicated Routers perform new SPF calculations Speed of light ms Routers update FIB, begin re-routing traffic s of seconds Figure : The many factors that impact convergence. For more information on Juniper s forwarding plane technology, please refer to Juniper Networks T Series Core Routers Architecture Overview. Copyright 0, Juniper Networks, Inc.

6 The Task of Convergence With an understanding of the various steps that can impact convergence, we can begin to focus on the areas that have the potential for the greatest returns in terms of speeding the process of convergence. The detection process is perhaps the most widely understood, and the various techniques described above can be effectively used to optimize the speed of detection in most networks. This paper, therefore, will not cover detection mechanisms in detail beyond the information provided above. In some of the other areas, there has already been much progress made in recent years towards improving convergence times with more efficient operating systems and more powerful routing hardware. Junos OS, for example, offers low protocol timers optimized for modern networks, and new routing platforms are capable of processing and calculating the new SPF much more quickly and efficiently. However, some aspects of end-to-end convergence are still bound by basic physics specifically, the speed of light. For link-state protocols such as IS-IS and OSPF, once the failure event is detected at the immediate neighbor node, it needs to be processed and propagated throughout the rest of the network. Propagation speed in fibers happens at the speed of light (about km/ms), so how quickly a node gets updated is directly related to its distance from the failure point. Though the speed of light is fast, it is simply not fast enough for some of the largest networks for example, a network with a diameter larger than,00 km (,00 miles) would be incapable of delivering convergence in under 0 milliseconds simply because of the propagation delay. Therefore, to achieve true <0 ms end-to-end convergence times an objective that Juniper Networks is actively striving towards a solution must find a way to sidestep these limits of physics. The answer is a combination of local repair and hierarchical forwarding tables as outlined below. When combined with the latest detection mechanisms and routing hardware and software, these lay the foundation for true, end-to-end restoration in under 0 ms. Components of a Complete Convergence Solution Achieving sub 0 ms convergence is relatively easy in small networks, but, as described above, many of the individual components of convergence begin to slow rapidly as the network scales. Specifically, geographically large networks face challenges from propagation delays, and networks with a large number of nodes (regardless of geographic characteristics) are slowed by the number of route updates that must be processed. Thus, the goal of rapid convergence can only be attained with a solution that enables fast convergence independent of network size. Some in the industry promote what is called prefix independent convergence, the ability to deliver fast convergence regardless of the number of BGP prefixes in the network. While this is certainly an important part of a complete convergence solution, it is only one aspect. Fast convergence also relies on speeding both IGP and BGP convergence, must work for all services, and must accelerate all of the processes outlined above. Juniper s complete convergence solution ensures both fast IGP and BGP convergence, and also extends this with techniques such as local repair and loop free alternate routes. Local Repair One way to speed convergence is to create a solution that can implement a repair that can be implemented before all the routers in the network have been notified and had their forwarding tables updated. This is known as a local repair (in contrast to the global repair scenario described above). Local repairs can be implemented immediately upon failure detection, while in the meantime, the routing software will continue to recalculate the entire network topology. Local repair and global repair are thus complementary local repair enables traffic to continue to be routed using a backup path until global repair is able to calculate a new optimal route. Eventually the entire network converges with the recalculated topology, but because the local repair is implemented immediately, disruption to traffic can be kept well under 0 ms. For a local repair to be possible, the following needs to occur: The forwarding table needs to be pre-populated with a viable backup path. There must be a shortcut path for forwarding table updates for backup path switching. 6 Copyright 0, Juniper Networks, Inc.

7 Reconsidering Figure, this means that after the link driver reports the link down message, the ukernel starts to activate the backup paths into the data plane FIB right away. Figure illustrates how local repair can reroute traffic in under 0 ms, enabling traffic to continue to flow while the rest of the global repair procedures play out. Local repair can be achieved in under 0 ms Failure detected (< ms) ms Local repair: traffic automatically rerouted to precalculated backup 0 ms Topology change communicated Routers perform new SPF calculations Routers update FIB, begin re-routing traffic based on global repair (if different) Speed of light ms s of seconds Global repair can continue while traffic rerouted to local repair route Figure : Local repair enables traffic to be rerouted before global convergence occurs. Local repair has long been available in networks that use RSVP-TE in the form of MPLS fast reroute. Since networks often use a mix of RSVP and LDP, a complete convergence solution must be capable of performing local repairs in an LDP-based network as well. Since LDP relies on IGP (OSPF or IS-IS) for the underlying routing and topology information, the backup route for a local repair in LDP networks must be added to the IGP. With Loop-Free Alternates (LFA), Juniper has pioneered an approach that brings MPLS fast reroute-like capabilities to OSPF and IS-IS-based IP/MPLS networks. By adding a preinstalled backup next hop into the forwarding plane (similar to fast reroute), LFA provides both link and node protection, and consistent sub-0 ms IGP convergence times that are independent of the size of the network, without adding operational burden. Loop Free Alternates A more detailed explanation of LFA is available in the paper Understanding and Deploying Loop Free Alternates; here we will only provide a brief overview. Essentially LFA works by using the IGP to pre-calculate an alternate less-than-equal path, and ensure that that path does not create any forwarding loops. This path is then configured in the forwarding table of LFA-enabled routers, allowing them to rapidly switch to the loop free path in the event of a failure. LFA can be configured on a per-router basis and they require other routers in the network to be aware of, or supporting, the protocol. LFA can be deployed in strategic locations to protect traffic and ensure sub-0 ms restoration in LDPbased networks. Hierarchical FIB Techniques such as LFA are very effective at improving IGP convergence time. But fast IGP convergence is only part of the equation. In today s networks, other protocols and services build upon IGP and therefore are affected by failures that cause IGP reconvergence. For example, a router obtains the direct next hop (or outgoing interface) of its BGP prefixes based on IGP reachability. BGP prefixes along with their direct next hop information are installed in the forwarding table in the Packet Forwarding Engine (PFE), and therefore need to be updated if the direct next hop is affected by the IGP convergence. In traditional implementations, there is a linear correlation between the number of routes affected by a given link and the restoration time. This is because each route points to its corresponding direct next hop or outgoing interface, meaning in the event of a failure, all of these routes must be updated with the new next hop. Copyright 0, Juniper Networks, Inc. 7

8 Route P Direct next hop Direct next hop Route P Direct next hop Direct next hop Route P Direct next hop Direct next hop Figure : Traditional implementations require individual next-hop updates, slowing convergence. In the network with a large number of BGP routes, this can take a long time. Therefore, a more scalable solution is needed so that the convergence time does not increase linearly as the network grows. The solution is a hierarchical FIB that can take advantage of indirect next hops. Hierarchical FIB reduces the convergence time associated with updating large numbers of BGP routes by introducing an indirect next hop. Indirect Next Hops Indirect next hops are a logical device that enables multiple routes in the routing table to point to a single next hop. By configuring an indirect next hop in the FIB, all routes for a given interface point to this indirect next hop, which then points to the actual next hop. The benefit of this approach is that in the event of a failure, the routes themselves do not need to be updated individually (since they still point to the indirect next hop); instead, only the pointer between the indirect next hop and the next hop needs to be changed, thus greatly reducing the update time. Route P Route P Indirect next hop Direct next hop Route P Direct next hop Figure : With indirect next hops, only one update needs to be made. Composite Next Hops The support of indirect next hops in the forwarding plane is capable of reducing the time to convergence from tens of seconds to several milliseconds. However, indirect next hops only works for BGP prefixes labels can present additional challenges. In Junos OS, routes from a VPN routing and forwarding (VRF) table from the same provider edge (PE) router typically share the same VPN label, so routes from the same VRF table and from the same PE router can point to a single indirect next hop. However, routers from other vendors allocate one VPN label per route, which can lead to multiple indirect next hops defeating the purpose of using indirect next hops. Since most networks are multivendor environments, Juniper has developed the concept of composite next hops to provide greater scaling and faster convergence for layer VPNs. In an IP/MPLS network, PE routers accept BGP updates with VPN labels. The information is installed in the forwarding table, along with a transport label (outer label) to reach the remote PE router beyond which the destinations can be reached. 8 Copyright 0, Juniper Networks, Inc.

9 Traditionally, each prefix (VPN label + outer label) points to a pair even though they often have the same outer label. Therefore, when there is a network convergence event that changes the outer label, every prefix needs to be updated (Figure ). As with indirect next hops in an IP network, there is a linear correlation between the number of routes affected by a given link and restoration time. Route P VPN Label + Outer Label VPN Label + Outer Label Route P VPN Label + Outer Label VPN Label + Outer Label Route P VPN Label + Outer Label VPN Label + Outer Label Figure : Traditionally, next hops are assigned by VPN label, requiring multiple route updates in the event of failure. Composite next hops work by splitting the inner and outer label. With a composite next hop, Juniper routers accept a large number of Layer VPN BGP updates with unique inner VPN labels. When the prefixes are installed in the forwarding table, they point to an indirect next hop, which points to an outer label. The router assigns indirect next hops according to the outer labels (Figure 6). The benefit of this approach is that in the event of a failure, only the pointer between the indirect next hop and the outer label needs to be changed, thus greatly reducing the update time. Route P VPN Label Route P VPN Label Indirect next hop Outer label Route P VPN Label Outer label Figure 6: Composite next hops split inner and outer label, enabling efficient use of indirect next hops for VPNs. Copyright 0, Juniper Networks, Inc. 9

10 Selector Next Hops Composite next hops reduce convergence time significantly when the VPN prefixes have the same exit points. However, when they have different exit points, they can t be grouped together by means of indirect next hops, and this is where selector next hops come into the picture. With selector next hops (Figure 7), each prefix points to a selector, which points to a pair of labels. There is a separate indicator that informs the selector which label to use for forwarding whether it be the first label or the second label. Using selector next hops brings a significant improvement in convergence time when there are large numbers of labelswitched paths (LSPs) in the core network. Route P Selector Label u or v Route P Selector Label w or x Route P Selector Label y or z Use st label Figure 7: With selector next hops, selectors switch over from first label to second label quickly. The use of indirect next hops, composite next hops, and selector next hops accelerates the process of updating the forwarding plane, and this speeds the global repair process. Taking another look at the convergence process illustrated earlier, Figure 8 shows how creating a hierarchical FIB using indirect and composite next hops can bring this time down to tens of milliseconds. Failure detected (< ms) ms Local repair: traffic automatically rerouted to precalculated backup Topology change communicated Routers perform new SPF calculations Hierarchical FIB minimizes convergence time for updating large number of routes Routers update FIB, begin re-routing traffic based on global repair (if different) 0 ms Speed of light ms s of seconds ms Figure 8: Hierarchical FIB (indirect, composite, and selector next hops) reduces the time it takes to update forwarding tables. Copyright 0, Juniper Networks, Inc.

11 BGP Add-Path Hierarchical FIB dramatically improves convergence speed in the event of a core link or node failure. However, when a remote (egress) PE router on the primary forwarding path becomes unavailable, the ingress PE router won t be able to benefit from hierarchical FIB. Therefore, as we strive toward sub-0 ms convergence, there needs to be a new mechanism to improve the failover time for remote PE route failures as well. This is achieved through a technique called BGP Add-Path, which modifies the way route reflectors advertise paths. Most BGP networks today use route reflectors to reduce the number of peering sessions between BGP speakers, and to provide a cleaner, hierarchical topology. By default, route reflectors reflect one best path to its peers for a given address prefix. When the best path becomes unavailable, the route reflector withdraws that path from its peers, recalculates a new path, and advertises the new best path to all peers (Figure 9). This requires both BGP and IGP convergence and can therefore be a lengthy process. RR Both PE and PE advertise prefixes to RR RR picks the best part (PE) and advertises to its peers PE failure RR detects the failure, withdraw paths through PE, and advertise new best path (PE) PE reroutes traffic VPNs PE PE P P IP/MPLS core PE PE VPNs Figure 9: BGP restoration behavior without BGP Add-Path. BGP Add-Path reduces the time taken in this process by allowing the route reflector to advertise multiple paths for the same address prefix (Figure ) without the new paths implicitly replacing existing paths. With BGP Add-Path, ingress PE routers can switch over to the alternate paths quickly upon the detection of remote PE router failure. Since failure detection is based on IGP time rather than BGP time, this occurs much more quickly. In addition to providing rapid convergence, BGP Add-Path can enable load balancing between the multiple paths advertised by the route reflector. RR Both PE and PE advertise prefixes to RR PE RR advertises both paths to PE and PE picked the best path (PE) PE failure VPNs P PE VPNs PE detects the failure of PE and switches to alternate path (PE) PE P IP/MPLS core PE Figure : BGP restoration behavior with BGP Add-Path. Copyright 0, Juniper Networks, Inc.

12 Convergence Scenarios and Configurations When applied together, the combination of detection mechanisms, local repair, loop free alternates, and hierarchical forwarding can provide dramatic increases in convergence time. Juniper s routers are the only platforms in the industry that combine all of these features driving rapid convergence. In this section, we will outline several scenarios and provide sample configurations that illustrate how to take advantage of the techniques outlined above. Configuration : Core Node/Link Failure in an IP Network In the sample network below (Figure ), PE receives BGP route prefixes from PE. Through an IGP calculation (OSPF or IS-IS), PE determines that P is the next hop for the received BGP routes, and by default PE installs BGP routes each with a pointer to P. RR PE PE P EBGP peer Peer EBGP peer PE P PE Figure : Sample network, core link failure. If a failure were to make the link between P and PE no longer available, the default behavior would be to flood information back to PE, which would then run an SPF calculation and determine that PE is now available through P, instead of P. It would then update next-hop information for all prefixes in the affected FIB. Traffic then follows arrow in Figure. As described above, this can take a significant amount of time in a large network. Route Direct next hop RR 0...x/ P 0...x/ P 0...x/ P.... P P P PE P PE EBGP peer Peer PE PE Figure : Global convergence could take many seconds. P EBGP peer Copyright 0, Juniper Networks, Inc.

13 When the network is capable of performing a local repair using LFA, traffic will continue to be forwarded via the pre-computed, preinstalled backup route (arrow in Figure ) while IGP recalculates the shortest path. When the alternate path is available (arrow ) on PE, it updates the next-hop information for the BGP routes affected. The difference is that indirect next hop enables all affected prefixes to be updated at once reducing convergence time to 0 ms for 00,000 routes from tens of seconds. Route Indirect next hop Next hop RR 0...x/ 0...x/ 0...x/ X P P.. PE PE P Peer PE P PE Configuration Example Figure : With LFA and hierarchical forwarding, a local repair () can be made, and global convergence () occurs more rapidly. Indirect next hop optimizes the convergence of a large number of route updates. Loop Free Alternates and Local Repair policy-options { policy-statement lb { then { load-balance per-packet; routing-options { forwarding-table { export lb; protocols { isis { interface so-/0/0 { nodelink-protection; interface so-/0/0 { link-protection; interface so-7/0/0 { no-eligible-backup; Indirect Next-Hop Configuration routing-options { forwarding-table indirect-next-hop Copyright 0, Juniper Networks, Inc.

14 Configuration : Core Node in an MPLS/VPN Network In the sample MPLS network below (Figure ), PE receives prefixes through multiprotocol BGP. Through an IGP calculation (OSPF or IS-IS) and LDP label exchange, PE populates its forwarding table with information necessary to reach remote destinations. When making a forwarding decision, PE pushes two labels to the packets VPN label (inner label) and a MPLS core label (outer label). If a failure were to make the link between P and PE no longer available, the default behavior would be for IGP to flood information back to PE as is done in an IP network, and for LDP to re-exchange label information. It then updates next-hop and label information for all prefixes in the affected FIB. Traffic then follows arrow in Figure. As described above, this can take a significant amount of time in a large network. Route Indirect next hop Label RR 0...x/ P P x/ P P x/ P P PE PE VPNs P VPNs PE P IP/MPLS core PE Figure : Default behavior in a core MPLS/VPN network. Similar to scenario, with LFA and local repair, traffic will continue to be forwarded via the pre-computed, preinstalled backup route (arrow in Figure ), while IGP recalculates the shortest path and LDP exchanges new label information. When the alternate path is available (arrow ) on PE, it updates the next-hop information for the BGP routes affected (Figure ). The difference here is that composite next hop separates inner and outer labels, and all affected prefixes that share a common BGP next hop can be updated at once. Route VPN label Label RR 0...x/ 0...x/ 0...x/ PE PE VPNs P VPNs PE P IP/MPLS core PE Figure : LFA and hierarchical forwarding, enable a local repair (), and composite next hop optimizes the convergence of a large number of route updates. Copyright 0, Juniper Networks, Inc.

15 Configuration Example Loop Free Alternates and Local Repair policy-options { policy-statement lb { then { load-balance per-packet; routing-options { forwarding-table { export lb; protocols { isis { interface so-/0/0 { nodelink-protection; interface so-/0/0 { link-protection; interface so-7/0/0 { no-eligible-backup; Indirect Next-Hop and Composite Next-Hop Configuration routing-options { forwarding-table indirect-next-hop; lvpn-composite-nexthop; Conclusion Rapid convergence is a complex but attainable goal. Achieving sub-0 ms convergence is a matter of breaking down the process of convergence into its underlying components and improving the efficiency of each. By leveraging a combination of link-layer, protocol-based, and protocol independent detection mechanisms, failures can be discovered as quickly as possible. Techniques such as local repair and LFA enable traffic to continue to flow even during the information flooding and propagation stages. And hierarchical forwarding dramatically speeds the process of updating the forwarding plane. Together, these processes only possible on Juniper routing systems can move the industry closer to the goal of consistent sub-0 ms convergence. Networks that employ these techniques and technologies will operate with increased availability and uptime, reducing the cost of downtime and maximizing the network s revenue generating potential. References The techniques and technologies described in this document can be used to dramatically speed convergence in some networks, consistently achieving restoration times under 0 milliseconds is quite feasible. Juniper Networks long-term vision is to enable no excuses sub-0 ms convergence for all networks. In this paper published by the Ethernet Academy, Juniper Fellow Kireeti Kompella outlines the future of MPLS transport and how this vision can be made a reality. Copyright 0, Juniper Networks, Inc.

16 End-to-End Service Restoration Additional information on Juniper Networks commitment to maximum uptime and continuous systems availability can be found within the following documents. White papers Unified ISSU: A Complete Approach to In-Service Software Upgrades Continuous Systems, Nonstop Operations with Junos OS Juniper Networks T Series Core Routers Architecture Overview About Juniper Networks Juniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network. This fuels high-performance businesses. Additional information can be found at Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters To purchase Juniper Networks solutions, Juniper Networks, Inc. 9 North Mathilda Avenue Sunnyvale, CA 9089 USA Phone: 888.JUNIPER ( ) or Fax: Juniper Networks (Hong Kong) 6/F, Cityplaza One King s Road Taikoo Shing, Hong Kong Phone: Fax: Juniper Networks Ireland Airside Business Park Swords, County Dublin, Ireland Phone: EMEA Sales: Fax: please contact your Juniper Networks representative at or authorized reseller. Copyright 0 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice EN Mar 0 Printed on recycled paper 6 Copyright 0, Juniper Networks, Inc.