Internet Draft Internet Engineering Task Force Dimitry Haskin Internet Draft Ram Krishnan Expires: December 1999 Nexabit Networks Robert Boyd Alan Hannan Frontier GlobalCenter June 1999 A Method for Setting an Alternative Label Switched Paths to Handle Fast Reroute draft-haskin-mpls-fast-reroute-00.txt Status 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 This document describes a method for setting an alternative label switched path to handle fast data packet reroute upon a failure in a primary label switched path in Multi-protocol Label Switching (MPLS) network. Haskin, et al. Expires December 1999 [Page 1] Internet Draft draft-haskin-mpls-fast-reroute-00.txt June 1999 1. Introduction The ability to quickly reroute traffic around a failure or congestion in a label switched path (LSP) can be important in mission critical MPLS networks. When an established label switched path becomes unusable (e.g. due to a physical link or switch failure) data may need to be re- routed over an alternative path. Such an alternative path can be established after a primary path failure is detected or, alternatively, it can be established beforehand in order to reduce the path switchover time. Pre-established alternative paths are essential where packet loss due to an LSP failure is undesirable. Since it may take a significant time for a device on a label switched path to detect a distant link failure, it may continue sending packets along the primary path. As soon as such packets reach a switch that is aware of the failure, packets must be immediately rerouted by the switch to an alternative path away from the failure if loss of data is to be avoided. Since it is impossible to predict where failure may occur along an LSP tunnel, it might involve complex computations and extensive signaling to establish alternative paths to protect the entire tunnel. In the extreme, to fully protect an LSP tunnel, alternative paths might be established at each intermediate switch along the primary LSP. This document defines a method for setting alternative label switched paths in such a matter that minimizes alternative path computation complexity and signaling requirements. It also can provide in-band means for quick detection of link and switch failures or congestion along a primary path without resorting to an out of band signaling mechanism. In order for the presented method to work, it is important that network topology and policy allow the establishment of a backup LSP between the endpoint switches of the protected LSP tunnel such that, with the exception of the tunnel endpoint switches, the backup LSP does not share any links or switches with the path that it intends to protect. 2. Alternative Path Arrangement The main idea behind the presented method is to reverse traffic at the point of the protected LSP back to the source switch of the protected LSP such that the traffic flow can be then redirected via a parallel LSP between source and destination switches of the protected LSP tunnel. Haskin, et al. Expires December 1999 [Page 2] Internet Draft draft-haskin-mpls-fast-reroute-00.txt June 1999 Referring to Figure 1, there is an MPLS network consisting of 7 interconnected switches. Figure 1: +--------+ 24 +--------+ 46 +--------+ +-->| Switch |------->| Switch |------->| Switch |---+ : | 2 |--------| 4 |--------| 6 | : : | | | | | | : 12 : +--------+ +--------+ +--------+ : : / / / \ : : / / / \ V +--------+ 31 +--------+ 53 +--------+ 75 +--------+ | Switch |<-------| Switch |<-------| Switch |<......| Switch | | 1 |--------| 3 |--------| 5 |-------| 7 | =>| |=======>| |=======>| |======>| |=> +--------+ 13 +--------+ 35 +--------+ 57 +--------+ The following terminology is used for purpose of describing the method: A portion of a label switched path that is to be protected by an alternative path is referred as 'protected path segment'. Only failures within the protected path segment, which may at its extreme include the entire primary path, are subject to fast reroute to the alternative path. A primary LSP between switches 1 and 7 is shown by a double-dashed links labeled 13, 35, and 57. Arrows indicate direction of the data traffic. The switch at the ingress endpoint of the protected path segment is referred as 'the source switch'. Switch 1 in Figure 1 is the source switch in our example of a protected path. The switch at the egress endpoint of the protected path segment is referred as 'the destination switch'. Switch 7 in Figure 1 is the destination switch in our example of a protected path. The switches between the source switch and the destination switch along the protected path are referred as protected switches. The switch immediately preceding the destination switch along the protected path segment is referred as the last hop switch. Switch 5 in Figure 1 is the last hop switch for the protected path. The essence of the presented method is that an alternative unidirectional label switched path is established in the following way: The initial segment of the alternative LSP runs between the last hop switch and the source switch in the reverse direction of the protected path traversing through every protected switch between the last hop switch and the source switch. The dashed line between switches 5 and 1 Haskin, et al. Expires December 1999 [Page 3] Internet Draft draft-haskin-mpls-fast-reroute-00.txt June 1999 illustrates such a segment of the alternative path. Alternatively, the initial LSP segment can be set from the destination switch to the source switch in the reverse direction of the protected path traversing through every protected switch between the destination switch and the source switch. The dashed line between switches 7 and 1 illustrates the initial path segment that is set in this way. The second and final segment of the alternative path is set between the source switch and the destination switch along a transmission path that does not utilize any protected switches. It is not an intention of this document to specify procedures for calculating such a path. The dashed line between Switches 1 and 7 through Switches 2, 4, and 6 illustrates the final segment of the alternative path. The initial and final segments of the alternative path are linked to form an entire alternative path from the last hop switch to the destination switch. In Figure 1 the entire alternative path consists of the LSP links labeled 53, 31, 12, 24, 46, and 46 if the alternative path originates at the last hop switch. Alternatively, the entire alternative path consists of the LSP links labeled 75, 53, 31, 12, 24, 46, and 46 if the alternative path originates at the destination switch of the primary path. As soon as a link failure or congestion along the protected path is detected an operational switch at ingress of failed link reroutes incoming traffic around of the failure or congestion by linking upstream portion of the primary path to the downstream portion of the alternative path. Thus if the link between Switches 3 and 5 fails, the primary and alternative paths are linked at Switch 3 forming the following label switched path for the traffic flow: 13->31->12->24->46->67. The presented method of setting the alternative label switched path has the following benefits: - Path computation complexity is greatly reduced. Only a single additional path between the source and destination switches of the protected path segment needs to be calculated. Moreover, both primary and alternative path computations can be localized at a single switch avoiding problems that can arise when computations are distributed among multiple switches. - The amount of LSP setup signaling is minimized. With small extensions to RSVP or LDP (described in separated documents), a single switch at ingress of the protected path can initiate label allocations for both primary and alternative paths. - Presence of traffic on the alternative path segment that runs in the reverse direction of the primary path can be used as an indication of a failure or congestion of a downstream link along the primary path. As soon as a switch along the primary path sees the reverse traffic flow, it may stop sending traffic downstream Haskin, et al. Expires December 1999 [Page 4] Internet Draft draft-haskin-mpls-fast-reroute-00.txt June 1999 of the primary path by initiating an immediate rerouting of data traffic to the alternative path. As the result of this "crank back" process the source switch may start sending data traffic directly along the final alternative path segment. It is fair to note that the crank-back technique increases the likelihood of data packet reordering during the path rerouting process. Therefore benefits of the reducing the alternative path latency should be weighed against possible problems associated with short term packet reordering. On a positive side, if multiple microflows are aggregated in a single protected LSP tunnel, only a very limited number of microflows may be affected by such packet reordering. Additionally, the impact of reordering on any single microflow may tend to be minimal. It also can be noted that if the alternative label switched path is originated at the destination switch of the primary path, it forms a 'loop-back' LSP that originates and terminates at this switch. Therefore in this case it is possible to verify integrity of the entire alternative path by simply sending a probe packet from the destination switch along the alternative path and asserting that the packet arrives back to the destination switch. When this technique is used to assert the path integrity, the care has to be taken that the limited diagnostic traffic is not interpreted as an indication of a primary path failure that triggers data rerouting at the intermediate switches. 3. Elementary link level protection scheme If only link-level protection is desired, an alternative path between link endpoints can be set up to protect each link. Such a scheme can be viewed as a degenerate case of this proposal in which the link endpoints constitute the source and destination endpoints in the described approach. 4. Bandwidth Reservation Considerations Generally there is no need to specifically allocate bandwidth resources to the alternate LSP. The Traffic-triggered priority of the primary LSP can be used as resource preemption priority for the alternate LSP in case the primary LSP fails and traffic is switched to the alternate LSP as described in this document. The traffic-triggered priority is the priority assigned to traffic belonging to an LSP, only when there is traffic present on that LSP. When there is no traffic, other LSPs sharing the interface should get full access to bandwidth and other system resources. Consequently, if the traffic-triggered priority of the primary LSP is greater than the holding priorities of the other LSPs using an interface in the alternate path, the alternate LSP can preempt bandwidth and other system resources as soon as traffic gets rerouted via the alternate LSP. This enables high-priority LSPs, which are being rerouted, to preempt resources from lower priority LSPs without explicit bandwidth reservation for the alternate path. Of Haskin, et al. Expires December 1999 [Page 5] Internet Draft draft-haskin-mpls-fast-reroute-00.txt June 1999 course, if bandwidth efficiency is not an issue, bandwidth resources can be explicitly reserved for the alternate LSP also. An extension to existing signaling protocols such as RSVP and LDP may be needed to indicate that traffic-triggered resource preemption is requested for a particular LSP as opposed to the setup priority preemption. 5. Intellectual Property Considerations Nexabit Networks may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document. In the event that Nexabit Networks obtains such patent rights, Nexabit Networks intends to license them on reasonable and non- discriminatory terms in accordance with the intellectual property rights procedures of the IETF standards process. 6. Acknowledgments This document has benefited from discussions with Jim Boyle. 7. References [1] Rosen, E. et al., "Multiprotocol Label Switching Architecture", Internet Draft, draft-ietf-mpls-arch-05.txt, April 1999. [2] Awduche, D. et al., "Requirements for Traffic Engineering over MPLS", Internet Draft, draft-ietf-mpls-traffic-eng-00.txt, October 1998. Haskin, et al. Expires December 1999 [Page 6] Internet Draft draft-haskin-mpls-fast-reroute-00.txt June 1999 7. Authors' Addresses Dimitry Haskin Nexabit Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 E-mail: dhaskin@nexabit.com Ram Krishnan Nexabit Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 E-mail: ram@nexabit.com Robert Boyd Frontier GlobalCenter 1154 East Arques Avenue, Sunnyvale, CA 94086 E-mail: rboyd@globalcenter.net Alan Hannan Frontier GlobalCenter 1154 East Arques Avenue, Sunnyvale, CA 94086 Email: alan@globalcenter.net Haskin, et al. Expires December 1999 [Page 7] Internet Engineering Task Force Ram Krishnan Internet Draft Dimitry Haskin Expires: December 1999 Nexabit Networks June 1999 Extensions to RSVP to Handle Establishment of Alternate Label-Switched Paths for Fast Re-route draft-krishnan-mpls-reroute-rsvpext-00.txt Status 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 This document describes the extensions that enables RSVP to support creation of an alternative label switched path to handle fast data packet reroute upon failure in a primary label switched path in an Multi-protocol Label Switching (MPLS) network as described in [3]. As such, this draft is a companion draft to [3]. The proposed extensions present no backward compatibility issues. Haskin, Krishnan Expires December 1999 [Page 1] Draft draft-krishnan-mpls-fast-reroute-rsvpext-00.txt June 1999 1. Introduction A mechanism to establish an alternate label-switched path (LSP) that is used for quickly re-routing traffic in the event of a network element failure or congestion along the primary LSP is described in [3]. Only one alternate LSP needs to be created in this approach as opposed to an approach that requires multiple alternate LSPs to be created at each intermediate switch along the LSP. Such an approach reduces computational complexity and the associated signalling overhead. It is required that the alternate backup LSP does not share any network elements (links or label-switched routers (LSR)) with the exception of the source and destination LSRs of the primary LSP. This document defines objects necessary for signalling the creation and establishment of the alternate LSP when the primary and alternative LSPs are initiated from a single router using RSVP [4]. 2. Description of the Approach The main idea behind the approach in [3]is to redirect traffic at the point of failure in the primary LSP back to the source end-point of the primary LSP in the reverse direction after which the traffic flow is sent along via the alternate disjoint LSP between source and destination switches of the protected primary LSP. Referring to Figure 1, there is an MPLS network consisting of 7 interconnected switches. Figure 1: +--------+ 24 +--------+ 46 +--------+ +-->| Switch |------->| Switch |------->| Switch |---+ : | 2 |--------| 4 |--------| 6 | : : | | | | | | : 12 : +--------+ +--------+ +--------+ : : / / / \ : : / / / \ V +--------+ 31 +--------+ 53 +--------+ 75 +--------+ | Switch |<-------| Switch |<-------| Switch |<......| Switch | | 1 |--------| 3 |--------| 5 |-------| 7 | =>| |=======>| |=======>| |======>| |=> +--------+ 13 +--------+ 35 +--------+ 57 +--------+ A primary LSP between switches 1 and 7 is shown by a double-dashed links labeled 13, 35, and 57. Arrows indicate direction of the data traffic. Krishnan, Haskin Expires December 1999 [Page 2] Draft draft-krishnan-mpls-fast-reroute-rsvpext-00.txt June 1999 The initial segment of the alternative LSP runs between the destination LSR and the source LSR in the reverse direction of the primary path traversing through every switch between the last hop switch and the source LSR. The dashed line between switches 5 and 1 illustrates such a segment of the alternative path. The second and final segment of the alternative path is set between the source switch and the destination switch along a transmission path disjoint from the primary LSP. The dashed line between Switches 1 and 7 through Switches 2, 4, and 6 illustrates the final segment of the alternative LSP. The initial and final segments of the alternative path are linked to form an entire alternative path from the last hop switch to the destination switch. In Figure 1 the entire alternative path consists of the LSP links labeled 53, 31, 12, 24, 46, and 46 if the alternative path originates at the last hop switch. As soon as a link failure or congestion along the protected path is detected an operational switch at ingress of failed link reroutes incoming traffic around of the failure or congestion by linking upstream portion of the primary path to the downstream portion of the alternative path. Thus if the link between Switches 3 and 5 fails, the primary and alternative paths are linked at Switch 3 forming the following label switched path for the traffic flow: 13->31->12->24->46->67. 3. Extensions to RSVP for Alternate LSP Establishment Clearly, a label-switched path needs to be set up similar to the establishment of the primary LSP. The presence of LABEL-REQ object in the PATH message and LABEL object in the RESV message enables the downstream-on-demand label allocation policy by which the labels are exchanged among the neighbors. As shown in Figure 1, the alternate LSP is composed of two components: the disjoint segment between the source end-point and the destination end-point of the primary LSP (12->24->46-67 in the example) and the segment in the reverse direction between the destination end-point and the source end-point traversing the same network elements as the primary LSP (75->53- >31). 3.1 Establishing the Disjoint Segment of the Alternate LSP. No new RSVP objects are necessary for establishing the disjoint segment of the alternate LSP. Procedures similar to the creation of the primary LSP can be used to establish this disjoint segment. As mentioned earlier, care should be exercised to make sure that this segment of the alternate path is completely disjoint from the primary LSP. For instance, the disjoint segment can be explicitly specified using the Explicit Route Object (ERO) in the PATH message [4]. Krishnan, Haskin Expires December 1999 [Page 3] Draft draft-krishnan-mpls-fast-reroute-rsvpext-00.txt June 1999 3.2 Establishing the Reverse Segment of the Alternate LSP. New RSVP objects are required in the PATH and RESV messages to establish the reverse segment of the alternate LSP. A new Flag option is defined in the Flags field of the SESSION- ATTRIBUTE object that specifies Fast-reroute based on reverse-path setup. Flags 0x08 = Fast reroute based on reverse-path alternate LSP. When this flag is set, all transit LSRs set up an alternate LSP based on the mechanism specified in this document. Two new optional objects are required: a REVERSE-LABEL-REQ object in the RESV message and REVERSE-LABEL object in the PATH message are used for setting up the reverse segment of the alternate LSP. The term REVERSE refers to the establishment of an alternate LSP in the reverse direction of the primary LSP. The function and format of these objects are similar to the LABEL-REQ and the LABEL object used to set-up the primary LSP. When the destination end-point of the primary LSP receives a PATH message consisting of the SESSION-ATTRIBUTE object, it includes the optional REVERSE-LABEL-REQ object in the corresponding RESV message if Fast-reroute is enabled in the SESSION-ATTRIBUTE object. Each LSR in the path of the primary LSP allocates a label for the reverse segment of the alternate LSP and stores the label in the PSB for inclusion in the corresponding PATH message. An LSR that receives a RESV message with the REVERSE-LABEL-REQ object should allocate and include the REVERSE-LABEL object in the corresponding PATH message, unless it is unable to allocate a label in the specified label range in the REVERSE-LABEL-REQ object. In that case, the LSR should send a PATHERR message with the appropriate error codes. REVERSE-LABEL object REVERSE-LABEL Class = [TBD] C-Type = 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length(bytes) | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object contents) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (top label) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Krishnan, Haskin Expires December 1999 [Page 4] Draft draft-krishnan-mpls-fast-reroute-rsvpext-00.txt June 1999 The contents of the REVERSE-LABEL object are a stack of labels, and the top of the stack is in the right four octets of the contents. REVERSE-LABEL-REQ object REVERSE-LABEL-REQ Class = [TBD] C-Type = 1 The format of the REVERSE-LABEL-REQ object is similar to that of the LABEL-REQ object with the exception of the Class number. Three possible C-Types are supported: Label request without a label range, Label request with an ATM label range and a Label request with a Frame Relay label range. The source end-point of the LSP allocates a label in the PATH message for the reverse segment of the alternate LSP, in response to a label request from its downstream neighbor. This label is used as the incoming label in its cross-connect table while the outgoing label used by the source end-point is allocated by its immediate downstream neighbor in the disjoint segment of the alternate LSP. The proposed extensions are backward compatible with those LSRs that do not recognize the optional REVERSE-LABEL_REQ and REVERSE-LABEL objects. 4. References [1] Rosen, E. et al., "Multiprotocol Label Switching Architecture", Internet Draft, draft-ietf-mpls-arch-05.txt, April 1999. [2] Awduche, D. et al., "Requirements for Traffic Engineering over MPLS", Internet Draft, draft-ietf-mpls-traffic-eng-00.txt, October 1998. [3] Haskin, D. et al., öA Method for Setting an Alternate Label- Switched Paths to Handle Fast Re-routeö, work in progress, draft- haskin-fast-reroute-00.txt, May 1999. [4] Awduche, D. et al., öExtensions to RSVP for LSP tunnelsö, work in progress, draft-ietf-mpls-rsvp-lsp-tunnel-01.txt, March 1999. Krishnan, Haskin Expires December 1999 [Page 5] Draft draft-krishnan-mpls-fast-reroute-rsvpext-00.txt June 1999 5. Authors' Addresses Ram Krishnan Nexabit Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 E-mail: ram@nexabit.com Dimitry Haskin Nexabit Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 E-mail: dhaskin@nexabit.com Krishnan, Haskin Expires December 1999 [Page 6]