Internet Draft
Internet Engineering Task Force                          Dimitry Haskin
Internet Draft                                             Ram Krishnan
Expires: June 2000                                  Lucent Technologies

                                                          December 1999


        A Method for Setting an Alternative Label Switched Paths
                         to Handle Fast Reroute

                 draft-haskin-mpls-fast-reroute-02.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 up 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 June 2000                  [Page 1]

Internet Draft  draft-haskin-mpls-fast-reroute-02.txt   December 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 manner 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 resources 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 failure 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 June 2000                  [Page 2]

Internet Draft  draft-haskin-mpls-fast-reroute-02.txt   December 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 :   +--------+        +--------+        +--------+   : 67
     :       /               /                 /      \   :
     :      /               /                 /        \  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 June 2000                  [Page 3]

Internet Draft  draft-haskin-mpls-fast-reroute-02.txt   December 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 67 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 67 if the alternative path originates at the destination switch
of the primary path.

As soon as a failure or congestion along the protected path is detected
an operational switch at ingress of failed link reroutes incoming
traffic around 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 the source switch detects the
     reverse traffic flow, it may stop sending traffic downstream of


Haskin, et al.            Expires June 2000                  [Page 4]

Internet Draft  draft-haskin-mpls-fast-reroute-02.txt   December 1999


     the primary path and start sending data traffic directly along the
     final alternative path segment.

     It is fair to note that 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.

     The described in-band signaling of an LSP failure to the source
     switch does not exclude other method of propagating an error
     condition back to the source.

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 source switch.


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 holding priority of the primary LSP can be
used as traffic-triggered 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 preemption priority assigned to an LSP that is utilized
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 alternative 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


Haskin, et al.            Expires June 2000                  [Page 5]

Internet Draft  draft-haskin-mpls-fast-reroute-02.txt   December 1999


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 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

Lucent Technologies may seek patent or other intellectual property
protection for some or all of the technologies disclosed in this
document. In the event that Lucent Technologies obtains such patent
rights, Lucent Technologies 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, Robert
Boyd, and Alan Hannan.


7. References

[1] Rosen, E. et al., "Multiprotocol Label Switching Architecture",
Internet Draft, draft-ietf-mpls-arch-06.txt, August 1999.

[2] Awduche, D. et al., "Requirements for Traffic Engineering over
MPLS", RFC-2702.


7. Authors' Addresses

Dimitry Haskin
Lucent Technologies
200 Nickerson Road
Marlborough, MA 01752
E-mail: dhaskin@lucent.com

Ram Krishnan
Lucent Technologies
200 Nickerson Road
Marlborough, MA 01752
E-mail: ram64@lucent.com



Haskin, et al.            Expires June 2000                  [Page 6]