IP VPN Deep Dive

An IP VPN Defined
How IP VPNs Work
Why Would a Business Want an IP VPN?
Introducing MPLS
Legacy WAN Technologies

An IP VPN Defined

An IP VPN can be defined as the analogue of a private IP wide-area network, running on a shared network infrastructure.

Large, multi-location businesses use a range of technologies to connect local-area networks (LANs), telephone systems and other equipment at far-flung locations. They build WANs for many reasons: to enable secure use of company-wide client/server applications, to transport email and files across secure channels, to centralize network administration - even, in some cases, to take inter-office voice and fax communications off the public network, and avoid paying long-distances charges on this traffic ("toll bypass").

There are many ways to build a WAN. Simple WANs can be built using point-to-point leased circuits (e.g., leased T1 or fiber), driven by premise equipment. Leased-line WANs are commonly set up in a "hub and spoke" topology, where one leased circuit connects each subsidiary location to a head office or central computing facility. This can be efficient where communications flow mostly between peripheral locations and the central site, as with mainframe-based client/server applications. Achieving Internet-style "any to any" communications is also possible in a hub-and-spoke WAN, provided equipment at the central site can handle the job of shuttling traffic from one peripheral location to another. But performance can be improved by building a "full mesh" - where each location connects to all the others on multiple leased circuits. This is practical for linking a few locations (e.g., linking main banking offices in New York, Houston and LA into a fully-meshed backbone), but becomes less manageable and affordable for larger numbers of nodes (e.g., attaching that backbone to 3,000 branch offices, nationwide).

Packet- and cell-switching technologies like X.25, frame relay and ATM provide any-to-any connectivity without a full physical mesh. A frame relay WAN, for example, requires only one connection between each location and the carrier's network. "Virtual circuits" are then provisioned across the network, connecting each location to all the others (these are unidirectional; bidirectional communications between two sites demands two virtual circuits, one in each direction). Simple frame relay WANs can be set up in a "hub and spoke" topology. Building a fully-meshed WAN means provisioning pairs of virtual circuits from each location to all the others. The physical mesh becomes a logical mesh.

Frame relay is a great improvement over leased lines. But that mesh of virtual circuits can still be hard to manage, upgrade and change. Frame relay also provides only limited built-in mechanisms for controlling quality of service. So it cannot enable best performance of applications like VoIP.

Digitization and Encoding

To transmit voice across an IP network, you start with an analog audio signal -- a pattern of frequencies initially propagated in air, transduced by microphone into an analogous pattern of electrical voltage fluctuations. This signal is converted to a sequence of (usually eight-bit) binary numbers by an analog-to-digital converter circuit, which samples line voltage repeatedly, at a high rate of speed (usually 8,000 times per second) as it changes over time. The result is typically (though not always) equivalent to a standard telecom 64kbps DS0 signal stream -- the same sort of input signal used as the "voice channel quantum" (the end-to-end switched bandwidth reserved for a phone call) in conventional digital telephony.

Next, the digitized input signal is mathematically pre-processed -- filtering background noise and emphasizing speech band information. When a speakerphone is engaged (or when using IP audioconferencing gear), additional audio pre-processing stages may analyze and cancel room-reverberation, speaker-to-mic echo, and other undesirable signal components.

It's also common, at this point, to identify and mark periods of silence for later deletion from the transmission bitstream. VoIP systems frequently save bandwidth (up to 40%, all other things being equal) simply by not transmitting any data when a speaker isn't talking. The technique -- called 'silence suppression' -- is made tolerable to the listener by sampling and regenerating normal background noise locally, at the far end of the call, a strategy called 'comfort noise regeneration.'

Another important pre-processing step may involve identifying tone-based inband signals (e.g., DTMF/MF or "touchtones") in the input stream (or capturing keypresses on the endpoint device), and replacing these with short codes for out-of-band transmission (and far-end regeneration). This saves bandwidth while insuring that legacy signals are transmitted reliably across the IP network (which -- in a hybrid network -- may constitute only part of the end-to-end call path).

The pre-processed input signal is then divided into speech frames (short chunks) and encoded -- transformed mathematically into a sequence of packet payloads, with optional compression. VoIP codecs (COder/DECoder) come in various standard and proprietary flavors, engineered for different bitrates and overall connection conditions. Where network availability is highly variable, VoIP endpoint devices can renegotiate which codec to use in mid-call, though such renegotiation is always obvious to call participants.

In the past (and still today, in special cases), VoIP solutions tended to emphasize compression, positing VoIP as a solution for multiline telephony across bandwidth-impoverished network segments and access loops. For example, the ITU G.729a codec uses only 8kbps of bandwidth; and more advanced codecs can communicate intelligible speech at rates down to about 5.3kbps for G.723.1 (imagine a single T-1 carrying 173 simultaneous conversations, instead of the standard 24). Extreme compression, however, adds latency (called 'algorithm delay') which must be endured by listeners, or offset by increased processing power, adding a cost premium to VoIP equipment.

The advent of broadband and standard 100BaseT Ethernet, moreover, has made compression less of an issue in many VoIP implementations. So today, the focus has shifted: most VoIP calls employ a standard G.711 codec, which requires 64kbps of bandwidth, but incurs almost no algorithm delay. In fact, where bandwidth is lavishly available, VoIP engineers are figuring out ways to use even more of it, providing a high-fidelity audio experience. The VoIP codec maker, GIPS, uses broad-spectrum digitization -- their codec is used by the Skype peer-to-peer VoIP client, among many others; PolyCom, a maker of high-end VoIP-based audioconferencing gear, is also experimenting with "high-fi telephony." DiamondWare, another maker of VoIP audioconferencing software, uses multiple microphones and input signal-processing to achieve stereo-imaging and 'heliophonic' effects (where the audio signal conveys the position of the speaker in a virtual '3D' space).

The audio-digitizing, signal processing and coding/decoding required for VoIP can be performed cost-effectively in several ways, depending on context. Today's wireline and wireless IP telephones employ monolithic "system on chip" components, capable of A/D conversion, signal processing, encoding, TCP/IP communications, keypad and display management, and sometimes system power management as well. Manufacturers of high-density VoIP gateways, which translate conventional analog or digital phone calls into VoIP packets and associated signaling and vice-versa, tend to use powerful, multi-core DSPs (digital signal processors) - putting dozens of these on a single cPCI board (Compact PCI - a PC board standard supporting "hot swap" for easy maintenance and reduced downtime) and managing 672 or more VoIP calls in a single chassis slot - thousands of calls on a single 6U rackmount system (or tens of thousands, when chassis are linked by "packet backplanes" like StarFabric and InfiniBand).

Today's standard PC CPUs (Pentium 66MHz or better) and the ARM RISC CPUs used in Blackberrys and WindowsCE palmtops can also muster up the horsepower to manage VoIP when computers are linked to wired or wireless LANs. This has encouraged programmers to create a plethora of "software only" VoIP solutions - "VoIP softphones" - some of which extend the functionality of other applications, such as Instant Messaging. Both Windows Messenger and AOL Instant Messaging (AIM) offer VoIP calling functionality. The free, proprietary, peer-to-peer VoIP client, Skype, offers a similar blend of IM and VoIP capabilities.

How IP VPNs Work

TCP/IP, the underlying now the dominant protocol in use on enterprise and institutional local-area networks and the standard protocol for Internet communications, offers a more efficient way of building "any-to- any" WANs. IP's dominance, ubiquity, and the non-proprietary nature of TCP/IP standards offers many benefits - lower hardware prices, a plethora of endpoint types, and open standards among them.

In a pure IP network, packets are routed or switched towards their destinations across a dynamic, largely self-configuring mesh of network elements and connections, permitting "any-to-any" connectivity. This "any-to-any" benefit is underutilized when TCP/IP traffic is carried over legacy WAN architectures, since these physical (or in the case of frame relay and ATM, virtual) connections must still be provisioned and maintained, and since additional effort and configuration may also be required to adjust TCP/IP packet addresses for transport.

You can also build WANs using TCP/IP alone. Though people have accomplished this using leased lines - for example, using TCP/IP to provide logical any-to-any connectivity across a hub-and-spoke leased-line WAN - it makes more sense to do so over a heavily-meshed, shared network. The Internet itself, of course, is such a network. But using the Internet as a WAN means overcoming significant security and performance issues.

Since the late 1990s, carriers have offered "managed IP network" services as an alternative to frame relay and raw Internet connectivity. The first generation of such services were just big private TCP/IP LANs, to which customers could connect at multiple locations. The shared, managed LAN would route TCP/IP traffic between locations, just as the Internet does - though with somewhat greater privacy and better performance.

Still, security remained a persistent worry for customers. And the performance of these carrier IP networks was still too variable for applications like VoIP, unless the network was both over-provisioned (way more bandwidth than required by peak traffic loads) and under-utilized (very few customers).

Strong encryption - using mathematical transformations to disguise data - offered means for solving the security issue, and creating the first real IP carrier networks that were both virtual and private. Early encryption solutions and standards focused on hiding packet contents. Subsequent solutions, called "tunneling encryption," obscure both packet contents and headers, so if data in transit is seen by others, nobody can read it, and nobody knows where it came from or is going to.

Using tunneling encryption applied with premise equipment, a customer can build a secure IP WAN across a carrier IP network, or across the Internet at large. Buying and managing this equipment is still costly, however. The equipment at each location must be provisioned with a table of IP addresses for all locations. And taken together, these costs and complexities make premise-based VPNs hard to scale. The encryption process also adds latency, which tends to degrade the performance of VoIP and IP video. In general, premise-based IP VPN is an appropriate solution only for smaller businesses with knowledgeable IT staffs, and fairly limited application requirements.

Why Would a Business Want an IP VPN?

• To achieve global, "'any-to-any" IP connectivity.
• To provide a migration path to convergence by connecting enterprise locations with an IP wide-area network capable of carrying voice, video and data over a single connection.
• To securely extend the reach of centralized, IP-based "intranet" applications to diverse locations and remote endpoints.
• To enable secure remote access.
• To build "IP extranets" - connecting customers and partners securely to internal resources, over shared carrier infrastructure.
• To simplify a legacy WAN, collapsing multiple service provider contracts and diverse WAN technologies onto a single, IP-based platform from one global vendor, enabling lower costs and easier, more centralized WAN management.
• Ultimately, to get more value for their network spend.

Introducing MPLS

Back in the late 1990s, service providers began looking for a better solution for building secure IP VPNs with predictable quality of service. They'd already built a first-generation multi-service network around a protocol called ATM (Asynchronous Transfer Mode) - a cell-switching protocol with virtual-circuit capability, similar to frame relay. But ATM can be inefficient to provision and maintain, and cannot serve connections with bandwidth greater than DS3, making it inefficient for the highest-capacity sections of backbone, and for some applications.

They found a better solution in MPLS - Multi-Protocol Label Switching - at that time still a very new and fast-evolving system for building high-speed, multiservice networks. By itself, MPLS offered means to support pre-provisioned routes across the network - virtual circuits called Label-Switched Paths or LSPs - and means to support multiple classes of service with different forwarding and drop priorities (i.e., Will this packet be forwarded ahead of other packets of lower CoS, when it arrives on a queue? Will it be dropped if congestion is encountered?). These were the basic capabilities required to build converged, fully-meshed, secure VPNs capable of transporting VoIP and IP video, along with other kinds of data.

Legacy WAN Technologies

In the past carriers have offered many technologies for building wide-area networks (WANs). These included:

• Leased point-to-point circuits (e.g., leased T1), which must be individually provisioned and configured by the carrier. In a multi-site WAN built on such technology, "any-to-any" connectivity is achieved by provisioning multiple point-to-point circuits, connecting each location to all other endpoints. Equipment at each location must direct network traffic along these multiple physical connections as required. Total cost of ownership for such a network is high, premise equipment and carrier 'demarc' hardware is complex, expensive, and difficult to maintain.
• Frame Relay, a legacy packet-switched WAN standard. In an FR WAN, a single physical connection serves each location, terminating on a specially-equipped router or FRAD (Frame Relay Access Device). Multiple logical connections - called Virtual Circuits (VCs) are then provisioned by the carrier to link each endpoint with all other endpoints; premise equipment must also be specially configured to access these VCs. Frame Relay is a distinct improvement over private lines, but FR networks still tend to be complex (all those virtual circuits to maintain), relatively expensive, and hard to manage.

Adding conventional TDM voice or video to a legacy WAN - while possible - is difficult and expensive, requiring additional point-to-point channel or virtual-circuit configuration, plus possible upgrades to premise WAN equipment (to allow telephone equipment hookup). It's also possible to add voice over Internet protocol (VoIP) to a legacy WAN; but this, too, may require additional premise hardware for voice-packet prioritization and configuration changes to reserve bandwidth (as well as changes to each LAN, enabling support of real-time traffic).

Today, as these legacy WAN technologies begin being superseded by IP VPN still supports them at network edges in order to permit customers to migrate at their own pace. For example, customers with an existing, stable frame relay network can use frame relay to access an IP VPN on our MPLS backbone, without major disruption to their FR/ATM network.