IETF Draft Vishal Sharma
Multi-Protocol Label Switching Srinivas Makam
Expires: May 2001 Ken Owens
Ben Mack-Crane
Tellabs Operations, Inc.
Changcheng Huang
Carleton University
Bora Akyol
Pluris, Inc.
November 2000
Extensions to RSVP-TE for MPLS Path Protection
<draft-chang-mpls-rsvpte-path-protection-ext-01.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.
Huang, et al [Page 1] IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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:
Huang et al. Expires December 2000 [Page 2]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
-- 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.
Huang et al. Expires December 2000 [Page 3]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
-- 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
Huang et al. Expires December 2000 [Page 4] IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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.
Huang et al. Expires December 2000 [Page 5]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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 .
Huang et al. Expires December 2000 [Page 6]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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
Huang et al. Expires December 2000 [Page 7] IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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
Huang et al. Expires December 2000 [Page 8]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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>
Huang et al. Expires December 2000 [Page 9]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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
Huang et al. Expires December 2000 [Page 10]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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
Huang et al. Expires December 2000 [Page 11]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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.
Huang et al. Expires December 2000 [Page 12] IETF Draft Extensions to RSVP-TE for MPLS Path Protection
November 2000
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 Tellabs Research Center
Computer Engineering
Carleton University One Kendall Square
1125 Colonel By Drive Bldg. 100, Ste. 121
Ottawa, Ontario K1S 5B6 Cambridge, MA 02139-1562
Phone: (613) 520-2600 ext. 2477 Vishal.Sharma@tellabs.com
Phone: 617-577-8760
Srinivas Makam Ken Owens
Tellabs Operations, Inc. Tellabs Operations, Inc.
4951 Indiana Avenue 1106 Fourth Street
Lisle, IL 60532 St. Louis, MO 63126
Srinivas.Makam@tellabs.com Ken.Owens@tellabs.com
Ph: 630-512-7217 Phone: 314-918-1579
Bora Akyol
Pluris, Inc.
10455 Bandley Drive
Cupertino, CA 95014
Akyol@pluris.com
Ph: 408-861-3302
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.
Huang et al. Expires December 2000 [Page 13]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection
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.
Huang et al. Expires December 2000 [Page 14]