MPLS Working Group Nipun Chawla Internet Draft Rajat Setia Intended Status: Standards Track Himanshu Tambakuwala Expires: October 1, 2015 Juniper Networks March 2015 Unique and Consistent Label LDP draft-ncrsht-mpls-unique-and-consistent-label-ldp-00 Abstract This document describes a mechanism to extend LDP control plane with path control feature, improved remote LFA support and allow easier monitoring of labelled packet flows in a LDP signaled MPLS network. The mechanism introduces a method in LDP to propagate a label for loopback address of a router such that each label identifies a LDP speaking router in the network. The method enhances the scope of unique label for loopback address of each LDP speaking router in a network from a platform or an interface level to an autonomous system. The procedures described in this mechanism apply to all LDP speaking routers running with ordered downstream unsolicited label distribution. Extending these procedures to independent or downstream on demand label distribution is a case of further study and thus beyond the scope of this document. Status of This Memo 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 1st October, 2015. [Page 1] Internet Draft Unique and Consistent Label LDP March 2015 Copyright Notice Copyright (c) 2015 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. Specification of Requirements 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 BCP 14, RFC 2119 [RFC2119]. Overview In a LDP signaled MP-BGP MPLS network a PE uses the loopback interface address for internal BGP peering and the same address is the default protocol next hop for prefixes being advertised from that PE. With MPLS implemented in the network the traffic destined to these prefixes is encapsulated with an MPLS header. This transport (outer) label header that is pushed onto the packet points to the protocol next hop of the prefix. In the next three sections of the document we explain the method to make this transport label for labeled packets same across all links in the autonomous system. Label Space and Label Binding This method uses a defined label range and binding of a label from that range to a loopback interface address on a LDP speaking router. An address of a loopback interface is unique across the network and thus a label for an address is unique in the network. The explanation of method to bind a label to loopback address is implementation specific and thus beyond the scope of this document. [Page 2] Internet Draft Unique and Consistent Label LDP March 2015 LDP Extension This method introduces a capability in LDP to "understand unique labels and advertise these unique labels" in such a way that they remain consistent in the network. This capability will be termed as "unique label capability" in further scope of this document. In case of mismatch of this capability among LDP peers, the LDP session will not be brought down and LDP shall continue to behave as per its classic implementation. The support of this capability implies the support for the unique-label TLV and unique-label-php TLV (both TLV explained later in the section). This method introduces a label mapping TLV (referred in the further scope of this document as "unique-label" TLV) which is in line with the generic label TLV (mentioned in [RFC5036] with new type. The Type field in this TLV identifies the label in the value field as a "unique" label. The LDP peers supporting this "unique label" capability advertises a label for their loopback using this "unique label" TLV. At transit, router advertises the same label as received to the upstream LDP neighbor(s). [Page 3] Internet Draft Unique and Consistent Label LDP March 2015 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| unique-label | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To achieve penultimate hop popping (PHP) a router advertises a label of 3 (implicit-null) or a label of 0 (explicit-null) for its local prefixes to LDP peers. In this mechanism, to support PHP, an additional TLV (referred to as "unique-label-php" TLV in the further scope of this document) is advertised in addition to the "unique label" TLV by the router. The PHR uses this "unique-label-php" TLV to update Label FIB (LFIB) entry with operation as pop (in case of implicit-null) or swap with 0 (in case of explicit-null) while using the "unique label" TLV to advertise the same label to the upstream LDP peer. This procedure ensures that the label for a router's loopback interface address is consistent throughout the network. 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| unique-label-php | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Page 4] Internet Draft Unique and Consistent Label LDP March 2015 Label Operation With this mechanism, at the ingress LER, packet's FEC is determined, label is pushed as the transport/outer label in the MPLS header. In transit, the LSR performs the label swap operation but with the same label with which the traffic had arrived. At PHR in case of PHP the classic operation of label pop or label swap with 0 are performed. Path control (Explicit routing) at ingress Every loopback interface address present in the network represents a node in the network and since every loopback address is bind to a unique label, we have a network with nodes having unique labels. All LDP speaking routers will have consistent information of labels to reach any LDP speaking router (node) in the network. PE1(S)-------P1(L1)-------P2(L2)------PE2(D) | | | | | | P3(lo0,L3)-------P4(L4)----- We want traffic destined to PE2 (egress) to follow path via P3 and explicitly define this path for the traffic at ingress (PE1). P3 advertises unique label L3 for its loopback address to P1 in a "unique label" TLV. The node P3 also advertises a "unique-label-php" TLV with a label 0 or 3 (default) to P1.P1 uses the "unique-label- php" to create an entry in its LFIB. P1 generates the same label for P3 loopback (as advertised by P3) and advertise to upstream neighbors. Hence PE1 is aware of unique label L1 for node P1, L3 for node P3 and L4 of node P4 .PE1 creates a label stack by pushing label L3 on top of label D. Label stack pushed at PE1 (ingress) looks like this ---------------------- | IP Packet | D | L3 | ---------------------- [Page 5] Internet Draft Unique and Consistent Label LDP March 2015 The above packet arrives at P1.First, this top label L3 is read at P1.At P1, the label L3 is either popped and pushed out to P3 or swapped with a label 0 and pushed out to P3 -if swap is performed at P1, then incoming label 0 will be popped at P3, the label D is swapped with label D and packet is forwarded to P4-if pop operation is performed at P1, then the label D is swapped with label D and packet is forwarded to P4 ------------------------------------ | IP Packet (with inner label) | D | ------------------------------------ The above packet arrives at P4. - At P4, depending upon PHP (with explicit or implicit null) scenario PE2 will receive either an IP packet or labelled packet with label 0 on top or labelled packet with D on top. We can further define transit path (at ingress) in terms of nodes, a packet should traverse to reach destination, by using a label stack of "unique label" of transit routers.The decision will be taken at ingress through defining label stack to be pushed. Any details on explicit routing implementation is a case of further study and thus beyond the scope of this document. Remote LFA enhancement This mechanism eliminates the need for creation of targeted session with the identified PQ node identified in the discovery of the backup path. Every loopback interface address present in the network is a node in the network and since every loopback address is bind to a unique label, we have a network with nodes having unique labels. All LDP speaking routers have consistent information of labels to reach any LDP speaking router (node) in the network [Page 6] Internet Draft Unique and Consistent Label LDP March 2015 PE1(S)-------P1(L1)-------P2(L2)------PE2(D) | | | | | | P3(lo0,L3)-------P4(L4)--- PE1-Source PE2- Destination The primary path between PE1 and PE2 is via P1 and P2. In case of link failure between P2 and PE2 the P2 becomes the point of local repair (PLR) the possible backup path to reach PE2 is via P3 and P4 in case P4 is identified as the PQ node. For this example let us assume that the backup path is PE1--->P1--->P2--->P1--->P3--->P4--- >PE2 The PLR in this case P2 like any other node in the network understands that label D is used to reach the egress PE (destination) and it also understands that label L4 is to be used to make the traffic reach to node P4 (identified PQ node).This removes the requirement of a targeted LDP session with the identified PQ node (P4 in this case) to learn the label L4 needs to forward the traffic to PE2 Assuming PQ node identified is P4 in the above example, the label to reach P4 (L4) is applied on top of label D and the packet is sent on the backup path Monitoring of labeled packet traffic flows With this mechanism the label for loopback address of each LDP speaking routers is made unique from a platform or an interface level to an autonomous system. This promotes easier monitoring of current flows of labelled packets in an MPLS network. With now consistent outer labels for all labelled traffic through the network, we identify from the label, the egress router for any labelled packet traversing on any link of the MPLS network. [Page 7] Internet Draft Unique and Consistent Label LDP March 2015 Interoperation This section explains the scenarios of LDP operation where the capability to support this mechanism does not match among few routers in the network PE1(S)-------P1(L1)-------P2(L2)------PE2(D) | | | | | | P3(lo0,L3)-------P4(L4)--- Assumption 1: Only P1 supports this mechanism With capability negotiation, P1 understands that none of its peer has the "unique label" capability support. Neither R1 creates a "unique- label" TLV nor does it create "unique-label-php" TLV. In case of mismatch of this capability among LDP peers, the LDP session will not be brought down and LDP shall continue to behave as per its classic implementation. Assumption 2: Only P1 & P2 support this mechanism. With capability negotiation, P1 and P2 understand that only they have unique label capability. P1 advertises L1 for its loopback address and send it in "unique-label" TLV to P2. P1 also generates 0 or 3 for its loopback address and send it in "unique-label-php" TLV to P2. P2 will use the received "unique-label-php" TLV to update its LFIB and advertise the same label L1 with "generic label TLV" (as explained in LDP RFC 5306) to PE2.P2 and PE2 will behave as native LDP peers with no support for this capability and will send a generated label of P1's loopback address to PE2. [Page 8] Internet Draft Unique and Consistent Label LDP March 2015 IANA Considerations This document requires the following code points to be assigned by IANA: - LDP message code point for the Capability message for Unique and Consistent Label LDP. - LDP TLV code point for the Unique Label TLV. - LDP TLV code point for the Unique Label PHP TLV. Security Considerations The security considerations of [RFC5286] and [RFC5036, RFC7358] also apply. Acknowledgments We would like to thank Pravin Bhandarkar for their contributions to this document. Normative References [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC7358] K. Raza, S. Boutros, L. Martini, "Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)", October 2014 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative References N/A [Page 9] Internet Draft Unique and Consistent Label LDP March 2015 Authors' Addresses Nipun Chawla Juniper Networks Electra, Exora Business Park, Bangalore, Karnataka, India 560103 EMail: nipunc@juniper.net Rajat Setia Juniper Networks Electra, Exora Business Park, Bangalore, Karnataka, India 560103 EMail: rsetia@juniper.net Himanshu Tambakuwala Juniper Networks Electra, Exora Business Park, Bangalore, Karnataka, India 560103 EMail: tambakhk@juniper.net [Page 10]