Prioritizing VoIP Traffic: Can You Hear Me Now?

Protect your voice over IP investment by implementing VLAN and QoS standards to ensure calls come through loud and clear.

June 2, 2006

12 Min Read
Network Computing logo

VoIP--or Voice over IP--provides a host of benefits, including automatic call forwarding; integration with e-mail, IM and videoconferencing; and presence capabilities to help employees find one another. VoIP systems can also simplify provisioning--just give the user a VoIP phone and a network jack. This is especially useful for enterprises with mobile workers, or those that need to quickly provision new employees or move people to new floors or buildings.

 

 

But none of those advantages will mean much if your network can't provide sufficient VoIP call quality. VoIP calls are extremely susceptible to delayed and lost packets, and can't tolerate network congestion. And because VoIP calls are real-time, there's no second chance to retransmit packets.


• The All IP Enterprise

• 10GigE: Fast, Pricey and Coming to a Data Center Near You

• IP-PBXs Come Into Their Own

• iSCSI Takes on Fibre Channel for the All-IP Enterprise

• Prioritizing VoIP Traffic

We'll look at the business case for deploying (or not) VoIP in your enterprise, and in "IP PBXs Come Into Their Own," we'll discuss the state of IP PBXs. We'll also look at ways to enable traffic prioritization capabilities in your network infrastructure. On the LAN, that means VLANs and switch-based QoS, as well as DiffServ on routers. You should also understand the basic requirements for measuring VoIP call quality, so you can monitor your system and respond when things go wrong. Follow these steps to ensure that your users can hear-and be heard.

The Business Case For VoIP

Certainly, VoIP makes a lot of sense for Cisco Systems, Avaya, Nortel Networks and the other equipment vendors that will earn billions of dollars from enterprises switching to IP PBXs and VoIP phones and investing in new networking gear. A more difficult question is, "Does it make sense for you?"

Vendors used to push VoIP as a way to cut phone bills. Rather than pay for long-distance calls, you could run VoIP on your data network. However, the decline in long-distance prices make that argument less compelling.

These days, there are two good drivers for deploying VoIP. The first is increased ease of deployment and provisioning, particularly for enterprises with multiple branch or remote offices. Such is the case for Gregg Davis, senior VP and CIO of Webcor Builders, a construction company based in San Mateo, Calif. Webcor regularly sets up offices at multiple construction sites--currently, it has 31.Where a traditional phone line might take weeks to come online at a job site, Davis says an Internet connection is available in days. "We just hand employees a [VoIP] handset and say, 'Here's your phone and computer, plug it in anywhere you have Internet access.'"

VoIP also makes more sense than cell phones for employees at building sites because it provides PBX features, such as four-digit dialing and interoffice transfers. In addition, cell coverage is often spotty at remote sites; Davis says he finds Internet access more dependable.

Michel Labelle, network manager of TSI (Terminal Systems Inc.), a port management company based in Vancouver, British Columbia, also cites provisioning as a key driver. The company is adding new employees and moving others between a pair of office buildings. Adds, moves and changes with a TDM network were cumbersome.

"With VoIP, they simply log in to the phone to get access," Labelle says. Phone service provisioning has dropped from an hour per user to minutes or seconds, a significant time saver for the IT staff.

Come Together

The second argument is that VoIP will play an integral role in a unified messaging system. Users have a variety of communication mechanisms at their fingertips--e-mail, land-line phone, cell phone and IM. The problem is, these systems aren't interconnected, so users are forced to hunt down their coworkers across multiple channels, a process that can be both frustrating and inefficient.

VoIP offers a tighter integration of communication systems. Many VoIP vendors include an IM client, videoconferencing, and presence, which allows workers to check the availability and locations of coworkers. Other features, such as the ability to forward a VoIP call to a cell phone or home phone, and to leave voicemail in an e-mail inbox, also promise to streamline communications.

A Bad Call?

Now that we've sold you on VoIP, allow us to play devil's advocate. As your CFO will likely point out, a VoIP rollout is expensive: In a recent Network Computing reader survey, 26 percent of respondents cited cost as the major roadblock to implementation. If your current PBX is still providing acceptable service, a wholesale replacement will be hard to justify, especially if the main driver is convergence, which sounds good on paper but has a difficult-to-quantify ROI.

Aside from the VoIP equipment, you may also incur the added cost of upgrading your network. First, you need to ensure that your switches can support VLAN and QoS (quality of service) standards. Those that can't will require a software upgrade, at a minimum.You also have to ensure that your network architecture is sufficiently provisioned. When TSI decided to move to VoIP, Labelle ripped and replaced the existing switch architecture. He upgraded to Gigabit Ethernet to the desktop. The new switches also support Power over Ethernet (PoE), which Labelle uses to supply electricity to VoIP handsets. Webcor's Davis also upgraded his infrastructure, with GigE to the desktop and 10GigE on core switches.

You can hedge your bets somewhat through a phased deployment of VoIP. Some vendors, such as Avaya, can support both VoIP and TDM phones on the same PBX.

QoS at Layer 2: Mind Your Ps & Qs

If you're running 10GigE in the data center and GigE to the desktop, you're well provisioned for VoIP. A 10GigE backbone should be able to support more than 100,000 simultaneous VoIP calls, depending on the codec used. Of course, a GigE network isn't required for VoIP; 100-Mbps access switches are also sufficient.

But wise architects don't rely on bandwidth alone to ensure that VoIP calls travel smoothly across the network. VoIP traffic must get priority treatment as packets pass through switching queues, which means setting up standards-based VLANs and QoS.802.1Q is the IEEE standard for creating VLANs. A companion standard, 802.1p, tags high-priority traffic at Layer 2 to move it to the front of the switch's queue. The 802.1p standard requires 802.1Q VLANs to be implemented before you can prioritize traffic. We'll look at both of these standards and how they can help limit disruptions to VoIP calls.


802.1p Priority Traffic Types
Click to enlarge in another window

802.1Q defines a VLAN tag that is appended to an Ethernet MAC frame. A VLAN is a virtual subnet that creates smaller broadcast domains within a larger switching architecture to ensure efficient use of bandwidth. Separate voice and data VLANs can also help protect VoIP traffic from service disruption by virus or worm activity on the network.

Inside the 802.1Q VLAN tag is a prioritization field. The 802.1p standard defines the priority levels that can be set inside this field. A packet marked as a higher-priority traffic type moves faster through the switch's buffer than packets marked as lower-priority or default traffic.

Priority levels range from 0 to 7. Zero is set by default and specifies a best-effort service, while 7 is the highest value and can be applied to network-critical traffic such as network control commands (see the chart, "802.1p Priority Traffic Types" at left ). The standard notes that Level 6 is sufficient for IP telephony, but if you have only two levels of prioritization--that is, voice and everything else--you can set VoIP traffic at any level from 1 to 7, as long as it's higher than "everything else."Note that the p and Q standards have been implemented in vendor switches for years. Also, the 802.1p standard has also been merged into the IEEE 802.1D standard.

Layer 3: Are You Being Served?

Any QoS settings you make on a Layer 2 Ethernet switch may be lost when the packets move to a Layer 3 router. To preserve QoS for voice on routers, you must implement DiffServ. DiffServ, or Differentiated Services, creates CoS (class of service) categories. Packets marked with a specific CoS will receive the appropriate QoS.

DiffServ is an IETF standard. A six-bit marker, called the DSCP (DiffServ Code Point) is applied inside the Type of Service (ToS) field in the IPv4 header (or the Traffic Class Octet in IPv6). The DSCP controls the PHB (Per Hop Behavior) of intermediate network devices. DiffServ-enabled devices will treat each packet according to its priority setting. The Expedited Forwarding PHB is recommended for applications that require low delay, low jitter, and very low packet loss--in other words, VoIP traffic.

Other important classes include AF (Assured Forwarding), which lets network architects classify applications as Gold, Silver and Bronze and then apportion a percentage of bandwidth for each class. For instance, Gold applications would share 50 percent of available bandwidth, Silver 30 percent, and so on. AF includes a mechanism to designate whether some packets should be dropped before others in case of congestion. DiffServ also specifies a default classification in which packets get best-effort treatment.

Post-deployment Monitoring

VoIP may be cooler than the "plain old telephone system," but the fact is that VoIP technology still aspires to deliver call quality on par with POTS. And while 802.1Q/p and DiffServ traffic prioritization can provide a measure of assurance that VoIP calls will be of tolerable quality, you still need to measure VoIP traffic to monitor internal service-level goals, identify potential trouble spots and respond to end-user complaints.

Traditional network monitoring and management systems from vendors such as Micromuse, NetIQ and Concord Communications are slowly integrating VoIP call quality capabilities. Meanwhile, a newer crop of vendors such as Brix Networks, Qovia and Clarus Systems sell VoIP-specific testing and monitoring equipment. Some VoIP phones and gateways can also generate operational statistics that can be correlated to call quality or used to identify poorly performing systems.

To successfully evaluate QoS, it's important to understand how metrics devised for circuit-switched networks are being applied to the world of packets. The gold standard for voice conversations in the telephony industry is "toll quality." In the POTS world, call quality is measured by a Mean Opinion Score (MOS), which has a range of 1 to 5. A score of 4.0 is toll quality.

MOSs used to be calculated by trained listeners who would rate speech samples played over a phone line, a subjective test. The International Telecommunications Union (ITU), the governing body for telephony standards that oversees the rules for MOS testing, has also created the P.862 test--or the Perceptual Evaluation of Speech Quality (PESQ). PESQ is an objective test that doesn't rely on humans. Instead, a sound file is sent from one point to another, then the original file is compared with the received file. The PESQ test, though not 100 percent equivalent to MOS ratings, is often used in its place.PESQ is known as an active, or intrusive, test because it pushes a test signal through a communications path. A passive test that measures the distortions in wave forms of actual VoIP calls is defined in the ITU P.563. This passive test can also be correlated to MOS ratings. However, P.563 isn't as accurate as PESQ, is computationally intensive and is more often used by carriers or very large enterprises.

Note that PESQ tests distortion. It's not meant to test the effects of delay (the lag time between sequential packets) or echo (in which the caller can hear herself on the other person's receiver). These parameters are measured using the E-Model, which is defined in the ITU's G.107 standard. The E-Model rates the conversational quality of a transmission with a metric called the R-factor, which can then be converted into an approximation of an MOS rating. The E-Model measures delay, echo and distortion caused by codecs. Proprietary vendor extensions have also been added for other VoIP-specific issues. However, because it was originally created for designing networks and not for measuring call quality, E-Model is less accurate than P.563.

VoIP-specific testing parameters are essential because traditional network measurements are often too blunt to detect problems. For instance, a typical five-minute polling interval using SNMP may miss a problem that erupts for a few crucial seconds. In addition, quality monitoring must also account for the delay introduced by the codec and jitter buffer used in the VoIP phone itself.

Tools that make use of all of these tests are staples of the telecommunications world, but are just now becoming widely available in the VoIP realm. Two companies, Psytechnics and Telchemy, have created technology for VoIP call quality testing that center around PESQ and the E-Model. The technology is embedded in third-party VoIP gateways, IP phones, VoIP chipsets and network management systems. For instance, Nortel Networks uses Telchemy software in its VoIP phones, and Micromuse licenses technology from Psytechnics.

The ITU isn't the only standards game in town for VoIP call-quality measurements, however. The IETF has created a standard to help define exactly what parameters should be captured for VoIP call-quality metrics, as VoIP adoption grows.The standard--the RTP Control Protocol Extended Reports (RTCP XR, RFC 3611)--collects and reports on 20 metrics from the data network and for voice quality, including MOS ratings, noise level, signal level and echo. It also reports on packet loss, roundtrip packet delay, delay caused by individual codecs and jitter buffer statistics. Telchemy is a strong proponent of RTCP XR, and Psytechnics has also endorsed the standard. Nortel Networks' Enterprise Network Management System uses RTCP XR, but other major VoIP vendors have yet to adopt it.

Andrew Conry-Murray is Network Computing's business editor. Write to him at acmurray@ nwc.com.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights