Network Working Group Robert May Internet Draft IP Infusion Inc. Expiration Date: December 2003 June 2003 Extensions to OSPF Version 2 to support a Generalized Virtual Router Architecture draft-may-ppvpn-vr-ospf-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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.'' 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 provides a generalized Virtual Router (VR) architecture and specifies the required extensions for [OSPFv2] to adapt the protocol to this architecture, such that separate "instances" of OSPF can be used for different Service Provider (SP) customers connected to different PE to CE links of a single PE box. This architecture accommodates the deployment of layer 3 IP VPNs to facilitate services such as Intranet connectivity, and allows the R. May [Expires December 2003] [Page 1] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 consolidation of multiple Service Provider (SP) customers onto a single Provider Edge (PE) device, while enforcing all necessary security between different customer data. 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 [ii]. Table of Contents 1 Introduction .......................................... 2 2 Virtual Routing ....................................... 3 2.1 Definition ............................................ 3 2.2 Requirements .......................................... 3 2.3 Interface Requirements................................. 4 2.4 TCP/IP Stack Requirements ............................. 4 2.5 Scalability Concerns .................................. 5 3 Routing Protocols ..................................... 5 3.1 OSPF on the PE to CE Link ............................. 5 3.1.1 OSPF Multiple-Instances ............................... 6 3.1.2 TCP/IP Stack Issues ................................... 6 3.1.3 Enforcing Interface Restrictions ...................... 6 3.1.4 Redistribute Information .............................. 6 3.1.5 Overlapping Address Spaces ............................ 6 3.2 Service Provider Network .............................. 7 4 Virtual Private Networks .............................. 7 5 System Administration ................................. 7 5.1 System Users .......................................... 7 5.2 OSPF Administration ................................... 8 6 Alternative Architecture .............................. 8 6.1 Scalability Comparison ................................ 8 6.2 Process / Task Starvation ............................. 9 7 Security Considerations ............................... 9 7 References ............................................ 9 8 Acknowledgements ...................................... 9 9 Authors' Addresses .................................... 9 1. Introduction This document provides a generalized Virtual Router (VR) architecture and specifies the required extensions for [OSPFv2] to adapt the protocol to this architecture, such that separate "instances" of OSPF can be used for separate customers connected to different PE to CE links of a single PE box. One popular service offered by SPs today is a VPN service where the provider installs, deploys and maintains VPN technology and then offers the service to customers. Traditionally, each end-user was responsible for this deployment, but economies of scale dictate that SPs can operate much more efficiently and significantly reduce R. May [Expires December 2003] [Page 2] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 the up-front (deployment) and on-going (maintenance/upgrade) costs to the customer. While the generalized VR architecture described in this draft is most popular for VPN services, it can also be applied to any other service that requires strict security between different customer data. Without VR, these services require separate hardware and software for each customer. Also note, that while this draft focuses on [OSPFv2], these same techniques can be applied to other routing protocols to run between the PE to CE link, such as IBGP, IS-IS, RIP (IPv4 and IPv6). 2. Virtual Routing (VR) A common source of inefficiency for the SP in deploying services such as IP VPN over an IP backbone, is the requirement for separate hardware and software (per customer) installed at the provider premises. This is required to enforce security between different customer networks to ensure that customers cannot access each other's data. Virtual Routing can be applied to this scenario to consolidate multiple customers per-PE device and enforce the necessary security. This significantly reduces up-front and on-going costs to the SP, which can be passed onto customers. 2.1 Definition A generalized VR architecture consists of multiple instances or contexts of all software, operating independently for different VR contexts. Data may be shared within a VR, but communication between VRs is not considered in this draft. To all other devices in the attached networks, a virtual router will appear exactly as a physical router. This promotes seamless integration and imposes no requirements on the network or attached devices. From [VRVPN], we recognize that a VR "...has exactly the same mechanisms as a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance." 2.2 Requirements Under this generalized VR architecture, a single VR has the following requirements: - A VR MUST be independent from any other VR. - A VR MUST include a separate instance or context of all software. The software MUST enforce security so that the instances/contexts do NOT access each others' data. R. May [Expires December 2003] [Page 3] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 - A VR MUST NOT access system resources, such as interfaces, that are not assigned to their VR context. - A VR MUST have the capability to be independently managed. A VR MUST NOT provide access to other VR contexts and MUST NOT provide access to system resources that are not assigned to their VR. The system employing the generalized VR architecture (PE router), has the following requirements: - The system MUST have the capability to create and delete different VR contexts and assign any parameters for the VR. - The system MUST have the capability to assign/bind system resources, such as interfaces, to different VR contexts. - The system TCP/IP stack MUST support the virtual router architecture and enforce appropriate security between contexts. 2.3 Interface Requirements The Virtual Router concept requires that interfaces can be bound to different VR contexts. More precisely: - An interface MUST be assigned to one and only one VR context, or global. - A VR context MAY be assigned to zero or more interfaces. - Logical interfaces SHOULD also support the same capability. This MAY include IP VPN (tunnel) endpoints. 2.4 TCP/IP Stack Requirements It is necessary to identify the extended requirements of the system TCP/IP stack that are employed by the generalized VR architecture. Some commercial TCP/IP stacks currently support these requirements: - The stack MAY provide a mechanism for creating and destroying VR contexts within the stack itself. Or, the stack MAY create and destroy VR contexts implicitly as needed. - The stack MUST provide a mechanism to allow applications to specify the VR context when installing or deleting routing table entries. When informing applications of routing table entries, the stack MUST specify the VR context. - The stack MUST provide a mechanism to allow applications to assign interfaces and other system resources to different VR contexts. R. May [Expires December 2003] [Page 4] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 - All TCP/IP stack APIs that apply MUST provide a mechanism for specifying the VR context. Examples are send/receive packet APIs. - When sending, the TCP/IP stack MUST resolve the destination using the correct context. - When receiving, the stack MUST enforce that the application VR context matches the context for which the packet was received (ex: ingress interface VR context matches application socket VR context). - During forwarding, the system MUST enforce that the ingress interface VR context matches the egress interface VR context (unless special policies are employed). - The stack SHOULD be extended to support overlapping address spaces across VR contexts. This MAY include the extension of stack applications, including ARP, ICMP, etc. 2.5 Scalability Concerns The generalized VR architecture imposes no requirements or restrictions on the connected customer or service provider networks, or their attached devices. Therefore, network scalability concerns are independent of this VR architecture. Scalability of the VR architecture itself is a big concern, however, especially as the number of Virtual Routers begins to grow. An alternative VR implementation and scalability comparison is provided at the end of this draft. 3. Routing Protocols The extensions to [OSPFv2] to support the generalized VR architecture are defined below. They can be adapted to any routing protocol that can run between the Provider Edge and Customer Edge devices to exchange routing information. 3.1 OSPF on the PE to CE Link [OSPFv2] is the most popular protocol to run between the PE and CE devices. One advantage is that customers only need to have expertise in IGP protocols and don't require BGP experts in-house. The [OSPFv2] protocol can be extended to support the generalized VR architecture such that separate contexts of OSPF are executed for different customers and all data is kept separate. Separate instances can be individually managed and the customer need not be aware they have a virtual router or a physical router. R. May [Expires December 2003] [Page 5] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 The following extensions can be added to the [OSPFv2] protocol to support this architecture: 3.1.1 OSPF Multiple-Instances - OSPF MUST support "multiple instances" of the protocol, where each instance's data is kept separately from all others'. Currently, this support is available on many commercial implementations of [OSPFv2] using 'router ospf <1-65535>' to configure the separate instances. - Standard OSPF "multiple instances" works such that all instances are bound to a single (global) Routing and/or Forwarding Information Base (RIB/FIB). This MUST be extended so that instances are bound to different VR contexts. 3.1.2 TCP/IP Stack Issues - Each OSPF instance MUST be extended so that it passes the VR identifier to any TCP/IP stack APIs that have been extended to support VR. Example APIs would be sockets, system calls, &c. 3.1.3 Enforcing Interface Restrictions - Each OSPF instance MUST NOT run on interfaces that are not bound to their VR context. - If an interface is removed from a VR context, OSPF MUST remove any attached networks and stop running on the interface. 3.1.4 Redistribute Information - Each OSPF instance MUST be extended to communicate only to other applications that are bound to their VR context. OSPF MUST be extended to support the redistribution of routes on a per-VR, or per-context basis. 3.1.5 Overlapping Address Spaces - Each OSPF instance MUST be extended to support overlapping address spaces such that networks connected to separate VRs/contexts MAY overlap. 3.2 Service Provider Network The generalized VR architecture makes no assumptions about the service provider's network, though it is most applicable for IP. The routing protocols belonging to any specific VR may run on any interface assigned to their VR context. This includes physical and logical interfaces, some of which may connect to (or traverse) the SP backbone. R. May [Expires December 2003] [Page 6] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 4. Virtual Private Networks The establishment of Virtual Private Networks is considered beyond the scope of this draft. The VPN endpoints SHOULD appear to the OSPF protocol as logical interfaces that can be assigned to different VR contexts. The VPN will then be available for running OSPF, static or other routing protocols over the connection to facilitate route exchange with remote sites on a per-VR basis. The advantage of this mechanism is that it does not require any special VPN capability on the PE box or within the SP network. The disadvantage of this mechanism is that separate VPNs must be established for each customer, even if many VPNs have the same destination PE box on the other side. [VRVPN] provides a sophisticated way to layer customer VRs over a special Service Provider VR (SPVR) to automate VPN establishment throughout the network, however, such capability is beyond the scope of this draft. 5. System Administration It is useful to identify the system administration extensions for the generalized Virtual Router architecture, though only a subset of these extensions will apply to [OSPFv2]. Others apply to the system / PE router at the global or box level. 5.1 System Users The generalized VR architecture recognizes two different types of users of the system: - The entire system MUST support some form of global administration, which enables authenticated users to configure global parameters for the device. This includes creating / deleting VRs, assigning interfaces and other system resources, setting any global VR information, such as user authentication lists. - The second mode is VR configuration, which MUST be identical to configuration of a physical router without VR employed. This MUST be provided as transparent to the administrator, thus enabling existing tools to be reused for configuration, operation, accounting, and maintenance. 5.2 OSPF Administration Existing implementations of [OSPFv2] MAY be extended to support a level of global configuration. This is not required if all global administration will be handled by a separate process, but SHOULD be provided to allow greater flexibility in the future. R. May [Expires December 2003] [Page 7] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 Existing implementations of [OSPFv2] MUST be extended to support VR configuration mode. When users log into OSPF (either via CLI, SNMP, web, or other interface), they MUST connect to a specific virtual router context. This MAY be determined implicitly by the VR context binding of the interface connecting the administrator to the management application. 6. Alternative Architectures As the number of Virtual Routers on a single device grows, scalability becomes a great concern. It may not be uncommon for SPs to consolidate 100 or more customers onto a single PE router, which must be able to handle the load. The VR architecture and changes to [OSPFv2] described in this draft define a multiple- context approach, where each context is bound to a VR. This architecture is also extended into the TCP/IP stack. An alternative to multiple-context is to use an 'actual' multiple- instances approach, where separate processes/tasks are started for OSPF for each VR. The advantage of such an approach is that few changes are required to [OSPFv2]. There are several disadvantages, however, that impose severe scalability and process/task starvation concerns. 6.1 Scalability Comparison The alternative architecture imposes the following scalability and process starvation concerns: - If each VR contains M protocols and there are N VRs defined in the system, then there will be (M * N) processes/tasks. which can soon become unmanageable. Furthermore, performance will be impacted by unnecessary context switching. - Dynamic process/task creation is generally a costly operation and may involve some level of IPC. Each new process/task will need to register with the operating system, TCP/IP stack, and any other applications, which can impact performance. - Interface assignment can be a costly operation using this model because each time an interface is assigned to/from a VR, the system will inform all other listening processes/tasks. If each of these tasks must add/remove an entry from a list, then this becomes a factor as the number of VRs increases. - Running multiple processes/tasks for each VR implies that a central management process/task will be used to coordinate the system, which can add even more IPC to the system as the number of VRs increases. R. May [Expires December 2003] [Page 8] Internet-Draft draft-may-ppvpn-vr-ospf-00.txt June 2003 6.2 Process / Task Starvation - The alternative architecture imposes a process/task starvation concern, which allows one VR to hog system resources: First, consider that each separate OSPF instance would have the same scheduling priority. Second, consider that several OSPF packets arrive in the following order from the network(s): O1-vr1 O1-vr2 O2-vr1 O3-vr1 O2-vr2 O3-vr2 O4-vr1 where (On-vrx = OSPF packet #n for VR #x). After O1-vr1 arrives, the OSFP process/task will begin to process this packet. Assume that the rest of the packets arrive during this time. Using the architecture defined in this draft, the OSPF packet will be processed in the order received (fair). Using the alternative architecture, VR #1 will process all of its packets, then VR #2 (unfair). Note that none of the concerns listed in sections 6.1 and 6.2 apply to the generalized VR architecture defined in this draft. 7. Security Considerations Security issues are not discussed in this memo. 8. Acknowledgements 9. Reference [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [VRVPN] Ould-Brahim, H., et al., "Network based IP VPN Architecture using Virtual Routers", , July 2002. 10. Author's Address Robert May IP Infusion Inc. 111 W. St. John Street, Suite 910 San Jose CA 95113 e-mail: robert@ipinfusion.com R. May [Expires December 2003] [Page 9]