Network Working Group George Swallow Internet Draft Cisco Systems, Inc. Category: Standards Track Expiration Date: January 2009 Jim Guichard Cisco Systems, Inc. July 7, 2008 Network Scaling with Aggregate LSPs draft-swallow-mpls-aggregate-fec-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 Abstract This document defines a means for an Multiprotocol Label Switched network to summarize routes while maintaining end-to-end LSP connectivity thereby reducing the number of host routes that need to be carried within the interior gateway protocol. Swallow & Guichard Standards Track [Page 1] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 Contents 1 Introduction .............................................. 3 1.1 Conventions ............................................... 3 1.2 Terminology ............................................... 3 2 Overview .................................................. 4 2.1 Inter-area LSP Construction ............................... 4 2.2 Label forwarding operation ................................ 6 3 Aggregate FEC ............................................. 7 3.1 Aggregate FEC Element ..................................... 7 3.2 Label distribution procedures ............................. 7 4 Algorithmically derived de-aggregation label .............. 8 5 Security Considerations ................................... 8 6 IANA Considerations ....................................... 8 7 References ................................................ 8 7.1 Normative References ...................................... 8 7.2 Informative References .................................... 9 8 Authors' Addresses ........................................ 9 Swallow & Guichard Standards Track [Page 2] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 1. Introduction The growth of next-generation Multiprotocol Label Switched (MPLS)-based services such as l2vpn, l3vpn and so on, have introduced an explosion in the number of edge devices that are needed to deploy such services. Typically these services require an end-to-end label- switched path LSP, from ingress Label-Switching Router (LSR) to egress LSR. These LSPs are maintained between the host IP addresses of the LSRs. This requirement forces the operator to carry each host address for every edge device within their interior gateway protocol (IGP) which has a negative impact on the scale and convergence goals of their IGP. This document defines extensions to the Label Distribution Protocol (LDP) to provide a means for the end-to-end LSP path to be maintained between edge devices without the necessity of carry each and every host address within the IGP or to distribute labels throughout a domain for host addresses. This is achieved by defining an Aggregate Forwarding Equivalence Class (FEC) and an algorithmically derived label per aggregated host route which stacked together form end-to- end LSPs. 1.1. Conventions 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 [KEYWORDS]. 1.2. Terminology ABR Area border router FEC Forwarding equivalence class IGP Interior gateway protocol LDP Label Distribution Protocol LIB Label information base LSP Label-switched path LSR label-switching router NHLFE Next-hop label forwarding entry PE Provider edge [LSR] RIB Routing information base VPN Virtual private network Swallow & Guichard Standards Track [Page 3] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 2. Overview In a typical MPLS deployment today, Service Providers are either running a flat IGP or leaking the loopback addresses of their PEs between the area of their IGPs. LDP then creates LSPs based on all of these host routes. Our objective here is to eliminate the need for a full mesh of LSPs between all PE pairs. This will enable Service Providers to scale and improve the convergence of their IGPs. The basic idea is to use an LSP bound to a summarized IP prefix to deliver MPLS packets from the ingress PE, across the core, to the ABRs serving the egress PEs. Nested within these LSPs are LSPs for each of the specific hosts covered by that prefix. This is accomplished by defining two new FECs, the Aggregate FEC and the De- aggregation FEC. The Aggregate FEC is exactly like the Prefix FEC as far as routing is concerned. An Aggregate FEC differs in that at the end of the LSP, it forms the context for interpreting the next label which is bound to a De-aggregation FEC. In that regard, an aggregate LSP never uses penultimate-hop popping. Further, to ensure that an LSP exists all the way to an LSR capable of de-aggregating the FEC, labels bound to these FECs are always distributed in ordered mode. A De-aggregation FEC represents a specific host route. It is exactly the same as a Host Address FEC except that labels bound to these FECs are not distributed in LDP. Instead, the label value bound to a particular host is algorithmically derived from the host address and the prefix length of the aggregate FEC using a simple algorithm described in section 4 below. The use of these FECs is illustrated in the example below. 2.1. Inter-area LSP Construction To illustrate the construction of inter-area LSPs consider the following simple topology with one backbone area and two stub areas. Using the mechanisms described within this document, we describe an LSP is built from ingress PE4 to egress PE1 with traffic destined to 192.169.0.22/32 in VPN_1: Swallow & Guichard Standards Track [Page 4] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 Area 0 +----------------+ Area 1 | | Area 2 +----------+ +----------+ | | | | | | | +-----+ VPN_1 | | | | PE1 |------192.169.0.22 | | | +-----+ | | | | 10.10.2.1 | | | | +-----+ +------+ +------+ +-----+ | PE4 | | ABR1 | | ABR2 | | PE2 | +-----+ +------+ +------+ +-----+ | | | | 10.10.2.2 | | | | | | | +-----+ | | | | PE3 | | | | +-----+ | | | | 10.10.2.3 +----------+ +----------+ | | +----------------+ Figure 1: Example network All routers are MPLS enabled and MPLS connectivity is required between all PE routers to facilitate edge services. In the egress area (area 2), the records available are: RIB LIB 10.10.2.1/32 Labels bound to: 10.10.2.1/32 10.10.2.2/32 10.10.2.2/32 10.10.2.3/32 10.10.2.3/32 The area border router ABR2 advertises in the backbone area: - the IP prefix 10.10.2/24 (which covers all available PE routers in area 2) in the IGP - a label (say 51) bound to the Aggregate FEC 10.10.2/24 in LDP to its neighbors in area 0. ABR2 algorithmically creates a label entry for each host route covered by the summary 10.10.2/24 (see section 4). It then creates NHLFEs for each of these binding them to the next-hop labels it received for each of the specific routes. Swallow & Guichard Standards Track [Page 5] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 In the backbone (area 0), the records available are: RIB LIB 10.10.2/24 Labels bound to: 10.10.2/24 The area border router ABR1 receives the route 10.10.2/24 via the IGP and labels from its neighbors in area 0 bound to the Aggregate FEC 10.10.2/24 {22} via LDP from the next-hop router towards the route 10.10.2/24. It redistributes both the route and a label bound to the FEC into area 1. The routers in area 1, including PE4, receive the route 10.10.2/24 via the IGP and and labels from their neighbors bound to the Aggregate FEC 10.10.2/24 via LDP. In the ingress area (area 1), the records available are: RIB LIB 10.10.2/24 Labels bound to: 10.10.2/24 2.2. Label forwarding operation Using the information presented in the previous section, the label forwarding from ingress PE4 to egress PE1 is as follows: PE4 has a VPN destination 192.169.0.22/32 reachable via remote PE1 whose next-hop is 10.10.2.1/32 which is bound to say 47. PE4 only has a summary route 10.10.2/24 covering the more specific next-hop 10.10.2.1/32, but has label bindings for that aggregate FEC. Using the same algorithm as the egress ABR2, PE4 determines that the de- aggregation label for PE1 is 17. PE1 creates a VRF entry for 192.169.0.22/32 which includes a three label stack consisting of its next-hop label for 10.10.2/24, say 22, stacked upon the de- aggregation label (17) stacked upon the VPN label (47). Thus to forward a packet 192.169.0.22/32 in VPN_1, PE4 pushes on a label stack {22, 17, 47}. This is forwarded via normal label- switching to ABR2 where it arrives with the label stack {51, 17, 47}. ABR2 recognizes label 51 as context label and pops it. It then looks up label 17 in the context associated 51. ABR2 then pushes onto the label stack the LDP derived label for the local PE. Forwarding continues at this point as per normal RFC4364 procedures. Swallow & Guichard Standards Track [Page 6] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 3. Aggregate FEC A FEC TLV is defined in [LDP] section 3.4.1. This TLV serves as a container for FEC Elements. To enable distribution of the Aggregate FEC, we define a new FEC Element. 3.1. Aggregate FEC Element Aggregate FEC Element value encoding: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Type (TBD)| Address Family | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field. PreLen One octet unsigned integer containing the length in bits of the address prefix that follows. A length of zero indicates a prefix that matches all addresses (the default destination); in this case the Prefix itself is zero octets). Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary. 3.2. Label distribution procedures LSRs MUST NOT assign a NULL label value to an Aggregate FEC. Swallow & Guichard Standards Track [Page 7] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 4. Algorithmically derived de-aggregation label In order to avoid having to distribute de-aggregation labels, they are algorithmically derived from the host address with the following procedure: The network mask is inverted and applied to mask off the high-order bits of the address. The remaining bits are treated as an integer to which 16 is added. This value represented as a 20-bit integer becomes the label value. The value 16 is added in the algorithm in order to bypass the reserved label range. Issue: This algorithm may not be appropriate for IPv6. 5. Security Considerations [to be written] 6. IANA Considerations [to be written] 7. References 7.1. Normative References [LDP] Andersson, L. et al., "LDP Specification", RFC 3036, January 2001. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Swallow & Guichard Standards Track [Page 8] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 7.2. Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 8. Authors' Addresses George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 Email: swallow@cisco.com Jim Guichard Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: jguichar@cisco.com Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement Swallow & Guichard Standards Track [Page 9] Internet Draft draft-swallow-mpls-aggregate-fec-01.txt July 2008 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Notice Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Swallow & Guichard Standards Track [Page 10]