Request for Comments: 4090 Hammerhead Systems
Category: Standards Track G. Swallow, Ed.
Cisco Systems
A. Atlas, Ed.
Avici Systems
May 2005
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines RSVP-TE extensions to establish backup label-
switched path (LSP) tunnels for local repair of LSP tunnels. These
mechanisms enable the re-direction of traffic onto backup LSP tunnels
in 10s of milliseconds, in the event of a failure.
Two methods are defined here. The one-to-one backup method creates
detour LSPs for each protected LSP at each potential point of local
repair. The facility backup method creates a bypass tunnel to
protect a potential failure point; by taking advantage of MPLS label
stacking, this bypass tunnel can protect a set of LSPs that have
similar backup constraints. Both methods can be used to protect
links and nodes during network failure. The described behavior and
extensions to RSVP allow nodes to implement either method or both and
to interoperate in a mixed network.
Table of Contents
1. Introduction ...................................................3
1.1. Background ...............................................4
2. Terminology ....................................................4
3. Local Repair Techniques ........................................6
3.1. One-to-One Backup ........................................6
3.2. Facility Backup ..........................................7
4. RSVP Extensions ................................................8
4.1. FAST_REROUTE Object ......................................8
4.2. DETOUR Object ...........................................11
4.2.1. DETOUR Object for IPv4 Address ...................11
4.2.2. DETOUR Object for IPv6 Address ...................12
4.3. SESSION_ATTRIBUTE Flags .................................13
4.4. RRO IPv4/IPv6 Sub-object Flags ..........................14
5. Head-End Behavior .............................................15
6. Point of Local Repair (PLR) Behavior ..........................16
6.1. Signaling a Backup Path .................................17
6.1.1. Backup Path Identification: Sender
Template-Specific ................................19
6.1.2. Backup Path Identification: Path-Specific ........19
6.2. Procedures for Backup Path Computation ..................20
6.3. Signaling Backups for One-to-One Protection .............21
6.3.1. Make-before-Break with Detour LSPs ...............22
6.3.2. Message Handling .................................23
6.3.3. Local Reroute of Traffic onto Detour LSP .........23
6.4. Signaling for Facility Protection .......................24
6.4.1. Discovering Downstream Labels ....................24
6.4.2. Procedures for the PLR before Local Repair .......24
6.4.3. Procedures for the PLR during Local Repair .......25
6.4.4. Processing Backup Tunnel’s ERO ...................26
6.5. PLR Procedures during Local Repair ......................26
6.5.1. Notification of Local Repair .....................26
6.5.2. Revertive Behavior ...............................27
7. Merge Node Behavior ...........................................28
7.1. Handling Backup Path Messages before Failure ............28
7.1.1. Merging Backup Paths using the Sender
Template-Specific Method .........................29
7.1.2. Merging Detours using the Path-Specific Method ...29
7.1.3. Message Handling for Merged Detours ..............31
7.2. Handling Failures .......................................31
8. Behavior of All LSRs ..........................................32
8.1. Merging Detours in the Path-Specific Method .............32
9. Security Considerations .......................................33
10. IANA Considerations ...........................................33
11. Contributors ..................................................35
12. Acknowledgments ...............................................36
13. Normative References ..........................................36
1. Introduction
This document extends RSVP [RSVP] to establish backup label-switched
path (LSP) tunnels for the local repair of LSP tunnels. This
extension will meet the needs of real-time applications such as voice
over IP, for which user traffic should be redirected onto backup LSP
tunnels in 10s of milliseconds. This timing requirement can be
satisfied by computing and signaling backup LSP tunnels in advance of
failure and by re-directing traffic as close to the failure point as
possible. In this way, the time for redirection includes no path
computation and no signaling delays, including delays to propagate
failure notification between label-switched routers (LSRs). Speed of
repair is the primary advantage of the methods and extensions
described here. The term local repair is used when referring to
techniques that re-direct traffic to a backup LSP tunnel in response
to a local failure.
A protected LSP is an explicitly-routed LSP that is provided with
protection. The repair methods described here are applicable only to
explicitly-routed LSPs. Application of these methods to LSPs that
dynamically change their routes, such as LSPs used in unicast IGP
routing, is beyond the scope of this document.
Section 2 covers new terminology used in this document. Section 3
describes two basic methods for creating backup LSPs. Section 4
describes the RSVP protocol extensions to support local protection.
Section 5 presents the behavior of an LSR that seeks to request local
protection for an LSP. The behavior of a potential point of local
repair (PLR) is given in Section 6, which describes how to determine
the appropriate strategy for protecting an LSP and how to implement
each of the strategies. Section 7 describes the behavior of a merge
node, the LSR where a protected LSP and its backup LSP rejoin.
Finally, Section 8 discusses the required behavior of other nodes in
the network.
The methods discussed in this document depend upon three assumptions:
o An LSR that is on the path of a protected LSP should always
assume that it is a merge point. This is necessary because
the facility backup method does not signal backups through a
bypass tunnel before failure.
o If the one-to-one backup method is used and a DETOUR object
is included, the LSRs in the traffic-engineered network
should support the DETOUR object. This is necessary so that
the Path message containing the DETOUR object is not
rejected.
o Understanding the DETOUR object is required to support the
path-specific method, which requires that LSRs in the
traffic-engineered network be capable of merging detours.
1.1. Background
Several years before work began on this document, operational
networks had deployed two independent methods of doing fast reroute;
these methods are called here one-to-one backup and facility backup.
Vendors trying to support both methods experienced compatibility
problems in attempting to produce a single implementation capable of
interoperating with both methods. There are technical tradeoffs
between the methods. These tradeoffs are so topologically dependent
that the community has not converged on a single approach.
This document rationalizes the RSVP signaling for both methods so
that any implementation can recognize all fast reroute requests and
clearly respond. The response may be positive if the method can be
performed, or it may be a clear error to inform the requester to seek
alternate backup means. This document also allows a single
implementation to support both methods, thereby providing a range of
capabilities. The described behavior and extensions to RSVP allow
LERs and LSRs to implement either method or both.
While the two methods could in principle be used in a single network,
it is expected that operators will continue to deploy either one or
the other. The goal of this document is to standardize the RSVP
signaling so that a network composed of LSRs that implement both
methods or a network composed of some LSRs that support one method
and others that support both can properly signal among those LSRs to
achieve fast restoration.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC-WORDS].
The reader is assumed to be familiar with the terminology in [RSVP]
and [RSVP-TE].
LSR: Label-Switch Router.
LSP: An MPLS Label-Switched Path. In this document, an LSP will
always be explicitly routed.
Local Repair: Techniques used to repair LSP tunnels quickly when a
node or link along the LSP’s path fails.
PLR: Point of Local Repair. The head-end LSR of a backup tunnel
or a detour LSP.
One-to-One Backup: A local repair method in which a backup LSP is
separately created for each protected LSP at a PLR.
Facility Backup: A local repair method in which a bypass tunnel is
used to protect one or more protected LSPs that traverse the
PLR, the resource being protected, and the Merge Point in
that order.
Protected LSP: An LSP is said to be protected at a given hop if it
has one or multiple associated backup tunnels originating at
that hop.
Detour LSP: The LSP that is used to re-route traffic around a
failure in one-to-one backup.
Bypass Tunnel: An LSP that is used to protect a set of LSPs
passing over a common facility.
Backup Tunnel: The LSP that is used to backup up one of the many
LSPs in many-to-one backup.
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that
bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel
that bypasses a single node of the protected LSP.
Backup Path: The LSP that is responsible for backing up one
protected LSP. A backup path refers to either a detour LSP
or a backup tunnel.
MP: Merge Point. The LSR where one or more backup tunnels rejoin
the path of the protected LSP downstream of the potential
failure. The same LSR may be both an MP and a PLR
simultaneously.
DMP: Detour Merge Point. In the case of one-to-one backup, this
is an LSR where multiple detours converge. Only one detour
is signaled beyond that LSR.
Reroutable LSP: Any LSP for which the head-end LSR requests local
protection. See Section 5 for more detail.
CSPF: Constraint-based Shortest Path First.
SRLG Disjoint: A path is considered to be SRLG disjoint from a
given link or node if the path does not use any links or
nodes which belong to the same SRLG as that given link or
node.
3. Local Repair Techniques
Two different methods for local protection are described. In the
one-to-one backup method, a PLR computes a separate backup LSP,
called a detour LSP, for each LSP that the PLR protects. In the
facility backup method, the PLR creates a single bypass tunnel that
can be used to protect multiple LSPs.
3.1. One-to-One Backup
In the one-to-one backup method, a label-switched path is established
that intersects the original LSP somewhere downstream of the point of
link or node failure. A separate backup LSP is established for each
LSP that is backed up.
[R1]----[R2]----[R3]------[R4]------[R5]
\ \ \ / \ /
[R6]----[R7]----[R8]------[R9]
Protected LSP: [R1->R2->R3->R4->R5]
R1’s Backup: [R1->R6->R7->R8->R3]
R2’s Backup: [R2->R7->R8->R4]
R3’s Backup: [R3->R8->R9->R5]
R4’s Backup: [R4->R9->R5]
Example 1. One-to-One Backup Technique
In the simple topology shown in Example 1, the protected LSP runs
from R1 to R5. R2 can provide user traffic protection by creating a
partial backup LSP that merges with the protected LSP at R4. We
refer to a partial one-to-one backup LSP [R2->R7->R8->R4] as a
detour.
To protect an LSP that traverses N nodes fully, there could be as
many as (N - 1) detours. Example 1 shows the paths for the detours
necessary to protect fully the LSP in the example. To minimize the
number of LSPs in the network, it is desirable to merge a detour back
to its protected LSP, when feasible. When a detour LSP intersects
its protected LSP at an LSR with the same outgoing interface, it will
be merged.
When a failure occurs along the protected LSP, the PLR redirects
traffic onto the local detour. For instance, if the link [R2->R3]
fails in Example 1, R2 will switch traffic received from R1 onto the
protected LSP along link [R2->R7], using the label received when R2
created the detour. When R4 receives traffic with the label provided
for R2’s detour, R4 will switch that traffic onto link [R4-R5], using
the label received from R5 for the protected LSP. At no point does
the depth of the label stack increase as a result of the detour.
While R2 is using its detour, traffic will take the path
[R1->R2->R7->R8->R4->R5].
3.2. Facility Backup
The facility backup method takes advantage of the MPLS label stack.
Instead of creating a separate LSP for every backed-up LSP, a single
LSP is created that serves to back up a set of LSPs. We call such an
LSP tunnel a bypass tunnel.
The bypass tunnel must intersect the path of the original LSP(s)
somewhere downstream of the PLR. Naturally, this constrains the set
of LSPs being backed up via that bypass tunnel to those that pass
through some common downstream node. All LSPs that pass through the
point of local repair and through this common node that do not also
use the facilities involved in the bypass tunnel are candidates for
this set of LSPs.
[R8]
\
[R1]---[R2]----[R3]-----[R4]---[R5]
\ / \
[R6]===[R7] [R9]
Protected LSP 1: [R1->R2->R3->R4->R5]
Protected LSP 2: [R8->R2->R3->R4]
Protected LSP 3: [R2->R3->R4->R9]
Bypass LSP Tunnel: [R2->R6->R7->R4]
Example 2. Facility Backup Technique
In Example 2, R2 has built a bypass tunnel that protects against the
failure of link [R2->R3] and node [R3]. The doubled lines represent
this tunnel. This technique provides a scalability improvement, in
that the same bypass tunnel can also be used to protect LSPs from any
of R1, R2, or R8 to any of R4, R5, or R9. Example 2 describes three
different protected LSPs that are using the same bypass tunnel for
protection.
As with the one-to-one method, there could be as many as (N-1) bypass
tunnels to fully protect an LSP that traverses N nodes. However,
each of those bypass tunnels could protect a set of LSPs.
When a failure occurs along a protected LSP, the PLR redirects
traffic into the appropriate bypass tunnel. For instance, if link
[R2->R3] fails in Example 2, R2 will switch traffic received from R1
on the protected LSP onto link [R2->R6]. The label will be switched
for one which will be understood by R4 to indicate the protected LSP,
and the bypass tunnel’s label will then be pushed onto the label-
stack of the redirected packets. If penultimate-hop-popping is used,
the merge point in Example 2, R4, will receive the redirected packet
with a label indicating the protected LSP that the packet is to
follow. If penultimate-hop-popping is not used, R4 will pop the
bypass tunnel’s label and examine the label underneath to determine
the protected LSP that the packet is to follow. When R2 is using the
bypass tunnel for protected LSP 1, the traffic takes the path
[R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection between
R2 and R4.
4. RSVP Extensions
This specification defines two additional objects, FAST_REROUTE and
DETOUR, to extend RSVP-TE for fast-reroute signaling. These new
objects are backward compatible with LSRs that do not recognize them
(see section 3.10 in [RSVP]). Both objects can only be carried in
RSVP Path messages.
The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to
support bandwidth and node protection features.
4.1. FAST_REROUTE Object
The FAST_REROUTE object is used to control the backup used for the
protected LSP. This specifies the setup and hold priorities, session
attribute filters, and bandwidth to be used for protection. It also
allows a specific local protection method to be requested. This
object MUST only be inserted into the PATH message by the head-end
LER and MUST NOT be changed by downstream LSRs. The FAST_REROUTE
object has the following format:
Class-Num = 205
C-Type = 1
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
| Include-all |
+-------------+-------------+-------------+-------------+
Setup Priority
The priority of the backup path with respect to taking
resources, in the range 0 to 7. The value 0 is the highest
priority. Setup Priority is used in deciding whether this
session can preempt another session. See [RSVP-TE] for the
usage on priority.
Holding Priority
The priority of the backup path with respect to holding
resources, in the range 0 to 7. The value 0 is the highest
priority. Holding Priority is used in deciding whether this
session can be preempted by another session. See [RSVP-TE] for
the usage on priority.
Hop-limit
The maximum number of extra hops the backup path is allowed to
take, from current node (a PLR) to an MP, with PLR and MP
excluded from the count. For example, hop-limit of 0 means
that only direct links between PLR and MP can be considered.
Flags
0x01 One-to-One Backup Desired
Requests protection via the one-to-one backup method.
0x02 Facility Backup Desired
Requests protection via the facility backup method.
Bandwidth
Bandwidth estimate; 32-bit IEEE floating point integer, in
bytes per second.
Exclude-any
A 32-bit vector representing a set of attribute filters
associated with a backup path, any of which renders a link
unacceptable.
Include-any
A 32-bit vector representing a set of attribute filters
associated with a backup path, any of which renders a link
acceptable (with respect to this test). A null set (all bits
set to zero) automatically passes.
Include-all
A 32-bit vector representing a set of attribute filters
associated with a backup path, all of which must be present for
a link to be acceptable (with respect to this test). A null
set (all bits set to zero) automatically passes.
The two high-order bits of the Class-Num (11) cause nodes that do not
understand the object to ignore it and pass it forward unchanged.
For informational purposes, a different C-Type value and format for