From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5714.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc5714.txt (limited to 'doc/rfc/rfc5714.txt') diff --git a/doc/rfc/rfc5714.txt b/doc/rfc/rfc5714.txt new file mode 100644 index 0000000..8b412f8 --- /dev/null +++ b/doc/rfc/rfc5714.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Shand +Request for Comments: 5714 S. Bryant +Category: Informational Cisco Systems +ISSN: 2070-1721 January 2010 + + + IP Fast Reroute Framework + +Abstract + + This document provides a framework for the development of IP fast- + reroute mechanisms that provide protection against link or router + failure by invoking locally determined repair paths. Unlike MPLS + fast-reroute, the mechanisms are applicable to a network employing + conventional IP routing and forwarding. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5714. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Shand & Bryant Informational [Page 1] + +RFC 5714 IP Fast Reroute Framework January 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 5 + 4. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Mechanisms for IP Fast-Reroute . . . . . . . . . . . . . . . . 7 + 5.1. Mechanisms for Fast Failure Detection . . . . . . . . . . 7 + 5.2. Mechanisms for Repair Paths . . . . . . . . . . . . . . . 8 + 5.2.1. Scope of Repair Paths . . . . . . . . . . . . . . . . 9 + 5.2.2. Analysis of Repair Coverage . . . . . . . . . . . . . 9 + 5.2.3. Link or Node Repair . . . . . . . . . . . . . . . . . 10 + 5.2.4. Maintenance of Repair Paths . . . . . . . . . . . . . 10 + 5.2.5. Local Area Networks . . . . . . . . . . . . . . . . . 11 + 5.2.6. Multiple Failures and Shared Risk Link Groups . . . . 11 + 5.3. Mechanisms for Micro-Loop Prevention . . . . . . . . . . . 12 + 6. Management Considerations . . . . . . . . . . . . . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + When a link or node failure occurs in a routed network, there is + inevitably a period of disruption to the delivery of traffic until + the network re-converges on the new topology. Packets for + destinations that were previously reached by traversing the failed + component may be dropped or may suffer looping. Traditionally, such + disruptions have lasted for periods of at least several seconds, and + most applications have been constructed to tolerate such a quality of + service. + + Recent advances in routers have reduced this interval to under a + second for carefully configured networks using link state IGPs. + However, new Internet services are emerging that may be sensitive to + periods of traffic loss that are orders of magnitude shorter than + this. + + Addressing these issues is difficult because the distributed nature + of the network imposes an intrinsic limit on the minimum convergence + time that can be achieved. + + However, there is an alternative approach, which is to compute backup + routes that allow the failure to be repaired locally by the router(s) + detecting the failure without the immediate need to inform other + routers of the failure. In this case, the disruption time can be + limited to the small time taken to detect the adjacent failure and + invoke the backup routes. This is analogous to the technique + + + +Shand & Bryant Informational [Page 2] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + employed by MPLS fast-reroute [RFC4090], but the mechanisms employed + for the backup routes in pure IP networks are necessarily very + different. + + This document provides a framework for the development of this + approach. + + Note that in order to further minimize the impact on user + applications, it may be necessary to design the network such that + backup paths with suitable characteristics (for example, capacity + and/or delay) are available for the algorithms to select. Such + considerations are outside the scope of this document. + +2. Terminology + + This section defines words and acronyms used in this document and + other documents discussing IP fast-reroute. + + D Used to denote the destination router under + discussion. + + Distance_opt(A,B) The metric sum of the shortest path from A to B. + + Downstream Path This is a subset of the loop-free alternates + where the neighbor N meets the following + condition: + Distance_opt(N, D) < Distance_opt(S,D) + + E Used to denote the router that is the primary + neighbor to get from S to the destination D. + Where there is an ECMP set for the shortest path + from S to D, these are referred to as E_1, E_2, + etc. + + ECMP Equal cost multi-path: Where, for a particular + destination D, multiple primary next-hops are + used to forward traffic because there exist + multiple shortest paths from S via different + output layer-3 interfaces. + + FIB Forwarding Information Base. The database used + by the packet forwarder to determine what actions + to perform on a packet. + + IPFRR IP fast-reroute. + + Link(A->B) A link connecting router A to router B. + + + + +Shand & Bryant Informational [Page 3] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + LFA Loop-Free Alternate. A neighbor N, that is not a + primary neighbor E, whose shortest path to the + destination D does not go back through the router + S. The neighbor N must meet the following + condition: + Distance_opt(N, D) < Distance_opt(N, S) + + Distance_opt(S, D) + + Loop-Free Neighbor A neighbor N_i, which is not the particular + primary neighbor E_k under discussion, and whose + shortest path to D does not traverse S. For + example, if there are two primary neighbors E_1 + and E_2, E_1 is a loop-free neighbor with regard + to E_2, and vice versa. + + Loop-Free Link-Protecting Alternate + A path via a Loop-Free Neighbor N_i that reaches + destination D without going through the + particular link of S that is being protected. In + some cases, the path to D may go through the + primary neighbor E. + + Loop-Free Node-Protecting Alternate + A path via a Loop-Free Neighbor N_i that reaches + destination D without going through the + particular primary neighbor (E) of S that is + being protected. + + N_i The ith neighbor of S. + + Primary Neighbor A neighbor N_i of S which is one of the next hops + for destination D in S's FIB prior to any + failure. + + R_i_j The jth neighbor of N_i. + + Repair Path The path used by a repairing node to send traffic + that it is unable to send via the normal path + owing to a failure. + + Routing Transition The process whereby routers converge on a new + topology. In conventional networks, this process + frequently causes some disruption to packet + delivery. + + + + + + + +Shand & Bryant Informational [Page 4] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + RPF Reverse Path Forwarding, i.e., checking that a + packet is received over the interface that would + be used to send packets addressed to the source + address of the packet. + + S Used to denote a router that is the source of a + repair that is computed in anticipation of the + failure of a neighboring router denoted as E, or + of the link between S and E. It is the viewpoint + from which IP fast-reroute is described. + + SPF Shortest Path First, e.g., Dijkstra's algorithm. + + SPT Shortest path tree + + Upstream Forwarding Loop + A forwarding loop that involves a set of routers, + none of which is directly connected to the link + that has caused the topology change that + triggered a new SPF in any of the routers. + +3. Scope and Applicability + + The initial scope of this work is in the context of link state IGPs. + Link state protocols provide ubiquitous topology information, which + facilitates the computation of repairs paths. + + Provision of similar facilities in non-link state IGPs and BGP is a + matter for further study, but the correct operation of the repair + mechanisms for traffic with a destination outside the IGP domain is + an important consideration for solutions based on this framework. + + Complete protection against multiple unrelated failures is out of + scope of this work. + +4. Problem Analysis + + The duration of the packet delivery disruption caused by a + conventional routing transition is determined by a number of factors: + + 1. The time taken to detect the failure. This may be of the order + of a few milliseconds when it can be detected at the physical + layer, up to several tens of seconds when a routing protocol + Hello is employed. During this period, packets will be + unavoidably lost. + + + + + + +Shand & Bryant Informational [Page 5] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + 2. The time taken for the local router to react to the failure. + This will typically involve generating and flooding new routing + updates, perhaps after some hold-down delay, and re-computing the + router's FIB. + + 3. The time taken to pass the information about the failure to other + routers in the network. In the absence of routing protocol + packet loss, this is typically between 10 milliseconds and 100 + milliseconds per hop. + + 4. The time taken to re-compute the forwarding tables. This is + typically a few milliseconds for a link state protocol using + Dijkstra's algorithm. + + 5. The time taken to load the revised forwarding tables into the + forwarding hardware. This time is very implementation dependent + and also depends on the number of prefixes affected by the + failure, but may be several hundred milliseconds. + + The disruption will last until the routers adjacent to the failure + have completed steps 1 and 2, and until all the routers in the + network whose paths are affected by the failure have completed the + remaining steps. + + The initial packet loss is caused by the router(s) adjacent to the + failure continuing to attempt to transmit packets across the failure + until it is detected. This loss is unavoidable, but the detection + time can be reduced to a few tens of milliseconds as described in + Section 5.1. + + In some topologies, subsequent packet loss may be caused by the + "micro-loops" which may form as a result of temporary inconsistencies + between routers' forwarding tables [RFC5715]. These inconsistencies + are caused by steps 3, 4, and 5 above, and in many routers it is step + 5 that is both the largest factor and that has the greatest variance + between routers. The large variance arises from implementation + differences and from the differing impact that a failure has on each + individual router. For example, the number of prefixes affected by + the failure may vary dramatically from one router to another. + + In order to reduce packet disruption times to a duration commensurate + with the failure detection times, two mechanisms may be required: + + a. A mechanism for the router(s) adjacent to the failure to rapidly + invoke a repair path, which is unaffected by any subsequent re- + convergence. + + + + + +Shand & Bryant Informational [Page 6] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + b. In topologies that are susceptible to micro-loops, a micro-loop + control mechanism may be required [RFC5715]. + + Performing the first task without the second may result in the repair + path being starved of traffic and hence being redundant. Performing + the second without the first will result in traffic being discarded + by the router(s) adjacent to the failure. + + Repair paths may always be used in isolation where the failure is + short-lived. In this case, the repair paths can be kept in place + until the failure is repaired, therefore there is no need to + advertise the failure to other routers. + + Similarly, micro-loop avoidance may be used in isolation to prevent + loops arising from pre-planned management action. In which case the + link or node being shut down can remain in service for a short time + after its removal has been announced into the network, and hence it + can function as its own "repair path". + + Note that micro-loops may also occur when a link or node is restored + to service, and thus a micro-loop avoidance mechanism may be required + for both link up and link down cases. + +5. Mechanisms for IP Fast-Reroute + + The set of mechanisms required for an effective solution to the + problem can be broken down into the sub-problems described in this + section. + +5.1. Mechanisms for Fast Failure Detection + + It is critical that the failure detection time is minimized. A + number of well-documented approaches are possible, such as: + + 1. Physical detection; for example, loss of light. + + 2. Protocol detection that is routing protocol independent; for + example, the Bidirectional Failure Detection protocol [BFD]. + + 3. Routing protocol detection; for example, use of "fast Hellos". + + When configuring packet-based failure detection mechanisms it is + important that consideration be given to the likelihood and + consequences of false indications of failure. The incidence of false + indication of failure may be minimized by appropriately prioritizing + the transmission, reception, and processing of the packets used to + detect link or node failure. Note that this is not an issue that is + specific to IPFRR. + + + +Shand & Bryant Informational [Page 7] + +RFC 5714 IP Fast Reroute Framework January 2010 + + +5.2. Mechanisms for Repair Paths + + Once a failure has been detected by one of the above mechanisms, + traffic that previously traversed the failure is transmitted over one + or more repair paths. The design of the repair paths should be such + that they can be pre-calculated in anticipation of each local failure + and made available for invocation with minimal delay. There are + three basic categories of repair paths: + + 1. Equal cost multi-paths (ECMP). Where such paths exist, and one + or more of the alternate paths do not traverse the failure, they + may trivially be used as repair paths. + + 2. Loop-free alternate paths. Such a path exists when a direct + neighbor of the router adjacent to the failure has a path to the + destination that can be guaranteed not to traverse the failure. + + 3. Multi-hop repair paths. When there is no feasible loop-free + alternate path it may still be possible to locate a router, which + is more than one hop away from the router adjacent to the + failure, from which traffic will be forwarded to the destination + without traversing the failure. + + ECMP and loop-free alternate paths (as described in [RFC5286]) offer + the simplest repair paths and would normally be used when they are + available. It is anticipated that around 80% of failures (see + Section 5.2.2) can be repaired using these basic methods alone. + + Multi-hop repair paths are more complex, both in the computations + required to determine their existence, and in the mechanisms required + to invoke them. They can be further classified as: + + a. Mechanisms where one or more alternate FIBs are pre-computed in + all routers, and the repaired packet is instructed to be + forwarded using a "repair FIB" by some method of per-packet + signaling such as detecting a "U-turn" [UTURN], [FIFR] or by + marking the packet [SIMULA]. + + b. Mechanisms functionally equivalent to a loose source route that + is invoked using the normal FIB. These include tunnels + [TUNNELS], alternative shortest paths [ALT-SP], and label-based + mechanisms. + + c. Mechanisms employing special addresses or labels that are + installed in the FIBs of all routers with routes pre-computed to + avoid certain components of the network. For example, see + [NOTVIA]. + + + + +Shand & Bryant Informational [Page 8] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + In many cases, a repair path that reaches two hops away from the + router detecting the failure will suffice, and it is anticipated that + around 98% of failures (see Section 5.2.2) can be repaired by this + method. However, to provide complete repair coverage, some use of + longer multi-hop repair paths is generally necessary. + +5.2.1. Scope of Repair Paths + + A particular repair path may be valid for all destinations which + require repair or may only be valid for a subset of destinations. If + a repair path is valid for a node immediately downstream of the + failure, then it will be valid for all destinations previously + reachable by traversing the failure. However, in cases where such a + repair path is difficult to achieve because it requires a high order + multi-hop repair path, it may still be possible to identify lower- + order repair paths (possibly even loop-free alternate paths) that + allow the majority of destinations to be repaired. When IPFRR is + unable to provide complete repair, it is desirable that the extent of + the repair coverage can be determined and reported via network + management. + + There is a trade-off between minimizing the number of repair paths to + be computed, and minimizing the overheads incurred in using higher- + order multi-hop repair paths for destinations for which they are not + strictly necessary. However, the computational cost of determining + repair paths on an individual destination basis can be very high. + + It will frequently be the case that the majority of destinations may + be repaired using only the "basic" repair mechanism, leaving a + smaller subset of the destinations to be repaired using one of the + more complex multi-hop methods. Such a hybrid approach may go some + way to resolving the conflict between completeness and complexity. + + The use of repair paths may result in excessive traffic passing over + a link, resulting in congestion discard. This reduces the + effectiveness of IPFRR. Mechanisms to influence the distribution of + repaired traffic to minimize this effect are therefore desirable. + +5.2.2. Analysis of Repair Coverage + + The repair coverage obtained is dependent on the repair strategy and + highly dependent on the detailed topology and metrics. Estimates of + the repair coverage quoted in this document are for illustrative + purposes only and may not be always be achievable. + + In some cases the repair strategy will permit the repair of all + single link or node failures in the network for all possible + destinations. This can be defined as 100% coverage. However, where + + + +Shand & Bryant Informational [Page 9] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + the coverage is less than 100%, it is important for the purposes of + comparisons between different proposed repair strategies to define + what is meant by such a percentage. There are four possibilities: + + 1. The percentage of links (or nodes) that can be fully protected + (i.e., for all destinations). This is appropriate where the + requirement is to protect all traffic, but some percentage of the + possible failures may be identified as being un-protectable. + + 2. The percentage of destinations that can be protected for all link + (or node) failures. This is appropriate where the requirement is + to protect against all possible failures, but some percentage of + destinations may be identified as being un-protectable. + + 3. For all destinations (d) and for all failures (f), the percentage + of the total potential failure cases (d*f) that are protected. + This is appropriate where the requirement is an overall "best- + effort" protection. + + 4. The percentage of packets normally passing though the network + that will continue to reach their destination. This requires a + traffic matrix for the network as part of the analysis. + +5.2.3. Link or Node Repair + + A repair path may be computed to protect against failure of an + adjacent link, or failure of an adjacent node. In general, link + protection is simpler to achieve. A repair which protects against + node failure will also protect against link failure for all + destinations except those for which the adjacent node is a single + point of failure. + + In some cases, it may be necessary to distinguish between a link or + node failure in order that the optimal repair strategy is invoked. + Methods for link/node failure determination may be based on + techniques such as BFD [BFD]. This determination may be made prior + to invoking any repairs, but this will increase the period of packet + loss following a failure unless the determination can be performed as + part of the failure detection mechanism itself. Alternatively, a + subsequent determination can be used to optimize an already invoked + default strategy. + +5.2.4. Maintenance of Repair Paths + + In order to meet the response-time goals, it is expected (though not + required) that repair paths, and their associated FIB entries, will + be pre-computed and installed ready for invocation when a failure is + detected. Following invocation, the repair paths remain in effect + + + +Shand & Bryant Informational [Page 10] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + until they are no longer required. This will normally be when the + routing protocol has re-converged on the new topology taking into + account the failure, and traffic will no longer be using the repair + paths. + + The repair paths have the property that they are unaffected by any + topology changes resulting from the failure that caused their + instantiation. Therefore, there is no need to re-compute them during + the convergence period. They may be affected by an unrelated + simultaneous topology change, but such events are out of scope of + this work (see Section 5.2.6). + + Once the routing protocol has re-converged, it is necessary for all + repair paths to take account of the new topology. Various + optimizations may permit the efficient identification of repair paths + that are unaffected by the change, and hence do not require full re- + computation. Since the new repair paths will not be required until + the next failure occurs, the re-computation may be performed as a + background task and be subject to a hold-down, but excessive delay in + completing this operation will increase the risk of a new failure + occurring before the repair paths are in place. + +5.2.5. Local Area Networks + + Protection against partial or complete failure of LANs is more + complex than the point-to-point case. In general, there is a trade- + off between the simplicity of the repair and the ability to provide + complete and optimal repair coverage. + +5.2.6. Multiple Failures and Shared Risk Link Groups + + Complete protection against multiple unrelated failures is out of + scope of this work. However, it is important that the occurrence of + a second failure while one failure is undergoing repair should not + result in a level of service which is significantly worse than that + which would have been achieved in the absence of any repair strategy. + + Shared Risk Link Groups (SRLGs) are an example of multiple related + failures, and the more complex aspects of their protection are a + matter for further study. + + One specific example of an SRLG that is clearly within the scope of + this work is a node failure. This causes the simultaneous failure of + multiple links, but their closely defined topological relationship + makes the problem more tractable. + + + + + + +Shand & Bryant Informational [Page 11] + +RFC 5714 IP Fast Reroute Framework January 2010 + + +5.3. Mechanisms for Micro-Loop Prevention + + Ensuring the absence of micro-loops is important not only because + they can cause packet loss in traffic that is affected by the + failure, but because by saturating a link with looping packets micro- + loops can cause congestion. This congestion can then lead to routers + discarding traffic that would otherwise be unaffected by the failure. + + A number of solutions to the problem of micro-loop formation have + been proposed and are summarized in [RFC5715]. The following factors + are significant in their classification: + + 1. Partial or complete protection against micro-loops. + + 2. Convergence delay. + + 3. Tolerance of multiple failures (from node failures, and in + general). + + 4. Computational complexity (pre-computed or real time). + + 5. Applicability to scheduled events. + + 6. Applicability to link/node reinstatement. + + 7. Topological constraints. + +6. Management Considerations + + While many of the management requirements will be specific to + particular IPFRR solutions, the following general aspects need to be + addressed: + + 1. Configuration + + A. Enabling/disabling IPFRR support. + + B. Enabling/disabling protection on a per-link or per-node + basis. + + C. Expressing preferences regarding the links/nodes used for + repair paths. + + D. Configuration of failure detection mechanisms. + + E. Configuration of loop-avoidance strategies + + + + + +Shand & Bryant Informational [Page 12] + +RFC 5714 IP Fast Reroute Framework January 2010 + + + 2. Monitoring and operational support + + A. Notification of links/nodes/destinations that cannot be + protected. + + B. Notification of pre-computed repair paths, and anticipated + traffic patterns. + + C. Counts of failure detections, protection invocations, and + packets forwarded over repair paths. + + D. Testing repairs. + +7. Security Considerations + + This framework document does not itself introduce any security + issues, but attention must be paid to the security implications of + any proposed solutions to the problem. + + Where the chosen solution uses tunnels it is necessary to ensure that + the tunnel is not used as an attack vector. One method of addressing + this is to use a set of tunnel endpoint addresses that are excluded + from use by user traffic. + + There is a compatibility issue between IPFRR and reverse path + forwarding (RPF) checking. Many of the solutions described in this + document result in traffic arriving from a direction inconsistent + with a standard RPF check. When a network relies on RPF checking for + security purposes, an alternative security mechanism will need to be + deployed in order to permit IPFRR to used. + + Because the repair path will often be of a different length than the + pre-failure path, security mechanisms that rely on specific Time to + Live (TTL) values will be adversely affected. + +8. Acknowledgements + + The authors would like to acknowledge contributions made by Alia + Atlas, Clarence Filsfils, Pierre Francois, Joel Halpern, Stefano + Previdi, and Alex Zinin. + + + + + + + + + + + +Shand & Bryant Informational [Page 13] + +RFC 5714 IP Fast Reroute Framework January 2010 + + +9. Informative References + + [ALT-SP] Tian, A., "Fast Reroute using Alternative Shortest Paths", + Work in Progress, July 2004. + + [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding + Detection", Work in Progress, January 2010. + + [FIFR] Nelakuditi, S., Lee, S., Lu, Y., Zhang, Z., and C. Chuah, + "Fast Local Rerouting for Handling Transient Link + Failures", IEEE/ACM Transactions on Networking, Vol. 15, + No. 2, DOI 10.1109/TNET.2007.892851, available + from http://www.ieeexplore.ieee.org, April 2007. + + [NOTVIA] Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute + Using Not-via Addresses", Work in Progress, July 2009. + + [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute + Extensions to RSVP-TE for LSP Tunnels", RFC 4090, + May 2005. + + [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast + Reroute: Loop-Free Alternates", RFC 5286, September 2008. + + [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free + Convergence", RFC 5715, January 2010. + + [SIMULA] Kvalbein, A., Hansen, A., Cicic, T., Gjessing, S., and O. + Lysne, "Fast IP Network Recovery using Multiple Routing + Configurations", Infocom 10.1109/INFOCOM.2006.227, + available from http://www.ieeexplore.ieee.org, April 2006. + + [TUNNELS] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP + Fast Reroute using tunnels", Work in Progress, + November 2007. + + [UTURN] Atlas, A., "U-turn Alternates for IP/LDP Fast-Reroute", + Work in Progress, February 2006. + + + + + + + + + + + + + +Shand & Bryant Informational [Page 14] + +RFC 5714 IP Fast Reroute Framework January 2010 + + +Authors' Addresses + + Mike Shand + Cisco Systems + 250, Longwater Avenue. + Reading, Berks RG2 6GB + UK + + EMail: mshand@cisco.com + + + Stewart Bryant + Cisco Systems + 250, Longwater Avenue. + Reading, Berks RG2 6GB + UK + + EMail: stbryant@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Shand & Bryant Informational [Page 15] + -- cgit v1.2.3