A Brief Tutorial on ATM

Zahir Ebrahim [March 5, 1992](DRAFT)

0.0 Preamble

This tutorial is an attempt to qualitatively present the ATM concepts, and to introduce it gently to readers unfamiliar with the subject. The purpose of this writeup is to bring interested readers up to speed on what the heck is this "ATM". There are also some "opinions" presented in this writeup. Please feel to disagree. And if I may have mis-stated some fact or something is in error, I would be happy to learn about it.

If the reader is interested in knowing the exact bit locations in the ATM header, or how to design and implement an ATM interface card, or other facts and figures about interconnect speeds etc, he/she is directed towards the copious ATM standards committees documents where the latest and greatest information is available in the most excruciating detail.

1.0 What is this acronym ATM ?

ATM stands for (no not automated teller machines) "Asynchronous Transfer Mode". It is primarily driven by telecommunications companies and is a proposed telecommunications standard for Broadband ISDN.

2.0 Motivation for ATM

In order to understand what ATM is all about, a brief introduction to STM is in order. ATM is the complement of STM which stands for "Synchronous Transfer Mode". STM is used by telecommunication backbone networks to transfer packetized voice and data across long distances. It is a circuit switched networking mechanism, where a connection is established between two end points before data transfer commences, and torn down when the two end points are done. Thus the end points allocate and reserve the connection bandwidth for the entire duration, even when they may not actually be transmitting the data. The way data is transported across an STM network is to divide the bandwidth of the STM links (familiar to most people as T1 and T3 links) into a fundamental unit of transmission called time-slots or buckets. These buckets are organized into a train containing a fixed number of buckets and are labeled from 1 to N. The train repeats periodically every T timeperiod, with the buckets in the train always in the same position with the same label. There can be up to M different trains labeled from 1 to M, all repeating with the time period T, and all arriving within the time period T. The parameters N, T, and M are determined by standards committees, and are different for Europe and America. For the trivia enthusiasts, the timeperiod T is a historic legacy of the classic Nyquist sampling criteria for information recovery. It is derived from sampling the traditional 4Khz bandwidth of analog voice signals over phone lines at twice its frequency or 8Khz, which translates to a timeperiod of 125 usec. This is the most fundamental unit in almost all of telecommunications today, and is likely to remain with us for a long time.

On a given STM link, a connection between two end points is assigned a fixed bucket number between 1 and N, on a fixed train between 1 and M, and data from that connection is always carried in that bucket number on the assigned train. If there are intermediate nodes, it is possible that a different bucket number on a different train is assigned on each STM link in the route for that connection. However, there is always one known bucket reserved a priori on each link throughout the route. In other words, once a time-slot is assigned to a connection, it generally remains allocated for that connections sole use throughout the life time of that connection.

To better understand this, imagine the same train arriving at a station every T timeperiod. Then if a connection has any data to transmit, it drops its data into its assigned bucket(time-slot) and the train departs. And if the connection does not have any data to transmit, that bucket in that train goes empty. No passengers waiting in line can get on that empty bucket. If there are a large number of trains, and a large number of total buckets are going empty most of the time (although during rush hours the trains may get quite full), this is a significant wastage of bandwidth, and limits the number of connections that can be supported simultaneously. Furthermore, the number of connections can never exceed the total number of buckets on all the different trains (N*M). And this is the raison-d'etre for ATM.

3.0 Advent of ATM

The telecommunications companies are investigating fiber optic cross country and cross oceanic links with Gigabit/sec speeds, and would like to carry in an integrated way, both real time traffic such as voice and hi-res video which can tolerate some loss but not delay, as well as non real time traffic such as computer data and file transfer which may tolerate some delay but not loss. The problem with carrying these different characteristics of traffic on the same medium in an integrated fashion is that the peak bandwidth requirement of these traffic sources may be quite high as in high-res full motion video, but the duration for which the data is actually transmitted may be quite small. In other words, the data comes in bursts and must be transmitted at the peak rate of the burst, but the average arrival time between bursts may be quite large and randomly distributed. For such bursty connections, it would be a considerable waste of bandwidth to reserve them a bucket at their peak bandwidth rate for all times, when on the average only 1 in 10 bucket may actually carry the data. It would be nice if that bucket could be reused for another pending connection. And thus using STM mode of transfer becomes inefficient as the peak bandwidth of the link, peak transfer rate of the traffic, and overall burstiness of the traffic expressed as a ratio of peak/average, all go up. In the judgement of the industry pundits, this is definitely the indicated trend for multimedia integrated telecommunications and data communications demands of global economies in the late 90's and early 21st century.

Hence ATM is conceived. It was independently proposed by Bellcore, the research arm of AT&T in the US, and several giant telecommunications companies in Europe, which is why there may be two possible standards in the future. The main idea here was to say, instead of always identifying a connection by the bucket number, just carry the connection identifier along with the data in any bucket, and keep the size of the bucket small so that if any one bucket got dropped enroute due to congestion, not too much data would get lost, and in some cases could easily be recovered. And this sounded very much like packet switching, so they called it "Fast packet switching with short fixed length packets." And the fixed size of the packets arose out of hidden motivation from the telecommunications companies to sustain the same transmitted voice quality as in STM networks, but in the presence of some lost packets on ATM networks.

Thus two end points in an ATM network are associated with each other via an identifier called the "Virtual Circuit Identifier" (VCI label) instead of by a time-slot or bucket number as in a STM network. The VCI is carried in the header portion of the fast packet. The fast packet itself is carried in the same type of bucket as before, but there is no label or designation for the bucket anymore. The terms fast packet, cell, and bucket are used interchangeably in ATM literature and refer to the same thing.

4.0 Statistical Multiplexing

Fast packet switching is attempting to solve the unused bucket problem of STM by statistically multiplexing several connections on the same link based on their traffic characteristics. In other words, if a large number of connections are very bursty (i.e. their peak/average ratio is 10:1 or higher), then all of them may be assigned to the same link in the hope that statistically they will not all burst at the same time. And if some of them do burst simultaneously, that that there is sufficient elasticity that the burst can be buffered up and put in subsequently available free buckets. This is called statistical multiplexing, and it allows the sum of the peak bandwidth requirement of all connections on a link to even exceed the aggregate available bandwidth of the link under certain conditions of discipline. This was impossible on an STM network, and it is the main distinction of an ATM network.

5.0 The ATM discipline and future challenges

The discipline conditions under which statistical multiplexing can work efficiently in an ATM network are an active area of research and experimentation in both academia and industry. It has also been a prodigious source of technical publications and considerable speculations. Telecommunications companies in the US, Europe, and Japan as well as several research organizations and standards committees are actively investigating how BEST to do statistical multiplexing in such a way that the link bandwidth in an ATM network is utilized efficiently, and the quality of service requirements of delay and loss for different types of real time and non real time as well as bursty and continuous traffics are also satisfied during periods of congestion. The reason why this problem is so challenging is that if peak bandwidth requirement of every connection is allocated to it, then ATM just degenerates into STM and no statistical advantage is gained from the anticipated bursty nature of many of the future broadband integrated traffic profiles.

Thus the past few years publications in "IEEE Journal of Selected Areas in Communications" and the "IEEE Network and Communications Magazines" are filled with topics of resource allocation in broadband networks, policing metering and shaping misbehaving traffic and congestion avoidance and control in ATM networks, and last but not least, multitudinous mathematical models and classifications speculating what the broadband integrated traffic of the future might actually look like, and how it might be managed effectively in a statistics based nondeterministic traffic transportation system such as an ATM network. The more adventurous readers desirous of learning more about ATM networks are encouraged to seek out these and the standards committees publications.

Fortunately however, these are problems that the service providers and ATM vendors like the telecommunications companies have to solve, and not the users. The users basically get access to the ATM network through well defined and well controlled interfaces called "User Network Interface" (UNI), and basically pump data into the network based on certain agreed upon requirements that they specify to the network at connection setup time. The network will then try to ensure that the connection stays within those requirements and that the quality of service parameters for that connection remain satisfied for the entire duration of the connection.

6.0 Who are the standards bodies investigating ATM ?

In the US, ATM is being supported and investigated by T1S1 subcommittee (ANSI sponsored). In Europe, it is being supported and investigated by ETSI. There are minor differences between the two proposed standards, but may converge into one common standard, unless telecommunications companies in Europe and America insist on having two standards so that they can have the pleasure of supporting both to inter-operate. The differences however are minor and do not impact the concepts discussed here. The international standards organization CCITT has also dedicated a study group XVIII to Broadband ISDN with the objective of merging differences and coming up with a single global worldwide standard for user interfaces to Broadband networks. No conclusions yet.

7.0 Types of User Network Interfaces (UNI) for ATM

It is envisioned that the ATM network service providers may offer several types of interfaces to their networks. One interface that is likely to be popular with companies that build routers and bridges for local area networks is a Frame based interface. One or more of the IEEE 802.X or FDDI frames may be supported at the UNI, with frame to ATM cell conversion and reassembly being done inside the UNI at the source and destination end points respectively. Thus a gateway host on a local area network might directly connect its ethernet, token ring, fddi, or other LAN/MAN interface to the UNI, and thus bridge two widely separated LANs with an ATM backbone network. This will preserve the existing investment in these standards and equipments, and enable a gradual transition of the ATM networks into the market place.

An alternate interface likely to be more popular in the longer run, and for which the concept of Broadband-ISDN really makes sense, is direct interface at the UNI with standard ATM cells. Such a streaming interface can hook subscriber telecom, datacom, and computer equipment directly to the network, and allow orders of magnitude greater performance and bandwidth utilization for integrated multimedia traffic of the future. Thus it is by no accident that the IEEE 802.6 packet for the MAC layer of the Metropolitan Area Network (MAN) DQDB protocol (Distributed Queue Dual Bus) looks very much like an ATM cell.

It is quite likely that companies may crop up (if they have not already done so) to design ATM multiplexers for interface to the UNI of a larger ATM backbone network. Especially if the CCITT succeeds in standardizing an interface definition for UNI, it will be an additional boon to this market. The multiplexers with multiple taps on the user side can connect to one fat ATM pipe at the network side. Such a multiplexer would hide the details of ATM network interface from the user, and provide simple, easy to use, low cost ATM cell taps to hook the user equipment into.

Companies with investment in existing STM networks such as T1 and T3 backbones, are likely to want a direct T3 interface to the UNI, thus allowing them to slowly integrate the newer ATM technology into their existing one. Thus it is possible to see a flurry of small startups in the future rushing to make large T3 multiplexers for connecting several T3 pipes into one large ATM pipe at the UNI.

Typically, an ATM network will require a network management agent or proxy to be running at every UNI which can communicate and exchange administrative messages with the user attachments at the UNI for connection setup, tear down, and flow control of the payload using some standard signalling protocol. A direct user attachment at the UNI is likely to cost more and be more complex, then a user attachment to something which in turns interfaces to the UNI.

8.0 What does an ATM packet look like

An ATM cell or packet as specified by T1S1 sub-committee is 53 bytes. 5 bytes comprise the header, and 48 bytes are payload. The header and payload are specified as follows:
<------------ 5 bytes ---------------->|<---------- 48 bytes --------->|
|VCI Label | control | header checksum | optional adaptation | payload |
| 24 bits  | 8 bits  |   8 bits        |   layer 4 bytes     |44 or 48 |
The 48 bytes of payload may optionally contain a 4 byte ATM adaptation layer and 44 bytes of actual data, or all 48 bytes may be data, based on a bit in the control field of the header. This enables fragmentation and reassembly of cells into larger packets at the source and destination respectively. (Since the header definition may still be in flux, it is possible that presense or absence of an adaptation layer information may not be explicitly indicated with a bit in the header, but rather implicitly derived from the VCI label). The control field may also contain a bit to specify whether this is a flow control cell or an ordinary cell, an advisory bit to indicate whether this cell is dropable in the face of congestion in the network or not, etc.

The ETSI definition of an ATM cell is similar, 53 bytes cell size, 5 byte header, 48 bytes data. However the difference is in number of bits for the VCI field, number of bits in the header checksum, and semantics and number of some of the control bits.

For a more detailed specification of the ATM header, see the appropriate standards committees documents.

9.0 Connections on an ATM network

As in STM networks, where a datum may undergo a time-slot-interchange between two intermediate nodes in a route, the VCI label in an ATM cell may also undergo a VCI label interchange at intermediate nodes in the route. Otherwise, the connections in the ATM network look remarkably similar to STM networks.

An Example:

Assume an ATM network with nodes in NY, ATLANTA, DALLAS, and SF. Say that Chuck while vacationing in NY decides to play Aviator with his buddies in Mtn view who are still grinding away on MPsniff. Also assume that we have ATM cell interfaces at UNI's in both NY and SF. This is what can happens: Chuck's portable $3K laptop makes a connection request to the UNI in NY. After an exchange of connection parameters between his laptop and the UNI (such as destination, traffic type, peak and average bandwidth requirement, delay and cell loss requirement, how much money he has got left to spend, etc}, the UNI forwards the request to the network. The software running on the network computes a route based on the cost function specified by Chuck, and figures out which links on each leg of the route can best support the requested quality of service and bandwidth. Then it sends a connection setup request to all the nodes in the path enroute to the destination node in SF.

Lets say that the route selected was NY--AT--DA--SF. Each of the four nodes might pick an unused VCI label on their respective nodes and reserve it for the connection in the connection lookup tables inside their respective switches. Say, NY picks VC1. It will send it to AT. AT in turn picks VC2, associates it with VC1 in its connection table, and forwards VC2 to DA. DA picks VC3 and associates it with VC2 in its connection tables and forwards VC3 to SF. SF picks VC4 and associates it with VC3 in its connection tables, and pings the addressed UNI to see if it would accept this connection request. Fortunately, the UNI finds Chuck's buddies and returns affirmative. So SF hands the UNI and Chuck's friends VC4 as a connection identifier for this connection. SF then acks back to DA. DA acks back to AT and sends it VC3. AT puts VC3 in its connection tables to identify the path going in the reverse direction, and acks to NY sending it VC2. NY associates VC2 in its connection tables with VC1, and acks the originating UNI with VC1. The UNI hands chuck's laptop VC1 and connection is established.

Chuck identifies the connection with VCI label VC1, and his buddies identify the connection with VCI label VC4. The labels get translated at each node to the next outgoing label like so:

		 NY     AT     DA     SF
	Chuck -> VC1 -> VC2 -> VC3 -> VC4 -> buddies
	Chuck <- VC1 <- VC2 <- VC3 <- VC4 <- buddies
Other scenarios are also possible and would depend on a vendor's implementation of the ATM network.

When Chuck has had enough playing Aviator and wants to get back to some serious scuba diving off the Atlantic coast, the connection is torn down, and the VCI labels are resued for other connections.

10.0 What Assumptions can a user attachment make for a VCI label ?

As is probably obvious from the above example, none. The VCI labels are owned by network nodes, and get randomized quite quickly as connections come and go. A VCI label is handed to a user attachment only as an opaque cookie, and not much can be assumed about its spatial distribution other than quite random.

It may be possible to have certain reserved VCI labels similar in concept to "well known port definitions of UDP and TCP", as identifiers for special well known services that may be provided by the network. However very little can be assumed about the dynamically assigned VCI labels for most user related connections.

A service provider is unlikely to accede to any special request by any one service requester to allocate it a chunk of VCI labels, unless the network itself is owned by the service requester. Furthermore, the address space of the VCI labels is limited to 24 bits and only designed to identify the connections between two points on a single link. The address space would disappear rather quickly if customers started to requisition portions of the VCI label for their own semantics.

If there is a specific need to assume semantics for the VCI label outside of the ATM network, i.e. require it to be within a certain range on the user attachments at the UNI, it is probably best to provide a lookup table in hardware inside the user attachments which can map the pretty much randomized VCI label assigned by the network to n bits of a new label to which the user attachment can assign its own semantics to its silicon's content.

11.0 What Protocol layer is ATM ?

As is probably evident by now, ATM is designed for switching short fixed length packets in hardware over Gigabit/sec links across very large distances. Thus its place in the protocol stack concept is somewhere around the data link layer. However it does not cleanly fit in to the abstract layered model, because within the ATM network itself, end-to-end connection, flow control, and routing are all done at the ATM cell level. So there are a few aspects of traditional higher layer functions present in it. In the OSI reference model, it would be considered layer 2 (where layer 1 is the physical layer and layer 2 is the datalink layer in the internet protocol stack). But it is not very important to assign a clean layer name to ATM, so long as it is recognized that it is a hardware implemented packet switched protocol using 53 byte fixed length packets.

What is perhaps more relevant is how will all this interact with current TCP/IP and IP networks in general, and with applications which want to talk ATM directly in particular. A convenient model for an ATM interface is to consider it another communications port in the system. Thus from a system software point of view, it can be treated like any other data link layer port. Thus for instance, in IP networks connected via gateways to ATM backbones, the model would be no different then it presently is for a virtual circuit connection carried over an STM link except that an IP packet over an ATM network would get fragmented into cells at the transmitting UNI, and reassembled into the IP packet at the destination UNI. Thus a typical protocol stack might look like this:

	ATM Adaptation Layer
	ATM Datalink layer
	Physical Layer (SONET STS-3c STS-12 STS-48)

Thus just like an ethernet port on a host is assigned an IP address, the ATM port may also be assigned an IP address. Thus the IP software in a router decides which port to send a packet to based on the IP address, and hands the packet to the port. The port then does the right thing with it. For an ethernet port, the ethernet header is tacked on and the Frame transmitted in ethernet style. Similarly, for an ATM port, the IP datagram is fragmented into cells for which an ATM adaptation layer is specified in the standards. The fragmentation and reassembly is done in hardware on the sending and receiving sides. A VCI label acquired via an initial one time connection establishment phase, is placed in the header of each cell, and the cells are drained down the fat ATM datalink layer pipe. On the receiving side, the cells are reassembled in hardware using the ATM adaptation layer, and the original IP packet is reformulated and handed to the receiving host on the UNI. The adaptation layer is not a separate header, but is actually carried in the payload section of the ATM cell as discussed earlier.

For direct interface to an ATM cell stream from an application, new interfaces have to be designed in the software that can provide the application with nice and fast mechanisms for connection establishment, data transfer, keep alive, tear down, and even application level flow control. In this case the software processing steps may look like this:

	Application Streaming Data
	OS interface to application
	ATM virtual circuit management/signalling
	Driver interface to ATM

where the ATM virtual circuit management represents software which understands the ATM header specifics, sets up and tears down connections, does demultiplexing of the payload to appropriate connections, and responds to whatever standard signalling protocol is employed by the ATM interface at the UNI for connection management.

12.0 The Physical Layer

The physical layer specification is not explicitly a part of the ATM definition, but is being considered by the same subcommittees. T1S1 has standardized on SONET as the preferred physical layer, and the STS classifications refer to the speeds of the SONET link. STS-3c is 155.5 Mbit/sec. STS-12 is 622 Mbit/sec, and STS-48 is 2.4 Gbit/sec. The SONET physical layer specifications chalk out a world wide digital telecommunications network hierarchy which is internationally known as the Synchronous Digital Hierarchy (SDH). It standardizes transmission around the bit rate of 51.84 Mbit/sec which is also called STS-1, and multiples of this bit rate comprise higher bit rate streams. Thus STS-3 is 3 times STS-1, STS-12 is 12 times STS-1, and so on. STS-3c is of particular interest as this is the lowest bit rate expected to carry the ATM traffic, and is also referred to as STM-1 (Synchronous Transport Module-Level 1). The term SONET stands for Synchronous Optical Network and is the US terminology for SDH (since they had to differ in something). So much for the acronym soup.

The SDH specifies how payload data is framed and transported synchronously across fiber optic transmission links without requiring all the links and nodes to have the same synchronized clock for data transmission and recovery (i.e. both the clock frequency and phase are allowed to have variations, or be plesiochronous). The intention being that products from multiple vendors across geographical and administrative boundaries should be able to plug and play in a standard way and the Broadband ISDN network be a true international network. And guess what the fundamental clock frequency is around which the SDH or SONET framing is done ? You guessed it, 8Khz or 125 usec.

However all of this sits below the ATM layer and the ATM cells are transported across the physical layer as opaque payload, also called the SONET payload or the Synchronous Payload Envelope (SPE). The physical layer is independent of the payload type, and can just as easily carry STM cells as ATM cells. Refer to the standards documents for more details.

13.0 Flow control in ATM

Unlike the reactive end to end flow control mechanisms of TCP in internetworking, the gigabits/sec capacity of ATM network generates a different set of requirements for flow control. If flow control was left on end to end feedback, then by the time the flow control message was received at the source, the source would have already transmitted over several Mbytes of data into the ATM pipe exacerbating the congestion. And by the time the source reacted to the flow control message, the congestion condition might have disappeared altogether unnecessarily quenching the source. The time constant of end to end feedback in ATM networks (actually feedback_delay * link_bandwidth product) may be so large that solely relying on the user attachments to keep up with the dynamic network is impractical. The congestion conditions in ATM networks are expected to be extremely dynamic requiring fast hardware mechanisms for relaxing the network to steady state, and necessitating the network itself to be actively involved in quickly achieving this steady state. Thus a simplistic approach of end to end closed loop reactive control to congestion conditions is not considered sufficient for ATM networks.

The present consensus among the researchers in this field is to use a holistic approach to flow control. They recommend employing a collection of flow control schemes along with proper resource allocation and dimensioning of the networks to altogether try and avoid congestion, to try and detect congestion build up early by closely monitoring the internal queues inside the ATM switches and reacting gradually as the queues reach different high watermarks, and to try and control the injection of the connection data into the network at the UNI such that its rate of injection is modulated and metered there first before having to go to the user attachement for a more drastic source quenching. The concept is to exercise flow control in hardware very quickly, gradually, and in anticipation rather than in desperation. Rate based schemes which inject a controlled amount of data at a specified rate that is agreed upon at connection setup time, and automatically modulate the rate based on the past history of the connection as well as the present congestion state of the network have seen much press lately. The network state may be communicated to the UNI by the network very quickly by generating a flow control cell whenever a cell is to be dropped on some node due to congestion (i.e. the queues are getting full). The UNI may then police the connection by changing its injection rate, or notify the user attachment for source quenching depending on the severity level of the congestion condition.

The major challenge during flow control is to try and only affect those connection streams which are responsible for causing the congestion, and not affect other streams which are well behaved. And at the same time, allow a connection stream to utilize as much bandwidth as it needs if there is no congestion. This topic is still an area of active research, experimentation, and prolific publications including several PhD thesis.

14.0 Does an ATM network provide inorder delivery ?

Yes. An ATM cell may encounter congestion and suffer variable delay due to bufferring within the ATM switches, and may even be dropped either due to congestion control or due to header checksum error. However an ATM connection always obeys causality, the cells in a connection (i.e. cells with the same VCI label) arrive inorder at the destination. This is so because there is no store and forwarding in the network, cells travel over a single virtual circuit path, the ATM switches do not switch the cells in the same VCI out of order, and no retransmissions is done at any point in the ATM network.

Connectionless services are also supported on ATM networks, but these are implemented as a higher layer service layered over the ATM datalink layer. Thus cells in a connectionless service may arrive out-of-order because there might be multiple VCIs over multiple paths setup to deliver the connectionless datagrams and cells may arrive over different paths in different order. Thus the fragmentation reassembly engine which implements the connectionless datagrams, and which is layered on top of the basic connection oriented service of the ATM layer, must carry sequence numbers in the adaptation layer in each cell and correct any reordering of the cells at reassembly time. This is what the IEEE 802.6 protocol for MAN does to support its connectionless service class.

15.0 Does an ATM network provide reliable delivery ?

No. There is no end-to-end reliable delivery service at the ATM layer. The ATM layer does not do any retransmissions and there are no end-to-end acknowledgements for what has been received. Reliable delivery service can be implemented as a layer on top of the basic connection oriented ATM layer, where acknowledgement of received data and retransmission of missing data can be done for connections requiring reliable delivery. Thus a TCP type transport layer protocol (layer 4 in the OSI model) layered on top of the ATM layer is required for guaranteed delivery.

16.0 Performance of an ATM interface

Unlike STM networks, ATM networks must rely on considerable user supplied information for the traffic profile in order to provide the connection with the desired service quality. There are some sources of traffic which are easier to describe than others, and herein lies the cost/performance challenge for best bandwidth utilization in an ATM interface.

An ATM network can support many types of services. Connection oriented as well as connection less. It can support services which may fall in any of the four categories (loss sensitive, delay sensitive), (loss insensitive, delay sensitive), (loss sensitive, delay insensitive), and (loss insensitive, delay insensitive). It can further reserve and allocate a fixed bandwidth for a connection carrying a continuous bit stream for isochronous traffic (repeating in time such as 8khz voice samples), allocate a bandwidth range for a variable bit stream for plesiochronous traffic (variable frequency such as interactive compressed video), as well as allocate no specific amount of bandwidth and rely on statistical sharing among bursty sources. It may also provide multiple priorities in any of the above categories. The services can span the entire gamut from interactive such as telephony and on-line data retrieval, to distributed such as video and stereo Hi-Fi broadcasts and multicasts for conferencing and database updates.

Thus the performance that one might get from ones ATM connection is very much dependent on the parameters that are specified at connection setup time. Just because the link bandwidth may be an STS-12, does not necessarily imply that the end to end payload bandwidth that the ATM interface can sustain will also be STS-12. It will in fact be considerably lower based on connection setup parameters and the quality of service request, and whether bandwidth was reserved or statistically multiplexed, and the load on the ATM network.

Typically, the ATM network may not permit 100% loading of any link bandwidth, and in fact user available bandwidth may not be allowed to exceed more than 80% of the peak bandwidth of the link. The UNI may start policing and/or denying new connection requests on the link if utilization exceeds this amount. Add the approx 10% overhead of the 5 byte header in the 53 byte cell, and the max sustainable payload throughput on an ATM cell stream interface may peak at 72% of the peak link bandwidth. And this does not include any adaptation layer overhead if present, signalling overhead, or physical layer overheads of SDH SONET framing and inter-cell spacing gaps.

And of course, application to application bandwidth may be even less, unless the software datapath from the interface driver through the OS to the application (and vice versa) is very carefully optimized. It would hardly be received very well if the end-to-end throughput from application to application would turn out to be no better for an ATM port than for an ethernet or fddi port due to software overheads.

How many cells might be realistically received or transmitted at a sustained rate on an ATM cell interface in a processor ? Hard to say for sure as there is no existence proof as yet.

However, what can be stated is that the transmitter and receiver performance is independent of each other. The transmitter side is constrained by the flow control of the simultaneous connection streams by pacing the injection rate according to the respective negotiated class of service and bandwidth requirements. The receiver side is constrained by asynchronous reception of cells at a variable rate, and with bufferring capacity for a large number of simultaneous connections each of which can be receiving data simultaneously. And if an adaptation layer is used, then the reassembly of these cells into a higher layer protocol data unit (PDU) must also be done in hardware by the receiver side. Thus a lot of thought is required in designing an ATM interface to a host system, poor design of which can cripple the system performance.

17.0 When can I have my own connection to an ATM network ?

The Broadband ISDN with ATM is an enabling technology. It will enable new kinds of applications and new types of usage which are only in peoples imagination today. It is a complete overhaul of the copper based low bandwidth telecommunications technology that has existed until now, and represents a massive investment both in research and development, as well as deployment and integration. The software investment required to make the ATM network work is tremendous, and many of the algorithms and theories about how to manage the ATM network are still in their infancy and mostly on paper. Considerable work is also required in developing new network management paradigms and protocols to effectively control and manage the vasts quantities of bandwidths and services that the revolution in communication technology is promising to offer.

At the present time, there are no commercially available ATM networks in the US (to my knowledge), though there are several ATM prototype switches and experiments in existence. The earliest anticipated roll out of commercial ATM switches is expected no sooner than 1995 time frame. And full fledged deployment of ATM networks with "COST EFFECTIVE" multi-media integrated services to end-users is still a lot farther away, probably closer to the end of this decade. But its coming...hang on.