VIEWS: 9 PAGES: 6 POSTED ON: 12/18/2011
A TINA-based solution for Dynamic VPN Provisioning on heterogeneous net- works Patricia Lago, Riccardo Scandariato Politecnico di Torino Dipartimento di Automatica e Informatica Torino, Italy Abstract* software (or logical) viewpoint to represent VPNs, without any assumption on the net- The objective of this work is to support dynamic (i.e. working environment that could be both con- on demand) VPN provisioning. To this aim, this paper nection-oriented and connectionless. presents an information model describing Virtual Pri- Another useful concept is that of connection vate Networks (VPNs) at a high level of abstraction. graph that we adapted to model both the The information model is based on COPS (Common network elements, and the VPNs activated on Open Policy Service ) and TINA concepts. top of them. In particular we defined the con- The paper also proposes an architecture for dynamic cept of area to represent a homogeneous set VPN control based on the defined information model. of networking resources inside a business The proposed model is meant for a large-scale, multi- domain, and to abstract details of the network provider environment elements inside a 3rd party business domain. The area can be assimilated to the TINA net- 1. Introduction work layers in which a sub-network in a for- The work described in this paper was inspired by the eign domain is viewed as an area exporting need for VPN provisioning as an added-value service, some kind of external, “public” image. in a user-friendly and semi-automated way. We started The IETF RAP Policy Architecture (RPA), with the following premises: i.e. an architectural framework defined by the Current technologies (network elements) must IETF RAP (RSVP Admission Protocol) be configured manually, provide low-level inter- Working Group . It specifies a framework faces, and support static VPN definition. for providing policy-based control over ad- mission decisions. It is based on the concept New communication protocols are appearing of policy defined as the combination of rules (e.g. COPS but not necessarily COPS only), as imposing the criteria for resource access and well as a new generation of Network Nodes (NN) usage. that are active and stateful elements: they store This architecture is composed of two main configuration information locally (e.g. Policy In- components for policy control: (1) the PEP formation Base, PIB), and trigger notifications (Policy Enforcement Point) component run- associated with the NN state and eventually with ning on a network node, and (2) the PDP the state of the network. (Policy Decision Point) which typically re- New-generation software architectures have sides at a Policy Server. COPS is used as the been designed to support network management protocol between the PDP and the PEP for and control. Examples are exchanging policy information. The TINA Network Resource Architecture COPS can be considered as a standard and (NRA, ) supporting the general require- interoperable mechanism for VPN provision- ment of crossing different network technolo- ing, allowing for dynamic updating of the gies (e.g. IP and ATM) and different adminis- connectivity, e.g. between VPN sites. trative domains. The NRA is based on the concept of connection that we adopt from the In summary, based on current enabling technologies and protocols, we defined a high-level description of * This work has been partially supported by European Project VPNs as a collection of objects and links among ob- IRISI Piemonte (Inter–Regional Information Society Initiative). jects. This VPN description (called information model) Further, IDL (Interface Definition Language) interac- is a conceptual model and must be then mapped on a tions from Policy Administration console to PCS would new actual definition of the PIB. This step is subject to permit the administrator to monitor the status of the ongoing and future work. network. Further, we designed a Provider architecture that op- erates dynamic VPN provisioning (from creation, to modification and deletion). This is based on the defini- tion of a set of policies automating VPN provisioning, and a set of components that maintain the VPN descrip- tion and on which to apply policies. The implementa- tion of the Provider architecture is subject to ongoing work. The following gives an overview of main ideas and current status of the work. Section 2 introduces the main concepts regarding a control architecture for VPN provisioning, and the underlying network information model for VPN representation. In particular, the exam- ple given in Section 2.1 gives a sampling of the ad- vantages of this approach and the problems we are facing, and Section 2.2 details the proposed control architecture managing the example. Section 3 concludes with some considerations. Figure 1. RPA Architecture 2. Information and Computational Models for VPN Provisioning COPS and RPA consider two alternative models that we apply to VPN provisioning: the outsourcing model The RPA architecture we adopted as a starting model in which the network nodes (NNs) trigger COPS notifi- when we designed our Provider architecture, can be cations upward (see the dashed arrow in Figure 1) to the graphically represented as in Figure 1 by using a com- PDP which (through the Policy Control Server) takes putational modeling notation: NNs are either COPS- decisions according to the current status of the network, aware (PEPs), or Policy Ignorant Nodes (PINs) encap- and configures NNs downward via COPS messages. sulated in a COPS proxy. Each NN is controlled by (and The provisioning model is the other way around: the interacts with) a PDP: thus, COPS regards the interac- PDP executes configuration instructions downward to tions between PDP and PEP components. Further, we the NNs. We think of the second approach even if we do introduced a server component (that we called Policy not take any particular assumption in this respect. Control Server, PCS) in charge of maintaining the status Concerning VPN models instead, we designed our of the whole network inside a business domain, and of solution according to the VPRN model (Virtual Private reacting according to both policies and current network Routed Network ). As illustrated in Figure 2, in situation. VPRNs the Internet Service Provider (ISP) network is As shown in Figure 1, policies are stored in a Direc- treated as an opaque IP cloud where only the border tory Service (e.g. via LDAP ). We suppose that poli- nodes (elements on the cloud border) are part of the cies can be directly accessed and modified via an ad- VPRN description: they represent the access points for ministration console with no interaction with the PCS VPN customers. The core nodes (elements inside the (see in the Figure LDAP access from the Policy Admin- cloud) are transparent. Customers access the VPN via a istration console to the Directory Service). In this case, customer edge device (CED), which originally is an LTAP (Lightweight Trigger Access Protocol) would enterprise router. Extending the IETF model, we de- notify PCS of the change: before accepting the change, fined a CED as both an enterprise router that intercon- PCS triggers a verification of the new policy, by execut- nects a plurality of hosts (i.e. a site) with the ISP, or a ing both a global conflict verification, and a local veri- single host that directly dials in the ISP border. In any fication in the PDPs. If both verifications are successful, case, each CED is connected to the ISP network by PCS approves the change in the Directory Service that means of one or more links (stub links) terminating on notifies the console. an ISP border router. MPLS (Multi-protocol Label Switching) paths do Core so. Border Nodes Nodes Note that, in a VPRN context, the tunneling mecha- nism must support multiplexing, i.e. tunnels can carry ISP Net tunnel-ID info. In fact, multiple VPN tunnels may be required between the same two IP endpoints. This is often needed in case where border nodes support multi- ple customers. Traffic for different customers travels CED over separate tunnels between the same two physical Tunnel devices. A multiplexing field is needed to distinguish which packets belong to which tunnel. In case of IP Stub Links networks, GRE/IPSec/L2TP1 tunnels can carry this kind CED of information; for the lower level tunneling, tunnel-ID info can be associated with the VCI/VPI couple and the Figure 2. The VPRN Model MPLS label. This work overcomes the traditional VPRN model described above, in two main aspects: In the original VPRN model, only dedicated links are 1. The provider network is depicted not so “opaque- considered as stub link technology. To grant customers a flexible way of accessing the network, instead, we pro- ly”, being it structured in areas (introduced in pose that the stub link be a dedicated link (e.g. a leased Section 1). 2. The provider network is described on two layers line or a Frame Relay circuit), a dial-up link (PPP con- of abstraction: the Topology layer providing the nection), or a tunnel starting from the client desktop and fine-grained description of the network, and the terminating at the ISP border node. A stub link in the Connectivity layer providing a corresponding ab- form of a tunnel is useful when either a client reaches his own VPN provider through an intermediary ISP, or straction on which VPNs are mapped. the client participates in multiple VPNs. Both aspects will be explained in the following Sec- tion. A description of the complete information model is The ISP supplies VPN connectivity between mem- given in . bers of the same VPN, by establishing a mesh of tunnels between the border nodes that have at least one attached 2.1. Provider Network Modeling CED belonging to that VPN. Each border node is able to forward the traffic received from an attached VPN There are three real-world cases that require a pro- member to the appropriate destination, within the same vider network be structured in sub-networks: first, dif- VPN, by using the tunnel mesh. In this way, the ISP ferent technologies other than IP may coexist within the sustains the burden of installing the tunnels and of man- same provider network; second, it can be divided into aging the routing mechanisms only. In this sense, the sub-networks for administrative purposes (for instance, VPN service is said network-centric. to accomplish to regional or country frontiers); finally, Generally speaking, a tunnel is a way to isolate dif- partitioning a large network into smaller domains leads ferent kinds of traffic. This can be implemented on two to a more scalable paradigm from the management different levels: perspective. On IP networks, a tunnel is a point-to-point, en- To satisfy the former cases (respectively integration capsulated communication that acts as an overlay of technologies, administrative partitioning, and scala- upon the IP backbone. In fact only the border bility) our work describes networks in terms of Provider nodes are acquainted with tunnels while the tun- Domains and Areas. nel traffic is opaque for the IP network core. IP A provider domain is made of all heterogeneous core nodes are unaware that a tunnel is traversing network resources (lines and networking equipment) them: tunnel packets are forwarded just as any owned by (or subject to) the same administrative au- other IP packet (this fact explains why core nodes thority (the ISP). These resources are partitioned into are not involved in the pure VPRN description, sub-networks called areas. An area is a homogeneous which considers only IP networks and IP tun- subset of ISP network nodes with the same forwarding nels). On a lower level, a way to isolate traffic flows is 1 Acronyms stand for: to physically split them. ATM/FR circuits, and GRE - Generic Routing Encapsulation IPSec - Internet Protocol Security L2TP - Layer Two Tunneling Protocol technology (irrespective of the ISO-layer at which the with the border nodes (elements on the cloud border) forwarding takes place, be it the layer 2 or the layer 3). enabled for the IP protocol. The right side area is sup- Each area network, however, provides an IP access level posed to be an IP native network. at its boundaries. Figure 3.(b) shows the instantiated information mod- The following figure presents (a) a pictorial descrip- el for a fragment of our example, namely the part ex- tion of a provider network and (b) its formalization as a ploding the Provider Domain PD1 into Area A1 (on the UML2 object diagram. right side of the Figure). In particular, the elements making up the information Provider ConnView model are the following. Core nodes are formalized as PC1 Network Node (NN - white) class instances, while bor- CED2 der devices are formalized as either Edges (E – dark CED1 gray) or Gateways (G – light gray). More precisely, a Area Provider Tunnel ConnView border node is a particular kind of Network Node ex- Topology PT1 Switch AC1 porting one of the following interfaces: the ii_Gateway TS1 interface, when the border node is the connect point G2 G1 E2 between two areas, or the ii_Edge interface, when the ATM IP Area border node is the access point for a CED. Area Area Topology AT1 Further, different areas are interconnected through NN2 Tunnel Switch class instances (see the middle plane of TL1 NN1 the pictorial representation and the related light-gray elements in the object diagram). As shown in the Figure (a) Graphical representation 3.(b), in general a Tunnel Switch is composed of two gateways and a Link (L) – also called trunk – connect- PD1: Provider Domain ing the corresponding network interfaces. In particular, PC1: Provider ConnView virtualizes the tunnel switch of our example (TS1) is implemented A1: Area PT1: Provider Topology by a unique border node providing two gateway inter- faces (G1 and G2) toward the two associated areas. CED1: CED TS1: Tunnel Switch virtualizes Therefore, the link is a fictitious connector that associ- AC1: Area ConnView ates two interfaces (I1 and I2) of the same border node. AT1: Area Topology Figure 3.(b) also shows the virtualization relation- G2: ii_Gateway L1: Link G1: ii_Gateway T1: Tunnel E2: ii_Edge ship between the connectivity and the topology view. NN1: Network Node NN2: Network Node The Provider ConnView (PC1) is the most abstract I2: Interface I1: Interface TL1: Topological Link representation of the Provider Domain, by presenting it TEP1: Tunnel End Point TEP2: Tunnel End Point as a single macro-area (to the foreign federated provid- ers too). PC1 virtualizes the Provider Topology PT1 (the NI1: Network Interface NI2: Network Interface (b) Information model light gray middle plane and the light gray objects in Figure 3), which maintains the fine-grained view of the provider domain: it is composed of Tunnel Switch ob- Figure 3. A provider network example jects that interconnect the areas, CED objects, and Area ConnView objects. In our example, the Area ConnView First, let us have a look to the graphical representa- AC1 (the dark gray cloud in the middle plane and the tion, which shows the relationships among a provider related dark gray objects in the diagram) presents the IP domain, its organization in areas, and the customers. area as an opaque cloud of border nodes only (gateways Starting from the upper layer, the example shows that and edges) connected by a mesh of Tunnels. Each tun- Customers access the VPN service through a Customer nel is marked with the identifier of the VPN it belongs Edge Device (CED), which can be both a host (CED2) to, and connects two Tunnel End Points (TEPs). The that directly dials in the provider domain, or an enter- latter represent the virtual interfaces, in a border device, prise router (CED1) that interconnects a site. The pro- that terminate a tunnel. At last, AC1 virtualizes the Area vider domain is split in two Areas (the white clouds in Topology AT1 (white in Figure 3), which maintains the the lowest plane), supposing that the left side area is finest-grained view of the IP area. It schematizes the built on ATM core nodes (inner elements in the cloud) area nodes as a set of NN objects (irrespective of their core or border position). Each NN is made of Network Interface (NI) objects representing those network cards 2 Based on OMG Unified Modeling Language. that are connected to the area. The TL1 Topological AC2 respectively). This component provides two Link object represents the physical interconnection interfaces: between two network nodes. ii_aConfiguration should permit the configura- tion of single area elements to establish tun- 2.2. The VPN Control Architecture nels (e.g. configure a gateway to cross-connect In Section 2 we sketched out the RPA architecture two areas). we just adopted as a pattern. Inspired by that architec- ii_aConnection should permit the configura- ture, we mapped our information model on an original tion of edges and gateways to attach CEDs or computational model that together make up an RPA-like activate trunks. architectural solution. Here we describe the main com- Component Area Topology manages the network ponents of our control architecture we propose to man- resources that are part of an area, organized ac- age VPN provisioning. Also, we give a brief description cording to the topology representation of the area of the exported interfaces that are to be considered only itself. It offers the following interface: indicative. ii_aManagement should implement topology Figure 4 shows the architectural components needed construction, i.e. to add, remove and inter- to manage the example given in the previous Section. In connect network nodes. detail, Figure 4.(a) reports the graphical representation (a) Graphical representation of the example, whereas Figure 4.(b) shows the associ- Provider ated components. Starting from the highest layer, the ConnView architecture is made of the following components: PC1 Component Provider ConnView manages the CED2 Provider Connectivity View (in our example cor- CED1 responding to PC1). It provides two external in- Provider Area ConnView AC2 Area ConnView terfaces (all indicated with prefix ii_): Topology PT1 AC1 ii_pFederation should permit external VPN Providers to establish 3rd Party relationships, and customers to join existing VPNs. We are ATM IP Area Area Area Topology considering two dual cases: external customers Area AT1 joining a Provider VPN, and a customer join- Topology ing an external VPN. AT2 ii_netMonitoring should permit an administra- tor to monitor the status of the network, e.g. the network workload, current VPNs, etc. Component Provider Topology manages the Pro- vider Topology View (in our example corre- sponding to PT1). It provides two interfaces: ii_vpnFactory should manage VPNs by creat- ing a VPN controller unit for each VPN. Con- trollers permit to manipulate the characteris- tics of a VPN, like VPN parties, topology or QoS details. ii_pManagement should manipulate the net- work in terms of both the resources owned by the provider, and the view offered by 3rd party providers. This means that this interface’ oper- ations can create and connect areas, and con- nect customer devices to the network (e.g. the CEDs in the Figure). Component Area ConnView manages the refine- Figure 4. The control architecture ment of the provider topology into areas repre- sented at the connectivity level: there will be one Further, components Provider ConnView and Pro- component instance for each network area (e.g. in vider Topology together make up the Policy Control our example two components manage AC1 and Server (shown in Figure 4) that can be implemented as a unique component. Similarly, area-related components make up the PDP component, one for each area. 3. Conclusions and further work In this paper we propose an innovative architecture for VPN provisioning based on a software representa- tion of a Provider network. The latter is rather stable, whereas the control architecture is still in its initial specification. In particular, we rely on the RPA architecture speci- fication, and on TINA concepts, like the separation between access session and service/communication sessions, thanks to which in our case, VPN resource allocation is carried out only after both VPN negotiation and conflict detection are completed. Nonetheless, we did not yet design either the exact interfaces we need, or the number of components that best operate resource allocation. E.g., performance analysis could possibly influence architecture design. In summary, it is important to note how a hierar- chical description for VPNs, together with a flexible and modern control architecture, permits the develop- ment of new value-added services with slight effort. Facilities such as QoS-based VPNs, and pay-per-use VPNs, jointly with the ease of deployment, can grant a competitive benefit from the Provider perspective. 4. References [ Boyle J., et al., “The COPS (Common Open Policy Service) Protocol”, IETF RFC 2748, Pro- posed Standard, Jan. 2000, at http://www.ietf.org.  Gai S., et al., “QoS Policy Framework Architec- ture”, IETF Internet Draft, Feb. 1999., draft-sgai- policy-framework-00.txt.  Scandariato R., Lago P., “Dynamic VPRN Provi- sioning: an Information Model and Architecture”, Politecnico Technical Report DAI-SE-2000-06- 14, Jun. 2000, at http://www.polito.it/~patricia/MyPages/pubs.htm #vpn-draft.  Steegmans F., et al., “Network Resource Archi- tecture 3.0”, TINA-C Baseline, NRA_v3.0_97_02_10, Feb. 1997, at http://www.tinac.com/specifications/specification s.htm.  Yavatkar R., et al., “A Framework for Policy- based Admission Control”, IETF RFC 2753, In- formational, Jan. 2000.  Yeong W., et al., “Lightweight Directory Access Protocol”, RFC 1777 - Internet Engineering Task Force, Mar. 1995.