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

ArticlesConnecting with ATM


October 1994 / Networking / Connecting with ATM

ATM promises fast, flexible networks but won't deliver unlimited bandwidth on demand

Peter Wayner

In the next few years, many networks will trade data using a collection of standards called ATM (Asynchronous Transfer Mode). These new standards promise to allow networks to blend real-time continuous streams of data, like digital video, with normal packetized transactions, without causing backups or delays.

Marketing professionals hype this hybrid approach with the seductive phrase ``bandwidth on demand,'' or BOND. In truth, ATM networks have limits and can still become overloaded, but the technology undoubtedly will offer unprecedented flexibility and very appealing performance for both LANs and WANs handling a wide mixture of data.

ATM differs from many of the prior common networking protocols in four major ways. The first and most important physical difference is that ATM uses no shared wires or fiber. Each computer has its own direct connection to a switch. Older approaches, such as Ethernet, save money by letting several computers share one wire. This is less expensive, but the wire quickly becomes overloaded when everyone uses it at once.

ATM networks aren't directly affected by the other computers using the network, because no one else can use a computer's direct connection to a switch (see the figure ``ATM Switching''). Users experience overloading only if they are competing with other machines for limited resources, such as time from a file server or bandwidth to sources outside the network. If you don't have shared wiring, you can eliminate bottlenecks like these by purchasing a larger outside network connection or another file server. Complete rewiring isn't necessary.

Second, data is transmitted over virtual circuits. This means that the switches between the sender and the rece iver create a temporary direct link between the two machines. The link, which is virtual only because it happens in software, emerges after each of the switches in the path decodes the final address, chooses its internal switching connections, and matches this information with an address that is assigned temporarily.

At that point, each packet carries only this ``predigested'' address, and the switches can pass the information on faster because they can avoid complicated table lookups. Much of the routing work is done only once for each connection.

The third difference is the existence of service classes. When two computers initiate a link, they also specify a level of service that they will demand of each switch along the route. When the switches predigest the address, they also check to ensure that they can honor the commitment. An ATM switch can, for instance, promise to deliver 155 Mbps of data flowing at a constant rate, which is useful for transmitting video information. The switch prevent s other users from grabbing this bandwidth after it is allotted.

ATM switches also offer variable-rate services for second-class data, data that does not travel with a time constraint. They issue bandwidth promises for this class of data, but the constraints are much more flexible. This arrangement lets a switch overbook the bandwidth and try to interleave the different requests that it receives by delaying some packets.

In contrast, older technologies often just move bits from one location to another. Ethernet, for instance, has no concept of priority. Each node listens for free time on the network for a random amount of time, passing on its packets when time becomes available. This random approach may be egalitarian, but it does not offer the performance guarantees necessary to do constant-rate data movement. Performance fluctuates noticeably, for example, as people on the same branch of the network start and finish their work. By the time users get clearance for their connections and slowdown s disappear, data flow already has been interrupted.

Although ATM's book-ahead strategy successfully provides constant-rate data service, it has one drawback. If a network's bandwidth is promised to certain users, others will be locked out. You could hardly call that BOND. Still, those who get clearance under ATM receive better service than that provided under earlier systems.

The final--and most important--difference between ATM and earlier standards is that it provides a consistent standard that works on both LANs and WANs. Earlier systems use one networking protocol for local networks and another for long-distance connections. This can be efficient, but it is often inflexible and confusing.

Inherently flexible, ATM allows the switches and branches of the network to expand in unexpected ways. You can rearrange the long-distance and local connections of each ATM switch to adjust to the load patterns of a network. If you need more long-distance traffic, you may allocate more channels to t hese circuits by doing simple reprogramming. Or you may allocate the channel for local traffic to a LAN in the next building. The same equipment will handle both tasks.

The Basic Foundation

Each of these four features is available, in one form or another, in more specialized networks. But together, the four should provide the right balance for network users who want high-speed data traffic that mixes both constant-rate and variable-rate data streams. When the ATM Forum (Foster City, CA), the industry group responsible for setting standards, made its initial choices, it selected an interesting mix of technological approaches that solves many problems and provides a high level of service. At the beginning, it seemed as if the cost of these services would be high, but now it appears that costs will drop significantly, as several people jump on the standard's bandwagon.

The basic unit of data on the ATM network is still a packet. In this case, it is a fixed 53 bytes long (see the figure ``An ATM Packet''). Out of the 53 bytes, 48 bytes hold data and 5 bytes hold the address of the destination. A number of recent network protocols have experimented with variable-length packets; however, the results have often proved unsatisfactory, because jams can occur when large packets are sent. Small packets are a compromise that makes sure that time-critical data, such as video, can always get through.

The 5 bytes in the header have six fields: GFC (Generic Flow Control), VPI (Virtual Path Identifier), VCI (Virtual Channel Identifier), PT (Payload Type), CLP (Cell Loss Priority), and HEC (Header Error Control). The most important fields, VPI and VCI, contain the predigested address for all the internal information the switches use to quickly route packets. For convenience, the address is broken into two parts.

Switches may set up their internal allocation of VPI and VCI numbers to aggregate many similar connections into one pipe. A switch might, for instance, assign a VPI of 3 to every connecti on that comes in via port 14 and leaves via port 2. Then the switch could effectively ignore the VCI for these connections.

The CLP is a 1-bit field used to mark packets that can be lost. The switches flip this bit on when they discover that a computer is sending more data than it has reserved. This means that any switch can toss away this packet if it is swamped. The HEC is an 8-bit checksum of the other information in the header. At the time of this writing, the uses for the GFC are not standardized, but it could be used to provide flexible available-rate service.

Flexible Flyers

A key feature of ATM is a call-initiation process that lets both continuous streams of data and bursts coexist peacefully. When one computer wants to send data to another, it sends a request for a particular type of connection. If the computer plans on establishing a video link, it might request 100 Mbps of continuous data traffic.

Each switch along the way decodes the address and determines the ports th rough which the information will enter and leave. It then considers the request for bandwidth and determines if it has enough available on the outgoing port. (The demand for the incoming port was already determined by the sender.) If sufficient bandwidth is available, the switch assigns a pair of VPIs and VCIs to the connection and records them in the pair's routing tables. The values of the VPI and VCI are different for each switch-to-switch hop along the connection. The tables contain the VPI/VCI pair of the sender and instruct the switch to replace them with a new VCI/VPI pair for the next hop and to send the packet from the correct port. It is at this point that some users might experience overloading.

One ATM switch may create a bottleneck between one half of the network and the other. If computers in one area create a bottleneck by booking all the bandwidth, then the other computers cannot get a connection; therefore, they must wait until the connections are broken. The simplest way to solve the problem is to reprogram the switches to allocate more bandwidth to the links to the bottlenecked switch. Because the switches often have an aggregate amount of bandwidth that they may use for any of their ports, you can often reallocate bandwidth from one port to another. When insufficient bandwidth is available, you may add another switch in the center of the network.

The Standard Issue

ATM standards are maintained by the ATM Forum (its Internet address is info@ atmforum.com). The basic standard is the ATM UNI (User-to-Network Interface), which governs the size and structure of the packets, and how connections begin and end. The current version of the standard is well evolved, and the ATM industry met to construct an intervendor LAN at the 1994 Networld+Interop show in Las Vegas with Supercomm/ICA in New Orleans. Switches and interface cards from many vendors were connected successfully.

The standards are evolving, as the ATM Forum decides which solutions are best for different problems. At this point, version 3.0 is finished, and the ATM Forum is working on its next release, version 3.1. These new standards probably won't make existing ATM equipment obsolete. Because several ATM protocols are handled in software, it is possible to reprogram old switches for the new standards.

Another issue standards hope to resolve is a unified billing scheme for all the long-distance carriers. Although UNI already governs how switches interact, it does not yet include enough information for the long-distance carriers that offer ATM service to connect ATM LANs in different communities. These carriers would like to supply potential customers with information about billing and pricing so that they can sell the service more effectively. Right now, you have to buy ATM service from a single long-distance carrier at a time.

The next standard, the BICI (Broadband Intercarrier Interface) should change all that. Version 1.0 is finished, and it specifies permanent virtual circuits. Version 1.1 was sched uled to be completed by September and will cover switched virtual circuits. It will effectively be able to initiate ATM links that hop along several long-distance carriers. Billing information will find its way back to you.

Levels of Service and Guarantees

At present, two approved levels of service are available to applications looking to ship data across the network. The first, Class A (or constant-rate data) service, must get to its destination with little delay in delivery time. The other option is Class C service, also known as variable-rate service. It offers looser guarantees on delivery time, which might confound applications such as digitized video or digitized voice. The standard specifies the amount of sustained bandwidth, peak bandwidth, burst size, and the maximum delay.

The ATM Forum is debating whether to add a third class, known as available bit-rate service. It would give switches even more latitude to delay data if higher-priority data arrived. This class of service is qu ite desirable because much of the software in use today does not require guaranteed services to perform simple tasks such as moving files or blocks of data.

The new service class is not just an attempt to provide a lower and less expensive class of service. It is necessary because old software does not always interact correctly with ATM. It may, for example, dump a large block of data on the network at a particular time, without reserving a guaranteed level of service. This burst overwhelms the network. In some cases, the switches flag the packets by flipping the CLP bit. In others, the burst floods the buffers, and packets are lost.

The solution is to create a closed-loop system between both ends of the link. The sending end keeps track of the space in the buffers at the other end and transmits only when space is available. This tightly controlled approach seems a bit clumsy when compared to the lightweight, predigested addressing spaces that define virtual circuits, but it is the only practica l way to handle large bursts.

Users of long-distance ATM connections will undoubtedly pay particular attention to each of these classes of service, because carriers will price their services at levels to maximize profit and ensure smooth use of their network. Carriers are certain to experiment with many pricing schemes, in part because the computerized nature of the business makes it tempting to do so. These schemes could vary from the simple (fixed cost per month) to something that outstrips airline pricing in complexity. Long-distance companies such as Ameritech, MCI, and AT&T cannot offer concrete examples of their pricing schemes, but all say that competition will encourage flexible schemes that target particular types of clients.

Inside the Switches

The switches that move information from one port to another port have a difficult job. For a switch to sustain data coming from each port, it must be designed so that it alleviates bottlenecks and prevents any interruption in data flow. T he smaller switches of 16 or fewer ports are often largely serial implementations that service each port in turn, while larger switches have more complicated, parallel switching fabrics.

Smaller switches revolve around a high-speed bus. Each port has its own controller, which places packets on the bus when it is the port's turn. In the meantime, each port controller listens to the bus for packets that are intended to leave its port. The bus must be able to run at a speed that provides enough bandwidth for every port. There is a limit to the scale of this approach.

A more general approach uses a flexible ``fabric'' of small switching elements. The result is a matrix like the one shown in the figure ``ATM Switching'' on page 96DM 18. The packets from each port enter on one side of the matrix. At each step in the clock, the switching elements pass the packets to an appropriate neighbor. Each switching element is connected to a few neighbors, which means that a packet might need to be switched sever al times before it reaches the right output port.

A switching matrix scales nicely, and the design can sustain switches with 64 ports or more. Of course, problems may arise when several ports are sending information to one output port. If the traffic is low-priority data traveling in the available bandwidth, it may overload the output port. Each small switch has only a small amount of buffer memory to ride out temporary overflows. If the overflow is too large for the memory buffer to handle, the buffers on the input ports take over.

Pipe Size

Many parts of the ATM standard do not depend on the connection speed. It would be possible, in theory, to run ATM over a 300-bps modem line. The industry, though, is creating several levels of speeds for the connections between computers and ATM switches. The basic levels are 45 and 155 Mbps, but other standards may evolve.

Interface cards that operate at slower speeds are less expensive to produce. A faster interface card in a computer must h ave larger buffers and better bus-interface electronics to handle the higher speeds. Also, wires capable of handling faster speeds must be better shielded.

In many cases, existing wires are good enough to handle slow ATM, but to install a fast ATM network, companies must rewire their offices. For this reason, some companies are exploring a much slower 25-Mbps ATM service that would run successfully over today's lower grade wires.

Grand Unifier

The ATM Forum likes to refer to ATM as ``The Grand Unifier.'' When it finishes the BICI standard, which allows long-distance companies to knit their networks into a seamless WAN, unification will really begin. As a next step, someone must produce the software layers that make it easier for the average developer to use video-class services without worrying about buffering and display problems.

When this work is finished, the main obstacle becomes political. Will a number of companies adopt the ATM standard? If everyone does, economies of scale will make ATM very inexpensive. Some users remain skeptical, pointing out that the last great unifier, ISDN, never really arrived.

The great promise of ATM, though, is that its standard format links all levels of a network. This factor, as well as the superior performance offered by switched circuits, should be enough to make ATM irresistible to a number of users with large, high-speed networks. Only time will tell whether ATM will prove irresistible enough to drive the technology to price levels that make it affordable enough for the average desktop.


Illustration: ATM Switching In an ATM matrix, each switch has three entry and three exit ports. Each switch must shift a signal to an exit port as the signal moves across the matrix.
Illustration: An ATM Packet Each ATM packet has 53 bytes. The most important segments, the VCI and the VPI, contain the address for routing.
Peter Wayner is a BYTE consulting editor who lives in Baltimore, Maryland. He can be reached on the Internet at pcw@access.digex.com or on BIX as ``pwayner.''

Up to the Networking section contentsGo to previous article: Connecting RemotelyGo to next article: Collapsing ComplexitySearchSend 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