WDIFF

draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt --> rfc4090.txt

Internet Draft Ping

Network Working Group P. Pan, Ed (Ciena Corp)
Expires: February 2005 George Ed.
Request for Comments: 4090 Hammerhead Systems
Category: Standards Track G. Swallow, Ed (Cisco Systems)
Alia Ed.
Cisco Systems
A. Atlas, Ed (Avici Systems) Ed.
Avici Systems
May 2005

Fast Reroute Extensions to RSVP-TE for LSP Tunnels

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

Status of this This Memo

This document is specifies an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six months the "Internet
Official Protocol Standards" (STD 1) for the standardization state
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 status of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list this protocol. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. this memo is unlimited.

Abstract

This document defines RSVP-TE extensions to and describes the use of RSVP to establish backup label-switched 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 milliseconds, in the event of a failure.

Two methods are defined here. The one-to-one backup method creates
detour LSPs for each protected LSP at each potential point of local
repair. The facility backup method creates a bypass tunnel to
protect a potential failure point; by taking advantage of MPLS label
stacking, this bypass tunnel can protect a set of protected LSPs that have
similar backup constraints. Both methods can be used to protect
links and nodes during network failure. The described behavior and
extensions to RSVP allow nodes to implement either method or both methods and
to interoperate in a mixed network.

Pan

Pan, et al. Standards Track [Page 1]

Internet Draft February

RFC 4090 RSVP-TE Fast Reroute May 2005

Table of Contents

1 Authors .................................................. 3
2

1. Introduction ............................................. 3
2.1 ...................................................3
1.1. Background ........................................... 4
3 ...............................................4
2. Terminology ............................................... 5
4 ....................................................4
3. Local Repair Techniques ................................... 7
4.1 One-to-one ........................................6
3.1. One-to-One Backup ..................................... 7
4.2 ........................................6
3.2. Facility Backup ....................................... 8
5 ..........................................7
4. RSVP Extensions ........................................... 9
5.1 ................................................8
4.1. FAST_REROUTE Object ................................... 9
5.2 ......................................8
4.2. DETOUR Object ......................................... 12
5.2.1 ...........................................11
4.2.1. DETOUR object Object for IPv4 address .................... 12
5.2.2 Address ...................11
4.2.2. DETOUR object Object for IPv6 address .................... 13
5.3 Address ...................12
4.3. SESSION_ATTRIBUTE Flags ............................... 14
5.4 .................................13
4.4. RRO IPv4/IPv6 Sub-Object Sub-object Flags ........................ 15
6 ..........................14
5. Head-End Behavior ......................................... 16
7 .............................................15
6. Point of Local Repair (PLR) Behavior ............................ 17
7.1 ..........................16
6.1. Signaling a Backup Path ............................... 18
7.1.1 .................................17
6.1.1. Backup Path Identification: Sender-Template Specific 19
7.1.2 Sender
Template-Specific ................................19
6.1.2. Backup Path Identification: Path-Specific ......... 20
7.2 ........19
6.2. Procedures for Backup Path Computation ................ 20
7.3 ..................20
6.3. Signaling Backups for One-To-One One-to-One Protection ........... 22
7.3.1 Make-Before-Break .............21
6.3.1. Make-before-Break with Detour LSPs ................ 23
7.3.2 ...............22
6.3.2. Message Handling .................................. 23
7.3.3 .................................23
6.3.3. Local Reroute of Traffic Onto onto Detour LSP ........... 24
7.4 .........23
6.4. Signaling for Facility Protection ..................... 25
7.4.1 .......................24
6.4.1. Discovering Downstream Labels ..................... 25
7.4.2 ....................24
6.4.2. Procedures for the PLR before Local Repair ........ 25
7.4.3 .......24
6.4.3. Procedures for the PLR during Local Repair ........ 25
7.4.4 .......25
6.4.4. Processing backup tunnel's Backup Tunnel's ERO .................... 26
7.5 ...................26
6.5. PLR Procedures During during Local Repair ..................... 27
7.5.1 ......................26
6.5.1. Notification of local repair ...................... 27
7.5.2 Local Repair .....................26
6.5.2. Revertive Behavior ................................ 28
8 ...............................27
7. Merge Node Behavior ....................................... 29
8.1 ...........................................28
7.1. Handling Backup Path Messages Before before Failure .......... 29
8.1.1 ............28
7.1.1. Merging Backup Paths using the Sender-Template
Specific Sender
Template-Specific Method ................................... 30
8.1.2 .........................29
7.1.2. Merging Detours using the Path-Specific Method ........ 30
8.1.2.1 An Example on Path Message Merging ............ 31
8.1.3 ...29
7.1.3. Message Handling for Merged Detours ............... 32
8.2 ..............31
7.2. Handling Failures ..................................... 32
9 .......................................31
8. Behavior of all All LSRs ...................................... 33
9.1 ..........................................32
8.1. Merging Detours in the Path-Specific Method ............... 33
10 .............32
9. Security Considerations ................................... 34
11 .......................................33
10. IANA Guidelines ........................................... 34
12 Intellectual Property Considerations ...................... 34
13 Full Copyright Statement .................................. 35

Pan ...........................................33
11. Contributors ..................................................35
12. Acknowledgments ...............................................36
13. Normative References ..........................................36

Pan, et al. Standards Track [Page 2]

Internet Draft February

RFC 4090 RSVP-TE Fast Reroute May 2005

14 Acknowledgments ........................................... 35
15 Normative References ...................................... 36
16 Editor Information ........................................ 36

1. Authors

This document was written by George Swallow, Ping Pan, Alia Atlas,
Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.

Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
email: jpv@cisco.com
phone: +1 978 497 6238

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

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

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

2. Introduction Introduction

This document extends RSVP [RSVP] to establish backup LSP label-switched
path (LSP) tunnels for the local repair of LSP tunnels. This technique is presented
to
extension will 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

Pan et al. [Page 3]

Internet Draft February 2005 traffic should be redirected onto backup LSP
tunnels in 10s of milliseconds. This timing requirement can be
satisfied by computing and signaling backup LSP tunnels in advance of
failure and by re-directing traffic as close to the failure point as
possible. In this way, the time for the redirection does not include any includes no path
computation or and no signaling delays, including delays to propagate
failure notification between LSRs. The speed label-switched routers (LSRs). Speed of
repair made possible by
the techniques and extensions described herein is the primary advantage of this method. We use the methods and extensions
described here. The term local repair is used when referring to
techniques which accomplish this, and refer that re-direct traffic to a backup LSP tunnel in response
to a local failure.

A protected LSP is an
explicitly routed explicitly-routed LSP which that is provided with such protection as a
protected LSP. These techniques
protection. The repair methods described here are applicable only to explicitly
routed LSPs;
explicitly-routed LSPs. Application of the techniques discussed herein these methods to LSPs
which that
dynamically change their routes routes, such as those LSPs used in unicast IGP routing
routing, is beyond the scope of this document.

Section 3 2 covers new terminology used in this document. The Section 3
describes two basic strategies methods for creating backup LSPs are described in Section
4. In LSPs. Section 5, 4
describes the RSVP protocol extensions to RSVP to support local
protection are described. In protection.
Section 6, 5 presents the behavior of an LER
which wishes LSR that seeks to request local
protection for an LSP is presented. LSP. The behavior of a potential point of local
repair (PLR) is given in Section 7; this 6, which describes how to determine
the appropriate strategy
to use for protecting an LSP and how to implement
each of the strategies. The Section 7 describes the behavior of a merge
node, the LSR where a protected LSP and its backup LSP rejoin, is described in Section 8. rejoin.
Finally, Section 8 discusses the required behavior of other nodes in
the network is
discussed in Section 9.

For the techniques network.

The methods discussed in this document to function properly,
there are depend upon three assumptions which must be made. First, an assumptions:

o An LSR
which that is on the path of a protected LSP SHOULD should always
assume that it is a merge point; this point. This is necessary because
the facility backup method does not signal backups through a
bypass tunnel before failure. Second, if

o If the one-to-one backup method is used and a DETOUR object
is included, the LSRs in the traffic-engineered network
should support the DETOUR object; this object. This is necessary so that
the Path message containing the DETOUR object is not
rejected.
Third, understanding of the DETOUR object is required to support

Pan, et al. Standards Track [Page 3]

RFC 4090 RSVP-TE Fast Reroute May 2005

o Understanding the DETOUR object is required to support the
path-specific method method, which requires that LSRs in the
traffic-engineered network be capable of merging detours.

2.1

1.1. Background

Several years before work began on this draft, document, operational
networks had deployed two independent methods of doing fast reroute, reroute;
these methods are called
herein here one-to-one backup and facility backup.
Vendors trying to support both methods were experiencing incompatiblity experienced compatibility
problems in

Pan et al. [Page 4]

Internet Draft February 2005 attempting to produce a single implementation capable of
interoperating with both. both methods. There are technical tradeoffs
between the methods. However these These tradeoffs are so topologically
dependent, dependent
that the community has not converged on a single approach.

This draft document rationalizes the RSVP signaling for both methods such so
that any implementation can recognize all FRR fast reroute requests and
clearly
respond, either positively respond. The response may be positive if they are capable of performing the
method, method can be
performed, or with it may be a clear error such that to inform the requester is informed and
can to seek
alternate means of backup. backup means. This draft document also allows a single
implementation to support both methods, thereby providing a range of
capabilities. Thus the The described behavior and extensions to RSVP allow
LERs and LSRs to implement either method or both methods. both.

While the two methods could in principle be used in a single network,
it is expected that operators will continue to choose to deploy either one or
the other. The goal of this draft document is to standardize the RSVP
signaling such so that either a network with composed of LSRs that implement both
methods or an a network composed of some LSRs that support one method
and others that support both, both can properly signal among those LSRs to
achieve fast restoration through the
chosen method.

3. restoration.

2. Terminology

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

The reader is assumed to be familiar with the terminology in [RSVP]
and [RSVP-TE].

LSR - Label Switch Router

LSP -

LSR: Label-Switch Router.

LSP: An MPLS Label Switched Label-Switched Path. In this document, an LSP will
always refer to an be explicitly routed LSP. routed.

Local Repair - Repair: Techniques used to repair LSP tunnels quickly when a
node or link along the LSPs LSP's path fails.

PLR -

Pan, et al. Standards Track [Page 4]

RFC 4090 RSVP-TE Fast Reroute May 2005

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

One-to-one Backup -

One-to-One Backup: A local repair technique where method in which a backup LSP is
separately created for each protected LSP at a PLR.

Pan et al. [Page 5]

Internet Draft February 2005

Facility Backup - Backup: A local repair technique where method in which a bypass tunnel is
used to protect one or more protected LSPs which that traverse the
PLR, the resource being protected protected, and the Merge Point in
that order.

Protected LSP - 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 - LSP: The LSP that is used to re-route traffic around a
failure in one-to-one backup.

Bypass Tunnel - Tunnel: An LSP that is used to protect a set of LSPs
passing over a common facility.

Backup Tunnel - Tunnel: The LSP that is used to backup up one of the many
LSPs in many-to-one backup.

NHOP Bypass Tunnel - Tunnel: Next-Hop Bypass Tunnel. A backup tunnel
which that
bypasses a single link of the protected LSP.

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

Backup Path - Path: The LSP that is responsible for backing up one
protection
protected LSP. A backup path refers to either a detour LSP
or a backup tunnel.

MP -

MP: Merge Point. The LSR where one or more backup tunnels rejoin
the path of the protected LSP, LSP downstream of the potential
failure. The same LSR may be both an MP and a PLR
simultaneously.

DMP -

DMP: Detour Merge Point. In the case of one-to-one backup, this
is an LSR where multiple detours converge and only converge. Only one detour
is signaled beyond that LSR.

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

CSPF -

CSPF: Constraint-based Shortest Path First.

Pan, et al. Standards Track [Page 5]

RFC 4090 RSVP-TE Fast Reroute May 2005

SRLG Disjoint - Disjoint: A path is considered to be SRLG disjoint from a
given link or node if the path does not use any links or
nodes which belong to the same SRLG as that given link or
node.

Pan et al. [Page 6]

Internet Draft February 2005

3. Local Repair Techniques

Two different techniques methods for local protection are presented here.
The described. In the
one-to-one backup technique has method, a PLR compute computes a separate backup LSP,
called a detour LSP, for each LSP which that the PLR protects using
this technique. With protects. In the
facility backup technique, method, the PLR creates a single bypass tunnel which that
can be used to protect multiple LSPs.

4.1. One-to-one backup

3.1. One-to-One Backup

In the one-to-one technique, backup method, a label switched label-switched path is established
which
that intersects the original LSP somewhere downstream of the point of
link or node failure. For each LSP which is backed up, a A separate backup LSP is established.

[R1]---[R2]-----[R3]----[R4]---[R5] established for each
LSP that is backed up.

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

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

Example 1: 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 that merges with the protected LSP at R4. We
refer to a partial one-to-one backup LSP [R2->R7->R8->R4] as a
detour.

To fully protect an LSP that traverses N nodes, nodes fully, there could be as
many as (N - 1) detours. The Example 1 shows the paths for the detours
necessary to
fully protect fully the LSP in Example 1 are given there. the example. To minimize the
number of LSPs in the network, it is desirable to merge a detour back
to its protected LSP LSP, when feasible. When a detour LSP intersects
its protected LSP at an LSR with the same outgoing interface, it will
be merged.

Pan, et al. Standards Track [Page 6]

RFC 4090 RSVP-TE Fast Reroute May 2005

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

Pan et al. [Page 7]

Internet Draft February 2005

[R4-R5] [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].

4.2.

3.2. Facility backup Backup

The facility backup technique method takes advantage of the MPLS label stack.
Instead of creating a separate LSP for every backed-up LSP, a single
LSP is created which that serves to backup back up a set of LSPs. We call such an
LSP tunnel a bypass tunnel.

The bypass tunnel must intersect the path of the original LSP(s)
somewhere downstream of the PLR. Naturally, this constrains the set
of LSPs being backed-up backed up via that bypass tunnel to those that pass
through some common downstream node. All LSPs which that pass through the
point of local repair and through this common node
which that do not also
use the facilities involved in the bypass tunnel are candidates for
this set of LSPs.

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

Protected LSP 1: [R1->R2->R3->R4->R5]
Protected LSP 2: [R8->R2->R3->R4]
Protected LSP 3: [R2->R3->R4->R9]
Bypass LSP Tunnel: [R2->R6->R7->R4]

Example 2: 2. Facility Backup Technique

In Example 2, R2 has built a bypass tunnel which that protects against the
failure of link [R2->R3] and node [R3]. The doubled lines represent
this tunnel. The scalability improvement this This technique provides is a scalability improvement, in
that the same bypass tunnel can also be used to protect LSPs from any
of R1, R2 R2, or R8 to any of R4, R5 R5, or R9. Example 2 describes three
different protected LSPs which that are using the same bypass tunnel for
protection.

Pan, et al. Standards Track [Page 7]

RFC 4090 RSVP-TE Fast Reroute May 2005

As with the one-to-one technique, to fully protect an LSP that
traverses N nodes, method, there could be as many as (N-1) bypass tunnels.
tunnels to fully protect an LSP that traverses N nodes. However,
each of those bypass tunnels could protected protect a set of LSPs.

When a failure occurs along a protected LSP, the PLR redirects

Pan et al. [Page 8]

Internet Draft February 2005
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 [R2->R6]. The label will be switched
for one which will be understood by R4 to indicate the protected LSP LSP,
and then the bypass tunnel's label will then be pushed onto the label-stack 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

This specification defines two additional objects, FAST_REROUTE and
DETOUR, to extend RSVP-TE for fast-reroute signaling. These new
objects are backward compatible with LSRs that do not recognize them
(see section 3.10 in [RSVP]). Both objects can only be carried in
RSVP Path messages.

The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to
support bandwidth and node protection features.

5.1.

4.1. FAST_REROUTE Object

The FAST-REROUTE 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 method to be requested. This
object MUST only be inserted into the PATH message by the head-end
LER and MUST NOT be changed by downstream LSRs. The
FAST-REROUTE FAST_REROUTE
object has the following format:

Pan

Pan, et al. Standards Track [Page 9]

Internet Draft February 8]

RFC 4090 RSVP-TE Fast Reroute May 2005

Class-Num = 205
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 7. The value 0 is the highest
priority. Holding Priority is used in deciding whether this
session can be preempted by another session. See [RSVP-TE] for
the usage on priority.

Hop-limit

The maximum number of extra hops the backup path is allowed to
take, from current node (a PLR) to a an MP, with PLR and MP
excluded in counting. from the count. For example, hop-limit of 0 means
that only direct links between PLR and MP can be considered.

Flags

0x01 One-to-one One-to-One Backup Desired

Indicates that

Requests protection via the one-to-one backup
technique is desired.

Pan method.

Pan, et al. Standards Track [Page 10]

Internet Draft February 9]

RFC 4090 RSVP-TE Fast Reroute May 2005

0x02 Facility Backup Desired

Indicates that

Requests protection via the facility backup
technique is desired. method.

Bandwidth

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

Exclude-any

A 32-bit vector representing a set of attribute filters
associated with a backup path 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 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 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 cause nodes that do not
understand the object should to ignore it and pass if it forward unchanged.

For informational purposes, a different C-type C-Type value and format for
the FAST_REROUTE object are specified below. This is used by legacy
implementations. The meaning of the fields is the same as that
described for C-Type 1.

Pan

Pan, et al. Standards Track [Page 11]

Internet Draft February 10]

RFC 4090 RSVP-TE Fast Reroute May 2005

Class-Num = 205
C-Type = 7

Unknown C-types C-Types should be treated as specified in [RSVP] Section
3.10.

5.2.

4.2. DETOUR Object

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

Class-Num = 63

5.2.1

4.2.1. DETOUR object Object for IPv4 address Address

Class-Num = 63
C-Type = 7

PLR ID

PLR_ID (1 - n)

Pan et al. [Page 12]

Internet Draft February 2005

IPv4 address identifying the PLR that is the beginning point of detour which is
a PLR.
the detour. Any local address on the PLR can be used.

Avoid Node ID

Pan, et al. Standards Track [Page 11]

RFC 4090 RSVP-TE Fast Reroute May 2005

Avoid_Node_ID (1 - n)

IPv4 address identifying the immediate downstream node that the
PLR is trying to avoid. Any local address of the downstream
node can be used. This field is mandatory, mandatory and is used by the
MP for the merging rules discussed below.

5.2.2

4.2.2. DETOUR object Object for IPv6 address Address

Class-Num = 63
C-Type = 8

0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR ID PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| PLR ID PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR ID PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR ID PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid Node ID Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid Node ID Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid Node ID Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid Node ID Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+

PLR ID

PLR_ID (1 - n)

An IPv6 128-bit unicast host address identifying the PLR that
is the beginning point of detour which is a PLR. the detour. Any local address on the
PLR can be used.

Avoid Node ID

Avoid_Node_ID (1 - n)

An IPv6 128-bit unicast host address identifying the immediate

Pan et al. [Page 13]

Internet Draft February 2005
downstream node that the PLR is trying to avoid. Any local
address on the downstream node can be used. This field is
mandatory,

Pan, et al. Standards Track [Page 12]

RFC 4090 RSVP-TE Fast Reroute May 2005

mandatory and is used by the MP for the 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 Detour Merge Point should combine all the merged
detours in the subsequent Path messages.

The high-order bit of the C-Class Class-Num is 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
generated as specified in [RSVP] for unknown objects with a
class-num Class-Num
of the form "0bbbbbbb".

Unknown C-types C-Types should be treated as specified in [RSVP] Section
3.10.

5.3.

4.3. SESSION_ATTRIBUTE Flags

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

For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has
the following flags defined: defined [RSVP-TE]:

Local protection desired: 0x01

This flag permits transit routers to use a local repair
mechanism which that may result in 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 indicates that label information should be 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 LSR SHOULD
set this flag; this is not necessary for the path-specific
method of the one-to-one backup technique.

Pan method.

Pan, et al. Standards Track [Page 14]

Internet Draft February 13]

RFC 4090 RSVP-TE Fast Reroute May 2005

The following new flags are defined:

Bandwidth protection desired: 0x08

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

Node protection desired: 0x10

This flag indicates to the PLRs along a protected LSP path that
a backup path which that bypasses at least the next node of the
protected LSP is desired.

5.4.

4.4. RRO IPv4/IPv6 Sub-Object Sub-object Flags

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

The RRO IPv4 and IPv6 sub-object address:

These two address sub-objects currently have the
following flags defined: defined [RSVP-TE]:

Local protection available: 0x01

Indicates that the link downstream of this node is protected
via a local repair mechanism, which can be either one-to-one or
facility backup.

Local protection in use: 0x02

Indicates that 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 of the neighboring
node).

Two new flags are defined:

Bandwidth protection: 0x04

The PLR will set this bit when the protected LSP has a backup
path
which that is guaranteed to provide the desired bandwidth that
is specified in the FAST_REROUTE object or the bandwidth of the
protected

Pan et al. [Page 15]

Internet Draft February 2005 LSP, if no FAST_REROUTE object was included. The PLR
may set this whenever the desired bandwidth is guaranteed; the
PLR MUST set this flag when the desired bandwidth is guaranteed

Pan, et al. Standards Track [Page 14]

RFC 4090 RSVP-TE Fast Reroute May 2005

and the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object. If the requested bandwidth is not
guaranteed, the PLR MUST NOT set this flag.

Node protection: 0x08

The PLR will set this bit when the protected LSP has a backup
path
which that provides protection against a failure of the next LSR
along the protected LSP. The PLR may set this whenever node
protection is provided by the protected LSP's backup path; the
PLR MUST set this flag when the node protection is provided and
the "node protection desired" flag was set in the
SESSION_ATTRIBUTE object. If node protection is not provided,
the PLR MUST NOT set this flag. Thus, if a PLR could only
setup set
up a link-protection backup path, the "Local protection
available" bit will be set set, but the "Node protection" bit will
be cleared.

5. Head-End Behavior

The head-end of an LSP determines whether local protection should be
requested for that LSP and which local protection technique method 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 "local protection desired" flag in the
SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the PATH message
message, or both. It is recommended that the The "local protection desired" flag in the
SESSION_ATTRIBUTE object SHOULD 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. method. If node protection is desired,
the head-end LSR should set the "node protection desired" flag in the
SESSION_ATTRIBUTE object; otherwise otherwise, this flag should be cleared.
Similarly, if a guarantee of bandwidth protection is desired, then
the "bandwidth protection desired" flag in the SESSION_ATTRIBUTE
object should be set; otherwise, this flag should be cleared.

Pan et al. [Page 16]

Internet Draft February 2005 If the
head-end LSR determines that control of the backup paths for the
protected LSP is desired, then the LSR should include the
FAST_REROUTE object. The PLRs will use the attribute filters,
bandwidth, hop-limit hop-limit, and priorities will be used by the PLRs when determining to determine the backup paths.

If the head-end LSR desires that the protected LSP be protected via
the one-to-one backup technique, method be used
for the protected LSP, then the head-end LSR should include a
FAST_REROUTE object and set the "one-to-one backup desired" flag. If

Pan, et al. Standards Track [Page 15]

RFC 4090 RSVP-TE Fast Reroute May 2005

the head-end LSR desires that the protected LSP be protected via the
facility backup technique, method, then the head-end LSR should include a
FAST_REROUTE object and set the "facility backup desired" flag. The
lack of a FAST_REROUTE object, or having both these flags
clear clear,
should be treated by PLRs as a lack of preference. If both flags are set
set, a PLR may use either method or both.

The head-end LSR of a protected LSP MUST support the additional flags
defined in Section 5.4 4.4 being set or clear in the RRO IPv4 and IPv6
sub-objects. The head-end LSR of a protected LSP MUST support the
RRO Label sub-object.

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

6. Point of Local Repair (PLR) Behavior

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

A PLR SHOULD support the FAST_REROUTE object, the "local protection
desired", "label recording desired", "node protection desired" desired", and
"bandwidth protection desired" flags in the SESSION_ATTRIBUTE object,
and the "local protection available", "local protection in use",
"bandwidth protection", and "node protection" flags in the RRO IPv4
and IPv6 sub-objects. A PLR MAY support the DETOUR object.

A PLR MUST consider an LSP as having to have asked for local protection if the
"local protection desired" flag is set in the SESSION_ATTRIBUTE
object and/or the FAST_REROUTE object is included. If the
FAST_REROUTE object is included, a PLR SHOULD consider providing
one-to-one protection if the "one-to-one desired" is set set, and it
SHOULD consider providing facility backup if the "facility backup
desired" flag is set when determining whether to provide local protection
and which technique to use to provide that local protection. set. If the "node protection desired" flag is set,
the PLR SHOULD try to provide node protection; if this is not
feasible, the PLR SHOULD

Pan et al. [Page 17]

Internet Draft February 2005 then try to provide link protection. If the
"bandwidth protection guaranteed" flag is set, the PLR SHOULD try to
provide a bandwidth guarantee; if this is not feasible, the PLR
SHOULD then try to provide a backup without a guarantee of the full
bandwidth.

Pan, et al. Standards Track [Page 16]

RFC 4090 RSVP-TE Fast Reroute May 2005

The following treatment for the RRO IPv4 or IPv6 sub-object's flags
must be followed if an RRO is included in the protected LSP's RESV
message. Based on this additional information information, the head-end may take
appropriate actions.

- Until a PLR has a backup path available, the PLR MUST clear the
relevant four flags in the corresponding RRO IPv4 or IPv6
sub-object. sub-
object.

- Whenever the PLR has a backup path available, the PLR MUST set the
"local protection available" flag. If no established one-to-one
backup LSP or bypass tunnel exists, or if the one-to-one LSP and
the bypass tunnel is in "DOWN" state, the PLR MUST clear the
"local protection available" flag in its IPv4 (or IPv6) address subobject
sub-object of the RRO and SHOULD send the updated RESV.

- The PLR MUST clear the "local protection in use" flag unless it is
actively redirecting traffic into the backup path instead of along
the protected LSP.

- The PLR SHOULD also set the "node protection" flag if the backup
path protects against the failure of the immediate downstream
node
node, and, if the path does not, the PLR SHOULD clear the "node
protection" flag. This MUST be done if the "node protection
desired" flag was set in the SESSION_ATTRIBUTE object.

- The PLR SHOULD set the "bandwidth protection" flag if the backup
path offers a bandwidth guarantee guarantee, and, if the path does not, the
PLR SHOULD clear the "bandwidth protection" flag. This MUST be
done if the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object.

7.1

6.1. Signaling a Backup Path

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

1. Unambiguously and uniquely identify identifying backup paths paths.

2. Unambiguously associate associating protected LSPs with their backup paths
paths.

3. Work Working with both global and non-global label spaces spaces.

4. Allow for Allowing merging of backup paths paths.

5. Maintain Maintaining RSVP state during and after fail-over.

Pan

Pan, et al. Standards Track [Page 18]

Internet Draft February 17]

RFC 4090 RSVP-TE Fast Reroute May 2005

LSP tunnels are identified by a combination of the SESSION and
SENDER_TEMPLATE objects. objects [RSVP-TE]. The relevant fields are as
follows.

IPv4 (or IPv6) tunnel end point address

IPv4 (or IPv6) address of the egress node for the tunnel.

Tunnel ID

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

Extended Tunnel ID

A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the
SESSION that remains constant over the life of the tunnel.
Normally it is set to all zeros. zero. Ingress nodes that wish to
narrow the scope of a SESSION to the ingress-egress pair may
place their IP address here as a globally unique identifier.

IPv4 (or IPv6) tunnel sender address

IPv4 (or IPv6) address for a sender node node.

LSP ID

A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC that
FILTER_SPEC, which can be changed to allow a sender to share
resources with itself.

The first three of these are in the SESSION object and are the basic
identification of for the tunnel. Setting the "Extended Tunnel ID" to
an IP address of the head-end LSR allows the scope of the SESSION to
be narrowed to only LSPs sent by that LSR. A backup LSP is
considered to be part of the same session as its protected LSP; therefore
these three cannot be varied.

The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same
SESSION may be protected and may take different routes; this is
common when rerouting a tunnel is rerouted using make-before-break. It is necessary
that a A backup
path must be clearly identified with its protected LSP, so
that LSP to allow
correct merging and state treatment can be done. treatment. Therefore, a backup path must
inherit its LSP ID from the associated protected LSP. Thus, the only
field in the SESSION and SENDER_TEMPLATE objects which that could be varied
between a backup path and a protected LSP is the "IPv4 (or IPv6)
tunnel sender address" in the SENDER_TEMPLATE.

Pan

Pan, et al. Standards Track [Page 19]

Internet Draft February 18]

RFC 4090 RSVP-TE Fast Reroute May 2005

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

7.1.1.

6.1.1. Backup Path Identification: Sender-Template-Specific Sender Template-Specific

In this approach, the SESSION object and the LSP_ID are copied from
the protected LSP. The "IPv4 tunnel sender address" is set to an
address of the PLR. If the head-end of a tunnel is also acting as
the PLR, it MUST choose an IP address different from the one used in
the SENDER_TEMPLATE of the original LSP tunnel.

When using the sender-template-specific approach, sender template-specific approach is used, 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 MAY be merged by the Detour Merge
Points, when the ERO from the MP to the egress is the same on each
LSP to be merged, as specified in [RSVP-TE].

7.1.2.

6.1.2. Backup Path Identification: Path-Specific

In this approach, rather than varying vary the SESSION or SENDER_TEMPLATE
objects, an implementation uses a new object, the DETOUR object, is used to
distinguish between PATH messages for a backup path and the protected
LSP.

Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
objects as the ones used in the protected LSP. The presence of a
DETOUR object in Path messages signifies a backup path; the presence
of a FAST_REROUTE object and/or the "local protection requested" flag
in the SESSION_ATTRIBUTE object indicates a protected LSP.

In the path-message-specific path message-specific approach, when an LSR receives
multiple merges Path messages which have
that are received with the same SESSION and SENDER_TEMPLATE objects
and that also have the same next-hop, that LSR
MUST merge the Path messages. next-hop object. Without this behavior,
it would be impossible to associate the multiple RESV messages received back would not be distinguishable as to
which with
the backup path each belongs to. This paths. However, this merging behavior does
reduce reduces the total
number of RSVP states inside the network at the expense of merging
LSPs with different EROs.

7.2

Pan, et al. Standards Track [Page 19]

RFC 4090 RSVP-TE Fast Reroute May 2005

6.2. Procedures for Backup Path Computation

Before a PLR can create a detour or a bypass tunnel, the desired
explicit route must be determined. This can be done using a CSPF.

Pan et al. [Page 20]

Internet Draft February 2005 CSPF
(Constraint-based Shortest Path First) computation. Before this CSPF
computation, the following information should must be collected at a PLR:

- The list of downstream nodes that the protected LSP passes
through. This information is readily available from the
RECORD_ROUTE objects during LSP setup. This information is also
available from the ERO. However, if the ERO contains loose
sub-objects, the ERO may not provide adequate information.

- The downstream links/nodes that we want to protect against.
Once again, this information is learned from the RECORD_ROUTE
objects. Whether node protection is desired is determined by
the "node protection" flag in the SESSION_ATTRIBUTE object and
local policy.

- The upstream uni-directional links that the protected LSP passes
through. This information is learned from the RECORD_ROUTE
objects; it is only needed for setting up one-to-one protection.
In the path-specific method, it is necessary to avoid the detour
and the protected LSP sharing a common next-hop upstream of the
failure. In the
sender-template-specific sender template-specific mode, this same
restriction is necessary to avoid sharing bandwidth between the
detour and its protected LSP, where that bandwidth has only been
reserved only once.

- The link attribute filters to be applied. These are derived
from the FAST_REROUTE object, if it is included in the PATH
message,
and or from the SESSION_ATTRIBUTE object otherwise.

- The bandwidth to be used is found in the FAST_REROUTE object, if
it is included in the PATH message, and or in the SESSION_ATTRIBUTE
object otherwise. Local policy may modify the bandwidth to be
reserved.

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

When applying a CSPF algorithm is used to compute the backup route, the
following constraints should must be satisfied:

- For detour LSPs, the destination MUST be the tail-end of the
protected LSP; for LSP. For bypass tunnels (Section 7), the destination
MUST be the address of the MP.

Pan, et al. Standards Track [Page 20]

RFC 4090 RSVP-TE Fast Reroute May 2005

- When setting up one-to-one protection is set up by using the path-specific
method, a detour MUST not traverse the upstream links of the
protected LSP in the same direction. This prevents the

Pan et al. [Page 21]

Internet Draft February 2005
possibility of early merging of the detour into the protected
LSP. When setting up one-to-one protection is set up using the
sender-template-specific sender-
template-specific method, a detour should not traverse the
upstream links of the protected LSP in the same direction;
this direction. This
prevents sharing the bandwidth between a protected LSP and its
backup upstream of the failure where the bandwidth would be used
twice in the event of a failure.

- The backup LSP 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 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 satisfy the resource requirements of the
protected LSP. This includes the link attribute filters,
bandwidth, and hop limits determined from the FAST_REROUTE
object and the SESSION_ATTRIBUTE object.

If such computation succeeds, the 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 might have emerged. If for any reason,
the PLR is unable to bring up a backup path, it must schedule a retry
at a later time.

7.3

6.3. Signaling Backups for One-To-One One-to-One Protection

Once a PLR has decided to locally protect an LSP locally with one-to-one
backup,
backup and has identified the desired path, it takes the following
steps to signal signals for the
detour.

The following describes the transformation to be performed upon the
protected LSP's PATH message to create the detour LSP's PATH message.

- If the sender-template specific sender template-specific method is to be used, then the
PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of
the SENDER_TEMPLATE to an address belonging to the PLR that is
not the same as was that used for the protected LSP. Additionally,
the DETOUR object MAY be added to the PATH message.

- If the path-specific method is to be used, then the PLR MUST add
a DETOUR object to the PATH message.

Pan, et al. Standards Track [Page 21]

RFC 4090 RSVP-TE Fast Reroute May 2005

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

Pan et al. [Page 22]

Internet Draft February 2005 be cleared. The "Label recording desired" flag MAY be
modified. If the Path Message contained a FAST_REROUTE object, object
and the ERO is not completely strict, the Include-any, Exclude-any, Exclude-
any, and Include-all fields of the FAST_REROUTE object SHOULD be
copied to the corresponding fields of the SESSION_ATTRIBUTE
object.

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

- The PLR MUST generate an EXPLICIT_ROUTE object toward the
egress. First, the PLR must remove all sub-objects preceding
the first address belonging to the Merge Point. Then the PLR
SHOULD add sub-objects corresponding to the desired backup path
between the PLR and the MP.

- The SENDER_TSPEC object SHOULD contain the bandwidth information
from the received FAST_REROUTE object, if included in the
protected LSP's PATH message.

- The RSVP_HOP object containing one of the PLR's IP address.

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

Detour LSPs are operate like regular LSPs in operation. LSPs. 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, changed or (2) the downstream interface and/or
the nexthop router for a protected LSP have has changed. The PLR may
recompute detour routes at any time.

7.3.1 Make-Before-Break

6.3.1. Make-before-Break with Detour LSPs

If the sender-template specific 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 the PLR (which were not used in the
SENDER_TEMPLATE of the protected LSP). If the current detour LSP
uses the first IP address in its SENDER_TEMPLATE, then the new detour
LSP should be signaled by using the second IP address in its
SENDER_TEMPLATE. Once the new detour LSP has been created, the
current detour LSP can be torn down. By alternating the use of these
IP addresses, the current and new detour LSPs will have different
SENDER_TEMPLATES and, thus, different state in the downstream LSRs.

Pan, et al. Standards Track [Page 22]

RFC 4090 RSVP-TE Fast Reroute May 2005

This make-before-break mechanism, changing which changes the PLR IP address in

Pan et al. [Page 23]

Internet Draft February 2005
the DETOUR object instead, is not feasible with the path-specific
method because
method, as the PATH messages for new and current detour LSPs may be
merged if they share a common next-hop.

7.3.2

6.3.2. Message Handling

LSRs must process the detour LSPs independent independently of the protected LSPs
to avoid triggering the LSP loop detection procedure described in
[RSVP-TE].

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

A session tear-down request is normally originated by the sender via
PathTear messages. When a PLR node receives a PathTear message from
upstream, it MUST delete both the protected and the detour LSPs. The
PathTear messages MUST propagate to both protected and detour LSPs.
During error conditions, the LSRs may send ResvTear messages to fix
problems on the failing path. When a PLR node receives the ResvTear
messages from downstream for a protected LSP, as long as a detour is
up, the ResvTear messages MUST not be sent further upstream.
PathErrs should be treated similiarly.

7.3.3 similarly.

6.3.3. Local Reroute of Traffic onto Detour LSP

When the PLR detects a failure on the protected LSP, the PLR MUST
rapidly switch packets to the protected LSP's backup LSP instead of
to the protected LSP's normal out-segment. The goal of this technique method
is to effect the redirection within 10s of milliseconds.

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

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

Example 3: 3. Redirect to Detour

Pan

Pan, et al. Standards Track [Page 24]

Internet Draft February 23]

RFC 4090 RSVP-TE Fast Reroute May 2005

In Example 3 above, 3, if the link [R2->R3] fails, then R2 would do the following.
Any traffic received on link [R1->R2] with label L32 would be sent out on
link [R2->R6] with label L46 (along the detour LSP) instead of out on
link [R3->R4] with lable label L34 (along the protected LSP). The Merge Point, R4, merge
point R4 would recognize that packets received on link [R7->R4] with
label L44 should be sent out on link [R4->R5] with label L35, L35 and thus that
they should be merged with the protected LSP.

7.4

6.4. Signaling for Facility Protection

A PLR may use one or more bypass tunnels to protect against the
failure of a link and/or a node. These bypass tunnels may be
setup set up
in advance or may be dynamically created as new protected LSPs are
signaled.

7.4.1.

6.4.1. Discovering Downstream Labels

To support facility backup, it is necessary for the PLR to must determine a label which that will
indicate to the MP that packets received with that label should be
switched along the protected LSP. This can be done without
explicitly signaling the backup path if the MP uses a label space
global to that LSR.

As described in Section 6, the head-end LSR MUST set the "label
recording requested" flag in the SESSION_ATTRIBUTE object for LSPs
requesting local protection. This will cause (as specified in
[RSVP- TE])
[RSVP-TE]) all LSRs to record their INBOUND labels and to note via a
flag if whether the label is global to the LSR. Thus, when a protected
LSP is first signaled through a PLR, the PLR can examine the RRO in
the Resv message and learn about the incoming labels that are used by
all downstream nodes for this LSP. LSP

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

7.4.2.

6.4.2. Procedures for the PLR before Local Repair

A PLR which that determines to use facility-backup to protect a given LSP
should select a bypass tunnel to use use, taking into account whether
node protection is to be provided, what bandwidth was
requested and requested,
whether a bandwidth guarantee is desired, and what link attribute
filters were specified in the FAST_REROUTE object.

Pan et al. [Page 25]

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

7.4.3. set up.

Pan, et al. Standards Track [Page 24]

RFC 4090 RSVP-TE Fast Reroute May 2005

6.4.3. Procedures for the PLR during Local Repair

When the PLR detects a link or/and node failure condition, it needs has 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 by using the sender-template-specific sender template-specific
method. The procedures to follow are similar to those described in
Section 7.3. 6.3.

- The SESSION 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 set to an address belonging to the PLR.

- The RSVP_HOP object MUST contain an IP source address belonging
to the PLR. Consequently, the MP will send messages back to the
PLR using as a destination with that IP address. address as the destination.

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

- The RRO object may need have to be updated, updated as described in Section
7.5.
6.5.

The PLR sends Path, PathTear, and ResvConf messages via the backup
tunnel. The MP sends Resv, ResvTear, and PathErr messages by
directly addressing sending
them directly to the address in the RSVP_HOP object
contents object, 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 through the bypass
tunnel. The MP should duplicate the Resv and ResvTear messages and sent
send them to both the PLR and the LSR indicated by the protected
LSP's RSVP_HOP object.

Pan

Pan, et al. Standards Track [Page 26]

Internet Draft February 25]

RFC 4090 RSVP-TE Fast Reroute May 2005

7.4.4.

6.4.4. Processing backup tunnel's Backup Tunnel's ERO

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

Sub-objects belonging to abstract nodes which that precede the Merge
Point are removed, along with the first sub-object belonging to
the MP. A sub-object identifying the Backup Tunnel destination is
then added.

More specifically, the PLR MUST:

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

- replace this first MP address with an IP address of the MP.
(Note that this could be same address that was just removed.)

7.5.

6.5. PLR Procedures During during Local Repair

In addition to the technique specific method-specific signaling and packet treatment,
there is common signaling which that should be followed.

During fast reroute, for each protected LSP containing an RRO object,
the PLR obtains the RRO from the protected LSP's stored RESV. The
PLR MUST update the IPv4 or IPv6 sub-object it inserted into the RRO
by setting the "Local protection in use" and "Local Protection
Available" flags.

7.5.1.

6.5.1. Notification of local repair Local Repair

In many situations, the route used during a Local Repair local repair will be less
than optimal. The purpose of Local Repair local repair is to keep high priority
and loss sensitive loss-sensitive traffic flowing while a more optimal re-routing of
the tunnel can be effected by the head-end of the tunnel. Thus Thus, the
head-end needs has to know of the failure so that it may re-signal an LSP
which is optimal.
optimal LSP.

Pan, et al. Standards Track [Page 26]

RFC 4090 RSVP-TE Fast Reroute May 2005

To provide this notification, the PLR SHOULD send a Path Error

Pan et al. [Page 27]

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

Additionally [RSVP-TE]).

Additionally, a head-end may also detect that an LSP needs has to be moved to a
more optimal path by noticing failures reported via the IGP. Note
that in the case of inter-area TE LSP (TE LSP spanning areas), the
head-end LSR will need have to rely exclusively on Path Error messages to
be informed of failures in another area.

7.5.2

6.5.2. Revertive Behavior

Upon a failure event, a protected TE LSP is locally repaired by the
PLR. There are two basic strategies for restoring the TE LSP to a
full working path.

- Global revertive mode: The head-end LSR of each tunnel is
responsible for reoptimizing the TE LSPs that used the failed
resource. There are several potential reoptimization triggers - 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 failure is detected. It is not tied to the
restoration of the failed resource.

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

There are several circumstances where in which a local revertive mode might
not be desirable. In the case of resource flapping (not an uncommon
failure type), this could generate multiple traffic disruptions.
Therefore, in the local revertive mode, the PLR should implement a
means to dampen the re-signaling process in order to limit potential
disruptions due to flapping.

In the local revertive mode, any TE LSP will be switched back,
without any distinction, as opposed to whereas in the global revertive mode
where mode, the
decision to reuse the restored resource is taken made by the head-end LSR
based on the TE LSP attributes. When the head-end learns of the
failure, it may reoptimize the protected LSP tunnel along a different
and more optimal path, because as it has a more complete view of the
resources and TE LSP constraints; this constraints. This means that the old LSP which that
has been reverted to may not no longer be optimal any
longer. optimal. Note that in the case
of inter-area LSP, where the TE LSP path computation might be done on
some Path Computation Server, Element, the reoptimization process can still be triggered on the Head-End

Pan

Pan, et al. Standards Track [Page 28]

Internet Draft February 27]

RFC 4090 RSVP-TE Fast Reroute May 2005

still be triggered on the Head-End LSP. The local revertive mode
is optional.

However, there are circumstances where in which the Head-end head-end does not have
the ability to reroute the TE LSP (e.g (e.g., if the protected LSP is
pinned down, as may be desirable if the paths are determined by using
an off-line optimization tool) tool), or if Head-end the head-end does not have the
complete TE topology information (depending on the path computation
scenario). In those cases, the local revertive mode might be a an
interesting option.

It is recommended that one always use the

The globally revertive mode. mode SHOULD always be used. Note that a link
or node "failure" may be due to the facility being permanently taken
out of service. Local revertive mode is optional. When used in
combination, the global mode may rely solely on timers to do the
reoptimization. When local revertive mode is not used, head-end LSRs
SHOULD react to RSVP error messages and/or IGP indications in order
to make a timely response.

Interoperability: If a PLR is configured with the local revertive
mode but the MP is not, any attempt from the PLR to resignal the TE
LSP over the restored resource would fail will fail, as the MP will not send any
Resv message. The PLR will still refresh the TE LSP over the backup
tunnel. The TE LSP will not revert to the restored resource;
instead
instead, it will continue to use the backup until it is re-optimized.

7. Merge Node Behavior

An LSR is a Merge Point if it receives the Path message for a
protected LSP and one or more messages for a backup LSP which that is
merged into that protected LSP. In the one-to-one backup
technique, method, the
LSR is aware that it is a merge node prior to failure. In the
facility backup technique, method, the LSR may 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 that is on the path of a protected LSP SHOULD
always assume that it is a merge point.

When a MP receives a backup LSP's Path message thru through a bypass
tunnel, the Send_TTL in the Common Header may not match the TTL of
the IP packet within which the Path message was transported. This is
expected behavior.

8.1.

7.1. Handling Backup Path Messages Before before Failure

There are two circumstances where in which a Merge Point will receive Path
messages for a backup path prior to failure. In the first case, if a
PLR is providing local protection via the one-to-one backup

Pan et al. [Page 29]

Internet Draft February 2005

technique, method,
the detour will be signaled and must be properly handled by the MP.

Pan, et al. Standards Track [Page 28]

RFC 4090 RSVP-TE Fast Reroute May 2005

In this case, the backup LSP may be signaled via the
sender-template-specific sender
template-specific method or via the path-specific method.

In the second case, if the Merge Point does not provide labels global
to the MP and record them in a Label sub-object of the RRO RRO, or if the
PLR does not use such recorded information, the PLR may signal the
backup path, path as described above in Section 7.4.1, to 6.4.1. This will determine the
label to use if the PLR is providing protection according to the
facility backup technique. method. In this case, the backup LSP is signaled via
the sender-template-specific sender template-specific method.

The reception of a backup LSP's path message does not indicate that a
failure has occured and occurred or that the incoming protected LSP will no
longer be used.

8.1.1. Merginging

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

An LSR may receive multiple Path messages for one or more backup LSPs
and, possibly, for the protected LSP. Each of these Path messages
will have a different SENDER_TEMPLATE. The protected LSP can be
recognized because it will either include the FAST_REROUTE object, object or have
the "local protection desired" flag set in the SESSION_ATTRIBUTE object
object, or both.

If the outgoing interface and next-hop LSR are the same, then the
Path messages are eligible for merging. Similar Similarly to that specified the
specification in [RSVP-TE] for merging of RESV messages, only those Path
messages whose ERO from that LSR to the egress is 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 be sent MUST be
that of the protected LSP. This merges the backup LSPs into the
protected LSP at that LSR. Once the final Path message has been
identified, the MP MUST start to refresh it downstream periodically.

If merging occurs and all the Path messages were for backup LSPs,
then the DETOUR object, if any, should be altered as specified in
Section 9.1

8.1.2. 8.1

7.1.2. Merging Detours using the 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 30]

Internet Draft February 2005 The merging
rule is the following:

For as follows:

If all Path messages that do not have either neither a FAST_REROUTE or nor a DETOUR object,
or if the MP is the egress of the LSP, no merging is required. The
messages are processed according to [RSVP-TE].

Pan, et al. Standards Track [Page 29]

RFC 4090 RSVP-TE Fast Reroute May 2005

Otherwise, the MP MUST record the Path state as well as their and the incoming
interface. If the Path messages do not share an outgoing interface
and a next-hop LSR, the MP MUST consider them as to be independent
LSPs, LSPs
and MUST NOT merge them.

For all the Path messages that share the same outgoing interface and
next-hop LSR, the MP runs the following procedure to create a Path
message to forward downstream.

1. If one or more of the Path messages is for the protected LSP (a
protected LSP is one originated from this node, or with the
FAST_REROUTE object, or without the DETOUR object), one of these
must become the chosen Path message. There could be more than
one; in that case, it is a local decision to choose which one to forward. forward is a local decision.
Quit.

2. From the remaining set of Detour Path messages, eliminate from
consideration,
consideration those that traverse nodes which that others want to
avoid.

3. If several still remain, it is a local decision to choose which one to forward. forward is a local
decision. If none remain, then the MP may MAY try and to find a new
route that does avoid avoids all nodes that all merging Detour Paths want to avoid and
avoid; it will forward a Path message with that ERO.

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

If no merged Path message can be constructed then constructed, the MP SHOULD send a
PathErr in response to the most recently received detour Path
message. If a protected Path is chosen to be forwarded, forwarded but it
traverses nodes that some detours want to avoid, PathErrs should SHOULD be
sent in response to those detour Paths which cannot merge.

Pan

Pan, et al. Standards Track [Page 31]

Internet Draft February 30]

RFC 4090 RSVP-TE Fast Reroute May 2005

8.1.2.1.

7.1.2.1. An Example on of Path 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: 4. Path Message Merging

In Example 4 above, 4, R8 will receive Path messages that have the same
SESSION and SENDER_TEMPLATE from detours for R2 and R3. During
merging at R8 since R8, because detour R3 has a shorter ERO path length (that
is, ERO is [R9->R5->R6], and path length is 3), R8 will select it as
the final LSP, LSP and will only propagate its Path messages downstream.
Upon receiving a Resv (or a ResvTear) message, R8 must relay on the
messages toward both R2 and R3.

R5 needs has to merge as well, and it will select the main LSP, since it
has the FAST_REROUTE object. Thus, the detour LSP terminates at R5.

8.1.3.

7.1.3. Message Handling for Merged Detours

When an LSR receives a ResvTear for an LSP, the LSR must determine
whether it has an alternate associated LSP. For instance, if the
ResvTear was received for a protected LSP, LSP but an associated backup
LSP has not received a ResvTear, then the LSR has an alternate
associated LSP. If the LSR does not have an alternate associated
LSP, then the MP MUST propogate propagate the ResvTear toward the LSP's
ingress
ingress, and, for each backup LSP merged into that LSP at this LSR,
the ResvTear SHOULD also be propogated propagated along the backup LSP.

The MP may receive PathTear messages for some of the merging LSPs.
PathTear messages SHOULD NOT be propagated downstream until the MP
has received PathTear messages for each of the merged LSPs. However,
the fact that one or more of the merged LSPs has been torn down
should be reflected in the downstream message, such as by changing
the DETOUR object, if any.

8.2. there is one.

7.2. Handling Failures

When a downstream LSR detects a local link failure, for any protected
LSPs routed over the failed link, Path and Resv state

Pan et al. [Page 32]

Internet Draft February 2005 MUST NOT be cleared
cleared, and PathTear and ResvErr messages MUST NOT be sent immediately; if
immediately. If this is not the case, then the facility backup
technique
method will not work. Further Furthermore, a downstream LSR SHOULD reset the

Pan, et al. Standards Track [Page 31]

RFC 4090 RSVP-TE Fast Reroute May 2005

refresh timers for these LSPs as if they had just been refreshed.
This is to allow time for the PLR to begin refreshing state via the
bypass tunnel. State MUST be removed if it has not been refreshed
before the refresh timer expires. This allows the facility backup
technique
method to work without requiring that it signal backup paths
thru through
the bypass tunnel before failure.

After a failure has occured, occurred, the MP must still send Resv messages
for the backup LSPs associated with the protected LSPs which that have
failed. If the backup LSP was sent through a bypass tunnel, then the
PHOP object in its Path message will have the 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 that had failed over to their
backup.

8. Behavior of all All LSRs

The objects defined and the techniques methods defined in this document require behavior
from all LSRs in the traffic-engineered network, even if that an LSR is
not along the path of a protected LSP.

First, if a DETOUR object is included in the backup LSP's path
message for the sender-template-specific sender template-specific method, the LSRs in the
traffic-engineered network should support the DETOUR object.

Second, if the Path-Specific Method path-specific method is to be supported for the one-to-one one-
to-one backup technique, method, it is necessary that the LSRs in the traffic-engineered traffic-
engineered network be capable of merging detours as specified below in
Section 9.1. 8.1.

It is possible to avoid specific LSRs which that do not support this
behavior by assigning an a link attribute to all the links of those LSPs
and then requesting that backup paths exclude that this link attribute.

9.1.

8.1. Merging Detours in the Path-Specific Method

If multiple Path Messages for different detours are received with the
same SESSION, SENDER_TEMPLATE, outgoing interface 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 33]

Internet Draft February 2005 in
Section 8.1.2 7.1.2 and shown in Example 4.

In addition, it is necessary to update the DETOUR object to reflect
the merging which that has taken place. This is done using the following
algorithm to format the outgoing DETOUR object for the final LSP:

Pan, et al. Standards Track [Page 32]

RFC 4090 RSVP-TE Fast Reroute May 2005

- Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the DETOUR
objects of all merged LSPs, and create LSPs into a new object with
all listed. object. Ordering is
insignificant.

10.

9. Security Considerations

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

It should be noted

Note that the facility backup technique method requires that a PLR and its
selected Merge Point will merge point trust RSVP messages received from each other.

11.

10. IANA Section Considerations

IANA [RFC-IANA] will assign RSVP Class Number 205 for has assigned the
FAST_REROUTE and following RSVP Class Number 63 for the DETOUR object. This
matches the current usage in production networks.

IANA will assign C-Type 1 Numbers for the standard FAST_REROUTE object
format
objects defined in section 5.1 and list C-Type this document.

10.1. DETOUR Object

IANA has assigned:

63 DETOUR

Class Types or C-Types:

7 as reserved as it
is still used by pre-standard implementations. IPv4
8 IPv6

Future C-Types will be assigned using the following guidelines:

C-Types 0 through 127 are assigned by Standards Action.

C-Types 128 through 191 are assigned by Expert Review.

C-Types 192 through 255 are reserved for Vendor Private Use.

For C-Types in the range 192 through 255, the first four octets of
the FAST_REROUTE DETOUR object after the C-Type MUST must be the Vendor's SMI Network
Management Private Enterprise Code (see [ENT]) in network byte order.

Pan, et al. Standards Track [Page 33]

RFC 4090 RSVP-TE Fast Reroute May 2005

10.2. FAST_REROUTE Object

IANA will assign C-Types has assigned:

205 FAST_REROUTE

Class Types or C-Types:

1 FAST_REROUTE Type 1
7 and 8 to RESERVED

In the IPv4 and IPv6 DETOUR object
formats FAST_REROUTE object, C-Type 7 is reserved as defined in section 5.2. it is still used
by pre-standard implementations. Future C-Types will be assigned
using the following guidelines:

Pan et al. [Page 34]

Internet Draft February 2005

C-Types 0 through 127 are assigned by Standards Action.

C-Types 128 through 191 are assigned by Expert Review.

C-Types 192 through 255 are reserved for Vendor Private Use.

For C-Types in the range 192 through 255, the first four octets of
the DETOUR FAST_REROUTE object after the C-Type MUST must be the Vendor's SMI
Network Management Private Enterprise Code (see [ENT]) in network
byte order.

12. Intellectual Property Considerations

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this

Pan, et al. Standards Track [Page 34]

RFC 4090 RSVP-TE Fast Reroute May 2005

11. Contributors

This document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect was written by George Swallow, Ping Pan, Alia Atlas,
Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.

Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA

Phone: +1 978 497 6238
EMail: jpv@cisco.com

Markus Jork
Quarry Technologies
8 New England Executive Park
Burlington, MA 01803
USA

Phone: +1 781 359 5071
EMail: mjork@quarrytech.com

Der-Hwa Gan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA

Phone: +1 408 745 2074
EMail: dhg@juniper.net

Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
USA

Phone: +1 916 415 0437
EMail: dcooper@gblx.net

Pan, et al. Standards Track [Page 35]

RFC 4090 RSVP-TE Fast Reroute May 2005

12. Acknowledgments

We would like to rights in standards-track acknowledge input and
standards-related documentation can be found helpful comments from Rob
Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, we
thank those, who have been involved in BCP-11. Copies of
claims of rights made available for publication interoperability testing and any assurances of
licenses to be made available, or the result of an attempt made
field trails, and provided invaluable ideas and suggestions. They
are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, Richard
Southern, and Bijan Jabbari.

13. Normative References

[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.

[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to
obtain a general license or permission RSVP for LSP
Tunnels", RFC 3209, December 2001.

[RFC-WORDS] Bradner, S., "Key words for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF has been notified of intellectual property rights
claimed in regard RFCs to some or all of the specification contained Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in this document. For more information consult the online list
of claimed rights.

13. RFCs", BCP 26, RFC 2434,
October 1998.

[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers

Pan, et al. Standards Track [Page 36]

RFC 4090 RSVP-TE Fast Reroute May 2005

Authors' Addresses

George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA

Phone: +1 978 244 8143
EMail: swallow@cisco.com

Ping Pan
Hammerhead Systems
640 Clyde Court
Mountain View, CA 94043
USA

EMail: ppan@hammerheadsystems.com

Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
USA

Phone: +1 978 964 2070
EMail: aatlas@avici.com

Pan, et al. Standards Track [Page 37]

RFC 4090 RSVP-TE Fast Reroute May 2005

Full Copyright Statement

This document and translations of it may be copied and furnished is subject 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 rights, licenses and derivative works. However, this
document itself may not be modified restrictions
contained in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, BCP 78, and 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.

Pan et al. [Page 35]

Internet Draft February 2005

The limited permissions granted above are perpetual and will not be
revoked by set forth therein, the Internet Society or its successors or assigns. authors
retain all their rights.

This document and the information contained herein is are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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. Acknowledgments

We would like

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to acknowledge input and helpful comments from Rob
Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially,
we thank those, who have been involved rights in interoperability testing
and field trails, and provided invaluable ideas RFC documents can be
found in BCP 78 and suggestions.
They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan,
Richard Southern, BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and Bijan Jabbari.

15. 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 any
assurances of licenses to RSVP for LSP
tunnels", RFC3029, December 2001.

[RFC-WORDS] Bradner, S., "Key words be made available, or the result of an
attempt made to obtain a general license or permission for the use in RFCs of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

Acknowledgement

Funding for Writing an
IANA Considerations Section in RFCs", the RFC 2434.

[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers

16. Editor Information

George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
email: swallow@cisco.com
phone: +1 978 244 8143

Pan et al. [Page 36] function is currently provided by the
Internet Draft February 2005

Ping Pan
640 Clyde Court
Mountain View, CA 94043
USA
e-mail: ppan@hammerheadsystems.com

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

Pan Society.

Pan, et al. Standards Track [Page 37] 38]

----