Internet Draft draft-casey-mpls-vpn-00.txt November 1998 MPLS Working Group L. Casey Internet Draft I. Cunningham Expiration Date: May 1999 R. Eros Nortel Networks November 1998 IP VPN Realization using MPLS Tunnels Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft describes a method of using MPLS to realize a provider IP VPN capability. The approach described here exploits the Label Switch Path (LSP) mesh implicitly established between all edge routers in an MPLS domain [4]. It uses 2 levels of LSP tunneling. The outer or base level is the hop by hop LSP tunnels that interconnect all VPN Border (Label Switch) Routers (VBR’s). The "bottom of label stack", nested level provides logically single hop tunnels between VBR’s. For each IP VPN, single hop nested tunnels are established between all VBR's serving that particular VPN. The draft outlines the components involved in the MPLS IP VPN architecture and outlines how they interact. The proposed realization is caste in terms of the VPN areas introduced in [1] and is geared to take advantage of a virtual router (VR) capability in the VBR's. This results in a powerful and flexible method of providing an IP VPN service that meets the requirements outlined in [3]. Also described are two extensions: offering MPLS VPN service to the customer (rather than IP service) and using Label Switching to traverse VPN areas[1]. Casey, et al. [Page 1] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 Table of Contents 1. Introduction 3 1.1 IP VPN 3 1.2 VPN Areas 3 1.3 VPN Border Routers - VBR's 3 1.4 Virtual Routers - VR's 3 1.5 MPLS based IP VPN's 4 1.6 Terminology 4 2. Architectural Overview 5 2.1 Components 5 2.1.1Enterprises, VPN-ID's and Enterprise Sites 5 2.1.2Stub Links 6 2.1.3VBRs and VR's 6 2.1.4Base Network and interior LSR's 7 2.2 Operation 7 2.2.1Establishing VPN Areas 7 2.2.2Establishing a new VPN 8 2.2.3Learning Site Reachability Information: 8 2.2.4VPN member dissemination: 8 2.2.5Nested Tunnel Mesh Establishment 9 2.2.6Intra VPN reachability 9 2.2.7IP Packet Forwarding 9 3 Details 9 3.1 VPN membership discovery 9 3.1.1Label space for nested labels 11 3.2 Detailed VBR Forwarding Behavior 11 3.3 A note on QoS and diff-serv 11 4 Extending the scope of MPLS. 11 4.1 Extending MPLS into the enterprise site networks. 11 4.2 Using MPLS between two or more MPLS VPN areas 12 5 Properties of the proposed scheme 12 5.1 IP VPN attributes 13 5.1.1A Routed IP service 13 5.1.2Data privacy 13 5.1.3Address Isolation 13 5.2 Other properties 13 5.2.1Separation of state 13 5.2.2Automatic configuration of VPN's. 14 5.2.3Exploits IP's Resilience 14 5.2.4Shared Bandwidth between Enterprises 14 5.2.5Engineerable to Enterprise Requirements 15 5.2.6Tracks MPLS Improvements 15 5.3 Scaling Factors 15 5.3.1Label Space Considerations 15 5.3.2VPN membership dissemination 16 6. Security Considerations 16 6.1 User Data Privacy 16 6.2 Service Provider Security 17 7. Intellectual Property Considerations 17 8. References 18 9. Authors' Addresses 18 Casey, et al. [Page 2] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 1.Introduction 1.1 IP VPN In [3] Heinanen, Glesson and Lin provide a definition of an IP VPN, or VPRN (Virtual Private Routed Network), and summarize its properties: address isolation, data privacy and intra VPN routing. In this context, an IP VPN is provided by a service provider as a service offering to enterprises. The IP specificity of an IP VPN arises because the service offered includes IP routing. (Since the underlying network technology described here is Multi-Protocol Label Switching, schemes similar to that proposed here could be used to offer other of routed protocol VPNs, e.g. an IPX VPN service). [3] also describes the procedures needed for an IP VPN to operate and provides examples of the multiple implementation options that exist for each procedure. 1.2 VPN Areas In a companion Internet Draft to this one [1], the IP VPN architecture of [3] is extended by the introduction of VPN areas. A VPN area is a partition of the service provider's network resources used for providing IP VPN service. A prime goal of VPN areas is to allow an IP VPN Service Provider to partition his base network based upon administrative domains, and/or network technology, and/or IP VPN implementation choices. The reader may consult [1] for the rationale and properties of VPN areas, but for the purposes of this draft, he or she can equate a VPN area with an MPLS domain [4]. 1.3 VPN Border Routers - VBR's All proposals for IP VPN's distinguish the first IP device in the path between the enterprise's network and the provider's shared network. Unfortunately, there is no common term for it. In this Internet Draft we use the term VPN Border Router or VBR. VBR's are located at the edge of VPN areas: they serve as tunnel ingress and egress points for enterprise IP traffic. (In multi- VPN area networks they also serve as the gateway device between VPN areas. For more details see [1].) 1.4 Virtual Routers - VR's A VBR may be dedicated to a single enterprise or it may be shared over many enterprises. In the latter case, it has to maintain separate forwarding tables for each VPN it serves, since their IP address spaces may not be distinct. If the reachability information needed to populate these forwarding tables is configured and exchanged on a per VPN basis then we say that the VBR supports Virtual Routers. (Virtual Routers are Casey, et al. [Page 3] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 described further in [1] and [7]). In this Internet Draft we assume that each VBR supports a Virtual Router (VR) per VPN that it serves. However, in fact there would be few changes if reachability information were acquired by other methods, such as [2]. 1.5 MPLS based IP VPN's This Internet Draft describes an implementation for a VPN Area that coincides with an MPLS domain (see [4]). If the entire Service Provider network is a single MPLS domain then the implementation provides the entire IP VPN service. Mechanisms to implement IP VPN service over MPLS networks have been proposed in [2], [6] and [7]. There are significant differences between all of these proposals. This proposal is closest to [7] in that is makes the use of Virtual Routers explicit (which [6] supported but did not describe). It differs from [7] in that it does not require IP multicast support in the service provider's base network. Rather this proposal exploits the tunnel mesh formed in an MPLS area by the topology driven implicit LSP set-up. This proposal uses just the functionality of MPLS that will be available in early deployments. Unlike [6] it does not require explicit LSP set-up. The MPLS architecture [3] and its Label Distribution Protocol [5], when combined with architectural constructs described in this document, provide a very flexible and powerful basis for building IP Virtual Private Networks 1.6 Terminology In addition to the MPLS related terminology of [4] the following terms are introduced Base label A label used by the base network as part of a hop by hop LSP. Base network The provider's IP/MPLS network LDP Label Distribution Protocol [4] LSP Label Switched Path [4] LSR Label Switching Router [4] MPLS Domain A set of MPLS enabled nodes that are contiguous at the outermost label stack level. (A clarification of the definition in [4]) Casey, et al. [Page 4] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 Nested label Label pushed onto label stack first, to identify nested LSP tunnel link. Nested LSP tunnel A LSP in which the links between nodes are hops are themselves base network LSP's. The label for a nested LSP tunnel link is pushed onto the label stack before the base label. Peer label A nested label used to identify the single logical hop between peer VR's Peer VR's VR's that serve the same IP VPN within the same VPN area. Stub link Dedicated IP link between a VBR and an enterprise site VBR VPN Border (Label Switched) Router VR Virtual Router VPN Area A partition of the base network, upon which IP VPN service is offered. Within a VPN Area the various VPN mechanisms (tunnelling, VPN membership discovery etc.) are the same. 2.Architectural Overview 2.1 Components The key elements of the MPLS based VPN architecture proposed in this draft are shown in Figure 1. +----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+ |EntR|----|VBR|---|LSR|--|LSR|---|VBR|---|LSR|---|VBR|----|EntR| +----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+ Enter- <--------VPN Area-------> <---VPN Area----> Enter- Prise <-----MPLS Domain-----> <--MPLS Domain--> prise Figure 1: IP VPN Path over 2 VPN Areas 2.1.1 Enterprises, VPN-ID's and Enterprise Sites The purpose of an IP VPN is to carry IP traffic between geographically dispersed sites of an enterprise. An enterprise that wants IP VPN service is first assigned a VPN- ID by the service provider. The VPN-ID as an identifier that is Casey, et al. [Page 5] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 unique within the carrier or group of carriers offering IP VPN service. (Strictly speaking for this proposal, a VPN-ID needs only be unique within a VPN area. However, we propose that a 16 bit VPN-ID be used that is unique within an AS. Prepending the AS number will then give a 32 bit globally unique VPN-ID, suitable for cross provider administrative purposes). 2.1.2 Stub Links All but the smallest of sites will interface to the provider's network from an enterprise router (EntR in figure 1) over a stub link. (Very small sites might not have an enterprise router, instead they might consist of a single LAN subnet, e,g an Ethernet, served directly from a VBR). Enterprise sites are connected to VBR's by dedicated stub links. The links may be logical (e.g. a Frame Relay VC) or physical, but they carry only traffic of the particular enterprise. The service offered on stub links is routed IP. There will be agreement between enterprise and provider on such factors as the routing protocol for each stub link. Since the VBR will participating in a routing exchange with enterprise routers it must have an IP address compatible with the enterprise's IP address space. An Enterprise may wish to use the same link for its traffic to and from the Internet or some extranet(s). This is most securely done by using different Layer 2 connections or tunnels, but a VBR might be able to separate out non-VPN traffic based upon its destination address. The handling of such traffic is outside the scope of this draft. Some larger Enterprise sites may be "not so stubby". They may have multiple links, from the same or different enterprise routers, to the same VBR or to different VBR's. There might be direct links between enterprise sites outside of the VPN. 2.1.3 VBRs and VR's VBR's are located at the edge of VPN areas. In this proposal they are edge LSR's: they serve as tunnel ingress and egress points for enterprise IP traffic crossing the provider's shared network. In multi VPN area networks, they also serve as the gateway device between VPN areas. We say that a VBR serves a particular VPN if it terminates one or more stub links to enterprise sites of that VPN. A gateway VBR that straddles two or more VPN areas serves a particular VPN if it forwards traffic for that VPN between the areas. With a VR implementation there is one VR realization on a VBR for each VPN that VBR serves. Each VR in effect terminates all the stub links of one enterprise. Casey, et al. [Page 6] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 A VBR may serve just one VPN, in which case it has just one VR (but since it is a LSR, it is also running a router instantiation in the provider's IP address space and routing regime). The more interesting case is when a VBR serves a large number of VPN's and consequently has a large number of VR realizations. 2.1.4 Base Network and interior LSR's The base network is the provider's underlying network that is shared amongst enterprises' IP VPN service. Here the base network is an MPLS network. The VBR's are MPLS edge nodes. In general, they will be connected to interior Label Switch Routers (LSR's). In this proposal the interior LSR's have no knowledge of the VPN service. They do not see native packets of the enterprises; all VPN traffic is tunneled through them. 2.2 Operation 2.2.1 Establishing VPN Areas A carrier, or consortium of carriers, (the Provider) wishing to offer IP VPN service has first to configure one or more MPLS domains. Each MPLS domain becomes a VPN area. The VPN area consists of VBR's around the edge and plain (non-edge) LSR's, interconnected by links. The interfaces to the links each have assigned to them an IP address from the provider's IP address space. In particular a VBR has an IP address in the Provider's IP address space. This address is not directly visible within any of the IP VPN's that the VBR will support. The provider determined routing regime determines routes within the MPLS domain and then, as per normal MPLS operation, LDP is invoked to establish implicit LSP's across the MPLS domain. The result is a full mesh of LSP's between all edge LSR's (which includes all VBR's). I.e. in each VBR's the is a Forwarding Equivalence Class (FEC) to next hop label map [4] that has an entry in it for every other VBR for the first hop of an LSP to that VBR. This defines the base tunnel mesh. We call these first hop labels in the FEC map base labels. They will be used as the top of stack labels for all inter VBR traffic. Base labels will be swapped at each LSR on the path to the destination VBR. (Since there are going to be two labels on the MPLS packets in this scheme, the somewhat confusing terminology of [4] would have base labels called level 2 labels - the LSP's that form the base tunnel mesh between VBR's would be called level 2 LSP's). Casey, et al. [Page 7] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 2.2.2 Establishing a new VPN The IP VPN Provider selects VBR's that will serve the new VPN and configures a VR at each one with the VP-ID. The provider then provisions stub links between VR's and one or more routers at each enterprise site. The stub link interfaces are assigned IP addresses from the enterprise's IP address space. (Note that in fact, if the provider has a globally unique subnet address range, he can reuse it within every IP VPN. It will not overlap with the enterprise IP address space whether the enterprise is using its own globally unique address space, or is using private addresses, 10.x.x.x etc). If the IP VPN to be established spans multiple VPN areas the provider must enable VR's in some of the gateway VBR's that straddle the relevant VPN areas. These VR's will participate in the following steps in all the VPN areas that they have been configured to operate in. 2.2.3 Learning Site Reachability Information: Heinanen et al. in [3] suggest a number of mechanisms for the VBR to learn the set of address prefixes that are reachable over the stub link to an Enterprise site. Using a VR to exchange routing information with one or more enterprise site routers is the most general mechanism. Part of the stub link configuration is to specify what routing protocol runs over it, between the Enterprise Router and the VBR. Of course, for genuine stub enterprise sites the degenerate routing regime is default routing at the enterprise router and static routing at the VR towards the enterprise site. 2.2.4 VPN member dissemination: Concurrent with a VR learning the IP address prefixes of the enterprise sites it is directly connected to, the VR needs to find its peer VR's. It has to discover which other VBR's in the VPN area serve its VPN. Although [3] suggests a number of mechanisms for this step, the one proposed here is unique to MPLS. Basically, the VR offers to establish a direct LDP session with every other VBR in the VPN area. But only VR's serving the same VPN will discover each other, and go on to establish pair- wise LDP sessions with each other. LDP sessions will only be successfully established between (the VR's in) VBR's that are supporting the same VPN's. A more complete description of this step is given in Section 3.1. Casey, et al. [Page 8] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 2.2.5 Nested Tunnel Mesh Establishment With every VR having an LDP session with every other VR of the same VPN, the stage is set to establish MPLS single hop nested tunnels between all the VR's, forming a private tunnel mesh. Each VR offers a single label to its peer (the upstream VR) for it to use when forwarding traffic to it. The peer VR will store this in a forwarding table as the nested label (i.e. the first label to be pushed on the label stack) for the destination VR). 2.2.6 Intra VPN reachability The first traffic that will flow over the nested tunnels is the exchange of routing information between VR's. We assume that when a VR is first configured for an IP VPN, part of the configuration information is the routing protocol that it should use "intra VPN". It would also be given any security credentials that it needs in order to participate as a neighbour router to the other VR's. After any discovery phase of the "intra VPN" routing regime, each VR will be advertising the enterprise address prefixes reachable through it. 2.2.7 IP Packet Forwarding As a result of routing exchanges between peer VR's and between VR's and enterprise routers, as appropriate, each VR will build a forwarding table that relates enterprise address prefixes (forward equivalency classes) to next hop. The next hop could be stored as the IP addresses of the end points the nested LSP tunnel to be used, or it could just be the tunnel labels (both levels). When IP packets arrive whose next hop is a VBR, the forwarding process pushes first the label for the peer VR (the nested tunnel label). Then the base label, for the first hop of the base network LSP that leads to the VBR, is pushed onto the packet. The doubly labeled packet is then forwarded to the next LSR in the base network LSP. When the packet arrives at the destination VBR the outermost label may have changed several times but the nested label has not changed. As the label stack is popped, the nested label is used to direct the packet to the correct VR. 3 Details 3.1 VPN membership discovery This section examines more closely the VPN membership discovery process: the way that each VR discovers all other VR's in the VPN area that are serving the same IP VPN. The entire process is enabled by the fact that each VBR has a set of labels for LSP's that lead to all other VBR's in the VPN Casey, et al. [Page 9] Internet Draft draft-casey-mpls-vpn-00.txt November 1998 area. This is the result of the basic MPLS implicit LSP construction process. We call this resulting mesh of MPLS hop-by- hop LSP's the base network tunnel mesh. An advantage of using MPLS is that the mesh of LSP's is self-healing in the event of interior, base network, topology changes. There is no route re- calculations performed by the VR's. Note that if the MPLS base network is used for traffic other than IP VPN's then some method of flagging VBR IP addresses from other FEC's is needed. A suggested method is that an unique address prefix be assigned to the VPN area and addresses from it only be used for VBR interfaces. Other methods are for further study. The LDP session initiation process [5] is used as the method of VR's discovering their peers, since the ultimate intent of the scheme is to establish a second level of MPLS tunnels. Every VR sends an LDP hello message down every base network LSP that exits its VBR. Hello messages (and any subsequent session messages) are encapsulated with the base MPLS label so that they are carried all the way to destination VBR. The LDP hello message is a form of query to determine if a VR for the same VPN (a peer) resides at the destination VBR. The VPN-ID (16 bits) is carried in the header of the LDP link hello as the