An introduction to ATM

What is ATM?


This question can be answered at a number of different levels. Here are three:


ATM is a new development which will have an impact on data transport similar to the impact of containerisation on freight transport. ATM technology allows all kinds of digital communications traffic (including data, voice, and video) to be carried in "cells". Cell switching is faster and easier than the older communications technologies, and ATM will gradually take over from current technologies in most applications. But don't take the analogy too far: the size of a cell is more like a cardboard carton than a freight container.

ATM is a jargon term from the telecommunications industry. ATM stands for "Asynchronous Transfer Mode", in which traffic is carried in 53-byte cells; it is capable of conveying all the types of traffic that are at present carried by two quite different technologies: Synchronous Transfer Mode (as in ISDN) for "isochronous" traffic such as digitised voice, and Packet Transfer Mode (as in X.25 or Ethernet) for data traffic. It must not be confused with jargon terms from other industries that happen to have the same initials, such as Adobe Type Manager and Automated Teller Machines.

ATM is the first truly scalable data communications technology. As computer systems develop, they require more and more throughput from the communications media to which they are connected. Ideally one would like to keep the same structure to the network and run it faster. Unfortunately, this can't be done in the case of Ethernet and FDDI because the protocols will not work at higher speeds. (The proposed 100 Mbit/s Ethernet uses a quite different technology from the original Ethernet.) ATM is a different technology, and the standards concentrate on different aspects of the design. This makes it independent of the speed at which the data are transmitted: although presently standardised only for speeds of 45, 100, 155, and 622 Mbit/s, it can be used at speeds down to 64 kbit/s and below, and up to 2.4 Gbit/s and beyond.


Is ATM really here to stay?

Yes. While it is true that the computer industry is forever coming up with future-proof new technologies that are supposed to solve all our problems and yet somehow never really happen, there are a number of reasons why ATM isn't one of them. For instance:

How is ATM different from present-day LANs?

ATM is basically a telecommunications technology, and many of its characteristics are similar to those of the telephone system. Each telephone has its own connection into an exchange (or "switch" in telecomms parlance) and the switches are connected to each other by trunk lines. There are three distinct phases to a telephone call: first dialling the number and getting the receiver picked up at the other end, then conveying sounds between the two ends of the conversation, then disconnecting. During the middle phase, the telephone system conveys the sounds but it is for the listener to interpret them: the telephone system won't help if you don't speak the same language as the person at the other end, but neither will it insist on you speaking a language it understands.

Ethernet (for instance) was developed as a system in which all the devices connected to it ("terminals") can broadcast messages which are received by all the other terminals; an "address" on the front of the message tells each terminal whether it should receive it or ignore it, so every terminal has to be able to understand all the messages. Moreover, all the terminals must share the capacity of the medium over which the messages are sent. If it is inadequate, or if the terminals are too far apart, then more than one "segment" must be used, and the segments linked by bridges, routers, or gateways. In ATM, it is the connection between the terminal and the communications system that is specified in the standards (as the User-Network Interface or UNI), also the connection between separate parts of the communications network (the NNI). In LANs such as Ethernet the specification is of the shared medium to which all terminals are connected. Therefore:

Do we have to throw everything away and start again?

No. If your current network is coping well with the traffic, there is no reason to change. And ATM products will be compatible with existing networks (or "heritage" or "legacy" networks as they are beginning to be called). In particular, PCs with Ethernet cards can be connected into an ATM network via a special Ethernet hub that has an ATM port at the back; it is not necessary to install an ATM interface in the PC unless services such as video are required at that PC. Twisted-pair Ethernet (10baseT) can be used to provide each PC with the full 10 Mbit/s, or thin co-ax Ethernet for connecting several PCs into each port of the hub.

The first uses of ATM include:

Eventually, ATM-connected PCs will start replacing telephones. However, the next generation of telecommunications (SDH in Europe, SONET in USA) is designed to carry not only ATM cells but also the fixed-bandwidth digital circuits of present-generation ISDN.

Will today's ATM products work with tomorrow's?

ATM networks transport cells, and the format of a cell is now well-established. The areas in which there is still uncertainty concern the local connection between the terminal and the switch and the way in which particular traffics (such as voice and live video) are encoded in the cell stream.

There will always be a requirement for a range of options for connecting the terminal to the switch, providing different trade-offs between cost, speed, and distance in the local area and also covering the requirement to connect isolated terminals directly to a wide area network. The ATM Forum originally specified two based on wide area standards (45 and 155 Mbit/s), and two more for the local area (100 and 155 Mbit/s), but the eventual choice is likely to be quite different; further options are being added, and the 25 Mbit/s interface proposed by IBM and others, is now accepted by the Forum, and is likely to take a significant part of the market.

However, because the connection between the terminal and the network is a local issue (not affecting the service provided to other terminals), as a system is extended the new connections can use new standards without affecting their ability to exchange information with terminals which are still using the original standards.

Standards for "signalling" between the terminal and the switch (including how to set up and clear down connections) are not quite finalised although UNI 3.0 andUNI 3.1 provide a workable framework for small to medium sized networks, but these functions are again part of the interface between the terminal and the network and are therefore a local issue. Moreover they are performed by software and therefore can be updated as required.

The lack of standards for how live video (for instance) is represented means that at present you should not expect that one supplier's product will be able to receive a picture transmitted by another's, although the network over which the picture is transmitted may come from any supplier. (In the analogy of telephones, different video interfaces at present speak different languages.) As standards emerge, it may well be possible to modify existing interfaces to use the new standards, or a "translation server" can be installed on the network to handle translation of video cell streams between the two formats. The functionality of the video interface as seen by an application should not depend on the data format, so it is not necessary to wait for open standards in this area before beginning development of applications.

What are the main technical features of ATM?

All traffic on an ATM network is carried in cells.

A cell consists of two parts:

(a) A header (4 bytes plus a 5th "check" byte to guard against corruption): this is the packaging, which consists mostly of a virtual circuit identifier (VCI) which is used to route the cell to its correct destination.

(b) A payload (48 bytes): this is the data being carried. Any kind of digitised traffic – for instance voice, video, stereo sound, or Ethernet packets – can be chopped up into cell-sized pieces. The communications system doesn't need to know anything about the payload in order to route the cells to their destination, although it may need to know (for instance) how much delay can be tolerated.

(The VCI is partitioned into a "virtual pipe identifier" and an identifier for a virtual circuit within that virtual pipe, and is thus more correctly referred to as the VPI/VCI. A virtual pipe is a bundle of virtual circuits that are all routed to the same place; a company might have such a connection between two of its sites.)

Different kinds of traffic use different AALs.

The way in which information is packed into the cells is defined by the "ATM adaptation layer" or AAL. So far, five of these have been defined; streams of cells can also be sent without conforming to any of them. AAL 1 is intended for traffic such as voice in which timeliness is important and a certain amount of data loss and corruption can be tolerated. It has a 4-bit sequence number (plus some check bits) so you know if a cell or two has been lost; the remaining 47 bytes are for the data, which has no check bits. If a few bytes of your telephone conversation are lost or corrupted you may hear a click but there is no lasting effect; there would be no point in getting the sender to repeat a lost or corrupted cell because by the time it arrived it would be too late. Usually you can still hear what the other person is saying; if you can't, you ask them to say it again or give up and try to get a better line.

AAL 2 is intended for traffic such as compressed video in which corruption may have a longer-lasting effect by making the decoder become confused. Thus in addition to a sequence number it has check digit protection for the whole payload and also a field which can carry additional information for the decoder. AALs 3 and 4 are intended to carry data traffic, in which accuracy is paramount. The encoding is the same as in IEEE 802.6 (DQDB), and allows several different messages to be interleaved on the same virtual circuit. As with speech, it is up to the "higher layers" to ask for a retransmission if a packet is lost or corrupted.

AAL 5 has been defined more recently and now has taken over from AALs 3 and 4. It is in many ways much simpler; in particular, only one message at a time can be sent on each virtual circuit.

ATM networks are thought of as being star-connected.

Ethernet, for instance, was originally defined as a bus network, with a single cable on to which each of the attached devices could broadcast "packets"; each packet would be receivable by all the other attached devices. Physical limitations (on distance, number of attached devices, or total traffic that can be carried by the cable) required the introduction of repeaters, bridges, hubs, etc, but the system is still one which appears to offer the service of broadcasting each message to all the other devices on the network. An ATM network consists of a number of switches, each with a number of ports. Each port may be connected to an end system (e.g. a PC) or to a port on another switch.

In the same way that an Ethernet does not need to be physically a bus, an ATM switch does not need to be physically a single piece of equipment; it may consist of a number of separate units, each of which contains one port or a group of ports. There are at present no standards for how these separate units should be linked together; current LAN technologies such as Ethernet's CSMA/CD and FDDI's token passing have inherent limitations on the data rates they can support. To support faster data rates, other technologies will have to be used; all current proposals use slotted rings or buffer insertion or a mixture of the two. A virtual circuit links two ports, and is identified at each port by a VCI; the VCI codes are not the same at each port unless by coincidence. All cells received with the relevant VCI at one port are retransmitted with the other VCI at the other port.

ATM networks are virtual circuit based (or "connection-oriented").

Before you can send cells to a particular destination, you have to set up a virtual circuit to that destination. This may be quite a complicated process for the network, if the route goes through a lot of switches, but is only done once, and in almost all applications it is acceptable for it to take a little time. It is therefore done by software.

Once the virtual circuit is set up, it is very easy for each switch to route the cells to the correct port. This can be done entirely by hardware; to increase the data rate through the switch you have to use faster hardware which will therefore route the cells faster. This means that ATM technology does not impose any limitations on the speed at which the network can carry data.

Current telecommunications networks are virtual circuit based: first you dial the number, then when the connection is made you can speak. There are now many millions of telephones each of which can dial any other, so this system clearly works successfully, even on an extremely large network!

LANs such as Ethernet, Token Ring, and FDDI are connectionless. This works well for a small workgroup, but is a limitation on a large network where routers must examine every packet to work out where to send it next.

ATM networks offer bandwidth on demand.

In current telecommunications networks, each circuit carries traffic at a fixed rate (usually 64 kbit/s). Thus as soon as you make a connection you are tying up a 64 kbit/s channel and reducing the capacity that other people can use by that amount. But many data processing applications need to send data in bursts; 64 kbit/s is inadequate during data bursts but the bandwidth is wasted in between bursts. If you increase capacity to cope with the data bursts (by using more than one circuit), you waste even more bandwidth in between them.

With ATM, virtual circuits do not of themselves consume resources (except for the minimal amount of memory needed in the switch to remember to which port and VCI it is connected). Thus a channel which has a nominal 64 kbit/s capacity would allow data bursts to be sent faster than that if there is spare capacity in the network, and in between bursts would not be tying up bandwidth that other people could use. However, the sender must not transmit at a faster rate than the network and the recipient can cope with; and traffic levels on links between switches may change very quickly. A computer in England could send many megabytes of data in the time it would take to notify it of congestion at a switch in Australia, for instance. One answer is to say that cells are always liable to be thrown away unless bandwidth has been reserved for them. Thus you might reserve 64 kbit/s of capacity (tying up resources again): any data beyond that amount would be thrown away in the event of congestion, and anyone else who uses capacity which you have reserved but not used on one link may have their data thrown away when it gets to the next link. Most of the industry recognises that users need a better service than this "real men drop cells" approach, and is working on ways to provide it, but only when there are large ATM networks carrying real traffic will we know whether they have succeeded.


John Grant

Development Director

K-Net Ltd

© 1994 Nine Tiles Computer Systems Ltd / K-Net Ltd


Return to home page