The future-proof VPN

As today's business customers demand a higher level of network access, the industry is migrating from a private network environment to a new model in which information is distributed throughout the enterprise network. Joining the mix are the road warriors and telecommuters who expect to access this information as easily as those in the office.

Enter the virtual private network (VPN), designed to meet the demands for information access in a secure, cost-effective environment. The VPN provisioning process differs among service providers by the type of infrastructure in the network core.

Internet service providers and IP-based competitive local exchange carriers will carve out a secure service across either the Internet or separate business-class IP networks. Incumbents, interexchange carriers and most CLECs typically route IP protocols across their frame relay/asynchronous transfer mode networks, adding routing functionality on top of the connection-oriented transport layer.

Whatever the approach, carriers have yet to cross substantial technological hurdles to make VPNs work in a secure, seamless and effective manner. In addition, they face significant challenges on the regulatory side: With the passage of the Telecommunications Act of 1996, building a VPN in an evolving regulatory environment presents formidable challenges to vendors, service providers and end users alike. For these reasons, carriers may want to forgo a routing-based VPN solution in favor of a more flexible platform.

Regulatory problems Analysis of several key sections of the telecom act raise some very real business and operational issues that vendors should consider as they build next generation equipment and as service providers deploy to large enterprises.

Here are a few of the relevant regulations and pending proposals within the act that may affect the establishment of a VPN service:

* Section 706 requires the FCC to initiate an inquiry into the availability of advanced telecommunications capabilities to all Americans. Within six months of initiating the study, the FCC must take "immediate action to accelerate the deployment" of advanced telecommunications capabilities.

* Section 251 requires incumbent LECs to offer cost-based rates and non-discriminatory interconnection to their networks and access to unbundled network elements. It also requires incumbents to wholesale retail services to new entrants.

* Section 271 includes the competitive compliance checklist for the regional Bell operating companies to demonstrate their effectiveness in opening local markets to competition.

A recent notice of proposed rulemaking provides RBOC relief from Sections 251 and 271 of the telecom act to help accelerate deployment of higher margin advanced data services. It allows RBOCs to establish an independent arm's-length and fully separate subsidiary for the purpose of offering advanced data services within the RBOC's region. Therefore, any CLEC can purchase a co-location tariff associated with multiplexing.

This means that a VPN advanced data service could be supported by a co-located multiplexer, but not by a co-located switch or router-although the FCC is assisting RBOCs in co-locating other networking elements, including data switches.

These regulations greatly affect both near-term and future design strategies for service providers wanting to add VPN services to their product portfolio.

Routers are not the answer A popular method today for establishing an RBOC- or CLEC-based VPN service involves the deployment of routers at the edge of the provider's core network either as a separate entity or as an integrated component of an edge switch (Figure 1).

The realized and perceived benefits of this approach include:

* Reduced virtual connections cost for the customer

* Lower operational expense for the service provider

* The ability to tunnel IP to a virtual connection up to "wire speed" that is transparent to the customer

* The ability to offer a variety of differentiated services tailored to a customer's specific transport, security, monitoring and management requirements.

Some say that virtual IP routing makes configuring and managing a VPN as straightforward as configuring and managing a router-based private network. Each group of end users "sees" the network as its own private domain. This has particular appeal to customers because they retain the ability to use private, unregistered IP addresses to create independent virtual routing networks.

This private networking space is created by the use of "tunnels" through the IP fabric via one of several emerging techniques-MPLS, L2TP, PPTP, IPSec and others.

But the use of routers as the enabling platform for the provisioning of VPN services presents several challenges to the CLEC seeking to expand its service footprint through co-location agreements with incumbent carriers.

The VPN service provider needs to manage switching and routing and faces the additional challenge of building multiple logical routers and maintaining router tables for separate enterprise end users that are not shared with anyone else. Overlap addresses among end customers is a concern.

Because of the current regulations, there are specific co-location issues: Is the router integrated into the switch? If so, do regulatory constraints exclude the co-location of such a platform with an integrated advanced data service capability in the central office?

Currently, incumbent LECs do not offer co-location tariffs for switches or routers. A CLEC with an existing core network typically cannot take advantage of placing a switch or a router in the CO. Even where the CLEC can place a switch or router into the incumbent's CO, accessing the device is difficult and time-consuming. This presents an ineffective environment for offering VPN services with the service level agreements (SLAs) requested by the corporate client.

Time-to-market delays are another concern. FCC regulations require the incumbent to offer comparable terms and conditions for tariffed facilities to other CLECs if the incumbent LEC itself offers advanced data services via a fully separate CLEC subsidiary. Alternatively, the incumbent carrier can offer this type of service directly and wholesale to any interested CLEC. This has led to delays as the incumbent LECs prepare and analyze their business cases before deciding on a deployment strategy.

Notwithstanding co-location concerns and time-to-market delays, the question arises as to whether the incumbent LEC's core switch can support two or more CLECs with a wholesale VPN service. Will the management system scale with the switch to support multiple VPN end users? Are there any other regulatory repercussions for an incumbent that wishes to create its own separate subsidiary as a CLEC?

Of extreme importance to the potential VPN client is the security of the service. Do the enterprise customers see only their part of the network or do they have the potential to "discover" the entire topology? Do they have access to the ATM/frame relay network? Do end users have access to routing tables, and how are they secured? What is the risk of unauthorized signaling? Will the routers be inundated with table updates every time something changes in the larger network?

Finally, there is the potential for limited freedom of choice. Does this type of architecture lock a service provider into using a particular supplier's virtual IP router products?

The multiservice solution Emerging in the marketplace today is a new breed of multiservice access platforms, which sit between the core network switch and the corporate router. These advanced platforms enable service providers to deploy virtual IP networks that are flexible, scalable and affordable (Figure 2).

This approach provides several benefits not available in a router-based approach. To achieve increased operational effectiveness, it is now possible to install a multiservice platform at every enterprise endpoint that has the processing power and intelligence to contain forwarding tables and automatically distribute these forwarding tables to all other multiservice access platforms in the network.

Forwarding tables make it easier to establish and manage a VPN without the additional administrative burdens, regulatory concerns and security issues associated with integrating a router in the network. The service provider now can tunnel IP to a virtual connection up to wire speed transparently.

New entrants to this area such as Advanced Switching Communications have designed platforms that can be configured as either a multiplexer or switch. Should the regulatory or business environment change and co-location of switching elements become feasible, a multiservice access platform can protect the customer's or service provider's investment in a VPN network.

These products may be reconfigured from a multiplexer to a switch or vice versa. For a CLEC that owns its own network and needs to expand through co-location in the RBOC CO, the multiservice access platform can be configured as a multiplexer that is tariffed for co-location. This provides the CLEC with a low-cost solution to expand its points of presence beyond current topological constraints and facilitates the distribution of advanced data services.

Rather than wait for the RBOC to determine the business model a CLEC will pursue, the multiservice access platform enables a CLEC to either co-locate multiplexing equipment based on established tariffs or resell an incumbent's advanced data services. Should the business model change, the CLEC can quickly reconfigure the multiplexer into a switch to provide local switching capabilities, offloading the core switches and reducing backhaul requirements.

CLECs require a scalable platform that allows them to cost-effectively grow their VPN networks from a trial environment to full-scale deployment. The platform must be designed with industrial-strength, carrier- class features such as full redundancy and NEBS compliance, and it must provide outstanding value regardless of the scale of the operation.

Organizations considering VPN services expect to receive the same high-level security that private network solutions provide. A multiservice access platform will look like an IP router at the customer premises, but it provides private network security levels because end users do not have direct visibility or access to the core network. The service is provisioned within the platform, so the customer gets what is provisioned by the service provider. The platform uses secured and customer-specific forwarding tables provisioned by the service provider. The user traffic can then be forwarded over the service provider's native, connection-based core network.

By isolating the end customer from the provisioning process, the service provider can offer more profitable SLAs. Customers get the inherent security of the virtual connection-based core network with the flexibility of IP routing. Enhanced security also includes isolation of IP forwarding tables among customers.

Combining with flexible management architecture allows for complete customization of the access node into a service provider's existing management system. With service enabling software, each access loop can be configured as ATM, frame relay or IP. SLAs and differentiated service qualities can be tailored and managed for each end user and each connection.

The coming months will produce further clarifications on the operational issues surrounding VPNs as service providers roll out networks for an increasing number of businesses. But until then, using a co- located multiservice access platform will help carriers establish and maintain their VPNs without the problems associated with integrating a router in the network.

In creating "meshed" connectivity between multiple sites, VPNs can potentially offer significant cost savings because of the type of connectivity and the pricing of network components.

Because private lines are point-to-point, carriers price them on a distance-sensitive basis. Frame relay networks are generally accessed via a dedicated local loop to the port of the frame relay switch and by establishing permanent virtual circuits (PVCs) to each network node. While these types of networks offer reduced costs over private lines, the sheer number of PVCs required for meshed connectivity adds cost and complexity.

In contrast, a VPN requires only that the site be connected to the network. It does not require a special physical or logical relationships between nodes in order to achieve "any-to-any" connectivity between sites.

In addition to the potential cost savings (see table), IP-based VPNs offer substantial advantages over connection-oriented solutions such as private line and frame relay PVCs. IP is tightly integrated with the desktop, the LAN and the WAN. Requiring no additional protocol conversion, IP is scalable and induces minimal additional overhead. Because IP is connectionless, companies can use it to create extranets.

The costs shown in the table, based on currently available carrier tariffs, represent average prices for different-sized networks that are fairly evenly distributed across the U.S. T-1 (1.54 Mb/s) prices average approximately $8000 a month and T-1 frame relay costs approximately $2500 a month. T-1 access to the Internet today averages $1500 a month.