The two different worlds of VPNs

Although most users don't realize it, there are two views of virtual private network (VPN) quality of service (QoS) today. First, there's the priority view, promoted by the Internet crowd and embodied in the developing Differentiated Services (Diff-Serv) standard. Then there's the provisioned view, promoted by facility-based carriers and based on the developing Multi-protocol Label Switching (MPLS) standard. The two approaches are dramatically different in what they would offer users.

Diff-Serv provides relative levels of service - say, bronze, silver and gold service classes, each with its own pricing. However, the exact performance delivered by any of these grades of service will vary depending on traffic and network conditions. Gold service may be better than bronze, but it won't have a specific set of QoS parameters to guarantee it, at least not Internetwide.

ISPs are the likely champion of Diff-Serv, but the very introduction of Diff-Serv may further strain the ISPs' business relationships. Efficient linkage of ISPs depends not on official interconnections, but on private peering agreements. Even in today's world of best-effort service, ISPs are bickering over the financial and technical terms of peering agreements. Introducing Diff-Serv would complicate matters considerably because the Diff-Serv standard doesn't spell out how multiple service levels would be provided in a single network, much less in a collection of ISPs.

Provisioned VPNs based on the marriage of IP and ATM would provide as absolute a level of QoS control as ATM would provide, which would enable the carriers to write specific service-level agreements (SLA) on these services.

MPLS creates tunnels that resemble virtual circuits in the way they work, which is why MPLS is a logical way to link IP and ATM. Facility-based carriers love MPLS because most of them favor ATM as the multiservice infrastructure of the future. But provisioned VPNs will require the buyer to set some limits on traffic volume in return for receiving a reserved performance level, which may make this type of VPN less flexible.

For facility-based carriers, interconnection won't be easy, either. Even though there are standards to permit the interconnection of virtual circuit networks, carriers have dragged their feet in adopting interconnect agreements. A Bellcore-sponsored effort to ensure frame relay interconnection fell apart years ago because of disinterest on the part of some key interexchange carriers. Frame relay networks are rarely interconnected today, and when they are, the interconnecting carriers usually won't guarantee QoS levels.

The lack of interconnect agreements hurts the smaller players, many of which won't be able to cover all their prospective buyers' sites because of limited service geography. If effective interconnect strategies aren't provided for both forms of VPNs, users with widely distributed sites may find only the national service providers can support them, which could increase VPN prices by reducing competition.

Then there's the customer premises equipment (CPE) issue. What does a Diff-Serv VPN access device look like, or for that matter, what does an IP-ATM/MPLS access device look like?

Because Diff-Serv doesn't provide absolute QoS levels, it doesn't require CPE that performs complex traffic shaping or management. All the CPE has to do is ensure that packets representing gold Diff-Serv services are queued ahead of those representing silver.

IP-ATM/MPLS, because it is based on virtual circuits or tunnels that act like virtual circuits, may require traffic shaping to ensure that user data doesn't exceed the traffic level that the service provider committed to carry. Because traffic shaping may introduce delays, it may be helpful to link this shaping process with flow control of the application, something some LAN vendors are already doing in a proprietary way.

One thing is sure: Applications will have to be classified by the level of QoS to which they're entitled, no matter what form of technology is used inside the network to provide that QoS. Policy management or directory-enabled networking may be overkill on the LAN, where it's less expensive to buy bandwidth than to manage it. However, at the VPN boundary, we're going to have to select the right class of Diff-Serv service, or put the data on the right MPLS pipe, to make VPN QoS work.

But there's good news. We're at least seeing the issues now. Users who know that all VPN strategies aren't the same, and that all VPN CPE won't necessarily work with all types of VPNs, are at least in a position to demand that their service providers and equipment vendors answer questions about their approaches to VPNs and QoS. The service providers' and vendors' answers should make it possible to pick a set of service and equipment options that meets buyer objectives.