Internet Draft 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. 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]