ells of asynchronous transfer mode (ATM), frame relay uses variable-size packets. Thus, it can dynamically adjust size according to the type of traffic.
Early frame-relay services were meant almost exclusively for interconnecting LANs, because that was just about all the first networks were capable of. Doing anything but data meant you were crazy or ignorantly optimistic. In fact, transporting voice traffic over frame-relay networks used to be a huge faux pas. Or, more specifically, in the early days of the market, most people thought that voice over frame relay was "a hu gefa uxp a (clipped s)." Most didn't believe it would work, or at least not very well.
When frame-relay service first became available, only one type of premises equipment could support it: the router. Ro
uters are good at handling data, but they are not geared for handling voice.
A Maturing Process
However, frame relay has matured in the past four years, from both a service offering and an equipment perspective. The average user finds that previous cardinal sins are now on the forgiven list. Carrying time-sensitive traffic is now a serious consideration for many companies. Things such as voice over frame relay and Systems Network Architecture (SNA) over frame relay are quite possible.
What makes voice over frame relay possible is the frame-relay assembler/disassembler (FRAD). They come from such vendors as ACT Networks, Micom Communications, and Motorola. FRADs are the frame-relay counterpart to X.25 packet assembler/disassemblers (PADs) in that they aggregate and convert traffic into frame-relay packets for transmission over a frame-relay network (see the figure
"Getting the Traffic Aboard"
).
A typical frame-relay network uses FRADs or routers in
each of an organization's branch offices or remote sites. The sites can be linked over a private frame-relay network or over a carrier's public frame-relay network (see the figure
"Putting It Together"
). Permanent virtual circuits (PVCs) carry data between two locations.
While the technical obstacles to delivering voice over frame relay may be removed, sometimes it is not possible for a reason that is often harder to overcome: corporate politics. Data purists argue that voice has no business on the data networks, that the networks were not designed for this purpose, and that the whole network will come crashing to the ground if all these "unauthorized" applications start sharing the bandwidth.
To a certain degree, such arguments have merit. Frame-relay networks are not designed to differentiate between applications, specifically the unique needs of one application versus another. For example, they cannot prioritize voice traffic over data, so that voice packets get there so
oner to allow for more natural speech flow. (ATM is designed for this purpose. It will offer carriers substantially more options for integrating voice and data applications on the same network.)
However, frame relay is here today. It's a mature technology that is widely available and extremely affordable. Many users have it installed, and in a flip-flop of network design from the 1970s, voice can ride for free over the data networks with relatively minor adjustments to network configurations.
Sound Business
Voice over frame relay is appropriate for small- to medium-size companies. You can cost-justify the frame-relay network based on the data applications, such as carrying LAN and SNA traffic (see
"Pruning Branch-Office Problems,"
July 1995 BYTE). Voice calls can essentially ride the network for free between locations connected by the frame-relay network. The savings can be tremendous.
Because of the nature of frame-relay networks, voice over frame relay is
best at on-net communications (i.e., connecting sites on the frame-relay network). It is not now suited for calling off-net, although future changes in standards and new frame-relay technologies could make that possible.
Consolidating voice onto a frame-relay network does not make sense for companies with huge voice networks. Fortune 1000 companies, for instance, probably can't justify the additional cost for premises equipment that will handle voice traffic and the cost for bandwidth to support many simultaneous intercompany calls. They are better off using private-line networks and/or virtual-private-network (VPN) services. These offer low cost for high volumes and provide a high level of sophistication.
Bonacker and Leight, a food-brokerage company using an ACT Networks FRAD, consolidated its voice, fax, LAN, and terminal-to-host data traffic over a single frame-relay network. The company reduced its telephone expenses by 35 percent, even after increasing its network bandwidth from 9.6 to 56
Kbps.
Internationally, it is even easier to cost-justify voice over frame. International connections and toll calls are so expensive that even some larger companies may save money by using the frame-relay network to carry international voice traffic.
Banco do Brasil, also an ACT customer, needed connectivity to 26 countries on four continents. Integrating the on-net voice and fax calls into a frame-relay network provided a savings of $4 million a year on the phone bills alone. This savings resulted in a six-month payback on the cost of the WAN.
The incremental cost to add 16 to 32 Kbps of bandwidth -- which on a frame-relay network is called the committed information rate (CIR) -- is typically between $10 and $50 per month, depending on the carrier. The FRADs that support voice over frame relay normally offer options for compression, which means a single conversation will need between 4 and 16 Kbps while in progress.
Getting Down to the Details
Voice traffic tu
rns out to be similar in many respects to data traffic -- both can be described as bursty and intermittent. An individual voice conversation consists of
speech bursts
. There are certain points in a conversation where there is little silence, such as in the middle of a sentence. Speech bursts are separated by short or long periods of silence, such as the pauses between sentences.
When put together, these conversations represent an intermittent traffic stream to the network, at least for smaller companies. At certain times, several long-distance conversations may be occurring simultaneously. At other times, no one will be using the phone for making long-distance calls to other on-net locations.
The important issue that must be resolved to send voice traffic over a frame-relay network is controlling the amount of delay that a packet experiences when traveling across the network. Voice traffic is not as tolerant of delay as data traffic. Most people begin to notice delay when it reaches 100
milliseconds.
Delay can occur in several places within the network. The customer premises equipment, the physical transmission facilities, and the frame-relay switches all add a measure of delay. Delay due to the transmission of the signal is estimated to be 1 ms per 100 circuit miles. The frame-relay network will add between 3 and 10 ms of delay per switch, but this is carrier-dependent and worth asking about when choosing a frame-relay provider. In general, voice transport should not be a problem for domestic networks, but internationally, the transmission delay can become annoyingly noticeable.
Supporting voice traffic on frame relay requires equipment that has the correct interfaces and support for voice-related functions, such as echo cancellation, silence detection and suppression, and fax detection and demodulation.
Voice applications include interconnecting PBXes, use of off-premises extensions (OPXes), private-line auto-ringdowns (PLARs), and connecting to the Public Switched Te
lephone Network (PSTN). The FRAD vendor should support two- and four-wire Ear and Mouth (E&M), Foreign Exchange Office (FXO), and Foreign Exchange Station (FXS) interfaces, as well as standard T1 and digital T1 interfaces.
The FRAD will packetize the voice traffic, prioritize it above the data traffic, and interleave the two traffic streams. Once in the network, the voice and data traffic are treated exactly the same.
The Public vs. Private Debate
On private frame-relay networks, consolidating voice onto frame relay is simple because you already know the key facts that affect performance: the number of switches that a circuit goes through, the circuit mileage, the network topology, and how the equipment handles voice.
Using a public frame-relay network is different because you have more uncertainty. You will need to fine-tune your premises equipment. Public frame-relay networks meet traffic requirements on a first-come, first-served basis. The first-served traffic is
counted toward the CIR, while the remainder is marked discard eligible (DE). If both voice and data are handled within the same PVC, the voice traffic needs to be sent to the network ahead of the data traffic.
Successfully supporting voice traffic on a frame-relay network requires the premises equipment to do at least three things: Segment long data packets to let voice traffic through more quickly, prioritize voice applications before data, and set the DE bit for noncritical data traffic.
If voice and data applications share the same network, and you neglect to do these three items, a voice packet may get "stuck" in a switch queue waiting for a large file or data stream to be transmitted. The frame-relay premises equipment must be able to segment large data frames into smaller frames. But the equipment must be intelligent enough to know to do this only when a voice packet is waiting to be transmitted. In that way, a higher-priority voice packet always gets priority and is transmitted even thoug
h the system might be in the process of transmitting a large file.
Priorities
Voice packets must get priority over data, but without introducing unacceptably long delays in transmitting the data traffic. Network users do not want the data network to slow down whenever someone picks up the phone. Therefore, the premises equipment must have priority buffer queues. High-priority traffic would be assigned to the high-priority buffer and would be transmitted before traffic waiting in the other buffer queues.
For example, imagine a situation linking the branch offices of a bank. Voice traffic shares a line with traditional LAN application file transfers and transaction-oriented SNA traffic. A teller who is updating a customer's account through an SNA session with a host computer in the bank's corporate headquarters should not have to wait a significantly longer time for the transaction to be completed whenever someone makes a phone call to another branch office. Similarly, the SNA
-session traffic -- because of its time-sensitive nature -- should have a higher priority in the frame-relay switch queues over data associated with a large file transfer between sites.
An added layer of sophistication lets the network manager assign minimum throughput levels for lower-priority buffers. Put another way, you must be able to ensure that the lower-priority data cannot be denied access to the network, even when higher-priority traffic is in the queue for transmission. The lower-priority data buffer would still be allowed to send a predefined level of traffic to the network.
Another difference in handling voice versus data is that voice is more tolerant of lost frame-relay packets than data is. In other words, if packets are lost in a data transmission, they must be retransmitted. Most of a voice conversation is actually silence. That means you won't notice if some packets are dropped. And even if the connection drops some packets, there is no time for the network to retransmit -- th
e participants will have to repeat words, if they even noticed the dropped packets.
Exploring Your Options
Frame relay has won many converts in the past year, and the market for frame-relay services is growing at an exponential rate. Many frame-relay users begin small, using it to support one or two applications. The most common uses of frame relay are for LAN and SNA applications. Once companies install a frame-relay network and it proves to be a reliable resource, they frequently begin to consolidate more applications onto it.
Service providers are still uncertain about how a large amount of voice traffic on a public frame-relay network will affect the overall performance of the network. The sensitive nature of voice makes service providers nervous, because frame-relay networks are designed to support more tolerant data applications. The concern is that users could be unhappy with the quality of the application, which could reflect poorly on frame relay.
However, ca
rriers do recognize that voice over frame relay can provide substantial cost savings for some customers. Therefore, carriers are looking for answers to the technical questions about how voice traffic needs to be treated by the frame-relay network and if supporting high levels of voice traffic will necessitate a change in frame-relay-network design.
A handful of equipment vendors already support voice over frame relay. ACT Networks has been a leader in this field. Its integrated FRAD has separate priority queues for voice, fax, and data traffic. Voice features include toll-quality voice compression, variable rates depending on network conditions, and early congestion recognition. The compression method used by ACT supports a voice conversation over an 8-Kbps PVC. ACT's technology has been licensed by StrataCom for use in its FastPAD.
Motorola Information Systems Group recently introduced a VoiceRelay option for its 6520 and 6560 MPRouter Pro, which integrates voice options with an existing router
platform. VoiceRelay also supports 8- or 16-Kbps PVCs using compression techniques, prioritizes voice over other frame-relay packets, and has an on-board echo canceler to filter out near-end echo. Fax support allows integrated fax and voice support on the same port.
Micom has added support for voice and fax over frame relay by enhancing its NetRunner router with voice capabilities. The company has integrated voice, fax, and data compression, and silence suppression support. Micom and other vendors exploit the half-duplex nature of voice communications to squeeze additional bandwidth out of frame-relay links. (Most conversations have only one person talking at a time.)
Currently, no service providers package voice-capable FRADs or routers with frame-relay service. This should change this year as service providers compete to offer more value-added options with frame relay.
Competing with ATM
Adding voice to frame-relay networks blurs the line between frame relay and AT
M. ATM's overhead makes it less efficient than frame relay for many data applications, but frame relay's variable-length frames are not as conducive to voice applications because they are sensitive to delay variation.
ATM's solution is to package all traffic into small, fixed-length cells. Frame relay's solution is to let the data traffic use a variable-length frame for reduced overhead but package the voice traffic into fixed-length cells.
The choice between frame relay and ATM necessitates a look at the entire network, all the applications, the connectivity speeds, and several other factors. For many small- and medium-size companies, a move to ATM will be cost-prohibitive. The value of voice over frame relay is that it lets these companies consolidate voice and data applications onto a single network for better economies of scale and cost savings.
Voice over frame relay will never be a solution for every company, but it is a good solution for many smaller companies with existing investm
ents in frame-relay systems. As more companies gain experience with frame relay, voice applications should be one of the fastest-growing applications for the next two years.
The standards for transporting voice traffic using frame relay have not been finalized. Those equipment vendors that support this option today have done so by using proprietary technology. Most say they will support the standards once they are finalized.
Hundreds of companies are now successfully integrating voice traffic with data traffic over frame relay, and they're saving money by doing so. Regardless of whether the standards are complete or the carriers are ready, the market has cast its vote. Voice over frame relay is here to stay.
WHERE TO FIND
ACT Networks, Inc.
Camarillo, CA
(800) 367-2281
(805) 388-2474
fax: (805) 388-3504
http://www.acti.com
Voice Gets Framed
