Geek Page - All Aboard: the rush toward ATM
The universal language of the Net will be spoken 53 bytes at a time.
Just as physicists dream of a final, all-encompassing theory, so technologists dream of a universal network, equally capable of handling voice, video, and data. This dream began its march toward reality with the development of ATM (Asynchronous Transfer Mode) by researchers at Bellcore and Cambridge University. By combining the best of earlier voice and data protocols, ATM offered telephone companies a way to support both types of traffic over the same network. The companies' quick acceptance of ATM spurred interest within the computer industry. A single standard for both voice and data promised an end to the networking Tower of Babel. The technology continues to evolve, and questions still remain, but products that support ATM are now entering the market.
The buzz about ATM can seem unfathomable given how little the protocol really defines. The technique simply divides all information, whether voice or video, into very short snippets. These snippets, called cells, are 53 bytes long. The first five bytes contain header information and the next 48 contain the actual data. The content of the data bytes could be ASCII characters or the sound of a whistle, but ATM uses constant length cells. This ensures that delays are predictable and fair: small voice packets can't get trapped behind long data packets. Constant length also allows for simpler - and therefore faster - switching hardware. While ATM doesn't specify a transmission speed, it was designed with the goal of gigabits per second in mind. The cell length of 48 bytes, however, was chosen purely out of the need to compromise: it was the arithmetic average of two competing proposals and left both sides equally unhappy.
Once information has been chopped into uniform cells, it becomes very easy to play with. Think of a data transmission as a train carrying ATM cells, making a transmission of 40 Mbits/sec equivalent to a train 100,000 cells long that launches every second. These cell trains depart from your phone or computer and are then routed through the network to their destination. Routing is done by ATM switches, which act like a switching yard: trains arrive, cells are switched to the correct output line (based on the address in the cell's header), and the newly formed trains are sent out. In the telephone network, the input lines may be copper while the outputs are fiber-optic cable, so an output train may be the combination of many inputs.
It is ATM's method of combining inputs, called statistical multiplexing, that makes the protocol so advantageous. A conventional telephone switch combines two 40 Mbyte/second cell-trains into one 80 Mbyte/second train by reserving the odd cars for the first input and the even cars for the second. This makes de-multiplexing at the other end a simple matter. But it also means that if one input line is momentarily quiet, as is common with data traffic, half the output cars must go empty. ATM avoids this wasted bandwidth by allowing inputs to be mixed together in any order: demultiplexing is done according to the information in the cell's header rather than the order of the cells. So by assuming that at least one line will be quiet at any given moment, ATM can multiplex, say, three 40 Mbyte/second lines into just one 100 Mbyte/second output. It does this by loading the train with all the cells that happen to be waiting. Of course, if all three lines start transmitting at full speed, a huge backup will occur as cells wait for an empty output car. Shaping traffic so that such simultaneous bursts don't occur - and figuring out how to cope when they do - are currently the hottest topics in the field of network research.
For statistical multiplexing to work, every ATM cell carries an identifier that defines its destination. Rather than assigning unique addresses to all destinations, as the postal system and Internet do, ATM has the source and destination agree on a randomly chosen number that uniquely identifies the connection only for as long as it is in use. This allows for shorter addresses, but also means that cells cannot be delivered until the identifiers necessary for a connection have been determined. For example, if I place a call from San Francisco to New York, my local switch might first send a request to the Chicago switch. These two switches will agree on some identifier, say 23, which neither switch is currently using. Chicago then repeats this process with the switch in New York and the two agree on an identifier of 42. My voice can now be chopped into cells identified by 23 and sent. When these cells arrive in Chicago, the switch looks up 23 in its table and sees that the next hop is to New York and that the hop identifier is 42. So the addresses in all my cells are changed to 42 and then shipped off to New York. Of course, the reality is somewhat more complex: ATM uses two numbers for an identifier, one number is more general than the other, and some switches may look at only the more general.
As ATM defines only the format and addressing of a cell, additional protocols are required for real applications. Below ATM is a lower-level protocol such as SONET (Synchronous Optical NETwork), which defines how bits are transmitted over fiber-optic lines. This layer also defines the speed of the ATM network, with the most popular standard, SONET OC-3, running at 155 Mbytes/second - about 15 times faster than current computer networks. Above ATM is one of the ATM Adaptation Layers that defines how cells are reassembled into larger units (such as data packets or video frames) at their final destination. And above the adaptation layer, there will probably be a protocol such as TCP to provide error-handling, since ATM is not able to guarantee error-free delivery.
Despite ATM's flexibility, or perhaps because of it, ATM will not be a panacea. Due to the small cell size, it will probably be too inefficient for high-speed LANs, despite all the hype you hear at shows like NetWorld + Interop. Nor is it clear that ATM is suitable for traffic dominated by constant bit-rate streams. But there is no doubt that ATM will be extremely important. It will be a universal language in the same way that English is, filled with compromises and borrowed concepts from other languages, awkward in certain situations, unusable in others. Yet, logical or not, through sheer popularity, it will alter how we communicate.
Steve G. Steinberg (steve@wired.com) never wants to be a member of a standards committee.
