Internet Draft
IETF Draft Changcheng Huang
Multi-Protocol Label Switching Vishal Sharma
Expires: December 2000 Srinivas Makam
Ken Owens
Tellabs Operations, Inc.
Bora Akyol
Pluris, Inc.
June 2000
Extensions to RSVP-TE for MPLS Path Protection
<draft-chang-mpls-rsvpte-path-protection-ext-00.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 working and protection
LSPs and for propagating fault notification upon LSP failure.
Huang et al. Expires December 2000 [Page 1]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
Table of Contents
1. Motivation
2. Purpose of this Document
3. Background
4. Terminology
5. Extensions for Protection Domain Configuration
6. Fault Notification Message
7.1. Extensions to Support Hop-by-Hop Fault Notification
7.2. Extensions to Support Notification Via Dedicated LSPs
8. Open Issues
9. Security Concerns
10. Acknowledgements
11. AuthorsĘ Addresses
121. References
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] 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.
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
Huang et al. Expires December 2000 [Page 2]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
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 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 new attributes to the EXPLICIT_ROUTE object (ERO) to help
configure a protection domain. This allows for the identification of
the protected LSP(s), and the identification of the endpoints (the
protection switch LSR (PSL) and the protection merge LSR (PML)) of a
protected path or path segment.
-- 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.
PML: Path Merge LSR. A PML is defined as an LSR that receives both
the working and the recovery paths of a protected LSP.
RNT: Reverse Notification Tree. A special point-to-multipoint LSP to
transport fault notification messages for a multipoint-to-point
working LSP.
Virtually Merged LSPs: A collection of LSPs that belong to the same
RSVP session, and all of which form a tree structure and terminate at
the same destination, but they are not physically merged.
Huang et al. Expires December 2000 [Page 3]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
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 transit-points of the protected
LSP or LSP segment (or optical trail) and protection 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)(PSL) that will execute protection switching
from a working path to a protection path. Sometimes it maybe also
necessary to identify the nodes which merge traffic from the working
and protection paths, that is the PMLs [2]. The configuration of the
protection domain 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 PSL)
Since it is unlikely that the working and protection paths will be
established by using normal routing, we will assume that a protection
domain will be configured by using the explicit route object (ERO) in
the Path message of RSVP_TE. This is because the working and
protection paths will likely be computed by intelligent on-line or
off-line algorithms, and will, therefore, need to be explicitly
specified during the setup phase. The last octet of the current sub-
objects in the ERO is not defined. Therefore, we propose to use this
octet by defining its unused bits as follows:
Bit Number Purpose Value
Bit 0 Notification Enabling 1= notification
(indicates whether this is a required
hop which has to generate fault 0= notification
notification) not required
Bit 1 Protection Path Indicator 1 = protection
(Indicates whether the current path
node lies on the protection 0 = regular path
path)
Bit 2 PSL 1 = yes
(Indicates whether the current 0 = no
node is a PSL)
Bit 3 PML 1 = yes
(Indicates whether the current 0=no
node is a PML)
Bit 4 RNT Root 1 = yes
(Indicates whether the current 0 = no
node is the root of an RNT)
Huang et al. Expires December 2000 [Page 4]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
Bits 5 to 7 Codepoint for the notification 000 = Hop-by-Hop
mechanism used. 001 = MPLS LSP for
(Identifies the type of virtually merged
notification mechanism that 010 = MPLS LSP for
will be used) physically merged
011 = SONET K1, K2
bytes (FFS).
If a node identified by an ERO does not support a protection
attribute described above, a PathErr message should be returned to
the source node, with error code "Routing Problem Error" and error
value Bad EXPLICIT ROUTE Attributes.
Following the approach in [1], the working and protection LSPs will
share the same Session ID but will use different LSP IDs. The Path
message for the protection LSPs will travel from the ingress node of
the protection LSP (which is also the ingress node of its associated
working LSP)to the egress node of the protection LSP (which is also
the egress node of its associated working LSP). The Resv message will
follow the same path but in the reverse order. An egress node can
decide on the reservation style for a particular LSP in the following
way. If the LSP is a LSP that requires notification (bit 0=1), the
egress node of the working path should terminate the Path message and
return a RESV message requesting the shared explicit (SE) reservation
style. Similarly, if the LSP is a protection LSP (bit 1=1), the
egress node of the protection path (which is also the egress node of
its corresponding working path) should again request the SE
reservation style. This will avoid reserving bandwidth redundantly.
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.
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 PathErr for notification
would require a change in the way the PathErr 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
Huang et al. Expires December 2000 [Page 5]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
unnecessarily overloads the meaning of the PathErr message.
-- Furthermore, as per the current RSVP specification, a PathErr
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 7.1, 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 PathErr 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 PathErr
message would require an intermediate node to differentiate between a
normal PathErr 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:
::= [ ]
[...]
[]
::=
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 |
Huang et al. Expires December 2000 [Page 6]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
+---------+----------+----------+----------+
| |
// Labels of Other Working Paths //
| |
+---------+----------+----------+----------+
Upon the occurrence of a fault, the notification 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 hop-by-hop they are sent as RSVP messages, but when using a
different notification protocol or method, they could as easily be
sent by encapsulating them in a format appropriate for the
notification protocol or method (for example, MPLS packets, SONET
overhead bytes) used.
7.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 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.
7.2 Extensions to Support Notification Via Dedicated LSPs
Huang et al. Expires December 2000 [Page 7]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
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), SE can have
different options, such as supporting an LSP per sender or a
multipoint-to-point 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 may 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 downstream
of this shared link on a diversely routed segment) does not affect
all LSPs. In general, the RNT mechanism described in [2] can only
support either a single point-to-point LSP or a multipoint-to-point
LSP. 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 point-to-multipoint) for
supporting 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 multipoint-to-point LSP that
passed through this node earlier), it should copy the label and
forward the Confirmation message to the next downstream node, this
process will continue until it reaches the root of the RNT.
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 also copy the label and forward the Confirmation message to
the next downstream node.
Huang et al. Expires December 2000 [Page 8]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
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
multipoint-to-point working LSP, or on several virtually merged
working LSPs. For a single point-to-point LSP or for a multipoint-
to-point LSP, the node can use the egress label of the working path
as a key. For virtually merged LSPs it can use the session ID as a
key 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.
8. Open Issues
Extensions to support using SONET or WDM layer for notification need
further study.
9. Security Concerns
This Internet Draft does not introduce additional security concerns
to signaling in MPLS networks other than those identified in [1].
10. 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.
11. AuthorsĘ Addresses
Changcheng Huang Vishal Sharma
Tellabs Operations, Inc. Tellabs Research Center
4951 Indiana Avenue One Kendall Square
Lisle, IL 60532 Bldg. 100, Ste. 121
Changcheng.Huang@tellabs.com Cambridge, MA 02139-1562
Ph: 630-512-7954 Vishal.Sharma@tellabs.com
Phone: 617-577-8760
Srinivas Makam Ken Owens
Tellabs Operations, Inc. Tellabs Operations, Inc.
Huang et al. Expires December 2000 [Page 9]
IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000
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
12. 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-
05.txt, February, 1999.
[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-00.txt, March 2000.
[3] Makam, S. et al, "A Framework for MPLS-based Recovery", Work in
Progress, Internet Draft, draft-makam-mpls-recovery-frmwrk-00.txt,
March 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-ip-optical-framework-00.txt,
March 2000.