FRAMINGHAM (04/18/2000) - All right, all you frame relay users who have been sneaking voice traffic onto the network. It's safe to come out now and show your faces - the carriers know you're doing it. Here in 2000, some of them will even help you at it. Your challenge, now that voice over frame relay is well established, is to know where the carrier's help is needed and where it's not.
Some experts say the appearance of "priority" permanent virtual circuits (PVC), which provide a red-carpet ride for voice across the frame relay net, is just a marketing gimmick that defeats the whole purpose of interweaving voice and data traffic.
Others say your choice should simply be to configure your own voice-enabled routers with the latest frame relay traffic-shaping techniques or turn over the whole job to your carrier if it offers a fully managed voice-over-frame service.
In either case, the bigger question will be what happens when your WAN is no longer all frame relay. Whether you introduce ATM to your heavier traffic sites via frame relay-to-ATM interworking or move toward an IP virtual private network, you will encounter new complications for voice traffic that standards committees are only beginning to address.
There's little question that voice over frame is one of the most popular starting points to convergence, at least for intracompany calls. Eric Larson, business development director in Motorola Inc.'s Internet and Networking Solutions unit in Mansfield, Massachusetts, estimates that up to 70 percent of his company's Vanguard frame relay routing devices ship with voice support.
In a way, voice over frame relay is like voice over ATM, but with less overhead. Frame relay is a lean, variable-length protocol that can produce long datagrams - 1,500 bytes or more, compared with ATM's standard 53 in every cell.
But voice requires a continuous flow of packets, so all frame relay access devices tend to assemble the frame relay voice traffic in small, even-size packets even while the data frames continue to vary in length. "The voice frames are very consistent. They look like ATM traffic," Larson says.
That's only half the battle, though. If a voice frame gets stuck behind an unusually long data frame on a relatively slow network link, it could introduce too much delay into the phone call. To deal with the problem, the Frame Relay Forum ratified implementation agreement FRF.12 - frame relay's 2-year-old "fragmentation" standard, which vendors are increasingly using for any device they label multiservice.
Under the process, voice and data frames are chopped into smaller fragments - the standard doesn't define a specific size - and a two-octet fragmentation header is added that includes a 12-binary-digit sequence number. The particular sequence number has little inherent meaning because it can roll over back to zero once it hits 12 "ones." But the fragments must arrive in order - including those originating from different frames because the sequence numbers wrap across frames - or the transmission will start dropping packets.
On a T-1 or greater frame relay link, fragmentation may not matter much, since there could be bandwidth to spare. But the point of voice over frame is often to take a branch location with a 56K or 128K-bps frame relay connection to push voice traffic across its excess capacity. In that case, users - or the carrier in a managed service - not only have to get data and voice fragments down to a realistic size, but also check the frame relay network parameters.
Many data-only frame relay users pay little attention to the reserved bandwidth on their links, called committed information rate, because they know they can burst up to the port speed. Voice changes that, experts agree, because "you want the data to burst around the voice," Larson says. How do you set committed information rate for voice? The key number is often 10K-bps times the number of simultaneous phone calls on a link. That's because the original voice-over-frame standard, FRF.11, mapped ITU G.729 - a standard for 8K-bps voice compression - onto frame relay. And the frame relay and fragmentation overhead means it will take a little more to push the voice across the network.
On a private implementation of voice over frame relay, you could try the even more efficient G.723 standard, which provides voice down to 5.3K-bps and is often used for voice over IP. But its use is not part of the voice-over-frame standard. Regardless of what voice compression you use, "120 percent of the compression rate is what it's going to take," says Tom Jenkins, a director of consulting at TeleChoice, a telecommunications research firm in Tulsa, Okla.
Instead of engaging in such fine calculations, carriers have often approached this challenge by simply offering customers separate PVCs for their voice traffic - or for that matter, SNA or other types of delay-sensitive traffic - but some experts look down their noses at this. "If you make sure the [customer premises] equipment prioritizes the voice, then the network prioritization shouldn't be needed," Jenkins says.
And if it's the customer premises equipment that's key, some carriers will offer to manage that. AT&T earlier this year announced a managed voice and data over frame relay service using Motorola gear. International carrier Equant offers a similar service internationally, called Integrated Voice and Data, using Cisco equipment.
But at the same time, many carriers are recommending that when users start maxing out their frame relay connections at data centers and other heavy-traffic sites, they go to ATM interfaces to the carrier network there and use frame relay-to-ATM interworking to create a single network.
The problem: The frame relay standard that accomplishes this interworking - FRF.8 - was drawn up for a data-only world. It only maps frame relay circuits to one of ATM's five classes of service and not the ones that were natively suited for voice traffic. That doesn't mean you can't send voice over ATM's variable bit rate nonreal-time class of service, but the carriers probably won't guarantee the results.
Some equipment vendors have workarounds. In Motorola's case, a tunnel is created through the ATM cloud for the voice traffic. That way you lose some routing efficiencies, but the traffic gets safely through, Larson says. In addition, Lori Dreher, president of the Frame Relay Forum, confirmed to Network World that the forum's technical committee has begun work on an extension to FRF.8 that would map frame circuits to more ATM service classes.