Internet Draft Internet Draft Loa Andersson Brad Cain Bilel Jamoussi Nortel Networks Requirement Framework for Fast Re-route with MPLS <draft-andersson-reroute-frmwrk-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Interest has recently grown in using MPLS for the creation of engineered backup paths. To evaluate the merits of these proposals we discuss the a framework of general requirements for fast re-route schemes. This document attempts to document the areas against which proposals can be considered. 1. Introduction This memo describes a requirement framework for evaluation of MPLS re-routing schemes. We discuss the areas where providers may have specific requirements. This document does not propose a specific re-route scheme but can be used as a framework for evaluation. Expires April 2000 [Page 1] INTERNET-DRAFT Framework for Fast Re-route with MPLS October 1999 1.1. Background Through the use of dynamic routing protocols, IP networks have the capability to re-route traffic around node or link failures. Using the current routing protocols this re-routing process may take several seconds to minutes. During this period of time black holes or transient loops may occur in the network, causing trafic delivery to be interupted. For a certain types of applications (e.g. www, mail and file tranfer) this is, if not optimal, at least acceptable. For other applications (e.g. real time applications) it is greater concern. The need to provide a much faster re-routing mechanism has been identified. Fast protection/re-route of LSP's in cases of link and/or node failure by means of alternative label switched paths (LSP) has been suggested [haskins] and [krishnan]. In [haskins] the ability to quickly re-route data traffic around a failure or congestion on a alternative label switched path is described. This can be important for in mission critical applications. When a link or node failure occurs, recovery is through the use of re-routing data over an alternative path. Such alternative paths can be established after a primary path failure is detected or, alternatively, it can be established beforehand in order to reduce the path failover time. 1.2. Backup Schemes In this section we explain the use of MPLS backup routing methods and describe in general how these schemes work. 1.2.1. Definitions MPLS backup schemes use secondary paths when routing on primary paths is unavailable. We now define the definitions for these two terms: - Primary path: We define the primary path as the path on which the traffic is directed by the routing protocol or a TE mechanism and which is (from some aspect) considered optimal for that traffic. - Secondary path: We define the secondary path as the path on which the traffic is directed by the re-routing mechanism. This is considered to be a potential sub-optimal. We consider networks in which traffic is using secondary paths to be in a semi-stable state. We also use the term "backup path" to describe a secondary path. Expires April 2000 [Page 2] ^L INTERNET-DRAFT Framework for Fast Re-route with MPLS October 1999 1.2.2. Generalization of Schemes MPLS backup schemes both establish backup paths and dynamically route traffic to these paths during failures. We now discuss the components of a backup schemes to frame the requirements. - Path Algorithms: Backup paths can be either pre-established or established dynamically (after a failure). Schemes may differ in the types of algorithms used to compute backup paths as well as whether the computation is on-line or off-line. - MPLS Use: Closely related to the path algorithm is the manner in which MPLS is utilized to construct and create the backup paths. Schemes may differ in the use of bi-directional paths, label-stacking, etc. - Failure Detection: Once a failure is detected, a notification must be sent to a router which either has a pre-established backup or can dynamically establish one. Schemes may differ in how the notification signal is propagated. For example, a notification could be explicit (e.g. RSVP or LDP) or data driven. 1.2.3. The Recovery Cycle We now present a generalized set of events which occur in a network when a failure occurs when a re-routing mechanism is active. 1. Link/Node failure occurs 2. Failure is detected (signaling initiated) 3. Signaling indicating the failure arrives at an entity which can perform the switch-over 4. The switch-over of traffic from the primary to the secondary occurs 5. The network enters a semi-stable state 6. Dynamic routing protocols converge after failure 7. New primary paths are established (through dynamic protocols) 8. New secondary paths may be established 9. Traffic switched over to the new primary paths While in the semi-stable state another failure might occur for the secondary path, the cycle could, if the the secondary path is protected, begin again. This however is a one way scheme, the abandoned primary path is not taken in to operation again, unless verified by the routing protocol after convergence. Expires April 2000 [Page 3] ^L INTERNET-DRAFT Framework for Fast Re-route with MPLS October 1999 2. Requirements for MPLS Re-Route The traffic engineering of routed networks in general and the fast re-route area in particular are emerging technologies. We see a need for defining a set of general requirement areas by which MPLS fast re-route schemes can be measured and evaluated. We specifically do not specify and hard (e.g. numerical) requirements at this time but give a framework for these specifications. 2.1. Backup restoration time We define backup restoration time as the time required for a backup path to be activated (and traffic flowing) after a failure. Backup Restoration Time is the sum of the Detection Time and the Signal Propagation Time. - Detection Time: We define detection time as the time lapsed between a failure of a node or link in the network and the time that any *local* action (at the point of failure) is taken in response to the failure. This time may be highly dependent on lower layer protocols. - Signal Propagation Time: We define signal propagation time as the time laspsed between the detection time and the time before a backup path is installed. An example of signal propagation time is the time required to signal a failure back to a node which can re-route traffic on a backup path. 2.2. Full Restoration Time We define full restoration time as the time required for a suitable semi-permanent restoration. This is the time required for traffic to be routed onto links which are capable or have been engineered sufficiently to handle excess traffic in failure scenarios. Note that this time may or may not be different from the "Backup Restoration Time" depending on the complexity of a scheme or the capacity of a network. A network that is in a semi-stable state (i.e. traffic flowing over sub-optimal paths), may show deteriating service over time. The network needs to be put back in a condition where "optimal paths" are used. 2.3. Holddown Time We define the holddown period as a bounded time for which a backup path must be used. In some scenarios it may be difficult to determine if the primary path is stable. In these cases a holddown time may be used to prevent excess flapping of traffic between a primary and secondary path. Expires April 2000 [Page 4] ^L INTERNET-DRAFT Framework for Fast Re-route with MPLS October 1999 2.4. Backup Capacity Backup schemes may require differing amounts of "backup capacity" in the advent of a failure. This capacity will be dependant on the traffic characteristics of the network. However, it may also be dependant on the particular backup path selection algorithms as well as the signaling and re-routing methods. 2.5. Additive Latency Backup schemes may introduce additive latency traffic. For example, a backup path may take many more hops. This may be dependent on the backup path selection algorithms as well as the signaling and re-routing methods. 2.6. Failure Types Backup schemes may account for only link failures or both node and link failures. For example, a scheme may require more backup paths to take node failures into account. 2.7. Re-ordering Backup schemes may introduce re-ordering of packets. This occurs when packets are re-routed back to the re-route point and fall behind packets which are now already on the backup path. For example, re-ordering may occur during detection and signaling time. Also the action of putting traffic back on optimal paths might cause packet re-ordering. 2.8. State Overhead As the number of backup paths grows, the state required to maintain them also grows. Schemes may require differing numbers of paths to maintain certain levels of coverage, etc. The state required may also depend on the particular scheme used to re-route packets. In many cases the state overhead will be in proportion to the number of backup LSPs. 2.9. Loss Backup schemes may introduce a certain amount of packet loss during switchover to a backup path. Schemes which introduce loss during detection and signaling time can measure this loss by evaluating restoration times in proportion to the link speed. In case of link or node failure a certain packet loss is inevitable. The packet loss is a function of packets per second times the full restoration time. Expires April 2000 [Page 5] ^L INTERNET-DRAFT Framework for Fast Re-route with MPLS October 1999 2.10. Coverage Backup schemes may offer various types of failover coverage. The total coverage may be defined in terms of several metrics: - Number of concurrent failures: dependent on the layout of backup paths, multiple failure scenarios may be able to be restored. - Number of backup paths: for a given failure, there may be one or more backup paths. - Percentage of coverage: dependent on a scheme and its implementation, a certain percentage of failures may be covered. This may be subdivided into percentage of link failures and percentage of node failures. The number of protected LSP's will highly effect how fast the total set of LSP's affected by a failure could be re-routed. The ratio of protected is n/N, there n is the number of protected LSPs and N is the total number of LSPs. Expires April 2000 [Page 6] ^L INTERNET-DRAFT Framework for Fast Re-route with MPLS October 1999 3. References [haskin] Dimitry Haskin, Ram Krishnan "A Method for Setting an Alternative Label Switched Paths to Handle Fast Reroute", draft-haskin-mpls-fast-reroute-01.txt, 1999, Work in progress. [krishnan] Dimitry Haskin, Ram Krishnan "Extensions to RSVP to Handle Establishment of Alternate Label-Switched Paths for Fast Re-route", draft-krishnan-mpls-reroute-rsvpext-01.txt, 1999, Work in progress. [makan] S. Makam, V. Sharma, K. Owens, C. Haung, "Protection/ Restoration of MPLS Networks", draft-makam-mpls-protection-00.txt, 1999, Work in progress. 4. Author's Addresses Loa Andersson Nortel Networks St Eriksgatan 115, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34 e-mail: loa.andersson@nortelnetworks.com Brad Cain Email: bcain@baynetworks.com Bilel Jamoussi Email: jamoussi@nortelnetworks.com Nortel Networks 3 Federal Street, BL3-03 Billerica, MA 01821, USA Expires April 2000 [Page 7]