WDIFF

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt --> draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

Network Working Group Ping Pan, Ed. (Juniper Networks)

Internet Draft Ping Pan, Ed (Ciena Corp)
Expires: Aug 2003 Der-Hwa Gan (Juniper Networks)
Expiration Date: July 2002
George Swallow (Cisco Systems)
Network Working Group
Jean Philippe Vasseur (Cisco Systems)
Dave Cooper (Global Crossing)
Alia Atlas Atlas, Ed (Avici Systems)
Markus Jork (Avici Systems)

Fast Reroute Extensions to RSVP-TE for LSP Tunnels

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt

draft-ietf-mpls-rsvp-lsp-fastreroute-02.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.

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 defines extensions to and describes the use of RSVP [RSVP, RSVP-TE] to
establish backup LSP 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 presented defined here. One is to setup The one-to-one backup method creates
detour LSPs
according to the requirements defined by the head-end users. The other
is to setup many-to-one bypass for each protected LSP using at each potential point of local
repair. The facility backup method creates a single bypass tunnel to backup
protect a potential failure point; by taking advantage of MPLS label
stacking, this bypass tunnel can protect a set of protected LSPs (making use of label stacking). that

Pan et al. [Page 1]

Internet Draft Aug 2003

have similar backup constraints. Both methods can be used to protect
links and nodes during network failure. The described
use of behavior and
extensions to RSVP allows allow nodes to implement either or both one-to-one methods
and many-to-one backups to
interoperate.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 1] interoperate in a mixed network.

Pan et al. [Page 2]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

1. Aug 2003

Contents

1 Introduction

This document describes the use of ............................................. 4
2 Terminology ............................................... 4
3 Local Repair Techniques ................................... 6
3.1 One-to-one Backup .................................... 6
3.2 Facility Backup ...................................... 7
4 RSVP [RSVP] to establish backup
LSP tunnels Extensions ........................................... 8
4.1 FAST_REROUTE Object .................................... 8
4.2 DETOUR Object .......................................... 11
4.3 SESSION_ATTRIBUTE Flags ................................ 12
4.4 RRO IPv4/IPv6 Sub-Object Flags ......................... 13
5 Head-End Behavior ......................................... 14
6 Point of Local Repair Behavior ............................ 15
6.1 Signaling a Backup Path ................................ 16
6.1.1 Backup Path Identification: Sender-Template Specific . 17
6.1.2 Backup Path Identification: Path-Specific ........... 18
6.2 Procedures for local repair Backup Path Computation ................. 18
6.3 Signaling Backups for One-To-One Protection ............ 20
6.3.1 Make-Before-Break with Detour LSPs .................. 21
6.3.2 Message Handling .................................... 21
6.3.3 Local Reroute of Traffic Onto Detour LSP tunnels. By ............ 22
6.4 Signaling for Facility Protection ...................... 23
6.4.1 Discovering Downstream Labels ....................... 23
6.4.2 Procedures for the term LSP tunnel
we mean an explicitly routed LSP. In this document, we often refer
to LSPs. In all cases we mean explicitly routed LSPs. Applicability PLR before Local Repair .......... 23
6.4.3 Procedures for the PLR during Local Repair .......... 23
6.4.4 Processing backup tunnel's ERO ...................... 24
6.5 PLR Procedures During Local Repair ..................... 25
6.5.1 Notification of local repair ........................ 25
6.5.2 Revertive Behavior .................................. 26
7 Merge Node Behavior ....................................... 27
7.1 Handling Backup Path Messages Before Failure ........... 27
7.1.1 Merging Backup Paths using the techniques discussed herein to LSPs which dynamically change
their routes such as those used Sender-Template
Specific Method ..................................... 28
7.1.2 Merging Detours using Path-Specific Method .......... 28
7.1.2.1 An Example on Path Message Merging ............... 29
7.1.3 Message Handling for Merged Detours ................. 30
7.2 Handling Failures ...................................... 30
8 Behavior of all LSRs ...................................... 31
8.1 Merging Detours in unicast IGP routing is beyond Path-Specific Method ................ 31
9 Security Considerations ................................... 32
10 IANA Guidelines ........................................... 32
11 Intellectual Property Considerations ...................... 32
12 Full Copyright Statement .................................. 32
13 Acknowledgments ........................................... 33
14 Normative References ...................................... 33
15 Author Information ........................................ 33

Pan et al. [Page 3]

Internet Draft Aug 2003

1. Introduction

This document extends RSVP [RSVP] to establish backup LSP tunnels
for the
scope local repair of this document.

In order LSP tunnels. This technique is presented
to meet the needs of real-time applications applications, such as voice over IP,
for which it is highly desirable to be able to re-direct user
traffic onto backup LSP tunnels in 10s of milliseconds. The backup LSPs have
to This
timing requirement can be placed 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, since
reporting possible. In this way, the
time for the redirection does not include any path computation or
signaling delays, including delays to propagate failure
notification between nodes may cost significant delay. LSRs. The speed of repair made possible by
the techniques and extensions described herein is the primary
advantage of this method. We use the term local repair when
referring to techniques which accomplish this, and refer the to an
explicitly routed LSP that which is associated to one or more backup
tunnels provided with such protection as a
protected LSP. There These techniques are applicable only to explicitly
routed LSPs; Application of the techniques discussed herein to LSPs
which dynamically change their routes such as those used in unicast
IGP routing is beyond the scope of this document.

Section 2 covers new terminology used in this document. The two
basic strategies for
setting up creating backup tunnels. These LSPs are one-to-one backup and facility
backup. One-to-one backup operates on described in Section
3. In Section 4, the basis protocol extensions to RSVP to support local
protection are described. In Section 5, the behavior of a backup LSP an LER
which wishes to request local protection for
each protected LSP. an LSP is presented.
The facility backup aims at using behavior of a single LSP
to back up a set potential point of protected LSPs.

1.1. One-to-one backup

In the one to one case, a label switched path local repair (PLR) is established which
intersects given in
Section 6; this describes how to determine the original tunnel somewhere downstream appropriate strategy
to use for protecting an LSP and how to implement each of the point
strategies. The behavior of
link or node failure. For each a merge node, the LSR where a
protected LSP which is backed up, another and its backup LSP rejoin, is established.

[R1]---[R2]-----[R3]----[R4]---[R5]
\ /
[R6]---[R7]

For example, suppose that described in Section 7.
Finally, the simple topology above, R1 creates a
tunnel to R5 via required behavior of other nodes in the path [R1->R2->R3->R4->R5]. R2 can provide user
traffic protection by creating a partial backup tunnel
[R2->R6->R7->R4] which merges with network is
discussed in Section 8.

For the original tunnel
[R1->R2->R3->R4->R5] at R4. We refer a partial one-to-one backup
tunnel [R2->R6->R7->R4] as a detour.

To fully protect a LSP that traverses through N nodes, techniques discussed in this document to function properly,
there could are three assumptions which must be
as many as (N - 1) detours. To minimize processing overhead, it is
desirable to merge detours back to a main LSP wherever possible.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 2]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

1.2. Facility backup

A second means of backing up LSPs made. First, an LSR
which is to take advantage of on the label
stack. Instead path of creating a separate protected LSP for every backed-up LSP, SHOULD always assume that
it is a
single LSP merge point; this is created which serves to necessary because the facility backup up a set of LSPs. We
call such a LSP tunnel
method does not signal backups through a bypass tunnel.

The bypass tunnel must intersect before
failure. Second, if the path of the original LSP(s)
somewhere downstream of the point of local repair. This of course
implies that the set of LSPs being backed up all pass through some
common downstream node. All LSPs which pass through the point of
local repair one-to-one backup method is used and through this common node which do not also use a
DETOUR object is included, the
facilities involved LSRs in the bypass tunnel are candidates for this set
of LSPs.

To effect the repair of the protected LSPs, packets belonging to a
LSP are redirected onto the bypass tunnel. An additional label
representing traffic-engineered
network should support the bypass tunnel DETOUR object; this is stacked onto necessary so that
the redirected
packets. At Path message containing the penultimate hop DETOUR object is not rejected.
Third, understanding of the bypass tunnel, the label for
the bypass tunnel DETOUR object is popped off the stack, revealing required to support
the label path-specific method which
represents the LSP being backed up.

[R8]
\
[R1]---[R2]----[R3]----[R4]---[R5]
\\ // \
[R6]===[R7] [R9]

In the above example, R2 requires that LSRs in this case would build a bypass tunnel
[R2->R6->R7->R4]. the
traffic-engineered network be capable of merging detours.

Pan et al. [Page 4]

Internet Draft Aug 2003

2. Terminology

The doubled lines represent key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this tunnel.
document are to be interpreted as described in RFC2119 [RFC-WORDS].

The
backup path for [R1->R2->R3->R4->R5] again rejoins the original path
at R4, but its path reader is now [R1->R2->R4->R5] assumed to be familiar with the bypass tunnel as
the connection between R2 terminology in [RSVP]
and R4. [RSVP-TE].

LSR - Label Switch Router

LSP - An MPLS Label Switched Path. In this example, the backup tunnel is a Next-Next-Hop (NNHOP) bypass
tunnel. That is, it bypasses a single node (R3) of the protected
path. NNHOP bypass tunnels may protect against Link (R2-R3) failure
and/or Node (R3) failure as NHOP bypass tunnel only protects against
link failure.

The scalability improvement comes in that this bypass tunnel can also
be used to backup LSPs from any of R1, or R2, R8 to any of R4, R5, or
R9 which traverse the link R2->R3.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 3]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

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 document, an LSP - An MPLS Label Switched Path
will always refer to an explicitly routed LSP.

Local Repair - Techniques used to repair LSP tunnels quickly
when a node or link along the LSPs 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 technique where a backup LSP
is separately created for each protected LSP at a PLR.

Facility Backup - A local repair technique where a bypass tunnel
is used to protect one or more protected LSPs which
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
which bypasses a single link of the protected LSP.

NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup
tunnel which bypasses a single node of the protected LSP.

Backup Path - The LSP that is responsible for backing up one

Pan et al. [Page 5]

Internet Draft Aug 2003

protection LSP. A backup path refers to either a detour LSP
or a backup tunnel.

PLR - Point of Local Repair. The head-end of a backup tunnel or
a detour LSP.

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, a Merge Point may
also be
this is an LSR where multiple detours converge and only one
detour is signaled beyond that LSR; this type of merge point
may be referred to as a Detour Merge Point. A MP may also

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 4]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

be a PLR. LSR.

Reroutable LSP - Any LSP for which the head-end LSR requests
for
local protection. See Section 9.1 for more detail.

CSPF - Constraint-based Shortest Path First.

3. RSVP Extensions

We propose two additional objects, FAST_REROUTE and DETOUR, that
extend RSVP-TE for fast-reroute signaling. The new objects are
defined

SRLG Disjoint - A path is considered to be backward compatible for LSRs that do not recognize them
(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 SRLG disjoint from a
given link or node protection features:

In many circumstances, it may be desirable for if the head-end LSR path does not
only use any links or
nodes which belong to signal an LSP the same SRLG as fast reroutable but also to specify to every
PLR along its path that the LSP must be rerouted onto given link or
node.

3. Local Repair Techniques

Two different techniques for local protection are presented here.
The one-to-one backup technique has a PLR compute a separate backup path
offering an equivalent bandwidth.

It may be desirable to signal the need
LSP, called a detour LSP, for the fast reroutable LSP to
be node protected along its path. By node protected we mean that each LSP which the PLR along protects using
this technique. With the path must protect facility backup technique, the reroutable LSP with a detour LSP
or PLR creates
a NNHOP backup single bypass tunnel (except for which can be used to protect multiple LSPs.

3.1. One-to-one backup

In the penultimate hop LSR that
will just require one-to-one technique, a NHOP backup tunnel). This way label switched path is established
which intersects the reroutable original LSP
is being protected against any somewhere downstream of the point
of link or node failure.

3.1. FAST_REROUTE Object

The FAST_REROUTE object carries the control information, such as
setup and hold priorities and bandwidth. A protected For each LSP uses the which is backed up, a
separate backup LSP is established.

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

Pan et al. [Page 6]

Internet Draft Aug 2003

Example 1: One-to-One Backup Technique

In the simple topology shown above in Example 1, the protected LSP
runs from R1 to R5. R2 can provide user traffic protection by
creating a partial backup LSP which 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 fully protect an LSP that traverses N nodes, there could be as
many as (N - 1) detours. The paths for the detours necessary to
fully protect the LSP in Example 1 are given there. 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
taking 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 technique takes advantage of the MPLS label
stack. Instead of creating a separate LSP for every backed-up LSP, a
single LSP is created which serves to backup 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 which pass
through the point of local repair and through this common node
which 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]

Pan et al. [Page 7]

Internet Draft Aug 2003

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 which protects against
the failure of link [R2->R3], link [R3->R4] or node [R3]. The
doubled lines represent this tunnel. The scalability improvement
this technique provides is 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 which are
using the same bypass tunnel for protection.

As with the one-to-one technique, to fully protect an LSP that
traverses N nodes, there could be as many as (N-1) bypass tunnels.
However, each of those bypass tunnels could protected 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 then the bypass tunnel's label will be pushed
onto the label-stack of the redirected packets. If
penultimate-hop-popping is used, then 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, then 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

We propose 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.

Pan et al. [Page 8]

Internet Draft Aug 2003

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, the
session attribute filters, and bandwidth to be used for protection.
It also allows a specific local protection technique 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 = TBD (use form 11bbbbbb for compatibility)
C-Type = 1

Setup Priority

The priority of the backup path with respect to taking
resources, in the range of 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 of 0 to specify 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 level backup path is allowed

Pan et al. [Page 9]

Internet Draft Aug 2003

to take, from current node (a PLR) to a MP, with PLR and MP
excluded in counting. For example, hop-limit of 0 means only
direct links between PLR and MP can be considered.

Flags

0x01 One-to-one Backup Desired

Indicates that protection via the one-to-one backup
technique is desired.

0x02 Facility Backup Desired

Indicates that protection via the facility backup
technique is
required during local repair. desired.

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) indicate that nodes
that do not understand the object should ignore it and pass if
forward unchanged.

For informational purposes, a different C-type value and format for
the FAST_REROUTE object can be are specified below. This is used by

Pan et al. [Page 10]

Internet Draft Aug 2003

existing implementations. The meaning of the fields is the same as
described for
both C-Type 1.

C-Type = 7

4.2. DETOUR Object

The DETOUR object is used in one-to-one and facility backup, and backup to identify detour
LSPs. It has the following format:

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 5]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

Class = TBD (use form 11bbbbbb (to conform 0bbbbbbb format for compatibility)
C-Type = 1 7

Setup Priority

The priority

PLR ID (1 - n)

IPv4 address identifying the beginning point of detour which
is a PLR. Any local address on the backup path with respect to taking resources,
in PLR can be used.

Pan et al. [Page 11]

Internet Draft Aug 2003

Avoid Node ID (1 - n)

IP address identifying the range of 0 immediate downstream node that
the PLR is trying to 7. The value 0 avoid. Router ID of downstream node
is the highest priority.
Setup Priority preferred. This field is mandatory, and is used in deciding whether this session can
preempt another session. See [RSVP-TE] for by
the usage on priority.

Holding Priority

The priority MP for merging rules discussed below.

There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in
a DETOUR object. If detour merging is desired, after each merging
operation, the backup path with respect to holding
resources, Detour Merge Point should combine all the merged
detours in the range of 0 to 7. subsequent Path messages.

The value 0 is high-order bit of the highest
priority. Holding Priority C-Class is used in deciding whether this
session can zero; LSRs that do not support
the DETOUR objects MUST reject any Path message containing a DETOUR
object and send a PathErr to notify the PLR. This PathErr SHOULD
be preempted by another session. See [RSVP-TE] generated as specified in [RSVP] for
the usage on priority.

Hop-limit

The maximum number unknown objects with a
class-num of extra hops the backup path is allowed
to take, from current node (a PLR) to a MP, with PLR form "0bbbbbbb".

4.3. SESSION_ATTRIBUTE Flags

To explicitly request bandwidth and MP
excluded node protection, two new flags
are defined in counting. the SESSION_ATTRIBUTE object.

For example, hop-limit of 0 means only
direct links between PLR both C-Type 1 and MP can be considered.

Flags

0x01 One-to-one Backup Desired

Indicates that 7, the LSP should be protected via SESSION_ATTRIBUTE object currently has
the one-
to-one backup following flags defined:

Local protection desired: 0x01

This flag permits transit routers to use a local repair
mechanism described which may result in Section 5. violation of the explicit route
object. When a fault is detected on an adjacent downstream link
or node, a transit node may reroute traffic for fast service
restoration.

Label recording desired: 0x02

This flag can only indicates that label information should be set by included
when doing a route record.

SE Style desired: 0x04

This flag indicates that the tunnel ingress node may choose to
reroute this tunnel without tearing it down. A tunnel egress
node SHOULD use the SE Style when responding with a Resv
message. When requesting fast reroute, the head-end LSRs.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 6] LSR
SHOULD set this flag; this is not necessary for the
path-specific method of the one-to-one backup technique.

Pan et al. [Page 12]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

0x02 Facility Backup Desired

Indicates that Aug 2003

The following new flags are defined:

Bandwidth protection desired: 0x08

This flag indicates to the PLRs along the protected LSP should path
that a backup path with a bandwidth guarantee is desired.
The bandwidth to be guaranteed is that of the protected via
LSP, if no FAST_REROUTE object is included in the facility
backup mechanism described PATH message;
if a FAST_REROUTE object is in Section 6. the PATH message, then the
bandwidth specified therein is that to be guaranteed.

Node protection desired: 0x10

This flag can
only be set by indicates to the head-end LSRs.

Bandwidth

Bandwidth estimate (32-bit IEEE floating point integer) in
bytes-per-second.

Exclude-any

A 32-bit vector representing PLRs along a set of attribute filters associated
with protected LSP path
that a backup path any of which renders a bypasses at least the next node of
the protected LSP is desired.

4.4. RRO IPv4/IPv6 Sub-Object Flags

To report whether bandwidth and/or node protection are provided as
requested, we define two news flags in the RRO IPv4 sub-object.

RRO IPv4 and IPv6 sub-object address:

These two sub-objects currently have the following flags defined:

Local protection available: 0x01

Indicates that the link unacceptable.

Include-any

A 32-bit vector representing a set downstream of attribute filters associated
with this node is protected
via a backup path any of local repair mechanism, which renders can be either one-to-one
or facility backup.

Local protection in use: 0x02

Indicates that a link acceptable (with
respect local repair mechanism is in use to maintain
this test). A null set (all bits set to zero)
automatically passes.

Include-all

A 32-bit vector representing a set tunnel (usually in the face of attribute filters associated
with a backup path all an outage of which must be present for a the link to be
acceptable (with respect to this test). A null set (all bits set
to zero) automatically passes. it
was previously routed over, or an outage of the neighboring
node).

Two new flags are defined:

Bandwidth protection: 0x04

The C-Class must be assigned in such PLR will set this when the protected LSP has a way that, for backup path
which is guaranteed to provide the LSRs that do
not support desired bandwidth specified
in the FAST_REROUTE objects, they MUST forward object or the objects
downstream unchanged.

Some bandwidth of the existing implementations use the FAST_REROUTE object with
a different C-type value, and slightly different object format (shown
below). For backward compatible purposes, it is documented here for
information purpose.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 7] protected

Pan et al. [Page 13]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

C-Type = 7

3.2. DETOUR Object

The DETOUR Aug 2003

LSP, if no FAST_REROUTE object was included. The PLR may set
this whenever the desired bandwidth is used in one-to-one backup to setup and identify
detour LSPs. It has guaranteed; the following format:

Class = TBD (to conform 0bbbbbbb format for compatibility)
C-Type = 7

0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid Node ID 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
|
MUST set this flag when the desired bandwidth is guaranteed
and the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object. If the requested bandwidth is not
guaranteed, the PLR ID n |
+-------------+-------------+-------------+-------------+
| Avoid MUST NOT set this flag.

Node ID n |
+-------------+-------------+-------------+-------------+ protection: 0x08

The PLR ID (1 - n)

IPv4 address identifying will set this when the beginning point of detour protected LSP has a backup path
which
is provides protection against a PLR. Any local address on failure of the PLR can be used.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 8]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

Avoid Node ID (1 - n)

IP address identifying next LSR
along the immediate downstream protected LSP. The PLR may set this whenever node that
protection is provided by the protected LSP's backup path; the
PLR is trying to avoid. Router ID of downstream MUST set this flag when the node protection is preferred. This field is mandatory, provided
and the "node protection desired" flag was set in the
SESSION_ATTRIBUTE object. If node protection is used by not provided,
the MP for merging rules discussed below.

There PLR MUST NOT set this flag. Thus, if a PLR could only
setup a link-protection backup path, the "Local protection
available" bit will be more than one pair set but the "Node protection" bit will
be cleared.

5. Head-End Behavior

The head-end of (PLR_ID, Avoid_Node_ID) entry an LSP determines whether local protection should
be requested for that LSP and which local protection technique is
desired for the protected LSP. The head-end also determines what
constraints should be requested for the backup paths of a protected
LSP.

To indicate that an LSP should be locally protected, the head-end
LSR MUST either set the "Local protection desired" flag in the
SESSION_ATTRIBUTE object or include a DETOUR FAST_REROUTE object in the
PATH message or both. It is recommended that the "local protection
desired" flag in the SESSION_ATTRIBUTE object always be set. If a
head-end LSR signals a FAST_REROUTE object, it MUST be stored for
Path refreshes.

The head-end LSR of a protected LSP MUST set the "label recording
desired" flag in the SESSION_ATTRIBUTE object. This facilitates
the use of the facility backup technique. If detour merging node protection is
desired, after each merging
operation (Section 5.3), the MP head-end LSR should combine all set the merged detours "node protection desired"
flag in the subsequent Path messages.

The C-Class must SESSION_ATTRIBUTE object; otherwise this flag should be assigned in such a way that, for the LSRs that do
not support the DETOUR objects, the LSRs MUST reject the message and
send
cleared. Similarly, if a PathErr to notify the PLR.

3.3. SESSION_ATTRIBUTE Modification

To explicitly require guarantee of bandwidth and node protection, two new flags
are defined in protection is
desired, then the SESSION_ATTRIBUTE object:

SESSION_ATTRIBUTE

Class = 207
C-Type = 7 (LSP_TUNNEL)

Current Flags:

Local "bandwidth protection desired: 0x01

This desired" flag permits transit routers to use a local repair mechanism
which may result in violation of the explicit route object.
When a fault is detected on an adjacent downstream link or node,
a transit node can reroute traffic for fast service restoration.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 9]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

Label recording desired: 0x02

This flag indicates that label information
SESSION_ATTRIBUTE object should be included
when doing a route record.

SE Style desired: 0x04

This set; otherwise, this flag indicates should
be cleared.

Pan et al. [Page 14]

Internet Draft Aug 2003

If the head-end LSR determines that control of the tunnel ingress node may choose to
reroute this tunnel without tearing it down. A tunnel egress node
SHOULD use backup paths for
the SE Style protected LSP is desired, then the LSR should include the
FAST_REROUTE object. The attribute filters, bandwidth, hop-limit
and priorities will be used by the PLRs when responding with a Resv message.
When requesting fast reroute, determining the backup
paths.

If the head-end LSR MUST set
this flag.

New Flags:

Bandwidth protection desired: 0x08

This flag indicates to the PLRs along desires that the protected LSP path
that a backup path with a bandwidth guarantee is desired.
The bandwidth which must be guaranteed is that of the protected
LSP, if no FAST_REROUTE object is included in via
the PATH message;
if one-to-one backup technique, then head-end LSR should include a
FAST_REROUTE object is in and set the PATH message, then "one-to-one backup desired" flag.
If the
bandwidth specified in there is head-end LSR desires that which must be guaranteed.

Node protection desired: 0x10

This flag indicates to the PLRs along a protected LSP path
that they must select a backup path that bypasses at least be protected via
the
next node of facility backup technique, then the protected LSP.

3.4. RRO Modification

To record bandwidth head-end LSR should include
a FAST_REROUTE object and node protection, we define two news flags in
the RRO IPv4 sub-object.

RRO IPv4 sub-object address:

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 10]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

Type: 0x01 IPv4 address

Current Flags:

Local protection available: 0x01

Indicates that set the link downstream "facility backup desired" flag.
The lack of this node is protected
via a local repair mechanism, which can be either one-to-one FAST_REROUTE object, or facility backup.

Local protection in use: 0x02

Indicates that having both these flags
clear should be treated by PLRs as a local repair mechanism is in use to maintain
this tunnel (usually in the face of an outage of the link it
was previously routed over, or an outage lack of the neighboring
node).

New Flags:

Bandwidth protection: 0x04

The PLR will preference. If
both flags are set this when the a PLR may use either method or both.

The head-end LSR of a protected LSP has a backup
path which provides MUST support the desired bandwidth, which is that additional
flags defined in
the FAST_REROUTE object Section 4.4 being set or clear in the bandwidth RRO IPv4 and
IPv6 sub-objects. The head-end LSR of the a protected LSP,
if no FAST_REROUTE object was included. The PLR may set this
whenever LSP MUST support
the desired bandwidth RRO Label sub-object.

If the head-end LSR of an LSP determines that local protection is guaranteed;
newly desired, this should be signaled via make-before-break.

6. Point of Local Repair Behavior

Every LSR along a protected LSP (except the PLR egress) MUST set follow the
PLR behavior described in this flag when document.

A PLR SHOULD support the desired bandwidth is guaranteed and FAST_REROUTE object, the "local protection
desired", "label recording desired", "node protection desired" and
"bandwidth protection desired" flag was set flags in the SESSION_ATTRIBUTE object.

Node protection: 0x08

When set, this indicates that the PLR has a backup path
providing protection against link
object, and node failure on
the corresponding path section. In case the PLR could only
setup a link-protection backup path, the "Local "local protection

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 11]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

available" bit will be set but the "Node available", "local protection in
use", "bandwidth protection", and "node protection" bit
will be cleared.

3.5. New RRO sub-object: MAX_PROTECTED_BANDWIDTH

This sub-object is carried flags in the
RRO object IPv4 and is optional. An
implementation IPv6 sub-objects. A PLR MAY support it. An LSR MUST ignore and silently
propagate this sub-object, if it is not understood.

RRO MAX_PROTECTED_BANDWIDTH sub-object:

0 1 2 3
+-------------+-------------+-------------+-------------+
| Type | Length | Flags |
+-------------+-------------+-------------+-------------+
| Bandwidth protection ratio |
+-------------+-------------+-------------+-------------+

Type: 0x04

Length: 32

Flags:

No Flags are currently defined

Bandwidth protection ratio

Let's call T the bypass tunnel selected DETOUR
object.

A PLR MUST consider an LSP as having asked for local protection if
the protected
LSP. The bandwidth "local protection ratio desired" flag is set in the sum of
the bandwidths of all SESSION_ATTRIBUTE
object and/or the protected LSPs having selected
T as their bypass tunnel / bandwidth of FAST_REROUTE object is included. If the bypass tunnel T.
The bandwidth protection ratio
FAST_REROUTE object is included, a 32-bit IEEE floating
point integer in bytes-per-second.

The minimum value for PLR SHOULD consider providing
one-to-one protection if the protected ratio is 1, which means "the TE
LSP "one-to-one desired" is bandwidth protected".

Note that set and SHOULD
consider providing facility backup if the PLR must select a "facility backup tunnel in such a way desired"
flag is set when determining whether to provide local protection
and which technique to use to provide that local protection. If
the
bandwidth protected ratio "node protection desired" flag is 1 for set, the TE LSP having required
bandwidth protection in PLR SHOULD try to
provide node protection; if this is not feasible, the SESSION_ATTRIBUTE object of their Path
message

The bandwidth protected ratio may be used for troubleshooting purpose

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 12] PLR SHOULD

Pan et al. [Page 15]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

or Aug 2003

then try to trigger appropriate decision provide link protection. If the head-end LSR (outside "bandwidth protection
guaranteed" flag is set, the
scope of this document).

4. Signaling for Backup Path

A number of objectives must be met PLR SHOULD try to obtain provide a satisfactory signaling
solution. These are summarized as follows:

1. Unambiguously and uniquely identify backup paths
2. Unambiguously associate protected LSPs with their backup paths
3. Work with both global and non-global label spaces
4. Allow for merging of backup paths
5. Maintain RSVP state during and after fail-over.

LSP tunnels are identified by bandwidth
guarantee; if this is not feasible, the PLR SHOULD then try to
provide a combination backup without a guarantee of the SESSION and
SENDER_TEMPLATE objects. full bandwidth.

The relevant fields are as follows.

IPv4 tunnel end point address

IPv4 address of the egress node following treatment for the tunnel.

Tunnel ID

A 16-bit identifier used RRO IPv4 or IPv6 sub-object's flags
must be followed if an RRO is included in the SESSION that remains constant
over protected LSP's RESV
message. Based on this additional information the life of head-end may
take appropriate actions.

- Until a PLR has a backup path available, the tunnel.

Extended Tunnel ID

A 32-bit identifier used PLR MUST clear the
relevant four flags in the SESSION that remains constant
over corresponding RRO IPv4 or IPv6
sub-object.

- Whenever the life of PLR has a backup path available, the tunnel. Normally PLR MUST set to all zeros. Ingress
nodes that wish to narrow the scope of a SESSION to
the
ingress-egress pair may place their IPv4 address here as a
globally unique identifier.

IPv4 tunnel sender address

IPv4 address for a sender node "local protection available" flag. If no established
one-to-one backup LSP ID

A 16-bit identifier used in or bypass tunnel exists, or the SENDER_TEMPLATE one-to-one
LSP and the
FILTER_SPEC that can be changed to allow a sender to share
resources with itself.

The first three of these are bypass tunnel is in "DOWN" state, the SESSION object and are PLR MUST clear
the basic
identification "local protection available" flag in its IPv4 (or IPv6)
address subobject of the tunnel. The last two are in RRO and SHOULD send the

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 13]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

SENDER_TEMPLATE.

In particular, setting updated RESV.

- The PLR MUST clear the "Extended Tunnel ID" to "local protection in use" flag unless it
is actively redirecting traffic into the original IPv4
sender address allows backup path instead of
along the PLR to identify to which protected LSP a
message (from MP) corresponds. For example, when a Resv message
arrives at LSP.

- The PLR SHOULD also set the PLR, "node protection" flag if the Extended Tunnel ID identifies backup
path protects against the original
sender, allowing failure of the immediate downstream
node and, if not, the PLR to identify SHOULD clear the state to "node protection"
flag. This MUST be refreshed.

4.1. Identification and association of backup paths

We propose two different approaches to identify backup paths: done if the "node protection desired" flag
was set in the SESSION_ATTRIBUTE object.

- Path Message Specific: The PLR SHOULD set the "bandwidth protection" if the backup paths use path
offers a bandwidth guarantee and, if not, SHOULD clear the same SESSION and SENDER_TEMPLATE
objects as
"bandwidth protection" flag. This MUST be done if the ones used "bandwidth
protection desired" flag was set in the protected LSP. However, the SESSION_ATTRIBUTE
object.

6.1 Signaling a Backup Path
messages need to provide enough information that allow the LSRs

A number of objectives must be met to differentiate the obtain a satisfactory signaling
solution. These are summarized as follows:

1. Unambiguously and uniquely identify backup paths from the
2. Unambiguously associate protected LSPs.

In case of one-to-one backup, the presence of DETOUR object
in Path messages signifies a LSPs with their backup path, while the presence paths
3. Work with both global and non-global label spaces
4. Allow for merging of
FAST_REROUTE object indicates a protected LSP.

- Sender-Template Specific:

In this approach, the SESSION object backup paths
5. Maintain RSVP state during and the LSP_ID after fail-over.

Pan et al. [Page 16]

Internet Draft Aug 2003

LSP tunnels are copied
from identified by a combination of the protected LSP. SESSION and
SENDER_TEMPLATE objects. The relevant fields are as follows.

IPv4 (or IPv6) tunnel sender end point address is set
to an

IPv4 (or IPv6) address of the PLR node. If the head-end of a tunnel is
also acting as the PLR, it must choose an IP address different
from egress node for the one tunnel.

Tunnel ID

A 16-bit identifier used in the SENDER_TEMPLATE SESSION that remains constant
over the life of the original LSP tunnel.

In the path-message-specific approach, when an LSR receives multiple
Path message which have the same Session and Sender Template objects
and which have

Extended Tunnel ID

A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the same next-hop, SESSION
that LSR must merge remains constant over the Path
messages; without this behavior, life of the multiple RESV messages received
back would not be distinguishable as tunnel. Normally set
to which backup path each
belongs to. This merging behavior does reduce all zeros. Ingress nodes that wish to narrow the total number scope of
RSVP states inside the network. One merging example is given in
Section 5.3.

When using the sender-template-specific approach, the protected LSPs
and the backup paths SHOULD use the Shared Explicit (SE) style. This
allows bandwidth sharing between multiple backup paths. The backup
paths and the protected LSP can be merged by the Merge Points, when
the ERO from the MP a
SESSION to the egress is the same on each LSP to be
merged, ingress-egress pair may place their IP address
here as specified in [RSVP].

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 14]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

5. One-to-one backup protection

In this section, we describe an one-to-one backup method that has a globally unique identifier.

IPv4 (or IPv6) tunnel sender address

IPv4 (or IPv6) address for a sender node

LSP ID

A 16-bit identifier used in the
feature to protect both network links SENDER_TEMPLATE and nodes.

To support the one-to-one backup, the users at head-end LSRs must
specify the backup service requirements for the protected LSPs. The
LSRs must
FILTER_SPEC that can be able changed to interface with CSPF allow a sender to compute share
resources with itself.

The first three of these are in the most suitable
detour route for SESSION object and are the protected LSPs. Upon receiving basic
identification of the local
protection requests for a protected LSP, tunnel. Setting the PLRs must try "Extended Tunnel ID" to
establish the detour LSPs immediately. During network failure,
an IP address of the
PLR must redirect head-end LSR allows the data packets into scope of the detour SESSION
to be narrowed to only LSPs in a timely
fashion.

5.1. Operation Overview

If a one-to-one sent by that LSR. A backup for a protected LSP is explicitly desired, the
head-end LSR SHOULD insert into the Path message a FAST_REROUTE
object, with
considered to be part of the "One-to-one Backup desired" flag set. A one-to-one
backup for a same session as its protected LSP may also LSP;
therefore these three cannot be created based upon a PLR's
local policy if either varied.

The last two are in the "local protection desired" flag is set SENDER_TEMPLATE. Multiple LSPs in the SESSION_ATTRIBUTE object or a FAST_REROUTE object same
SESSION may be protected and take different routes; this is included or
both.

When processed at a PLR, the PLR initiates a detour LSP by sending common
when rerouting a
new Path message tunnel using make-before-break. It is necessary
that contains a DETOUR object. Since an LSP cannot backup path be a clearly identified with its protected LSP, so
that correct merging and state treatment can be done. Therefore, a detour
backup path must inherit its LSP at ID from the associated protected
LSP. Thus, the only field in the same time, any Path message
MUST NOT contain both FAST_REROUTE SESSION and DETOUR objects,

The LSRs that initiate the detour LSPs SHOULD support both
FAST_REROUTE SENDER_TEMPLATE
objects which could be varied between a backup path and DETOUR objects. It is possible that some LSRs along a protected
LSP do not support this standard. If that is the case,
those LSRs will not establish protection for their immediate links or
nodes. Any LSR which does support this standard SHOULD provide
protection.

The LSRs that support "IPv4 (or IPv6) tunnel sender address" in the detour LSPs MUST store all received
FAST_REROUTE and/or DETOUR objects for
SENDER_TEMPLATE.

Pan et al. [Page 17]

Internet Draft Aug 2003

There are two different methods to uniquely identify a backup
path. These are described below.

6.1.1. Backup Path refreshes. The LSRs must
process Identification: Sender-Template-Specific

In this approach, the detour LSPs independent of SESSION object and the protected LSPs to avoid
triggering LSP_ID are copied from
the LSP loop detection procedure described in [RSVP-TE]. protected LSP. The one-to-one backup can use either path-message-specific or sender-
template-specific "IPv4 tunnel sender address" is set to identify an
address of the detour LSPs.

When using PLR. If the sender-template-specific approach, head-end of a tunnel is also acting as
the protected and
detour LSPs should have PLR, it MUST choose an IP address different from the "SE Style desired" bit set one used
in the
SESSION_ATTRIBUTE objects. At SENDER_TEMPLATE of the MP, original LSP tunnel.

When using the detour LSPs merge into sender-template-specific approach, the

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 15]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002 protected
LSPs according to and the merging rules defined for SE style
reservations in [RSVP].

In backup paths SHOULD use the case of one-to-one backup, there is no need for Shared Explicit (SE)
style. This allows bandwidth sharing between multiple backup
paths. The backup paths and the PLRs to
learn about protected LSP MAY be merged by the backup labels used at
Detour Merge Points, when the merging points.

5.2. Procedures for ERO from the PLR

Upon receiving a Path message that contains a FAST_REROUTE object, a
PLR needs MP to run CPSF based on the information provided in the
FAST_REROUTE, as well as egress is the downstream interface and nexthop router
information, to compute a detour route. More details
same on CSPF
computation are described each LSP to be merged, as specified in Section 7.

Once [RSVP-TE].

6.1.2. Backup Path Identification: Path-Specific

In this approach, rather than varying the SESSION or
SENDER_TEMPLATE objects, a detour new object, the DETOUR object, is successfully computed used
to distinguish between PATH messages for a backup path and established, the PLR needs
not to compute
protected LSP.

Thus, the detour routes again, unless (1) backup paths use the contents of
FAST_REROUTE have changed, or (2) same SESSION and SENDER_TEMPLATE
objects as the downstream interface and/or ones used in the
nexthop router for a protected LSP have changed.

After a successful detour computation, the PLR generates a Path
message to setup a detour path. LSP. The Path consists presence of the following:

- A
DETOUR object that specifies in Path messages signifies a backup path; the current PLR ID and
Avoid Node ID. Only one pair
presence of (PLR_ID, Avoid_Node_ID)
permitted.

- An EXPLICIT_ROUTE FAST_REROUTE object toward and/or the egress. The ERO information
comes from "local protection
requested" flag in the CSPF computation.

- The SENDER_TSPEC SESSION_ATTRIBUTE object contains the bandwidth information from indicates a
protected LSP.

In the previously received FAST_REROUTE objects.

- The RSVP_HOP object contains path-message-specific approach, when an LSR receives
multiple Path messages which have the PLR's IP address.

- The detour LSP may generate same SESSION and
SENDER_TEMPLATE objects and process its own RRO object.

- The FAST_REROUTE object MUST NOT be included.

- When using also have the sender-template-specific approach, same next-hop, that LSR
MUST merge the "IPv4
tunnel sender address" in Path messages. Without this behavior, the SENDER_TEMPLATE must multiple
RESV messages received back would not be set to
an address belonging distinguishable as to
which backup path each belongs to. This merging behavior does
reduce the PLR.

- The detour LSPs MUST use total number of RSVP states inside the same reservation style as network at the
protected LSP. This
expense of merging LSPs with different EROs.

6.2 Procedures for Backup Path Computation

Before a PLR can create a detour or a bypass tunnel, the desired
explicit route must be correctly reflected in the
SESSION_ATTRIBUTE object.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 16] determined. This can be done using a CSPF.

Pan et al. [Page 18]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

- All other objects SHOULD be identical to those of Aug 2003

Before CSPF computation, the protected
LSP. following information should be
collected at a PLR:

- The PLR MUST not mix the messages for list of downstream nodes that the protected and LSP passes
through. This information is readily available from the detour
LSPs. When a PLR receives Resv, ResvTear and PathErr messages
RECORD_ROUTE objects during LSP setup. This information is also
available from the downstream detour destination, ERO. However, if the messages MUST ERO contains loose
sub-objects, the ERO may not be forwarded
upstream. Similarly, when a PLR receives ResvErr and ResvConf
messages provide adequate information.

- The downstream links/nodes that we want to protect against. Once
again, this information is learned from a protected LSP, it MUST not propagate them onto the
associated detour LSP.

A session tear-down request RECORD_ROUTE
objects. Whether node protection is desired is normally originated determined by
the sender via
PathTear messages. When a PLR node receives a PathTear message from
upstream, it MUST delete both protected "node protection" flag in the SESSION_ATTRIBUTE object and detour LSPs.
local policy.

- The PathTear
messages MUST propagate to both upstream uni-directional links that the protected and detour LSPs.

During error conditions, LSP
passes through. This information is learned from the LSRs may send ResvTear messages
RECORD_ROUTE objects; it is only needed for setting up
one-to-one protection. In the path-specific method, it is
necessary to fix
problems on avoid the failing path. When a PLR node receives detour and the ResvTear
messages from downstream for a protected LSP, as long as LSP sharing
a detour is
up, common next-hop upstream of the ResvTear messages MUST not sent further upstream.

5.3. Procedures for failure. In the MP using
sender-template-specific mode, this same restriction is
necessary to avoid sharing bandwidth between the Path-Specific Approach

An LSR (that is, a MP) may receive multiple Path messages detour and
its protected LSP, where that bandwidth has only been reserved
once.

- The link attribute filters to be applied. These are derived
from
different interfaces with identical SESSION the FAST_REROUTE object, if included in the PATH message,
and SENDER_TEMPLATE
objects. Path state merging is REQUIRED. the SESSION_ATTRIBUTE object otherwise.

- The merging rule bandwidth to be used is found in the following:

For all Path messages that do not have either FAST_REROUTE object,
if included in the PATH message, and in the SESSION_ATTRIBUTE
object otherwise. Local policy may modify the bandwidth to be
reserved.

- The hop-limit, if a FAST_REROUTE or object was included in the
PATH message.

When applying a
DETOUR object, or CSPF algorithm to compute the backup route, the
following constraints should be satisfied:

- For detour LSPs, the MP is destination MUST be the egress tail-end of the LSP, no merging is
required. The messages are processed according to [RSVP-TE].

Otherwise,
protected LSP; for bypass tunnels (Section 6), the MP destination
MUST record be the Path state as well as their
incoming interface. If address of the Path messages do not share outgoing
interface and next-hop LSR, MP.

- When setting up one-to-one protection using the MP must consider them as independent
LSPs, and must path-specific
method, a detour MUST not merge them.

For all traverse the Path messages that share upstream links of the same outgoing interface and
next-hop LSR,
protected LSP in the MP runs same direction. This prevents the following procedure to select one

Pan et al. [Page 19]

Internet Draft Aug 2003

possibility of early merging of
them as the final detour into the protected
LSP.

1. Eliminate from consideration those that When setting up one-to-one protection using the
sender-template-specific method, a detour should not traverse nodes that other
LSPs want to avoid.

2. If one
the upstream links of the protected LSP is originated from this node, in the same direction;
this must prevents sharing the bandwidth between a protected LSP
and its backup upstream of the failure where the bandwidth
would be used twice in the final LSP. Quit.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 17]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

3. If only one event of a failure.

- The backup LSP contains FAST_REROUTE object, this cannot traverse the downstream node and/or link
whose failure is being protected against. Note that if the
PLR is the penultimate hop, node protection is not possible
and only the downstream link can be avoided. The backup path
may be computed to be SRLG disjoint from the downstream node
and/or link being avoided.

- The backup path must be satisfy the
final resource requirements of the
protected LSP. Quit.

4. If there are several LSPs, This includes the link attribute filters,
bandwidth, and not all of them have a DETOUR
object, then eliminate those with DETOUR hop limits determined from final LSP
considerations.

5. If several candidates remain (that is, there are both detour
and protected LSPs), prefer the ones with FAST_REROUTE
object and SESSION_ATTRIBUTE object.

If none found, prefer such computation succeeds, the ones without DETOUR object. PLR should attempt to establish a
backup path. The PLR may schedule a re-computation at a later time
to discover better paths that may have emerged. If none
found, prefer for any reason,
the ones with DETOUR object.

7. If several candidate LSPs still remain, it PLR is a local decision unable to choose which one will be the final LSP. The decision can
be based on the number of IP hops in ERO, bandwidth requirements,
or others. bring up a backup path, it must schedule a
retry at a later time.

6.3 Signaling Backups for One-To-One Protection

Once the final a PLR has decided to locally protect an LSP with one-to-one
backup, and has been identified, identified the MP MUST only transmit desired path, it takes the
Path messages that are corresponding following
steps to signal the final LSP. Other LSPs are
considered merged at this node. detour.

The MP may receive PathTear messages for some of following describes the merging LSPs.
No PathTear message should transformation to be propagated downstream until performed upon the MP has
received tear-down from all merging LSPs.

When an LSR receives a ResvTear for an LSP and it
protected LSP's PATH message to create the detour LSP's PATH
message.

- If the sender-template specific method is not a PLR for
that LSP, to be used, then the LSR SHOULD propagate
PLR MUST change the ResvTear towards "IPv4 (or IPv6) tunnel sender address" of the
LSP's ingress. For each backup LSP where
SENDER_TEMPLATE to an address belonging to the LSR PLR that is not
the merge node, same as was used for the ResvTear should also be propagated along protected LSP. Additionally, the backup LSP towards
DETOUR object MAY be added to the backup LSP's ingress, a PLR.

5.3.1. An Example on Path Message Merging

Consider PATH message.

- If the following example:

G----H----I--\
| | | \
A----B----C----D----E---F

The protected LSP path-specific method is A-B-C-D-E-F. After running CSPF, let the detour
ERO from B to be B-G-H-I-D-E-F, and used, then the detour ERO from C be C-H-I-E-F.

H will receive Path messages that have PLR MUST add
a DETOUR object to the same SESSION PATH message.

- The SESSION_ATTRIBUTE flags "Local protection desired",
"Bandwidth protection desired" and

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 18] "Node protection desired" MUST

Pan et al. [Page 20]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

SENDER_TEMPLATE from detours for B and C. During merging at H, since
detour C has Aug 2003

be cleared. The "Label recording desired" flag MAY be modified.
If the Path Message contained a shorter ERO path length (that is, ERO is I-E-F, FAST_REROUTE object, and
path length the ERO
is 3), H will select it as not completely strict, the final LSP, Include-any, Exclude-any, and only
propagate its Path messages downstream. Upon receiving a Resv (or a
ResvTear) message, H must relay on
Include-all fields of the messages toward both B and C.

E needs FAST_REROUTE object SHOULD be copied to merge as well, and will select
the main LSP, since it has corresponding fields of the SESSION_ATTRIBUTE object.

- If the protected LSP's Path message contained a FAST_REROUTE
object, this MUST be removed from the detour LSP's PATH message.

- The PLR MUST generate an EXPLICIT_ROUTE object toward the FAST_REROUTE object. Thus, egress.
First, the detour LSP terminates at E.

5.3.2. Creating new DETOUR object at MP

If several LSPs are merged, PLR must remove all sub-objects preceding the MP uses first
address belonging to the following algorithm Merge Point. Then the PLR SHOULD add
sub-objects corresponding to
format its outgoing DETOUR object for the final LSP: desired backup path between the
PLR and the MP.

- If final LSP is protected LSP itself (that is, it contains
FAST_REROUTE object), no DETOUR The SENDER_TSPEC object needed.

- Otherwise, combine all SHOULD contain the (PLR_ID, Avoid_Node_ID) pairs bandwidth information
from
all the DETOUR objects of all merged LSPs, and create a new received FAST_REROUTE object, if included in the
protected LSP's PATH message.

- The RSVP_HOP object
with all listed. Ordering is insignificant.

5.4. Local reroute containing one of the traffic onto the PLR's IP address.

- The detour LSP LSPs MUST use the same reservation style as the
protected LSP. This must be correctly reflected in the
SESSION_ATTRIBUTE object.

Detour LSPs are regular LSPs in operation. They are established as
soon as Once a detour path is
successfully computed and the detour LSP is established, the PLR
need not compute detour routes again, unless (1) the contents of
FAST_REROUTE have changed, or (2) the downstream interface and/or
the nexthop router for a protected LSP have changed. The PLR may
recompute detour routes at any time.

6.3.1 Make-Before-Break with Detour LSPs are up. During local repair, packets

If the sender-template specific method is used, it is possible to
do make-before-break with detour LSPs. This is done by using two
different IP addresses belonging to a the PLR (which were not used in
the SENDER_TEMPLATE of the protected LSP). If the current detour
LSP are simply switched (for example, label
swapping) onto uses the first IP address in its SENDER_TEMPLATE, then the corresponding new
detour LSP. At the Merge Point, LSP should be signaled using the
packets arrived from second IP address in its
SENDER_TEMPLATE. Once the new detour LSP are merged to has been created, the final LSP.

In
current detour LSP can be torn down. By alternating the example above, if there is a node failure at D, C will switch
traffic onto use of
these IP addresses, the pre-established current and new detour LSP (C-H-I-E-F). At E, LSPs will have
different SENDER_TEMPLATES and, thus, different state in the
traffic switches onto
downstream LSRs.

This make-before-break mechanism, changing the protected LSP again.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 19] PLR IP address in

Pan et al. [Page 21]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

6. Facility protection using label stacked bypass tunnel

In this section, we describe a Aug 2003

the DETOUR object instead, is not feasible with the path-specific
method where a single backup tunnel
can be used to protect many LSPs. The LSPs can be protected against
both link because the PATH messages for new and node failures.

Each PLR makes use of one or more NHOP or NNHOP bypass tunnels. Each
bypass tunnel will be used to backup a set of protected LSP. Those
bypass tunnels may be setup initially or current detour LSPs
may also be dynamically
setup. The users at head-end initiate the fast reroute merged if they share a common next-hop.

6.3.2 Message Handling

LSRs must process by
setting the appropriated fields in detour LSPs independent of the SESSION_ATTRIBUTE and/or
FAST_REROUTE objects in an LSP's Path messages. At each PLR, one
bypass tunnel is selected protected LSPs
to reroute an LSP's data packets avoid triggering the LSP loop detection procedure described in case of
network failure.
[RSVP-TE].

The process of selecting PLR MUST not mix the messages for the protected and the detour
LSPs. When a PLR receives Resv, ResvTear and PathErr messages from
the downstream detour destination, the messages MUST not be forwarded
upstream. Similarly, when a bypass tunnel for PLR receives ResvErr and ResvConf
messages from a protected LSP is performed by the PLR when LSP, it MUST not propagate them onto the LSP
associated detour LSP.

A session tear-down request is first setup.

During failure, normally originated by the sender via
PathTear messages. When a PLR reroutes node receives a PathTear message from
upstream, it MUST delete both the data packets of each protected
LSP onto and the bypass tunnel. detour LSPs. The control
PathTear messages of the backed-up
LSPs are also sent over the bypass tunnel. The facility backup uses MUST propagate to both protected and detour LSPs.

During error conditions, the sender-template-specific approach LSRs may send ResvTear messages to identify fix
problems on the backup tunnels.

6.1. Discovering downstream labels failing path. When global labels are in use at MPs, the PLR may learn backup labels
in a very efficient manner. The labels are learned during normal
signaling of PLR node receives the ResvTear
messages from downstream for a protected LSP by observing LSP, as long as a detour is
up, the contents ResvTear messages MUST not be sent further upstream.
PathErrs should be treated similiarly.

6.3.3 Local Reroute of the RRO
object in the Resv message. Traffic onto Detour LSP

When the PLR detects a failure on the protected LSP is first signaled through a PLR, LSP, the PLR can
learn about the incoming labels that are used by all downstream nodes
for this LSP. In particular, it can learn incoming labels used by
downstream MPs, whether they are one hop or multiple hops away from MUST
rapidly switch packets to the PLR. The labels are learned during normal signaling protected LSP's backup LSP instead of
the protected LSP by observing LSP's normal out-segment. The goal of this technique
is to effect the contents redirection within 10s of milliseconds.

L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5
| |
L46 | L47 | L44
R6---------------R7

Protected LSP: [R1->R2->R3->R4->R5]
Detour LSP: [R2->R6->R7->R4]

Example 3: Redirect to Detour

Pan et al. [Page 22]

Internet Draft Aug 2003

In Example 3 above, if the RRO object in the Resv
message.

Two methods are available for discovering/obtaining link [R2->R3] fails, then R2 would do
the following. Any traffic received on link [R1->R2] with label used at
L32 would be sent out link [R2->R6] with label L46 (along the merge node. One relies
detour LSP) instead of out link [R3->R4] with lable L34 (along the
protected LSP). The Merge Point, R4, would recognize that packets
received on explicit signaling over link [R7->R4] with label L44 should be sent out link
[R4->R5] with label L35, and thus merged with the protected LSP.

6.4 Signaling for Facility Protection

A PLR may use one or more bypass
tunnel prior tunnels to any protect against the
failure of the primary path. If the nodes a link and/or a node. These bypass tunnels may be
setup in advance or may be dynamically created as new protected
LSPs are signaled.

6.4.1. Discovering Downstream Labels

To support facility backup, it is necessary for the
network use PLR to
determine a global-to-the-node label space, then which will indicate to the MP that packets
received with that label can should be
discovered by using switched along the RRO object protected
LSP. This can be done without additional signaling.

When this second method is intended, explicitly signaling the backup path
if the MP uses a label space global to that LSR.

As described in Section 5, the head-end router includes an
RRO object and sets LSR MUST set the label-recording-requested "label
recording requested" flag in the
Session_Attribute object. SESSION_ATTRIBUTE object for LSPs
requesting local protection. This will cause (as specified in
[RSVP- TE]) all nodes LSRs to record their INBOUND labels and to note via
a flag

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 20]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002 if the label is global to the node.

Note that LSR. Thus, when global labels are used, no Path a protected
LSP is first signaled through a PLR, the PLR can examine the RRO in
the Resv message need be sent
via and learn about the bypass tunnel prior to failure. incoming labels that are used
by all downstream nodes for this LSP.

When MPs use per-interface-label spaces, the PLR must send Path
messages (for each Reroutable LSP) protected LSP using a bypass tunnel) via the that
bypass tunnel prior to the failure in order to discover the
appropriate MP label. The signaling procedures for this are identical to those in section 6.3
Section 6.4.3 below.

6.2.

6.4.2. Procedures for the PLR before fast-reroute

When a protected LSP in first signaled, all the PLRs along the path Local Repair

A PLR which determine determines to create a backup tunnel via a bypass tunnel should
perform the following:

- If the "Local protection desired" bit is set in the
SESSION_ATTRIBUTE and there is no Fast_Reroute object, or
there is use facility-backup to protect a Fast_Reroute object with the Facility-Backup-Desired
flag set, the PLR given
LSP should select or create a bypass tunnel for
the reroutable LSP.

- If the PLR can find a NNHOP bypass tunnel, the PLR MUST set
the "Node protection" bit and the "Local protection available"
flags of its IPv4 or IPv6 RRO subobject if an RRO object is
included in the Resv message.

- If the PLR cannot find a NNHOP bypass tunnel, but can find
a NHOP bypass tunnel, the PLR must clear the "Node protection"
bit and must set the "local protection available" flags in
the RRO object of the Resv message,

- If the PLR can find a bypass tunnel with bandwidth guarantee,
the PLR must set the "Bandwidth protection" flag in the
above mentioned RRO subobject.

- If the PLR cannot find a bypass tunnel with the requested
bandwidth guarantee, the PLR must clear the "Bandwidth
protection" flag in the above mentioned RRO subobject.

Based on this additional information the head-end may take
appropriate actions.

Note that when global labels are used, no Path message need be sent
via the bypass tunnel prior to failure.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 21] use taking into account
whether node protection is to be provided, what bandwidth was
requested and whether a bandwidth guarantee is desired, and what
link attribute filters were specified in the FAST_REROUTE object.

Pan et al. [Page 23]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

6.3. Aug 2003

The selection of a bypass tunnel for a protected LSP is performed
by the PLR when the LSP is first setup.

6.4.3. Procedures for the PLR during fast-reroute Local Repair

When the PLR detects a link or/and node failure condition, it needs
to reroute the data traffic onto the bypass tunnel and to start
sending the control traffic for the protected LSP onto the bypass
tunnel.

The backup tunnel is identified as follows: using the sender-template-specific
method. The procedures to follow are similar to those described in
Section 6.3.

- The SESSION and SESSION_ATTRIBUTE are is unchanged.

- The SESSION_ATTRIBUTE is unchanged except as follows:
The "Local protection desired", "Bandwidth protection desired",
and "Node protection desired" flags SHOULD be cleared.
The "Label recording desired" MAY be modified.

- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE
is changed
(set set to an address belonging to the PLR). PLR.

- The RSVP_HOP object must MUST contain the IPv4 an IP source address
(and LIH) of
belonging to the bypass tunnel. PLR. Consequently, the MP will send messages
back to the PLR with HOP objects containing this same
IPv4 using as a destination that IP address.

- The PLR must MUST generate an EXPLICIT_ROUTE object toward the
egress. Detailed ERO processing is described below.

- The RRO object may need to be updated, as described below.

Messages sent by in Section
6.5.

The PLR sends Path, PathTear, and ResvConf messages via the backup tunnel include Path, PathTear,
tunnel. The MP sends Resv, ResvTear, and ResvConf. Messages sent PathErr messages by MP via
directly addressing them to the address in the same RSVP_HOP object
contents include Resv, as specified in [RSVP].

If it is necessary to signal the backup prior to failure to
determine the MP label to use, then the same Path message is sent.
In this case, the PLR SHOULD continue to send Path messages for the
protected LSP along the normal route. PathTear messages should be
duplicated, with one sent along the normal route and one sent thru
the bypass tunnel. The MP should duplicate the Resv and ResvTear
messages and sent them to both the PLR and ResvTear.

6.3.1. the LSR indicated by the
protected LSP's RSVP_HOP object.

Pan et al. [Page 24]

Internet Draft Aug 2003

6.4.4. Processing backup tunnel's ERO

Procedures for ERO processing are described in [RSVP-TE]. This
section describes additional ERO update procedures for Path messages
which are sent over bypass tunnels. If normal ERO processing rules are followed by the Merge Point, and the PLR
sends a Path message via the backup tunnel,
were followed, the Merge Point would examine the first sub-object and
likely reject it (Bad initial sub-
object). sub-object). This is because the
unmodified ERO may might contain the IP address of a bypassed node (in
the case of a NNHOP Backup Tunnel), or of an interface which is
currently down (in the case of a NHOP Backup Tunnel). For this
reason, the PLR must update invoke the following ERO procedures before sending a
Path messages onto
Backup Tunnels.

This is done by operating on the original ERO: message via a bypass tunnel.

Sub-objects belonging to abstract nodes which precede the Merge Point
are removed, along with the first Sub-object sub-object belonging to the MP. A

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 22]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

Sub-object
sub-object identifying the Backup Tunnel destination is then added.

More specifically, the PLR must: MUST:

- remove all the sub-objects proceeding the first address belonging
to the MP.

- replace this first MP address with the an IP destination address of the backup tunnel.

The procedure described above ensures successful ERO processing at MP.
(Note that this could be same address that was just removed.)

6.5. PLR Procedures During Local Repair

In addition to the Merge Point.

6.3.2. Processing backup tunnel's RRO technique specific signaling and packet
treatment, there is common signaling which should be followed.

During fast reroute, for each protected LSP containing an RRO
object, the PLR must update obtains the RRO by inserting an IPv4 sub-object with the
IPv4 address of the backup tunnel source address in the Path
messages.

For each rerouted LSP in the backup tunnel, from the protected LSP's stored
RESV. The PLR must MUST update the
RRO object in Resv messages sent upstream in the following manner:

- In the IPv4 or IPv6 sub-object inserted by this node, set the
"Local protection available" and "Local protection in use" flags
according to the current state of the local repair mechanism.

- Update the label sub-object recording the INBOUND label
(same label value as the one sent the Resv message).

6.4. Procedures for state maintenance during fast-reroute

We will describe how state is maintained using an example:

[R8]
\
[R1]---[R2]-X--[R3]----[R4]---[R5]
\\ // \
[R6]===[R7] [R9]

We assume that:

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 23]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

- a bypass tunnel is set up and follows the R2-R6-R7-R4 path;

- PLR (R2) performs 1:N protection;

- various protected LSPs exist and follow the R2-R3-R4 segment;

- link R2-R3 fails, and all protected LSPs are rerouted via
the bypass tunnel.

Note that it inserted
into the same procedure as RRO by setting the one described bellow would apply "Local protection in case use" and "Local
Protection Available" flags.

6.5.1. Notification of a node (R3) failure.

6.4.1. Path state

Path state for every locally repaired LSPs is refreshed downstream by local repair

In many situations, the PLR. These Path messages use route used during a new SENDER_TEMPLATE value (the
IPv4 tunnel sender address Local Repair will be less
than optimal. The purpose of Local Repair is set to a PLR address), keep high priority
and are sent
onto loss sensitive traffic flowing while a more optimal re-routing of
the bypass tunnel with changed PHOP, ERO and RRO.

When a local link fails, there could can be some protected LSPs using
this link. At this point, effected by the LSR MUST NOT remove head-end of the state (Path
and Resv) and send PathTear and ResvErr messages that are
corresponding tunnel. Thus the
head-end needs to these LSPs immediately. We always assume that these
LSPs know of the failure so it may have been repaired upstream, and new Path messages will soon
arrive via re-signal an LSP
which is optimal.

To provide this notification, the bypass tunnels.

However, PLR SHOULD send a Path Error

Pan et al. [Page 25]

Internet Draft Aug 2003

message with error code of "Notify" (Error code =25) and an error
value field of ss00 cccc cccc cccc where ss=00 and the state will sub-code = 3
("Tunnel locally repaired") (see [RSVP-TE])

Additionally a head-end may also detect that an LSP needs to be removed if they have not been refreshed by moved
to a PLR after the soft-state lifetime has expired.

6.4.2. Resv state

Resv state is refreshed by the MP more optimal path by sending Resv messages to noticing failures reported via the IP
destination contained IGP.
Note that in the PHOP object case of inter-area TE LSP (TE LSP spanning areas),
the head-end LSR will need to rely exclusively on Path message received
via Error messages
to be informed of failures in another area.

6.5.2 Revertive Behavior

Upon a failure event, a protected TE LSP is locally repaired by the bypass tunnel.

The PLR receives these Resv messages, refreshes
PLR. There are two basic strategies for restoring the original state
(corresponding TE LSP to a
full working path.

- Global revertive mode: The head-end LSR of each tunnel is
responsible for reoptimizing the protected LSP), and hence continues refreshing TE LSPs that used the state upstream failed
resource. There are several potential reoptimization triggers -
RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and
timers. Note that this re-optimization process may proceed as
soon as the PLR failure is detected. It is not tied to the head-end.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 24]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

6.5. Local reroute
restoration of the traffic onto the bypass tunnel

To perform failed resource.

- Local Repair, packets belonging revertive mode: Upon detecting that the resource is
restored, the PLR re-signals each of TE LSPs that used to a protected be
routed over the restored resource. Every TE LSP successfully
resignaled along the restored resource is switched back.

There are
sent on several circumstances where a local revertive mode might
not be desirable. In the corresponding backup tunnel in case of resource flapping (not an uncommon
failure type), this could generate multiple traffic disruptions.
Therefore, in the local failure.

An additional label (representing revertive mode, the bypass tunnel) is pushed onto PLR should implement a
means to dampen the stack. At re-signaling process in order to limit
potential disruptions due to flapping.

In the penultimate hop of local revertive mode, any TE LSP will be switched back,
without any distinction, as opposed to the bypass tunnel, global revertive mode
where the
additional label decision to reuse the restored resource is popped off taken by the stack. The packet thus arrives at
head-end LSR based on the Merge Point with TE LSP attributes. When the same top-level label it would have carried
when arriving prior to failure (although head-end
learns of the failure, it would have arrived on may reoptimize the protected LSP tunnel
along a different interface prior to failure).

7. Procedures for detour and bypass tunnel computation

To setup more optimal path, because it has a more
complete view of the detours described in Section 5 resources and TE LSP constraints; this means
that the bypass tunnels in
Section 6, CSPF old LSP which has been reverted to may not be used to find the optimal route. Before CSPF
computation, any
longer. Note that in the following information should be collected at a PLR:

- The list case of downstream nodes that inter-area LSP, where the protected TE LSP passes
through. This information
path computation might be done on some Path Computation Server, the
reoptimization process can still be triggered on the Head-End

Pan et al. [Page 26]

Internet Draft Aug 2003

LSP. The local revertive mode is readily available from optional.

However, there are circumstances where the
RECORD_ROUTE objects during Head-end does not have
the ability to reroute the TE LSP setup. Note, a (e.g if the protected LSP's
ERO LSP is
pinned down, as may be desirable if the paths are determined using
an off-line optimization tool) or if Head-end does not provide adequate have the
complete TE topology information since (depending on the LSP could path computation
scenario). In those cases, the local revertive might be a loose routed path.

- The downstream links/nodes that we want to protect against. Once
again, this information
interesting option.

It is learnt from recommended that one always use the RECORD_ROUTE objects.

- The upstream uni-directional links globally revertive mode.
Note that a link or node "failure" may be due to the protected LSP passes
through, this information facility being
permanently taken out of service. Local revertive mode is learnt from
optional. When used in combination, the RECORD_ROUTE
objects. This information global mode may rely
solely on timers to do the reoptimization. When local revertive
mode is only needed for setting up
one-to-one protection in path-message-specific approach.

- The LSP resource information, such as bandwidth. Such information
can be found not used, head-end LSRs SHOULD react to RSVP error messages
and/or IGP indications in the FAST_REROUTE objects.

When applying a CSPF algorithm order to compute the backup route, make a timely response.

Interoperability: If a PLR is configured with the
following constraints should be satisfied:

- The source address of local revertive
mode but the backup LSP MP is not, any attempt from the current PLR,
For setting detours (Section 5), PLR to resignal the destination MUST be TE
LSP over the tail-end of restored resource would fail as the protected LSP, whereas for setting up
bypass tunnels (Section 6), MP will not send
any Resv message. The PLR will still refresh the destination MUST be TE LSP over the address
of
backup tunnel. The TE LSP will not revert to the MP.

- When setting up one-to-one protection using restored resource;
instead it will continue to use the path-specific
approach, backup until it is
re-optimized.

7. Merge Node Behavior

An LSR is a detour MUST not traverse the upstream links of

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 25]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002 Merge Point if it receives the Path message for a
protected LSP in the same direction. This prevents the
possibility of early merging of the detour and one or more messages for a backup LSP which is
merged into the that protected LSP.

- The In the one-to-one backup LSP cannot traverse
technique, the downstream nodes and links LSR is aware that we are trying it is a merge node prior to protect against. However, if
failure. In the PLR
is facility backup technique, the penultimate hop, avoid traversing downstream link only.
The detour LSP/bypass tunnel LSR may also be SRLG disjoint from not know
that it is a Merge Point until a failure occurs and it receives a
backup LSP's Path message. Therefore, an LSR which is on the path
of a protected section (see LSP SHOULD always assume that it is a merge point.

When a MP receives a backup LSP's Path message thru a bypass
tunnel, the note at Send_TTL in the end of this section).

- The backup path must satisfy Common Header may not match the resource requirements TTL of
the
protected LSP.

If such computation succeeds, IP packet within which the PLR should trigger RSVP to
establish a backup path. The PLR may schedule Path message was transported. This
is expected behavior.

7.1. Handling Backup Path Messages Before Failure

There are two circumstances where a re-computation at Merge Point will receive Path
messages for a
later time. The backup path should prior to failure. In the first case, if
a PLR is providing local protection via the one-to-one backup

Pan et al. [Page 27]

Internet Draft Aug 2003

technique, the detour will be as short as possible, signaled and must
merge back into be properly handled
by the protected LSP at its MP. If for any reason, In this case, the
PLR is unable to bring up a backup path, it must schedule a retry at
a later time.

The PLR has the option to apply other constraints during LSP may be signaled via the CSPF
computation. For example, a simple
sender-template-specific method can be or via the path-specific method.

In the second case, if the Merge Point does not provide labels
global to terminate the
computation as soon as MP and record them in a backup path is found. On Label sub-object of the other hand, an
implementation RRO
or if the PLR does not use such recorded information, the PLR may wish
signal the backup path, as described above in Section 6.4.1, to continue exhaustive search
determine the label to discover an
optimal path with lowest cost (or highest available bandwidth).

The PLR also has use if the option PLR is providing protection
according to re-compute the facility backup path
periodically even after technique. In this case, the
backup LSP is up and running to ensure
continuous adaptation to the latest network conditions. However,
during signaled via the replacement sender-template-specific method.

The reception of a functional backup LSP's path with message does not indicate that
a more
optimal one, failure has occured and the incoming protected LSP will no longer
be used.

7.1.1. Merginging Backup Paths using the Sender-Template Specific Method

An LSR may not have any backup path available receive multiple Path messages for a short interval. Except, if the PLR supports both one-to-one
and facility one or more backup schemes,
LSPs and, possibly, the protected LSP. Each of these Path messages
will have a different SENDER_TEMPLATE. The protected LSP could can be protected by
multiple backup LSPs. In this case,
recognized because it will either include the LSP is fully protected at all
time.

Nevertheless, FAST_REROUTE object,
have the exact CSPF algorithms to be used to compute back-up
tunnels "local protection desired" flag set in the
SESSION_ATTRIBUTE object or detour LSPs are beyond both.

If the scope of this document. Both
[OSPF-TE] outgoing interface and [ISIS-TE] may provide more insight on this subject.

Note also that next-hop LSR are the backup tunnel path computation may be performed by
a centralized path computation server or may use some distributed
backup path computation algorithms.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 26]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

7.1. Notion of diverse routing

Two TE LSPs same, then the
Path messages are said link diverse if and only if their paths do not
have any link eligible for merging. Similar to that specified
in common. Two TE LSPs are said node diverse if and [RSVP-TE] for merging of RESV messages, only if their paths do not have any node in common. It those Path messages
whose ERO from that LSR to the egress is
straightforward the same can be merged.
If merging occurs and one of the Path messages merged was for the
protected LSP, then the final Path message to demonstrate that two node diverse paths are also
link diverse.

To be effective a backup tunnel must imperatively sent MUST be diversely routed
from that
of the protected LSP. This merges the backup LSPs into the
protected LSP path section at that LSR. Once the final Path message has been
identified, the MP MUST start to refresh it is protecting. That is, a one-
hop NHOP backup tunnel path must not contain downstream
periodically.

If merging occurs and all the protected link. In Path messages were for backup LSPs,
then the example provided DETOUR object, if any, should be altered as specified in
Section 6, 8.1

7.1.2. Merging Detours using the backup LSP path must not
contain Path-Specific Method

An LSR (that is, an MP) may receive multiple Path messages from
different interfaces with identical SESSION and SENDER_TEMPLATE
objects. In this case, Path state merging is REQUIRED.

Pan et al. [Page 28]

Internet Draft Aug 2003

The merging rule is the R2-R3 link. A NNHOP backup tunnel must following:

For all Path messages that do not contain have either a FAST_REROUTE or a
DETOUR object, or the
protected link nor MP is the PLR's next hop. In egress of the first example provided
in Section 1, LSP, no merging is
required. The messages are processed according to [RSVP-TE].

Otherwise, the backup tunnel must not traverse MP MUST record the R2-R3 link nor Path state as well as their
incoming interface. If the R3 node.

The notion of SRLG diverse path also exists. A set of links
constitute a SRLG ("Shared Risk Link Group") if they Path messages do not share a resource
whose failure may affect outgoing
interface and next-hop LSR, the MP MUST consider them as independent
LSPs, and MUST NOT merge them.

For all the links in Path messages that share the set. So same outgoing interface and
next-hop LSR, the backup
tunnel may be SRLG disjoint from MP runs the protected following procedure to select one of
them as the Path message to forward downstream.

1. Eliminate from consideration those that traverse nodes that
other Path messages want to avoid.

2. If one LSP path section it is
protecting.

Note that in originated from this node, this must be
the case of final LSP. Quit.

3. If only one Path protection, message contains FAST_REROUTE object, this
becomes the whole paths chosen Path message. Quit.

4. If there are several LSPs, and not all of the
protected LSP them have a DETOUR
object, then eliminate those with DETOUR from consideration.

5. If several candidates remain (that is, there are both detour
and protected LSPs), prefer the backup tunnel must be entirely link/node
diverse.

Well-known algorithms can be used to compute link/node/SRLG diversely
routed paths.

8. Network Failure Detection, Notification and Troubleshooting

8.1. Notification of local repair

In many situations, ones with FAST_REROUTE object.

6. If none found, prefer the route used during a Local Repair will be less
than optimal. The point of ones without DETOUR object. If none
found, prefer the Local Repair ones with DETOUR object.

7. If several candidate Path message still remain, it is to keep high priority
and loss sensitive traffic flowing while a more optimal re-routing of local
decision to choose which one will be the tunnel final LSP. The decision
can be effected by based on the head-end number of IP hops in ERO, bandwidth
requirements, or others.

Once the tunnel. Thus final Path message has been identified, the
head-end needs MP MUST start to know of
refresh it downstream periodically. Other LSPs are considered merged
at this node. For bandwidth reservation on the outgoing link, any
merging should be considered to have occured before bandwidth is
reserved. Thus, even though Fixed Filter is specified, multiple
detours and/or their protected LSP which are to be merged due to
sharing an outgoing interface and next-hop LSR will reserve only
the failure so it may re-signal an LSP
which is optimal.

To provide this notification, bandwidth of the PLR SHOULD send a final Path Error message with error code of "Notify" (Error code =25) and an error
value field of ss00 cccc cccc cccc where ss=00 and the sub-code = 3
("Tunnel locally repaired") (see [RSVP-TE])

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 27] on that outgoing
interface.

Pan et al. [Page 29]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

Note also that in the case of inter-area TE LSP (TE LSP spanning
areas), the head-end LSR will exclusively rely Aug 2003

7.1.2.1. An Example on the Path Error
message to be informed Message Merging

R7---R8---R9-\
| | | \
R1---R2---R3---R4---R5---R6

Protected LSP: [R1->R2->R3->R4->R5->R6]
R2's Detour: [R2->R7->R8->R9->R4->R5->R6]
R3's Detour: [R3->R8->R9->R5->R6]

Example 4: Path Message Merging

In Example 4 above, R8 will receive Path messages that have the LSP
same SESSION and SENDER_TEMPLATE from detours for R2 and R3.
During merging at R8 since detour R3 has suffered a failure if the
failure occurs in another area than the area shorter ERO path length
(that is, ERO is [R9->R5->R6], and path length is 3), R8 will
select it belongs to. In the
case of a failure occurring in the head-end area or in as the case of
intra-area TE final LSP, and only propagate its Path messages
downstream. Upon receiving a Resv (or a ResvTear) message, R8 must
relay on the head-end could also detect the TE LSP failure
through the IGP notification.

8.2. Failure detection mechanisms

Link failure detection can be performed through layer-2 failure
detection mechanism. Node failure detection can be done through IGP
loss of adjacency or RSVP hellos messages extensions toward both R2 and R3.

R5 needs to merge as per defined
in [RSVP-TE]. However, well, and will select the main LSP, since it is beyond
has the scope of this document to
define and describe FAST_REROUTE object. Thus, the exact mechanisms on failure detection. detour LSP terminates at
R5.

7.1.3. Message Handling for Merged Detours

When an LSR receives a network failure is detected, ResvTear for an LSP, the PLR MUST immediately switch
traffic from LSR must determine
whether it has an alternate associated LSP. For instance, if the
ResvTear was received for a protected LSP to the LSP, but an associated backup path. At the same time,
the PLR MAY send
LSP has not received a PathErr messages toward ResvTear, then the head-end LSR to notify
the failure condition. The PLR MUST send a RESV with has an updated RRO
which indicates that local protection is in use.

8.3. Troubleshooting of local repair

For troubleshooting purposes, alternate
associated LSP. If the LSR does not have an RRO object may be inserted in alternate associated
LSP, then the
Path message sent by MP MUST propogate the head-end. The previously described
mechanisms do not require ResvTear toward the Path message to carry an RRO object.
On LSP's
ingress and, for each backup LSP merged into that LSP at this LSR,
the other hand, ResvTear SHOULD also be propogated along the RRO object MUST backup LSP.

The MP may receive PathTear messages for some of the merging LSPs.
PathTear messages SHOULD NOT be inserted in propagated downstream until the Resv
message MP
has received PathTear messages for each of the protected LSP if merged LSPs.
However, the "Local protection desired" bit fact that one or more of the SESSION_ATTRIBUTE merged LSPs has been set torn
down should be reflected in the corresponding Path downstream message, or such as by
changing the DETOUR object, if FAST_REROUTE object is present in any.

7.2. Handling Failures

When a downstream LSR detects a local link failure, for any
protected LSPs routed over the failed link, Path messages.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 28] and Resv state

Pan et al. [Page 30]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

9. Interoperability considerations

The following guidelines are useful when running one-to-one and/or
facility backups.

9.1. Requesting local-protection Aug 2003

MUST NOT be cleared and recognizing those requests

The head-end LSR of a protected LSP PathTear and ResvErr messages MUST either set the "Local
protection desired" flag in NOT be
sent immediately; if this is not the SESSION_ATTRIBUTE object, or include case, then the FAST_REROUTE object, or both. A PLR MUST consider that a PATH
message with either facility backup
technique will not work. Further a set "Local protection desired" flag in the
SESSION_ATTRIBUTE object, or the presence of downstream LSR SHOULD reset the FAST_REROUTE object,
or both
refresh timers for these LSPs as if they had just been refreshed.
This is to be a request allow time for local protection.

A PLR SHOULD consider the constraints signaled PLR to begin refreshing state via a received
FAST_REROUTE object, or a received SESSION_ATTRIBUTE object
(Bandwidth and Node protection constraints on the
bypass tunnel can
also tunnel. State MUST be specified by setting the "Bandwidth protection desired" and
"Node protection desired" bits in removed if it has not been refreshed
before the SESSION_ATTRIBUTE object), when
determining refresh timer expires. This allows the facility backup path
technique to use. work without requiring that it signal backup paths
thru the bypass tunnel before failure.

After a failure has occured, the MP must still send Resv messages
for the backup LSPs associated with the protected LSPs which have
failed. If signaled the backup constraints
and bandwidth are desired, LSP was sent through a bypass tunnel, then
the PATH PHOP object in its Path message SHOULD contain will have the
FAST_REROUTE object.

A head-end LSR MUST set IP address of the
associated PLR. This will ensure that Resv state is refreshed.

Once the local link has recovered, the MP may or may not accept
Path messages for existing protected LSPs which had failed over to
their backup.

8. Behavior of all LSRs

The objects defined and the "Label recording desired" flag techniques defined in this document
require behavior from all LSRs in the
SESSION_ATTRIBUTE object traffic-engineered network,
even if a backup tunnel through a bypass tunnel that LSR is desired.

If local protection was not requested for along the current LSP path of a tunnel
and it protected LSP.

First, if a DETOUR object is then desired for that tunnel, included in the head-end LSR MUST send a
new Path backup LSP's path
message reflecting for the change ("Local protection desired"
flag set in sender-template-specific method, the SESSION_ATTRIBUTE object or include a FAST_REROUTE
object). When a node detects a change LSRs in the SESSION_ATTRIBUTE object
it SHOULD forward
traffic-engineered network should support the Path message immediately.

9.2. Backups for local protection

A PLR that recognizes that local protection DETOUR object.

Second, if the Path-Specific Method is required on a
protected LSP MUST try to protect be supported for
the LSP's data path immediately, by
either setting up an one-to-one detour LSP or a bypass tunnel.

When a network has a mix of PLRs that support either one-to-one
backup, or facility backup, or both, backup technique, it is up to necessary that the LSRs in
the traffic-engineered network
operators be capable of merging detours as
specified below in Section 8.1.

It is possible to decide avoid specific LSRs which backup mechanism do not support this
behavior by assigning an link attribute to use.

When using both schemes, all the PLR has links of those
LSPs and then requesting that backup paths exclude that link
attribute.

8.1. Merging Detours in Path-Specific Method

If multiple Path Messages for different detours are received with
the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop
LSR, then the LSR must function as a Detour Merge Point and merge
the detour Path Messages. This merging should occur as specified

Pan et al. [Page 31]

Internet Draft Aug 2003

in Section 7.1.2 and shown in Example 4.

In addition, it is necessary to update the option DETOUR object to backup data

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 29]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

traffic on an one-to-one detour LSP, as well as on a bypass tunnel.
In case of a network failure, reflect
the PLR can re-reroute traffic merging which has taken place. This is done using
one of the two backup path initially. If the backup path failed also, the other backup path can be used
following algorithm to re-reroute user traffic.

If no established detour LSP or backup tunnel exists, or format the detour
LSP and outgoing DETOUR object for the backup tunnel is in "DOWN" state,
final LSP:

- Combine all the PLR MUST clear (PLR_ID, Avoid_Node_ID) pairs from all the
"local protection available" flag in its IPv4 (or IPv6) address
subobject
DETOUR objects of the RRO all merged LSPs, and SHOULD send the updated RESV. When create a detour
LSP or backup tunnel new object with
all listed. Ordering is established, the PLR MUST set the "local
protection available" flag and the appropriated "bandwidth
protection" and "node protection" bits, and SHOULD send the updated
Resv.

10. insignificant.

9. Security Considerations

This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RSVP] remain
relevant.

11.

It should be noted that the facility backup technique requires that
a PLR and its selected Merge Point will trust RSVP messages
received from each other.

10. IANA Guidelines

IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and
DETOUR objects. Currently, in production networks, FAST_REROUTE uses
C-class 205, and DETOUR uses C-class 63.

12.

11. Intellectual Property Considerations

Cisco Systems and Juniper Networks may have intellectual property
rights claimed in regard to some of the specification contained in
this document

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 30]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

13.

12. Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing

Pan et al. [Page 32]

Internet Draft Aug 2003

the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

14.

13. Acknowledgments

We would like to acknowledge the input and helpful comments from Arthi Ayyangar, Riza Cetin, Rob
Goguen, Carol Iturralde, Kireeti Kompella, Manoj Leelanivas, Tony Li, Yakov Rekhter and Nischal Sheth.

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 31]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

15. Curtis Villamizar. Especially,
we thank those, who have been involved in interoperability testing
and field trails, and provided invaluable ideas and suggestions.
They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan,
Richard Southern, and Bijan Jabbari.

14. Normative References

[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
-- version 1 functional specification," RFC2205, September 1997.

[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC3029, December 2001.

[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-
katz-yeung-ospf-traffic-05.txt, June 2001.

[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-tr affic-03.txt, June 2001.

[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434.

16.

15. Author Information

Ping Pan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale,
CIENA Corp.
10480 Ridgeview Court

Pan et al. [Page 33]

Internet Draft Aug 2003

Cupertino, CA 94089 95014
e-mail: pingpan@juniper.net ppan@ciena.net
phone: +1 408 745 3704 366 4991

Der-Hwa Gan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: dhg@juniper.net
phone: +1 408 745 2074

George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
email: swallow@cisco.com
phone: +1 978 244 8143

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 32]

Internet Draft draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt January 2002

Jean Philippe Vasseur
Cisco Systems, Inc.
11, rue Camille Desmoulins
92782 Issy les Moulineaux Cedex 9,
France
300 Apollo Drive
Chelmsford, MA 01824
email: jvasseur@cisco.com jpv@cisco.com
phone: +33 689108267 +1 978 497 6238

Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
email: dcooper@gblx.net
phone: +1 916 415 0437

Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
email: aatlas@avici.com
phone: +1 978 964 2070

Markus Jork
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
email: mjork@avici.com
phone: +1 978 964 2142

draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt ^L[Page 33]

Pan et al. [Page 34]

----