Internet Draft Network Working Group Hamid Ould-Brahim Internet Draft Bryan Gleeson draft-ouldbrahim-vpn-vr-01.txt Gregory Wright Expiration Date: January 2001 Nortel Networks Timon Sloane N.E.T Rainer Bach T-Data Rick Bubenik SAVVIS Communications Abraham Young Huawei Technologies July 2000 Network based IP VPN Architecture using Virtual Routers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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 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." Ould-Brahim, et. al [Page 1] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 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 draft describes a network based VPN architecture using virtual routers. The VPN service is built based on the virtual router (VR) concept, which has exactly the same mechanisms as a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Within a VPN domain, an instance of routing is used to distribute VPN reachability information among VR routers. Any routing protocol can be used, and no VPN-related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Virtual routers can be deployed in different VPN configurations, direct VR to VR connectivity through layer-2 or by aggregating multiple VRs into a single VR combined with IP or MPLS based tunnels. This architecture accommodates different backbone deployment scenarios, e.g. where the service provider owns their own backbone, and where the service provider obtains backbone service from one or more other service providers. 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. Table of Contents 1 Introduction ........................................ 3 2 Requirements ........................................ 4 3 Network Reference Model .............................. 5 3.1 The Backbone ........................................ 5 4 Virtual Router Definition ............................ 5 5 How VPNs are built and deployed using VRs?............ 6 5.1 VR to VR Connectivity over layer-2 Connections........ 6 5.2 Virtual Router Backbone Aggregation .................. 7 5.2.1 Relationship between the VRs and the Backbone VR ..... 8 5.2.2 Multiple Backbones connected to a single PE .......... 8 6 VPN Topology and Membership Discovery ................ 9 7 Operations and Management ............................ 10 7.1 Backbone Migration ................................... 10 7.2 Troubleshooting ...................................... 10 Ould-Brahim, et al. July 2000 [Page 2] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 8 Quality of Service ................................... 11 9 Scalability .......................................... 11 10 Security Considerations .............................. 11 11 References............................................ 11 11 Acknowledgments ..................................... 12 12 Authors' Addresses .................................. 12 14 Full Copyright Statement ............................ 14 1. Introduction Several solutions have been put forward to achieve different levels of network privacy when building VPNs across a shared backbone. Most of these solutions require separate per VPN forwarding capabilities and make use of IP or MPLS based tunnels across the backbone [VPN- VR], [VPN-CORE], and [VPN-RFC2547]. This document describes a network based VPN architecture using virtual routers. The architecture complies with the IP VPN framework described in [VPN-RFC2764]. The objective is to provide per VPN based routing, forwarding, quality of service, and service management capabilities. The VPN service is built based on the virtual router concept, which has exactly the same mechanisms as a physical router, and therefore inherits all existing mechanisms and tools for configuration, deployment, operation, troubleshooting, monitoring, and accounting. Virtual routers can be deployed in different VPN configurations, direct VR to VR connectivity through layer-2 links/tunnels or by aggregating multiple VRs into a single VR combined with IP or MPLS based tunnels. This architecture accommodates different backbone deployment scenarios, e.g. where the service provider owns their own backbone, and where the service provider obtains backbone service from one or more other service providers. Within a VPN domain, an instance of routing is used to distribute VPN reachability information among VR routers. Any routing protocol can be used, and no VPN-related modifications or extensions are needed to the routing protocol for achieving VPN reachability. VPN reachability information to and from customer sites can be dynamically learned from the CE using standard routing protocols or it can be statically provisioned on the VR. The routing protocol between the virtual routers and CEs is independent of the routing used in the VPN backbone. The routing protocol between the VRs maybe the same or it might be different than the routing mechanism used between the CE and VR. There are two fundamental architectures for implementing network based VPNs, virtual routers (VR) and piggybacking. The main difference between the two architectures resides in the model used to achieve VPN reachability and membership functions. In the VR Ould-Brahim, et al. July 2000 [Page 3] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 model, each VR in the VPN domain is running an instance of routing protocol responsible to disseminate VPN reachability information between VRs. Therefore, VPN membership and VPN reachability are treated as separate functions, and separate mechanisms are used to implement these functions. VPN reachability is carried out by a per- VPN instance of routing, and a range of mechanisms is possible for determining membership (see section 6.0). In the piggyback model the VPN network layer is terminated at the edge of the backbone, and a backbone routing protocol (i.e. BGP-4) is responsible for disseminating the VPN membership and reachability information between provider edge routers (PE) for all the VPNs configured on the PE. [VPN-RFC2547bis] is an example of a piggyback VPN architecture. 2. Requirements This section lists some requirements addressed by the proposed architecture: (a) It should be easy to configure, deploy, operate and troubleshoot each VPN independently using existing mechanisms and tools. (b) The architecture should accommodate different levels of data and routing security. (c) The backbone internal nodes must not be VPN aware and will not keep any VPN state inside the backbone (for scalability purposes). (d) It is desirable to support the use of any routing protocol in the VPN domain and in the backbone. (e) The architecture must support overlapping VPN address spaces in separate VPNs. (f) Quality of service should be configurable per VPN. (g) The architecture should accommodate different sizes of VPNs, and one VPN should not impact other VPNs on the PE. (h) The addition of a new VPN site or the reconfiguration of an existing VPN site must not impact other VPNs. (i) The architecture should support direct paths between VPN sites that bypass the service provider backbone (backdoor links). Traffic can be directed to the backdoor link, or injected to the backbone with the flexibility of using both the backbone access, and the backdoor link as internal or external paths. (j) The architecture must work over different deployment scenarios, e.g. where the service provider owns their own backbone, and where the service provider obtains backbone service from one or more other service providers. (k) The architecture should not be limited to a single tunneling mechanism. Ould-Brahim, et al. July 2000 [Page 4] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 3. Network Reference Model A VPN customer site is connected to the provider backbone by means of a connection between a CE device, (which can either be a bridge or a router) and a virtual router. CE devices are preconfigured to connect to one (or more) VR(s). M ul tiple virtual routers coexist on the same service provider edge device (PE). CE devices can be attached to VRs over any type of access link (e.g. ATM, frame relay, ethernet, PPP or IP tunneling mechanism such as IPSec, L2TP or GRE tunnels). +---+ +---+ | P |....| P | +---+ +---+ PE / \ PE +----+ +------+ +------+ +---+ | CEs|--|-{VRs}| |{VRs}-|--|CEs| +----+ +------+ +------+ +---+ \ / +---+ +---+ | P |....| P | +---+ +---+ Figure 1: Network Reference Model CE sites can be statically connected to the provider network via dedicated circuits, or can use dial-up links. Routing tables associated with each virtual router define the site-to-site reachability for each VPN. The internal backbone provider routers (P) are not VPN aware and do not keep VPN state. 3.1 Backbone In general the backbone is a shared network infrastructure, which represents: (a) A layer-2 ATM or frame relay network. (b) An IP network. (c) An MPLS network. Not all VPNs existing on the same PE are necessarily connected to the same backbone. The same backbone can be built from multiple transport technologies. 4. Virtual Router Definition Ould-Brahim, et al. July 2000 [Page 5] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 A virtual router (VR) is an emulation of a physical router at the software and hardware levels. Virtual routers have independent IP routing and forwarding tables and they are isolated from each other. This means that a VPN's addressing space can overlap with another VPN's address space. The addresses need only be unique within a VPN domain. A virtual router has two main functions: 1. Constructing routing tables describing the paths between VPN sites using any routing technologies (e.g., static, OSPF, RIP, or BGP). 2. Forwarding packets to the next hops within the VPN domain. From the VPN user point of view, a virtual router provides the same functionality as a physical router. Separate routing, and forwarding capabilities provide each VPN CE link with the appearance of a dedicated router that guarantees isolation from other VPN traffic while running on shared forwarding and transmission resources. Virtual routers belonging to the same VPN domain must have the same Virtual Private Network Identifier (VPNID). An example of VPNID format is described in [VPN-RFC2685]. To the CE access device, the virtual router appears as a neighbor router in the CE based network, to which it sends all traffic for non-local VPN destinations. Each CE access device must learn the set of destinations reachable through its connection to the virtual router; this may be as simple as a default route. Virtual routers participating in a single VPN domain are responsible for learning and disseminating VPN reachability information among themselves. A given virtual router holds the routes only for the specific VPNs configured for that VR. Any routing protocol can be used between the VRs and the CEs. 5. How VPNs are built and deployed using VRs? Two main VR deployment scenarios can be used for building virtual private networks: . VR to VR connectivity over a layer 2 connections. . Aggregating multiple virtual routers over a single virtual router. The above VR deployment scenarios can coexist on a single PE and they are not mutually exclusive. 5.1 VR to VR Connectivity over Layer 2 Connections As illustrated in figure 2, virtual routers can be deployed over direct layer-2 frame relay or ATM connections or other layer-2 transport technology. Ould-Brahim, et al. July 2000 [Page 6] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 PE PE +---------------+ +---------------+ +-----+ | | | | +-----+ |VPN-A| | +----+ Layer-2 connections +----+ | |VPN-A| |sites|-|-|VR-A| <--------------------------->|VR-A|-|-|sites| +-----+ | +----+ | -------- | +----+ | +-----+ | |-( Layer-2)-| | +-----+ | +----+ | (Backbone) | +----+ | +-----+ |VPN-B|-|-|VR-B| | -------- | |VR-B|-|-|VPN-B| |sites| | +----+<--------------------|------->+----+ | |sites| +-----+ | | | | +-----+ +---------------+ +---------------+ Figure 2: VR to VR connectivity over a layer-2 backbone This type of VR deployment allows direct quality of service engineering per VPN connection basis. The connections can be statically configured or dynamically established. 5.2 Virtual Router Backbone Aggregation Another typical VPN configuration consists of connecting multiple virtual routers to the backbone through the use of a single virtual router (figure 3). For easy reference in the following sections let's call this single virtual router "the backbone virtual router" or "the backbone VR". The backbone virtual router is not functionally different than other virtual routers. It is only a virtual router that is configured and deployed in a special configuration. PE PE +---------------+ +---------------+ +-----+ | | | | +-----+ |VPN-A| | +----+ MPLS/IP based Tunnels +----+ | |VPN-A| |sites|-|-|VR-A|\<--------------------------->|VR-A|-|-|sites| +-----+ | +----+ +----+ | -------- | +----+/+----+ | +-----+ | |VR-1|-|-(IP/MPLS )-|-|VR-2| | +-----+ | +----+/+----+ |(Backbones )| +----+\+----+ | +-----+ |VPN-B|-|-|VR-B| | ---------- | |VR-B|-|-|VPN-B| |sites| | +----+<-------|-------------------->+----+ | |sites| +-----+ | MPLS/IP based Tunnels | +-----+ | | | | +---------------+ +---------------+ Figure 3: VR-1 and VR-2 used as backbone VRs Ould-Brahim, et al. July 2000 [Page 7] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 The backbone virtual router connects each PE to a shared backbone infrastructure. Backbone virtual routers can be deployed over ATM, FR, IP, or MPLS networks. Since the backbone VR allows the aggregation of VPN VRs, backbone configuration remains unaffected as new VPN sites are added. The relationship between the VRs and the backbone VR is an overlay relationship. No routing relationship exists between the VRs and the backbone VRs. VPN data and routing information is tunneled through the use of IP or MPLS based tunnels. Other types of tunneling are not excluded with this architecture. The tunnels can be statically configured or dynamically established. The tunnel appears to VRs as a point-to- point link. Traffic sent through the tunnel, and forwarded by the backbone VR is opaque to the underlying backbone technology used. The backbone VR makes it appear as if each VR within a VPN is directly connected (full and partial mesh configurations supported). Each VR within the VPN exchanges routing information directly with the other VRs in the VPN. The backbone VR exchanges routing information with other backbone entities (P routers and possibly other backbone VRs). Virtual routers can run any routing protocol on their local VPN domain. Both static routes and dynamic routing protocols such as RIP, OSPF, and BGP-4 can be used. VPN sites exchange routing information through the tunnels over the backbone. If a backdoor link is used between private CE based network running any IGP, then by adjusting the backdoor link costs appropriately, the backbone link can be favored for forwarding VPN traffic. By lowering the weight, the backdoor link can be used as a backup link in case the backbone path fails. 5.2.1 Relationship between the VRs and the Backbone VR The routing domain of a set of VRs participating in a single VPN has no relation to the routing domain of the backbone VR. The backbone VR is not necessarily aware of the routing instances running on each private virtual router. 5.2.2 Multiple Backbones connected to a single PE Figure 4 illustrates an example where multiple backbones are connected to the same PE. This type of configuration can be used when the PE is connected to multiple service provider backbones, or when the service provider offers different VPN services for different type of backbones. Ould-Brahim, et al. July 2000 [Page 8] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 PE PE +---------------+ +---------------+ +-----+ | | | | +-----+ |VPN-A| | +----+ | | +----+ | |VPN-A| |sites|-|-|VR-A|\ | | |VR-A|-|-|sites| +-----+ | +----+ +----+ | --------- | +----+/+----+ | +-----+ | |VR-1|-|-(Backbones)|-|VR-2| | +-----+ | +----+/+----+ | ( 1 )| +----+\+----+ | +-----+ |VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B| |sites| | +----+ | | +----+ | |sites| +-----+ | | | | +-----+ | | | | +-----+ | | | | +-----+ |VPN-C| | +----+ | | +----+ | |VPN-C| |sites|-|-|VR-C|\ | | |VR-C|-|-|sites| +-----+ | +----+ +----+ | -------- | +----+/+----+ | +-----+ | |VR-3|-|-(Backbone)-|-|VR-4| | +-----+ | +----+/+----+ | ( 2 & 3 ) | +----+\+----+ | +-----+ |VPN-D|-|-|VR-D| | -------- | |VR-D|-|-|VPN-D| |sites| | +----+ | | +----+ | |sites| +-----+ | | | | +-----+ +---------------+ +---------------+ Figure 4: Multiple Backbones connected to a single PE 6. VPN Topology and Membership Discovery The virtual router approach explicitly separates the mechanisms used for distributing reachability information from mechanisms used for achieving VPN topology determination. VPN membership information refers to the set of PEs that have customers in a particular VPN. VPN topology represents the set of PEs and their interconnectivity. The topology can be a full-mesh of PEs, a hub and spoke, or anything in between. Dynamic topology can also be handled due to on-demand VPN customers. VPN membership discovery can be achieved through different mechanisms, for example [VPN-ITU]: . Directory server approach, which VRs query a server to determine their neighbors. . Explicit configuration via a management platform. . Piggybacking VPN information using existing routing protocols (e.g., BGP) [VPN-BGP]. The above mechanisms can be combined on a single PE. As an example, for some VPNs topology discovery is done only through a management Ould-Brahim, et al. July 2000 [Page 9] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 platform. For others, dynamic topology discovery is achieved using existing routing protocol [VPN-BGP]. 7. Operations and Management One of the greatest strengths of the VR approach to VPN creation is that all the existing tools for operating, managing and debugging IP networks can continue to be used without modification. All the standard MIBs, such as the forwarding/route table and interface MIBs are available. In case of PE failure (e.g. migration, upgrades, etc.), the service provider may want to control and decide what VPN services gets reestablished first. This particular point is important when a large number of VPNs is supported on the PE where each VPN service has different service availability requirements. Since each VR operates as an independent router, it is possible for the management of the VRs to be outsourced. VPN customers may choose to configure (or perhaps only to monitor) the VRs that make up their VPN. It is also possible that the backbone VRs could be managed by a separate entity. Each VR operates independently, and can be individually reconfigured without effecting other VRs on the same PE. In some implementations, it may even be possible for a VR to be "rebooted" by a customer without effecting other VRs. 7.1 Backbone Migration One benefit in using multiple backbone virtual routers is the ability for the backbone network administrator to migrate its backbone from one core technology to another with minimal disruption to VPN services. Indeed a VPN configuration change or a VPN-software upgrade is totally transparent to the backbone protocol and policies (this is due to decoupling the VPN routing protocol from the provider backbone routing protocol). 7.2 Troubleshooting The service provider or the VPN customer can use all existing troubleshooting tools per VPN basis (e.g. ping and traceroute). As an example a VPN customer can telnet to its own VR and performs some troubleshooting operations. In this particular case, the service provider can configure for each VPN customer restricted privileges over the virtual router associated with the customer VPN network. However, backbone topology information is completely hidden to the VPN VR, and therefore to the service provider customer. Ould-Brahim, et al. July 2000 [Page 10] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 8. Quality of Service This architecture can utilize different quality of service mechanisms. QoS mechanisms developed for physical routers can be used with VRs, on a per-VR basis. e.g. classification, policing, drop policies, traffic shaping and scheduling/bandwidth reservation. The architecture allows separate quality of service engineering of the VPNs and the backbone. 9. Scalability Only the PEs are handling the VPN type information. The internal backbone routers (the P routers) are not VPN aware. Furthermore, virtual routers allow multiple privates CE based networks to connect to a single PE. One advantage of the ability to contain the VPN address space and VPN routing and forwarding capabilities within the virtual router entity is the possibility to distribute PE system resources per VPN basis. Indeed, as an example, different scheduling mechanisms can be used for processing each VPN activity within the PE. This type of per VPN resource management contributes in establishing a wide range of priority schemes among VPNs within the PE. 10. Security Considerations Different levels of data, routing and configuration security can be implemented. Any existing security related mechanisms supported by existing routing protocols (e.g. authentication) can be used unmodified in the VR architecture. If IPSec tunneling is used as the tunneling protocol, then both the control and data traffic that travels over the tunnel can be secured; so that routing specific security enhancements are not needed. Any private routing, forwarding and addressing manipulation are done within the virtual router context. Direct layer-2 connections (ATM, FR), or specific tunneling mechanisms can also provide different levels of data security. 11. References [GRE-RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [CR-LDP] Jamoussi, B., et al, "Constraint-based LSP Setup using LDP", Work in Progress. [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. Ould-Brahim, et al. July 2000 [Page 11] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC-2401] Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC2401, November 1998. [RFC-2411] Thayer, R., et al, "IP Security Document Roadmap", RFC 2411, November 1998. [RFC-2661] Townsley, W., et al, "Layer Two Tunneling Protocol L2TP", RFC2661, August 1999. [RFC-2685] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [VPN-CORE] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN Architecture", Work in Progress [VPN-BGP] Ould-Brahim, H., et al., "BGP/VPN: VPN Information Discovery for network based VPNs", work in progress, July 2000. [VPN-INW] Sumimoto, J., et al, "MPLS VPN Interworking", Work in Progress. [VPN-ITU] "Draft Recommendation Y.IPVPN", Study Group 13, Q20/13, May 2000. [VPN-RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress. [VPN-RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [VPN-RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. 12. Acknowledgments The authors would like to acknowledge the following individuals for their helpful comments and suggestions: Bilel Jamoussi, David Hudson, David Drynan, Ru Wadasinghe, Peter Ashwood-Smith, Can Aysan, Martin Pepin, Ahmad Khalid, John Luetchford, and Don Fedyk. 13. Author's Addresses Ould-Brahim, et al. July 2000 [Page 12] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 Hamid Ould-Brahim Bryan Gleeson Nortel Networks Nortel Networks P O Box 3511 Station C 2305 Mission College Blvd Ottawa, ON K1Y 4H7 Santa Clara CA 95054 Canada USA Phone: +1 (613) 765 3418 Phone: +1 (408) 565 2625 Email: hbrahim@nortelnetworks.com Email:bgleeson@shastanets.com Gregory Wright Timon Sloane Nortel Networks N.E.T P O Box 3511 Station C 6500 PASEO Padre Parkway Ottawa, ON K1Y 4H7 Fremont, CA 94555 Canada USA Phone: +1 (613) 765 7912 Phone: +1 (510) 574 2477 Email: gwright@nortelnetworks.com Email:timon_sloane@net.com Rainer Bach Rick Bubenik, T-Data SAVVIS Communications Hans-Guenther-Sohl-Strasse7 717 Office Parkway 40235, Duesseldorf St. Louis, Mo. 63141 Germany USA Phone: 49 211 694 2420 Phone: +1 (314) 468-7021 Email: Rainer.Bach@telekom.de rickb@savvis.net Abraham Young HUAWEI Technologies Co., LTD. Kefa Road Science-Based Industrial Park Nanshan District, Shenzhen 518057 China Phone: +86-755-6543662 Email: abyoung@huawei.com.cn Ould-Brahim, et al. July 2000 [Page 13] Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Ould-Brahim, et al. July 2000 [Page 14]