Loading ...
Interesti...
Internet Services
SaaS and Web Services
37
0
Try Now
Log In
Pricing
An Introduction to Virtual Private Networks: Towards D-VPNs Luís Henrique M. K. Costa1,2 — Serge Fdida1 — Otto Carlos M. B. Duarte2 1 LIP6 – Université Pierre et Marie Curie 4, place Jussieu 75252 Paris Cedex 05 - France {Luis.Costa, Serge.Fdida}@lip6.fr 2 Grupo de Teleinformática e Automação – GTA Universidade Federal do Rio de Janeiro – COPPE/EE P.O. Box 68504 - 21945-970 - Rio de Janeiro - RJ - Brasil otto@gta.ufrj.br ABSTRACT. Virtual Private Networks (VPN) have many different implementations being deployed and numerous definitions are consequently found in the literature. Nevertheless, the VPN con- cept has two important characteristics: the ability to construct different “virtual” networks sharing the same physical infrastructure and to provide closed group communication. Starting from these basic properties, this paper first makes a survey of the main VPN technologies to afterwards extend the VPN concept giving the key ideas of the Dynamic VPNs (D-VPN). To define this new concept we analyze the similarities between the multicast/group communication model and the VPN concept, showing that attaching some properties, such as Quality of Service guarantees, to a multicast group is conceptually the same as providing these guarantees inside a VPN. RÉSUMÉ. Les Réseaux Privés Virtuels (Virtual Private Networks - VPN) ont de nombreuses im- plémentations en déploiement et par conséquent la littérature en présente des différentes défini- tions. Néanmoins, les VPNs ont deux caractéristiques spécialement importantes : l’habilité de construire des différents réseaux “virtuels” qui partagent la même infrastructure physique et de permettre la communication de groupe contrôlée. Avec ces propriétés comme point de départ, nous présentons un panorama des principaux technologies des VPN pour ensuite proposer une extension naturelle de son concept, les VPN Dynamiques (Dynamic VPN - D-VPN). Pour bâtir ce nouveau concept nous analysons les similarités trouvées entre les modèles de communica- tion de groupe/multicast et le VPN. Nous montrons qu’associer certaines propriétés, comme des garanties de Qualité de Service, à un groupe multicast revient conceptuellement à la même approche utilisée lorsque ces garanties sont ajoutées à un VPN. KEYWORDS: virtual private networks, group communication, multicast, quality of service MOTS-CLÉS : réseaux privés virtuels, communication de groupe, multicast, qualité de service Network and Information Systems Journal. Volume 2 - nÆ 6/2000 2 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 1. Introduction Virtual Private Network (VPN) is an evolving technology which is currently the subject of several academic and commercial projects. VPNs are mainly used for closed group communication within a controlled and secure network environment, without needing to construct a private network. Thus a major argument for the deployment of VPNs is the economical advantages in relation to dedicated networks. Unfortunately, multiple definitions of a Virtual Private Network proliferate in the market place. It is difficult to give a closed definition of a VPN. Nevertheless, we find that a quite general and complete definition is provided in [FER 98]: “A VPN is a communications environment in which access is controlled to al- low peer connections only within a defined community of interest, and is constructed through some form of partitioning of a common underlying communications medium, where this underlying communications medium provides services to the network on a non-exclusive basis”. A simpler definition is also presented: “A VPN is a private network constructed within a public network infrastructure, such as the global Internet”. We believe that the simplest definition of a VPN derives from the main concept of VPNs, the ability to provide closed group communication. Other VPN characteris- tics can be derived from the properties associated to that communication, such as the security level and Quality of Service (QoS) guarantees. In this paper we present the VPN motivations, implementations, and emerging solutions to address QoS and secu- rity. We introduce the envelope concept which is found at the crossroads of multicast communication and VPN. 1.1. VPN motivations Maybe the strongest motivation of VPNs relies in the economics of communica- tions. A collection of virtual networks implemented on top of a common physical communications infrastructure is cheaper than the construction of the equivalent col- lection of discrete networks, each for a single client. Another interest of VPNs is, of course, the ability to turn some parts of an organi- zation’s network virtually invisible to external observers. This aspect of communica- tions privacy can play an important role for organizations. Depending on the level of security demanded by the organization, the simple abstraction of discretion and net- work obscurity of a VPN may suffice. However, for higher levels of user security a corresponding requirement for strong security of access and data transmission within the network is required, and additional mechanisms should be implemented. Towards D-VPNs 3 The VPN abstraction is also interesting in providing closed group communication. VPNs can also be thought as a support of the same functionality of multicast com- munication, but within a controlled and secure environment. One may also think of the use of multicast communication within a VPN, which looks like a two-level group communication. The applicability of VPNs in this area is promising. Another important motivation of VPNs is the intrinsic ability to partition network resources. By means of resource partitioning, it is possible to provide some kind of QoS guarantees to applications. Network resources may be reserved, or provided, in a per-VPN basis. Network resources may include buffers in routers, bandwidth on links, etc., and even address space might be thought as a shared resource (depending on how VPNs are implemented, address spaces can overlap). 1.2. VPN requirements From the definition and motivations of VPNs, one can enumerate several require- ments for VPN construction [GLE 00]. Any VPN has a minimal set of capabilities and may have optional features according to the requirements of the user. The main point is that for a VPN to work, it must be possible to map the user services to corresponding capabilities in the network infrastructure. To define a VPN, an administrative mechanism is needed for designating mem- bership in the VPN. A host may belong to one or more VPNs, as well as the global Internet. The ability to dynamically change the host membership is desirable. The addition of new hosts to the VPN (e.g., a dial user) should be signaled to the provider in the case of an enterprise VPN. In general this should be done transparently to the VPN members. Nevertheless, the VPN may be informed of user additions and dele- tions because of security or group management issues. The set of members of a VPN may be identified, [FOX 99] proposes one approach. Regarding security, different capabilities may be required from the VPN depend- ing on the user service. The minimal ability asked from a VPN is to guarantee some kind of isolation between the virtual network and the exterior world, as derived from the definition of a VPN. Depending on the level of security required, user connectiv- ity may be defined including a variety of security mechanisms as IPSec [KEN 98]. Security may be requested discretely by end-user hosts or the VPN may enforce a mandatory security policy. The VPN may provide QoS support. This can be done in two different ways: users may signal its QoS requirements with RSVP [BRA 97] (or other signaling method), IP precedence bits or what ever, or the VPN may internally assign QoS requirements to be mapped to the transmission infrastructure. For QoS to be guaranteed, the infras- tructure may explicitly support QoS requests, or it may be projected in such a way that it consistently provides adequate QoS (with a certain level of confidence). 4 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 An enterprise may demand a specific level of availability from the service provider for the VPN service. This can also be understood as a QoS requirement and may be achieved by redundant links that are visible to, or hidden from, the user enterprise. Other optional capabilities may also be defined, relative to addressing, load shar- ing, frame sequencing, MTU support, etc. [GLE 00]. 1.3. Administrative model There are two basic models of administration and management of VPNs. In the first category, the end user organization designs and operates the VPN, for example with end-user access through the public dial network. In the second model, a ser- vice provider has contractual responsibility for designing and operating the VPN in response to specified user requirements. Nevertheless, VPNs are not limited to these two models. Since the concept of VPN is tied to private communication but also to resource reservation and partitioning, one can imagine constructing VPNs within a single organization network, to ensure a certain QoS or data security to a group of users [GLE 00]. This work presents an overview of the VPN research area. Section 2 briefly re- views the main technologies of constructing VPNs. Section 3 discusses the QoS issues in VPN implementations. Section 4 presents the main VPN research projects. Section 6 presents some final remarks. 2. VPN Implementations There are several kinds of VPN. Depending on their functional requirements, there may be also multiple methods of constructing VPNs. The selection of a specific VPN implementation includes issues like the security level needed, scalability relative to growing the VPN, as well as the complexity of implementing and maintaining the VPN (how automated is VPN creation, and how dynamic is the structure of the VPN?). We can divide the several VPN types according to the layer in the TCP/IP protocol stack where the VPN is implemented. We can have network-layer, link-layer and transport/application-layer VPNs [FER 98]. The VPN types can also be divided into “peer” and “overlay” VPNs, according to the implementation model. In the peer model, the network layer path computation is done on a hop-by-hop basis. Each node in the data forwarding path is a peer node with the next-hop node. Traditional routed networks are examples of the peer model. Al- ternatively, in the overlay model the network layer forwarding is not done hop-by-hop, but via “cut-throughs” in the link-layer, communicating an entry node “directly” with an edge node on the other side of a large cloud. ATM and Frame Relay implementa- tions are examples of the overlay model. In many cases this model can provide better Towards D-VPNs 5 performance, but scaling issues arise when a huge number of edge nodes is connected in a mesh. We briefly describe in the following sections the characteristics of the main VPN types, beginning by network-layer VPNs (route filtering and tunneling) followed by link-layer VPNs. 2.1. Route filtering Route filtering, or “controlled route leaking”, consists of controlling route prop- agation in such a way that only certain networks receive routes for other networks which are within their own community of interest. This is a peer model, since a router within a VPN site establishes relationship with a router in the VPN provider’s network, instead of edge-to-edge communication with other sites in the VPN. While the common underlying Internet generally carries the routes for all networks connected to it, this architecture assumes that only a subset of such networks form a VPN. Given the lack of explicit knowledge of reachability to locations other than the VPN members, privacy of services is directly achieved by the inability of VPN members to respond to messages originating from outside the VPN. Route-filtering VPNs are conceptually simple, but present some problems and are sometimes considered as a primitive VPN construction method. The use of partial routing information is very subtle to misconfiguration problems. It supposes a com- mon routing core, which imposes problems to VPN addressing, since the different VPN address spaces can not overlap. There is, however, a more scalable and less suitable to human misconfiguration approach to route filtering, the use of BGP Communities [CHA 96]. The use of the BGP communities attribute allows a VPN provider to mark BGP NLRIs (Network Layer Reachability Information) with a community attribute. Configuration control allows route information to be propagated in accordance with a community profile. 2.2. Tunneling Sending specific parts of the network traffic through a tunnel is another method of constructing VPNs. The most common mechanisms are GRE (General Route En- capsulation) [HAN 94], L2TP (Layer Two Tunneling Protocol) [TOW 99] and PPTP (Point-to-Point Tunneling Protocol) [HAM 99]. DVMRP [WAI 88] tunnels can also be used: the MBone may be viewed as a kind of worldwide VPN. Tunneling is an overlay model, thus scaling issues arise and are dependent on the utilization of point-to-point or point-to-multipoint tunnels and how these tunnels are used to construct the VPN. 6 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 2.2.1. GRE tunnels GRE tunnels [HAN 94] are generally configured between an ingress and an egress router in the network. The packets forwarded through the tunnel are encapsulated with a GRE header and placed in the tunnel with the address of the tunnel endpoint as destination. In the endpoint the GRE header is popped and the packet continue to be forwarded in the original IP fashion. GRE tunnels are generally point-to-point but there are some vendor implementations that support point-to-multipoint configu- rations. The architectural concept of tunneling is to build a VPN as a collection of tunnels across a common host network. Each tunnel connects the point of attachment to this common network to remote points from the same VPN. Routing in a specific VPN is isolated from routing in the common network. The several VPNs within the common host network may use the same address space without problems of overlapping. The tunnel can also encapsulate different protocol families. Nevertheless, there are problems with GRE tunnels regarding the administrative overhead and scaling to large number of tunnels, since GRE tunnels must be manually configured. A complete mesh of tunnels with a large number of peering adjacencies can result in a negative effect on routing efficiency. 2.2.2. Virtual Private Dial Networks There are several technologies, proprietary mechanisms as well as standard-based mechanisms, that are able to construct Virtual Private Dial Networks (VPDN). Never- theless, there are two technologies that seem to grow in popularity: L2TP [TOW 99] and PPTP [HAM 99] tunnels. L2TP is in fact a mechanism originated from the com- bination of the earlier L2F protocol specification and the PPTP protocol [FER 98]. L2TP has a “compulsory” tunneling model, or NAS-initiated tunnel (Network Ac- cess Server or dial access server). It means that when a user dials to a NAS, this server creates a tunnel to a predetermined endpoint in the network, possibly based on a local configuration profile. PPTP has a “voluntary” tunneling model, or client-initiated. It permits clients to configure and establish point-to-point tunnels to arbitrary located PPTP servers, without the participation of the NAS. The tunnel may terminate in any PPTP server in the network, given that this server is reachable through classical routing. In fact, PPTP and L2TP have many similarities, the main difference between them residing in the tunneling model adopted. This tunneling model may be the decision factor when choosing one of the two technologies according to the needs of the ap- plication. The main issue is whether the network provider has the control of the PPP session to be established or not. Towards D-VPNs 7 2.3. ATM and Frame Relay VPNs To construct a conventional private data network, dedicated circuits from a public carrier are combined with additional private communications infrastructure. In gen- eral the large communications (public) infrastructure uses some kind of time-division and/or frequency-division multiplexing to create a dedicated circuit, where there is synchronization of the data clock of the sender and receiver. This clocking rate is fixed by the capacity of the dedicated circuit. A link-layer VPN tries to provide the same functionality of these conventional private data networks, while achieving economics of scale by the use of a common switched public network infrastructure. A collection of VPNs share the same infras- tructure. In general these networks operate at Layer 3 or higher, while the infrastruc- ture is represented by Frame Relay or ATM. The main difference from conventional private data networks is that there is no synchronized data clock between the sender and the receiver, nor is there a dedicated transmission path. In general, the sender has no knowledge of the available capacity of the virtual circuit, so sender and receiver may use adaptive clocking of data. The sender can adapt its transmission rate accord- ing to the requirements of the application and signaling received from the network and the receiver. A public switched WAN (ATM or Frame Relay-based) is very flexible. The client is unaware whether the provider is actually able to guarantee the contracted service at all times under all possible conditions. It is a task of the service provider the provi- sion of sufficient network resources and the admission control of connections in the network to guarantee a certain QoS level. On the other hand, the client is able to trans- mit data at a rate higher than the contracted. The excess information units (cells) are marked (as DE - Discard Eligible in Frame Relay or by setting the CLP (Cell Loss Priority) bit in ATM). In times of congestion, these marked cells are firstly discarded. The service provider may project the network to provide a specific QoS level to the VPNs carried. There are scaling issues with ATM and Frame Relay VPNs, related to the config- uration and provisioning of new virtual circuits. A complete mesh of virtual circuits between all pair of endpoints may not scale, while on the other hand a partial mesh can lead to suboptimal routing. These scaling issues are common to the overlay model. 2.3.1. Multi-Protocol Over ATM VPN implementation through the use of MPOA (Multi-Protocol Over ATM) [HEI 93] is similar to other “cut-through” methods. The idea is to use a switched link-layer to enable all “Layer-3 nodes” to be a single hop away from one another. In this model, edge routers determine the path in the ATM network since they know which egress router packets must be forwarded to. Therefore packets are forwarded on a Virtual Connection (VC) specific to an egress router. Nevertheless, since egress 8 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 routers cannot use ARP on the ATM cloud, an IP to ATM address resolution server is needed. One advantage of MPOA is the use of dynamic circuits, while some other VPN im- plementations rely on statically configured structures. MPOA may be used to control the creation of edge-to-edge VCs dynamically. There are nevertheless two problems with this model. The first is the dependence on the ATM technology which poses problems with hybrid networks. Second, there are scaling issues as with other “cut- through” (and overlay) models, for example, routing sub-optimality when there is no full-mesh connectivity. 2.4. Multi-Protocol Label Switching Most of the network architectures can be divided into two models: the use of network-layer routing and per-packet switching or the use of link-layer circuits and per-flow switching. MPLS (Multi-Protocol Label Switching) [ROS 00b] is an hybrid architecture that mixes these two approaches. MPLS VPNs [MUT 00] address the scaling issues presented by other models by using a single routing environment with VPN labels, as packet labels are necessary to activate per-VPN routing tables. MPLS makes the Layer 2 switching environment visible to routing by adding Layer 3 (IP routing) functionality to switches. MPLS is intended to support a va- riety of link-layer technologies and heterogeneous Layer 2 switching environments. MPLS uses a label swapping forwarding structure. Packets entering the MPLS cloud are assigned a label based on local forwarding decision. Packets are then switched in the MPLS cloud by checking the incoming label that determines the next hop and pro- duces the outgoing label, in a local label-indexed table. These tables are constructed by the use of the IP routing protocol in conjunction with a Label Distribution Protocol [AND 00]. This lightweight encapsulation based on the use of labels together with the notion of boundary-determined transit paths provides some of the mechanisms needed to support VPNs. MPLS VPNs are formed by the constrained distribution of routing information (a way to form VPNs and control connectivity between them), the use of VPN Identifiers (that concatenated with IP addresses provides unique addresses) and the use of MPLS to forward packets along the constructed routes [MUT 00]. In [ROS 00a], a method for implementing MPLS VPNs is proposed. In this ap- proach BGP distributes routing information. The MPLS cloud (or backbone) is viewed as a set of P and PE routers (service Provider and service Provider Edge routers). PE routers are connected to CE devices (Customer Edge devices - often a switch or router). CE devices connect the MPLS backbone to the site network. Each PE router maintains a forwarding routing table per site; packets are forwarded only to sites that have at least one VPN in common with the originating site. It is desirable that the address spaces of (non-intersecting) different VPNs can overlap, thus the rout- ing protocol has to distribute multiple routes to the same destination (address prefix in Towards D-VPNs 9 the case of BGP). MBGP (Multiprotocol extensions to BGP) [BAT 98] allows BGP to carry routes from multiple address families. A new address family, named VPN-IPv4, is defined to carry per-VPN routes. Figure 1 gives an overview of the BGP/MPLS VPN framework. SP 1 SP 2 Site 5 Site 4 Site 3 Site 2 Site 1 Static, RIP, OSPF or EBGP EBGP Site 6 IBGP IGP IBGP PE - Provicer Edge Router SP - Service Provider P - Provider Router ASBR - Autonomus System Border Router CE - Customer Edge Router VPN-IPv4 routes IPv4 routes MPLS MPLS Internet PE1 PE2 PE3 CE3 CE2 CE1 CE4 ASBR ASBR PE4 CE5 P P P P P P P P P P PE5 CE6 Figure 1. BGP/MPLS VPN architecture. Scalability issues are taken into account by the architecture. P routers do not store any VPN routes, by means of a two-level labeling scheme in MPLS [ROS 00a]. PE routers maintain one routing table per site and store routes just for VPNs that are present in the sites directly connected to it. In Figure 1, router PE1 stores only one routing table for Site 1 while router PE2 stores two routing tables, one associated with the Site 2 the other for Site 3. Routing table for Site 1 stores routes just for sites which have VPNs in common with Site 1. In this way the communication between two sites that have no VPN in common is prevented and on the other hand VPNs that have no site in common may have overlapping address spaces. Each PE routing table is marked with the associated VPN (or VPNs), and the PE router distributes these routes only for other PE and ASBR (Autonomous System Border Routers) routers that have sites within common VPNs connected to it. Thus VPN-IPv4 routes are exchanged just between PE routers, they are not propagated to the customer sites neither to the Internet backbone. BGP route reflectors, if used, can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs supported by the service provider. The same applies to ASBRs, present in the case where VPNs span more than one service provider. No component has to store routes for all VPNs, improving scalability. 10 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 2.5. Virtual Local Area Networks Virtual Local Area Networks (VLAN) [VAR 97] are a particular VPN type. VLANs were proposed as an alternative approach to the use of routers to contain broadcast traffic. The VLAN technology was recently standardized by the IEEE (standard IEEE 802.1q). A LAN is considered a broadcast domain whereas a LAN segment is a collision domain. LAN segments are connected through bridges or switches, elements that do not forward collisions (as opposite to hubs and repeaters). LANs are connected through routers, elements that do not propagate broadcasts. VLANs allow a network manager to logically segment a LAN into different broadcast domains without routers. Bridging software defines which workstations belong to the broadcast domain and routers are only used to communicate between two VLANs. VLANs are constructed by means of explicit tagging or implicit tagging. In ex- plicit tagging a VLAN identifier is added to the data (in [VAR 97], tag headers for Ethernet, Token Ring and FDDI are presented). In implicit tagging the data is not marked, instead the VLAN from which the data came is identified based on informa- tion like the port on which the data arrived. This approach is less flexible, especially relating to host mobility. Membership may be defined by the port (e.g. of a bridge), by MAC address, protocol type, IP subnet address, or even by the application type. Any combination of these methods supposes that the bridges have a coherent database with the VLAN membership. The main arguments for the deployment of VLANs relate to performance gains especially when the network traffic consists of a high percentage of broadcasts and multicasts. There is also an economical argument for VLANs: using bridges instead of routers to implement broadcast domains is likely to be a cheaper approach. 2.6. Transport and Application Layer VPNs Although there is no theoretical impeachment to the deployment of transport and application-layer VPNs, this is not very common. The most common implementation method is to use encryption services at either layer. For example, encrypted e-mail transactions and authenticated DNS (Domain Name System) are cited in [FER 98]. The Transport Layer Security protocol (TLS) [DIE 99] is worth mentioning. The main idea of TLS is to provide privacy and data integrity between two communicat- ing applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The TLS Record Protocol lays on top of some re- liable transport protocol (e.g., TCP). The TLS Record Protocol provides private and reliable connections. Symmetric cryptography is used for data encryption. The TLS Record Protocol is used for encapsulation of various higher level protocols. One such Towards D-VPNs 11 encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the data transmission. 3. QoS Provision in VPNs The definition of a VPN as a “private network” leads directly to performance issues, in other words, how one can associate some QoS characteristics to a spe- cific VPN. There is a lot of work in progress that address the VPN QoS require- ments [DUF 98, SYS , LIM , DEL 97]. A QoS framework for IP-based VPNs is presented in [DUF 98]. Hereafter we review its main concepts. As VPNs are supposed to replace networks constructed with private lines, the same kind of service offered by these networks would be expected from VPNs. Therefore, in addition to closed group communication and secure data transmission, VPNs have to offer some performance guarantees in terms of delay and bandwidth for example. Two connectivity models are introduced. The first is the Virtual Private Link, where the VPN is constructed from a set of point-to-point virtual links. The tunneling techniques presented earlier fit into this model. The second is the Virtually Routed Network. Customer routers connect to provider routers and traffic isolation between VPNs is achieved by some kind of encapsulation within the provider network. Tech- niques like MPLS VPNs fit into this model. A performance oriented service description is defined by means of two service abstractions. In the first one, a customer asks the service provider a pipe between two VPN sites with certain QoS requirements. To construct a VPN, a customer has to know the traffic matrix of the network and to ask for the pipes between every pair of sites in the network. The “hose” performance abstraction is introduced [DUF 98]. The idea is to reduce the information that the customer has to pass to the provider. In this abstraction, a VPN endpoint informs the “outgoing” and “incoming” maximum data rates that this site is expected to send and receive from all other VPN endpoints (optionally a set of them). A hose may be viewed as a pipe where one endpoint is known and the other endpoint may be any other hose in the VPN. The customer does not have to provide a complete traffic matrix nor the spread of this traffic to other endpoints in the VPN. Figure 2 illustrates the hose model. The user site only informs its outgoing and incoming data rates, and the set of hose endpoints. The contract specifies that x + y + z = 5Mb=s, but it does not specify the values of x, y and z, as would be the case if the pipe model was used. In the hose model supposes the connectivity between all endpoints (or a specified set). The hose abstraction gives the customer freedom to send traffic between every pair of endpoints provided that the traffic in and out of the endpoints does not exceed 12 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 Orig Dest 1 Dest 2 Dest 3 Network a b c y x z a+b+c=10Mb/s x+y+z=5Mb/s 5 Mb/s 10 Mb/s Figure 2. An example of the hose model. the agreed capacities. In these conditions the service provider is expected to meet cer- tain Service Level Agreements (SLA), such as bounded delay and packet loss. There- fore the problem is to the service provider to guarantee these SLAs under all possible conditions, all the time. The Virtually Routed Network model might fit better to this abstraction than the Virtual Private Link model. QoS support Regarding QoS provision there are several possibilities. One may define a single set of QoS requirements for the VPN. The VPN construction reflects these require- ments, possibly with bandwidth reservation by the service provider. However we may also think of different QoS levels within the same VPN. There are at least two ways to achieve this more general model: – Model A - To manage the resources on a VPN-specific basis. Resources for different flows, with different QoS requirements, are allocated from the resources re- served to the specific VPN. Here there are two possibilities: 1. to do scheduling only at the edges, with different scheduling services for dif- ferent QoS flows (it is possibly done by the customer), or 2. to mark packets at the network entry, in this case the network serves differently different packet types. In any case resources are managed and reserved for a specific VPN. – Model B - To manage resources on a QoS-basis, across all VPNs. The traffic specification is thus made for each of the QoS classes (a VPN with three classes of QoS has to provide three traffic specifications). The network treats differently each of the classes for a specific VPN, or in other words, the network manages the traffic across all tuples (QoS class, VPNs). In this technique, each origin of the VPN has a set of hoses with different QoS characteristics. Towards D-VPNs 13 3.1. Implementing QoS 3.1.1. Integrated Services The Integrated Services (IntServ) [BRA 94] framework is one of the possibilities to implement QoS within a VPN. Either the Guaranteed Service or the Controlled Load Service can be used to support the VPN resource management. In the IntServ framework, there is a signaling protocol (Resource reSerVation Protocol - RSVP) [BRA 97] that is used to make reservations between two endpoints. In the hose model, the dynamic reservation mechanism provided by RSVP can be used to implement reservations between any two endpoints in a dynamic fashion. It remains to the service provider to guarantee the SLAs given that the hose specification is respected. The capacity negotiated for the hose plays a role when there are several pipes reserved for a customer. One incompatibility between the hose model and the IntServ framework is that in the first the reservation is made for a pipe, that is, for all traffic between a pair of nodes; in IntServ the reservation is made on a per-flow basis. A pipe can potentially carry several flows of the same VPN. A resource aggregation might be used in this case. 3.1.2. Differentiated Services In the Differentiated Services (DiffServ) [BLA 98] model scheduling decisions at routers are based in the DS byte of the IP header. The values of DS define different per-hop behaviors (PHB). These DiffServ PHBs may be used with additional signaling and/or provisioning to support QoS in VPNs. When a customer constructs a VPN, it passes to the network a set of endpoints to be connected along with the traffic characteristics and QoS profile of the specific hose/pipe. The network has to check if there are available resources to meet the QoS requirements of this hose/pipe. In the case of a pipe, resources have to be available across a path between two endpoints. In the case of a hose, it is necessary to make such a check between all VPN access points. In this case one should assume a particular traffic matrix. Defining such a traffic matrix is a problem of the service provider, considering the dynamic characteristic of a hose. The bandwidth check may be made by a bandwidth broker (aware of the network topology) or by a hop-by-hop signaling mechanism, that in this case is used only for admission control. This approach differs from the IntServ model: there is no creation of packet classifiers or scheduling state at intermediate routers. If resources are managed in a VPN-basis with scheduling made by the customer (model A - option 1), the QoS required from the network to a specific VPN would have to be the more stringent QoS requirement of that VPN. Model A option 2 would be difficult to implement since the DiffServ routers do not know how to distinguish traffic from different VPNs by default. 14 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 Model B, where resources are partitioned on a per-QoS basis, can be implemented by marking packets at the access point based on its traffic class. The admission control would be made in a per-class basis. The construction of the resource-management models proposed in [DUF 98] must be better studied since one may imagine many variations of them. 3.1.3. MPLS MPLS seems to be a technology well suited to support QoS in VPNs, especially considering the hose abstraction and a virtual routed connectivity. A full mesh can be realized in MPLS by means of a sink tree (in fact, a Label Switched Path (LSP) tree) to each hose endpoint from all other endpoints. The performance model can be realized by dynamically changing the resources allocated to each LSP tree. Using a sink tree makes it easy to the provider to check if the committed resources for a hose are respected, since the reservation requests flowing towards the exit point will be merged and only succeed if the total falls in the range reserved at the hose exit. Another possibility is to use the IntServ model at the customer network. In this case the RSVP requests from the customer site are merged and translated to reserva- tion requests in the MPLS network, in a way similar to the pure IntServ realization. The traffic management and service categories that MPLS will support are still in discussion [ROS 00b]. 4. VPN Projects There are some projects currently in progress that treat the problem of VPN QoS provisioning. We make a brief review of the most important ones. Cisco Systems proposes a QoS-VPN architecture [SYS ] that is based on the fea- tures of a proprietary QoS-provision product. The proposal includes packet classifi- cation (using a committed access rate), bandwidth management (including policing, shaping and bandwidth allocation), congestion avoidance and continuity of packet pri- ority over Layers 2 and 3 by means of MPLS. Packet classification is made (by now) using the ToS (Type of Service) field of the IP header and packets can be marked following different criteria such as IP addresses, TCP/UDP port numbers, etc.. Band- width allocation is achieved by WFQ, in one of two ways, class-based or flow-based. Congestion avoidance is implemented by WRED. These components are combined to provide specific QoS guarantees. A VPN-specific signaling facility is absent. Other projects are also concerned with VPN construction by the user. These projects try to automate the VPN generation and some of them address QoS issues. It is the case of VNS (Quality of Service Virtual Network Service) [LIM ]. VNS proposes an architecture where users are provided an application that enables the construction of virtual networks. VNS is responsible for partitioning the network resources (bandwidth, router buffers, etc.) and allocating them to individual virtual Towards D-VPNs 15 networks. Routers are able to identify flows and virtual networks. A packet schedul- ing algorithm (HFSC - Hierarchical Fair Service Curve) at routers is responsible for delivering link sharing and supporting real-time service. The link layer is supposed to be ATM, and each virtual-link of the network is associated with a virtual circuit. In this way the bandwidth of virtual links can be specified. The Supranet concept is introduced in [DEL 97]. The approach employed to pro- vide QoS is to construct VPNs on top of a Integrated Services network. A Supranet is a network-layer VPN constructed by means of tunneling. The proposed architec- ture has a double-stack layered structure, with one stack for real-time services and the other for non real-time ones. There are also other projects that are mainly concerned with automating the cre- ation of virtual networks, such as the Genesis Kernel [CAM 99] and the X-Bone [TOU 98]. In the Genesis architecture, programmable networks are used to create “child” virtual networks. This is a new paradigm for automating the creation, deploy- ment and management of the network architectures. One of the main motivations of the project is the emergence of open programmable networks. The X-Bone is a system for the automated deployment of overlay networks, virtual networks constructed by means of encapsulation tunnels. The idea is to automate the creation of overlay backbones such as the 6-Bone and to facilitate testing of new protocols by creating an isolated environment. The X-Bone uses a graphical interface and multipoint control channel to manage overlay deployment at the IP layer, much like teleconference sessions are controlled via the session directory (sd) tool. The X- Bone has three basic components. The Overlay Manager is responsible for running the algorithms that acquire resources, configure them and manage them as a coherent overlay. Resource Daemons are processes running at or near resources such as routers and links, they are responsible for keeping information about the state of that resource and coordinating its sharing by multiple overlays. A Multicast Control Protocol uses a two-layer IP system similar to that used by sd/sdr. A common announcement channel (the first layer) is used for resource requests. Once the resources for an overlay are acquired, a control channel (second layer) is created for this specific overlay. This control channel reaches only that set of resources. 5. Towards Dynamic VPNs and the "Envelope" Concept Advances in networking research and technology will enable sophisticated multi- media group communications. Therefore, besides increasing the speed of the local- loop as well as the core network, new services will be required to support the appli- cation needs. VPNs as well as VLANs share the objective of being able to shape the network resources to address some critical issues. Today, a VPN is mainly used for closed-group communication, secured and controlled. It avoids to construct a private network, allows to organize the network resources according to the customer needs and therefore might have an economic advantage. It is usually constructed through 16 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 some form of partitioning of a common underlying communication medium. Assume that group communication becomes a major traffic source, we will face applications where the group of users varies in time and space. Unfortunately, today’s VPNs are statically managed and configured and will suffer facing these new application dy- namics. There exist some similarities between VPN in the general sense and multicast/group communication. In fact, both concepts share common features, needs, and objectives. Namely, a group is a unique virtual object attached with a name and an address. A group is a set of entities that satisfy, at a given point in time, a well-defined member- ship rule. This leads to the decomposition of the framework into two different sets of systems. The social group carries an application semantics and the networking group is the abstraction that enables the social group entities to communicate. The social group holds some constraints so that the application can be established and main- tained. This represents the basis of the group management functions. Active Group Integrity (AGI) conditions are a way to express the constraints on the group compo- sition. It could be defined as a condition on the size of the group, the presence of a quorum, etc. Also, other aspects such as floor control and session management have to be considered. A group can be either static or dynamic according to the fact that its composition can change over time. It is likely that most groups will be dynamic. Therefore, an entity needs to find a way to express its wish to join a group. This is achieved through a join operation that enables this entity to become a member of a given group (if the AGI is satisfied or without control in an open model such as the Deering one for IP multicast). The join is directed to a given group whose name has been advertised by another protocol. Being attached to a group address means for the group members that the routing protocol will be in charge to deliver the protocol data units to every single active user. In order to be successful, a group communication will also require the availability of network resources to satisfy quantitative as well as qualitative requirements. Infor- mation on the QoS (Quality of Service) as well as the security needs will be attached to the group. Similarities with the VPN concept clearly appear because of the common features summarized in Table 1. A complex situation will appear when applications and users will become more and more dynamic in space and time. Todays’ statically managed and configured sys- tems will suffer facing this new capabilities. It will then become mandatory to extend the multicast concept to a Q-VPN one that is a VPN attached with QoS properties but also to a D-VPN solution able to attach QoS as well as dynamicity. Assume that a set of communicating entities share the same space defined by a list of properties. An "envelope" () is defined as the set of properties attached to a group of active entities involved in a given communication in the wide sense (appli- cation, subnetwork, flow, etc.). The envelope defined properties such as AGI, QoS, Towards D-VPNs 17 Table 1. Similarities between the Multicast and VPN models. Multicast VPN Multicast address Globally unique VPN Identifier Multicast Membership VPN Membership Group Management (IGMP), Session Management, and Floor Control VPN Management (static or dynamic) & Advertisement Multicast properties (QoS) VPN properties (QoS, security) Traffic Engineering Traffic Engineering Multicast routing VPN reachability security and so on. These properties should be maintained by the system whatever the configuration of the environment and its evolution. An envelope is therefore uniquely defined by an envelope ID (ID). The issue of being able to provide a unique (ID) in a distributed way is out of the scope of this paper. An envelope ID is attached to an envelope and used by the underlying sys- tem to perform the routing and distribution functions. Once an (ID) is chosen, it is distributed over the network using an advertisement protocol (AP : Envelope Adver- tisement Protocol). A new entity can join a given envelope. As such, and if granted by the envelope AGI, this entity will inherit from all the properties of that envelope and the system will adapt to cover this new entity with these attached properties. This operation is complex and requires sophisticated network engineering functions to ex- tend the envelope to the new entity. Therefore, the basic transfer mechanism of the network can be tag based. A tag is a marker or eventually a piece of code that, when processed in a router will explicitly provide the envelope properties, namely: QoS, security, forwarding, and homing (mobility). We believe that the forwarding function is a sophisticated mechanism able to efficiently derive the output port from the tag information, as well as the required resources to forward the packet according to the envelope needs. The envelope concept () is very similar to the group concept with QoS and secu- rity or the dynamic concept of a VPN. Therefore, it is likely that many mechanisms and protocols of these elements can be re-used in this framework. Nevertheless, we expect that looking at the problem from a different perspective will allow us to achieve a more elegant and efficient solution. This work is in progress. 6. Final Considerations The VPN concept is very general, thus giving an exact definition of a VPN is a difficult task. Nevertheless, we are able to identify some characteristics that any “VPN-service” should provide: closed user group communication and data security. Economics of scale appear as a strong argument for the deployment of most of the 18 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 VPN solutions, provided by the VPN ability to share a common underlying infras- tructure in a transparent manner. VPNs may be implemented by a large variety of technologies, ranging from dial- lines to ATM or MPLS links, using multiple mechanisms to support data security as well as some level of QoS guarantees. Some of the protocols and technologies that are likely to be used to implement VPNs are in the area of current research, this is the case of the IPSec protocol and the MPLS technology. Thus we may expect several new implementation approaches in the near future. Especially regarding QoS provision in VPNs, there is a lot of work to be done as some of the possible support-technologies of VPNs are still under discussion, like MPLS, and the Integrated and Differentiated Services architectures. We have introduced the new envelope concept which is found at the crossroads of multicast communication and VPN. A work is on-going to build the architecture required to enable this system. 7. References [AND 00] ANDERSSON L., DOOLAN P., FELDMAN N., FREDETTE A., THOMAS B., “LDP Specification”, 2000, Work in progress: draft-ietf-mpls-ldp-11.txt. [BAT 98] BATES T., CHANDRA R., KATZ D., REKHTER Y., “Multiprotocol Extensions for BGP-4”, RFC 2283, 1998. [BLA 98] BLAKE S., BLACK D., CARLSON M., DAVIES E., WANG Z., WEISS W., “An Architecture for Differentiated Services”, RFC 2475, 1998. [BRA 94] BRADEN R., CLARK D., SHENKER S., “Integrated Services in the Internet Archi- tecture: An Overview”, RFC 1633, 1994. [BRA 97] BRADEN R., ZHANG L., BERSON S., HERZOG S., JAMIN S., “Resource Reserva- tion Protocol (RSVP) - Version 1 Functional Specification”, RFC 2205, 1997. [CAM 99] CAMPBELL A. T., MEER H. G. D., KOUNAVIS M. E., MIKI K., VICENTE J., VILLELA D. A., “The Genesis Kernel: A Virtual Network Operating System for Spawn- ing Network Architectures”, IEEE International Conference on Open Architectures and Network Programming - OPENARCH99, 1999. [CHA 96] CHANDRA R., TRAINA P., LI T., “BGP Communities Attribute”, RFC 1997, 1996. [DEL 97] DELGROSSI L., FERRARI D., “A Virtual Network Service for Integrated-Services Internetworks”, 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video, 1997. [DIE 99] DIERKS T., ALLEN C., “The TLS Protocol Version 1.0”, RFC 2246, 1999. [DUF 98] DUFFIELD N., GOYAL P., GREENBERG A., MISHRA P., RAMAKRISHNAN K. K., VAN DER MERWE J. E., DORASWAMY N., JAGANNATH S., “A Performance Oriented Service Interface for Virtual Private Networks”, 1998, Internet-draft: draft-duffield-vpn- qos-framework-00.txt. [FER 98] FERGUSON P., HUSTON G., “What is a VPN”, Cisco Systems and Telstra Internet, 1998, White paper available at http://www.employees.org/˜ ferguson/. Towards D-VPNs 19 [FOX 99] FOX B. A., GLEESON B., “Virtual Private Networks Identifier”, RFC 2685, 1999. [GLE 00] GLEESON B., LIN A., HEINANEN J., ARMITAGE G., MALIS A., “A Framework for IP Based Virtual Private Networks”, RFC 2764, 2000. [HAM 99] HAMZEH K., PALL G. S., VERTHEIN W., TAARUD J., LITTLE W. A., ZORN G., “Point-to-Point Tunneling Protocol (PPTP)”, RFC 2637, 1999. [HAN 94] HANKS S., LI T., FARINACCI D., TRAINA P., “Generic Routing Encapsulation (GRE)”, RFC 1701, 1994. [HEI 93] HEINANEN J., “Multiprotocol Encapsulation over ATM Adaptation Layer 5”, RFC 1483, 1993. [KEN 98] KENT S., ATKINSON R., “Security Architecture for the Internet Protocol”, RFC 2401, 1998. [LIM ] LIM L. K., ZHANG H., MANKIN A., “Implementing Quality of Service Virtual Net- work Service (VNS) on CAIRN”, project site: http://www.cs.cmu.edu/ hzhang/VNS. [MUT 00] MUTHUKRISHNAN K., MALIS A., “A Core MPLS IP VPN Architecture”, RFC 2917, 2000. [ROS 00a] ROSEN E. E. A., “BGP/MPLS VPNs”, 2000, Work in progress: draft-rosen- rfc2547bis-02.txt. [ROS 00b] ROSEN E. C., VISWANATHAN A., CALLON R., “Multiprotocol Label Switching Architecture”, 2000, Work in progress: draft-ietf-mpls-arch-07.txt. [SYS ] SYSTEMS C., “Quality of Service for Virtual Private Networks”, White Paper available at http://www.cisco.com/warp/public/779/largeent/vpne/qsvpn_wp.htm. [TOU 98] TOUCH J., HOTZ S., “The X-Bone”, IEEE GLOBECOM’98 - Internet Mini- Conference, 1998. [TOW 99] TOWNSLEY W. M., VALENCIA A., RUBENS A., PALL G. S., ZORN G., PALTER B., “Layer Two Tunneling Protocol (L2TP)”, RFC 2661, 1999. [VAR 97] VARADARAJAN S., “Virtual Local Area Networks”, Ohio State Univer- sity, 1997, Tech. report available at http://www.cis.ohio-state.edu/˜ jain/cis788- 97/virtual_lans/index.htm. [WAI 88] WAITZMAN D., PARTRIDGE C., DEERING S., “Distance Vector Multicast Routing Protocol”, RFC 1075, 1988. Acknowledgements This work was sponsored by FUJB, CNPq, CAPES/COFECUB, and IST Project GCAP N0 1999-10504. Luís Henrique M. K. Costa was born in Rio de Janeiro, Brazil, on October 4, 1973. He received the Electronic Engineer degree and the M. Sc. degree in Electrical Engineering from Universidade Federal do Rio de Janeiro, Brazil, in 1997 and 1998, respectively. He is currently doing a D. Sc. thesis at the University Pierre et Marie Curie (Paris 6), France. His major research interests are group communication, quality of service routing, and multicast routing. 20 Network and Information Systems Journal. Volume 2 - nÆ 6/2000 Serge Fdida is a professor at the University Pierre et Marie Curie (Paris) since 1991. He received the Doctorat de 3eme Cycle in 1984, and the Habilitation a Diriger des Recherches specializing in Modelling of computer networks in 1989 from the University Pierre et Marie Curie. From 1989 to 1995, he was a Full Professor to the University Rene Descartes (Paris). His research interests are in the area of high speed networking, multicast communication, re- source management and performance analysis. He is heading the Network and Performance group of the LIP6 Laboratory (CNRS-University of Paris 6). Otto Carlos M. B. Duarte was born in Rio de Janeiro, Brazil, on October 23, 1953. He re- ceived the Electronic Engineer degree and the M. Sc. degree in Electrical Engineering from Universidade Federal do Rio de Janeiro, Brazil, in 1976 and 1981, respectively, and the Dr. Ing. degree from ENST/Paris, France, in 1985. Since 1978 he is Associate Professor at Uni- versidade Federal do Rio de Janeiro. Presently, he is heading the computer network group (Grupo de Teleinformática e Automação - GTA). His major research interests are high speed communications, multimedia protocols, QoS guarantees, mobile agents, and active networks. View publication stats