Internet Draft Akber Qureshi Ramesh Nagarajan Expires April 2003 Y.T. Wang Sandy Goldfless Lucent Technologies October 2002 MPLS-TE Shared Mesh Protection 1. 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. 2. Abstract This document discusses the shared mesh protection concept. Its aim is to provide fast, guaranteed recovery of service at significantly less cost of protection capacity compared to other schemes. In companion documents [1,2], extensions to RSVP-TE and OSPF-TE protocols are proposed that enable shared mesh protection. Those extensions, together with this document, first address global repair with path-based protection switching, as opposed to local repair of LSP failures and reroute. However, the concept can be extended straightforwardly to the local repair techniques being considered in the MPLS working group. 3. Purpose of This Document The purpose of this document is to introduce and discuss the concept of path-based shared mesh protection. The document discusses this specific protection switching recovery scheme with shared-resource in terms of recovery path resource usage as outlined in the MPLS WG shared-mesh-protection-Goldfless October 2002 draft-qureshi-mpls-shared-protection-00.txt [Page 2] draft on the framework for MPLS-based recovery [3]. It provides input to the MPLS Working Group for making recommendations to respective working groups for protocol extensions in supporting shared mesh protection [1],[2]. 4. Introduction In [3], the framework for MPLS-based recovery was presented, including outlines of principles, methods, and comparison criteria for evaluating different recovery schemes. Some form of protection bandwidth sharing and signaling support have been previously discussed in [4],[5]. In this document, the shared mesh protection concept is discussed which is applicable to the global repair topologically and to the 1- to-1, n-to-1 and n-to-m protections from path mapping perspective discussed in [3]. To guarantee the recovery and to maintain the performance of the service, sufficient resource needs to be available at the setup time of the protection LSPs. However it may or may not require reseravation for additional protection bandwidth. Indeed the key observation is that the need for reservation of protection bandwidth depends on whether there is already sufficient protection capacity set aside to protect other connections which do not belong to the same shared risk groups (SRGs)with the new primary connection. Thus the shared mesh protection scheme can significantly reduce the required network protection capacity. Once a failure of a primary path (in the path-based case), is identified, the protection LSP for the affected working LSP is activated with just enough reserved protection bandwidth to guarantee failure recovery. Speed of recovery is supported by using fast failure notification schemes (which are beyond the scope of this document). 5. Shared Mesh Protection Path-based protection schemes such as 1-to-1 or n-to-1 consider the protection of service traffic between two particular nodes. To provide protection of a working connection, guaranteed recovery with similar grade of service and sufficient amount of bandwidth must be set aside in the network. This can be achieved by computing and reserving required protection capacity at the same time that computation and activation of the working connection is performed. For path-based schemes, arrival of a request to establish shared mesh protection service between two nodes can prompt computation of a pair shared-mesh-protection-Goldfless October 2002 draft-qureshi-mpls-shared-protection-00.txt [Page 3] of disjoint connections between them. The primary and protection connections would be set up, meeting the following two necessary requirements. First, sufficient bandwidth should be available along the route of the working connection to accommodate the requested load. Second, either of the following two conditions must hold: either whatever bandwidth for protection had previously been reserved along the protection path is already sufficient to guarantee recovery from any single link or node failure along the new working path, or there must be enough available bandwidth along the protection path to accommodate the additional reservation. From the point of view of the network, the degree to which the additional bandwidth for protection should be shared in this manner depends on the failure coverage objective for the particular LSP: whether the objective for the LSP is protection against failure of any single node, of any single link, or of an SRG. 6. Need for RSVP-TE Extensions The computation of the protection path can be done in several ways depending on the available information. The simplest way is to calculate a disjoint path using the same link weights as the ones used for calculation of the primary path. In this case each router along the protection path needs to know about the primary path for which it is requested to protect. Further, knowing the primary path along each node of the protection path allows the admission controller of that node to determine, using locally maintained sharing information, the exact amount of bandwidth required and that which can be shared. Outgoing interface ID's are required to be communicated in addition to the router ID's. Details regarding the proposed RSVP-TE extensions to support sharing of protection resources can be found in [1] which addresses the requirements brought forth first in [5]. 7. Need for OSPF-TE Extensions While some sharing of protection bandwidth may be realized with the proposed extensions of RSVP-TE [1], the amount of bandwidth reserved for restoration is "best effort" and usually not minimized since the sharing potential on each of the links is not known before the protection path choice is made at the source router. Additional protection resource and sharing information of the network would be required for the source router to compute more intelligently the desired protection path which was first discussed in [5]. The proposed extensions to OSPF-TE [2] addresses this need and allow the source router compute the primary and protection path combination that utilizes the network resources efficiently with minimum signaling/crankback load. shared-mesh-protection-Goldfless October 2002 draft-qureshi-mpls-shared-protection-00.txt [Page 4] 8.0. References [1] Hua Autumn Liu, et al, "RSVP-TE Extension for Shared Mesh Protection", IETF draft-liu-rsvp-mpls-shared-protection-00.txt, Oct. 2002 [2] Ajay Sathyanath, et al, "OSPF-TE Extension for Shared Mesh Protection", IETF draft-sathyanath-ospf-mpls-shared-protection- 00.txt, Oct. 2002 [3] Vishal Sharma, Fiffi Hellstrand, (editors), "Framework for MPLS-based Recovery," IETF draft-ietf-mpls-recovery- frmwrk-08.txt, Oct.,2002 [4] J-P Vasseur, et.al., "Traffic Engineering Fast Reroute: Backup tunnel path computation for bandwdith protection," IETF draft- vasseur-mpls-backup-computation-00.txt, June 2002 [5] S. Kini, et.al., "Shared Backup Label Switched Path Restoration," IETF draft-kini-restoration-shared-backup-01.txt, May 2001 9. Author Information Akber Qureshi Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: mqureshi@lucent.com phone: +1 732 949 4791 Ramesh Nagarajan Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: rameshn@lucent.com phone: +1 732 949 2761 Y.T. Wang Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: ytwang@lucent.com phone: +1 732 949 0676 Sandy Goldfless Lucent Technologies 1 Robbins Rd. Westford, MA 10886 shared-mesh-protection-Goldfless October 2002 draft-qureshi-mpls-shared-protection-00.txt [Page 5] e-mail: sgoldfless@lucent.com phone: +1 978 952 7512 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 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. shared-mesh-protection-Goldfless October 2002