Internet Draft Internet Engineering Task Force Karthik Muthukrishnan INTERNET-DRAFT Andrew Malis Expires April 5, 1999 Ascend Communications <draft-muthukrishnan-corevpn-arch-00.txt> October 5 1998 Core IP VPN Architecture 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), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 2. Acronyms LSP Label Switched Path PNA Private Network Administrator SP Service Provider SPED Service Provider Edge Device SPNA SP Network Administrator VMA VPN Multicast Address VPNID VPN Identifier VR Virtual Router VRC Virtual Router Console 3. Abstract This draft presents an approach for building core VPN services in the service provider backbone, as described in [Heinanen]. This approach does not depend on MPLS running in the backbone but will benefit from it. The central vision is for the service provider to provide a virtual router service to their customers. Ease of configuration, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications are the keystones of this architecture. Muthukrishnan, Malis Expires March, 1999 [Page 1] INTERNET-DRAFT Core VPNs October 2, 1998 4. Introduction This draft describes how VPN services in the backbone of the SP's network could be built. The predominant emphasis is on providing a virtual router service and every effort has been made to make the virtual router as equivalent to a physical router as possible. The aspects of a router that a virtual router needs to emulate are configuration of any combination of routing protocols, monitoring of the network and troubleshooting. Providing a logically independent routing domain to every VPN enhances the SP's ability to offer a fully flexible virtual router service that can fully serve the SP's customer without requiring physical per-VPN routers. The approach presented here meets most of the requirements set forth in [Heinanen] but differs significantly in that we have strived to not require or depend on any modifications of any existing routing protocols. Neighbor discovery is aided by the use of an emulated LAN and is achieved by the use of ARP. This draft has made a concerted effort to draw the line between the SP and the PNA: layer 1 and layer 2 services belong and are managed by the SP while layer 3 services belong to and are managed by the PNA. By the provisioning of fully logically independent routing domains the PNA has been given the flexibility to use private and unregistered addresses. Data security is not an issue given the use of private LSPs and the use of VPNID encapsulation when forwarding on shared LSPs. The approach espoused in this draft differs from that described in [Jamieson] in the following ways: No routing protocol is modified or used to aid in the neighbor discovery mechanism. No VPN subnet from the SP's address space is required to be allocated. No PNL to PNL direct peering is used. It is not required for the CPE gear to be also MPLS compliant, thus allowing existing enterprise routers to not have to be upgraded. 5. Objectives 1. Easy, scalable configuration of VPN endpoints in the service provider network. 2. No use of globally unique SP IP resources such as IP subnets. 3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. 4. Virtual Routers fully configured and monitored by network administrator of the VPN. Muthukrishnan, Malis Expires March, 1999 [Page 2] INTERNET-DRAFT Core VPNs October 2, 1998 5. Forwarding quality fully configurable; at the lowest end best effort internet LSP. 6. Differentiated services on a VPN by VPN basis based on private LSPs. 7. Security of internet routers extended to Virtual Routers. 8. Specific routing protocols not mandated between Virtual Routers. 9. No special extensions to existing routing protocols such as BGP, RIP, OSPF, ISIS etc. 6. Requirements The service provider network must run some form of multicast routing to all nodes that will have VPN connections and to nodes that have to forward Virtual Router discovery multicast datagrams. 7. Architectural Outline 1. Every VPN is assigned a 16 bit VPNID which is unique within the SP's network. The choice of 16 bits for VPNID (rather than 32 bits) allows 65k VPNs to be built in a SP's network and simultaneously keeps this ID small enough to be transmitted in encapsulation headers. 2. The VPN service is offered in the form of a Virtual Router service. These VRs reside in the SPED and are as such confined to the edge of the SP's cloud. The VRs will use the SP's network for data and control packet forwarding but are otherwise invisible outside the SPEDs. 3. The "size" of the VR contracted to the VPN in a given SPED is the quantity of IP resources such as routing interfaces, route filters, routing entries etc. This is entirely under the control of the SP and provides the fine granularity required to empower the SP to offer virtually infinite grades of VR service on a per- SPED level. [Example: one SPED may be the aggregating point (say headquarters of the corporation) for a given VPN and a number of other SPEDs may be access points (branch offices). In this case, the SPED connected to the headquarters may be contracted to provide a large VR while the SPEDs connected to the branch offices may house small, perhaps stub VRs]. 4. One of the indicators of the size of the VPN is the number of Muthukrishnan, Malis Expires March, 1999 [Page 3] INTERNET-DRAFT Core VPNs October 2, 1998 SPEDs in the SP’s network that have connections to CPE routers. As globally unique IP resources do not have to be dedicated/assigned to VPNs, the number of SPEDs is not limited by any artificial configuration limits. 5. Layer 1 and Layer 2 entities belong to and are managed by the SP. To be specific, physical switches/routers, physical links, logical layer 2 connections (such as DLCI in Frame Relay and VPI/VCI in ATM) and LSPs (and their assignment to specific VPNs) are under the control of the SP. In the context of VPNs, it is the SP's responsibility to contract and assign layer 2 entities to specific VPNs. 6. Layer 3 entities belong to and are managed by the PNA. Examples of these entities include IP interfaces, choice of dynamic routing protocols or static routes, and routing interfaces. This provides a virtual routing domain to the PNA and empowers the PNA to design the network to achieve intranet, extranet and traffic engineering goals. 7. The PNA can manage and monitor the VPN using the methods that would have been used if physical routers rather than VRs were used. Therefore, management may be performed using SNMP or other similar methods or directly at the console, the VR console (VRC). Monitoring and troubleshooting may be performed using SNMP or similar, but may also include the use of standard tools such as ping, traceroute etc. Again, the VRC may be used for these purposes just like any physical router. 8. The VRs in the SPEDs form the VPN in the SP's network. Together, they represent a virtual routing domain. They dynamically discover each other by utilizing an emulated LAN resident in the SP's network. Each VPN in the SP's network is assigned a multicast address. Subscription to this multicast address allows a VR to discover and be discovered by other VRs. 9. Data forwarding may be done in one of several ways: hop-by-hop using some form of tunneling SPED-to-SPED, a public LSP with best-effort characteristics or a traffic engineered private LSP with differentiated characteristics. The choice of which LSP is configurable by the SP. The default is the public LSP with best- effort characteristics. The hop-by-hop mechanism is available to route packets during periods of LSP establishment and failure. 8. Scalable Configuration A VPN is expected to have 100s to 1000s of endpoints within the SP cloud. Configuration should therefore scale at most linearly with Muthukrishnan, Malis Expires March, 1999 [Page 4] INTERNET-DRAFT Core VPNs October 2, 1998 the number of end points. Anything worse will make this task too daunting for the service provider. To this end, all that the service provider needs to allocate/assign are physical/logical links from the private network to the service provider edge device. 9. Dynamic Neighbor Discovery The VRs in a given VPN reside in a number of SPEDs in the network. The problem is that these VRs need to be connected together. One way to do this is to require the configuration of tunnels between these VRs in a fully meshed fashion. This is obviously not scalable from a configuration and network resource standpoint. Hence the need arises to allow these VRs to dynamically discover each other. Neighbor discovery is facilitated as follows: each VPN is given a limited emulated LAN. This emulated LAN is used in several ways: 1. Address resolution uses this LAN to resolve next-hop (private) IP addresses associated with the other VRs. 2. Routing protocols such as RIP and OSPF use this limited emulated LAN for neighbor discovery and to send routing updates. The per-VPN LAN is emulated using an IP multicast address. In the interest of conserving public address space and because this multicast address needs to be visible only in the SP network space, we would use an address from the Organizationally scoped multicast addresses (239.192/14) as described in [Meyer]. Each VPN is allocated an address from this range. To completely eliminate configuration in this regard, this address could be computed given the VPNID. 10. Virtual Router Configuration Muthukrishnan, Malis Expires March, 1999 [Page 5] INTERNET-DRAFT Core VPNs October 2, 1998 172.150/18 172.150.128/18 ----------------------- ---------------------------| | | | | | 172.150.128.1 | | Parts DB | --------------- | | OSPF | | OSPF | ------------| VR - A |-------------- |-------------| ) ( RIP RIP ) ( ) ( |--------------| -----------------| | | | | | VR - B | | VR - C | |--------------- |----------------- | | Extranet ------------------------- | 172.150.64/18 V Vendors Figure 1 Each Virtual Router is configurable by the PNA as though it were a private physical router. The resources that this Virtual Router may consume is of course limited by the bounds set by the SP on a SPED by SPED basis. Each VPN has a number of physical connections (to CPE routers) and a number of logical connections (to the emulated LAN). Each of these connections is IP capable and can be configured to utilize any combination of the standard routing protocols and routing policies to achieve specific corporate network goals. To illustrate, in Figure 1, there are 3 VRs on 3 SPEDs. VR-C and VR-B have a physical connection each to CPE equipment while VR-A has 2 physical connections. Each of the VRs has a fully IP capable logical connection to the emulated LAN. VR-A has the (physical) connections to the headquarters of the company and runs OSPF over those connections. It can therefore route packets to 172.150/18 and 172.150.128/18. VR-B runs RIP in the branch office(over the physical connection) and uses RIP (over the logical connection) to export 172.150.64/18 to VR-A. VR-A advertises a default route to VR-B over the logical connection. VR-C is the extranet connection for vendors to use to connect to the parts database at 172.150.128.1. Hence VR-C advertises a default route to VR-A over the logical connection. VR-A exports only 175.150.128.1 to VR-C. This keeps the rest of the corporate network from being subjected to a security problem. The network administrator will configure the following: Muthukrishnan, Malis Expires March, 1999 [Page 6] INTERNET-DRAFT Core VPNs October 2, 1998 1. OSPF connections to the 172.150/18 and 172.150.128/18 network in VR-A. 2. RIP connections to VR-B and VR-C on VR-A. 3. Route policies on VR-A to advertise only the default route to VR- B. 4. Route policies on VR-A to advertise only 172.159.128.1 to VR-C. 5. RIP on VR-B to VR-A. 6. RIP on VR-C to advertise a default route to VR-A. 11. Forwarding As mentioned in the architectural outline, data forwarding may be done in one of four ways. The actual method in all but the first outlined here is configurable. At the high end the private LSP is preferred for data forwarding and at the other end hop-by-hop forwarding is used. The order of forwarding preference is therefore: optionally configured private LSP, best effort public LSP and lastly, hop-by-hop. 11.1 Private LSP This LSP is optionally configured on a per-VPN basis. This LSP is usually associated with non-zero bandwidth reservation and/or a specific differentiated service or QOS class. If this LSP is available it is used for user data and for VPN private control data forwarding. 11.2 Best Effort Public LSP VPN data packets are forwarded using this LSP if a private LSP with specified bandwidth and/or QOS characteristics is either not configured or not presently available. The LSP that is used is that destined for the egress router in VPN 0. The VPNID in the shim header is used to de-multiplex data packets from various VPNs at the egress router. 11.3 Hop-by-hop This method of forwarding is used when no LSP is currently available to carry the traffic. This could happen when the LSP is going through a down transient. To confine the VPN routing tables to the edges of the SP network, the VPNID and the egress SPED's ID need to carried Muthukrishnan, Malis Expires March, 1999 [Page 7] INTERNET-DRAFT Core VPNs October 2, 1998 all the way. An approach is to tunnel the packet to the egress SPED with the IP protocol set to IPVPN (protocol number to be allocated by IANA) and with a label pushed to represent the VPNID [TBD]. 12. Differentiated Services The configuration of private LSPs for VPNs allows the SP to offer differentiated services to paying customers. These private LSPs could be associated with any available QOS class. Multiple private LSPs with different QOS classes could be configured in a VPN with flow profiles used to sort the packets among the LSPs. This feature together with the ability to size the virtual routers allows the SP to offer truly differentiated services to the VPN customer. 13. Virtual Router Security Considerations 13.1 Data Security This allows the SP to assure the VPN customer that data packets in one VPN never has the opportunity wander into another. From a routing standpoint, this is achieved by maintaining separate instances of routing protocols and routing tables for each virtual router. From a data forwarding standpoint, the use of VPN encapsulation headers (in the case of shared LSPs or hop-by-hop forwarding) or the use of private LSPs guarantees data privacy. 13.2 Configuration Security Virtual routers appear as real routers to the PNA. This means that they may be configured by the PNA to achieve connectivity between offices of a corporation. Obviously, the SP has to guarantee that the PNA and the PNA's designees are the only ones to have access to the VRs on the SPEDs the private network has connections to. Since the virtual router console is functionally equivalent to a physical router, all of the authentication methods available on a physical console such as password, RADIUS, etc. are available to the PNA. By allowing only authenticated PNAs to access the VR console, the SP guarantees that the VPN is in full control of its destiny. 14. Physical Network Security When a PNA logs in to a SPED to configure or monitor the VPN, the PNA is logged into the VR for the VPN. The PNA has layer 3 configuration and monitoring privileges for the VR. Specifically the PNA has no configuration privileges for the physical network. This provides the guarantee to the SP that a VPN administrator will not be able to inadvertently or otherwise adversely affect the SP's network. Muthukrishnan, Malis Expires March, 1999 [Page 8] INTERNET-DRAFT Core VPNs October 2, 1998 15. Virtual Router Monitoring All of the router monitoring features available on a physical router is available on the virtual router. This includes utilities such as "ping" and "traceroute". In addition, the ability to display private routing tables, link state databases, etc. are available. 16. Acknowledgements Thanks to Sridhar Komandur and Peter Fetterolf of Ascend Communications for their helpful review and feedback. 17. References [Callon] Callon R., et al, "A framework for Multiprotocol Label Switching, draft-ietf-mpls-framework-02.txt". [Rosen] Rosen E., et al, "Multiprotocol Label Switching Architecture", draft-ietf-mpls-arch-02.txt. [Heinanen] Heinanen J., et al, "MPLS Mappings of generic VPN mechanisms", draft-heinanen-generic-vpn-mpls-00.txt. [Jamieson] Jamieson D., et al, "MPLS VPN Architecture", draft- jamieson-mpls-vpn-00.txt. [Meyer] Meyer D., "Administratively Scoped IP Multicast". RFC 2365. 18. Authors' addresses Karthik Muthukrishnan Ascend Communications 1 Robbins Road Phone: (978) 952-1368 Westford, MA 01886 Email: karthikm@ascend.com Andrew Malis Ascend Communications 1 Robbins Road Westford, MA 01886 Phone: (978)-952-7414 Email: malis@ascend.com Muthukrishnan, Malis Expires March, 1999 [Page 9]