With a promise to support a full range of
applications through a core broadband backbone, ATM has caught
the imagination of a wide spectrum of users. To deliver on this
promise, the ATM Forum and its participants have crafted a
protocol layer flexible enough to provide the mechanisms needed
to adapt the cell transmissions into the necessary higher level
behaviors. ATM has been designed to support applications
including broadband ISDN, carrying multiple synchronous
information channels, as a transfer mechanism for frame-relay and
Switched Multi-Megabit Data Service (SMDS) applications, and
finally as a link-transport mechanism for Local Area Networks.
Each of these types of interfaces requires special mapping
services to operate over the ATM cell structure. The AAL provides
these mappings. These classes of service are mapped to the AAL
protocols 0 through 5, referred to as AAL0, AAL1, etc. Figure 1
shows the relationship of the AAL, its major components with the
remainder of the ATM protocol stack. Residing above the ATM
layer, the AAL protocol elements transfer their information over
one or more ATM cells.
Figure 2 shows the internal components of the
AAL. The services provided by each of these components is as
follows: As the information is transferred through each of
these layers it takes on a different format. The Service Data
Units (SDU) is the representation of data between two service
layers; for example, the ATM SDU is presented to the SAR layer
for AAL processing. The Interface Data Unit (IDU) is a
subcomponent of the SDU; one or more IDUs can contribute to a
single SDU. Finally, the familiar term Protocol Data Unit (PDU)
is used to represent data between a sublayer and its supporting
sublayer. With these options, the way information is named can
become confusing.
AAL is the simplest and least useful of the AAL
service classes is AAL-0. This class of service provides a direct
interface into the ATM layer by users. It has been included in
the standard to permit equipment designers to disregard the AAL
in its entirety. While some had envisioned AAL-0 to useful in
supporting control and service messaging, it lacks the guaranteed
delivery mechanisms that are critical to many network control
functions. For proprietary systems this can be useful. For
systems that must operate in open environments, with equipment
from multiple vendors, this "feature" should probably
be avoided. It doesn't provide much in the way of an aid to
interoperability. In support of synchronous networking, AAL-1
provides a constant rate bit-stream between the two ends of an
ATM connection. The data stream is locked to a fixed timing
reference. While providing steady rate transfer is a relatively
simple matter over a single synchronous interface, the
asynchronous nature of ATM provides a significant challenge.
Variations in a network's ability to deliver ATM traffic can
result in significant jitter that impedes orderly reassembly of
the synchronous traffic stream. Figure 3 shows the format of the
AAL-1
Some of the most interesting aspects of AAL-1 are
involved in clock recovery. Send too much information and data
must be dropped. Send too little (too slow), and information must
be padded. Two general approaches to resolving these issues have
been proposed, Synchronous Residual Time Stamp where the clocks
on both ends of a network connection are synchronized, and
Adaptive Clock, in which the receiver adjusts the speed of its
clock on the basis of the amount of information available in its
receive buffers. AAL-2 is based on the assumption that some forms of
isochronous information can be represented in a multiple data
rate format. For example, the rate of some video compression
techniques can vary on the basis of the complexity and rate of
change of moving images. While this portion of the standard has
been highlighted, it is absent from the published standards. Based on the SMDS standard, AAL-3/4 provides data transport
services for both connection and connectionless data. These
services correspond to Class C and Class D data. Unlike AAL-0 and
AAL-1, AAL-3/4 includes a range of service options. Information
is transferred in either message or streaming mode. Optional
delivery assurance techniques include discarding faulty SDUs,
end-to-end data recovery, and delivery of all SDUs regardless of
their integrity. Assured transmission through retransmission is
discussed in the standards, but is not fully specified.
Non-assured transmission is supported in the standard, with
options to deliver or discard faulty SDUs. Typically, it is most
useful to discard faulty SDUs. Delivery of unreliable information
is typically something to avoid. Several logical AAL connections
can be multiplexed over a single ATM Virtual Circuit (VC).
Finally, AAL-3/4 provides a capability to support multipoint
delivery of information from a single source. To support this set of services, the AAL-3/4 architecture is
considerably more involved than the other AAL protocols. Active
processing is performed by both the CPCS and SAR layers to
provide additional functions. Processing steps include receipt of
the User data frame to AAL, CPCS formatting of the AAL-PDU for
transmission to the destination, followed by forwarding of the
CPCS-PDU to the SAR layer for segmentation into a set of 44-byte
PDUs for transmission (with 3 octets of SAR control information)
over the ATM layer. On receipt of the ATM PDU, the opposite
process ensues, with the SAR reassembling the stream of SAR-PDUs
into a single CPCS-PDU, and delivering the received CPCS-PDU to
the CPCS for final processing and delivery of information to the
user. A summary of these processes follows. The AAL-3/4 CPCS is responsible for managing the integrity of
AAL-3/4 information. It additionally pads the information
data-block size to an even multiple of 4 octets, simplifying
protocol processing by CPUs such as the Motorola 680x0 series
that are popular in telecommunications systems. Figure 4 shows
the format of the CPCS-PDU. The fields of the PDU and their use
are:
The Segmentation and Reassembly Sublayer manages
the fragmentation and reassembly of the AAL-3/4 CPCS-PDUs into
payload information that can be carried by the ATM cells. The
format of the SAR-PDU is shown in Figure 5. The SAR-PDU fields
and there application are as follows:
While the AAL-3/4 provides a rich set of
services, it does so at the expense of additional protocol
overhead and processing. AAL-5, originally coined the Simple and
Efficient Adaptation Layer (SEAL) was designed to provide similar
services at lower overhead. This AAL takes advantage of the ATM
End of Message (EOM) flag to signal the end of a single message.
Significant overhead is elimated by removing the SAR header and
trailer. Processing involves construction of a CPCS-PDU (shown in
Figure 6) that can carry between 1 and 65535 octets, that is
segmented into a series of 48 octet SAR-PDUs for ATM
transmission.
Components of the AAL-5 CPCS-PDU are: Through services provided by the AAL protocols,
user applications are able to realize the full scope of services
promised by ATM.
AAL - ATM Adaptation Layer
Providing the glue to support the full range of ATM services.
AAL protocols have been defined to support five classes of
service:
Figure 1 - AAL Service Classes & AAL Types
Figure 2 - AAL Sublayers
AAL-0 NULL AAL
AAL-1 Supports Class A Constant Bit Rate Traffic
SAR-PDU, that is sent over a single ATM cell. AAL-1 PDU fields
include the Sequence Number that consists of a three-bit
repeating sequence number, and a "CS-indication" bit, a
4-bit Sequence Number Protection (SNP) field that protects
against sequence number errors, and a 47-octet payload.
Typically, this payload field is intended to be filled, however,
it can be partially used based on prenegotiated operation.
Figure 3 - AAL-1 Cell Format
AAL-2 Variable Rate Synchronous Service
AAL-3/4 End-To-End Data Transport
Figure 4 - AAL-3/4 CPCS PDU Format
Figure 5 - SAR-PDU Format
AAL-5 Simple Data Transfer
Figure 6 - AAL-5 CPCS-PDU