Internet DRAFT - draft-chang-mpls-rsvpte-path-protection-ext
draft-chang-mpls-rsvpte-path-protection-ext
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
July 2001
Huang et al. Expires December 2000 [Page 14]
IETF Draft Ken Owens
Multi-Protocol Label Switching Erlang Technology, Inc.
Expires: August 2002 Vishal Sharma
Metanoia, Inc.
Srinivas Makam
Ben Mack-Crane
Tellabs Operations, Inc.
Changcheng Huang
Carleton University
Bora Akyol
Pluris, Inc.
July 2001
Extensions to RSVP-TE for MPLS Path Protection
<draft-chang-mpls-rsvpte-path-protection-ext-02.txt
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ôwork in progress.ö
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
To deliver reliable service, multi-protocol label switching (MPLS)
requires a set of procedures to enable -protection of the traffic
carried on - label switched paths (LSPs). Thus existing signaling
mechanisms must be extended appropriately to support such
functionality. Recently, RSVP-TE [1] has introduced extensions to
RSVP to support the establishment of LSP tunnels. This draft extends
RSVP-TE to support path protection [2] in MPLS. Specifically, we
provide signaling support for establishing backup LSPs and for
propagating fault notification upon LSP failure.
Table of Contents Page
1. Motivation 2
2. Purpose of this Document 2
3. Background 3
4. Terminology 4
5. Extensions to Support Protection Domain Configuration 4
5.1 EXPLICIT ROUTE PROTECTION sub-object 5
5.2 PATH PROTECTION object 6
5.2.1 RNT Type 7
5.2.2 Hold-off and Wait-to-rstore Timer Options 7
5.2.3 Flags 8
5.3 Error Codes for ERO 8
6. Fault Notification Message 9
6.1 Extensions to Support Hop-by-Hop Fault Notification 10
6.2 Extensions to Support Notification Via Dedicated LSPs 11
7. Open Issues 12
8. Security Concerns 13
9. Acknowledgements 13
10. AuthorsÆ Addresses 13
11. References 13
1. Motivation
Recently, there has been considerable standards activity within the
IETF towards establishing a recovery framework for MPLS [3], and
towards devising recovery mechanisms for MPLS-based networks [2],
[4], [5], [7], [8], [9] and, lately, also for intelligent optical
networks [6]. A number of these proposals have considered path-based
recovery. There is, therefore, a need to appropriately extend
existing signaling protocols to facilitate the operation of these
path-based recovery mechanisms.
Since RSVP-TE has been devised specifically to support the
establishment of LSP tunnels and provides some limited support for
local repair, a logical choice is to extend it to support path
protection as well.
2. Purpose of this Document
The purpose of this document is to extend RSVP-TE to support path
protection in MPLS networks. Although we focus here on the path
protection mechanism proposed in [2], several of the extensions that
we introduce are general, and are applicable to any path-based
recovery scheme; for example, optical lightpath recovery. The major
differences between this 01 version and the previous 00 version are:
-- Bits defined in the ERO subject replaced by a new ERO sub-object
-- Define new Protection Object that is embeded in the ERO sub-
object
-- More encoding details
3. Background
RSVP-TE [1] extends the RSVP protocol to support the establishment of
LSP tunnels. New objects that have been added for this purpose
include RECORD-ROUTE, SESSION-ATTRIBUTE, EXPLICIT-ROUTE, LABEL-
REQUEST and LABEL. To create an LSP tunnel, the sender node creates
an RSVP Path message with a LABEL-REQUEST object. If the sender
wishes the Path message to follow a pre-determined route, it uses an
EXPLICIT-ROUTE object to identify the route. The destination node of
a label-switched path responds to a LABEL-REQUEST by allocating a
label and including a LABEL object in the RSVP Resv message that it
sends in response to the Path message. The Resv message is sent back
upstream by following, in reverse order, the path state that was
created by the Path message on its way downstream.
Although RSVP-TE offers some support for reliability, such as a Hello
message for detecting link failures and an option in the SESSION-
ATTRIBUTE object that allows for local repair, it still does not
provide adequate support to allow for the operation of a path
protection mechanism [2]. In this draft, we introduce extensions to
RSVP-TE to enable support of MPLS path protection. Specifically, we
propose the following:
-- Adding an Explicit Route PROTECTION sub-object to the ERO to
allow for the identification of the endpoints (the path switch
LSR (PSL) and the path merge LSR (PML)) of a protected path or
path segment (protection domain).
-- Adding PATH PROTECTION object to the path message to help
configure a protection domain.
-- Adding Path Protection Error Codes
-- Adding a LABEL-REQUEST object in the Resv message and a LABEL
object in the Confirmation message to support the establishment
of a layer 2 path for propagating fault related
notification(s). This is needed because RSVP-TE does not
currently provide a mechanism to implement a reverse
notification tree (RNT) [2] via the establishment of point-to-
multi-point LSPs. As will be seen later, in some circumstances
having a RNT implementation based on layer 2 forwarding can
substantially speed up notification by eliminating the need to
process the notification message at intermediate nodes.
-- Adding a Notification message to carry the fault information
signal (FIS) and the fault recovery signal (FRS).
4. Terminology
The terminology used in our draft follows that defined in [1], [2]
and [3]. We will repeat some of the important terms here for the
convenience of the reader.
PSL: Path Switch LSR. A PSL is defined as an LSR that originates both
the working and the recovery paths of a protected LSP. The PSL is the
source of the recovery path.
PML: Path Merge LSR. A PML is defined as an LSR that receives both
the working and the recovery paths of a protected LSP. The PML is the
destination of the recovery path.
RNT: Reverse Notification Tree. An RNT is used to notify all upstream
neighbors of a node that has detected a fault.
Virtually Merged LSPs: A collection of LSPs that belong to the same
RSVP session, and all of which terminate at the same destination, and
share a common route from some point towards that destination.
5. Extensions to Support Protection Domain Configuration
One of the first requirements for a path-based protection scheme is
the configuration of a protection domain [3], namely the
identification and configuration of the set of LSRs (or OXCs in an
agile optical network) that are the end-points of the protected LSP
or LSP segment (or optical trail). In addition, for a path-based
protection mechanism [2] it is also necessary to identify the node(s)
that will serve as the root(s) of the reverse notification tree(s)
(RNT), and to identify the node(s) (PMLs) that will merge traffic
from the working and protection paths [2]. The configuration of the
protection domain ideally occurs in conjunction with the
establishment of the working path. (Note that in a path-based scheme,
the protection path may be pre-configured or may be configured after
the fault is detected and a notification communicated to the path
switch LSR (PSL), which is responsible for switching traffic from the
failed working path to the protection/backup path.)
RSVP allows the path to be specified loosely (each node determines
itÆs next hop) or explicitly (each node has been given itÆs next
hop). In either case, the ERO object is used. An Explicit Route
Protection sub-object is being defined as an extension to the
existing RSVP ERO message fields. The origination or PSL node in the
MPLS network participates in setting up the working and protection
paths. The destination or PML point node in the MPLS network
participates in setting up a recovery path as a merging network
switch element. The PSL learns the working and protection paths that
are merged to the same outgoing network switch element during
signaling or working/protection path configuration process.
5.1 EXPLICIT ROUTE PROTECTION sub-object
A new sub-object of the ERO is used to identify the PSL and PML. The
PATH PROTECTION sub-object has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |P| Prot. Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH PROTECTION Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This subobject could be strict or loose (i.e., the L bit could be 0
or 1). The Type is 5 (Explicit Route Protection). The Length is 12
P
Whether this element is the PSL or PML. 0 denotes PSL.
Protection Type
The protection type this particular working and protection path
pair supports. The current values) are (future values are for FFS):
0000000 1+1
0000001 1:1
Router ID
The elementÆs Router ID. The EXPLICIT ROUTE PROTECTION sub-object
must follow the appropriate ERO Subobject to identify the
PSL/PML[2].
PATH PROTECTION
The PSL, after processing the EXPLICIT ROUTE PROTECTION sub-object,
will add the PATH PROTECTION Object to the Path Message. The PML,
after processing the EXPLICIT ROUTE PROTECTION sub-object, will
remove the PATH PROTECTION Object from the Path Message.
5.2 PATH PROTECTION object
A Path message travels from a sender to receiver(s) along the same
path(s) used by the data packets. The IP source address of a Path
message must be an address of the sender it describes, while the
destination address must be the DestAddress for the session. These
addresses assure that the message will be correctly routed through a
non-RSVP cloud.
The nodes that the Path message travels from a sender to receiver(s)
may not need path protection for the entire path. The PSL, after
processing the EXPLICIT ROUTE PROTECTION sub-object, will insert the
PATH PROTECTION object into the Path message. Therefore, only the
nodes that are part of the protection domain receive informational
elements in regard to protection. The PML, after processing the
EXPLICIT ROUTE PROTECTION sub-object, will remove the PATH PROTECTION
object from the Path message.
The format of an RSVP Path message with the Path Protection Object
extension is:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <TIME_VALUES> ]
[ <EXPLICIT_ROUTE> ]
[ <PATH PROTECTION> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The presence of this object specifies that protection is supported.
The following table illustrates the structure of the Path Protection
Object.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RNTT |Holdoff Option | WTR Option |R|Flags | RESVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the attibutes are equal to:
Length is 8, Class is 0bbbbbbb (TBD), C-type is 1.
RNTT
Specifies how the notification is implemented .
Hold-off Timer Option
Specifies the hold-off time requirements.
Wait-to-Restore Timer Option
Specifies the wait-to-restore time requirements.
Revertive Option
Specifies whether the recovery action is revertive.
Flags
Specifies whether the Path message is for the working path or
protection path.
RESVD
Reserved for Future Use
5.2.1 RNT Type
Specifies whether the RNT is implemented as a Hop-by-hop (Layer 3)
LSP, as an MPLS (Layer 2) LSP, or over SONET K1/K2 bytes.The default
is Hop-by-hop, 000. Other valid values:
001 MPLS LSP
010 SONET K1/K2
5.2.2 Hold-off and Wait-to-restore Timer Options
In order to give lower layers (i.e. SONET) time to perform
restoration, the timer options specify the hold-off and wait-to-
restore time requirements. Since each element along the path must be
able to support the timer options when specified, the options must be
specified in the PATH message. The defaults (although could be
operator defined) for the timer options are:
00000000 No timer requirements
00000001 50ms timer requirements
00000010 100ms timer requirements
00001011 1s timer requirements
00001100 2s timer requirements
00010100 10s timer requirements
01000110 1m timer requirements
01001111 10m timer requirements
11111111 Policy Derived Timer Requirements
5.2.3 Flags
The following flags are defined:
0x01 Working Path Enabled
This flag permits the ingress node or the PSL to identify that
the Path Message is for the working path
0x02 Protection Path Enabled
This flag permits the ingress node or the PSL to identify that
the Path Message is for the protection/recovery path.
0x04 Extra Traffic
This flag permits the protection links to carry extra traffic.
This flag is an indication that any resourvces allocated to
this protection path are available to be used by other traffic,
however it does not necessarly mean that the extra traffic will
use the same labels as the protection path.
5.3 Error Codes for ERO
In the processing described above, certain errors must be reported as
a ôRouting Problemö. The value of the ôRouting Problemö error code is
24.
The following defines error values for the Routing Problem Error
Code:
Value Error:
11 Bad EXPLICIT_ROUTE Protection sub-object
12 Bad PSL node
13 Bad PML node
14 Protection Mechanism not supported
6. Fault Notification Message
A second requirement for a path protection mechanism is to have an
appropriately defined message that is used to convey fault
information from the point of failure to the node responsible for
initiating recovery action(s). The notification information should
enable each intermediate node (lying between the point of failure and
the protection switch LSR) to unambiguously identify the LSPs
affected by the failure, and enable it to forward this information to
the appropriate nodes further upstream. Ideally, MPLS would have some
sort of OAM functionality for this purpose. Since MPLS lacks OAM
functionality, this section presents a solution.
Although the PathErr message could be enhanced to support fault
notification, such enhancements may require significant changes to
the format and behavior of the PathErr message, as explained below.
-- A PathErr message is typically sent in response to a Path message.
A notification message, on the other hand, needs to be sent as soon
as the fault is detected, and should not need to wait for the arrival
of the next Path message. Thus, adapting Path Err for notification
would require a change in the way the Path Err message is currently
handled. Although it is possible to change the semantics of the
PathErr message to be sent as soon as a fault is detected, this
unnecessarily overloads the meaning of the PathErr message.
-- Furthermore, as per the current RSVP specifications,a Path Err
message is forwarded hop-by-hop (with attendant processing). This
limits the notification mechanism to the hop-by-hop approach. As we
explain in Section 5, for a faster response, it may be advantageous
to have the option to set up a point-to-multipoint LSP as a
realization of an RNT.
-- Yet another observation is that merely extending the Error Value
field of the ERROR SPEC object in the Path Err message is not
sufficient to convey the required fault notification-related
information. Thus, a new object needs to be defined to carry this
additional information in any case. Adding this to the Path Err
message would require an intermediate node to differentiate between a
normal Path Err message and one carrying fault notification
information. Thus, it is cleaner to have a separate message for doing
so, since it provides a general notification structure that can be
used by either hop-by-hop or LSP-based forwarding.
Therefore, we define a new notification message as follows:
<Notification Message>::= <Common Header> [ <INTEGRITY> ]
<SESSION> <List of NOTIFICATION
objects>
[<POLICY-DATA>à]
[<sender descriptor>]
<sender descriptor> ::= <SE/FE flow descriptor>
The NOTIFICATION objects are defined as follows:
Class =? C-type =1 for IPv4 failure notification
C-type =2 for Ipv4 recovery notification
+---------+----------+----------+----------+
| Ipv4 Failure Detection Node ID |
+------------------------------------------|
| MPLS Label of a Working Path |
+---------+----------+----------+----------+
| |
// Labels of Other Working Paths //
| |
+---------+----------+----------+----------+
Class =? C-type =3 for Ipv6 failure notification
C-type =4 for Ipv6 recovery notification
+---------+----------+----------+----------+
| |
| Ipv6 Failure Detection Node ID |
| |
| |
+---------+----------+----------+----------+
| MPLS Label of a Working Path |
+---------+----------+----------+----------+
| |
// Labels of Other Working Paths //
| |
+---------+----------+----------+----------+
on message may either be conveyed hop-by-hop (involving some amount
of processing and modification at each hop) or it may be conveyed by
using a layer 2 label switched path, which we call the MPLS LSP
approach.
Observe that in essence what the notification objects describe, is
the content and format of the fault notification information. When
using RSVP-TE they are sent as RSVP messages, but when using a
different signaling protocol or method, they could as easily be sent
by encapsulating them in a format appropriate for the signaling
protocol or method (for example, SONET overhead bytes) used.
6.1 Extensions to support hop-by-hop fault notification
The hop-by-hop approach of transporting a notification message can
be supported with minimal changes, and multiple sessions can share
the same message on a particular link. In this case, however,
notification messages have to be processed at each node and therefore
introduce extra delay. Upon the occurrence of a failure the
propagation of LSAs may cause unstable states. Observe that a hop-by-
hop notification message has to compete with the propagation of
routing information, which can potentially result in an unpredictable
situation (this could be mitigated by delaying the propagation of
LSAs via some holdoff mechanism).
The easiest way to support hop-by-hop fault notification is to send a
Notification message hop-by-hop. A node detecting a fault generates a
Notification message. The node must identify all of the working LSPs
affected by the fault (which may not be in the same session), insert
in the Notification object(s) the labels used by the upstream node(s)
to identify these LSPs, and forward the Notification message to the
corresponding upstream node(s). Each intermediate node examines the
NOTIFICATION object list to learn of all the affected working paths
and their corresponding upstream interfaces. Those interfaces will
then repack their own Notification messages with the labels used by
their upstream neighbors to identify these LSPs, and in turn forward
the Notification message to their own upstream neighbors. This
process continues at successive nodes, until a PSL is reached. The
PSL removes the labels of the working paths that it originates, and
itself forwards the message as an intermediate node, until the last
NOTIFICATION object has been removed. Notification messages should be
encapsulated in a raw IP packet, with their destination address set
equal to the RSVP PHOP.
6.2 Extensions to Support Notification Via Dedicated LSPs
Currently, RSVP-TE supports two styles of reservation, namely FF and
SE. While FF can only support point-to-point LSPs (because it creates
a distinct reservation for the traffic from each sender that is not
shared by other senders), SE can have different options, such as
supporting an LSP per sender or a multipoint-to-point (merged) LSP.
Although there is a single reservation on a link for all the senders
in SE, since each sender is explicitly listed in the RESV message,
different labels may be assigned to different senders, thereby
creating different LSPs. In the latter case, these different LSPs
(which share some links in common) maybe diversely routed at the
downstream links. It is, therefore, difficult to ûshare a
notification message for different LSPs on a particular link without
examining the payload of the notification message at each hop. This
is because not all LSPs sharing a link may need to be notified if a
failure (which may have occurred upstream of this shared link on a
diversely routed segment) does not affect all LSPs. Therefore, the
RNT is a general mechanism that can support either a single point-to-
point LSP or a merged LSP. In general, therefore, for notification
via dedicated LSPs, different working LSPs must use different RNTs.
But if LSPs that belong to the same session form a tree structure
(without necessarily merging at the point of convergence), they too
can share an RNT. We will call such LSPs virtually merged.
To setup a dedicated LSP (point-to-point or merged) for suporting a
RNT, the root of the RNT should insert LABEL-REQUEST object and RESV-
CONFIRM object in the Resv message that it receives from the down
stream node before forwarding it to the upstream node. (Recall that
the root of the RNT need not be the destination of the LSPs, nor need
it be a PML.)
The PSL receiving this message will allocate a label, generate a
Confirmation message, insert a LABEL object in that message and
forward it to the downstream node. Each intermediate node will
replace the label with a newly allocated label and forward it to the
next downstream node. The root of the RNT will terminate the message.
Since a multipoint-to-point LSP should share the same RNT, when an
intermediate node finds that the labels of the working path are
merged on the downstream link, and a label has already been allocated
for the protection path on that downstream link (by a Confirmation
message from a different source on the multi-point to point LSP that
passed through this node earlier), it should terminate the
Confirmation message.
Virtually merged LSPs should also share the same RNT. When an
intermediate node finds that a label for the protection path is
already allocated for the same working session (by a Confirmation
message from the source of a different virtually merged LSP), it too
should terminate the Confirmation message.
Each node on the protected path should maintain an inverse cross-
connect table [2] The key used to index the inverse-crossconnect
table depends on whether the node lies on a single point-to-point or
point-to-multipoint working LSP, or on several virtually merged
working LSPs. For a single point-to-point LSP or for a point-to-
multipoint LSP, the node can use the egress label as an index.
Similarly for virtually merged LSPs it can reference the session ID
as an index into the inverse crossconnect table.
Upon the occurrence of a fault, the node detecting the fault
identifies the working paths affected by the fault. It then uses its
inverse cross-connect table to identify their corresponding RNTs. The
node then generates a Notification message for each RNT and sends it
over the LSP dedicated to that RNT. The Notification message should
at least carry the Node ID of the node detecting the fault.
Intermediate nodes forward the message as normal MPLS packets, using
normal label swapping. The PSL that terminates an RNT path also
terminates the Notification message and starts protection switching
process. The Notification message should be encapsulated by an MPLS
layer frame (e.g. the shim header). No extra IP encapsulation is
required.
7. Open Issues
Extensions to support using SONET or WDM layer for notification need
further study.
8. Security Concerns
This Internet Draft does not introduce additional security concerns
to signaling in MPLS networks other than those identified in [1].
9. Acknowledgements
We would like to thank Neil Harrison, Dave Allan, and J. Noel
Chiappa, and Ben Mack-Crane for useful discussions on MPLS
protection, which were helpful in articulating some of the ideas in
this draft.
10. AuthorsÆ Addresses
Changcheng Huang Vishal Sharma
Department of Systems and Computer Metanoia, Inc.
Engineering
Carleton University 335 Elan Village Lane
1125 Colonel By Drive Unit 203
Ottawa, Ontario K1S 5B6 San Jose, CA 95134-2539
Phone: (613) 520-2600 ext. 2477 Phone: 408-943-1794
v.sharma@ieee.org
Srinivas Makam Ken Owens
Tellabs Operations, Inc. Erlang Technology, Inc.
4951 Indiana Avenue 1106 Fourth Street
Lisle, IL 60532 St. Louis, MO 63126
Srinivas.Makam@tellabs.com keno@erlangtech.com
Ph: 630-512-7217 Phone: 314-918-1579
Bora Akyol Ben Mack-Crane
Pluris, Inc. Tellabs Operations, Inc.
10455 Bandley Drive 4951 Indiana Avenue
Cupertino, CA 95014 Lisle, IL 60532
Akyol@pluris.com Ben.Mackcrane@tellabs.com
Ph: 408-861-3302 Ph: 630-848-7875
11. References
_______________________________
[1] Awduche, D, et al, ôRSVP-TE: Extensions to RSVP for LSP Tunnels,ö
Internet Draft, Work in Progress, draft-ietf-mpls-revp-lsp-tunnel-
07.txt, August 2000.
[2] Huang, C., Sharma, V., Makam, V., and Owens, K., ôA Path
Protection Mechanism for MPLS networks,ö Internet Draft, Work in
Progress, draft-chang-mpls-path-protection-02.txt, November 2000.
[3] Makam, S. et al, ôA Framework for MPLS-based Recovery,ö Work in
Progress, Internet Draft, draft-ietf-mpls-recovery-frmwrk-00.txt,
September 2000.
[4] Shew, S. ôFast Restoration of MPLS Label Switched Paths,ö Work in
Progress, Internet Draft, <draft-shew-lsp-restoration-00.txt>,
October 1999.
[5] Goguen, R. and Swallow, G., ôRSVP Label Allocation for Backup
Tunnelsö, draft-swallow-rsvp-bypass-label-00.txt, work in
progress, October 1999.
[6] Luciani, J., et al, ôIP over Optical Networks û A Framework,ö
Work in Progress, Internet Draft, draft-many-ip-optical-framework-
01.txt, July 2000.
[7] Hellstrand, F. and Andersson, L.,öExtensions to CR-LDP and RSVP-
TE for setup of pre-established recovery tunnelsö, Work in
Progress, Internet Draft, draft-hellstrand-mpls-recovery-merge-
00.txt, July 2000.
[8] Kini, S., et al, ôShared backup Label Switched Path restorationö,
Work in Progress, Internet Draft, draft-kini-restoration-shared-
backup-00.txt, November 2000.
[9] Kini, S., et al, ôReSerVation Protocol with Traffic Engineering
extensions. Extension for Label Switched Path restorationö, Work
in Progress, Internet Draft, draft-kini-rsvp-lsp-restoration-
00.txt, November 2000.
