draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt   draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt 
Network Working Group Ping Pan, Ed. (Juniper Networks) Internet Draft Ping Pan, Ed (Ciena Corp)
Internet Draft Der-Hwa Gan (Juniper Networks) Expires: May 2003 Der-Hwa Gan (Juniper Networks)
Expiration Date: July 2002 George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Network Working Group Jean Philippe Vasseur (Cisco Systems) Jean Philippe Vasseur (Cisco Systems)
Dave Cooper (Global Crossing) Dave Cooper (Global Crossing)
Alia Atlas (Avici Systems) Alia Atlas, Ed (Avici Systems)
Markus Jork (Avici Systems) Markus Jork (Avici Systems)
Fast Reroute Extensions to RSVP-TE for LSP Tunnels Fast Reroute Extensions to RSVP-TE for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the use of RSVP [RSVP, RSVP-TE] to establish This document defines extensions to and describes the use of RSVP
backup LSP tunnels for local repair of LSP tunnels. [RSVP, RSVP-TE] to establish backup LSP tunnels for local repair of
LSP tunnels. These mechanisms enable the re-direction of traffic
Two methods are presented here. One is to setup one-to-one detour LSPs onto backup LSP tunnels in 10s of milliseconds in the event of a
according to the requirements defined by the head-end users. The other failure.
is to setup many-to-one bypass LSP using a single tunnel to backup a set
of protected LSPs (making use of label stacking). Both methods can be
used to protect links and nodes during network failure. The described
use of RSVP allows both one-to-one and many-to-one backups to
interoperate.
1. Introduction
This document describes the use of RSVP [RSVP] to establish backup
LSP tunnels for local repair of LSP tunnels. By 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
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.
In order to meet the needs of real-time applications such as voice
over IP, 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 be placed as close to the failure point as possible, since
reporting failure between nodes may cost significant delay. We use
the term local repair when referring to techniques which accomplish
this, and refer the LSP that is associated to one or more backup
tunnels as a protected LSP. There are two basic strategies for
setting up backup tunnels. These are one-to-one backup and facility
backup. One-to-one backup operates on the basis of a backup LSP for
each protected LSP. The facility backup aims at using a single LSP
to back up a set of protected LSPs.
1.1. One-to-one backup
In the one to one case, a label switched path is established which
intersects the original tunnel somewhere downstream of the point of
link or node failure. For each LSP which is backed up, another
backup LSP is established.
[R1]---[R2]-----[R3]----[R4]---[R5]
\ /
[R6]---[R7]
For example, suppose that in the simple topology above, R1 creates a
tunnel to R5 via 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 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, there could be
as many as (N - 1) detours. To minimize processing overhead, it is
desirable to merge detours back to a main LSP wherever possible.
1.2. Facility backup
A second means of backing up LSPs is to take advantage of the 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 a LSP tunnel a bypass tunnel.
The bypass tunnel must intersect the path of the original LSP(s) Two methods are defined here. The one-to-one backup method creates
somewhere downstream of the point of local repair. This of course detour LSPs for each protected LSP at each potential point of local
implies that the set of LSPs being backed up all pass through some repair. The facility backup method creates a bypass tunnel to
common downstream node. All LSPs which pass through the point of protect a potential failure point; by taking advantage of MPLS label
local repair and through this common node which do not also use the stacking, this bypass tunnel can protect a set of protected LSPs that
facilities involved in the bypass tunnel are candidates for this set have similar backup constraints. Both methods can be used to protect
of LSPs. links and nodes during network failure. The described behavior and
extensions to RSVP allow LERs and LSRs to implement either or both
methods and to interoperate in a mixed network.
To effect the repair of the protected LSPs, packets belonging to a Contents
LSP are redirected onto the bypass tunnel. An additional label
representing the bypass tunnel is stacked onto the redirected
packets. At the penultimate hop of the bypass tunnel, the label for
the bypass tunnel is popped off the stack, revealing the label which
represents the LSP being backed up.
[R8] 1 Introduction ............................................. 4
\ 2 Terminology ............................................... 4
[R1]---[R2]----[R3]----[R4]---[R5] 3 Local Repair Techniques ................................... 6
\\ // \ 3.1 One-to-one Backup ....................................... 6
[R6]===[R7] [R9] 3.2 Facility Backup ......................................... 7
4 RSVP 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 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 .............. 22
6.4 Signaling for Facility Protection ....................... 23
6.4.1 Discovering Downstream Labels ......................... 23
6.4.2 Procedures for the 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 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 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 References ................................................ 33
15 Author Information ........................................ 33
In the above example, R2 in this case would build a bypass tunnel 1. Introduction
[R2->R6->R7->R4]. The doubled lines represent this tunnel. The
backup path for [R1->R2->R3->R4->R5] again rejoins the original path
at R4, but its path is now [R1->R2->R4->R5] with the bypass tunnel as
the connection between R2 and R4.
In this example, the backup tunnel is a Next-Next-Hop (NNHOP) bypass This document extends RSVP [RSVP] to establish backup LSP tunnels
tunnel. That is, it bypasses a single node (R3) of the protected for the local repair of LSP tunnels. This technique is presented
path. NNHOP bypass tunnels may protect against Link (R2-R3) failure to meet the needs of real-time applications, such as voice over IP,
and/or Node (R3) failure as NHOP bypass tunnel only protects against for which it is highly desirable to be able to re-direct user
link failure. traffic 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 failure point as 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 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 to an
explicitly routed LSP which is provided with such protection as a
protected LSP. 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.
The scalability improvement comes in that this bypass tunnel can also Section 2 covers new terminology used in this document. The two
be used to backup LSPs from any of R1, or R2, R8 to any of R4, R5, or basic strategies for creating backup LSPs are described in Section
R9 which traverse the link R2->R3. 3. In Section 4, the protocol extensions to RSVP to support local
protection are described. In Section 5, the behavior of an LER
which wishes to request local protection for an LSP is presented.
The behavior of a potential point of local repair (PLR) is given in
Section 6; this describes how to determine the appropriate strategy
to use for protecting an LSP and how to implement each of the
strategies. The behavior of a merge node, the LSR where a
protected LSP and its backup LSP rejoin, is described in Section 7.
Finally, the required behavior of other nodes in the network is
discussed in Section 8.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC-WORDS]. document are to be interpreted as described in RFC2119 [RFC-WORDS].
The reader is assumed to be familiar with the terminology in [RSVP] The reader is assumed to be familiar with the terminology in [RSVP]
and [RSVP-TE]. and [RSVP-TE].
LSR - Label Switch Router LSR - Label Switch Router
LSP - An MPLS Label Switched Path LSP - An MPLS Label Switched Path. In this document, an LSP
will always refer to an explicitly routed LSP.
Local Repair - Techniques used to repair LSP tunnels quickly Local Repair - Techniques used to repair LSP tunnels quickly
when a node or link along the LSPs path fails. 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 Protected LSP - An LSP is said to be protected at a given hop if
it has one or multiple associated backup tunnels originating it has one or multiple associated backup tunnels originating
at that hop. at that hop.
Detour LSP - The LSP that is used to re-route traffic around Detour LSP - The LSP that is used to re-route traffic around
a failure in one-to-one backup. a failure in one-to-one backup.
Bypass Tunnel - An LSP that is used to protect a set of LSPs Bypass Tunnel - An LSP that is used to protect a set of LSPs
passing over a common facility. passing over a common facility.
skipping to change at page 4, line 44 skipping to change at page 5, line 43
NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel
which bypasses a single link of the protected LSP. which bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup
tunnel which bypasses a single node of the protected LSP. tunnel which bypasses a single node of the protected LSP.
Backup Path - The LSP that is responsible for backing up one Backup Path - The LSP that is responsible for backing up one
protection LSP. A backup path refers to either a detour LSP protection LSP. A backup path refers to either a detour LSP
or a backup tunnel. 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 MP - Merge Point. The LSR where one or more backup tunnels rejoin
the path of the protected LSP, downstream of the potential the path of the protected LSP, downstream of the potential
failure. In the case of one-to-one backup, a Merge Point may failure. The same LSR may be both an MP and a PLR
also be an LSR where multiple detours converge and only one simultaneously.
detour is signaled beyond that LSR; this type of merge point
may be referred to as a Detour Merge Point. A MP may also DMP - Detour Merge Point. In the case of one-to-one backup,
be a PLR. this is an LSR where multiple detours converge and only one
detour is signaled beyond that LSR.
Reroutable LSP - Any LSP for which the head-end LSR requests Reroutable LSP - Any LSP for which the head-end LSR requests
for local protection. See Section 9.1 for more detail. local protection. See Section 9.1 for more detail.
CSPF - Constraint-based Shortest Path First. CSPF - Constraint-based Shortest Path First.
3. RSVP Extensions SRLG Disjoint - A path is considered to be SRLG disjoint from a
given link or node if the path does not use any links or
nodes which belong to the same SRLG as that given link or
node.
We propose two additional objects, FAST_REROUTE and DETOUR, that 3. Local Repair Techniques
extend RSVP-TE for fast-reroute signaling. The new objects are
defined 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 Two different techniques for local protection are presented here.
support bandwidth and node protection features: The one-to-one backup technique has a PLR compute a separate backup
LSP, called a detour LSP, for each LSP which the PLR protects using
this technique. With the facility backup technique, the PLR creates
a single bypass tunnel which can be used to protect multiple LSPs.
In many circumstances, it may be desirable for the head-end LSR not 3.1. One-to-one backup
only to signal an LSP as fast reroutable but also to specify to every
PLR along its path that the LSP must be rerouted onto a backup path
offering an equivalent bandwidth.
It may be desirable to signal the need for the fast reroutable LSP to In the one-to-one technique, a label switched path is established
be node protected along its path. By node protected we mean that each which intersects the original LSP somewhere downstream of the point
PLR along the path must protect the reroutable LSP with a detour LSP of link or node failure. For each LSP which is backed up, a
or a NNHOP backup tunnel (except for the penultimate hop LSR that separate backup LSP is established.
will just require a NHOP backup tunnel). This way the reroutable LSP
is being protected against any link or node failure.
3.1. FAST_REROUTE Object [R1]---[R2]-----[R3]----[R4]---[R5]
\ \ \ / \ /
[R6]---[R7]-------[R8]----[R9]
The FAST_REROUTE object carries the control information, such as Protected LSP: [R1->R2->R3->R4->R5]
setup and hold priorities and bandwidth. A protected LSP uses the R1's Backup: [R1->R6->R7->R8->R3]
FAST_REROUTE object to specify the level of protection that is R2's Backup: [R2->R7->R8->R4]
required during local repair. The FAST_REROUTE object can be used for R3's Backup: [R3->R8->R9->R5]
both one-to-one and facility backup, and has the following format: R4's Backup: [R4->R9->R5]
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]
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.
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) Class = TBD (use form 11bbbbbb for compatibility)
C-Type = 1 C-Type = 1
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags | | Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 6, line 25 skipping to change at page 9, line 26
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Include-any | | Include-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Exclude-any | | Exclude-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Include-all | | Include-all |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Setup Priority Setup Priority
The priority of the backup path with respect to taking resources, The priority of the backup path with respect to taking
in the range of 0 to 7. The value 0 is the highest priority. resources, in the range of 0 to 7. The value 0 is the highest
Setup Priority is used in deciding whether this session can priority. Setup Priority is used in deciding whether
preempt another session. See [RSVP-TE] for the usage on priority. this session can preempt another session. See [RSVP-TE] for
the usage on priority.
Holding Priority Holding Priority
The priority of the backup path with respect to holding The priority of the backup path with respect to holding
resources, in the range of 0 to 7. The value 0 is the highest resources, in the range of 0 to 7. The value 0 is the highest
priority. Holding Priority is used in deciding whether this priority. Holding Priority is used in deciding whether this
session can be preempted by another session. See [RSVP-TE] for session can be preempted by another session. See [RSVP-TE] for
the usage on priority. the usage on priority.
Hop-limit Hop-limit
The maximum number of extra hops the backup path is allowed The maximum number of extra hops the backup path is allowed
to take, from current node (a PLR) to a MP, with PLR and MP 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 excluded in counting. For example, hop-limit of 0 means only
direct links between PLR and MP can be considered. direct links between PLR and MP can be considered.
Flags Flags
0x01 One-to-one Backup Desired 0x01 One-to-one Backup Desired
Indicates that protection via the one-to-one backup
Indicates that the LSP should be protected via the one- technique is desired.
to-one backup mechanism described in Section 5.
This flag can only be set by the head-end LSRs.
0x02 Facility Backup Desired 0x02 Facility Backup Desired
Indicates that the LSP should be protected via the facility Indicates that protection via the facility backup
backup mechanism described in Section 6. This flag can technique is desired.
only be set by the head-end LSRs.
Bandwidth Bandwidth
Bandwidth estimate (32-bit IEEE floating point integer) in Bandwidth estimate (32-bit IEEE floating point integer) in
bytes-per-second. bytes-per-second.
Exclude-any Exclude-any
A 32-bit vector representing a set of attribute filters associated A 32-bit vector representing a set of attribute filters
with a backup path any of which renders a link unacceptable. associated with a backup path any of which renders a link
unacceptable.
Include-any Include-any
A 32-bit vector representing a set of attribute filters associated A 32-bit vector representing a set of attribute filters
with a backup path any of which renders a link acceptable (with associated with a backup path any of which renders a link
respect to this test). A null set (all bits set to zero) acceptable (with respect to this test). A null set (all bits
automatically passes. set to zero) automatically passes.
Include-all Include-all
A 32-bit vector representing a set of attribute filters associated A 32-bit vector representing a set of attribute filters
with a backup path all of which must be present for a link to be associated with a backup path all of which must be present for
acceptable (with respect to this test). A null set (all bits set a link to be acceptable (with respect to this test). A null set
to zero) automatically passes. (all bits set to zero) automatically passes.
The C-Class must be assigned in such a way that, for the LSRs that do The two high-order bits of the Class-Num (11) indicate that nodes
not support the FAST_REROUTE objects, they MUST forward the objects that do not understand the object should ignore it and pass if
downstream unchanged. forward unchanged.
Some of the existing implementations use the FAST_REROUTE object with For informational purposes, a different C-type value and format for
a different C-type value, and slightly different object format (shown the FAST_REROUTE object are specified below. This is used by
below). For backward compatible purposes, it is documented here for existing implementations. The meaning of the fields is the same as
information purpose. described for C-Type 1.
C-Type = 7 C-Type = 7
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved | | Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Bandwidth | | Bandwidth |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Include-any | | Include-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Exclude-any | | Exclude-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
3.2. DETOUR Object 4.2. DETOUR Object
The DETOUR object is used in one-to-one backup to setup and identify The DETOUR object is used in one-to-one backup to identify detour
detour LSPs. It has the following format: LSPs. It has the following format:
Class = TBD (to conform 0bbbbbbb format for compatibility) Class = TBD (to conform 0bbbbbbb format for compatibility)
C-Type = 7 C-Type = 7
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PLR ID 1 | | PLR ID 1 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 9, line 12 skipping to change at page 12, line 8
IPv4 address identifying the beginning point of detour which IPv4 address identifying the beginning point of detour which
is a PLR. Any local address on the PLR can be used. is a PLR. Any local address on the PLR can be used.
Avoid Node ID (1 - n) Avoid Node ID (1 - n)
IP address identifying the immediate downstream node that IP address identifying the immediate downstream node that
the PLR is trying to avoid. Router ID of downstream node the PLR is trying to avoid. Router ID of downstream node
is preferred. This field is mandatory, and is used by is preferred. This field is mandatory, and is used by
the MP for merging rules discussed below. the MP for merging rules discussed below.
There could be more than one pair of (PLR_ID, Avoid_Node_ID) entry in 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 a DETOUR object. If detour merging is desired, after each merging
operation (Section 5.3), the MP should combine all the merged detours operation, the Detour Merge Point should combine all the merged
in the subsequent Path messages. detours in the subsequent Path messages.
The C-Class must 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 a PathErr to notify the PLR.
3.3. SESSION_ATTRIBUTE Modification
To explicitly require bandwidth and node protection, two new flags
are defined in the SESSION_ATTRIBUTE object:
SESSION_ATTRIBUTE The high-order bit of the C-Class 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.
Class = 207 4.3. SESSION_ATTRIBUTE Flags
C-Type = 7 (LSP_TUNNEL)
0 1 2 3 To explicitly request bandwidth and node protection, two new flags
+-------------+-------------+-------------+-------------+ are defined in the SESSION_ATTRIBUTE object.
| Setup Pri | Holding Pri | Flags | Name Length |
+-------------+-------------+-------------+-------------+
| |
// Session Name (NULL padded display string) //
| |
+-------------+-------------+-------------+-------------+
Current Flags: For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has
the following flags defined:
Local protection desired: 0x01 Local protection desired: 0x01
This flag permits transit routers to use a local repair mechanism This flag permits transit routers to use a local repair
which may result in violation of the explicit route object. mechanism which may result in violation of the explicit route
When a fault is detected on an adjacent downstream link or node, object. When a fault is detected on an adjacent downstream link
a transit node can reroute traffic for fast service restoration. or node, a transit node may reroute traffic for fast service
restoration.
Label recording desired: 0x02 Label recording desired: 0x02
This flag indicates that label information should be included This flag indicates that label information should be included
when doing a route record. when doing a route record.
SE Style desired: 0x04 SE Style desired: 0x04
This flag indicates that the tunnel ingress node may choose to This flag indicates that the tunnel ingress node may choose to
reroute this tunnel without tearing it down. A tunnel egress node reroute this tunnel without tearing it down. A tunnel egress
SHOULD use the SE Style when responding with a Resv message. node SHOULD use the SE Style when responding with a Resv
When requesting fast reroute, the head-end LSR MUST set message. When requesting fast reroute, the head-end LSR
this flag. SHOULD set this flag; this is not necessary for the
path-specific method of the one-to-one backup technique.
New Flags: The following new flags are defined:
Bandwidth protection desired: 0x08 Bandwidth protection desired: 0x08
This flag indicates to the PLRs along the protected LSP path This flag indicates to the PLRs along the protected LSP path
that a backup path with a bandwidth guarantee is desired. that a backup path with a bandwidth guarantee is desired.
The bandwidth which must be guaranteed is that of the protected The bandwidth to be guaranteed is that of the protected
LSP, if no FAST_REROUTE object is included in the PATH message; LSP, if no FAST_REROUTE object is included in the PATH message;
if a FAST_REROUTE object is in the PATH message, then the if a FAST_REROUTE object is in the PATH message, then the
bandwidth specified in there is that which must be guaranteed. bandwidth specified therein is that to be guaranteed.
Node protection desired: 0x10 Node protection desired: 0x10
This flag indicates to the PLRs along a protected LSP path This flag indicates to the PLRs along a protected LSP path
that they must select a backup path that bypasses at least the that a backup path which bypasses at least the next node of
next node of the protected LSP. the protected LSP is desired.
3.4. RRO Modification
To record bandwidth and node protection, we define two news flags in
the RRO IPv4 sub-object.
RRO IPv4 sub-object address: 4.4. RRO IPv4/IPv6 Sub-Object Flags
Type: 0x01 IPv4 address To report whether bandwidth and/or node protection are provided as
requested, we define two news flags in the RRO IPv4 sub-object.
0 1 2 3 RRO IPv4 and IPv6 sub-object address:
+-------------+-------------+-------------+-------------+
| Type | Length | IPv4 address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 address (continued) | Prefix Len | Flags |
+-------------+-------------+-------------+-------------+
Current Flags: These two sub-objects currently have the following flags defined:
Local protection available: 0x01 Local protection available: 0x01
Indicates that the link downstream of this node is protected Indicates that the link downstream of this node is protected
via a local repair mechanism, which can be either one-to-one via a local repair mechanism, which can be either one-to-one
or facility backup. or facility backup.
Local protection in use: 0x02 Local protection in use: 0x02
Indicates that a local repair mechanism is in use to maintain Indicates that a local repair mechanism is in use to maintain
this tunnel (usually in the face of an outage of the link it this tunnel (usually in the face of an outage of the link it
was previously routed over, or an outage of the neighboring was previously routed over, or an outage of the neighboring
node). node).
New Flags: Two new flags are defined:
Bandwidth protection: 0x04 Bandwidth protection: 0x04
The PLR will set this when the protected LSP has a backup The PLR will set this when the protected LSP has a backup path
path which provides the desired bandwidth, which is that in which is guaranteed to provide the desired bandwidth specified
the FAST_REROUTE object or the bandwidth of the protected LSP, in the FAST_REROUTE object or the bandwidth of the protected
if no FAST_REROUTE object was included. The PLR may set this LSP, if no FAST_REROUTE object was included. The PLR may set
whenever the desired bandwidth is guaranteed; the PLR MUST set this whenever the desired bandwidth is guaranteed; the PLR
this flag when the desired bandwidth is guaranteed and the MUST set this flag when the desired bandwidth is guaranteed
"bandwidth protection desired" flag was set in the and the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object. SESSION_ATTRIBUTE object. If the requested bandwidth is not
guaranteed, the PLR MUST NOT set this flag.
Node protection: 0x08 Node protection: 0x08
When set, this indicates that the PLR has a backup path The PLR will set this when the protected LSP has a backup path
providing protection against link and node failure on which provides protection against a failure of the next LSR
the corresponding path section. In case the PLR could only 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 a link-protection backup path, the "Local protection setup a link-protection backup path, the "Local protection
available" bit will be set but the "Node protection" bit available" bit will be set but the "Node protection" bit will
will be cleared. be cleared.
3.5. New RRO sub-object: MAX_PROTECTED_BANDWIDTH 5. Head-End Behavior
This sub-object is carried in the RRO object and is optional. An The head-end of an LSP determines whether local protection should
implementation MAY support it. An LSR MUST ignore and silently be requested for that LSP and which local protection technique is
propagate this sub-object, if it is not understood. desired for the protected LSP. The head-end also determines what
constraints should be requested for the backup paths of a protected
LSP.
RRO MAX_PROTECTED_BANDWIDTH sub-object: 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 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.
0 1 2 3 The head-end LSR of a protected LSP MUST set the "label recording
+-------------+-------------+-------------+-------------+ desired" flag in the SESSION_ATTRIBUTE object. This facilitates
| Type | Length | Flags | the use of the facility backup technique. If node protection is
+-------------+-------------+-------------+-------------+ desired, the head-end LSR should set the "node protection desired"
| Bandwidth protection ratio | flag in the SESSION_ATTRIBUTE object; if only link protection is
+-------------+-------------+-------------+-------------+ desired, 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.
Type: 0x04 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 attribute filters, bandwidth, hop-limit
and priorities will be used by the PLRs when determining the backup
paths.
Length: 32 If the head-end LSR desires that the protected LSP be protected via
the one-to-one backup technique, then head-end LSR should include a
FAST_REROUTE object and set the "one-to-one backup desired" flag.
If the head-end LSR desires that the protected LSP be protected via
the facility backup technique, 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 should be treated by PLRs as a lack of preference. If
both flags are set a PLR may use either method or both.
Flags: The head-end LSR of a protected LSP MUST support the additional
flags defined in Section 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.
No Flags are currently defined If the head-end LSR of an LSP determines that local protection is
newly desired, this should be signaled via make-before-break.
Bandwidth protection ratio 6. Point of Local Repair Behavior
Let's call T the bypass tunnel selected for the protected Every LSR along a protected LSP (except the egress) MUST follow the
LSP. The bandwidth protection ratio is the sum of PLR behavior described in this document.
the bandwidths of all the protected LSPs having selected
T as their bypass tunnel / bandwidth of the bypass tunnel T.
The bandwidth protection ratio is a 32-bit IEEE floating
point integer in bytes-per-second.
The minimum value for the protected ratio is 1, which means "the TE A PLR SHOULD support the FAST_REROUTE object, the "local protection
LSP is bandwidth protected". desired", "label recording desired", "node protection 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.
Note that the PLR must select a backup tunnel in such a way that the A PLR MUST consider an LSP as having asked for local protection if
bandwidth protected ratio is 1 for the TE LSP having required the "local protection desired" flag is set in the SESSION_ATTRIBUTE
bandwidth protection in the SESSION_ATTRIBUTE object of their Path object and/or the FAST_REROUTE object is included. If the
message FAST_REROUTE object is included, a PLR SHOULD consider providing
one-to-one protection if the "one-to-one desired" is set and 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. If
the "node protection desired" flag is set, the PLR SHOULD try to
provide node protection; if this is not feasible, the PLR SHOULD
then try to provide link protection.
The bandwidth protected ratio may be used for troubleshooting purpose The following treatment for the RRO IPv4 or IPv6 sub-object's flags
or to trigger appropriate decision the head-end LSR (outside the must be followed if an RRO is included in the protected LSP's RESV
scope of this document). message. Based on this additional information the head-end may
take appropriate actions.
4. Signaling for Backup Path - 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.
- 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 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 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 and, if 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" if the backup path
offers a bandwidth guarantee and, if not, SHOULD clear the
"bandwidth protection" flag. This MUST be done if the "bandwidth
protection desired" flag was set in the SESSION_ATTRIBUTE
object.
6.1 Signaling a Backup Path
A number of objectives must be met to obtain a satisfactory signaling A number of objectives must be met to obtain a satisfactory signaling
solution. These are summarized as follows: solution. These are summarized as follows:
1. Unambiguously and uniquely identify backup paths 1. Unambiguously and uniquely identify backup paths
2. Unambiguously associate protected LSPs with their backup paths 2. Unambiguously associate protected LSPs with their backup paths
3. Work with both global and non-global label spaces 3. Work with both global and non-global label spaces
4. Allow for merging of backup paths 4. Allow for merging of backup paths
5. Maintain RSVP state during and after fail-over. 5. Maintain RSVP state during and after fail-over.
LSP tunnels are identified by a combination of the SESSION and LSP tunnels are identified by a combination of the SESSION and
SENDER_TEMPLATE objects. The relevant fields are as follows. SENDER_TEMPLATE objects. The relevant fields are as follows.
IPv4 tunnel end point address IPv4 (or IPv6) tunnel end point address
IPv4 (or IPv6) address of the egress node for the tunnel.
IPv4 address of the egress node for the tunnel.
Tunnel ID Tunnel ID
A 16-bit identifier used in the SESSION that remains constant A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel. over the life of the tunnel.
Extended Tunnel ID Extended Tunnel ID
A 32-bit identifier used in the SESSION that remains constant A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION
over the life of the tunnel. Normally set to all zeros. Ingress that remains constant over the life of the tunnel. Normally set
nodes that wish to narrow the scope of a SESSION to the to all zeros. Ingress nodes that wish to narrow the scope of a
ingress-egress pair may place their IPv4 address here as a SESSION to the ingress-egress pair may place their IP address
globally unique identifier. here as a globally unique identifier.
IPv4 tunnel sender address IPv4 (or IPv6) tunnel sender address
IPv4 address for a sender node IPv4 (or IPv6) address for a sender node
LSP ID LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC that can be changed to allow a sender to share FILTER_SPEC that can be changed to allow a sender to share
resources with itself. resources with itself.
The first three of these are in the SESSION object and are the basic The first three of these are in the SESSION object and are the basic
identification of the tunnel. The last two are in the identification of 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 take different routes; this is common
when rerouting a tunnel using make-before-break. It is necessary
that a backup path be clearly identified with its protected LSP, so
that correct merging and state treatment can be done. 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 could be varied between a backup path and a protected
LSP is the "IPv4 (or IPv6) tunnel sender address" in the
SENDER_TEMPLATE. SENDER_TEMPLATE.
In particular, setting the "Extended Tunnel ID" to the original IPv4 There are two different methods to uniquely identify a backup
sender address allows the PLR to identify to which protected LSP a path. These are described below.
message (from MP) corresponds. For example, when a Resv message
arrives at the PLR, the Extended Tunnel ID identifies the original
sender, allowing the PLR to identify the state to be refreshed.
4.1. Identification and association of backup paths 6.1.1. Backup Path Identification: 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.
We propose two different approaches to identify backup paths: 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 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].
- Path Message Specific: 6.1.2. Backup Path Identification: Path-Specific
The backup paths use the same SESSION and SENDER_TEMPLATE In this approach, rather than varying the SESSION or
objects as the ones used in the protected LSP. However, the Path SENDER_TEMPLATE objects, a new object, the DETOUR object, is used
messages need to provide enough information that allow the LSRs to distinguish between PATH messages for a backup path and the
to differentiate the backup paths from the protected LSPs. protected LSP.
In case of one-to-one backup, the presence of DETOUR object Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
in Path messages signifies a backup path, while the presence of objects as the ones used in the protected LSP. The presence of
FAST_REROUTE object indicates a protected LSP. DETOUR object in Path messages signifies a backup path; the
presence of FAST_REROUTE object and/or the "local protection
requested" flag in the SESSION_ATTRIBUTE object indicates a
protected LSP.
- Sender-Template Specific: In the path-message-specific approach, when an LSR receives
multiple Path messages which have the same SESSION and
SENDER_TEMPLATE objects and also have the same next-hop, that LSR
must merge the Path messages. Without this behavior, the multiple
RESV messages received back would not be distinguishable as to
which backup path each belongs to. This merging behavior does
reduce the total number of RSVP states inside the network at the
expense of merging LSPs with different EROs.
In this approach, the SESSION object and the LSP_ID are copied 6.2 Procedures for Backup Path Computation
from the protected LSP. The IPv4 tunnel sender address is set
to an 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 the one used in the SENDER_TEMPLATE of the original LSP
tunnel.
In the path-message-specific approach, when an LSR receives multiple Before a PLR can create a detour or a bypass tunnel, the desired
Path message which have the same Session and Sender Template objects explicit route must be determined. This can be done using a CSPF.
and which have the same next-hop, that LSR must merge the Path
messages; without this behavior, the multiple RESV messages received
back would not be distinguishable as to which backup path each
belongs to. This merging behavior does reduce the total number 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 Before CSPF computation, the following information should be
and the backup paths SHOULD use the Shared Explicit (SE) style. This collected at a PLR:
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 to the egress is the same on each LSP to be
merged, as specified in [RSVP].
5. One-to-one backup protection - 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.
In this section, we describe an one-to-one backup method that has the - The downstream links/nodes that we want to protect against. Once
feature to protect both network links and nodes. 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.
To support the one-to-one backup, the users at head-end LSRs must - The upstream uni-directional links that the protected LSP
specify the backup service requirements for the protected LSPs. The passes through. This information is learned from the
LSRs must be able to interface with CSPF to compute the most suitable RECORD_ROUTE objects; it is only needed for setting up
detour route for the protected LSPs. Upon receiving the local one-to-one protection. In the path-specific method, it is
protection requests for a protected LSP, the PLRs must try to necessary to avoid the detour and the protected LSP sharing
establish the detour LSPs immediately. During network failure, the a common next-hop upstream of the failure. In the
PLR must redirect the data packets into the detour LSPs in a timely sender-template-specific mode, this same restriction is
fashion. necessary to avoid sharing bandwidth between the detour and
its protected LSP, where that bandwidth has only been reserved
once.
5.1. Operation Overview - The link attribute filters to be applied. These are derived
from the FAST_REROUTE object, if included in the PATH message,
and the SESSION_ATTRIBUTE object otherwise.
If a one-to-one backup for a protected LSP is explicitly desired, the - The bandwidth to be used is found in the FAST_REROUTE object,
head-end LSR SHOULD insert into the Path message a FAST_REROUTE if included in the PATH message, and in the SESSION_ATTRIBUTE
object, with the "One-to-one Backup desired" flag set. A one-to-one object otherwise. Local policy may modify the bandwidth to be
backup for a protected LSP may also be created based upon a PLR's reserved.
local policy if either the "local protection desired" flag is set in
the SESSION_ATTRIBUTE object or a FAST_REROUTE object is included or
both.
When processed at a PLR, the PLR initiates a detour LSP by sending a - The hop-limit, if a FAST_REROUTE object was included in the
new Path message that contains a DETOUR object. Since an LSP cannot PATH message.
be a protected and a detour LSP at the same time, any Path message
MUST NOT contain both FAST_REROUTE and DETOUR objects,
The LSRs that initiate the detour LSPs SHOULD support both When applying a CSPF algorithm to compute the backup route, the
FAST_REROUTE and DETOUR objects. It is possible that some LSRs along following constraints should be satisfied:
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 the detour LSPs MUST store all received - For detour LSPs, the destination MUST be the tail-end of the
FAST_REROUTE and/or DETOUR objects for Path refreshes. The LSRs must protected LSP; for bypass tunnels (Section 6), the destination
process the detour LSPs independent of the protected LSPs to avoid MUST be the address of the MP.
triggering the LSP loop detection procedure described in [RSVP-TE].
The one-to-one backup can use either path-message-specific or sender- - When setting up one-to-one protection using the path-specific
template-specific to identify the detour LSPs. method, a detour MUST not traverse the upstream links of the
protected LSP in the same direction. This prevents the
possibility of early merging of the detour into the protected
LSP. When setting up one-to-one protection using the
sender-template-specific method, a detour should not traverse
the upstream links of the protected LSP in the same 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.
When using the sender-template-specific approach, the protected and - The backup LSP cannot traverse the downstream node and/or link
detour LSPs should have the "SE Style desired" bit set in the whose failure is being protected against. Note that if the
SESSION_ATTRIBUTE objects. At the MP, the detour LSPs merge into the PLR is the penultimate hop, node protection is not possible
protected LSPs according to the merging rules defined for SE style and only the downstream link can be avoided. The backup path
reservations in [RSVP]. may be computed to be SRLG disjoint from the downstream node
and/or link being avoided.
In the case of one-to-one backup, there is no need for the PLRs to - The backup path must satisfy the resource requirements of the
learn about the backup labels used at the merging points. protected LSP. This SHOULD consider the link attribute
filters, bandwidth, and hop limits determined from the
FAST_REROUTE object and SESSION_ATTRIBUTE object.
5.2. Procedures for the PLR 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 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.
Upon receiving a Path message that contains a FAST_REROUTE object, a 6.3 Signaling Backups for One-To-One Protection
PLR needs to run CPSF based on the information provided in the
FAST_REROUTE, as well as the downstream interface and nexthop router
information, to compute a detour route. More details on CSPF
computation are described in Section 7.
Once a detour is successfully computed and established, the PLR needs Once a PLR has decided to locally protect an LSP with one-to-one
not to compute the detour routes again, unless (1) the contents of backup, and has identified the desired path, it takes the following
FAST_REROUTE have changed, or (2) the downstream interface and/or the steps to signal the detour.
nexthop router for a protected LSP have changed.
After a successful detour computation, the PLR generates a Path The following describes the transformation to be performed upon the
message to setup a detour path. The Path consists of the following: protected LSP's PATH message to create the detour LSP's PATH
message.
- A DETOUR object that specifies the current PLR ID and - If the sender-template specific method is to be used, then the
Avoid Node ID. Only one pair of (PLR_ID, Avoid_Node_ID) PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the
permitted. SENDER_TEMPLATE to an address belonging to the PLR that is not
the same as was used for the protected LSP. Additionally, the
DETOUR object MAY be added to the PATH message.
- An EXPLICIT_ROUTE object toward the egress. The ERO information - If the path-specific method is to be used, then the PLR MUST add
comes from the CSPF computation. a DETOUR object to the PATH message.
- The SENDER_TSPEC object contains the bandwidth information from - The SESSION_ATTRIBUTE flags "Local protection desired",
the previously received FAST_REROUTE objects. "Bandwidth protection desired" and "Node protection desired" MUST
be cleared. The "Label recording desired" flag MAY be modified.
If the Path Message contained a FAST_REROUTE object, and the ERO
is not completely strict, the Include-any, Exclude-any, and
Include-all fields of the FAST_REROUTE object should be copied to
the corresponding fields of the SESSION_ATTRIBUTE object.
- The RSVP_HOP object contains the PLR's IP address. - If the protected LSP's Path message contained a FAST_REROUTE
object, this MUST be removed from the detour LSP's PATH message.
- The detour LSP may generate and process its own RRO object. - 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 FAST_REROUTE object MUST NOT be included. - The SENDER_TSPEC object should contain the bandwidth information
from the received FAST_REROUTE object, if included in the
protected LSP's PATH message.
- When using the sender-template-specific approach, the "IPv4 - The RSVP_HOP object containing one of the PLR's IP address.
tunnel sender address" in the SENDER_TEMPLATE must be set to
an address belonging to the PLR.
- The detour LSPs MUST use the same reservation style as the - The detour LSPs MUST use the same reservation style as the
protected LSP. This must be correctly reflected in the protected LSP. This must be correctly reflected in the
SESSION_ATTRIBUTE object. SESSION_ATTRIBUTE object.
- All other objects SHOULD be identical to those of the protected Detour LSPs are regular LSPs in operation. Once a detour path is
LSP. 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
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 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 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.
This make-before-break mechanism, changing the PLR IP address in
the DETOUR object instead, is not feasible with the path-specific
method because the PATH messages for new and current detour LSPs
may be merged if they share a common next-hop.
6.3.2 Message Handling
LSRs must process the detour LSPs independent 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 The PLR MUST not mix the messages for the protected and the detour
LSPs. When a PLR receives Resv, ResvTear and PathErr messages from LSPs. When a PLR receives Resv, ResvTear and PathErr messages from
the downstream detour destination, the messages MUST not be forwarded the downstream detour destination, the messages MUST not be forwarded
upstream. Similarly, when a PLR receives ResvErr and ResvConf upstream. Similarly, when a PLR receives ResvErr and ResvConf
messages from a protected LSP, it MUST not propagate them onto the messages from a protected LSP, it MUST not propagate them onto the
associated detour LSP. associated detour LSP.
A session tear-down request is normally originated by the sender via A session tear-down request is normally originated by the sender via
PathTear messages. When a PLR node receives a PathTear message from PathTear messages. When a PLR node receives a PathTear message from
upstream, it MUST delete both protected and detour LSPs. The PathTear upstream, it MUST delete both the protected and the detour LSPs. The
messages MUST propagate to both protected and detour LSPs. PathTear messages MUST propagate to both protected and detour LSPs.
During error conditions, the LSRs may send ResvTear messages to fix During error conditions, the LSRs may send ResvTear messages to fix
problems on the failing path. When a PLR node receives the ResvTear 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 messages from downstream for a protected LSP, as long as a detour is
up, the ResvTear messages MUST not sent further upstream. up, the ResvTear messages MUST not be sent further upstream.
PathErrs should be treated similiarly.
5.3. Procedures for the MP using the Path-Specific Approach
An LSR (that is, a MP) may receive multiple Path messages from
different interfaces with identical SESSION and SENDER_TEMPLATE
objects. Path state merging is REQUIRED.
The merging rule is the following:
For all Path messages that do not have either a FAST_REROUTE or a
DETOUR object, or the MP is the egress of the LSP, no merging is
required. The messages are processed according to [RSVP-TE].
Otherwise, the MP MUST record the Path state as well as their
incoming interface. If the Path messages do not share outgoing
interface and next-hop LSR, the MP must consider them as independent
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 select one of
them as the final LSP.
1. Eliminate from consideration those that traverse nodes that other
LSPs want to avoid.
2. If one LSP is originated from this node, this must be
the final LSP. Quit.
3. If only one LSP contains FAST_REROUTE object, this must be the
final LSP. Quit.
4. If there are several LSPs, and not all of them have a DETOUR
object, then eliminate those with DETOUR 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.
6. If none found, prefer the ones without DETOUR object. If none
found, prefer the ones with DETOUR object.
7. If several candidate LSPs still remain, it is a local decision
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.
Once the final LSP has been identified, the MP MUST only transmit the
Path messages that are corresponding to the final LSP. Other LSPs are
considered merged at this node.
The MP may receive PathTear messages for some of the merging LSPs.
No PathTear message should be propagated downstream until the MP has
received tear-down from all merging LSPs.
When an LSR receives a ResvTear for an LSP and it is not a PLR for
that LSP, then the LSR SHOULD propagate the ResvTear towards the
LSP's ingress. For each backup LSP where the LSR is the merge node,
the ResvTear should also be propagated along the backup LSP towards
the backup LSP's ingress, a PLR.
5.3.1. An Example on Path Message Merging
Consider the following example:
G----H----I--\
| | | \
A----B----C----D----E---F
The protected LSP is A-B-C-D-E-F. After running CSPF, let the detour
ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be C-H-I-E-F.
H will receive Path messages that have the same SESSION and
SENDER_TEMPLATE from detours for B and C. During merging at H, since
detour C has a shorter ERO path length (that is, ERO is I-E-F, and
path length is 3), H will select it as the final LSP, and only
propagate its Path messages downstream. Upon receiving a Resv (or a
ResvTear) message, H must relay on the messages toward both B and C.
E needs to merge as well, and will select the main LSP, since it has
the FAST_REROUTE object. Thus, the detour LSP terminates at E.
5.3.2. Creating new DETOUR object at MP
If several LSPs are merged, the MP uses the following algorithm to
format its outgoing DETOUR object for the final LSP:
- If final LSP is protected LSP itself (that is, it contains
FAST_REROUTE object), no DETOUR object needed.
- Otherwise, combine all the (PLR_ID, Avoid_Node_ID) pairs from
all the DETOUR objects of all merged LSPs, and create a new object
with all listed. Ordering is insignificant.
5.4. Local reroute of the traffic onto the detour LSP
Detour LSPs are regular LSPs in operation. They are established as
soon as the protected LSPs are up. During local repair, packets
belonging to a protected LSP are simply switched (for example, label
swapping) onto the corresponding detour LSP. At the Merge Point, the
packets arrived from the detour LSP are merged to the final LSP.
In the example above, if there is a node failure at D, C will switch 6.3.3 Local Reroute of Traffic onto Detour LSP
traffic onto the pre-established detour LSP (C-H-I-E-F). At E, the
traffic switches onto the protected LSP again.
6. Facility protection using label stacked bypass tunnel 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
the protected LSP's normal out-segment. The goal of this technique
is to effect the redirection within 10s of milliseconds.
In this section, we describe a method where a single backup tunnel L32 L33 L34 L35
can be used to protect many LSPs. The LSPs can be protected against R1-------R2-------R3-------R4-------R5
both link and node failures. | |
L46 | L47 | L44
R6---------------R7
Each PLR makes use of one or more NHOP or NNHOP bypass tunnels. Each Protected LSP: [R1->R2->R3->R4->R5]
bypass tunnel will be used to backup a set of protected LSP. Those Detour LSP: [R2->R6->R7->R4]
bypass tunnels may be setup initially or may also be dynamically
setup. The users at head-end initiate the fast reroute process by
setting the appropriated fields in the SESSION_ATTRIBUTE and/or
FAST_REROUTE objects in an LSP's Path messages. At each PLR, one
bypass tunnel is selected to reroute an LSP's data packets in case of
network failure. The process of selecting a bypass tunnel for a
protected LSP is performed by the PLR when the LSP is first setup.
During failure, the PLR reroutes the data packets of each protected Example 3: Redirect to Detour
LSP onto the bypass tunnel. The control messages of the backed-up
LSPs are also sent over the bypass tunnel. The facility backup uses
the sender-template-specific approach to identify the backup tunnels.
6.1. Discovering downstream labels In Example 3 above, 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 link [R2->R6] with label L46 (along the
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 link [R7->R4] with label L44 should be sent out link
[R4->R5] with label L35, and thus merged with the protected LSP.
When global labels are in use at MPs, the PLR may learn backup labels 6.4 Signaling for Facility Protection
in a very efficient manner. The labels are learned during normal
signaling of the protected LSP by observing the contents of the RRO
object in the Resv message.
When a protected LSP is first signaled through a PLR, the PLR can A PLR may use one or more bypass tunnels to protect against the
learn about the incoming labels that are used by all downstream nodes failure of a link and/or a node. These bypass tunnels may be
for this LSP. In particular, it can learn incoming labels used by setup in advance or may be dynamically created as new protected
downstream MPs, whether they are one hop or multiple hops away from LSPs are signaled.
the PLR. The labels are learned during normal signaling of the
protected LSP by observing the contents of the RRO object in the Resv
message.
Two methods are available for discovering/obtaining the label used at 6.4.1. Discovering Downstream Labels
the merge node. One relies on explicit signaling over the bypass
tunnel prior to any failure of the primary path. If the nodes in the
network use a global-to-the-node label space, then the label can be
discovered by using the RRO object without additional signaling.
When this second method is intended, the head-end router includes an To support facility backup, it is necessary for the PLR to
RRO object and sets the label-recording-requested flag in the determine a label which will indicate to the MP that packets
Session_Attribute object. This will cause (as specified in [RSVP- received with that label should be switched along the protected
TE]) all nodes to record their INBOUND labels and to note via a flag LSP. This can be done without explicitly signaling the backup path
if the label is global to the node. if the MP uses a label space global to that LSR.
Note that when global labels are used, no Path message need be sent As described in Section 5, the head-end LSR MUST set the "label
via the bypass tunnel prior to failure. recording requested" flag in the SESSION_ATTRIBUTE object for LSPs
requesting local protection. This will cause (as specified in
[RSVP- TE]) all LSRs to record their INBOUND labels and to note via
a flag if 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.
When MPs use per-interface-label spaces, the PLR must send Path When MPs use per-interface-label spaces, the PLR must send Path
messages (for each Reroutable LSP) via the bypass tunnel prior to the messages (for each protected LSP using a bypass tunnel) via that
failure in order to discover the appropriate MP label. The signaling bypass tunnel prior to the failure in order to discover the
procedures for this are identical to those in section 6.3 below. appropriate MP label. The signaling procedures for this are in
Section 6.4.3 below.
6.2. Procedures for the PLR before fast-reroute
When a protected LSP in first signaled, all the PLRs along the path
which determine 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 a Fast_Reroute object with the Facility-Backup-Desired
flag set, the PLR 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 6.4.2. Procedures for the PLR before Local Repair
appropriate actions.
Note that when global labels are used, no Path message need be sent A PLR which determines to use facility-backup to protect a given
via the bypass tunnel prior to failure. LSP SHOULD select a bypass tunnel to 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.
The selection of a bypass tunnel for a protected LSP is performed
by the PLR when the LSP is first setup.
6.3. Procedures for the PLR during fast-reroute 6.4.3. Procedures for the PLR during Local Repair
When the PLR detects a link or/and node failure condition, it needs 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 to reroute the data traffic onto the bypass tunnel and to start
sending the control traffic for the protected LSP onto the bypass sending the control traffic for the protected LSP onto the bypass
tunnel. tunnel.
The backup tunnel is identified as follows: The backup tunnel is identified 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 unchanged. - The SESSION is unchanged.
- The IPv4 tunnel sender address of the SENDER_TEMPLATE is changed - The SESSION_ATTRIBUTE is unchanged except as follows:
(set to an address belonging to the PLR). The "Local protection desired", "Bandwidth protection desired",
and "Node protection desired" flags SHOULD be cleared.
The "Label recording desired" MAY be modified.
- The RSVP_HOP object must contain the IPv4 source address - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE
(and LIH) of the bypass tunnel. Consequently, the MP will send is set to an address belonging to the PLR.
messages back to the PLR with HOP objects containing this same
IPv4 address.
- The PLR must generate an EXPLICIT_ROUTE object toward the egress. - The RSVP_HOP object must contain an IP source address
Detailed ERO processing is described below. belonging to the PLR. Consequently, the MP will send messages
back to the PLR using as a destination that IP address.
- The RRO object may need to be updated, as described below. - The PLR must generate an EXPLICIT_ROUTE object toward the
egress. Detailed ERO processing is described below.
Messages sent by PLR via the backup tunnel include Path, PathTear, - The RRO object may need to be updated, as described in Section
and ResvConf. Messages sent by MP via the same RSVP_HOP object 6.5.
contents include Resv, and ResvTear.
6.3.1. Processing backup tunnel's ERO The PLR sends Path, PathTear, and ResvConf messages via the backup
tunnel. The MP sends Resv, ResvTear, and PathErr messages by
directly addressing them to the address in the RSVP_HOP object
contents as specified in [RSVP].
Procedures for ERO processing are described in [RSVP-TE]. If normal If it is necessary to signal the backup prior to failure to
ERO processing rules are followed by the Merge Point, and the PLR determine the MP label to use, then the same Path message is sent.
sends a Path message via the backup tunnel, the Merge Point would In this case, the PLR should continue to send Path messages for the
examine the first sub-object and likely reject it (Bad initial sub- protected LSP along the normal route. PathTear messages should be
object). 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 the LSR indicated by the
protected LSP's RSVP_HOP object.
This is because the ERO may contain the IP address of a bypassed node 6.4.4. Processing backup tunnel's ERO
(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 the ERO before sending Path messages onto
Backup Tunnels.
This is done by operating on the original 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
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), or of an interface which is
currently down (in the case of a NHOP Backup Tunnel). For this
reason, the PLR invoke the following ERO procedures before sending a
Path message via a bypass tunnel.
Sub-objects belonging to abstract nodes which precede the Merge Point Sub-objects belonging to abstract nodes which precede the Merge Point
are removed, along with the first Sub-object belonging to the MP. A are removed, along with the first sub-object belonging to the MP. A
Sub-object identifying the Backup Tunnel destination is then added. sub-object identifying the Backup Tunnel destination is then added.
More specifically, the PLR must: More specifically, the PLR must:
- remove all the sub-objects proceeding the first address belonging - remove all the sub-objects proceeding the first address belonging
to the MP. to the MP.
- replace this first MP address with the IP destination address of - replace this first MP address with an IP address of the MP.
the backup tunnel. (Note that this could be same address that was just removed.)
The procedure described above ensures successful ERO processing at
the Merge Point.
6.3.2. Processing backup tunnel's RRO
During fast reroute, for each protected LSP containing an RRO object,
the PLR must update 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, the PLR 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 6.5. PLR Procedures During Local Repair
We will describe how state is maintained using an example: In addition to the technique specific signaling and packet
treatment, there is common signaling which should be followed.
[R8] During fast reroute, for each protected LSP containing an RRO
\ object, the PLR obtains the RRO from the protected LSP's stored
[R1]---[R2]-X--[R3]----[R4]---[R5] RESV and updates it by inserting an IPv4 sub-object with the IPv4
\\ // \ address of the outbound interface address the traffic is forwarded
[R6]===[R7] [R9] onto.
We assume that: 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.
- a bypass tunnel is set up and follows the R2-R6-R7-R4 path; 6.5.1. Notification of local repair
- PLR (R2) performs 1:N protection; In many situations, the route used during a Local Repair will be less
than optimal. The purpose of Local Repair is to keep high priority
and loss sensitive traffic flowing while a more optimal re-routing of
the tunnel can be effected by the head-end of the tunnel. Thus the
head-end needs to know of the failure so it may re-signal an LSP
which is optimal.
- various protected LSPs exist and follow the R2-R3-R4 segment; To provide this notification, the PLR SHOULD send a 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])
Additionally a head-end may also detect that an LSP needs 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 to rely exclusively on Path Error messages
to be informed of failures in another area.
- link R2-R3 fails, and all protected LSPs are rerouted via 6.5.2 Revertive Behavior
the bypass tunnel.
Note that the same procedure as the one described bellow would apply Upon a failure event, a protected TE LSP is locally repaired by the
in case of a node (R3) failure. PLR. There are two basic strategies for restoring the TE LSP to a
full working path.
6.4.1. Path state - 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 -
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.
Path state for every locally repaired LSPs is refreshed downstream by - Local revertive mode: Upon detecting that the resource is
the PLR. These Path messages use a new SENDER_TEMPLATE value (the restored, the PLR re-signals each of TE LSPs that used to be
IPv4 tunnel sender address is set to a PLR address), and are sent routed over the restored resource. Every TE LSP successfully
onto the bypass tunnel with changed PHOP, ERO and RRO. resignaled along the restored resource is switched back.
When a local link fails, there could be some protected LSPs using There are several circumstances where a local revertive mode might
this link. At this point, the LSR MUST NOT remove the state (Path not be desirable. In the case of resource flapping (not an uncommon
and Resv) and send PathTear and ResvErr messages that are failure type), this could generate multiple traffic disruptions.
corresponding to these LSPs immediately. We always assume that these Therefore, in the local revertive mode, the PLR should implement a
LSPs may have been repaired upstream, and new Path messages will soon means to dampen the re-signaling process in order to limit
arrive via the bypass tunnels. potential disruptions due to flapping.
However, the state will be removed if they have not been refreshed by In the local revertive mode, any TE LSP will be switched back,
a PLR after the soft-state lifetime has expired. without any distinction, as opposed to the global revertive mode
where the decision to reuse the restored resource is taken 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 it has a more
complete view of the resources and TE LSP constraints; this means
that the old LSP which has been reverted to may not be optimal any
longer. Note that in the case of inter-area LSP, where the TE LSP
path computation might be done on some Path Computation Server, the
reoptimization process can still be triggered on the Head-End
LSP. The local revertive mode is optional.
6.4.2. Resv state However, there are circumstances where the Head-end does not have
the ability to reroute the TE LSP (e.g if the protected 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 have the
complete TE topology information (depending on the path computation
scenario). In those cases, the local revertive might be a
interesting option.
Resv state is refreshed by the MP by sending Resv messages to the IP It is recommended that one always use the globally revertive mode.
destination contained in the PHOP object of the Path message received Note that a link or node "failure" may be due to the facility being
via the bypass tunnel. 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.
The PLR receives these Resv messages, refreshes the original state Interoperability: If a PLR is configured with the local revertive
(corresponding to the protected LSP), and hence continues refreshing mode but the MP is not, any attempt from the PLR to resignal the TE
the state upstream of the PLR to the head-end. LSP over the restored resource would 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 it will continue to use the backup until it is
re-optimized.
6.5. Local reroute of the traffic onto the bypass tunnel 7. Merge Node Behavior
To perform Local Repair, packets belonging to a protected LSP are An LSR is a Merge Point if it receives the Path message for a
sent on the corresponding backup tunnel in case of local failure. protected LSP and one or more messages for a backup LSP which is
merged into that protected LSP. In the one-to-one backup
technique, the LSR is aware that it is a merge node prior to
failure. In the facility backup technique, 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 is on the path
of a protected LSP SHOULD always assume that it is a merge point.
An additional label (representing the bypass tunnel) is pushed onto When a MP receives a backup LSP's Path message thru a bypass
the stack. At the penultimate hop of the bypass tunnel, the tunnel, the Send_TTL in the Common Header may not match the TTL of
additional label is popped off the stack. The packet thus arrives at the IP packet within which the Path message was transported. This
the Merge Point with the same top-level label it would have carried is expected behavior.
when arriving prior to failure (although it would have arrived on a
different interface prior to failure).
7. Procedures for detour and bypass tunnel computation 7.1. Handling Backup Path Messages Before Failure
To setup the detours described in Section 5 and the bypass tunnels in There are two circumstances where a Merge Point will receive Path
Section 6, CSPF may be used to find the optimal route. Before CSPF messages for a backup path prior to failure. In the first case, if
computation, the following information should be collected at a PLR: a PLR is providing local protection via the one-to-one backup
technique, the detour will be signaled and must be properly handled
by the MP. In this case, the backup LSP may be signaled via the
sender-template-specific method or via the path-specific method.
- The list of downstream nodes that the protected LSP passes In the second case, if the Merge Point does not provide labels
through. This information is readily available from the global to the MP and record them in a Label sub-object of the RRO
RECORD_ROUTE objects during LSP setup. Note, a protected LSP's or if the PLR does not use such recorded information, the PLR may
ERO may not provide adequate information since the LSP could signal the backup path, as described above in Section 6.4.1, to
be a loose routed path. determine the label to use if the PLR is providing protection
according to the facility backup technique. In this case, the
backup LSP is signaled via the sender-template-specific method.
- The downstream links/nodes that we want to protect against. Once The reception of a backup LSP's path message does not indicate that
again, this information is learnt from the RECORD_ROUTE objects. a failure has occured and the incoming protected LSP will no longer
be used.
- The upstream uni-directional links that the protected LSP passes 7.1.1. Merginging Backup Paths using the Sender-Template Specific Method
through, this information is learnt from the RECORD_ROUTE
objects. This information is only needed for setting up
one-to-one protection in path-message-specific approach.
- The LSP resource information, such as bandwidth. Such information An LSR may receive multiple Path messages for one or more backup
can be found in the FAST_REROUTE objects. LSPs and, possibly, 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,
have the "local protection desired" flag set in the
SESSION_ATTRIBUTE object or both.
When applying a CSPF algorithm to compute the backup route, the If the outgoing interface and next-hop LSR are the same, then the
following constraints should be satisfied: Path messages are eligible for merging. As specified in [RSVP],
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.
- The source address of the backup LSP is the current PLR, If merging occurs and all the Path messages were for backup LSPs,
For setting detours (Section 5), the destination MUST be then the DETOUR object, if any, should be altered as specified in
the tail-end of the protected LSP, whereas for setting up Section 8.1
bypass tunnels (Section 6), the destination MUST be the address
of the MP.
- When setting up one-to-one protection using the path-specific 7.1.2. Merging Detours using the Path-Specific Method
approach, a detour MUST not traverse the upstream links of
the protected LSP in the same direction. This prevents the
possibility of early merging of the detour into the protected
LSP.
- The backup LSP cannot traverse the downstream nodes and links An LSR (that is, an MP) may receive multiple Path messages from
that we are trying to protect against. However, if the PLR different interfaces with identical SESSION and SENDER_TEMPLATE
is the penultimate hop, avoid traversing downstream link only. objects. In this case, Path state merging is REQUIRED.
The detour LSP/bypass tunnel may also be SRLG disjoint from
the protected section (see the note at the end of this section).
- The backup path must satisfy the resource requirements of the The merging rule is the following:
protected LSP.
If such computation succeeds, the PLR should trigger RSVP to For all Path messages that do not have either a FAST_REROUTE or a
establish a backup path. The PLR may schedule a re-computation at a DETOUR object, or the MP is the egress of the LSP, no merging is
later time. The backup path should be as short as possible, and must required. The messages are processed according to [RSVP-TE].
merge back into the protected LSP at its MP. If for any reason, 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 the CSPF Otherwise, the MP MUST record the Path state as well as their
computation. For example, a simple method can be to terminate the incoming interface. If the Path messages do not share outgoing
computation as soon as a backup path is found. On the other hand, an interface and next-hop LSR, the MP must consider them as independent
implementation may wish to continue exhaustive search to discover an LSPs, and must not merge them.
optimal path with lowest cost (or highest available bandwidth).
The PLR also has the option to re-compute the backup path For all the Path messages that share the same outgoing interface and
periodically even after the backup is up and running to ensure next-hop LSR, the MP runs the following procedure to select one of
continuous adaptation to the latest network conditions. However, them as the Path message to forward downstream.
during the replacement of a functional backup path with a more
optimal one, the protected LSP may not have any backup path available
for a short interval. Except, if the PLR supports both one-to-one
and facility backup schemes, the protected LSP could be protected by
multiple backup LSPs. In this case, the LSP is fully protected at all
time.
Nevertheless, the exact CSPF algorithms to be used to compute back-up 1. Eliminate from consideration those that traverse nodes that
tunnels or detour LSPs are beyond the scope of this document. Both other Path messages want to avoid.
[OSPF-TE] and [ISIS-TE] may provide more insight on this subject.
Note also that the backup tunnel path computation may be performed by 2. If one LSP is originated from this node, this must be
a centralized path computation server or may use some distributed the final LSP. Quit.
backup path computation algorithms.
7.1. Notion of diverse routing 3. If only one Path message contains FAST_REROUTE object, this
becomes the chosen Path message. Quit.
Two TE LSPs are said link diverse if and only if their paths do not 4. If there are several LSPs, and not all of them have a DETOUR
have any link in common. Two TE LSPs are said node diverse if and object, then eliminate those with DETOUR from consideration.
only if their paths do not have any node in common. It is
straightforward to demonstrate that two node diverse paths are also
link diverse.
To be effective a backup tunnel must imperatively be diversely routed 5. If several candidates remain (that is, there are both detour
from the protected LSP path section it is protecting. That is, a one- and protected LSPs), prefer the ones with FAST_REROUTE object.
hop NHOP backup tunnel path must not contain the protected link. In
the example provided in Section 6, the backup LSP path must not
contain the R2-R3 link. A NNHOP backup tunnel must not contain the
protected link nor the PLR's next hop. In the first example provided
in Section 1, the backup tunnel must not traverse the R2-R3 link nor
the R3 node.
The notion of SRLG diverse path also exists. A set of links 6. If none found, prefer the ones without DETOUR object. If none
constitute a SRLG ("Shared Risk Link Group") if they share a resource found, prefer the ones with DETOUR object.
whose failure may affect all the links in the set. So the backup
tunnel may be SRLG disjoint from the protected LSP path section it is
protecting.
Note that in the case of Path protection, the whole paths of the 7. If several candidate Path message still remain, it is a local
protected LSP and the backup tunnel must be entirely link/node decision to choose which one will be the final LSP. The decision
diverse. can be based on the number of IP hops in ERO, bandwidth
requirements, or others.
Well-known algorithms can be used to compute link/node/SRLG diversely Once the final Path message has been identified, the MP MUST start to
routed paths. 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 bandwidth of the final Path message on that outgoing
interface.
8. Network Failure Detection, Notification and Troubleshooting 7.1.2.1. An Example on Path Message Merging
8.1. Notification of local repair 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]
In many situations, the route used during a Local Repair will be less Example 4: Path Message Merging
than optimal. The point of the Local Repair is to keep high priority
and loss sensitive traffic flowing while a more optimal re-routing of
the tunnel can be effected by the head-end of the tunnel. Thus the
head-end needs to know of the failure so it may re-signal an LSP
which is optimal.
To provide this notification, the PLR SHOULD send a Path Error In Example 4 above, R8 will receive Path messages that have the
message with error code of "Notify" (Error code =25) and an error same SESSION and SENDER_TEMPLATE from detours for R2 and R3.
value field of ss00 cccc cccc cccc where ss=00 and the sub-code = 3 During merging at R8 since detour R3 has a shorter ERO path length
("Tunnel locally repaired") (see [RSVP-TE]) (that is, ERO is [R9->R5->R6], and path length is 3), R8 will
Note also that in the case of inter-area TE LSP (TE LSP spanning select it as the final LSP, and only propagate its Path messages
areas), the head-end LSR will exclusively rely on the Path Error downstream. Upon receiving a Resv (or a ResvTear) message, R8 must
message to be informed that the LSP has suffered a failure if the relay on the messages toward both R2 and R3.
failure occurs in another area than the area it belongs to. In the
case of a failure occurring in the head-end area or in the case of
intra-area TE LSP, the head-end could also detect the TE LSP failure
through the IGP notification.
8.2. Failure detection mechanisms R5 needs to merge as well, and will select the main LSP, since it
has the FAST_REROUTE object. Thus, the detour LSP terminates at
R5.
Link failure detection can be performed through layer-2 failure 7.1.3. Message Handling for Merged Detours
detection mechanism. Node failure detection can be done through IGP
loss of adjacency or RSVP hellos messages extensions as per defined
in [RSVP-TE]. However, it is beyond the scope of this document to
define and describe the exact mechanisms on failure detection.
When a network failure is detected, the PLR MUST immediately switch When an LSR receives a ResvTear for an LSP, the LSR must determine
traffic from the protected LSP to the backup path. At the same time, whether it has an alternate associated LSP. For instance, if the
the PLR MAY send a PathErr messages toward the head-end LSR to notify ResvTear was received for a protected LSP, but an associated backup
the failure condition. The PLR MUST send a RESV with an updated RRO LSP has not received a ResvTear, then the LSR has an alternate
which indicates that local protection is in use. associated LSP. If the LSR does not have an alternate associated
LSP, then the MP MUST propogate the ResvTear toward the LSP's
ingress and, for each backup LSP merged into that LSP at this LSR,
the ResvTear should also be propogated along the backup LSP.
8.3. Troubleshooting of local repair The MP may receive PathTear messages for some of the merging LSPs.
No PathTear message should 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.
For troubleshooting purposes, an RRO object may be inserted in the 7.2. Handling Failures
Path message sent by the head-end. The previously described
mechanisms do not require the Path message to carry an RRO object.
On the other hand, the RRO object MUST be inserted in the Resv
message for the protected LSP if the "Local protection desired" bit
of the SESSION_ATTRIBUTE has been set in the corresponding Path
message, or if FAST_REROUTE object is present in Path messages.
9. Interoperability considerations When a downstream LSR detects a local link failure, for any
protected LSPs routed over the failed link, Path and Resv state
MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be
sent immediately; if this is not the case, then the facility backup
technique will not work. Further a downstream LSR SHOULD reset the
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 to work without requiring that it signal backup paths
thru the bypass tunnel before failure.
The following guidelines are useful when running one-to-one and/or After a failure has occured, the MP must still send Resv messages
facility backups. for the backup LSPs associated with the protected LSPs which 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.
9.1. Requesting local-protection and recognizing those requests 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.
The head-end LSR of a protected LSP MUST either set the "Local 8. Behavior of all LSRs
protection desired" flag in the SESSION_ATTRIBUTE object, or include
the FAST_REROUTE object, or both. A PLR MUST consider that a PATH
message with either a set "Local protection desired" flag in the
SESSION_ATTRIBUTE object, or the presence of the FAST_REROUTE object,
or both to be a request for local protection.
A PLR SHOULD consider the constraints signaled via a received The objects defined and the techniques defined in this document
FAST_REROUTE object, or a received SESSION_ATTRIBUTE object require behavior from all LSRs in the traffic-engineered network,
(Bandwidth and Node protection constraints on the bypass tunnel can even if that LSR is not along the path of a protected LSP.
also be specified by setting the "Bandwidth protection desired" and
"Node protection desired" bits in the SESSION_ATTRIBUTE object), when
determining the backup path to use. If signaled backup constraints
and bandwidth are desired, the PATH message SHOULD contain the
FAST_REROUTE object.
A head-end LSR MUST set the "Label recording desired" flag in the First, if a DETOUR object is included in the backup LSP's path
SESSION_ATTRIBUTE object if a backup tunnel through a bypass tunnel message for the sender-template-specific method, the LSRs in the
is desired. traffic-engineered network should support the DETOUR object.
If local protection was not requested for the current LSP of a tunnel Second, if the Path-Specific Method is to be supported for
and it is then desired for that tunnel, the head-end LSR MUST send a the one-to-one backup technique, it is necessary that the LSRs in
new Path message reflecting the change ("Local protection desired" the traffic-engineered network be capable of merging detours as
flag set in the SESSION_ATTRIBUTE object or include a FAST_REROUTE specified below in Section 8.1.
object). When a node detects a change in the SESSION_ATTRIBUTE object
it SHOULD forward the Path message immediately.
9.2. Backups for local protection It is possible to avoid specific LSRs which do not support this
behavior by assigning an link attribute to all the links of those
LSPs and then requesting that backup paths exclude that link
attribute.
A PLR that recognizes that local protection is required on a 8.1. Merging Detours in Path-Specific Method
protected LSP MUST try to protect 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 If multiple Path Messages for different detours are received with
backup, or facility backup, or both, it is up to the network the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop
operators to decide which backup mechanism to use. LSR, then the LSR must function as a Detour Merge Point and merge
the detour Path Messages. This merging should occur as specified
in Section 7.1.2 and shown in Example 4.
When using both schemes, the PLR has the option to backup data In addition, it is necessary to update the DETOUR object to reflect
traffic on an one-to-one detour LSP, as well as on a bypass tunnel. the merging which has taken place. This is done using the
In case of a network failure, the PLR can re-reroute traffic using following algorithm to format the outgoing DETOUR object for the
one of the two backup path initially. If the backup path failed also, final LSP:
the other backup path can be used to re-reroute user traffic.
If no established detour LSP or backup tunnel exists, or the detour - Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the
LSP and the backup tunnel is in "DOWN" state, the PLR MUST clear the DETOUR objects of all merged LSPs, and create a new object with
"local protection available" flag in its IPv4 (or IPv6) address all listed. Ordering is insignificant.
subobject of the RRO and SHOULD send the updated RESV. When a detour
LSP or backup tunnel 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. Security Considerations 9. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RSVP] remain considerations pertaining to the original RSVP protocol [RSVP] remain
relevant. relevant.
11. IANA Guidelines 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 IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and
DETOUR objects. Currently, in production networks, FAST_REROUTE uses DETOUR objects. Currently, in production networks, FAST_REROUTE uses
C-class 205, and DETOUR uses C-class 63. C-class 205, and DETOUR uses C-class 63.
12. Intellectual Property Considerations 11. Intellectual Property Considerations
Cisco Systems and Juniper Networks may have intellectual property Cisco Systems and Juniper Networks may have intellectual property
rights claimed in regard to some of the specification contained in rights claimed in regard to some of the specification contained in
this document this document
13. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at page 31, line 33 skipping to change at page 33, line 15
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Acknowledgments 13. Acknowledgments
We acknowledge the helpful comments from Arthi Ayyangar, Riza Cetin, We would like to acknowledge input and helpful comments from Rob
Rob Goguen, Carol Iturralde, Kireeti Kompella, Manoj Leelanivas, Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially,
Yakov Rekhter and Nischal Sheth. 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,
and Richard Southern.
15. References 14. References
[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
-- version 1 functional specification," RFC2205, September 1997. -- version 1 functional specification," RFC2205, September 1997.
[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC3029, December 2001. tunnels", RFC3029, December 2001.
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft- [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF,
katz-yeung-ospf-traffic-05.txt, June 2001. draft-katz-yeung-ospf-traffic-05.txt, June 2001.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-tr affic-03.txt, June 2001. ietf-isis-tr affic-03.txt, June 2001.
[RSVP-REFRESH] L. Berger, et al, "RSVP Refresh Overhead Reduction
Extensions", RFC2961.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434. IANA Considerations Section in RFCs", RFC 2434.
16. Author Information 15. Author Information
Ping Pan Ping Pan
Juniper Networks CIENA Corp.
1194 N.Mathilda Ave 10480 Ridgeview Court
Sunnyvale, CA 94089 Cupertino, CA 95014
e-mail: pingpan@juniper.net e-mail: ppan@ciena.net
phone: +1 408 745 3704 phone: +1 408 366 4991
Der-Hwa Gan Der-Hwa Gan
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: dhg@juniper.net e-mail: dhg@juniper.net
phone: +1 408 745 2074 phone: +1 408 745 2074
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
email: swallow@cisco.com email: swallow@cisco.com
phone: +1 978 244 8143 phone: +1 978 244 8143
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
11, rue Camille Desmoulins 300 Apollo Drive
92782 Issy les Moulineaux Cedex 9, Chelmsford, MA 01824
France email: jpv@cisco.com
email: jvasseur@cisco.com phone: +1 978 497 6238
phone: +33 689108267
Dave Cooper Dave Cooper
Global Crossing Global Crossing
960 Hamlin Court 960 Hamlin Court
Sunnyvale, CA 94089 Sunnyvale, CA 94089
email: dcooper@gblx.net email: dcooper@gblx.net
phone: +1 916 415 0437 phone: +1 916 415 0437
Alia Atlas Alia Atlas
Avici Systems Avici Systems
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/