MPLS Working Group S. Kini Internet-Draft Ericsson Intended Status: Standards Track Expires: July 2011 January 26, 2011 Hierarchical Labels in the Label Distribution Protocol (LDP) draft-kini-mpls-ldp-hierarchy-00.txt Status of this Memo Distribution of this memo is unlimited. 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 July 30, 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. Kini Expires July 2011 [Page 1] Internet Draft LDP H-Labels January 26, 2011 Abstract Label Distribution Protocol (LDP) is used to advertise mappings of Forwarding Equivalence Classes (FECs) to labels. IP prefix FECs are used to setup Label Switched Paths (LSPs) along routed paths. LDP advertises label mappings for IP Prefix FECs that appear as routes in the route table. As the number of FECs in the network increases the number of labels correspondingly increases. During certain failure conditions a large number of label mappings may have to be generated and/or installed in the data plane. In this document we describe an LDP extension to advertise hierarchical label mappings. This helps to reduce the number of label mappings that are downloaded during certain failure conditions and hence improves convergence times. Kini Expires July 2011 [Page 2] Internet Draft LDP H-Labels January 26, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. TLV Encodings and associated procedures . . . . . . . . . 5 4.1.1. Hierarchical Label (H-Label) TLV . . . . . . . . . . 5 4.1.2. Metric TLV . . . . . . . . . . . . . . . . . . . . . 5 4.1.2.1. Metric TLV procedures . . . . . . . . . . . . . 6 4.1.3. More Label TLV . . . . . . . . . . . . . . . . . . . 6 4.1.3.1. More Label TLV procedures . . . . . . . . . . . 7 4.1.4. H-Label Capability Parameter TLV . . . . . . . . . . 7 4.2. Extensions to Label distribution and management . . . . . 7 4.2.1. Label mapping origination by Egress LSR . . . . . . . 7 4.2.2. Label Distribution Control Mode . . . . . . . . . . . 7 4.2.2.1. Independent Label Distribution Control . . . . . 7 4.2.2.2. Ordered Label Distribution Control . . . . . . . 8 4.2.3. Label Retention Mode . . . . . . . . . . . . . . . . 8 4.2.3.1. Conservative Label Retention Mode . . . . . . . 8 4.2.4. Label Installation . . . . . . . . . . . . . . . . . 8 4.3. Extensions to LDP Messages . . . . . . . . . . . . . . . . 8 4.3.1. Label Mapping Message . . . . . . . . . . . . . . . . 9 4.3.1.1. Label Mapping Message procedures . . . . . . . . 9 4.3.2. Label Request Message . . . . . . . . . . . . . . . . 9 4.3.2.1. Label Request Message Procedure . . . . . . . . 9 4.4. Structuring the FTN . . . . . . . . . . . . . . . . . . 10 5. Mapping metrics of specific IGPs . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Kini Expires July 2011 [Page 3] Internet Draft LDP H-Labels January 26, 2011 1. Introduction Label Distribution Protocol ([LDP]) is widely deployed protocol in MPLS networks. However it faces limitations in fast convergence especially in scaled scenarios. Some of these problems are described in section 3. A solution to this problem is described in section 4. 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. Problem Statement LDP typically allocates a unique label per FEC. Even when the FECs have a common egress LSR, there may be a unique label per FEC. This is typical when the FEC has a unique nexthop on the egress LSR and a FEC lookup on the egress LSR must be avoided. When the path to the egress LSR changes (e.g. due to link/node failures), many FTN and/or ILM entries need to be re-programmed to the data plane. This increases the convergence time. To deduce the association of the FEC and the egress LSR, a link-state IGP may be used to flood information about the FECs. However, when there are a large number of FECs, IGP stability and convergence are adversely affected. Alternately an additional protocol such as BGP may be used but that increases the operational cost. If targeted LDP is used the number of LDP sessions is of the order of the number of LSRs in the network and this has poor scaling properties. 4. Solution The solution in this document defines a mechanism to distribute the mapping of a FEC to the corresponding egress LSR (along with the label mapping) using LDP. This label mapping is henceforth referred to as a hierarchical label mapping or H-Label mapping. Using this mapping, an LSP hierarchy is used to transport packets belonging to the FEC. A path to the egress is lower in the hierarchy over which an LSP higher in the hierarchy (specific to the FEC) is tunneled. The label for the LSP higher in the hierarchy is the one allocated by the egress LSR. When the path to an egress LSR changes and results in a nexthop change, only the nexthop corresponding to the path that is lower in the hierarchy needs to be re-programmed in the data plane. This speeds up convergence. Only the FECs to the egress LSR have to be carried in a routing protocol (e.g. link-state IGP), thus reducing the size of the information carried in the routing protocol and results in the faster routing protocol convergence. This also helps Kini Expires July 2011 [Page 4] Internet Draft LDP H-Labels January 26, 2011 faster routing protocol convergence in cases where the egress LSR goes down. The new/modified TLVs, messages and procedures to realize this hierarchy are described in subsequent sections. 4.1. TLV Encodings and associated procedures 4.1.1. Hierarchical Label (H-Label) TLV This TLV is a type of Label TLV and can occur in any LDP message that can have a Label TLV as defined in [LDP]. In addition it can occur as an optional parameter in the Label Request message. This TLV consists of two optional sub-TLVs, a Generic Label TLV and a FEC TLV. The FEC TLV MUST have a single Address Prefix FEC Element. This FEC Element is henceforth referred to as Egress LSR Address. When the H-Label TLV occurs in the Label Mapping message it MUST have both TLVs. When the H-Label TLV occurs in the Label Request message it MAY not have any sub-TLV or have just the FEC TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| H-Label (0xTBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Generic Label (0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| FEC (0x0100) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress LSR Address Prefix FEC Element | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2. Metric TLV This TLV is optional in the Label Mapping message that has an H- Label. The Metric is an attribute of the FEC. Kini Expires July 2011 [Page 5] Internet Draft LDP H-Labels January 26, 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Metric (0xTBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Type | Metric Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |.. Metric Value| +-+-+-+-+-+-+-+-+ Metric Type 1 octet unsigned integer type value. Values in the range 0x00 to 0x0f are defined in this document. Values from 0x10 to 0xff are reserved for future use. Metric Value For Metric Types 0x00 to 0x0f this is a 4 byte unsigned integer type value. If the Metric Type is 0x0f then the Metric Value MUST be greater than 0. If a Metric TLV is not present in a label mapping message with an H-Label then the message MUST be treated as having Metric Type of zero and a Metric Value of zero. 4.1.2.1. Metric TLV procedures Two Metric TLVs with Metric Type between 0x00 and 0x0f can be compared to determine the lower/higher metric. The comparison procedure is as follows: 1. A metric with Metric Type 'n' is always lower than a metric of Metric Type 'n+1'. This is independent of the Metric Value. 2. If two metrics have the same Metric Type (except if it is 0x0f) then the comparison is made on the value obtained by adding the metric (from the route table) for the route to the Egress Address Prefix FEC Element (from the corresponding H-Label TLV) to the Metric Value. 3. If two metrics have a Metric Type of 0x0f then the comparison is made using only the Metric Value. If the values are the same after comparison, the two metrics are considered equal-cost. 4.1.3. More Label TLV This TLV is optional in the Label Mapping message that has a Label Request Message ID TLV. Kini Expires July 2011 [Page 6] Internet Draft LDP H-Labels January 26, 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| More Labels (0xTBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.3.1. More Label TLV procedures This TLV being present indicates that more label mappings will be sent for that FEC in response to a specific Label Request Message. 4.1.4. H-Label Capability Parameter TLV This TLV is defined to enable the Hierarchical Label capability. It follows the encoding specified in [LDP-CAP]. There is no Capability Data associated with this TLV. The motivation and behavior when this capability is enabled are all described in this document. 4.2. Extensions to Label distribution and management 4.2.1. Label mapping origination by Egress LSR An Hierarchical Label capable LSR that is an egress for a FEC due to the nexthop being outside of the label switching network or the FEC elements being reachable by crossing a routing domain boundary SHOULD originate a label mapping with a H-Label. The H-Label MUST have LSR Egress Address as the LSR's own address (typically its loopback address). These mappings SHOULD be advertised to all neighbors that are Hierarchical Label capable. If a neighbor does not have Hierarchical Label capability the LSR MUST advertise labels to it as specified by [LDP]. 4.2.2. Label Distribution Control Mode Both independent and ordered LSP controls are supported when H-Label mappings are advertised. 4.2.2.1. Independent Label Distribution Control An LSR that is not an egress for a FEC SHOULD advertise H-Label mappings for a FEC with its address (typically loopback) as the Egress LSR Address, if it does not receive H-Label mappings from one of the FEC's nexthops. The LSR MUST additionally advertise a label mapping as described in [LDP] if it has a neighbor that does not have Hierarchical Label Capability. Kini Expires July 2011 [Page 7] Internet Draft LDP H-Labels January 26, 2011 4.2.2.2. Ordered Label Distribution Control In this control mode an LSR that receives H-Label mappings from its neighbors, selects those with the lowest cost paths to the FEC. The selection algorithm is described in detail in section 4.3.1.1. These mappings are advertised to its neighbors that are Hierarchical Label capable. Note that routes corresponding to the FECs need not appear in the route table (via IGP) before advertising these label mappings to neighboring LSRs. However, a LSP to the Egress LSR Address must be present. If a neighbor is not Hierarchical Label capable then a label as described in [LDP] is advertised. The FTN and ILM entry creation is described in section 4.2.4. 4.2.3. Label Retention Mode 4.2.3.1. Conservative Label Retention Mode When using Conservative Label Retention mode, if all the paths/nexthops for the FEC have a common Shared Risk Link Group (SRLG) it is RECOMMENDED that the LSR have as a backup an alternative nexthop that doesn't share an SRLG. This could involve requesting a label from another neighbor. The method to determine the alternate nexthop is outside the scope of this document. 4.2.4. Label Installation When an H-Label is installed for a FEC in the FTN, packets belonging to the FEC are switched using a hierarchical LSP. The LSP with outer label goes to the egress LSR of the FEC. If some LSRs along the routed path do not support H-Labels, the outer LSP goes till the furthest downstream LSR (that supports H-Labels) along the routed path to the egress LSR before an LSR incapable of H-Label occurs. The outer LSP may even be a TE LSP. The inner LSP identifies the FEC at the egress of the outer LSP. If a FEC for which a H-Label mapping exists was advertised to a neighbor without the H-Label (due to that neighbor not being capable) then the Incoming Label Map (ILM) entry should be installed with a swap operation to the hierarchical LSP. If an LSR is purely a transit LSR it SHOULD NOT install any entries in the data plane for label mapping messages with an H-Label. 4.3. Extensions to LDP Messages This section defines extensions to the LDP Messages and procedures defined in [LDP] and [LDP-IA]. Kini Expires July 2011 [Page 8] Internet Draft LDP H-Labels January 26, 2011 4.3.1. Label Mapping Message The encoding of the Label Mapping Message has the following modifications: 1. An H-Label TLV can be present instead of a Label TLV. See TLV encoding in section 4.1.1. 2. An optional parameter Metric TLV can occur if an H-Label is present. See TLV encoding in section 4.1.2. 4.3.1.1. Label Mapping Message procedures Hierarchical Label capable LSRs originate Label Mapping as described in sections 4.2.1. and 4.2.2.1. The Egress LSR Address in the H-Label MUST be an address that belongs to that LSR and has a path from other LSRs. Typically this would be a loopback address for which a LDP label mapping has been advertised. If the metric for the FEC is non- zero then a Metric TLV with appropriate Metric Type and Metric Value is included. An H-Label SHOULD NOT be advertised for addresses that belong to the LSR e.g. loopback addresses. When an LSR receives Label Mapping Messages for a FEC containing an H-Label, it selects some of these label mappings for advertising to neighbors and installation into the FTN and ILM. The selection algorithm is as follows. Firstly, mappings received from neighbors that are the nexthop for the Egress LSR Address in the corresponding H-Label are chosen. These mappings are advertised to all LDP neighbors. From among these, the mappings with the lowest metric value are chosen using the metric comparison algorithm from section 4.1.2.1. These label mappings are installed in FTN and ILM entries as described in section 4.2. 4.3.2. Label Request Message The FEC TLV in the request message can contain a Wildcard FEC Element. 4.3.2.1. Label Request Message Procedure On receiving a Label Request Message, the LSR creates Label Mapping messages for all the Labels for that FEC. If the FEC TLV has a Wildcard FEC Element then all for which label mappings are present are returned in the response. In this case multiple label mapping messages are sent in response. On receiving the LSR additionally checks if it has selected mappings for that FEC according to the procedure in section 4.3.1.1. Those mappings are sent as a response to this request. Kini Expires July 2011 [Page 9] Internet Draft LDP H-Labels January 26, 2011 4.4. Structuring the FTN When installing a FTN entry corresponding to a Label Mapping message with a H-Label, a hierarchy must be used. First a push operation using the Label from the Generic Label TLV in the H-Label must be done. This is the LSP for the FEC that is higher in the LSP hierarchy. This must be followed by a push operation of a label for a LSP to the Egress LSR Address. This LSP is lower in the hierarchy. Implementations should handle changes to the nexthops of the LSP to the Egress LSR Address in such a way that the LSPs higher in the hierarchy are quickly updated to realize fast convergence. 5. Mapping metrics of specific IGPs The 32-bit value in the Metric TLV is sufficient to contain metrics defined for IGPs in [OSPF], [ISIS-TE] and [RIPv2]. The preferences between different routes of an IGP are described within the IGP e.g., [OSPF], [ISIS-2LVL] etc. The Metric Type for the Metric TLV (defined in 4.1.2. ) should be chosen in accordance with the IGPs definitions. It should be noted that a metric such as the OSPF Type-2 external metric MUST be mapped to a Metric Type 0xf in the H-Label mapping. This section describes TLVs that are defined in this document and their associated procedures. 6. Security Considerations This document does not bring any new security considerations beyond those already described in [LDP]. 7. IANA Considerations The following assignments are required from IANA - TLV Types for Hierarchical Label Capability Parameter, H-Label, Metric and More Label. Recommend next available values 0x604, 0x605, 0x606 and 0x607. 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. [RIPv2] Malkin, G., "RIP Version 2", RFC 2453, November 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [BGP-LBL] Rekhter, Y., "Carrying Label Information in BGP-4", RFC Kini Expires July 2011 [Page 10] Internet Draft LDP H-Labels January 26, 2011 3107, May 2001. [LDP] Andersson, L., et al, "LDP Specification", RFC 5036, October 2007. [LDP-IA] Decraene, B., et al, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [ISIS-2LVL] Li, T., et al, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, October 2008. [LDP-CAP] Thomas, B., et al, "LDP Capabilities", RFC 5561, July 2009. 8.2. Informative References [MPLS-ARCH] Rosen, E., et al, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [ISIS-TE] Li, T., et al, "IS-IS Extensions for Traffic Engineering", RFC 5307, October 2008. 9. Acknowledgements The authors would like to thank Joel Halpern and Pramodh D'Souza for their comments. Kini Expires July 2011 [Page 11] Internet Draft LDP H-Labels January 26, 2011 Authors' Addresses Sriganesh Kini Ericsson 300 Holger Way, San Jose, CA 95134 EMail: sriganesh.kini@ericsson.com Kini Expires July 2011 [Page 12]