Internet Engineering Task Force Dimitry Haskin
Internet Draft Ram Krishnan
Expires: November 2000 Lucent Technologies
May 2000
A Method for Setting an Alternative Label Switched Paths
to Handle Fast Reroute
draft-haskin-mpls-fast-reroute-04.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 reroute of traffic upon a failure in a
primary label switched path in Multi-protocol Label Switching (MPLS)
network.
Haskin, et al. Expires November 2000 [Page 1]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
Table of Contents
1. Introduction.......................................................2
2. Alternative Path Arrangement.......................................3
3. 1:1 protection.....................................................6
4. 1:N protection.....................................................6
5. Restoration Shortcuts..............................................7
6. Elementary link level protection scheme............................8
7. Bandwidth Reservation Considerations...............................8
8. Intellectual Property Considerations...............................9
9. Acknowledgments....................................................9
10. References........................................................9
11. Authors' Addresses................................................9
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 with the objective to provide a single failure protection in such
a manner that facilitates quick restoration comparable to 50
milliseconds provided in SONET self-healing rings and at the same time
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. Both one-to-one (1:1)
protection and many-to-one (1:N) protection can be achieved with the
proposed approach as described in this document.
Haskin, et al. Expires November 2000 [Page 2]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
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.
The fast reroute support can be facilitated with additional extensions
incorporated in the MPLS signaling protocols such as RSVP or CR-LDP.
These extensions are not defined in this document.
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.
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 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.
Haskin, et al. Expires November 2000 [Page 3]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
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 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 along the protected path is detected, an
operational switch at the ingress of the failed link reroutes incoming
traffic around the failure or congestion by redirecting this traffic
into the alternative LSP traversing the switch in the reverse direction
of the primary LSP according to the procedures described in the
following sections of the document.
Haskin, et al. Expires November 2000 [Page 4]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
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.
- Optionally, 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
the primary path and start sending data traffic directly along the
final alternative path segment.
It is fair to note that this 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 be minimal.
The described in-band signaling of an LSP failure to the source
switch does not exclude other methods 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 must 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.
Haskin, et al. Expires November 2000 [Page 5]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
3. 1:1 protection
If the 1:1 path protection is desired, an individual backup LSP is set
for each LSP that needs to be protected as described in section 2. When
a switch detects that a downstream link has failed, it simply splices
the traffic onto the alternative LSP. Referring to Figure 1, if the
link between the Switch 3 and Switch 5 fails, Switch 3 accomplishes the
fast reroute by swapping the incoming MPLS label 13 of the primary path
with the outgoing MPLS label 31 of the alternative path. In this
example 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.
4. 1:N protection
In the case of the 1:N protection a single alternative path can be used
for protection of more than one LSP between the same source and
destination switches. The difference in rerouting LSPs the 1:N
protection case is that, rather than splicing protected traffic into
the alternative LSP, it may be necessary to use the MPLS label stacking
to tunnel protected traffic via the backup LSP to the destination
switch as described below.
A switch detecting failure of a downstream link, first swaps the
incoming MPLS label of each protected LSP with the respective incoming
label that identifies that LSP at the destination switch and then
pushes the outgoing label of the backup LSP to the top of the forwarded
MPLS packets. In essence, the protected MPLS packets are encapsulated
inside of the backup LSP and emerge at the backup tunnel tail at the
egress switch with their respective labels known to that switch.
Referring to Figure 1 and assuming that global label space is used at
the destination switch, if the link between the Switch 3 and Switch 5
fails, Switch 3 swaps incoming MPLS label 13 of the protected LSP with
label 57 (incoming label at Switch 7) and then encapsulates the
resulting packet into the backup tunnel by pushing label 31 to the top
of the forwarded MPLS packets.
Needless to say in order for this scheme to work, each router in the
protected path must be aware what labels are used at the egress LSR for
each protected LSP. Such knowledge can be propagated with the
appropriate extensions incorporated into signaling protocols such as
RSVP or CR-LDP.
A single segment of a tunnel between source and destination switches
can be used to protect multiple LSP segments that originate and
terminate on these switches as long as this segment of the backup
tunnel is completely disjoint from each protected LSP segment except
for the source and destination switches. In such a case the reverse
segments of backup path merge into the disjoint segment of the backup
path at the source switch of the protected LSPs as illustrated in
Haskin, et al. Expires November 2000 [Page 6]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
Figure 2. In Figure 2, dashed lines represent protected LSPs and
double-dashed lines represent backup LSP tunnels.
Figure 2:
+--+ +---+ +--+
| |=======>|LSR|========>|D |
| | +---+ |E |
| | +---+ +---+ |S |
| S|<===| |<===| |<===|T |
| O|--->|LSR|---> LSR|--->|I |
| U| +---+ +---+ |N |
| R| |A |
| C| +---+ +---+ |T |
| E|<===| |<===| |<===|I |
| |--->|LSR|--->|LSR|--->|O |
| | +---+ +---+ |N |
+--+ +--+
5. Restoration Shortcuts
Some types of applications require bounded end-to-end transmission
delays to deliver useful services. A notable example is the Voice over
IP (VoIP) service which requires end-to-end delays that donÆt exceed
400 ms for an acceptable level of service. VoIP is also a prime
candidate for the fast reroute services. Since most of the voice codecs
in use today operate in the range of 20-50 ms latency, the network
component is left with around 300 ms of the end-to-end delay limit.
Given the above considerations, it is important that, when restoration
provisions are made for a delay sensitive service, transmission delays
over an alternative path would not exceed an acceptable limit. Since a
number of the current network providers are capable to guarantee
network transport delay that do not exceed 80 ms on their backbone, it
appears that in some cases it will be possible to use the proposed
restoration technique with a single alternative path. It allows for at
most 200 ms round trip delay over a reverse path segment plus at most
100 ms delay over a disjoint backup path segment. However in other
cases it may be necessary to introduce restoration shortcuts as
described below to satisfy the VoIP latency requirement during
restoration.
Restoration shortcuts are achieved by allowing selected transit routers
in the primary LSP to establish one or more æshortcutÆ alternative LSPs
to the egress router as illustrated in Figure 3. In this illustration,
primary link failures that may occur downstream of LSR B are rerouted
over the shortcut LSP from LSR B to the destination of LSP being backed
up. In illustrated example the shortcut LSP merges into the backup LSP
at LSR D.
Haskin, et al. Expires November 2000 [Page 7]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
Figure 3:
+--+ +---+ +--+
| |------------>|LSR|------------>|D |
| | | D | |E |
| S| +---+ |S |
| O| ^ |T |
| U| | |I |
| R| | |N |
| C| +---+ +---+ +---+ |A |
| E|<---|LSR|<---|LSR|<---|LSR|<---|T |
| |===>| A |===>| B |===>| C |===>|I |
| | +---+ +---+ +---+ |O |
| | |N |
+--+ +--+
6. 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.
7. 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. What we call here 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 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.
Haskin, et al. Expires November 2000 [Page 8]
Internet Draft draft-haskin-mpls-fast-reroute-03.txt May 2000
8. 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.
9. Acknowledgments
This document has benefited from discussions with Jim Boyle, Robert
Boyd, and Alan Hannan. We also thank Ken Schroder and Jeff Parker for
their comments on the document.
10. 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.
11. 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 November 2000 [Page 9]