MPLS Working Group S. Kini Internet Draft S. Narayanan Intended Status: Standards Track Ericsson Expires: May 2012 October 31, 2011 MPLS Fast Re-route using extensions to LDP draft-kini-mpls-frr-ldp-02.txt 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. Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Kini & Narayanan Expires May 2012 [Page 1] Internet Draft FRR LDP October 31, 2011 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 2012 [Page 2] Internet Draft FRR LDP October 31, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. LDP Local Repair Technique . . . . . . . . . . . . . . . . . . 4 5. Protocol procedures and extensions . . . . . . . . . . . . . . 5 6. Examples of FRR-LDP . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Kini & Narayanan Expires May 2012 [Page 3] Internet Draft FRR LDP October 31, 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. Scope This draft is applicable only when per platform label spaces are used. Per interface label spaces are out of scope. 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 (link, node, SRLG) is excluded from the topology. 4. LDP Local Repair Technique Kini & Narayanan Expires May 2012 [Page 4] Internet Draft FRR LDP October 31, 2011 When a failure occurs in an IGP network, traffic along a shortest- path LSP that is upstream from the failure gets affected. Traffic along the shortest-path LSP that is not upstream of the failure does not get affected. A backup shortest-path LSP (BSP LSP) for a shortest path LSP (or FEC) is another LSP that goes from the PLR to an LSR that can label-switch the traffic back along that part of the shortest-path LSP that is not upstream for that failure. The LSR on which the BSP LSP terminates is called the BSP Merge Point or BSP-MP. The BSP LSPs are LDP LSPs. The BSP LSP becomes a single hop LSP when a Loop Free Alternate (LFA) is present. In such cases the mechanism in [IPFRR-LFA] is used. The mechanisms in this draft should be used when an LFA is not available. A shortest path LSP to the BSP-MP should be used as a BSP LSP if one is available. This must use label stacking as follows. First the label of the LSP should be swapped with that allocated by the BSP-MP for that FEC. Next, the label to the BSP-MP should be stacked. When a single such shortest path LSP is not available to be used as a BSP LSP, multiple shortest path LSPs and/or interfaces on directly connected LSRs can be stitched together. The LSRs that stitch such LSPs together do so by advertising another label for the FEC. This label is stacked below the shortest path LSP label. It is allocated on demand and is initiated from the PLR to the first stitching LSR. If there is a stitching LSR further downstream (i.e. towards the BSP- MP) the stitching LSR in turn requests a label from the downstream stitching LSR. The protocol extensions required to setup BSP LSPs are described in section 4. The label actions for the BSP LSPs are pre-installed in the forwarding tables. The PLR pre-computes the label-operation changes to be performed on the failure trigger. When the failure occurs, the PLR detects the failure as a local event and performs the pre-computed label operation actions. None of the LSRs along the BSP LSP other than the PLR have to perform any additional operation at the instant of failure in order to protect the traffic. FRR-LDP is a local repair mechanism that can protect against link, node and SRLG failures. The BSP LSPs that have to be setup depend on the network topology. It also depends on the type of protection (e.g. per-FEC or per-nexthop). Sample topologies with FRR-LDP applied are described in section 5. 5. Protocol procedures and extensions The PLR must establish a targeted LDP session with the BSP MP or the next stitching LSR to get the label bindings it needs for the backup LSP. It must negotiate the on-demand mode for the targeted sessions Kini & Narayanan Expires May 2012 [Page 5] Internet Draft FRR LDP October 31, 2011 and request only those label bindings that it needs to protect the LSPs. Additionally the PLR sends the path information when the next LSR is a stitching LSR so that it can request the stitching LSR further downstream for label bindings. A new TLV "Backup Path Vector TLV" is defined. It should be noted that this TLV is required only when multiple shortest path LSPs need to be stitched together for the BSP LSP. The TLV consists of a list of addresses of stitching LSRs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Backup Path Vector (0xTBD)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Type | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Type | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hop Type 1 - Indicates that the stitching LSR should use a shortest path LDP LSP to reach the next stitching LSR 2 - Indicates that the stitching LSR should use a directly connected interface to reach the next stitching LSR This TLV is used in the "Label Request" message. Each stitching LSR removes the first address in this TLV before requesting a label from the next stitching LSR. A Capability TLV is defined for LDP in accordance to [LDP-CAP] to advertise its capability to process the "Backup Path Vector" TLV. An area scope capability TLV is also advertised via IGP ([OSPF-CAP] and [ISIS-CAP]) for the same so that the PLR can take it into account when computing the BSP LSP. 6. Examples of FRR-LDP Kini & Narayanan Expires May 2012 [Page 6] Internet Draft FRR LDP October 31, 2011 In the example topology below, link A-B is of cost 100. All other links are unit cost. To protect against the failure of LSR E for FEC F, LSR C sets up a BSP LSP C-A-B-G where A and B stitch shortest path LSP C-A, the LSP A-B (due to B advertising a label to A) and the shortest path LSP B-G. The PLR (LSR C) computes the backup path by executing a shortest path computation on the topology excluding LSR E. It initiates a label-request towards LSR A for FEC F, with the "Backup Path Vector" TLV containing the address of LSR B (Hop Type 2) and of LSR G (Hop Type 1). LSR A further initiates a label-request towards LSR B with a "Backup Path Vector" TLV containing the address of LSR G (Hop Type 1). LSR B in turn initiates a label request for FEC F to LSR G (without the Backup Path Vector TLV). Note that in this case since B and G are directly connected this label may be the same one that LSR G had originally allocated for F. LSR B then allocates a label F, sets the label operation to swap to the label allocated by G and to forward over LSP B-G and returns that label in the label response to LSR A. LSR A in turn allocates another label for F, sets the label operation to swap to the label allocated by B and to forward over LSP A-B and returns that label in the label response to LSR C. +-----+ +-----+ +-----+ | A |-----------| B |--------| G | +-----+ +-----+ +-----+ | | | | | | +-----+ +-----+ +-----+ | C | | D | | H | +-----+ +-----+ +-----+ \ / | \ +-----+ / +-----+ \___| E |__/ | I | +-----+ +-----+ | | | | +-----+ | | F | -------------------+ +-----+ 7. Security Considerations This document does not introduce any additional security considerations beyond those in [LDP]. 8. IANA Considerations New TLV types are needed for the "Backup Path Vector" and the LDP, Kini & Narayanan Expires May 2012 [Page 7] Internet Draft FRR LDP October 31, 2011 OSPF and ISIS Capability values. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 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. [OSPF-CAP] Lindem, A., et al, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [ISIS-CAP] Vasseur, JP., et al, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [IPFRR-LFA] Atlas, A., et al, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [LDP-CAP] Thomas, B., et al, "LDP Capabilities", RFC 5561, July 2009. 9.2. Informative References [NOT-VIA] Shand, M., et al, "IP Fast Reroute Using Not-via Addresses", draft-ietf-rtgwg-ipfrr-notvia-addresses-07 (Work in progress), April 2011. 10. Acknowledgements Kini & Narayanan Expires May 2012 [Page 8] Internet Draft FRR LDP October 31, 2011 The authors would like to thank Joel Halpern for their review and useful comments. Authors' Addresses Sriganesh Kini EMail: sriganesh.kini@ericsson.com Srikanth Narayanan EMail: srikanth.narayanan@ericsson.com Kini & Narayanan Expires May 2012 [Page 9]