Internet Draft Internet Engineering Task Force Juha Heinanen INTERNET DRAFT Telia Finland, Inc. Expires September 1998 Eric Rosen cisco Systems VPN support with MPLS <draft-heinanen-mpls-vpn-01.txt> 1. 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). 2. Abstract This document provides a high-level description of how Virtual Private Networks can be supported by using MPLS. Heinanen VPN Support with MPLS [Page 1] INTERNET DRAFT March, 1998 3. Introduction Intranets are one of the fast growing ways to deploy the TCP/IP protocol suite. In order to provide Intranet services to its customers, Service Providers must be able to address the problems of data privacy and addressing privacy (the use of non-unique, private IP addresses [2]). It turns out that Multiprotocol Label Switching (MPLS) [1], due to its ability to decouple packet forwarding from the context of a packet's IP header, provides a simple and effective solution to these important problems. The following sections discuss various ways to support VPNs over a Service Provider network that implements MPLS. They cover both the case where the customer VPN site participates and the case where the customer site does not participate in MPLS with the Service Provider network. In the latter case, the customer site need not implement MPLS at all. It is assumed that the customer sites exchange reachability information with the Service Provider network either using static routing or BGP; the customer sites do not need to directly exchange routing information with each other. Within the Service Provider network the assumption is that either OSPF and Label Distribution Protocol (LDP) [3] or BGP is used to distribute reachability and label binding information. 4. Virtual Private Networks (VPNs) To form a VPN over a set of customer sites connected to a Service Provider network, each such site advertises to the Service Provider a set of destinations reachable within the site, and the Service Provider network redistributes this information to all other sites in the set. Since a Service Provider network needs to support multiple VPNs, and since these VPNs could use private address spaces [2], the routing system within the Service Provider network needs to disambiguate between reachability information associated with different VPNs. To accomplish this, the Service Provider assigns each VPN its own VPN Identifier; the routing system uses a combination of this VPN Identifier and normal reachability information for disambiguating reachability information associated with different VPNs. Use of VPN Identifiers allows a single routing system to support multiple VPNs whose address spaces overlap with each other. A VPN Identifier can be constructed, for example, by appending an integer that uniquely identifies a VPN within a Service Provider Heinanen VPN Support with MPLS [Page 2] INTERNET DRAFT March, 1998 network to an Autonomous System (AS) number of that network. A site can at the same time be a member of more than one VPN. A VPN could be connected to the Internet. Exchange of routing information in support of the connectivity to the Internet could be accomplished by precisely the same means as it is accomplished in the absence of VPNs and MPLS. 5. Distribution of routing information between a customer site and the Service Provider network The customer router that connects the customer site to the Service Provider network can either participate or not participate in MPLS with the Service Provider network. In either case, the Service Provider LSR that connects the site to the Service Provider network is configured with the list of VPN Identifiers of the VPNs that the customer site belong to. 5.1. Customer router participates in MPLS with the Service Provider LSR When the customer router participates in MPLS with the Service Provider LSR, BGP is used to distribute both IP reachability information and label bindings between the customer site and the Service Provider network. Distribution of label bindings with BGP is described in [4]. This allows the customer LSR and the Service Provider LSR to inform each other about the routes that are available for each VPN and what labels have been bound to them. When the Service Provider LSR receives an advertisement from the customer LSR, the Service Provider LSR identifies the VPN that the customer LSR belongs to, and uses a combination of the VPN Identifier of that VPN and the reachability information received via this advertisement to distribute this combination within the Provider's network. Correspondingly, the Provider's LSR forwards to the customer site only those advertisements that belong to the VPN(s) that the site belongs to. If a customer site belongs to multiple VPNs, it may want to dynamically exchange information with the Service Provider network regarding which routes belong to which VPNs. This could be accomplished either by requiring the site to maintain multiple routing peerings with the Service Provider (one peering per VPN), or by requiring that the routing advertisements carry not just the reachability information, but a combination of VPN Identifier and the reachability information. This combination would allow the Service Heinanen VPN Support with MPLS [Page 3] INTERNET DRAFT March, 1998 Provider LSR to unambiguously determine how this information has to be distributed. If the customer site and the Service Provider network don't want to exchange reachability information using a routing protocol, it is still possible for them to dynamically inform each other which address prefixes belong to which VPNs by extending LDP to carry not just address prefixes, but a combination of VPN Identifiers and address prefixes. In this context one may consider treating LDP as a protocol that advertises not just label binding, but the reachability information as well. The details of doing this are left for further study. 5.2. Customer router does not participate in MPLS with the Service Provider LSR When the customer router does not participate in MPLS with the Service Provider LSR, it is assumed that reachability information between the customer router and the Service Provider LSR is distributed either via static routing or using BGP. In the case of static routing, the Service Provider LSR connected to a customer router controls (based on its configuration information) how the reachability information for the site that the customer router belongs to gets combined with the VPN Identifier(s) that the site belongs to. When BGP is used to exchange routing information between a customer router and a Service Provider router, procedures for doing this are similar to the ones described in the previous section, except that BGP doesn't carry label binding information. The most important difference between this case and the case described in the previous section is that when a customer router doesn't participate in MPLS with the Service Provider LSR, the Service Provider LSR must have unambiguous procedures by which it can classify packets arrived from directly connected customer routers into VPNs. If a site belongs to multiple VPNs, this requires that the address spaces of these VPNs do not overlap. Heinanen VPN Support with MPLS [Page 4] INTERNET DRAFT March, 1998 6. Distribution of VPN bindings within the Service Provider network When a Service Provider LSR learns a combination of VPN Identifier and reachability information (and possibly also a label binding) from a customer site, it must somehow make this combined information known to the other customer sites that are members of the same VPN. This section covers the cases where either OSPF and LDP or BGP is used to distribute reachability information and label bindings within the Service Provider network. If the Service Provider network is using OSPF to distribute reachability information, the Service Provider LSR that receives reachability information from a customer site injects this information together with the corresponding VPN identifier in its OSPF process. The VPN identifier allows the OSPF process to disambiguate among (potentially) overlapping addresses of multiple VPNs. One possibility is to use the Opaque LSA option [5]. Details of carrying the VPN Identifier in OSPF is left for further study. In addition to injecting the stream to its OSPF process, the Service Provider's LSR also advertises the corresponding label to its peers within the Provider's network using LDP. This advertisement is otherwise a normal LDP advertisement except that, as in above, the VPN Identifier is included in the LDP messages. The VPN identifier is used by the receiving LSR to disambiguate among (potentially) ambiguous routes. If the Service Provider network is using BGP to distribute reachability information, then also the corresponding labels can be piggybacked into BGP advertisements in the same way as was done above between the customer router and the Service Provider LSR. For VPN support, the advertisements must include the VPN identifier. Use of LSP hierarchy and two levels of labels [3] could be used to improved scaling properties. If the customer router does not participate in MPLS with the Service Provider LSR then the Service Provider's LSR that advertises a route reachable via the customer site also terminates the corresponding Label Switched Path (LSP) [1]. When terminating the LSP, the LSR uses the label carried by packets to map the enclosed (IP or MPLS) packets to the correct customer site. Heinanen VPN Support with MPLS [Page 5] INTERNET DRAFT March, 1998 7. Use of BGP VPN Identifiers could be carried in BGP as part of NLRI using the BGP Multiprotocol Extensions attribute [6]. The associated label binding information could be carried as part of this attribute as well, similar to [7]. In addition, VPN Identifiers could be carried in the BGP Community Attribute [8], if needed. 8. Security considerations As shown in this document, MPLS can be used to implement VPNs over a Service Provider network, where the VPNs are fully isolated from each other in terms of both visibility and packet forwarding. The data privacy is accomplished by manually associating a set of unique VPN Identifiers to the customer interfaces of the Service Provider's LSRs. The VPN Identifiers are used to limit the distribution of both reachability and label information. If a customer site has not received a label for a particular destination, it has no means to send labeled packets to that destination provided that the LSRs assign the labels so that they are unique per interface. Similarly, in the case of a non-MPLS customer site, the Service Provider network would not forward IP packets to destinations that are not advertised by the other members of the VPN. Manual configuration of the VPN Identifiers is always subject to human error. However, configuration of a single VPN Identifier once per customer interface is a much simpler process than configuration of a list of IP address prefixes, since the latter need to be modified each time a new customer site is added to or removed from the VPN. Heinanen VPN Support with MPLS [Page 6] INTERNET DRAFT March, 1998 9. Intellectual Property Considerations Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms. 10. References [1] Callon, R., et al, "A Framework for Multiprotocol Label Switching", draft-ietf-mpls-framework-02.txt. [2] Rekhter, Y., et al., "Address Allocation for Private Internets", RFC1918, Feb 1996. [3] Rosen, Eric et al, "A Proposed Architecture for MPLS", draft- ietf-mpls-arch-00.txt. [4] Rekhter, Yakov and Rosen, Eric, "Carrying Label Information in BGP-4", draft-rekhter-bgp4-mpls-00.txt. [5] Coltun, Rob, "The OSPF Opaque LSA Option", draft-ietf-ospf- opaque-02.txt. [6] Bates, Tony, et al, "Multiprotocol Extensions for BGP-4", RFC2283, Feb 1998 [7] Rekhter, Yakov, Rosen, Eric, "Carrying Label Information in BGP- 4", draft-rekhter-bgp4-mpls-00.txt. [8] Chandra, Ravi, et al, "BGP Communities Attribute", RFC1997, August 1996 11. Author Information Heinanen VPN Support with MPLS [Page 7] INTERNET DRAFT March, 1998 Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland Phone +358 303 944 808 Email: jh@telia.fi Eric Rosen cisco Systems. Inc. 250 Apollo Drive Chelmsford, MA 01824 Email: erosen@cisco.com