There could be gold in that thar competitive local exchange carrier (CLEC) copper.
Internet protocol (IP)-based virtual private network (VPN) services present an opportunity waiting to be mined. In the metropolitan markets that define the CLEC business, VPN services are an ideal solution for customers hoping to replace expensive leased lines and data services with IP networking.
But until recently IP VPN strategies typically were regarded in terms of the Internet: leveraging its global accessibility and low cost as a medium for wide area network (WAN) connectivity. This emphasis on Internet VPNs has more or less missed the business of selling high-speed, high-quality VPNs for local consumption, however. Rather than pitching tunnels across the Internet, CLECs can sell high-speed, business-class VPN services using their metropolitan networks as the backbone.
Panning for Savings
A replacement for the leased lines and frame relay that typically connect offices or branch locations across town and within a region, VPNs can offer a cheaper, faster and easier route for customers. Leveraging the CLECs' established bandwidth alternatives, metropolitan VPNs can be used with any Layer 2 or Layer 1 access technology to provide native local area network (LAN) speed connections that entirely bypass the Internet VPN throttle. From this perspective, Internet connectivity becomes the long-haul option, just one of several choices for bringing traffic in or sending it out across the wide area.
To connect customer sites across the WAN or to pull in remote-user traffic, CLECs either can leverage their own WAN facilities, provide the cheaper option of Internet transport or both. Performance will be better (even fully guaranteed) over the carrier's own network, but VPNs easily can extend connectivity to remote users, business partners and customers over the Internet as desired.
VPNs are the key to the local IP market. In loose technical terms, VPNs are IP's equivalent to the permanent virtual circuits (PVCs) of asynchronous transfer mode (ATM) or frame relay--they carve private bandwidth out of a carrier's shared infrastructure and thus provide the security and assured performance that business users demand.
In the business sense, VPNs are essentially an outsourcing solution. Until now, CLECs have focused on Layer 1 (copper/fiber/wireless etc.) and Layer 2 (voice/frame relay/ ATM) services. VPNs arrive at Layer 3, getting CLECs into the IP game that until now has been played mostly by Internet service providers (ISPs).
New Weapons
The early VPN gateway products were designed for toll-bypass strategies and are enterprise-point products. Early adopters have used them to build their own individual VPN solutions, but they are not adequate for large-scale IP service deployments.
New carrier-grade VPN products, however, have integrated IP bandwidth management that can deliver performance guarantees to meet customer service level agreements (SLAs).
This bandwidth management must be extremely granular, able to partition bandwidth not only between different user networks but also across a single customer's traffic stream. As a service competing against Layer 1 (leased line) and Layer 2 (frame relay/ATM) options, IP VPNs still must allow customers to maintain control over how their bandwidth dollars are spent. The goal is to achieve IP services that can deliver on the same parameters as today's established technologies.
Architecturally, a carrier-grade VPN solution should integrate these requirements in one platform that consumes less space and is managed more easily than a collection of separate elements. It's ultimately a matter of building VPN capabilities at the integral part of a carrier's operations, not as a service afterthought.
The "private" in virtual private networking is a matter of separating and insulating each customer's traffic. IP security (IPSec) standards for tunneling and data encryption set the rules to carve private end-to-end pipes or "tunnels" out of public IP bandwidth and then encrypt the information that flows within those tunnels. The IPSec standards define strong authentication and encryption services at the IP network layer, and will play a dominant role in VPNs.
In addition to IPSec at Layer 3, there are two standards for establishing tunnels at Layer 2. These are the point-to-point tunneling protocol (PPTP) and Layer 2 tunneling protocol (L2TP), neither of which includes the encryption capabilities of IPSec. IPSec's value beyond these solutions is that it operates at IP's Layer 3. It allows for native, end-to-end IP tunneling and, as an IP-layer service, it can complement connection-oriented Layer 2 schemes.
IPSec provides a robust architecture for secure wide area and remote dial-in VPN services. It is fully complementary to any underlying Layer 2 network architecture, but with its addition of Layer 3 security, IPSec marks a transition from early VPN tunneling to full-fledged VPN services.
Of course, different implementations of IPSec will confer varying degrees of security services. Rather than handing off security functions to a standalone security server as VPN gateway products have done, this functionality should be integral to the VPN service platform. Security integration includes support for both Internet key exchange (IKE), which automatically negotiates security associations among gateway endpoints, and for the public key infrastructure via X.509 formatted certifications, plus interoperability with emerging certificate authorities.
A Tough Crowd
Security is just the first component of a VPN solution. Customers also will demand predictable performance, with service levels matching what they've come to expect on their existing networks and what they need to run business-critical applications.
There are two different aspects to the VPN performance requirement. First, users need guaranteed service levels that apply to VPN trunks across the backbone. These bandwidth guarantees mimic private leased lines and must offer performance akin to frame relay's committed information rate (CIR) service, for example.
Secondly, customers need control over how their VPN bandwidth is shared and partitioned among their own users and applications. This quality of service (QoS) allocation requirement is a bandwidth management concern that plays out at every network access point.
Differentiated services (DiffServ) is the emerging IP specification for building services that can offer QoS across public IP networks. By classifying traffic streams and policing their admission rates as they enter the network, user-level QoS can be achieved with technologies such as class-based queuing (CBQ). CBQ is an IP layer feature that classifies traffic according to granular network policies. It provides the admission controls, assignment to classes and provisioning support that, when complemented with DiffServ, allows individual customers, applications, subnets or even different groups of users each to receive bandwidth tailored to meet their specific QoS requirements.
DiffServ and CBQ can be combined to manage IP traffic efficiently in very dynamic, large-scale environments by adding one further capability: bandwidth borrowing. Bandwidth borrowing allows customer traffic to burst at rates beyond CIR when idle bandwidth is available on the network. Likewise, different traffic classes within a customer's VPN link may borrow bandwidth from one another as needed. The result is a Layer 3 VPN service that achieves the bandwidth efficiencies of statistical multiplexing.
Because VPNs aggregate large volumes of traffic and also will operate over the Internet, robust and reliable Internet-scaled routing services must be integrated at the access point. Most VPN devices are simple gateways that rely on external routers for connectivity. What's required is a single platform that integrates routing functionality and supports major IP routing protocols. For reliability, the VPN platform should include solid implementations of both border gateway protocol 4 (BGP4) multihoming and the virtual router redundancy protocol (VRRP). These dual protocols allow inherent redundancy in case backbone links or routers fail, securing the VPN platform as a mission-critical device.
Overall integration is the key to a robust VPN architecture. With the early focus on tunneling alone, first-generation VPN gateways address only one piece of the VPN challenge. They demand a host of other platforms to handle routing, security, bandwidth management and other aspects of a business-class service. This multibox solution increases management complexity and reduces reliability by introducing many configuration interfaces and single points of failure. The result is that each VPN access point would require four or more separate networking platforms (a router, VPN gateway, bandwidth manager and security firewall). Each device is a potential point of failure that could bring the entire link down, so for mission-critical WAN deployments, users have to double the hardware count at each site (that could be eight boxes, total) to provide backup redundancy.
This multiplicity of platforms is what early adopters have had to deal with, cobbling together a VPN solution from the various parts available. So many separate, discrete boxes not only increase management and reliability concerns, but they also introduce added latency with performance mismatches that typically compromise the performance and scalability of the entire solution. But integrated, second-generation VPN platforms bring together the key requirements for business-class VPN services.
Having built a business around fierce competition for cheap local access, and with the Internet as a long-haul option, CLECs are well-positioned to meet the corporate shift to outsource IP networking. Stepping up a rung to IP's Layer 3, the more value that carriers can add to the bandwidth they deliver, the more profit they derive from the local loop connection.
For this reason alone, IP VPNs across metropolitan backbones could be the next gold rush in the CLEC community.
Ashley Stephenson is chairman of Xedia Corp. in Littleton, Mass. He can be reached at (978) 952-6000, ext. 101.
