Internet Draft                                          Sriganesh Kini
Expires : April, 2001                                   Murali Kodialam
<draft-kini-rsvp-lsp-restoration-00.txt>                T.V.Lakshman
                                                        - Bell Labs

                                                        Curtis Villamizar
                                                        - Avici Systems

         ReSerVation Protocol with Traffic Engineering extensions.
           Extension for Label Switched Path restoration

                  draft-kini-rsvp-lsp-restoration-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

   Traffic engineering using MPLS involves the setting up of label
   switched paths (LSP) possibly with explicit routing and with bandwidth
   guarantees. The reliability of these LSPs can be increased by providing
   a backup LSP onto which traffic can be switched upon failure of an
   element in the path of the active LSP. Backup LSPs can be routed in a
   way that bandwidth can be shared between backup links of more than one
   active path while still guaranteeing recoverability for a set of
   failures. This sharing greatly increases the network efficiency thereby
   increasing the number of LSPs that can be carried while maintaining
   guarantees. Algorithms which can route such recoverable LSPs while
   using only aggregate network usage information are being developed.
   Keeping these algorithms as the primary motivation this document
   describes a mechanism to signal shared backup LSPs using RSVP.







S. Kini, et al           Expires April, 2001                        [Page 1]


Internet Draft     draft-kini-rsvp-lsp-restoration-00.txt      November 2000

1. Introduction

   The concept of sharing links along backup paths is explained in [3].
   RSVP (as described in [1]) with the extensions (as described in [2])
   is used to signal a LSP. This document proposes further extensions RSVP.
   These extensions are useful to signal shared backup LSPs.

2. Extensions to RSVP-TE

2.1 Backup LSP Information Object

   A new type of object "Backup LSP Information Object" is defined.

   Four new C-Types are defined

2.1.1 Type of LSP C-Type = 1

   0 = Active path
   1 = Backup path

   This is a one byte length field.

   When the status changes from backup to active path the node should
   allocate bandwidth as if this path is an active path.

2.1.2 Route of Active Path C-Type = 2

   The route of the active LSP is specified in the Path message during the
   setup of the backup LSP using the Route of Active Path C-Type = 2.

   The format is same as ERO Class = 20 and C-Type = 1.

   Processing :
   This object should be forwarded unchanged to the next hop.
   Changes in Route of Active Path C-Type = 2 :
   A change in this object SHOULD result in deallocation of previously
   allocated bandwith for backup path and then reallocate bandwidth
   for this backup LSP.

2.1.3 Failure Entity C-Type = 3

   The entity(ies) whose failure has to be protected against, is listed
   using the sub objects given below. If this information is conveyed in
   Path messages of the backup path then they can be used to allocate
   bandwidth for backup paths by sharing it between different backup
   paths. A failure entity set is used to denote a grouping for which a
   backup route can be specified. This object only needs to be sent in the
   path messages of the active path. The first node in the ERO for failure
   entity should setup the backup path for the failure entity set. If no
   ERO is given for the failure entity set the node adjacent to the first
   object of the failure entity (or the first object of the failure entity
   set) should setup the backup LSP.


S. Kini, et al           Expires April, 2001                        [Page 2]


Internet Draft     draft-kini-rsvp-lsp-restoration-00.txt      November 2000


   Five types of subobjects are currently defined.

2.1.3.1 Subobject 1: Link wih IPv4 address

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Length    | IPv4 address (4 bytes)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv4 address (continued)      | Prefix Length |      Flags    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         0x01  IPv4 address of the link

      Length

         The Length contains the total length of the subobject in bytes,
         including the Type and Length fields. A length of 2 denotes
         that every link has to be protected. Otherwise the length is 8.

      IPv4 address

         A 32-bit unicast, host address.  Any network-reachable
         interface address is allowed here.  Illegal addresses,
         such as certain loopback addresses, SHOULD NOT be used.

      Prefix length

          A prefix length of 32 denotes a specific link.

      Flags

         0x01  Start of failure entity set
         0x02  End of failure entity set

2.1.3.2 Subobject 2: Link with IPv6 address

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Length    | IPv6 address (16 bytes)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)      | Prefix Length |      Flags    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

S. Kini, et al           Expires April, 2001                        [Page 3]


Internet Draft     draft-kini-rsvp-lsp-restoration-00.txt      November 2000

      Type

         0x02  IPv6 address

      Length

         The Length contains the total length of the subobject in
         bytes, including the Type and Length fields. A length of 2 denotes
         that every link has to be protected. Otherwise the length is 20.

      IPv6 address

         A 128-bit unicast host address.

      Prefix length

         A prefix length of 128 denotes a specific link.

      Flags

         0x01  Start of failure entity set
         0x02  End of failure entity set


2.1.3.3 Subobject 3: Node wih IPv4 address

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Length    | IPv4 address (4 bytes)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv4 address (continued)      | Prefix Length |      Flags    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         0x03  IPv4 address (any address of the node)

      Length

         The Length contains the total length of the subobject in
         bytes, including the Type and Length fields. A length of 2 denotes
         that every node has to be protected. Otherwise the length is 8.

      IPv4 address

         A 32-bit unicast, host address.  Any network-reachable
         interface address is allowed here.  Illegal addresses,
         such as certain loopback addresses, SHOULD NOT be used.

      Prefix length

         A prefix length of 32 denotes a specific node.

S. Kini, et al           Expires April, 2001                        [Page 4]


Internet Draft     draft-kini-rsvp-lsp-restoration-00.txt      November 2000

      Flags

         0x01  Start of failure entity set
         0x02  End of failure entity set


2.1.3.4 Subobject 4: Node with IPv6 address

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Length    | IPv6 address (16 bytes)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IPv6 address (continued)      | Prefix Length |      Flags    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         0x04  IPv6 address (any address of the node)

      Length

         The Length contains the total length of the subobject in
         bytes, including the Type and Length fields. A length of 2 denotes
         that every node has to be protected. Otherwise the length is 20.

      IPv6 address

         A 128-bit unicast host address.

      Prefix length

         A prefix length of 128 denotes a specific node.

      Flags

         0x01  Start of failure entity set
         0x02  End of failure entity set










S. Kini, et al           Expires April, 2001                        [Page 5]


Internet Draft     draft-kini-rsvp-lsp-restoration-00.txt      November 2000

2.1.3.5 Subobject 5 : SRLG

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Length    | SRLG (4 bytes)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | SRLG (continued)              | Reserved      |      Flags    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         0x05  SRLG

      Length

         The Length contains the total length of the subobject in
         bytes, including the Type and Length fields. A length of 2 denotes
         that every SRLG has to be protected. Otherwise the length is 8.

      SRLG

         A 32-bit SRLG.

      Flags

         0x01  Start of failure entity set
         0x02  End of failure entity set

2.1.3.6 Subobject 6 : ERO for that failure entity set

      Denotes the Explicit route for that failure entity set. Should
      immediately follow the failure entity set. Format same as that
      described in section 4.3 of [2].

2.1.4 Active path session id C-Type = 5

     Same as the session object as described in 4.6.1 of [2]. Should
     be included in all messages signaling the backup path.

2.1.5 Active path sender Template C-Type = 6

     Same as the sender template object as described in 4.6.2 of [2].
     Should be included in all messages signaling the backup path.

3. Security Considerations

   This document raises no new security issues for RSVP.

4. IANA Considerations

   The value of the new object "Backup LSP Information Object" should be


S. Kini, et al           Expires April, 2001                        [Page 6]


Internet Draft     draft-kini-rsvp-lsp-restoration-00.txt      November 2000

   assigned by IANA. The value should be assigned so that the object is
   forwarded unchanged by a node which does not understand the object.

5. Acknowledgments

   The authors would like to thank Vishal Sharma and Roch Guerin for their
   comments on this work.

6. References

   [1] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource
       ReSerVation Protocol (RSVP) -- Version 1 Functional
       Specification", RFC 2205, September 1997.

   [2] Awduche, D.O, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnesl",
       Internet Draft <draft-ietf-mpls-rsvp-lsp-tunnel-06.txt>, July 2000.

   [3] Kini. S, et al, "Shared backup Label Switched Path restoration",
       Work in progress, Internet Draft <draft-kini-restoration-shared-
       backup-00.txt>. November 2000.

7. Author's Addresses

   Sriganesh Kini
   Lucent Technologies, Bell Labs
   Room 4C-526, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   Phone : 732 949 6418
   Email : kini@dnrc.bell-labs.com

   Murali Kodialam
   Lucent Technologies, Bell Labs
   Room 4D-525, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   Phone : 732 949 6296
   Email : muralik@dnrc.bell-labs.com

   T.V.Lakshman
   Lucent Technologies, Bell Labs
   Room 4D-531, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   Phone : 732 949 4778
   Email : lakshman@dnrc.bell-labs.com

   Curtis Villamizar
   Avici Systems
   Email : curtis@avici.com







S. Kini, et al           Expires April, 2001                        [Page 7]


Internet Draft     draft-kini-rsvp-lsp-restoration-00.txt      November 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."


























S. Kini, et al           Expires April, 2001                        [Page 8]