Once a product or technology is labeled "mature," that usually means its days are numbered. Typically, it's just a matter of time until something newer, faster and better relegates it to the scrap heap. But in the case of frame relay, that may not be so. Even though service providers are looking to phase out the data transmission service, according to David Hold, senior analyst of network services at Sterling, Va.-based research firm Current Analysis Inc., that doesn't mean your company should. Hold offers advice about when frame relay is a good option and when it's wise to migrate to an IP-based network service.
If you had to use one word to describe the frame relay market, what would it be and why?
David Hold: Mature … or declining. It's been around since the early '90s; there's little technical innovation and all the standards work that was meant to be done has been done. There's a certain amount of quality of service and they've added the ability to multiplex multiple lower speed circuits to create a higher speed circuit, which is called multilink. So it's basically a commodity service these days.
Many have said frame relay's days are numbered, but that may not necessarily be the case, right?
Hold: Well, one thing we know is that per-port prices are continuing to fall. How much or how fast prices come down will vary widely on the type of customer. The larger enterprise customers are
Will current and future pricing trends make frame relay a superior value?
Hold: In some ways, yes. One advantage that IP VPNs have had over frame relay is cost. They do tend to be more efficient for locations that have large numbers of endpoints, but as frame relay gets cheaper, it becomes a half dozen of one or six of the other.
So if you're an enterprise and have a large frame relay network that's stable and doesn't cost much to operate, why would you want to migrate? Usually there are two reasons: Your carrier wants you to get off of it, so they can turn the service off, which is something we're starting to hear from carriers, or there's a compelling app like VoIP that would give you an impetus to make a switch.
Today, how does frame relay stack up with asynchronous transfer mode (ATM)?
Hold: Frame and ATM go hand in hand. ATM is by far the more capable of the two, specifically in regard to providing high QoS to real-time, delay-sensitive applications. If you want to emulate a TDM [time-division multiplexing] circuit, ATM is probably the most reliable way of doing that.
On the other hand, frame relay is more efficient for carrying data packets. You have variable length frames to put IP data or Ethernet data, so you don't get the overhead you get with ATM, where variable length data packets have to be chopped up to fit into the 48 byte payload of a 53 byte cell. So if you have 64 bytes, most of your second cell is going to be empty and your efficiency is going right down the drain.
In what specific ways are IP-based services superior?
Hold: The big thing is they are connectionless as opposed to being connection-oriented. With frame relay—and with ATM, too—you have permanent virtual circuits from one point to every other point. With IP, you don't have to do that; you just put in the IP address and send. Does that matter? In a network with just a few endpoints, it doesn't matter, but with larger numbers of endpoints, you get a scalability issue. So it's a matter of scalability and cost, and each has a charge associated with it.
So how can an organization determine when maintaining a large frame relay network with numerous PVCs doesn't make sense?
Hold: It depends how many PVCs you need to connect every point to every other point in a full mesh configuration. If you have three endpoints, you only need three circuits, but as you add endpoints, that number grows quite rapidly. So what you end up with is this mass of circuits that you have to configure and manage, and it becomes inefficient because you have to pay for each one and for the management [[cost factor??]], which is why PVC networks aren't scalable.
While frame relay is best suited to centralize hub-and-spoke architectures, it was originally based on the X.25 packet-switching technology for transmitting analog voice data. Are there situations where it's OK for run voice over frame relay, as opposed to VoIP?
Hold: You can do voice over frame relay. People do it, and it works. It just works better over IP. I recently talked to a large enterprise that put their VoIP traffic over the frame relay backbone. They said it worked, but it took them two months to do all the quality tweaking. When they eventually migrated to an IP VPN based on Multiprotocol Label Switching (MPLS), the cost savings were a 50% reduction from the PVC charges, and it worked a lot better.
So based on the emergence of VoIP and network convergence initiatives, how much life does frame relay have, and how soon should enterprises look to move away from it?
Hold: People have been predicting the demise of frame relay since the late '90s. It has taken years before people became comfortable, at least on the network services side, of doing IP VPNs. Most IP VPNs rely on customer premise equipment, and those are a no-brainer. But the network services where the carrier is doing all the work, those have been slow to take off. We're starting to see some migration, and that's fueled by VoIP.
But given the size of the frame relay market, which is probably in the $10 billion to $12 billion range, it's going to take a long time for that to go away completely. Carriers are going to see decreasing revenues, so as prices come down, the margins will come down. There are a few carriers already announcing to customers that they are putting an end-of-line on legacy frame relay and ATM networks, and that will speed up migrations, but there will always be carriers willing to keep networks in operation as long as people want them.