Internet Draft
Internet Engineering Task Force                            Ram Krishnan
Internet Draft                                           Dimitry Haskin
Expires: December 1999                                 Nexabit Networks

                                                              June 1999

        Extensions to RSVP to Handle Establishment of Alternate
                 Label-Switched Paths for Fast Re-route

               draft-krishnan-mpls-reroute-rsvpext-00.txt

Status

   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

   This document describes the extensions that enables RSVP to
   support creation of an alternative label switched path to handle
   fast data packet reroute upon failure in a primary label switched
   path in an Multi-protocol Label Switching (MPLS) network as
   described in [3]. As such, this draft is a companion draft to [3].
   The proposed extensions present no backward compatibility issues.

Haskin, Krishnan        Expires December 1999                [Page 1]

Draft      draft-krishnan-mpls-fast-reroute-rsvpext-00.txt  June 1999

1. Introduction

   A mechanism to establish an alternate label-switched path (LSP) that
   is used for quickly re-routing traffic in the event of a network
   element failure or congestion along the primary LSP is described in
   [3]. Only one alternate LSP needs to be created in this approach as
   opposed to an approach that requires multiple alternate LSPs to be
   created at each intermediate switch along the LSP. Such an approach
   reduces computational complexity and the associated signalling
   overhead. It is required that the alternate backup LSP does not
   share any network elements (links or label-switched routers (LSR))
   with the exception of the source and destination LSRs of the primary
   LSP.

   This document defines objects necessary for signalling the creation
   and establishment of the alternate LSP when the primary and
   alternative LSPs are initiated from a single router using RSVP [4].

2. Description of the Approach

   The main idea behind the approach in [3]is to redirect traffic at
   the point of failure in the primary LSP back to the source end-point
   of the primary LSP in the reverse direction after which the traffic
   flow is sent along via the alternate disjoint LSP between source and
   destination switches of the protected primary LSP.

   Referring to Figure 1, there is an MPLS network consisting of 7
   interconnected switches.

   Figure 1:

            +--------+   24   +--------+   46   +--------+
        +-->| Switch |------->| Switch |------->| Switch |---+
        :   |   2    |--------|   4    |--------|   6    |   :
        :   |        |        |        |        |        |   :
     12 :   +--------+        +--------+        +--------+   :
        :       /               /                 /      \   :
        :      /               /                 /        \  V
      +--------+   31   +--------+   53   +--------+   75  +--------+
      | Switch |<-------| Switch |<-------| Switch |<......| Switch |
      |   1    |--------|   3    |--------|   5    |-------|   7    |
    =>|        |=======>|        |=======>|        |======>|        |=>
      +--------+   13   +--------+   35   +--------+   57  +--------+

   A primary LSP between switches 1 and 7 is shown by a double-dashed
   links labeled 13, 35, and 57. Arrows indicate direction of the data
   traffic.

 Krishnan, Haskin       Expires December 1999                [Page 2]

Draft      draft-krishnan-mpls-fast-reroute-rsvpext-00.txt  June 1999

   The initial segment of the alternative LSP runs between the
   destination LSR and the source LSR in the reverse direction of the
   primary path traversing through every switch between the last hop
   switch and the source LSR. The dashed line between switches 5 and 1
   illustrates such a segment of the alternative path.

   The second and final segment of the alternative path is set between
   the source switch and the destination switch along a transmission
   path disjoint from the primary LSP. The dashed line between Switches
   1 and 7 through Switches 2, 4, and 6 illustrates the final segment
   of the alternative LSP.

   The initial and final segments of the alternative path are linked to
   form an entire alternative path from the last hop switch to the
   destination switch. In Figure 1 the entire alternative path consists
   of the LSP links labeled 53, 31, 12, 24, 46, and 46 if the
   alternative path originates at the last hop switch.

   As soon as a link failure or congestion along the protected path is
   detected an operational switch at ingress of failed link reroutes
   incoming traffic around of the failure or congestion by linking
   upstream portion of the primary path to the downstream portion of
   the alternative path. Thus if the link between Switches 3 and 5
   fails, the primary and alternative paths are linked at Switch 3
   forming the following label switched path for the traffic flow:
   13->31->12->24->46->67.

3. Extensions to RSVP for Alternate LSP Establishment

   Clearly, a label-switched path needs to be set up similar to the
   establishment of the primary LSP. The presence of LABEL-REQ object
   in the PATH message and LABEL object in the RESV message enables the
   downstream-on-demand label allocation policy by which the labels are
   exchanged among the neighbors. As shown in Figure 1, the alternate
   LSP is composed of two components: the disjoint segment between the
   source end-point and the destination end-point of the primary LSP
   (12->24->46-67 in the example) and the segment in the reverse
   direction between the destination end-point and the source end-point
   traversing the same network elements as the primary LSP (75->53-
   >31).

3.1 Establishing the Disjoint Segment of the Alternate LSP.

     No new RSVP objects are necessary for establishing the disjoint
    segment of the alternate LSP. Procedures similar to the creation of
    the primary LSP can be used to establish this disjoint segment. As
    mentioned earlier, care should be exercised to make sure that this
    segment of the alternate path is completely disjoint from the
    primary LSP. For instance, the disjoint segment can be explicitly
    specified using the Explicit Route Object (ERO) in the PATH message
    [4].

 Krishnan, Haskin       Expires December 1999                [Page 3]

Draft      draft-krishnan-mpls-fast-reroute-rsvpext-00.txt  June 1999

3.2 Establishing the Reverse Segment of the Alternate LSP.

   New RSVP objects are required in the PATH and RESV messages to
   establish the reverse segment of the alternate LSP.

   A new Flag option is defined in the Flags field of the SESSION-
   ATTRIBUTE object that specifies Fast-reroute based on reverse-path
   setup.

   Flags

     0x08 = Fast reroute based on reverse-path alternate LSP. When this
   flag is set, all transit LSRs set up an alternate LSP based on the
   mechanism specified in this document.

   Two new optional objects are required: a REVERSE-LABEL-REQ object in
   the RESV message and REVERSE-LABEL object in the PATH message are
   used for setting up the reverse segment of the alternate LSP. The
   term REVERSE refers to the establishment of an alternate LSP in the
   reverse direction of the primary LSP. The function and format of
   these objects are similar to the LABEL-REQ and the LABEL object used
   to set-up the primary LSP.

   When the destination end-point of the primary LSP receives a PATH
   message consisting of the SESSION-ATTRIBUTE object, it includes the
   optional REVERSE-LABEL-REQ object in the corresponding RESV message
   if Fast-reroute is enabled in the SESSION-ATTRIBUTE object. Each LSR
   in the path of the primary LSP allocates a label for the reverse
   segment of the alternate LSP and stores the label in the PSB for
   inclusion in the corresponding PATH message. An LSR that receives a
   RESV message with the REVERSE-LABEL-REQ object should allocate and
   include the REVERSE-LABEL object in the corresponding PATH message,
   unless it is unable to allocate a label in the specified label range
   in the REVERSE-LABEL-REQ object. In that case, the LSR should send a
   PATHERR message with the appropriate error codes.

   REVERSE-LABEL object

   REVERSE-LABEL Class = [TBD] C-Type = 1

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length(bytes)           |  Class-Num    |     C-Type    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                       (Object contents)                     //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          (top label)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Krishnan, Haskin       Expires December 1999                [Page 4]

Draft      draft-krishnan-mpls-fast-reroute-rsvpext-00.txt  June 1999

   The contents of the REVERSE-LABEL object are a stack of labels, and
   the top of the stack is in the right four octets of the contents.

   REVERSE-LABEL-REQ object

   REVERSE-LABEL-REQ Class = [TBD] C-Type = 1

   The format of the REVERSE-LABEL-REQ object is similar to that of the
   LABEL-REQ object with the exception of the Class number. Three
   possible C-Types are supported: Label request without a label range,
   Label request with an ATM label range and a Label request with a
   Frame Relay label range.

   The source end-point of the LSP allocates a label in the PATH
   message for the reverse segment of the alternate LSP, in response to
   a label request from its downstream neighbor.  This label is used as
   the incoming label in its cross-connect table while the outgoing
   label used by the source end-point is allocated by its immediate
   downstream neighbor in the disjoint segment of the alternate LSP.
   The proposed extensions are backward compatible with those LSRs that
   do not recognize the optional REVERSE-LABEL_REQ and REVERSE-LABEL
   objects.

4. References

   [1] Rosen, E. et al., "Multiprotocol Label Switching Architecture",
   Internet Draft, draft-ietf-mpls-arch-05.txt, April 1999.

   [2] Awduche, D. et al., "Requirements for Traffic Engineering over
   MPLS", Internet Draft, draft-ietf-mpls-traffic-eng-00.txt, October
   1998.

   [3] Haskin, D. et al., öA Method for Setting an Alternate Label-
   Switched Paths to Handle Fast Re-routeö, work in progress, draft-
   haskin-fast-reroute-00.txt, May 1999.

   [4] Awduche, D. et al., öExtensions to RSVP for LSP tunnelsö, work
   in progress, draft-ietf-mpls-rsvp-lsp-tunnel-01.txt, March 1999.

 Krishnan, Haskin       Expires December 1999                [Page 5]

Draft      draft-krishnan-mpls-fast-reroute-rsvpext-00.txt  June 1999

5. Authors' Addresses

   Ram Krishnan
   Nexabit Networks, Inc.
   200 Nickerson Road
   Marlborough, MA 01752
   E-mail: ram@nexabit.com

   Dimitry Haskin
   Nexabit Networks, Inc.
   200 Nickerson Road
   Marlborough, MA 01752
   E-mail: dhaskin@nexabit.com

 Krishnan, Haskin       Expires December 1999                [Page 6]