Internet Draft Pascal Menezes Expiration Date: Nov 2002 Ting Cai Don Flynn Terabeam Yakov Rekhter Kireeti Kompella Juniper Networks Loa Andersson Ufors Marc Lasserre Riverstone Sunil Khandekar Timetra Networks Hamid Ould-Brahim Nortel Networks Giles Heron PacketExchange Ltd. Hans Johnsen Tropic Networks, Inc. Hierarchical MPLS Services using 2547bis and BGP/MPLS draft-menezes-hierarchical-mpls-service-00.txt Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 that are valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "works 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. Abstract This document describes a network service model for service providers to deliver economical layer 2 VPN services using hierarchical MPLS. The service model builds on top of 2547 and Internet Draft - Expires Dec. 2002 1 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 BGP/MPLS and extends to building L2VPN services between customer sites with a scalable peering model. It reduces the cost of services for downstream providers by using a distance-insensitive IP Network Service Provider (NSP) as a WAN partner to connect distant regions. It simplifies downstream providerÆs operation and improves the scalability of a traditional standard overlay model by allowing the downstream provider to peer with the upstream provider for both Internet transit and L2VPN services. Table of Contents 1 Specification of Requirements..................................2 2 Introduction...................................................2 3 The Peering Model and Framework................................5 3.1 LSP Hierarchical Model.......................................6 3.2 Class of Service Mapping.....................................7 4 Technical Details..............................................8 5 Example of Operations..........................................9 6 Security Considerations.......................................10 7 Acknowledgements..............................................10 8 Reference.....................................................10 9 AuthorsÆ Addresses............................................10 1 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 RFC 2119 [1]. 2 Introduction Traditionally, local exchange carriers buy Internet transit and VPN services from Tier 1 service providers and resell such services to enterprises or other customers. To provide VPN services, one possibility is to use Frame Relay or ATM circuits, but it is costly to lease large-circuit bandwidth over long distances. And it is also complex to operate both LAN and WAN networks as LAN and WAN are often built on different technologies such as Ethernet and SONET. Another possibility is to use MPLS/VPN services which are typically distance-insensitive. To traffic engineer the network and to provide QoS, VPN, and other services, the overlay model is typically deployed (see Figure 1). In the overlay model, explicitly routed MPLS Label Switched Paths (LSPs)are established end-to-end to form a full-mesh virtual network on top of the underlying physical network. This approach raises scalability concerns because it requires N^2 Menezes Internet Draft - Expires Dec. 2002 2 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 square number of LSPs (where N is the number of sites being connected), with routers at the end of these LSPs having routing peering with each other; and it demands configuration changes at all sites when a new site is added. Also, it is more complex to design and operate routing that spans not just individual sites but the wide area as well. CE (LEC) / | \ / | \ / | \ / PE (NSP) \ / | \ / | \ / | \ / | \ / | \ CE (LEC) /---PE (NSP)------------------- PE (NSP)--- \ CE(LEC) \ | / \ | / \ | / \ | / \ | / \ | / \ PE (NSP) / \ | / \ | / \ | / CE (LEC) Figure 1. Overlay Model We propose a generic peering model (see Figure 2) that works for any upstream and downstream providers. The term upstream/downstream provider is relative and upstream provider can be loosely defined as the provider further away from the end users. For simplicity, we use the term National Service Provider or NSP as the upstream provide for the rest of the document. The peering model improves the scalability of the overlay model by pushing the complexity of operating a WAN backbone to upstream providers, thus reduces the operating cost of local exchange carriers (LEC). In this model, a LEC router (CE) that connects the LEC to a WAN has routing peering not with LEC routers in other sites but with a WAN router (PE). As a result of this peering, the LEC router receives routing information for other sites, even if the router doesnÆt have routing peering with LEC routers in other sites. In addition, the NSP creates a collection of ôsink trees,ö where each tree is rooted at a particular site with the rest of the sites Menezes Internet Draft - Expires Dec. 2002 3 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 forming leaves of that tree. By using the hierarchical VPN approach described in [2], the NSP could support multiple LECs. Moreover, by using the concept of MPLS label stacking, each LEC provider could establish LSPs and interconnect routers in different sites without introducing additional routing/forwarding overhead on the NSP. Finally, the LEC could use MPLS label stacking to further reduce routing/forwarding overhead within each LEC site. Menezes Internet Draft - Expires Dec. 2002 4 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 CE (LEC) | | | PE (NSP) / | \ / | \ / | \ / | \ / | \ CE (LEC)---PE(NSP)_/---------------------- \ PE (NSP)--- CE(LEC) \ | / \ | / \ | / \ | / \ | / \ | / PE (NSP) | | | CE (LEC) Figure 2. Peering Model 3 The Peering Model and Framework To accommodate these requirements, this document proposes that a VPN hierarchical model to be used, a model in which the lower hierarchy is operated by the NSP and the higher hierarchy is made up of inter- site LEC services operated by the LEC. Generation of these lower hierarchical connections is the responsibility of the NSP and is coordinated with the LEC via an automated procedure (which is the purpose of this document). This document focuses on MPLS as the technology for hierarchical capability, the use of RFC 2547bis [2] as the mechanism that the NSP would use internally to offer VPN services to the LEC, and the use of BGP [3] to exchange both the routing and label information between the NSP and the LEC. An automated procedure, which is based on the mechanisms described in [2] and [3], automates the NSPÆs generation of inter-site LSPs that can be used by the LEC. Other mechanisms and standards that can be used to accommodate these same requirements are for future study. Menezes Internet Draft - Expires Dec. 2002 5 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 ( LEC 1 ) ( NSP Network ) ( LEC 2 ) ( ) ( ) ( ) ( ) ( )( ) ( PE1 - LEC - CE1 --- PE1 û P1 û- P2 û PE2 --- CE2 û LEC û PE2 ) ( BB ASBR ) ( )( ASBR BB ) ( ) ( ) ( ) ( ) ( ) ( ) <------><----------------><------> Automated Announcement NSP Service Automated Announcement Figure 3. The Peering Model In Figure 3, the NSP PE routers that connect to the LEC at each site form peering relationships with the LEC routers (e.g., PE1 forms routing peering with CE1) (this is a function of the NSPÆs VPN services using RFC 2547bis [2]). While the LEC may be under the same administrative control for each site, we assume that the LEC in each site forms a separate IGP domain. The LEC CE router(s) in a given site exchanges only with the PE router(s) of the NSP routes and labels for the destinations that originate from that site. When a site is added to the network, the CE router automatically advertises to the NSP PE its routes for the destinations in that site, as well as labels for these routes, by using BGP [3]. The NSP PE routers in turn distribute the routes to their PE peers through BGP, and each PE peer further delivers the routes to other CE routers. Other sitesÆ CE routers that are in the same virtual private network as the new CE router will receive announcement of the new CE router and, therefore, have an LSP connection back to this new CE router and to other destinations reachable through this router (these are the destinations in the site to which the router belongs). Thus, LSPs among CE routers are automatically established, and these LSPs could be used as inter-site LEC services. It is important to note that these inter-site LSPs that are generated by the NSP are hierarchical in nature, in the sense that they could be used to carry all kinds of traffic, including another higher-level LSP (which could be signaled by RSVP-TE or LDP) or IP traffic or both. Moreover, the procedures/protocols for establishing the LSPs at one level of the hierarchy (e.g., inter- site service LSPs) need not be the same as the procedures/protocols for establishing the LSPs at other levels of the hierarchy (e.g., inter-site LSPs). 3.1 LSP Hierarchical Model It is important to note the scalability achieved through hierarchical LSPs. For example, as shown in Figure 4, Ps of NSP network only need to store labels to reach its PEs. These PEs only need to know how to reach the corresponding CEs that it services. Menezes Internet Draft - Expires Dec. 2002 6 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 It is not necessary for the NSPÆs PEs to understand or care about the inter-site service LSPs of the LECs. The PEs in the NSPÆs network do not see any label stack other than the inter-site LSP. Therefore, when a LEC creates an inter-site service LSP from one site to another across the NSP, the NSP has no state information for that LSP (this is assuming that the inter-site service LSP is created by using RSVP-TE). Therefore, an NSP for a given PE can accommodate many LEC customers in a scalable fashion. Moreover, an inter-site service LSP could be used by a LEC to offer services, such as Layer 2 VPNs, to multiple customers, thus further improving the scalability of the approach. ( LEC 1 ) ( NSP Network ) ( LEC 2 ) ( ) ( ) ( ) ( ) ( )( ) ( PE1 - LEC - CE1 --- PE1 û P1 û- P2 û PE2 --- CE2 û LEC û PE2 ) ( BB ASBR ) ( )( ASBR BB ) ( ) ( ) ( ) ( ) ( ) ( ) <------NSP LSP-----> <------------Inter-Site LSP --------> <-----------------------Inter-Site Service LSP -----------------> Figure 4. Hierarchical LSP Model 3.2 Class of Service Mapping An important aspect of this service is for the NSP to offer CoS capabilities so that SLAs within a LECÆs site also can be honored for inter-site services. To achieve this requirement, the markings of any higher-level LSP (or IP packet) SHOULD be propagated to lower-layer LSPs, including traffic-engineered LSPs that are within the NSPÆs network. This functionality offers great scalability because as each packet (IP or MPLS) enters the NSPs network, it carries with it a marking that indicates which CoS PHB [diff serv] it needs. Therefore, the propagation of the marking from higher- layer services to lower-layer LSPs is completely feasible as long as a LEC enters into a bilateral CoS agreement with the NSP by Menezes Internet Draft - Expires Dec. 2002 7 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 specifying the behavior of each CoS marking. Future work will describe how a hard QoS model can also be achieved using a similar process. ( LEC 1 ) ( NSP Network ) ( LEC 2 ) ( ) ( ) ( ) ( ) ( )( ) ( PE1 - LEC - CE1 --- PE1 û P1 û- P2 û PE2 --- CE2 û LEC û PE2 ) ( BB ASBR ) ( )( ASBR BB ) ( ) ( ) ( ) ( ) ( ) ( ) <------------------> NSP LSP EXP Marking <----------------------------------> Inter-Site LSP EXP Marking <---------------------------------------------------------------> Inter-Site Service LSP EXP Marking 4 Technical Details As we mentioned above, the inter-site LSPs are created by following the procedures described in Section 9 of [2]. In addition, this document assumes that BGP is used as the protocol for exchanging routing and label information between the PEs of the WAN provider and the CE-ASBRs of the LEC(as specified in [3]). Note that when a CE-ASBR advertises a route to a WANÆs PE, the label associated with this route should be Implicit NULL. This document assumes that the inter-site service LSPs are established by using RSVP-TE (however LDP could easily be used). The RSVP-TE setups for these LSPs are carried by the NSP (including the ingress and egress PEs of the NSP) as plain data; neither the ingress nor the egress NSP PEs create any RSVP and/or labeling states for these setups. Doing this avoids the need for the NSP to maintain state on a per inter-site service LSP basis. This is key to this proposal as this is what allows the NSP to offer hierarchical MPLS services and yet scale to support tens of thousands of LECs. No state information is stored on the NSPs PEs. The setups create RSVP and label state on the routers within LEC, including the routers (CEs) that peer with the NSP routers but not on any of the NSPÆs routers. With respect to how one would construct the Explicit Route Object (ERO) carried by the setups, there are several options. One option is for the LEC service provider to use some off-line tool to compute Menezes Internet Draft - Expires Dec. 2002 8 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 the EROs for the inter-site service LSPs. Another alternative is to compute the ERO on a per LEC basis. Using the example shown in Figure 4, with this alternative, PE1 in LEC1 would compute the ERO for the segment of the path through LEC1, and CE2-ASBR would compute the ERO for the segment of the path through LEC2. For the purpose of handling the ERO carried in the setups, one alternative is to assume that the LEC routers that peer with the NSP routers are treated as being one hop away from each other. Using the example shown in Figure 4, for the purpose of handling the ERO carried by the RSVP-TE setup for an inter-site service LSP from PE1 in LEC1 to PE2 in LEC2, CE1-ASBR and CE2-ASBR are treated as being one hop from each other. Another alternative for handling the ERO is to require that the originator of an inter-site service LSP specify the hop over the NSP network as a loose one. Again, using the example shown in Figure 4, PE1 in LEC1 would specify CE2-ASBR as a loose hop in the ERO. 5 Example of Operations Consider the following topology AS1 (LEC) | AS2 (WAN) | AS3 (LEC) R1---R2---R3---R4--....--R5---R6---R7---R8 where AS2 provides WAN VPN services to a LEC service provider composed of AS1 and AS3. The routing protocol between R3 and R4 is eBGP. The same is true for R5 and R6. R6 advertises to R5 (via eBGP) a single address prefix ("AS3 prefix") that covers all the destinations in AS3 with itself as a next hop. R6 advertises the "AS3 prefix" to R5 with an Implicit NULL label. R5 advertises this prefix to R4 with label L2 and next-hop R5. R4 advertises the prefix to R3 with label L1 and next-hop R4. With this in mind, the following illustrates MPLS forwarding associated with the inter-site LSP (LSP from R3 to R6). LSR dest action R3 "AS3" push L1 R4 L1 swap L1 with L2; push R5 L2 pop L2, forward to R6 For the inter-site service LSP (R1-R8), the RSVP hops are R1, R2, R3, R6, R7, and R8. R{2,3,6,7} send RSVP labels M{1,2,3,4}, respectively, to the previous hop. With this in mind, the following illustrates MPLS forwarding associated with the inter-site service LSP (LSP from R1 to R8). Menezes Internet Draft - Expires Dec. 2002 9 Hierarchal MPLS Services using 2547 and BGP/MPLS June 2002 LSR dest action R1 R8 push M1 R2 M1 swap M1 with M2 R3 M2 swap M2 with M3; push L1 R4 L1 swap L1 with L2; push R5 L2 pop L2, forward to R6 (top label is now M3) R6 M3 swap with M4 R7 M4 PHP/explicit null R8 - - 6 Security Considerations This document does not affect the underlying security issues of MPLS and does not introduce any security considerations that are not already part of the existing usage for LSPs. 7 Acknowledgements Special thanks to Yakov Rekhter and Ting Cai for their primary contribution to this draft. 8 Reference [1] Bradner, S. "Key Words for Use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [2] Rosen, E., et al. "BGP/MPLS VPNs," draft-ietf-ppvpn-rfc2547bis- 00.txt, July 2001. [3] Rekhter, Y., and E. Rosen. "Carrying Label Information in BGP-4," RFC3107, May 2001. [4] "RSVP-TE: Extensions to RSVP for LSP Tunnels," draft-ietf-mpls- rsvp-lsp-tunnel-08.txt. Work in progress. [5] Kompella,K., and Y. Rekhter. "LSP Hierarchy with MPLS TE," draft-ietf-mpls-lsp-hierarchy-02.txt, February 2001. 9 AuthorsÆ Addresses Pascal Menezes Terabeam 14833 NE 87th St. Phone: (206) 686-2001 Redmond, WA, USA Email: Pascal.Menezes@Terabeam.com Ting Cai Terabeam 14833 NE 87th St. Phone: (206) 255-6220 Redmond, WA, USA Email: Ting.Cai@terabeam.com Menezes Internet Draft - Expires Dec. 2002 10 Internet Draft June 2002 Don Flynn Terabeam 14833 NE 87th St. Phone: (206) 321-4724 Redmond, WA, USA Email: Don.Flynn@Terabeam.com Yakov Rekhter Phone: (408) 745-2000 Juniper Networks Email: yakov@juniper.net Loa Andersson Utfors Research, Architecture and Future Lab (URAX) Utfors AB R…sundav„gen 12 Box 525, 169 29 Solna, Phone: +46 8 5270 2000 Sweden Email: loa.andersson@utfors.se Marc Lasserre Riverstone Networks 5200 Great America Pkwy Phone: (408) 878-6550 Santa Clara, CA 95054 Email: marc@riverstonenet.com Sunil Khandekar Timetra Networks 274 Ferguson Drive Phone: (650) 237-5100 Mountain View, CA 94043 Email: sunil@timetra.com Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Phone: (613) 765-3418 Ottawa ON K1Y 4H7 Canada Email: hbrahim@nortelnetworks.com Giles Heron PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL Phone: +44 207 377 4130 United Kingdom Email: giles@packetexchange.net Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Phone: (408) 745-2000 Sunnyvale, CA 94089 Email: kireeti@juniper.net Hans Johnsen Tropic Networks, Inc. 135 Michael Cowpland Dr, Suite 200 Kanata, Ontario K2M 2E9 Phone: (613) 270-5399 Canada Email: hjohnsen@tropicnetworks.com Menezes Internet Draft - Expires Dec 2002 11