MPLS Working Group S. Kini Internet Draft S. Narayanan Intended Status: Standards Track Ericsson Expires: September 2011 March 7, 2011 MPLS Fast Reroute using extensions to LDP draft-kini-mpls-frr-ldp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 This Internet-Draft will expire on September 7, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kini & Narayanan Expires May 28, 2011 [Page 1] Internet Draft FRR for LDP Mar 7, 2011 Abstract LDP is widely deployed in MPLS networks to signal LSPs. Since LDP establishes LSPs along IGP routed paths, its failure recovery is gated by IGP's re-convergence. Mechanisms such as IPFRR and RSVP-TE based FRR have been used to provide faster re-route for LDP LSPs. However these techniques have significant complexity and/or may not have full coverage. In this document we describe a method to perform fast re-route of LDP LSPs. The goal is to have recovery characteristics similar to the methods in [RSVP-TE-FRR] without depending on additional protocols but at the same time provide full coverage. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. LDP Local Repair Technique . . . . . . . . . . . . . . . . . . 3 6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 10.1. Normative References . . . . . . . . . . . . . . . . . . 4 10.1. Informative References . . . . . . . . . . . . . . . . . 5 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Kini & Narayanan Expires May 28, 2011 [Page 2] Internet Draft FRR for LDP Mar 7, 2011 1. Introduction LDP is a widely deployed signaling protocol in MPLS networks. It signals LSPs along IGP routed paths. In case of a failure in the network, the recovery of traffic on LDP LSPs is gated by re- convergence of IGPs. IGPs have relatively slower convergence since it is affected by factors such as link-state database flooding, re- computation etc. Approaches such as [IPFRR-LFA] can provide an alternate route that may be used by LDP. However this method does not provide full coverage. Other IPFRR methods such as [NOT-VIA] involve significant complexity. Another approach to protect LDP LSPs is to use RSVP-TE LSPs to the next-hop or next-next-hop and protect the LDP traffic by using the techniques specified in [RSVP-TE-FRR]. This has the complexity of deploying an additional protocol [RSVP-TE] in order to protect LDP LSPs. In this document we describe a local-repair mechanism that can provide fast-reroute for LDP LSPs without requiring additional mechanisms from other protocols. This mechanism is henceforth referred to as FRR-LDP. It aims to provide traffic recovery times similar to that provided by [RSVP-TE-FRR]. This mechanism works for a link-state IGP such as [OSPF] and [ISIS]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology SPT: Shortest Path Tree PLR: Point of Local Repair. The head-end LSR of a backup-SP LSP. Backup-SP LSP (BSP LSP): An LDP LSP that provides a backup for a specific failure on the shortest path LDP LSP. The failed entity may be a link, a node or a SRLG. This LSP originates from the PLR(s). Backup-SP Merge Point (BSP-MP): The LSR where the Backup-SP LSP is label switched to a label allocated for the shortest path LDP LSP. It need not be downstream of the failed entity. Exclude-SPT: The shortest path tree from a PLR to a destination, when a particular failure point is excluded. 4. LDP Local Repair Technique Kini & Narayanan Expires May 28, 2011 [Page 3] Internet Draft FRR for LDP Mar 7, 2011 An LSR that can act as a BSP-MP for a given destination for a specific failure advertises a label so that the PLR can a priori select a BSP LSP to switch to when that failure occurs. Note that the PLR is also the BSP-MP for the trivial case when a LFA is present in which case this technique is reduced to the one in [IPFRR-LFA]. Also unlike [NOT-VIA], FRR-LDP does not require extra not-via addresses at each LSR along the repair path that are used to route around a failure. FRR-LDP tries to re-use the shortest-path LDP LSPs that are already present in the network before the failure as much as possible in order to provide a repair path. In combination with label stacking it requires a relatively smaller increase in forwarding state. For a given failure entity on a SPT towards a destination, LSRs upstream of the failure can act as a BSP-MP. If such an LSR is along the SPT from the PLR towards the destination in the topology after the failure, then the LSR acts as a BSP-MP and advertises a label so that the PLR can select the BSP LSP to switch to when the failure occurs. Note that at the time of failure the actions at the PLR are sufficient to protect the traffic. Other LSRs need not react at the instant the failure occurs in order to protect the traffic. 6. Protocol Extensions The primary protocol extensions consist of 1. Extensions to LDP Label mapping messages to indicate the failure entity for which the label is advertised and the PLR. 2. Procedures to get the next-next-hop advertised label in order to do node protection. Detailed encodings will be provided in future versions of this draft. 7. Security Considerations This document does not bring any new security considerations beyond those already described in [LDP]. 8. IANA Considerations These will be specified when the protocol extensions are defined. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Kini & Narayanan Expires May 28, 2011 [Page 4] Internet Draft FRR for LDP Mar 7, 2011 Requirement Levels", BCP 14, RFC 2119, March 1997. [LDP] Andersson, L., et al, "LDP Specification", RFC 5036, October 2007. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [ISIS] International Organization for Standardization, "Intermediate system to intermediate system intra-domain- routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO Standard 10589, 1992. [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RSVP-TE-FRR] Pan, P., et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [IPFRR-LFA] Atlas, A., et al, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. 10.1. Informative References [NOT-VIA] Shand, M., et al, "IP Fast Reroute Using Not-via Addresses", draft-ietf-rtgwg-ipfrr-notvia-addresses-06 (Work in progress), October 2010. 11. Acknowledgements The authors would like to thank Joel Halpern for his comments. Kini & Narayanan Expires May 28, 2011 [Page 5] Internet Draft FRR for LDP Mar 7, 2011 Authors' Addresses Sriganesh Kini Ericsson 300 Holger Way, San Jose, CA 95134 EMail: sriganesh.kini@ericsson.com Srikanth Narayanan Ericsson 300 Holger Way, San Jose, CA 95134 EMail: srikanth.narayanan@ericsson.com Kini & Narayanan Expires May 28, 2011 [Page 6]