May 2001

Virtual Symmetry

BY KEVIN MAYER

In the case of VPNs, complexity is unavoidable, since we expect VPNs to reconcile a tangle of conflicting goals. VPNs should allow businesses to support more or less autonomous divisions or working groups; at the same time, VPNs should help businesses promote common goals, reinforcing the sense of authority and control. VPNs should extend business information and communications resources without regard to geography; at the same time, VPNs should support selective or permissive access and maintain security. VPNs should allow closer cooperation between business partners; at the same time, VPNs should enforce limits on information sharing, while helping businesses maintain distinct identities, ensuring they identify and pursue their own interests. VPNs should facilitate mergers and acquisitions, though the promise of effective internetworking; VPNs should deliver on integration promises so well that even a company of "shreds and patches" should appear finely tailored.

VPN VARIATIONS
Taken together, these conflicting goals suggest that in business, "virtual" may mean almost anything. Accordingly, in networking, "virtual" may describe any number of connectivity arrangements. For example, a virtual corporation could be something as simple as a company that supports remote workers. In such cases, a VPN might consist of a dial-up connection, from the remote worker to a corporate site, typically through a secure tunnel. Or the remote worker might dial-in directly to a remote access server, perhaps with the benefit of an 800-number or, if that were not available, a long-distance call. Other options consistent with this sort of access might include a remote PBX solution, that is, some way to treat the remote worker's phone as an extension of the corporation's PBX.

That the solutions just described are fairly recent VPN developments, and are fairly modest in scope. More venerable and more elaborate VPNs have linked far-flung corporate sites for years. Indeed, some would argue that the VPN concept isn't limited to virtually private transmissions over the public Internet, or over the PSTN to a remote access server, but that VPNs also include wide area networks relying on dedicated facilities and leased lines. You could make the argument that leased lines, by definition, are not owned, and are therefore not private property. In addition, you could say that "virtual" should be taken to mean that the multi-site corporation merely appears to be a single entity. Hence, a WAN relying on dedicated facilities could be called a VPN.

VPNs, however, needn't rely on dedicated facilities to link multiple corporate sites. For example, corporations can avoid per-mile line charges by linking via some sort of data network. Indeed, such networks offer a cost-effective option for linking branch offices to the corporate network. In some cases, the VPNs available from such networks confine the service provider to a relatively limited role. That is, the service provider might deliver basic transport and connectivity, perhaps via frame relay or a T1 line. The service provider would not, however, contribute any premises equipment that might support special security or quality of service measures. The service provider would simply guarantee a certain amount of bandwidth, and whatever the enterprise decided to do with that bandwidth would be the enterprise's business.

Some enterprises might prefer to outsource the network management chores that go along with maintaining a multi-site VPN. These enterprises might take advantage of service provider offerings ranging from equipment rentals to training to help desk support. In the case of multiservice networks, enterprises concerned about quality might opt to run their traffic over provisioned VPNs or IP VPNs offering quality of service guarantees, thus avoiding the public Internet.

VPN-STYLE CONVERGENCE
As if all the aforementioned variations weren't enough to exhaust one's patience, there's the matter of convergence. When we contemplate convergence, plus real-time interactivity, we might be inclined to rethink the usually sharp divide between transport and content.

Such a divide would seem to make sense with VPNs. After all, VPNs are about transport. The VPN mechanism, if it may be called that, stands more or less separate from the actual generation of traffic. In the case of an IP VPN, why should it matter to the VPN whether any given packet has to do with a document download or a phone conversation? If a VPN is to carry voice traffic with any success, it will have to accommodate voice traffic's sensitivity to latency.

Here, I should note that I don't have in mind the traditional voice VPN. In my conversations with various suppliers of VPN solutions, I perhaps incautiously began talking about voice VPNs, while assuming I would be understood to mean data VPNs configured to support interactive voice and video. Often, that was not the case. Many people understood voice VPNs to mean networks in which leased lines were used to connect disparate PBXs.

Increasingly, we will take it for granted that VPNs are data VPNs, whether they happen to carry voice traffic or not. Eventually, we won't even worry too much over whether any particular VPN infrastructure or service is voice-capable or not. We'll just assume that it is. In the meantime, however, we'll want to scrutinize VPN services or infrastructure components closely before trusting them with voice traffic.

The growing tendency to assume that any VPN is part of a larger trend, one that may lead the word "convergence" to fall into disuse. "Convergence" can be misleading, since it suggests some sort of parity between voice and data. There is no such parity. Increasingly, voice developments are contingent on data developments. It is up to voice to hitch its wagon to the data star. In practical terms, this means suppliers of voice-optimized components must provide these components in forms that accommodate the data-centric outlook of enterprises and service providers, as well as the development priorities of mainstream data infrastructure and networking equipment vendors.

A few examples: CompactPCI voice processing boards appearing in high-availability network servers; voice verification, natural language speech rec, and text-to-speech technology incorporated into various portal solutions; network testing solutions that ensure voice and data may share the same transport resources without compromising voice quality; etc. We're not talking about "convergence," a fusing of equals. We're talking about how data is absorbing voice, and how voice is more than willing to be absorbed.

What may be the primary example of data absorbing voice is the topic of this column: the voice-capable data VPN. While few expect that VPNs will incorporate network elements that combine VPN functionality and PBX functionality, VPNs will become increasingly adept at working with IP-PBXs and/or PBX/gateway combinations.

ABSORBTION REQUIREMENTS
If the problem with voice and video traffic is sensitivity to latency, why not just provision more bandwidth? Well, the cost advantages of relying on a VPN's shared facilities could quickly fade if you were to provision too liberally. For many corporations, cost considerations are paramount. Thus, if a data VPN were to accommodate voice, some means of ensuring voice quality other than over-provisioning would be valuable, especially if latency-adding security measures were to be implemented as well. Typically, in such a scenario, considerations turn to prioritization schemes, that is, giving voice packets higher priority than, say, data packets attributable to e-mail exchanges or Internet browsing.

I've had several discussions with industry experts on the bandwidth/security/ voice quality tradeoffs posed by data VPNs that would accommodate voice and video. Jason Choong, product marketing manager for Agilent Technologies, notes that for packet telephony over a VPN, the "key requirement is QoS, that is, a jitter-free, low-delay transport. Bandwidth is, strictly speaking, not a key requirement for individual connections, but becomes an issue when trunking is involved. This could either be a service provider carrying large numbers of connections between cities, or enterprises taking T1 or E1 trunks to the backbone. It's unlikely that bandwidth will be a constraint for voice service due to low bandwidth utilization, so the over-provisioning versus bandwidth management debate is unlikely to be a significant consideration for VoIP applications."

"Now, if you're looking at the QoS issue, you enter the quagmire of poor QoS guarantees over IP. This is the basis behind MPLS, which, through traffic engineering, allows you to better manage you flows (including voice flows), to allow better guarantees on QoS. The same mechanisms make MPLS a front-runner for provider-based VPN management. For this reason, you will find much interest out there on VoIP over MPLS solutions. You should also note that traditional VPN technology, such as L2TP or IPSec do not provide QoS guarantees. They're really more focused on flow management and security."

Whether security could threaten voice quality in any given deployment depends on the degree of security appropriate for that deployment.

"Security needs vary," notes David Saunders, senior director of marketing for the Enterprise Business Unit of Clarent, "According to a company's voice application purposes. Most organizations simply need firewall equipment that prevents denial-of-service attacks for voice equipment and that prevents hacker entry into data elements. Those organizations that desire protection of signaling information so that eavesdroppers cannot see who's calling whom may deploy additional encryption equipment that encrypts data traveling through specific data ports, generally without adversely affecting voice performance. Should a company desire total encryption of all voice packets to ensure that eavesdroppers cannot hear voice conversations, encryption hardware can do this as well; however, network planners must be certain that the equipment's processing capability can process without delay the number of packets that voice gateways generate each second."

"Whereas software-only solutions are generally untested and therefore unsuitable for voice over packet networks, many new network and data protection market entrants have introduced combinations of software control and hardware execution elements that improve protection without adversely affecting voice quality."

Another dimension to the security issue is privacy within the network, depending on the type of network transport. "Today's voice over VPN networks," notes Saunders, "typically use one of two networking approaches: 1. Point-to-point non-routable protocols such a Frame Relay or ATM that guarantee privacy within the network. 2. Point-to-multipoint IP networks that require encryption equipment to maintain privacy."

"Voice and data convergent equipment may combine voice and data into frames or cells that can be transmitted over frame relay or ATM networks without the need for external VPN equipment [which may provide voice compression, voice-to-data conversion, and LAN-to-WAN routing functionality]. This equipment additionally assigns voice packets higher priority than data packets, [accommodating] voice's real-time nature."

"VoIP equipment delivers voice packets that must then be delivered to the network via external routing equipment. Implementations that ensure privacy therefore require external encryption devices -- usually separate from IP routers -- that filter or encrypt packets."

Clarifying the distinction between enterprise-scale and service provider requirements, Choong indicates that "if the service is managed by an enterprise, [and if] the enterprise is relying on an unsecured IP transport offered by an ISP, then security will need to be initiated by devices in the enterprise. As such, hardware-based solutions will not be required because the bandwidth used by individual enterprises (even when combining voice and data traffic) will not exceed the performance offered by software-based security solutions."

"However, a provider-based (or perhaps a very large private facility) solution, with voice and VPN data multiplexed from many enterprises will require ASIC-based encryption. Traffic management is typically done through software because the processing requirements are significantly lower, and the algorithms are just too complex (and change too often) to burn into ASICs."

CONCLUSION
While this column has done no more than scratch the surface of data VPN/packet telephony applications, it has at least reflected some of the variety these applications may exhibit, as well as the variety of deployment configurations that may enable these applications. Beyond the traditional voice VPN -- that is, the sort of VPN that relies on dedicated facilities to link PBXs -- there are data VPNs that may accommodate voice, and may do so over different transport types with varying degrees of security and encryption.

In voice over data VPN deployments, the balance of cost considerations with quality and security requirements will vary, and will likely demand some combination of adequate bandwidth provisioning, packet prioritization, and software/hardware security.

If we may add one more distinction to our examination of multi-service VPNs, we should briefly note the difference between "interactive" voice and video and "streaming" voice and video. In general, the interactive type is more demanding, being, by definition, "real-time." As indicated by David Oliver, chief technologist at IP AXXESS, "when packets of regular data are lost on the Internet (which happens routinely), they are resent later to ensure all the data is delivered correctly. This is done for broadcast voice (Internet Radio) where a large buffer smoothes out the delays caused by retransmission, and works well in a situation where a delay of tens of seconds doesn't affect usefulness -- no one really minds if they get the news ... half a minute late!"

"For conversations, delay is irritating and can be confusing if any echo is present in the signal, so packet telephony simply fills in for lost packets with either silence (which gives a "cellular" quality to the call), or by using predictive coding techniques to smooth out the gaps and provide a better listening experience."

Thus, data VPNs that may carry voice and data are distinct from traditional voice VPNs, and are also distinct from the sort of applications that might occur to someone with a data-centric point of view, particularly one that emphasizes the broadcast of information to a relatively passive audience. Streaming voice and video is one thing, interactive voice and video, which may extend the reach of business applications and enhances interactivity, is another. We'll explore the subject in more detail next month, in a lengthier feature on data VPNs and their growing ability to accommodate interactive voice and video.

[ Return To The May 2001 Table Of Contents ]