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.