[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
    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]