Archives
 
 
 
  Special
 
 
 
  About Us
 
 
 

Newsletter
Free E-mail Newsletter from BYTE.com

 
    
           
Visit the home page Browse the four-year online archive Download platform-neutral CPU/FPU benchmarks Find information for advertisers, authors, vendors, subscribers Request free information on products written about or advertised in BYTE Submit a press release, or scan recent announcements Talk with BYTE's staff and readers about products and technologies

ArticlesAre You Ready for ATM?


August 1996 / State Of The Art / Are You Ready for ATM?

Pioneers are using ATM. Here are five reasons why you might want to join the pack.

Lane F. Cooper

Voice. . .video. . .distributed client/server computing.. . . Many Fortune 1000 network managers are losing sleep over how they'll handle burgeoning network traffic and gigabytes of data. Simply throwing more bandwidth at the problem isn't a total solution because not all demands on the network are equal. For instance, most e-mail and data-file transfers can cope with latency. On the other hand, multimedia applications require a guarantee of a minimum level of performance throughout a session.

Asynchronous transfer mode (ATM) promises broadband speeds that surpass 1 Gbps, as well as quality-of-service guarantees that make multimedia viable. Add to that the technology's ability to absorb different access technologies--whether it be Ethernet, frame r elay, or Fiber Distributed Data Interface (FDDI)--on a single network, and you get the attention of corporate network managers.

But we've all heard the promises of ATM proponents for years. Even now that many of the initial standards issues have been resolved, ATM remains mainly a tool for telecommunications service providers to increase backbone bandwidth and pave the way for consolidating voice, data, and video onto a single network.

This leaves corporate network managers still asking, "When will ATM make our lives easier?"

For pioneering network administrators, the answer may be, "Now" (see the sidebars "ATM Goes Stratospheric" and "ATM Energizes Distributed Computing"). To help large corporations implement ATM today, there will be a continuing wave of new ATM products and services for LANs and WANs this year. These products include everything from cheap 25.6-Mbps adapter cards to s witches with built-in Ethernet ports for quick links to existing LANs (see the article "Virtually Well Connected"). Nevertheless, ATM still requires the pioneer spirit. Widespread corporate implementations of ATM probably won't happen until 1998 and later, when we will see hardware and software applications that will better integrate heterogeneous networks into new ATM infrastructures (see the article "Teach Your Apps to Speak ATM"). Should you be an ATM pioneer and make ATM part of your short-term plans? Or should you plan for ATM as a technology for the future? The following questions can help you find the answers for your company.

Question # 1: What can ATM offer to reduce bandwidth bottlenecks that traditional LAN technologies cannot provide?

Traditional LAN technologies primarily support store-and-forward data transfers. These technologies use connectionless routers. That is, no circuit is set up for the data exchange. Instead, the sender launches data, wh ich finds its way to the receiver on a "best-effort" basis. Consequently, when network performance degrades because of congestion, everybody--and every application--shares the pain.

ATM is a connection-oriented technology. Because it was designed for telecommunications carriers to support voice connections, ATM can establish virtual circuits , which reserve dedicated amounts of bandwidth for the duration of the session. This ability guarantees that bandwidth will be available when needed, and this separates ATM from technologies like FDDI and Fast Ethernet, which also offer broadband access.

By setting aside bandwidth for discrete connections, you can use ATM to better manage the different types of traffic going over the network without overinvesting in bandwidth infrastructure. For instance, for the people within your company who are simply exchanging e-mail messages or transferring text documents (this is perhaps the majority of your traffic), network management software will let you set aside relatively small amounts of ATM's scalable bandwidth.

The remaining bandwidth then becomes available for resource-intensive applications like videoconferencing, which needs perhaps 3 Mbps for the remainder of the session. With bandwidth locked in for the video sessions in a virtual circuit, nothing that occurs on the rest of the network can degrade the quality of the connection.

Question #2: If and when we commit to ATM, how do we begin the transition from our existing network?

The best first step is to ATM-enable discrete high-performance groups within the enterprise. Thus, you might equip the LANs in resource-intensive workgroups, like engineering design or radiology, with ATM adapter cards and then bridge the souped-up LANs to the rest of the corporate network.

Question #3: During the transition process, how do we integrate the alphabet soup of platforms, protocols, and OSes we have in our legacy networks?

Downsizing, mergers, and the natur al evolution of networks all mean that network managers must combine ATM with myriad technologies and protocols that were originally designed to be supported by a dedicated infrastructure.

One of the problems with integrating different protocols onto a single network is that some network technologies can obtain and use available backbone bandwidth better than others. For example, when you roll TCP/IP traffic into a trunk with IPX, it tends to effectively starve the IPX traffic of bandwidth. Since much of the current networking technology is connectionless, it is difficult to identify and assist the lower-performing protocols on the backbone. From a multiprotocol management standpoint, the challenge is to make sure everybody's traffic gets where it needs to go within predictable performance parameters.

The bandwidth guarantees associated with ATM's connection-oriented characteristics come into play here. Besides being able to set aside bandwidth for different traffic types (voice, text, or video) o r applications (workgroup computing or videoconferencing), ATM's virtual circuits can guarantee that each protocol has enough access to backbone network resources to serve your work force.

How do you make sure everyone gets the resources they need? You simply define a virtual circuit for TCP/IP, IPX, DECnet, Systems Network Architecture (SNA), or any other protocol to let it coexist on the same corporate backbone.

Each protocol then has fair access to any free bandwidth that may be available on the trunk at any particular time. Most ATM switch vendors sell protocol-specific cards that you can insert into a switch on your corporate backbone and manage a multiprotocol network. Increasingly, this approach could also support voice data and help computer telephony integration (CTI) tear down the wall that exists between the telephone and data networks.

Question #4: How does ATM fit in with the mix of technologies that link remote workers to central offices?

If you're strugglin g to integrate workers who routinely dial in to the corporate LAN via regular voice-grade copper wires, there is some good news. The shift by public telecommunications companies from analog to digital technology means that most central office switches that are operated by the service carriers are already digital. Basic rate ISDN, which supports 64 Kbps, is more widely deployed than ever before, and newer Digital Subscriber Line (DSL) technology promises to help boost performance for telephony and data transmissions.

ATM may combine with these technologies to provide high-speed connectivity using the existing copper telecommunications infrastructure. For example, U S West earlier this year launched a trial to see if DSL can support speeds of 768 Kbps to 1.544 Mbps, or faster, using digital modems. Results aren't in yet, but the telephone line in this trial is transporting data using the new digital technology to access the carrier's ATM backbone. Companies that are attached to the broadband network can s upport peer-to-peer connections between remote users and the LANs, as well as pay for the use of the carrier's ATM backbone to interconnect with other LANs in the region.

The early interconnections between DSL and ATM technologies are not symmetric. In other words, there is a significant capacity difference between upstream (to the network) and downstream (to the remote PC) traffic. But there should still be plenty of bandwidth to support communications between an enterprise network and a remote location. For example, Asymmetric Digital Subscriber Line (ADSL) supports between 64 and 640 Kbps going upstream, with 1.5 to 6 Mbps going downstream.

Question #5: How can ATM tie together our international operations?

Whether your international presence is large or small, you face the challenges of keeping in touch with subsidiaries and customers that are several time zones away and perhaps in countries where only rudimentary telecommunications infrastructures exist.

One strateg y is to use ATM via satellite to connect international and geographically remote operations. Beginning this September, Comsat World Systems will offer a two-tiered ATM service that will provide intermediate- and high-bandwidth services to common carriers and multinational network customers. Some of its services will use very small aperture terminals (VSATs), which are highly portable earth stations that can handle high-capacity links to the Intelsat system of geosynchronous satellites.

The integration of ATM into these VSAT networks will enable remote facilities to exchange massive amounts of multimedia information, including voice, with terrestrial networks for real-time access to corporate applications. Currently, the ATM Research and Industrial Enterprise Study (ARIES) project conducted by the American Petroleum Institute is investigating a land-and-satellite-based network that uses ATM for oil exploration (see the sidebar "ATM Goes Stratospheric").

Status Check

Today, large -scale ATM implementation is primarily the work of long-distance and regional carriers and Internet service providers that need a wide range of services over a single network infrastructure. If you need large amounts of bandwidth and guaranteed resources, ATM products and services will help you become a corporate pioneer. Otherwise, it may be best to wait two to four years before you start your company's network down the road to becoming ATM-enabled.


Where to find


American Petroleum Institute

Washington, DC
Phone:    (202) 682-8000
Internet: 
http://www.api.org/news/226proj.htm


Westinghouse Energy Systems

Monroeville, PA 
Internet: 
http://www.esbu.westinghouse.com
 


ATM Powers Move from Supercomputer to Client/Server

illustration_link (29 Kbytes)

ATM is a technology for today at a Westinghouse division that designs nuclear power plants.


Lane F. Cooper is a writer specializing in broadband-network technologies. You can reach him by sending e-mail to lcooper404@aol.com or on BIX c/o editors@bix.com .

Up to the State Of The Art section contentsGo to previous article: Go to next article: ATM Goes StratosphericSearchSend a comment on this articleSubscribe to BYTE or BYTE on CD-ROM  
Flexible C++
Matthew Wilson
My approach to software engineering is far more pragmatic than it is theoretical--and no language better exemplifies this than C++.

more...

BYTE Digest

BYTE Digest editors every month analyze and evaluate the best articles from Information Week, EE Times, Dr. Dobb's Journal, Network Computing, Sys Admin, and dozens of other CMP publications—bringing you critical news and information about wireless communication, computer security, software development, embedded systems, and more!

Find out more

BYTE.com Store

BYTE CD-ROM
NOW, on one CD-ROM, you can instantly access more than 8 years of BYTE.
 
The Best of BYTE Volume 1: Programming Languages
The Best of BYTE
Volume 1: Programming Languages
In this issue of Best of BYTE, we bring together some of the leading programming language designers and implementors...

Copyright © 2005 CMP Media LLC, Privacy Policy, Your California Privacy rights, Terms of Service
Site comments: webmaster@byte.com
SDMG Web Sites: BYTE.com, C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, New Architect, SD Expo, SD Magazine, Sys Admin, The Perl Journal, UnixReview.com, Windows Developer Network