The fourth frame relay application we are covering in our series from the Network Consultants Handbook is VoFr -- certain to be a major consideration in your future, if not present. This in-depth study explains all the technical data you need for reference in using this budding implementation, complete with tables and illustrations.
Network Consultants Handbook - Frame Relay
by Matthew Castelli
Voice over Frame Relay (VoFr)
Voice over Frame Relay (VoFr) has been recently enjoying the general acceptance of any efficient and cost-effective technology. In the traditional plain old telephone service (POTS) network, a conventional (with no compression) voice call is encoded, as defined by the ITU pulse code modulation (PCM) standard, and utilizes 64 kbps of bandwidth. Several compression methods have been developed and deployed that reduce the bandwidth required by a voice call down to as little as 4 kbps, thereby allowing more voice calls to be carried over a single Frame Relay serial interface (or subinterface PVC). Table 15-14 demonstrates these different compression algorithms and the bandwidth utilized per algorithm.
Table 15-14: Voice Compression Algorithms with Bandwidth Utilization
||Bit Rate (Bandwidth Required)|
|G.711 PCM (A-Law/U-Law) ||64 kbps (DS0)|
|G.726 ADPCM ||16, 24, 32, 40 kbps|
|G.729 CS-ACELP ||8 kbps|
|G.728 LD-CELP ||16 kbps|
|G.723.1 CELP ||6.3/5.3 kbps variable|
A common concern regarding VoFR is keeping latency and jitter within acceptable limits. This can be a challenge in a network that is built around applications that can tolerate both; however, it is possible to pull a "trick or two" within the network.
One approach is to increase the CIR over each Frame Relay PVC that will carry voice traffic and not mark the voice traffic as DE.
Another approach is to implement separate PVCs for voice and data applications, segregating the traffic prior to transmission from the router.
A third approach is to work with a network service provider that offers PVC of different levels of delay/priority. Some providers offer as many as three PVC levels, or priorities:
- Top priority for delay-sensitive traffic (such as voice and SDLC)
- No (or middle) priority for traffic that can tolerate some level of delay (such as LAN traffic)
- Low priority for applications that can tolerate significant levels of delay (such as Internet access and e-mail)
Voice Coders-Decoders (Codecs)
The issue with packetized voice is the ability of the sending and receiving voice codecs (coders-decoders) to be able to clock against each other to ensure the synchronization of the data flow. Two of the more common Voice over X (VoX) implementations are Voice over Frame Relay (VoFr) and Voice over ATM (VoATM). The reason for ATM's popularity in the VoX arena is that ATM utilizes fixed cell lengths of 53 bytes, enabling the sending and receiving codecs to clock against each other in synchronicity, ensuring the seamless flow of the voice traffic.
Frame Relay frames operate in a similar fashion to ATM (packet-switching versus cell-switching). However, one of the significant differences with regard to voice traffic is that Frame Relay frames are of variable length, up to 4096 bytes, making it difficult for the sending and receiving codecs to clock against each other because the "start" and "stop" flags appear at seemingly random intervals.
Several VoFr, or Voice FRAD (VFRAD), vendors are on the market today, each with its own workaround to the variable frame length issue. Each workaround is similar in that the sending codec limits the payload size of the transmitted frame, usually to 2000 bytes, or 2 kilobytes (KB). By utilizing this fixed length, the sending and receiving codecs can now clock against each other because the receiving codec now knows when the "stop" flag will appear, enabling a more seamless voice conversation.
A direct correlation exists between the quality of voice and the compression algorithm used. This quality is measured with something called the mean opinion score (MOS). Table 15-15 compares these different compression algorithms and their respective MOS.
Table 15-15: Voice Compression Mean Opinion Scores
It is considered efficient to send compressed voice over data circuits, initially over point-to-point leased lines and more recently over Frame Relay. Because of this, it is natural for enterprise users to consider supporting voice service across an existing, or planned, Frame Relay WAN.
Generally, VoFr implementations utilize CIR/DE to prioritize voice over data traffic across the VC. To do this effectively, the proper amount of CIR bandwidth needs to be determined prior to implementation. The formula used to determine this is as follows:
FRLCIR = ((VOXMODULE X MODULEBANDWIDTH) + VOXBUFFER)
VOXBUFFER = ((VOXMODULE X MODULEBANDWIDTH) X 20%)
is the number of VoFr modules; MODULEBANDWIDTH
is the amount of bandwidth per voice module, and VOXBUFFER
is the amount of additional buffer space on the VC for the voice traffic.
For example, assume a FRAD with a 4-port voice module, utilizing G.728 compression (16 kbps). The CIR required to support the VoFr service is determined by the previous formulae:
FRLCIR = ((4 X 16) + 12.8) = 76.8 kbps
VOXBUFFER = ((4 X 16 kbps) 4 20%) = 12.8 kbps
The minimum amount of CIR required to support this configuration is 76.8 kbps. Typically, a network provider provisions CIR in multiples of 16 kbps or 64 kbps; therefore, the minimum CIR to support the voice traffic here would be 80 kbps. This is for voice traffic only; it is reasonable to expect to add incremental CIR to support data traffic requirements as well across the VC.
VoFR, as with all VoX, is subjected to and unforgiving of quality issues, most notably delay and jitter.
Voice over Frame Relay service is enabled by the use of Frame Relay communications devices, such as routers or FRADs, configured with voice modules. These devices are sometimes referred to as Voice FRADs, or VFRADs.
Although VoFR implementations are efficient and cost effective for intra-enterprise or intra-corporate communication, there are considerations, such as quality, to be made regarding the use of packetized voice when dealing with non-Frame Relay WAN, or off-net, users.
Figure 15-26 illustrates how a typical Voice over Frame Relay implementation might look, supporting simultaneously both on-net (VoFr) and off-net (POTS) implementations.
Figure 15-26: On-Net (VoFr) and Off-Net (POTS) Voice Implementation
(Click image for larger view in a new window)
Figure 15-27 illustrates how voice and data can be merged to more effectively utilize WAN resources by the addition of a router to support data communication between enterprise sites.
Figure 15-27: Frame Relay with Voice, Data, and Fax Communications
(Click image for larger view in a new window)
Our next segment from Cisco Press' Network Consultants Handbook will discuss Frame Relay Traffic Shaping.