October 1999

VoFR VS. VoIP: Know The Good And The Bad,  Avoid The Ugly

BY JOE MANGIOCAVALLO

Converging your data and voice network over a common infrastructure is now a pretty familiar goal. The real conundrum today is which technology will achieve the most savings and bandwidth optimization. On the table are two key technologies in the data and voice convergence market: Frame Relay (FR) and Internet Protocol (IP). So, how does an enterprise customer decide?

Network managers must first recognize the differences between Voice over Frame Relay (VoFR) and Voice over IP (VoIP) and, when converging data and voice over either technology, they should examine the packet overhead, packet prioritization, topologies, and costs.

PACKET OVERHEAD — THE LOWER, THE BETTER
Frame Relay and IP packets have similar constructions, each containing a header and a payload of digitized, compressed voice/fax information. Currently, FR telephony packets clearly consume less bandwidth in Kbps than IP (see sidebar) which is handicapped by a larger packet overhead.

IP’s 7 Kbps packet overhead is actually an estimate and it can reach as high as 9 Kbps when the IP packet is encapsulated by another protocol, such as Frame Relay’s RFC 1490. IP overhead may also peak at 9 Kbps in a LAN environment with Ethernet or Token Ring encapsulation, even though LAN bandwidth consumption is often insignificant.

For voice/data integration to work well over corporate networks, jitter and latency must be less than 200 ms. Low latency can be achieved by voice/fax packet prioritization, and is realized differently for IP than it is for FR.

To prioritize voice/fax IP packets, there are two possible techniques. One method is for a network administrator to specifically program the router to look for the VoIP gateway’s “well known UDP port number,” a reserved port number registered by the gateway manufacturer for exclusive worldwide use. A second approach is to use a prioritization protocol that is understood by both router and gateway. An example is RSVP, a new prioritization standard that certain router vendors now selectively include in their operating software.

With Frame Relay, voice/fax packets are automatically prioritized ahead of data packets in the voice-enabled FRAD without any user setup. Some FR implementations can even prioritize at different levels within a multitude of active voice/fax trunks, whereas IP usually has only one priority level. Although the effects of prioritization are the same with FR and IP, FR has the edge in ease of manageability and multi-level prioritization.

COMPARE COSTS
Network topologies for FR and IP are fundamentally different — FR is connection-oriented, while IP is connectionless. A customer using FR will pay for a WAN access line (cost dependent on bandwidth and distance), the port into the service (price dependent on the access line’s bandwidth), and for each PVC between each Remote Frame Relay Access Device (RFRAD).

The WAN access line from the RFRAD to the FR service can carry multiple PVCs, and in many cases there can be several PVCs from one RFRAD to another or to a multitude of RFRADs. Costs will skyrocket when networks with fully meshed PVCs increase in size (each site is connected to every other site with at least one PVC). For example: a fully meshed 10-site network has only 45 PVCs, a 100-site network contains 4950 PVCs, and a 1000-site network a whopping 4,999,500 PVCs.

In an IP network, routers and level-3 switches determine which subsequent router will receive each IP packet, based on the packet’s header information and available bandwidth. However, IP frames characteristically take a different route each time they are sent from the same source to the same destination, and may even arrive out of order before being corrected by the router. Conversely, FR frames in a PVC will travel the same route in a Frame Relay network.

The advantage of voice over IP is that it avoids the Virtual Channel (VC) concept and associated meshing costs. The price, though, is its potential for higher jitter from variable routing paths, especially on the Internet where the variations in packet routes are nearly unlimited. Fortunately for most corporate IP WAN networks, variable routing does not appreciably add to the jitter since they are not bandwidth constrained and similar direct routes are often available for consecutive packets.

So what matters most to corporate networks is the cost of services and the network topology. For network topologies that are primarily “hub-and-spoke,” the FR PVC count is proportional to the number of branch sites. The PVC count is fairly small in these topologies and public FR service costs less than public IP. Only extensive and fully meshed network topologies, featuring a greater number of FR PVCs, are better off with public IP.

Bear in mind, many of today’s corporate customers operate hub-and-spoke topologies with a normal mix of data and voice, and pay 35-50 percent less for public FR than they would for IP. For predominately voice/fax traffic in hub-and-spoke or point-to-point networks, FR offers an even greater advantage as it requires less WAN bandwidth. IP voice/data networks are only more cost-effective with bigger, more highly meshed networks (around 25-50 remote sites).

SORTING THE STANDARDS
The work to standardize both VoFR and VoIP will continue to be an ongoing process, and keeping a score card on what both the Frame Relay Forum (FRF) and the IMTC VoIP Forum produce is no easy task.

For now, the FRF has two Implementation Agree-ments (IA). The first is FRF.11 which provides for multiplexed PVCs, speech compression using G.726 (ADPCM) and G.729 (8K CS-ACELP), fax de-modulation, and the format for carrying multiple voice samples in single frames. The second IA is FRF.12 which provides for frame segmentation across a Frame Relay network.

The IMTC has recently produced its second VoIP Interoperability Implementation Agreement, IA 2.0. It is based on the ITU H.323 conferencing standard and, while H.323 is in fact a standard, IA 2.0 is only an agreement, a precursor to a standard.

When building pure packet voice/fax networks, three key considerations are: voice quality, bandwidth cost/efficiency, and interface flexibility. Both VoIP and VoFR support excellent voice quality, and product costs for both fall within the $500-$1000 per-channel, per-end range. A typical installation will multiplex approximately 100-200 channels from 8 T1/E1 central office connections onto a single T1/E1 WAN line.

In the end, enterprise customers should investigate these considerations and weigh them against their current and future network requirements, so they may implement converged data and voice networks that are perfectly cost-effective and efficient, whether they be on IP or Frame Relay.

Joe Mangiocavallo is manager, Product Management at Memotec Communications, and is instrumental in repositioning Memotec’s Frame Relay products to emphasize multiprotocol access as well as multiservice applications, while building on voice capabilities. Memotec Communications is a provider of data, voice, and video convergence solutions for telecommunications carriers, ISPs, and corporate customers. For more information, please visit their Web site at www.memotec.com.

The following figures were produced from Bell Labs. To determine peak bandwidth consumed during an active conversation, add the packet overhead with the speech compression codec. Peaks occur only for a few seconds and are replaced by 0 Kbps during natural periods of silence. During a 20-30 second period, silence occurs about 50 percent of the time when one person talks while the other listens. Pauses and interruptions contribute another 10 percent, and the remaining bandwidth consumption averages 40 percent of the peak bandwidth.

[return to the text]

For More Information

• The Frame Relay Forum homepage. Also, check out Frame vs. ATM and Frame/ATM interworking for information.

• Alliance Datacom Frame Relay, ATM, and IP Resource Center.

• http://peter.itsc.state.md.us/ ITSC/techrepts/framerly.html — a good reference on Frame Relay, including an overview of its use in the WAN and how it works in the OSI model.

• Part of the Alliance Datacom site that deals with troubleshooting a Frame Relay network.

• http://cctpwww.cityu.edu.hk/network/l2_framerelay.htm — good site from the University of Hong Kong, includes some newsgroup links as well as other information.

• Motorola’s Frame Relay reference page. Also, check out their FAQ page.

• An interesting tutorial held by Norm Al Dude and Professor N. Erd.

• Some information on Frame Relay for Linux (note that the site is maintained by Linas, not Linus!)