Frame Relay, ATM, IP, …which one is for you?
Don’t ask that outdated question. Especially, when they can together do wonders for
you. Doubts…? This paper from networking industry leader Cisco, tells you why.
Every few years the networking
vendors’ marketing people revive a concept that has been around since the beginning
of time, or at least the beginning of networks: they lock onto a promising new technology
as the multiservice networking solution.
Ideally, a multiservice network is able to
run applications of differing performance characteristics with a minimum of compromises.
For example, voice requires minimal bandwidth, but is highly delay-sensitive. File
transfers require large amounts of bandwidth, but are relatively delay-insensitive. Said
another way, a multiservice network provides the ability to integrate all of your
applications into a single network, with minimal performance compromises. The idea is that
a single network is cheaper, easier, and more efficient to operate than multiple networks.
What began a number of years ago with Frame
Relay, continued with Asynchronous Transfer Mode (ATM), and now focuses on IP, is the
concept that there is one truly multiservice network technology that will efficiently
operate over low-speed and high-speed lines, transporting voice, video, e-mail, and SNA.
You really can’t blame the marketers; after all, sales people are always looking for
that one "golden bullet" that will seal the deal, and it is the job of marketing
to provide it. But in this case, the golden bullet is more accurately described as the
"golden Swiss army knife". But we’ll get to that.
The problem is that we get stuck on the
"golden bullet" idea. People get caught up in a particular technology and rely
on that favourite to the exclusion of nearly everything else. UNIX programmers are nearly
religious about their particular flavour of operating system (and the same could be said
for the Microsoft NT backers). Apple users have almost a siege mentality against Windows
users. In networking, Ethernet versus Token Ring arguments continue even today, and IP
bigots regularly battle ATM bigots over which technology provides the best integration
hopes. So the idea that there should be a single multiservice network technology is not
surprising, nor is it new.
Let’s take a look at three
technologies that have carried the multiservice title: Frame Relay, ATM, and IP. Each has
its strengths and weaknesses, but each also plays an important role in the multiservice
network.
History of Multiservice Solutions
About seven years ago, Frame Relay came into the market and with it the hype as
the newest data, voice, and video integration technology. Frame Relay was developed in the
early nineties to take advantage of the newer digital networks that were being installed.
These networks had much lower error rates than the analog networks they replaced, and the
thinking was that all of the correction features of X.25 were no longer needed. Most
networking vendors support Frame Relay and nearly every service provider does as well.
As a multiservice networking technology,
Frame Relay has not lived up to the original hype. While a number of vendors have been
successful selling Frame Relay Access Devices (FRADs, which combine nearly any data
application into Frame Relay) and voice-over-Frame Relay solutions, standardization
efforts on critical applications such as voice and fax lagged behind market requirements.
Priority standardization also remains elusive, as does the ability to easily transit
multiple Frame Relay networks seamlessly.
The largest contributor to Frame
Relay’s ability to merge data and voice applications is the recent development of
Service Level Management (SLM) and the next generation of SLM, which includes traffic
shaping. (Traffic shaping is the metering of traffic from the LAN onto the WAN based on
policies or traffic profiles that have been defined.) When SLM systems support voice, we
can expect to see greater gains in Frame Relay multiservice networking. Had these tools
been available five years ago, we might have found the "golden bullet" in Frame
Relay.
its focus to IP, Frame Relay continues to grow at an impressive rate, between 20 - 40
percent a year by most estimates. It’s a low- to high-speed, mature technology that
is simple to deploy and supports basic Quality of Service (QoS).
Relay, combine their strengths and minimize their weaknesses to create a scalable,
interoperable, high-performance network that suits most enterprise networking needs
ATM was the next technology to be
given the mantle of world’s best integration technology. The main benefit of ATM is
that it promises five different classes of service to meet the needs of multiple
application types, including the ability to mimic circuit switching (something Frame Relay
does not do). Each service class defines individual performance characteristics, ranging
from best effort (Unspecified Bit Rate or UBR) to highly controlled, full-time bandwidth
(Constant Bit Rate or CBR).
alt="The multiservice network can be seeen as overlaying layers, with users connecting to the layer that offers them the most appropriate service"
align="right" hspace="4" vspace="4">It is this ability to
discriminate between applications and their respective performance requirements that makes
ATM such a useful multiservice networking technology. In effect, ATM gives us a mini
"golden Swiss army knife" at the core of our network.
ATM benefits from extensive service-level
definitions that are required by a variety of applications. Currently ATM is the only
common transport technology capable of imitating other services such as a full-time Time
Division Multiplexing (TDM) circuit, best-effort Variable Bit Rate (VBR) transport, and
controlled delay/loss services.
But ATM is not the "golden
bullet". A drawback to this technology is the overhead imposed by ATM framing and the
bandwidth that it consumes on lower-speed lines (less than T1/E1). Five bytes of overhead
are used for every 48 bytes of payload (commonly referred to as the "cell tax").
ATM also pads a cell with blank bytes if there is not enough data to fill all 48 bytes.
Very few voice or data applications segment the bit stream into neat 48 byte segments, a
situation that potentially creates additional overhead in the form of the cell padding.
IP is the latest technology to bear the
multiservice title. It is getting harder to avoid all of the hype surrounding IP, even if
you are not associated with the telecom industry. Service providers are touting their
voice-over-IP calling card services, and nearly every vendor has some sort of IP
positioning statement for voice, video, and SNA. Users are inundated with vendors claiming
to have ideal, IP technology-based solutions to the integrated communications problem. In
fact, they may be right. IP is the only technology that is popularly deployed all the way
from the desktop to the WAN core. But an awful lot depends on other choices the user
makes.
The reality of generic IP is that real-time
applications often do not work well because of variable queuing delays, congestion losses,
and the inability to share bandwidth on a particular link between applications with
different performance requirements. IP networks, as originally conceived, offer
"best-effort" QoS. Mission-critical applications, including voice, need much
more.
is the ability of the transport network (probably Frame Relay or ATM) to recognize what
service was required from the applications it is carrying. The usual scheme involved
mapping particular applications manually into specific service levels (DLCIs or a
particular ATM QoS). Current standards efforts rely on the use of IP’s socket
information to identify applications automatically. Policy-based networks should use the
Type-of-Service (ToS) bits (Diff-Serv) to signal desired class of service. An additional
emerging standard, called Multiprotocol Label Switching (MPLS), promises to take IP QoS to
the next step by using labels on each packet to indicate service attributes such as
different service classes that utilize specific queuing schemes.
Solution: The Golden Swiss Army Knife
SNA managers, who frequently carry the weight of their corporation on their
shoulders, have reinforced the idea that there is not one all-encompassing standalone
technology. They are willing to pay the rates for leased-lines (by some estimates, more
than 60 percent of SNA networks are still on leased-lines), as well as operate parallel
networks, in exchange for guaranteed QoS.
In today’s multiservice network,
technology agnosticism provides "the golden Swiss army knife". Sometimes you
need ATM, sometimes Frame Relay, and sometimes, even IP. Each network provides its own
service benefits, as well as cost, feature, and performance compromises. The best solution
today for an integrated network that supports data, voice, and video is, well, an
integrated one. The most successful multiservice networks use a combination of
technologies that have been around for years: ATM at the core, Frame Relay and IP as
low-speed access, and IP performing application integration functions.
Interconnect/LAN Emulation
Transport/Interworking
(IP-Frame Relay-SMDS)
Emulation-PABX
Videoconferencing
Distribution
Multimedia
***Optimum   **Good   *Fair   NS: Not Suitable
  NQ: Not Quoted–Are felt presently not applicable with advantage (might be
applicable in the future)
Source: The ATM Forum
"combination" does not imply "compromise," and settling is not part of
the bargain. These technologies are maturing into valuable role players in the
multiservice network. And while some standards work remains to be done, we can see the
light at the end of the tunnel.
Policy-based networks should use the ToS
bits (Diff-Serv) to signal the ATM or Frame Relay network of the desired class of service.
This linkage between application type and network service is critical to the operation of
multiservice networks. Having this linkage for both Frame Relay and ATM enables network
users to get the most out of multiservice networks, without having to compromise
efficiency or performance.
Using other technologies such as IP or
Frame Relay to aggregate traffic can help to alleviate the partially filled cell problem
and also create greater efficiencies at lower speeds. The strengths of ATM, as well as its
weaknesses, help its position in the multitechnology, multiservice network. The use of
Frame Relay and IP as access to ATM at the core of IP networks supports the
multitechnology, multiservice network proposition.
Put together, these technologies combine
their strengths and minimize their weaknesses to create a scalable, interoperable,
high-performance network that suits most enterprise network needs—and in this
industry, most is not a bad thing. Just as in politics, a majority usually amounts to a
winner.
IP’s Dual Personality
We seem to use confusing terminology when we talk about multiservice networks.
Vendors and service providers are actually doing us a favour by referring to these
networks as IP networks. IP is the technology most visible to the end user, and is really
the technology that gets the ball rolling. IP supports voice, video, SNA, SAP, e-mail,
Web, and most anything else you care to put over it. The rest is just transport—which
may sound simple, but it’s the details that will get you.
Because IP is doing such a terrific job of
getting everything together, it is now up to the network to get that data from one side of
the network to the other—in such a way that the data is still valuable or usable when
it arrives. This is where Frame Relay and ATM come in. By our estimation, nearly 60
percent of IP access lines actually run Frame Relay at the network level. And even IP
networks take advantage of ATM at the network core. This is not heresy, but smart
application of technology.
Where all this takes us is pretty simple.
The idea that we can integrate our data, voice, and video applications into a common
infrastructure just makes sense. The technologies that we will use to accomplish this are
not new, and the word technologies—plural—is key. There is not one "golden
bullet" that will do what we want. It has been tried with Frame Relay, ATM, and even
IP. We can, however, take advantage of the best of these technologies without compromising
on important scalability, efficiency, and performance requirements.