The principle objective of Project VOLAN is to research solutions to problems associated with the successfull deployment of Provider Provisioned Virtual Private Networks (PPVPN). These are a type of Virtual Private Networks (VPN) that are managed and deployed by the Service Provider themselves and are offered as a service to corporate customers. Click here for accessing our log of things done so far.

VPN's are private networks operating over the public Internet. Like the Mbone (or Abone or 6bone) it is a type of overlay network that uses tunnels to form a virtual network on top of the public Internet. To a normal user, VPN provides the benefits of a private network (like access to company servers, Intranet etc.), while corporations benefit from the low operational costs offered by it (Need to write on alt.vpns).

VPNs can be deployed by the organisations themselves, by hiring sysadmins that do the configuration at every site. However, as the number of sites to be connected to a VPN increases, it becomes increasingly difficult to maintain them. Moreover, sysadmins don't have any control over the ISP's core network, over which the VPN is established, thus limiting the flexibilty of any such solution.

This is where PPVPN comes into picture. Imaging an ISP offering a VPN service package to the organisation. In this case, the ISP takes the responsibility of deploying and maintaining connectivity between different sites. The organisation just has to give its requirements, for example: the kind of topology that it needs, number of sites that needs to be connected, bandwidth that needs to be reserved etc., and the ISP takes care of the rest.

However such a solution is not without its associated problems and it is the aim of this project to identify such problems and find effective solutions to them.

The name "Volans" comes from the star constellation "Volans" and more information about this can be found here.

1. Shashank Khanvilkar [ Send Email ]

We have identified a number of problem areas that have good research potential. Most of these problem areas were thought by asking ourselves the question "What are the requirements of such a PPVPN from a customer's perspective and from the service provider's perspective?". In other words, we wanted to know what expectations will the customer (and the service provider) have from such a PPVPN. These [*] [*] documents also provide a good starting point for beginers and accordingly we have also classified all such expectations into three different categories as discussed below:

1. Service requirements: These are the requirements that the customer can observe or measure, and thus verify that the Service Provider (SP) is honoring his side of the service agreement.
   • High Availability: Most of the corporate customers for PPVPNs will have business models that highly depend on connectivity between their geographically distributed sites. This naturally implies that the SP contrated to provide VPN service must gurantee high availability (or UPTIME) with bounded DOWNTIME. Providing such reliable network is an open research issue and many solutions have been proposed that use redundant paths that get activated whenever there is a link/node failure. Such redundancy comes at a cost and any proposed solution must aim to minimize such costs.
   • Stability: Internet uses routing protocols such as Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and Border Gateway Protocol (BGP) [*]. These protocols are called best effort routing protocols, and they normally use single objective optimization algorithms, which consider only one metric (either hop count or line cost) and minimize it to find the shortest path from the source to the destination. Thus, all traffic is routed along the shortest path leading to congestion on some links while other links might remain under-utilized. Furthermore, if link congestion is used to derive the line cost such that highly congested links have a higher cost, then such algorithms can cause oscillations in the network, where traffic load continuously shifts from heavily congested links to lightly congested links. Moreover such routing protocols do not allow the corporation to set policies that dictate which links are used by the SP to route their traffic. (Some corporations may not prefer certain SP's). A popular PPVPN solution must take all this into consideration. Advanced routing concepts like constrain-based routing might be one research area here.
   • Support for Multicasting and Broadcasting: Multicasting and broadcasting functions have now proved their importance in multimedia communications. However, such network functions are often provided using an overlay network. Since a PPVPN itself is an overlay network, providing multicasting with another overlay network will increase the overhead on each packet. Thus efficient ways need to be researched for providing these functions in a PPVPN. We have not yet seen any study that quantifies the extent of overhead incurred by using existing multicasting algorithms.
   • Data Isolation: Corporate customers will surely want their data to be completely isolated as well as secure. Security has different implications and is discussed as a seperate point below. However data isolation, here, means ISP's must guarantee that data from one corporate VPN does not leak (even accidently) into another corporate VPN. This is a valid problem as most VPNs will be built using private IP addresses. Thus some extra information needs to be added to each packet to distinguish between different VPN's. Moreover the SP must guarantee that certain control information, like routing updates, does not get mixed up between different VPN's. (This has lead to different PPVPN solutions.) Brief Survey of different tunneling techniques can be found here.
   • Security: This is one of the most important requirement for PPVPNs. An SP must be able to provide mechanisms for user-data security (data encryption, authentication and integrity) between VPN end-points, access-control mechanisms (which user is allowed to access which site) and security from externatl attacks like DoS, spam mail etc. It is essential the all these mechanism must be provided in such a way that they can be changed very often. An effecient and unified distirbuted solution needs to be researched for this purpose.
   • Virtual Topology: A good PPVPN should support arbitary topology formation for the customer. Some customers might prefer the Hub and spoke topology, while others might prefer to have a full meshed VPN. It should be easy to overlay such topology on the existing SP network. An additional service might present a GUI interface to the customer, which provides real-time information about its network. How will this service be acheived? Some more thoughts can be found here.
   • Addressing: Every customer might have a seperate addressing structure. Some addresses might be public while others might be private. A PPVPN solution must be able to support all such addresses for every customer.
   • QoS Support: The SP can choose to provide end-to-end QoS (for this to be possible the SP might have to upgrade his backbone network to support end-to-end QoS using Diffserv, Intserv or MPLS (or any other QOS architecture defined for the Internet) or provide QoS only on the access network, called "managed access VPN service" (in this case QoS is only provided over the access network connecting the Customer to the SP.Some acccess networks to be considered here are:
     
     • ATM Virtual Connections (VCs)
     • Frame Relay Data Link Connection Identifiers (DLCIs)
     • 802.1d Prioritized Ethernet
     • MPLS-based access
     • Multilink Multiclass PPP
     • QoS-enabled wireless (e.g., LMDS, MMDS)
     • Cable modem
     • QoS-enabled Digital Subscriber Line (DSL)
     It is quite probable that the need to provide QoS will occur primarily in the access network, since that will often be the only bottleneck. This is likely to occur since the backbone statistically multiplexes different users, and is traffic engineered or includes capacity for restoration and growth. Hence end-to-end QoS may not be a major issue.
   • SLA and SLS monitoring and reporting: SLS is Service Level Specification and is used to quantify the requirements of the customer. SLS will vary depending on the PPVPN model of choice. For example, currently two models are popular:
     
     • Point-to-point Model or Pipe Model: "Pipe" model, defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a pair of VPN sites. Point-to-Point SLS is analogous to the SLS typically supported over point-to-point Frame Relay or ATM PVCs or an edge-to-edge MPLS tunnel
     • Point-to-Cloud model or Hose Model: "Hose model", defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a CE and a PE for traffic destined to a set (either all or a subset) of other sites in the VPN (i.e., the cloud), as applicable. In other words, a point-to-cloud SLS defines compliance in terms of all packets transmitted from a given VPN site toward the SP network on an aggregate basis
     SLA, on the other hand, is the Service Level Agreement that forms the binding contract between the SP and the customer. Let us assume that the customer and SP, using certain SLS's reach an SLA. However, after this contract is signed there should be some monitoring agencies that need to verify that both parties are meeting their side of the contract. We anticipate that third-party monitoring agencies will form an integral part of any PPVPN solution providing useful inputs during litigations. Some of the objectives of these 3rd party agencies will be monitoring and reporting:
     
     • QoS and traffic parameters for the Intserv flow or Diffserv class.
     • Availability (or UPTIME) for the whole site, or particular links or whole VPN.
     • Duration of outage intervals per site, route or VPN.
     • Service activation interval (e.g., time to turn up a new site).
     • SP's Customer-Service response time.
     • Time to repair interval.
     • Total traffic offered to the site, route or VPN.
     • Measure of non-conforming traffic for the site, route or VPN.
     • Delay and delay variation (jitter) bounds.
     • Packet ordering, at least when transporting L2 services sensitive to reordering (e.g., ATM).
     This is one emerging research areas as there are not sufficient tools to provide such services.
   • Network Resource Partitioning: Since the SP will be offering service to more than one customers, it is necessary that the SP's resoruces are shared fairly among all the customers. More thought needs to be put on this point.
   • Mobility Support: High speed wireless access can be provided using WLAN (which have become quite ubiquitous), and cellular networks (3G +). Hence it may not be too far-fetched to think that any PPVPN solution must also support mobility. Currently Internet supports mobility using Mobile IP, which forms one overlay. Hence supporting mobility over PPVPN's will require, at least, two overlay networks (IP-in-IP-in-IP), if done using the traditional techniques. Thus one research area is to develop techniques that can support mobility over PPVPNs.
2. Provider Requirements: These are requirements from the service providers point-of-view to provide a cost-effective and profitable VPN solution
   • Scalability: For every Customer subscribing to the PPVPN service, the SP will have to maintain separate routing tables, as well as separate routing algorithm instances to maintain such tables. For example, consider an organization like GE, which decides to connect all its 50 worldwide locations with a VPN. In the simplest case, the ISP from which GE buys a VPN service, might decide to create a fully-connected mesh network. This would entail maintaining a routing table with 49 entries and a different routing instance within each router. It is projected that there will be at least O(10^4) VPN's in the next few years. Thus efficient techniques need to be researched that are more scalable.
     The scalability metric can be expressed in terms of
     • User's per site
     • Sites per VPN
     • No. of PE's and CE's
     • No. of VPN's that the network can support
     • No. of VPNs per customer
     • No. of addresses that each VPN can support
     In order for layer 3 PE-based VPNs to scale, all routes for all VPNs cannot reside on all PEs. How is the distribution of VPN routing information constrained so that it is distributed to only those devices that need it? Some Solutions are mentioned here and here.
   • Managment: The service provider must have tools to view the topology, operational state and other such parameters for any VPN. Similar management software must also be provided to the customer. Take a look here.
3. Autodiscovery: For PE-based VPNs, when a new site is added to a PE, how do the other PEs find out about it? When a PE first gets attached to a given VPN, how does it determine which other PEs are attached to the same VPN. For CE-based VPNs, when a new site is added, how does its CE find out about all the other CEs at other sites of the same VPN? Some solutions are mentioned here.
4. Engineering Requirements: These are bottomlines that should be followed, to make a PPVPN solution more acceptable. They have been pinched from here.
   • Forwarding plane requirements: Any proposed PPVPN solution must make as much use as possible of the existing standards and protocols that have been defined. The core routers should not be expected to maintain extra state for VPN's. The solution has to be independent of the tunnenling techniques like IP-in-IP, GRE, MPLS, L2TP and Ipsec (in case of L2 VPN's encapsulation techniques as defined in PWE3??). PPVPN should not impose any restrictions on the backbone traffic engineering and conversely, the backbone traffic engineering must have no effect on PPVPN.
   • Control plane requirements The plug and play feature of a VPN solution with minimum configuration requirements is an important consideration. The VPN solutions should have mechanisms for protection against customer interface and/or routing instabilities so that they do not impact other customers' services. A VPN should be provisioned with minimum number of steps. For instance,a VPN need not be configured in every PE. For this to be accomplished, an auto-configuration and an auto-discovery protocol, which should be as common as possible to all VPN solutions, should be defined. However, these mechanisms should not adversely affect the cost, scalability or stability of a service by being overly complex, or by increasing layers in the protocol stack. Mechanisms to protect the SP network from effects of misconfiguration of VPNs should be provided.
   • Control Plane Containment The PPVPN control plane must include a mechanism through which the service provider can filter PPVPN related control plane information as it passes between Autonomous Systems. For example, if a service provider supports a PPVPN offering, but the service provider's neighbors do not participate in that offering, the service provider should not leak PPVPN control information into neighboring networks. Neighboring networks must be equipped with mechanisms that filter this information should the service provider leak it.
   • Requirements related to commonality of PPVPN mechanisms with each other and with generic Internet mechanisms: As far as possible, the mechanisms used to establish a VPN service should re-use well-known IETF protocols, limiting the need to define new protocols from scratch. It should, however, be noted that the use of Internet mechanisms for the establishment and running of an Internet-based VPN service, shall not affect the stability, robustness, and scalability of the Internet or Internet services. In other words, these mechanisms should not conflict with the architectural principles of the Internet, nor should it put at risk the existing Internet systems. For example, IETF-developed routing protocols should be used for routing of L3 PPVPN traffic, without adding VPN-specific state to the Internet core routers. Similarly, well-known L2 technologies should be used in VPNs offering L2 services, without imposing risks to the Internet routers. A solution must be implementable without requiring to add additional funcionality to the P devices in a network, and minimal functionality to! the PE in a PE-based VPN and CE in a CE-based VPN. In addition to commonality with generic Internet mechanisms, infrastructure mechanisms used in different PPVPN solutions (both L2 and L3), e.g., discovery, signaling, routing and management, should be as common as possible.
   • Each technical solution is expected to be based on interoperable Internet standards. Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution should be ensured (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers. The technical solution must be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service. Customer access connections to a PPVPN solution may be different at different sites (e.g., Frame Relay on one site and Ethernet on another). Interconnection of a L2VPN over an L3VPN as if it were a customer site shall be supported. However, interworking of Layer 2 technologies is not required, and is outside the scope of the working group, and therefore, of this document. Inter-domain interoperability - It should be possible to deploy a PPVPN solution across domains, Autonomous Systems, or the Internet.