Asynchronous Transfer Mode (ATM) has been one of the hottest telecommunications topics for many years. Although ATM products and services are available, ATM is still in the early stages of its life-cycle. This article will provide an overview about ATM to describe what it is, how it will work, what its capabilities are, and some areas of current work.
DEFINITIONS
ATM is one of the family of high-speed, fast packet services, that includes frame relay and the Switched Multimegabit Data Service (SMDS). Fast packet switching technologies take advantage of the fact that today's networks employ digital signaling and optical fiber and are, therefore, much cleaner than "traditional" packet networks. Fast packet protocols, then, perform only minimal error checking and no error correction based upon the assumption that bit errors are rarely present. If an error is, in fact, found, the offending data is discarded; it is the responsibility of higher layer end-to-end protocols to fix errors.
There are many technology drivers for these new services, including the increased capability of microprocessors, the increasing speed of LANs, and the increasing bandwidth demand of graphics-based applications. A related trend shaping the design of the public network is the relatively large increase in the demand for data services (20-33% annual growth) versus the demand for traditional voice services (2-5% annual growth).
But ATM goes beyond the capabilities of frame relay and SMDS by extending the basic concepts of the Integrated Services Digital Network (ISDN); namely, the goal of a single network infrastructure that can be used to offer many different types of services. Increasingly, voice, video, image, and data are all transported digitally and, therefore, appear the same to network switches and transmission lines; while the service characteristics are all different, the switching and transport needs are the same.
ATM is the technology that has been chosen as the transport mechanism for Broadband ISDN (B-ISDN) services. B-ISDN has a relatively simple definition: it refers to those services that require channel speeds greater than 2 Mbps, which is the maximum speed of an ISDN Primary Rate Interface (PRI). B-ISDN services include videotelephony, videoconferencing, image mail, high-speed data transfer, information distribution services, user-controlled entertainment, and video on demand.
But B-ISDN services are not just characterized by high speed; they may also be described by their utilization of the available bandwidth, tolerable cell loss, and the tolerable amount of end-to-end delay. Voice, for example, requires a channel speed of 64 kbps, utilizes the entire bandwidth, cannot tolerate an end-to-end delay of much more than about 20-40 ms, and requires that the end-to-end delay remain relatively constant. LAN interconnection, on the other hand, might need a channel capacity of several tens of millions of bits per second, but is very bursty in nature, resulting in low bandwidth utilization; in addition, end-to-end delays of several hundred milliseconds is acceptable and this delay may vary widely from packet to packet.
So, what is ATM? ATM combines the best aspects of traditional round-robin time division multiplexing (TDM) and statistical multiplexing. TDM transmission (such as a T-1 carrier) uses fixed-size time slots, each of which is allocated to a specific application or user. The downside of TDM is that if a user has no data to send when its time slot comes around, the time slot remains unused, resulting in wasted bandwidth. Statmuxing answers this concern by never letting the transmission line to be idle as long as any user has data to send. The downside of statmuxing is that every transmission needs to carry an address since ownership can no longer be inferred by the time at which a transmission arrives.
ATM is a form of cell relay, where all transmitted data is fragmented into (small) fixed-size data units called cells. Cell relay technology greatly simplifies the statistical multiplexing of many different types of services, such as voice, video, image, graphics, and data. The term asynchronous is used because the ownership of a cell is not dependent upon the time when the cell arrives at the destination.
Another potential advantage of ATM is that it is a scalable technology. This means that ATM may be able to be used at speeds ranging from the very slow (1.544 Mbps or less) to the very fast (10 Gbps and above). It also means that the geographic scope of ATM can vary; the same technology that can be employed in a LAN or campus backbone may also be employed in the infrastructure of the wide-area public telecommunications network. This suggests a very smooth migration of applications and increased performance since protocol conversion and translation can be eliminated.
ATM STANDARDS AND INTERFACES
Several organizations are involved in creating ATM specifications, all with a slightly different charter. The International Telecommunication Union - Telecommunication Standardization Sector (ITU-T; formerly the CCITT) originally defined ATM as part of their B-ISDN recommendation suite. The American National Standards Institute (ANSI) is responsible for U.S. national ATM standards.
Although not a formal standards body, perhaps the most important ATM group at this time is the ATM Forum, comprising ATM product manufacturers and service providers. The ATM Forum defines Implementation Agreements (IAs), which represent agreements for product and service implementations amongst the several hundred member companies of the Forum. Unlike the formal standards process, draft IAs are not available to non-members and non-members may not comment on draft specifications. ATM Forum IAs are typically forwarded to ANSI and the ITU-T for formal national and international adoption.
{===============================}
----------- { ----------- ----------- } {=========}
|Broadband| { |Broadband| |Broadband| } { IEC }
|Terminal |---+---{-|Switching|---+---|Switching|-}----+----{ ATM }
|Equipment| UNI { | System | NNI | System | } B-ICI { Network }
----------- { ----------- ----------- } {=========}
{===============================}
LEC ATM Network
The ATM specifications focus on three interfaces (Figure 1). The User-Network Interface (UNI) defines the set of services that will be offered to network subscribers by an ATM network provider. The UNI includes the rules for how users will send data into the network and how users will specify the characteristics of the service that they want. UNI 3.0, approved in September 1993, and UNI 3.1, approved the following September, both incorporate call control signaling, but were based upon slightly different versions; for that reason, UNI 3.0 does not interoperate with UNI 3.1. UNI 4.0 is expected in mid-1995.
The Network Node Interface (NNI) defines how switches within a local carriers' network will communicate. The purpose of a standard NNI is so that a local exchange carrier (LEC) is not limited to using a single vendor's switches. The Broadband Intercarrier Interface (B-ICI) defines the interface between a LEC's network and an interexchange carrier's (IEC) network.
ATM utilizes a 53-octet cell, comprising a 5-octet Header and 48-octet Payload. The size of the cell was chosen to balance the requirements of latency and protocol efficiency. If a cell is transporting time-sensitive traffic, such as voice, it collects a sample every 125 microseconds. Since the cell Payload should be as full as possible, it follows that the amount of time it takes to construct a cell will be directly related to size of the Payload; small Payloads, then, will result in small assembly delay. When cells are transporting user data, however, protocol efficiency is the key criteria; efficiency increases as cell size grows because the header overhead remains constant. Selecting a 48-octet Payload (and 5-octet Header) was a compromise; it takes 6 milliseconds to gather 48 digital voice samples and only about 9% of the cell represents overhead.
ATM PROTOCOLS AND SERVICES
Figure 2 shows the ATM protocol stack. The bottom-most layer is the Physical Layer, responsible for moving cells within the ATM network. The Physical Layer performs include medium-specific functions (such as bit timing, medium characteristics, and physical connectors) as well as medium-independent transmission functions (such as framing and signaling).
--------------------------- |Application |Application | |------------+------------| |Higher Layer|Higher Layer| | Protocol | Protocol | |------------+------------| | ATM Adaptation Layer | |-------------------------| | ATM Layer | |-------------------------| | Physical Layer | ---------------------------
ATM was originally envisioned to operate over optical fiber facilities; the ITU-T, in fact, specifically refers to Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) speeds of 155.52 and 622.08 Mbps. The ATM Forum, ANSI, Bellcore, and other organizations are also defining and/or exploring many other speed and media options for the UNI, including DS1 (1.544 Mbps), DS3 (44.736 Mbps), type 3 unshielded twisted pair (UTP-3) at 25 and 51 Mbps, and UTP-5 using FDDI's Transparent Asynchronous Transmitter/Receiver Interface (TAXI) at 100 Mbps.
The next layer in the ATM protocol stack is the ATM Layer. ATM provides a connection-oriented cell switching service, meaning that a logical connection between two ATM hosts must be in place before information may be exchanged between those two hosts. The ATM Layer is primarily responsible for the generation of the cell Header and the functions associated with the Header, including the switching and routing of cells, flow control, congestion notification, bit error detection in the Header, and cell delineation.
8 7 6 5 4 3 2 1 --------------------------------- | GFC | VPI | |---------------+---------------| | VPI | VCI | |-------------------------------| | VCI | |-------------------------------| | VCI | PTI |CLP| |-------------------------------| | HEC | ---------------------------------
Figure 3 shows the format of the cell Header, as used across the UNI. The fields of the Header, and their function, are:
----------- ----------- | Upper | | Upper | | Layer |<----------------------------------------->| Layer | |Protocols| |Protocols| |---------| |---------| | AAL |<----------------------------------------->| AAL | |---------| ----------- ----------- |---------| |ATM Layer|<--+-->|ATM Layer|<--+-->|ATM Layer|<--+-->|ATM Layer| |---------| | |---------| | |---------| | |---------| |Physical | | |Physical | | |Physical | | |Physical | | Layer |<--+-->| Layer |<--+-->| Layer |<--+-->| Layer | ----------- UNI ----------- NNI ----------- UNI ----------- HOST BSS BSS HOST
The Physical Layer and ATM Layer, taken together, provides the facilities for the connection-oriented transport of cells. These two protocol layers must be implemented in every ATM device, including end-user hosts and broadband switching systems (BSS), as shown in Figure 4.
The ATM Adaptation Layer (AAL) is an end-to-end protocol that provides the interface between the ATM Layer and higher layer protocols and applications. The AAL is responsible for accepting messages from higher layer protocols and fragmenting them into smaller entities for transport in cells. It is also responsible for providing any necessary additional services that might be expected by the higher-layer application, such as timing, synchronization, sequencing, and error detection and/or correction.
It is the capabilities of the ATM Adaptation Layer that makes ATM able to support a wide variety of services. The services are defined by the ITU-T in terms of their service classes (Figure 5), which are distinguished by a variety of communications parameters, including:
------------------------------------------------
Service Class | A | B | C | D |
|-----------------------------+----------------|
Mode | Connection-oriented | Connectionless |
|----------------------------------------------|
Bit Rate | Constant | Variable |
|----------------------------------------------|
Delay Tolerance | Delay-sensitive | Delay-insensitive |
|--------------------+-------------------------|
| Circuit | Packet | Frame | |
Example | Emulation | Video | relay, | SMDS, IP |
| (voice) | | X.25 | |
|-----------+--------+--------+----------------|
Type | 1 | 2 | 3/4, 5 | 3/4, 5 |
------------------------------------------------
Figure 5 also denotes the AAL type, which describes the format of the user data in the cell Payload, which will differ based on the service class being supported. AAL Type 1 (AAL1), for example, is defined for Class A service. An AAL1 Payload contains one octet of overhead for clocking and sequencing plus 47 octets of user data. AAL2 has not yet been defined; it is a place-holder for packet video services.
AAL3 and AAL4 were defined for Class C and D services, respectively, and the definitions were merged in 1991 (now called AAL3/4). AAL3/4 takes a block of user data (an IP packet, for example, or a frame relay frame), adds some overhead information for end-to-end transport across the network, and then fragments this data for transport in the cell; each AAL3/4 Payload contains 4 octets of additional protocol overhead and 44 octets of user data. AAL5 was also defined for Class C services. AAL5 takes a higher layer user data packet, adds some protocol overhead information, and then fragments the new packet into 48-octet blocks for transport in the Payload. AAL5 uses all 48 octets of the Payload for user data compared to the 44 octets of user data in an AAL3/4 cell, and has been shown to demonstrate 20-30% better throughput.
---------------------------------------------------------------- | | | GUARANTEES | | | SERVICE | DESCRIPTORS |--------------------| FEEDBACK | | | |Loss|Delay|Bandwidth| | |=========+====================+====+=====+=========+==========| | CBR | PCR, CDVT |Yes | Yes | Yes | No | |---------+--------------------+----+-----+---------+----------| | VBR-RT | PCR, CDVT, SCR, BT |Yes | Yes | Yes | No | |---------+--------------------+----+-----+---------+----------| | VBR-NRT | PCR, CDVT, SCR, BT |Yes | Yes | Yes | No | |---------+--------------------+----+-----+---------+----------| | UBR | Unspecified |No | No | No | No | |---------+--------------------+----+-----+---------+----------| | ABR | PCR, CDVT, MCR |Yes | No | Yes | Yes | ----------------------------------------------------------------
FIGURE 6. ATM Forum service definitions.
Figure 6 shows the service class definition that has been defined by the ATM Forum for UNI 4.0. The ATM Forum is defining service classes based upon the QoS guarantees needed by the service and whether appropriate feedback control mechanisms are in place to control the amount of cell loss during peak traffic times in the network.
The ATM Forum defines five service classes. Continuous Bit Rate (CBR) and Variable Bit Rate - Real Time (VBR-RT) services roughly correspond to Class A and Class B services, respectively. Variable Bit Rate - Non Real Time (VBR-NRT) is similar to VBR-RT, except with much less stringent time constraints.
Unspecified Bit Rate (UBR) and Available Bit Rate (ABR) services are intended for delay-insensitive traffic, such as that defined in Classes C and D. These classes were defined for the following reason. CBR and VBR services will get priority access to a channel's bandwidth. Why, then, try to allocate a specific amount of bandwidth to delay-insensitive data since data will just get whatever bandwidth is left over anyway? UBR is a best-effort delivery scheme; lack of a feedback mechanism means that cells may be discarded during periods of congestion. ABR service (sometimes called Class Y) is defined to support bursty data applications (such as TCP/IP and LAN interconnection). An ABR service is allocated all of the bandwidth that is needed by the application and available on the channel; feedback mechanisms will throttle the sending host to minimize cell loss as the available amount of bandwidth shrinks and grows.
So, what is the significance of service classes and AAL types? Service classes allude to the QoS guarantees that a network can deliver to the customer. When a network subscriber establishes a virtual connection, a service class and any appropriate QoS parameters are associated with that connection. In today's public ATM service offerings, some combination of Class C, Class D, UBR, or ABR services are supported; neither CBR (Class A) nor real-time VBR (Class B) services are generally available from network providers.
The AAL type describes the specific cell format that the end-user equipment can recognize. Equipment from some particular vendor may support voice over ATM, for example, even in the absence of a network's Class A or CBR service; the equipment may use AAL1, another AAL, or a proprietary Payload format. The Payload format is, in fact, irrelevant to how the network handles and switches cells; after all, cells is cells.
Finally, the higher layer protocols support the end-to-end user applications. Any set of protocols and applications should be able to operate over ATM.
OTHER RELATED SPECIFICATIONS
There are a number of other ATM-related specification that are currently under development within the ATM Forum and other organizations. One of the hottest topics is that of ATM LAN Emulation (LANE). ATM is being examined both to interconnect so-called "legacy" LANs (such as Ethernet and token ring) as well as to directly support LAN applications. Initial LANE specifications are expected from the ATM Forum by the summer of this year.
Circuit emulation service (CES) over ATM is another hot topic. To support a 64 or Nx64 kbps CBR service, such as voice or video, the ATM network has to dedicate an appropriate amount of bandwidth (or some number of cells per unit time) to that application. Among the issues to be resolved are how to precisely control the bit rate, recover timing information from the cell stream, and format the Payload. Initial CES specifications are expected in the spring of this year.
A related issue is the support of video over ATM. While supporting video over a CBR service is feasible, it is not the preferred method because of the enormous bandwidth requirements. The Motion Pictures Expert Group (MPEG) compression scheme is the one most likely to be used with ATM, although it is not yet clear how to carry MPEG information in ATM cells, particularly with respect to timing and error recovery. While AAL2 was defined specifically for packet video, it appears that much of the work in this area is focusing on using AAL5 instead and, possibly, dropping AAL2 altogether. Initial specifications in this area are expected by the end of the year.
Internetworking ATM with other services is critically important since it helps ensure the graceful adoption of ATM and assures the long-term viability of the other services. A frame relay/ATM interworking implementation agreement was adopted in 1993 by the ATM Forum and Frame Relay Forum, defining how frame relay frames should be carried in ATM cells and how to handle such functions as bit-error detection, congestion notification, and bandwidth management. In 1994, the ATM Forum, SMDS Interest Group (SIG), and European SIG developed a specification for SMDS over AAL3/4. A final example is the work on-going within the Internet Engineering Task Force (IETF) to define the transport of IP datagrams and IP address resolution in an ATM network.
The ATM Data Exchange Interface (DXI) is another important specification. Users connecting a LAN to an ATM service will almost certainly employ a router. However, not all routers are capable of creating an appropriate AAL data packet and creating ATM cells; many routers can create the packet but require an ATM data service unit (ADSU) to fragment the packet into cells. In this environment, the ATM DXI must be employed; it is a protocol that specifies how the router and ADSU should exchange information. The ATM DXI, completed in 1993, is probably an interim standard; eventually all routers will support "native-mode" ATM and be able to directly generate cells, obviating the need for a special ADSU.
ATM provides a connection-oriented, or virtual circuit, service. To date, ATM services utilize permanent virtual circuits (PVC), meaning that the customer must define the characteristics of the connection, including the end-points, at the time of service subscription. Switched virtual circuits (SVC) add tremendous flexibility to an ATM service by allowing connections to be established on-demand between any two points. The user-network signalling for this purpose will use ISDN-like call control, where the user equipment specifies the characteristics of the connection (such as the service class, required bandwidth, and QoS parameters) at connection setup time. ITU-T Recommendation Q.2931 defines these signaling procedures; a subset of Q.2931 is employed by the ATM Forum UNI.
Finally, network management has emerged as an increasingly important tool in the last five years, particularly as user's telecommunications networks and devices become increasingly complex. The ATM Forum has developed the Interim Local Management Interface (ILMI), based on the Simple Network Management Protocol (SNMP), so that one UNI can learn about the configuration at the UNI at the other end of a virtual connection. The IETF has produced an ATM Management Information Base (MIB) for SNMP, while the ATM Forum has produced an ATM DXI MIB; other MIBs are under development. Lastly, Bellcore is developing a framework for Customer Network Management (CNM) so that customers of an ATM service can manage certain aspects of the service from their own local network management systems.
CONCLUSION
It could probably be argued that ATM is not the optimal technology for voice or video or data or image traffic. ATM is, however, currently viewed as the optimal technology available for integrating voice and video and data and image traffic on a single network infrastructure. The ATM applications of today are relatively modest compared to the potential of the future, and the total promise is still some years away. ATM is receiving an excellent level of support from the service provider and equipment vendor community; most LECs and IECs are offering, or intend to offer, an ATM service, while available products include routers, ADSUs, campus and wide area switches, and protocol analyzers.
There are a variety of sources for additional information about ATM. One good text is ATM: Theory and Application by David McDyson and Darren Spohn (McGraw-Hill, 1994); another is ATM Networks by Rainer Handel, Manfred Huber, and Stefan Schroder (Addison-Wesley, 1994). There is also a Usenet/Internet discussion list devoted to cell relay, ATM, and related topics at comp.dcom.cell-relay@indiana.edu (Internet users can subscribe to this list by sending e-mail to cell-relay-request@indiana.edu; place the line "subscribe cell-relay" in the body of the message). Finally, Table 1 lists a number of Internet sites that contain ATM-related information; the Frequently Asked Questions (FAQ) list is a particularly good place to start looking.
TABLE 1. Some Internet sites hosting ATM-related information.
ATM Forum web site
ATM Forum ftp server
ATM Interoperability Lab (IOL), U. NH
ATM 25 Alliance (ftp)
"Cell Relay Retreat"
"Cell Relay Retreat" ftp archive (including DSS 2, QSAAL...)
SGI "ATM Primer"
LANL "ATM Tutorial"
ATM Chip Web
ATM products
ATM Component Review (subscription)
ATM & Linux
ATM references
IP over ATM information
IP over ATM (ftp)
AT&T's WWW server
AT&T's ATM ftp server
Adaptec ATM products
ATM 25 Alliance
Bellcore ATM docs (ftp)
Cambridge University ATM Document Collection
Fore Systems ATM ftp archive
Herwig's ATM Page (lots of pointers...)
Newbridge VIVID ATM Web page
North Carolina State U. ftp archive (ATM/QoS/Multimedia papers)
Purdue U. ATM info
Telecom Finland ATM ftp archive (ITU-T, ANSI, other ATM specs.)
ATM/gigabit networks
CANARIE ATM testbed network
European ATM Project
NASA's ATM switch technology and vendor
survey
Network for Engineering & Research in Oregon
North Carolina Information Highway
SURFnet4 Project
Network performance (ATM)
Performance Database Server at the University of Kentucky
Performance SPEC FAQ
Video-conferencing on Fore ATM (ftp)
Wireless ATM (Ohio State)
Wireless ATM (Olivetti)
Keshav's ATM papers at AT&T