Internet Draft P. Lago draft-scandariato-ppvpn-info-model-00.txt R. Scandariato Expires August 2001 Politecnico di Torino February 2001 An Information Model for Provider Provisioned Virtual Private Networks 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 describes an information model representing a network architecture aimed at operating service provisioning. The network information model represents both the network topology, its resources and interconnections, and Virtual Private Networks (VPNs) on top. VPNs are considered the basic tool for providing Network Services, as well as a network feature to build added-value Application Services. Table of Contents 1 Introduction.....................................................2 2 Requirements and Background......................................2 3 Terminology......................................................4 4 Network Information Model........................................6 4.1 Notation.......................................................6 4.2 Overview.......................................................6 February 2001 [Page 1] An Information Model for PPVPNs 4.3 Area details...................................................8 4.4 Provider Network..............................................11 4.5 Virtual Private Network.......................................12 Security Considerations...........................................13 Appendix A. ELM-coded information model...........................13 Appendix B. Data Type Definition for EML..........................18 References........................................................20 Author's Addresses................................................21 1 Introduction This document describes an information model representing a network architecture aimed at operating service provisioning. This abstract model is called network information model. The network information model represents both the network topology, its resources and interconnections, and Virtual Private Networks (VPNs) on top. In this draft, the concept of VPN does not identify a mere connectivity service, but a network capability offered to third party providers by means of a network API. Service providers can exploit VPN capabilities to deploy new generation services, which benefit from the integrated security and quality of service features provided by the network. In this sense, VPNs are a sort of network environment (a middleware) to support services. The connectivity service is only the simplest form of VPN-based service. To enable network providers to plug VPN capabilities in their networks, we designed an engineered information model that gives a software representation of provider-based VPNs. The assumption is that VPN complexity should reside within the provider network, and that VPNs should be transparent to customers. The model is targeted to large-scale networks, by addressing scalability issues. Based on the network information model we designed a control architecture (not described in this document, see [1]), which should operate the VPN-based reservation of network resources. The control architecture, together with the network information model, should make up a VPN framework allowing to dynamically define VPNs at a high level of abstraction and that automates the configuration operations. 2 Requirements and Background This Section provides an overview of general requirements and starting assumptions that represent the base for the resulting network information model. February 2001 [Page 2] An Information Model for PPVPNs From the more general perspective, a set of requirements are common to any type of VPN: Security Traffic is carried out over public networks. Therefore data are exposed to possible attacks. Two are the aspects that make data secure: data cyphering and authentication of VPN members. Privacy of addressing Addresses of VPN members should be private (and virtual). Interoperability VPNs should rely on standardized technologies as the result of a large consensus. This ensures interoperability among different vendor implementations. Reliability Virtual networks should fulfill the same reliability issues as physical networks. In addition to the above common requirements, ôprovider-basedö VPNs set the following specific requirements: Scalability Network provider should be able to change network dimensions with no influence on provisioning issues. The adopted VPN model should be applicable to both small/medium size networks and large scale ones. Multi protocol support Network provider should not take any assumptions about the network technologies of potentially interconnected sites. Therefore, VPNs should guarantee support to any network protocol. To adapt the network protocol used inside customer sites to the protocol used in the provider network core, VPNs must be implemented by tunneling mechanisms. As a consequence, multi protocol support leads to a discrimination among tunneling technologies, as some of them do not support multi protocol transport (e.g. IP-in-IP). Quality of Service The network provider should ensure QoS for VPNs ôbuyedö by customers. Quality parameters are band, delay and jitter. An additional added value is the possibility for customers to define classes of traffic with various priority characteristics in the context of the same VPN. Dynamism VPNs should support both statically connected customers (e.g. through interconnected company branches), and customers that want to dynamically connect to VPNs, eventually for limited time periods. This requirement especially applies to residential and mobile users connecting via modem. February 2001 [Page 3] An Information Model for PPVPNs Programmability and Automation Due to dynamism, the number and dimension of VPNs can vary considerably in relatively short time periods. Therefore, a network provider should be able to configure/allocate resources in a programmed and (semi-) automated way. Moreover, this work considers VPNs not only as a standalone service delivered to end-users, but also as a network facility on top of which (new) VPN-based services can be implemented by service providers. However, service providers should not be annoyed with physical details that underlay the establishment of virtual connectivity. They must perceive VPNs as a high-level facility they can easily request to the network provider, and can customize according to specific service needs. In other words, virtual connectivity should be a programmable ôobjectö: the network provider exports a set of operations to create (or to gain access to) a VPN object and then the service provider can customize it by modifying the VPN properties. Multi-Provider support VPNs should possibly span over different/multiple provider networks. To negotiate this type of VPNs, common standardized interfaces between different network providers are necessary. Simplicity and Performance To produce an effective framework, simplicity and performance are essential. All requirements listed in this Section have been considered in the definition of the network information model described in the remaining of this draft. 3 Terminology Network Provider: authority that owns and/or manages a Provider Network. Provider Network: a physical network under the administrative authority of a single Network Provider. A Provider Network is made of resources such as devices (e.g. routers and switches) and links. Virtual Connectivity Provider (VCP): a Network Provider that offers Network Services to Customers. Customer: client of a Virtual Connectivity Provider. It can be both a User and a Service Provider that requests Network Services in place of Users. User: a single residential client and/or a corporate site. February 2001 [Page 4] An Information Model for PPVPNs Network Service: network facility provided by VCPs to both Service Providers and Users (e.g. Virtual Network). Application Service: facility provided by Service Providers to Users. Service: both Network Service and Application Service. Service Provider (SP): authority that offers Application Service. SPs exploit Network Services in order to provide added value application services to Users. Virtual Network (VN): Network Service provisioned by a VCP (or a federation of collaborative VCPs). Virtual Networks allow Customers to define their own abstract network on top of the physical one. VN interconnects users and it is a customizable connectivity object with regards to its security and/or QoS characteristics. Virtual Private Network(VPN): in the context of this draft the term VPN refers to virtual private routed network, i.e. a particular kind of network based VPN defined by [2]. VPNs are the network technology VCPs adopt to provide VNs. Since there is a 1:1 correspondence between VNs (service) and VPNs (underlying technology) we use the two terms interchangeably, except where misleading. Node: device within a Provider Network. Nodes are grouped in Border Nodes and Core Nodes. Area: portion of Provider Network where devices share the same forwarding and tunneling technology. Each area, however, offer an IP access at its edge. Border Node: a Node residing at area edge. Core Node: every Node that is not a Border Node. Border Router: same as Border Node (since area border is made up of IP devices) Virtual Router (VR): per-VPN dedicated process running on a Border Node Tunnel: connection between two Virtual Routers that emulates (behaves as) a point-to-point link. Customer Edge Device (CED): device interconnecting Users to provider February 2001 [Page 5] An Information Model for PPVPNs network edge (similarly to CEP in [2]). Stub: link interconnecting a CED to a Border Router. Member: a participant to a given VN/VPN. 4 Network Information Model 4.1 Notation Class diagrams presented in this section are coded in UML [3]. We adopt the following typographical conventions: o-- means "aggregation" Y-- means "derivation" <-- means "directionality" Due to typographical restrictions, classes in diagrams do not show the complete list of attributes. Further, some secondary relationships are not displayed in diagrams. However, Appendix A presents the complete network information model. In Appendix A we use ELM language to code information. ELM is a XML-based [4] modeling language, whose schema is given in Appendix B. 4.2 Overview VPRN model (described in RFC 2764 [2]) considers a provider network as a global and opaque IP cloud where only nodes on cloud border are part of VPN description. Nodes within the cloud are transparent. Users access the network via customer premises equipment (CPE), which is a corporate router connecting corporate hosts to provider edge node. Each CPE is connected to the provider network by means of one or more links (stubs). The network provider is responsible for establishing a mesh of tunnels between the provider edge nodes that have at least one attached CED belonging to a given VPN. This mesh represents a new- dedicated network that virtualizes the physical one. Conceptually, there is a dedicated mesh per each VPN and the mesh topology is arbitrary: it can be partially or full meshed, depending on customer needs. Within each provider edge node there are VPN-specific forwarding mechanisms to forward packets received from stub links (the ingress traffic) to the appropriate ônext hopö router. The term ônext hopö refers to the virtual network constituted by the per-VPN mesh, not to the physical network. Packets, in fact, are delivered by using the tunnel mesh. This draft assumes virtual routing as the VPN-specific forwarding mechanism. February 2001 [Page 6] An Information Model for PPVPNs This work overcomes the traditional VPRN model described above, in following aspects: 1) We substitute CPE with CED and extend the concept of stub link. 2) No assumptions on tunneling technology are made. 3) The provider network is depicted not so ôopaquelyö. 4) The provider network is described on two layers of abstraction. 1)Extending the VPRN model, we defined our CED entity as both a corporate router that interconnects a plurality of hosts (i.e. a site) with the Provider Network, and a single host that directly dials in the Provider Network border. Further, in [2] only dedicated links are considered as stub technology. To grant customers a flexible way of accessing the network, instead, we propose that the Stub link be a dedicated link (for instance, a leased line or a Frame Relay circuit), a dial-up link (PPP connection), or a tunnel that starts from the client desktop and terminates on the Provider Network border node. A Stub link in the form of a tunnel is useful when a user reaches his own Network Provider through an intermediary Internet Service Provider (ISP). In this case the User (typically a mobile user) can dial a local ISP to gain access to the public Internet and than he/she can reach the remote Network Provider by means of a voluntary tunnel that starts from the user desktop and ends at the Network Provider edge. 2) RFC 2764 takes into account only IP tunneling technology. Generally speaking, a tunnel is a way to isolate different kinds of traffic. Indeed, this can be implemented on two different levels: on IP networks, a tunnel is a point-to-point, encapsulated communication that acts as an overlay upon the IP backbone. On a lower level, a way to isolate traffic flows is to physically split them. ATM and Frame Relay circuits, and MPLS paths do so. This work provides support for both types of technology; the tunnel is simply required to support multi protocols and multiplexing (i.e. tunnels can carry tunnel-ID info). In case of IP networks, GRE/IPSec/L2TP tunnels can carry this kind of information; for lower level tunneling, tunnel-ID info can be associated with the VCI/VPI couple and the MPLS label. 3) The provider network cannot be depicted so opaquely as in RFC 2764. For example, if we think to the integration of QoS warranties with VPNs we cannot consider the network as an opaque cloud. QoS, in fact, must be configured along the entire tunnel path, both at entry and exit points as well as in transit points. Accordingly, in our model Core Nodes are an integral part of the VPN description. Further, we depict Provider Network as a structured network. There are three real-world cases that require a provider network be structured (i.e. fragmented into sub-networks): first, different technologies other than IP may coexist within the same provider network; second, it can be divided into sub-networks for administrative purposes (for instance, to accomplish regional or country frontiers); finally, from the management perspective February 2001 [Page 7] An Information Model for PPVPNs partitioning a large network into smaller domains leads to a more scalable paradigm. To satisfy above cases (respectively integration of technologies, administrative partitioning, and scalability) this work describes networks in terms of Provider Network and Areas. A Provider Network is made of all heterogeneous network resources (lines and networking equipment) owned by (or subject to) the same administrative authority (the Network Provider). These resources are partitioned into sub-networks called Areas. In this way, a provider domain can be viewed as a collection of connected areas. An area is a homogeneous subset of nodes with the same forwarding technology (irrespective of the ISO-layer at which forwarding takes place, be it the layer 2 or the layer 3) and the same tunneling mechanisms. Each area, however, provides IP access at its boundaries. That is, if a portion of the provider network were made up of ATM switches, it would be eligible to become an Area by simply implementing IP access at its border and by preserving ATM-level forwarding in the core. Similarly, a network segment entirely composed by IP routers could constitute another Area (by maintaining the IP-level forwarding in the core). This definition of area permits to exploit native technologies to build up tunnels (as MPLS does). For instance, an IP area can use IPSec tunnels, while an ATM area can adopt VCs in place of the conventional IP tunnels. 4) The last (and main) difference with the VPRN model is the abstraction approach we adopted. Since a VN is a virtualization of a physical network, we describe the provider network with a dual viewpoint: from the topological perspective (i.e. the physical layer) and the connectivity one (i.e. the virtual layer). Both the area entity and the provider network entity are described from this dual viewpoint. Each entity owns a finer representation of its resources called topology (which describe the physical structure of the pertaining network), while it exports an abstract view called connectivity view (which is the representation of the pertaining virtual network that overlays the physical network). 4.3 Area details As introduced before, an Area is a portion of the provider network. Area entity is represented by one Area Topology object (providing what we call the topology layer description) and one Area Connectivity View object (providing the connectivity layer description). The latter is an abstract view of the former; in fact, in Area Connectivity View core nodes and physical links are not detailed. Only tunnel interconnections are summarized. Figure 1 shows the UML class diagram formalizing the area connectivity description. February 2001 [Page 8] An Information Model for PPVPNs +---------------+ | Area Topology | +---------------+ o | +----------------------+------------------------+ | | | topologicalLink | 1..* | +--------+ +-------------+ | | | | Topological | | 2..* | |--------| Link | +----------+ +-----------+ | +-------------+ | Physical |o----------| Physical |--+ ^ 1..* | Device | 1 2..* | Interface | | +----------+ +-----------+ | Y 1 ^ 1 | | | | +--------+ | | | | | | +-------+ +--------+ | | | Core | | Border | | | | Node | | Node | | | +-------+ +--------+ | | 1..*| 1 ^ | | +-----------+ | runsOn | | | | | boundTo servedBy | | +--------+ | | | | | | | |0..* |0..* | | +----------+ +-----------+ | | | Virtual |o----------| Virtual | | | | Router | 1 0..* | Interface |--+ 0..* | | +----------+ +-----------+ | +----------+ | | 2..* | |---------| Tunnel | | | | | +----------+ | | +--------+ | 1..* | | tunnel | | | | +-------+------------------------+----------------------+ | o +-----------+ | Area | | ConnView | +-----------+ Figure 1. Area information model The Area Topology describes an area network in terms of Physical Device (PD) entities, Topological Link (TL) entities, and CED entities (see aggregation relationships from class Area Topology). February 2001 [Page 9] An Information Model for PPVPNs PD represents a device (e.g. a router), which is a traditional traffic forwarder with optional QoS capabilities. Devices are interconnected by means of topological links, which are software representations of physical connections such as a serial link, Frame Relay circuit, etc. PD is made up of one or more Physical Interface (PI) entities representing network adapters. Instances of TL association class connect two PI objects belonging to distinct devices. In more detail PD has an attribute 'position' (see Appendix A), which type is an enumeration of BORDER or CORE. Accordingly, class PD is specialized in Core Nodes and Border Nodes. Border nodes are attachment/access points for CED objects and are eligible to support one or more virtual routers (see later). Border nodes have the peculiarity to participate in both the topology and the connectivity. Area Connectivity View (for short ConnView) describes an area network in terms of Virtual Router (VR) entities, border node entities (which are potential hosts for new VRs) and Tunnel (T) entities. Hence the area connectivity view hides core details. A virtual router is a per-VPN dedicated router that maintains the VPN routing table and exploits (is realized on) the forwarding capabilities of the underlying physical device. VRs exchange routing info about Members they serve and are interconnected by means of tunnels. A virtual router is made up of Virtual Interface (VI) entities, representing tunnel end-points. Tunnel entities are point- to-point connections between two virtual interfaces and represent encapsulated and optionally encrypted connections (such as a GRE/L2TP/IPSec tunnel), or a virtual circuit (such as a ATM/FR circuit or a MPLS path). At last, additional inter-relationships between Area ConnView and Area Topology entities have been modeled by associations 'boundTo' (between VI and PI) and 'servedBy' (between T and TL). The first simply implements the correspondence between a physical adapter and tunnel end-points it serves. The second maps each tunnel to the physical path it crosses. In this way it is possible to precisely manage QoS characteristics of tunnels. Figure 2 shows inheritance associations of topological and connectivity entities. Classes Node (N), Link (L), and Interface (I) are abstract classes. They represent a generic device, a generic interconnection, and a generic interface respectively. They abstract attributes common to both topological and connectivity derived classes. In particular classes PD and VR inherit from class Node. In turn, class PD is specialized in classes CD and BN. Classes PI and VI inherit from class Interface. Finally, classes TL and T inherit from class Link. Note that Link is an association class representing an interconnection between two generic interfaces. February 2001 [Page 10] An Information Model for PPVPNs +--------+ | | +-------+ | |----------| Link | +-------+ 1 1..* +-----------+ | +-------+ | Node |o------------| Interface |--+ Y +-------+ +-----------+ | Y Y | | | | +---+---+ +---+---+ +---+---+ | | | | | | +----------+ | +-----------+ | +----------+ | | Virtual | | | Virtual | | | Virtual | | | Router | | | Interface | | | Link | | +----------+ | +-----------+ | +----------+ | | | | +----------+ +-----------+ +----------+ | Physical | | Physical | | Physical | | Device | | Interface | | Link | +----------+ +-----------+ +----------+ Y | +--------+ | | +-------+ +--------+ | Core | | Border | | Node | | Node | +-------+ +--------+ Figure 2. Inheritance trees 4.4 Provider Network Diagram in Figure 3 formalizes the overall description of provider networks. A Provider Network includes multiple Areas. The provider network owns one Provider Topology entity (topology layer description) and exports one Provider ConnView entity (connectivity layer description), which is a virtualization of the former. Provider topology is made up of all area connectivity views (and their interconnections) that reside within the provider network. Network Provider operates configuration based on this high-level network description. This simplifies configuration tasks performed by network provider. Finer configuration is delegated to single areas. This allows a high scalability in provider network dimension. Provider connectivity view virtualizes the topology by presenting the network as a single macro-area where only provider border nodes are visible. This abstract view is exported to customers (users and service providers) and federated 3rd-party network providers that want to establish multi-provider virtual networks. The Provider ConnView is a sort of common interface Network Providers exchange February 2001 [Page 11] An Information Model for PPVPNs with other VCPs and export toward SPs in order to establish business relationships. 1 +----------+ includes +------+ 1 +-----o| Provider |------------>| Area |o-----+ | | Network | 1 1..* +------+ | | +----------+ o 1 | | o 1 | | 1 | | | | 1 +----------+ | | +----------+ 1..* | Provider | | | | Area |--+ | ConnView | | | | ConnView | | +----------+ | | +----------+ | | | | | | |virtualizes | | virtualizes| | | | | | | | | 1 | 1 | | | +-----------+ +----------+ | | +------>| Provider | | Area |<------+ | | Topology | | Topology | | +-----------+ +----------+ | 1 o | | | +--------------------------------------+ Figure 3. Provider Network overall structure Class Provider Network aggregates Area entities and is made of one Provider Connectivity View (for short ConnView) entity and one Provider Topology entity. The first virtualizes the latter. In turn, class Provider Topology is made of all Area ConnView entities within the provider network. 4.5 Virtual Private Network To this point, we described concepts representing the building blocks of VPNs such as tunnels and virtual routers, and we analyzed how they fit in the network architecture. We still did not mention how a VPN is actually integrated inside the network information model. A VPN is a somewhat ôtransversalö concept. In fact it can span multiple areas and possibly overcome provider boundaries too. Nevertheless, in case of multi-provider VPNs (also called extended VPNs), each network provider is responsible only for the portion of its competence. From the provider perspective, an extended VPN can be considered as a full-contained internal VPN, whereas external portions are viewed as client members. February 2001 [Page 12] An Information Model for PPVPNs Figure 4 shows the UML class diagram formalizing the area connectivity description. +----------+ spansOn +-------+ | Area |<--------------| VPN | | ConnView | 1..* 1..* +-------+ +----------+ | vpnID | +-------+ +-------+ o | +--------------+---------------+ | | | | 2..* | 2..* | 1..* +-----------+ +----------+ +----------+ | Virtual | | Member | | Tunnel | | Router | +----------+ +----------+ +-----------+ Figure 4. VPN information model A VPN entity (identified by a globally unique identifier as stated in [5]) aggregates all the members (at least two) of virtual network, all virtual routers of the provider network through which the members are reachable, and all tunnels of the provider network that inter-connect virtual routers. Class Member is a software representation of user that maintains accounting data or user credentials. Members, tunnels, and virtual routers can belong to multiple Area ConnViews. Security Considerations Security considerations are an integral part of any VPN mechanisms, and are detailed [2]. This draft does not add further security issues. Appendix A. ELM-coded information model
R.Scandariato, P.Lago 19, Feb. 2001
February 2001 [Page 13] An Information Model for PPVPNs February 2001 [Page 14] An Information Model for PPVPNs February 2001 [Page 15] An Information Model for PPVPNs February 2001 [Page 16] An Information Model for PPVPNs February 2001 [Page 17] An Information Model for PPVPNs Appendix B. Data Type Definition for EML February 2001 [Page 18] An Information Model for PPVPNs February 2001 [Page 19] An Information Model for PPVPNs References [1] Scandariato R., Lago P., "Dynamic VPRN Provisioning: an Information Model and Architecture", Politecnico Technical Report DAI-SE-2000-06-14, June 2000. At http://www.polito.it/~patricia/MyPages/pubs.htm#vpn-draft [2] Gleeson B., et al., "A framework for IP based VPN", RFC 2764, Informational, February 2000 [3] OMG, ôUnified Modeling Language, Version 1.3ö, OMG Specification formal/2000-03-01, March 2000 February 2001 [Page 20] An Information Model for PPVPNs [4] W3C, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000 [5] Fox B., Gleeson B., "Virtual Private Networks Identifiers", RFC 2685, Standard Track, September 1999 Author's Addresses Patricia Lago Dipartimento di Automatica e Informatica Politecnico di Torino Corso Duca degli Abruzzi, 24 Torino, Italy 10129 Phone: +39-011-564-7008 Fax: +39-011-564-7099 E-mail: patricia@polito.it Riccardo Scandariato Dipartimento di Automatica e Informatica Politecnico di Torino Corso Duca degli Abruzzi, 24 Torino, Italy 10129 Phone: +39-011-564-7084 Fax: +39-011-564-7099 E-mail: riccardo@polito.it February 2001 [Page 21]