MPLS Working Group Pranjal Kumar Dutta Internet Draft Wim Henderickx Intended status: Informational Alcatel-Lucent Expires: January 2012 July 4, 2011 Upstream LSR Redundancy for Multi-point LDP Tunnels draft-pdutta-mpls-mldp-up-redundancy-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 January 4, 2012. 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. Dutta, et al. Expires January 4, 2012 [Page 1] Internet-Draft mLdp Upstream Redundancy July 2011 Abstract Label Distribution Protocol (LDP) can be used to set up Point-to- Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. The existing specification for this functionality assumes that a downstream LSR selects only one upstream LSR for a P2MP or MP2MP LSP. A Make-Before-Break (MBB) procedure in mLdp base specification [MLDP] for graceful upstream LSR change but that is not applicable when the upstream LSR node fails. As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to such failures. This document describes a set of procedures that minimize packet loss when an upstream LSR node fails. This document does not change any specifications of mLdp protocol as defined in [MLDP] and so there are no inter-operability requirements for the procedures described in this document. Table of Contents 1. Introduction...................................................2 1.1. Problem Statement.........................................2 2. Conventions used in this document..............................3 3. Terminology....................................................3 4. Upstream LSR Redundancy........................................4 5. Backup Upstream LSR Selection..................................5 5.1 Equal-Cost-Multi-Path (ECMP).............................5 5.2 Loop-Free-Alternate (LFA).............................6 6. Fast Failover to Backup Upstream LSR...........................7 7. Security Considerations........................................7 8. IANA Considerations............................................7 9. References.....................................................8 9.1. Normative References......................................8 9.2. Informative References....................................8 10. Acknowledgments...............................................8 1. Introduction 1.1. Problem Statement The Label Distribution Protocol (LDP) extensions for setting up Point-to-Multipoint (P2MP) Label Switched Paths (LSPs) and Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLdp]. This set of extensions is generally known as "Multipoint LDP" (mLdp) and this documents refer P2MP and MP2MP LSPs as "mLdp Tunnels", unless specified otherwise. Dutta, et al. Expires January 4, 2012 [Page 2] Internet-Draft mLdp Upstream Redundancy July 2011 A node Z that wants to join an mLdp Tunnel determines the upstream peer U which is Z's next-hop on the best path from Z to the root node R of the mLdp tunnel. If there is more than one such LDP peer due to Equal-Cost-Multi-Path (ECMP), only one of them is picked. As defined in [MLDP] when there are several candidate upstream LSRs, the LSR Z must select only one upstream LSR based on a localized selection algorithm at node Z. When the best path to reach the root changes, the mLdp tunnel may be broken temporarily resulting in packet loss until the LSR Z re- converges to a new upstream LSR U'. A set of Make-Before-Break (MBB) procedures is defined in [MLDP] for graceful transition to new upstream LSR U' and thus minimize this traffic loss. However these set of procedures are not applicable when upstream LSR U fails and that results in loss of traffic till topology re-converges to new upstream U' and Z completes set-up of new path towards the root. mLdp tunnels carry loss sensitive traffic such as broadcast video so it is very important to provide protection against such upstream node failures. A router's IGP convergence time is generally on the order of hundred's of milliseconds; the application traffic may be sensitive to losses greater than tens of milliseconds till the local LSR selects new upstream LSR and establishes the mLdp tunnel path towards the root node. Minimizing traffic loss requires a mechanism for the local LSR Z on detection of failure to its immediate upstream U to rapidly invoke a repair path, which is minimally affected by any subsequent re- convergence. This document describes a set of procedures to provide protection against failure of upstream LSR by pre-establishing an mLdp tunnel path to one or more secondary upstream LSRs. The specification in this document leverage existing methodologies to achieve upstream LSR failover protection without imposing requirements on inter-operability or new protocol specification. 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 [RFC-2119]. 3. Terminology Primary Upstream : Upstream LSR chosen by a node to receive traffic on an mLdp tunnel. Dutta, et al. Expires January 4, 2012 [Page 3] Internet-Draft mLdp Upstream Redundancy July 2011 Backup Upstream : Redundant Upstream LSR chosen by a node to receive traffic on an mLdp tunnel on failure of its primary upstream. ECMP : Equal Cost Multi-Path LFA : Loop-Free-Alternates 4. Upstream LSR Redundancy Upstream LSR failure protection can be provided by taking advantage of redundant topologies in service provider networks. A local LSR Z selects two upstream LSRs - one primary LSR U and at least one backup LSR U'. Label mappings L sent to U and L' sent to U shares the same downstream next-hop label forwarding entries at Z. It needs to be ensured that mLdp tunnel path along such secondary LSR U' is loop free. Data packets are received by Z from both U and U' simultaneously. Redundant packets received from U' are discarded by Z. When Z detects a reachability failure to U then it switches its upstream to the backup LSR U' and packets are immediately available to forward out of each downstream next-hops. The amount of traffic loss in such failovers is dependent on the detection methodologies used by Z to detect failure of U. Details of such methodologies are out of scope of this document. This mode of upstream LSR protection causes traffic replication from U' to Z which is dropped at Z. Note that such traffic replication does may demand extra capacity although on failure of U, the mLdp tunnel would have converged to U' anyway as a result of network topology change. In service provider networks it is likely that such redundant paths are kept disjoint from fate sharing. Redundant replications may not require additional capacity in the network, but may change replication distribution in upstream router U'. This method is simple and is localize to individual routers along the path from root to leaves of an mLdp tunnels. There arises no inter- operability requirements since there is no change in mLdp protocol operation. End-to-end failure protection and recovery can be achieved by such localized protection at every node. Dutta, et al. Expires January 4, 2012 [Page 4] Internet-Draft mLdp Upstream Redundancy July 2011 5. Backup Upstream LSR Selection Backup upstream LSR protection is highly dependent on topology, that is on the existence of two disjoint paths from LSR Z performing protection to the root node R of the mLdp tunnel. Upstream LSR Protection works best for following topologies: 5.1 Equal-Cost-Multi-Path (ECMP) R ... ... | | +-----+ +-----+ | U' | | U | +-+---+ +-----+ | | | 4 4 | | | | | \|/ \|/ | | | +-----+ | +----| Z |---+ +--+--+ | | | 10 | +----------+----------+ | | +--+--+ +--+--+ |Leaf | | Leaf| +-----+ +-----+ Figure 1. If the IGP installs ECMP paths at node Z to the Root Node R of the mLdp tunnel, then Z selects one primary upstream LSR U based on procedures in [MLDP]. If there are other LDP peers with remaining paths in ECMP then Z can select one or more of those peers as backup upstream LSR U' and label mappings are sent to those peers. Packets received from backup upstream LSRs are dropped locally at Z till primary upstream U fails. Since the packets from U' are already arriving at Z so Z can switchover to U' immediately on detection of failure to U. Further ECMP also means loop-free so on failure of U, Dutta, et al. Expires January 4, 2012 [Page 5] Internet-Draft mLdp Upstream Redundancy July 2011 this does not cause any loop in the path of the mLdp tunnel through U' from root node R towards the leaves. 5.2 Loop-Free-Alternate (LFA) It is possible that in service provider network there are several loop free alternate paths exist. [RFC5286] provides specification for IP Fast Reroute with Loop-Free Alternates (LFA). R ... ... | | +-----+ +-----+ | U' | | U | +-+---+ +-----+ | | | 5 4 | | | | | \|/ \|/ | | | +-----+ | +----| Z |---+ +--+--+ | | | 10 | +----------+----------+ | | +--+--+ +--+--+ |Leaf | | Leaf| +-----+ +-----+ Figure 2. In the absence of ECMP paths from Z towards root node R, IGPs may compute LFA paths from Z towards the root node. Z would select LDP peer on primary next-hop provided by IGP as primary upstream LSR U and peers on LFA next-hops as candidate backup upstream LSRs U'. Rapid upstream failure protection is achieved through use of pre- calculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on Dutta, et al. Expires January 4, 2012 [Page 6] Internet-Draft mLdp Upstream Redundancy July 2011 the LFA topology of the network. Especially when networks does not have ECMP, then backup stream LSR selection using LFA has significant advantages. It is RECOMMENDED that LFA next-hops computed for this purpose are "Node-Protecting", that is the backup LSR U' in turn must not choose U as its primary upstream LSR. However without node protection although upsteam node failure may not be protected, it definitely provides link protection on failure of downstream link from U to Z. 6. Fast Failover to Backup Upstream LSR When node Z selects a backup upstream LSR and sends backup label mapping L' for joining the mLdp tunnel path towards the root, it is RECOMMENDED that Z installs L' into data plane with one exception : L' MUST NOT be forwarding traffic to its downstream - it is kept in "blocking mode". When Z detects failure on its primary upstream U, it triggers switchover of traffic from primary upstream label L to L', thus blocking L and unblocking L' in forwarding traffic to downstream(s). This is important to avoid duplication of traffic to downstream during failover. A single failover trigger may be sufficient for fast switchover of traffic in all mLdp tunnels that have selected U as primary upstream to their respective backup upstream labels. For some implementations it may not be possible to pre-install a backup label L' into data plane in blocking mode. On primary upstream failure, if L' is added before L is removed, there is a potential risk of packet duplication, and/or the creation of transient data plane forwarding loop. If L is removed before L' is added, packet loss may result. For such implementations the RECOMMENDED procedure is to remove L before adding L'. 7. Security Considerations This document does not require additional security considerations to what is required in [MLDP]. 8. IANA Considerations There is no IANA considerations required by this document. Dutta, et al. Expires January 4, 2012 [Page 7] Internet-Draft mLdp Upstream Redundancy July 2011 9. References 9.1. Normative References [MLDP] Ina Minei, Kireeti Kompella, IJsbrand Wijnands, Bob Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-11.txt, October 2010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5286] A. Atlas, A. Zinin, "Basic Specification for IP Fast Re Route: Loop-Free Alternates. 9.2. Informative References TBD. 10. Acknowledgments Authors would like to acknowledge reviews and valuable feedbacks from Paul Kwok. This document was prepared using 2-Word-v2.0.template.dot. Dutta, et al. Expires January 4, 2012 [Page 8] Internet-Draft mLdp Upstream Redundancy July 2011 Authors' Addresses Pranjal Kumar Dutta Alcatel-Lucent 701, E Middlefield Road, Mountain View, CA 94043, USA. Email: pranjal.dutta@alcatel-lucent.com Wim Henderickx Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium Email: wim.henderickx@alcatel-lucent.be Dutta, et al. Expires January 4, 2012 [Page 9]