MPLS Working Group S. Kini Internet Draft S. Narayanan Intended Status: Standards Track Ericsson Expires: January 2012 July 11, 2011 MPLS Fast Re-route using extensions to LDP draft-kini-mpls-frr-ldp-01.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 January 2012 [Page 1] Internet Draft FRR LDP July 11, 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 January 2012 [Page 2] Internet Draft FRR LDP July 11, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. LDP Local Repair Technique . . . . . . . . . . . . . . . . . . 4 4.1. Per-prefix protection . . . . . . . . . . . . . . . . . . 5 4.1.1 Sharing BSP LSPs using label stacking . . . . . . . . . 6 4.1.2. Shortest-path LSPs as BSP LSPs . . . . . . . . . . . . 6 4.1.3. Hybrid BSP using shortest-paths . . . . . . . . . . . 7 4.2. Per nexthop protection . . . . . . . . . . . . . . . . . . 7 5. Protocol extensions . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Failure Element TLV . . . . . . . . . . . . . . . . . . . 8 5.2. Backup Path Vector TLV . . . . . . . . . . . . . . . . . . 8 5.3. Tunneled FEC TLV . . . . . . . . . . . . . . . . . . . . . 9 5.3. Protocol procedures . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Kini & Narayanan Expires January 2012 [Page 3] Internet Draft FRR LDP July 11, 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 January 2012 [Page 4] Internet Draft FRR LDP July 11, 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) is setup from the PLR to an LSR that can label-switch the traffic back along the shortest-path LSP that is not upstream from the failure. Such an LSR is referred to as the BSP Merge Point or BSP-MP. LDP is used to setup the BSP 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] are used. The mechanisms in this draft should be used when an LFA is not available. The BSP LSPs to be setup in a network depends on the network topology, the failures that need to be protected and the method used by the PLR to protect the traffic. Link, node and SRLG failures can be protected by applying FRR-LDP. The different ways of applying FRR- LDP are described below. In all these methods none of the LSRs along the BSP LSP other than the PLR have to perform any special operation at the instant of failure in order to protect the traffic. The PLR pre-computes the label-operation actions to be performed on the failure trigger. This is due to FRR-LDP being a local protection mechanism. 4.1. Per-prefix protection In this method BSP LSPs must be setup per prefix for every failure that needs to be protected. The BSP LSP can be along the shortest path to the prefix from the PLR, computed in the topology with the failure entity removed (Exclude-SPT). The BSP LSP terminates at the BSP MP which is the LSR along that path that is not upstream from the failure (at the PLR) and hence can label-switch the traffic from the BSP LSP to the shortest-path LSP of that prefix in the current network topology. All the LSRs along the BSP LSP, except the PLR, allocate a label for the BSP LSP. The PLR installs a label-swap operation on a local failure to switch the traffic from the shortest- path LSP of the protected prefix to the label allocated by the nexthop along the BSP LSP. This method is illustrated through an example in Fig 1. Say all the links are of equal cost. Let L:X-y denote the label allocated by LSR X for prefix y for the shortest-path LSP. Let L:X-y-F denote the label allocated by LSR X for the prefix y for the failure F. These labels are for the BSP LSP. Consider a prefix e at LSR E. Say this prefix has to be protected against failure of link BE. In this case L:C-e-BE is a label allocated by C for the BSP LSP for the prefix p for the failure of link BE. Though D is the LSR that will merge the traffic back to the shortest-path LSP, it does not need to advertise a separate label since the shortest-path LSP label L:D-e can be re- Kini & Narayanan Expires January 2012 [Page 5] Internet Draft FRR LDP July 11, 2011 used. A label-swap action of L:C-e-BE to L:D-e is installed by LSR C in its ILM. Similarly, a label L:C-e-DE is allocated by LSR C. In this topology two extra labels are adequate to protect against any failure for a prefix terminating at E. The label on the packet as it goes from C to E along the path C-B-E before the failure would be L:B-e -> L:E-e. When PLR B receives a trigger of link BE failure it installs a swap operation from L:B-e to L:C-e-BE. Thus the labels on the packet as it goes from C to E would be L:B-e -> L:C-e-BE -> L:D-e -> L:E-e. +-----+ +-----+ | C |----------------| D | +-----+ +-----+ | | | | +-----+ +-----+ +-----+ | A |-------| B |----------------| E | +-----+ +-----+ +-----+ Figure 1 Example topology 4.1.1 Sharing BSP LSPs using label stacking The number of BSP LSPs can be greatly reduced by using label stacking. When the path of BSP LSPs is the same for multiple prefixes and/or failures, the same BSP LSP can be used using label stacking. The BSP MP advertises a label for the prefix to the PLR. The protocol mechanisms to advertise this are described later. In cases where the BSP MP has multiple equal-cost paths to the destination and some of them can go through the failure point, this label must be different than the shortest-path LSP label that it has allocated for that prefix. The label-swap operations for that label have to be set such that the paths taken do not go through the failure point. During a protection switch the PLR does a label swap of the protected LSP to the label advertised by the BSP MP and then pushes the label of the shortest-path LSP to the BSP MP. As a failure trigger action the PLR swaps the protected LSPs label with that advertised by the BSP MP for that prefix. It then pushes the BSP LSP label and forwards the packet. 4.1.2. Shortest-path LSPs as BSP LSPs A shortest-path LSP in the current network topology from the PLR can also be used as a BSP LSP by applying label stacking at the PLR. This can be done only if such a shortest-path LSP exists and it does not Kini & Narayanan Expires January 2012 [Page 6] Internet Draft FRR LDP July 11, 2011 fate-share with the failure that is being protected against. The BSP MP advertises a label for that prefix to the PLR. The protocol mechanisms to advertise this are described later. In cases where the BSP MP has multiple equal-cost paths to the destination and some of them can go through the failure point, this label must be different than the shortest-path LSP label that it has allocated for that prefix. The label-swap operations for that label have to be set such that the paths taken do not go through the failure point. During a protection switch the PLR does a label swap of the protected LSP to the label advertised by the BSP MP and then pushes the label of the shortest-path LSP to the BSP MP. Such a shortest-path LSP may be used to as a BSP LSP for many prefixes by first swapping with label specific to the prefix before pushing the label of the shortest-path LSP. In the example in Fig 1, LSR B uses the shortest-path LSP to D as the BSP LSP for protecting the LSP to prefix e from failure of the link BE. The PLR B pre-installs a failure action for link BE that it should first swap the label L:B-e to L:D-e and then push the label for the shortest-path LSP to D. In this example, there are no additional labels allocated for protection than the shortest-path LSP labels. Also multiple prefixes terminating at E can be protected using the same BSP LSP. 4.1.3. Hybrid BSP using shortest-paths When the BSP LSP cannot use a shortest-path LSP then all the LSRs along the BSP LSP except the PLR must allocate labels. It is possible to reduce the number of labels required for the BSP LSP by encapsulating into shortest-path LSPs along the path of the BSP LSP. This further reduces the additional info needed for FRR-LDP. Details of this will be provided in future versions of the doc. 4.2. Per nexthop protection In this method only the next-hop is protected using FRR-LDP. In this case label stacking must be used at the PLR before sending the packet to the next downstream LSR (for link protection) or the next-to-next downstream LSR (for node protection). For SRLG protection, it may be necessary to learn a label allocated by a node further downstream. Protocol extensions similar to record label would need to be defined for this. The BSP LSP can be along the shortest path from the PLR to the next downstream LSR(or next-next-hop), computed in the topology with the failure entity removed. The BSP MP is the LSR that label-switches traffic to a shortest-path LSP to that nexthop in the current network topology. Kini & Narayanan Expires January 2012 [Page 7] Internet Draft FRR LDP July 11, 2011 The advantage of this method compared to per-prefix protection is that lesser number of BSP LSPs are needed. This is due to all LSPs that go through that nexthop being protected using a single BSP LSP. However the packet may take a less optimal path till the shortest- path re-computation is done. If a shortest-path LSP from the PLR to the BSP MP exists that can be used as the BSP-LSP, an additional level of label-stacking must be used. This can further reduce the number of additional labels required for BSP LSPs. 5. Protocol extensions The BSP LSP is signaled using extensions to LDP. When a BSP LSP is used to protect multiple prefixes (by label stacking) the label mapping of each of the protected prefixes needs to be advertised to the PLR. A targeted LDP session can be used for this. This can have scalability issues and hence an option to advertise it without targeted LDP is defined. 5.1. Failure Element TLV A Failure Element TLV identifies the failure that the BSP LSP is protecting against. It identifies that this message is for a BSP LSP. 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| Failure Element (0xTBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure Element Identifier | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Failure Element Type Can be one of either a link (v4/v6), node (v4/v6) or a SRLG Failure Element Identifier A link is identified by an IP address of one of its ends. A node is identified by its loopback IP address. The SRLG is as defined in RFC 4202. 5.2. Backup Path Vector TLV The Backup Path Vector TLV indicates the path taken by this BSP LSP from the BSP MP to the PLR. It consists of loopback addresses of each LSR along the path. The first address would be that of the MP and the Kini & Narayanan Expires January 2012 [Page 8] Internet Draft FRR LDP July 11, 2011 last address would be the PLR 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Backup Path Vector (0xTBD)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunneled FEC TLV The Tunneled FEC TLV indicates to the PLR the label advertised by the MP for the FEC for re-routing traffic. This label should be used to tunnel through the BSP LSP. The intermediate nodes do not install any data-plane state for a tunneled FEC. 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| Tunneled Prefix (0xTBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Protocol procedures An LSR computes the failures and prefixes for which it can act as a BSP MP and advertises a label mapping for the BSP LSP by including the Failure Element TLV and the Backup Path Vector TLV. The intermediate LSRs of a BSP LSP allocate labels for the BSP LSP and also advertise it upstream using the Backup Path Vector TLV. If label stacking is used BSP MP also advertises label mappings for the tunneled prefixes by including the Tunneled Prefix TLV in addition to the Failure Element TLV and the Backup Path Vector TLV. The intermediate LSRs do not allocate labels for this since the label is tunneled in a BSP LSP. They forward the label mapping using the Backup Path Vector TLV. The PLR installs actions for a failure trigger using the labels. Kini & Narayanan Expires January 2012 [Page 9] Internet Draft FRR LDP July 11, 2011 6. Security Considerations This document does not introduce any additional security considerations beyond those in [LDP]. 7. IANA Considerations New TLV types are needed for Failure Element TLV, Backup Path Vector TLV and Tunneled Prefix TLV. 8. References 8.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. [IPFRR-LFA] Atlas, A., et al, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. 8.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. 8. Acknowledgements The authors would like to thank Joel Halpern for their review and Kini & Narayanan Expires January 2012 [Page 10] Internet Draft FRR LDP July 11, 2011 useful comments. Authors' Addresses Sriganesh Kini EMail: sriganesh.kini@ericsson.com Srikanth Narayanan EMail: srikanth.narayanan@ericsson.com Kini & Narayanan Expires January 2012 [Page 11]