ATM adaptation layer

From Wikipedia, the free encyclopedia

This article does not cite any references or sources.
Please help improve this article by adding citations to reliable sources. Unsourced material may
be challenged andremoved. (March 2008)

The use of Asynchronous Transfer Mode (ATM) technology and services creates the
need for an adaptation layer in order to support information transfer protocols, which
are not based on ATM. This adaptation layer defines how to segment and
reassemble higher-layer packets into ATM cells, and how to handle various
transmission aspects in the ATM layer.

Examples of services that need adaptations are Gigabit Ethernet, IP, Frame
Relay, SONET/SDH, UMTS/Wireless, etc.

The main services provided by AAL (ATM Adaptation Layer) are:

 Segmentation and reassembly

 Handling of transmission errors
 Handling of lost and misinserted cell conditions
 Timing and flow control

The following ATM Adaptation Layer protocols (AALs) have been defined by the ITU-
T. It is meant that these AALs will meet a variety of needs. The classification is
based on whether a timing relationship must be maintained between source and
destination, whether the application requires a constant bit rate, and whether the
transfer is connection oriented or connectionless.

 AAL Type 1 supports constant bit rate (CBR), synchronous, connection

oriented traffic. Examples include T1 (DS1), E1, and x64 kbit/s emulation.
 AAL Type 2 supports time-dependent Variable Bit Rate (VBR-RT) of
connection-oriented, synchronous traffic. Examples include Voice over ATM.
AAL2 is also widely used in wireless applications due to the capability of
multiplexing voice packets from different users on a single ATM connection.
 AAL Type 3/4 supports VBR, data traffic, connection-oriented, asynchronous
traffic (e.g. X.25 data) or connectionless packet data (e.g. SMDS traffic) with an
additional 4-byte header in the information payload of the cell. Examples include
Frame Relay and X.25.
  AAL Type 5 is similar to AAL 3/4 with a simplified information header
scheme. This AAL assumes that the data is sequential from the end user and
uses the Payload Type Indicator (PTI) bit to indicate the last cell in a
transmission. Examples of services that use AAL 5 are classic IP over ATM,
Ethernet Over ATM, SMDS, and LAN Emulation (LANE). AAL 5 is a widely used
ATM adaptation layer protocol. This protocol was intended to provide a
streamlined transport facility for higher-layer protocols that are connection
oriented.

AAL 5 was introduced to:

 reduce protocol processing overhead.

 reduce transmission overhead.
 ensure adaptability to existing transport protocols.

The AAL 5 was designed to accommodate the same variable bit rate, connection-
oriented asynchronous traffic or connectionless packet data supported by AAL 3/4,
but without the segment tracking and error correction requirements.
AAL: ATM Adaptation Layer (AAL0, AAL2, AAL3/4, AAL5)

The ATM Adaptation Layer (AAL) relays ATM cells between ATM Layer and higher
layer. When relaying information received from the higher layers, it segments the
data into ATM cells. When relaying information received from the ATM Layer, it must
reassemble the payloads into a format the higher layers can understand. This
operation, which is called Segmentation and Reassembly (SAR), is the main task of
AAL. Different AALs were defined in supporting different traffic or service expected to
be used. The service classes and the corresponding types of AALs were as follows:

Class A - Constant Bit Rate (CBR) service: AAL1 supports a connection-oriented

service in which the bit rate is constant. Examples of this service include 64 Kbit/sec
voice, fixed-rate uncompressed video and leased lines for private data networks.

Class B - Variable Bit Rate (VBR) service: AAL2 supports a connection-oriented

service in which the bit rate is variable but requires a bounded delay for delivery.
Examples of this service include compressed packetized voice or video. The
requirement on bounded delay for delivery is necessary for the receiver to
reconstruct the original uncompressed voice or video.

Class C - Connection-oriented data service: For connection-oriented file transfer and

in general, data network applications where a connection is set up before data is
transferred, this type of service has variable bit rate and does not require bounded
delay for delivery. Two AAL protocols were defined to support this service class, and
have been merged into a single type, called AAL3/4. But with its high complexity, the
AAL5 protocol is often used to support this class of service.

Class D - Connectionless data service: Examples of this service include datagram

traffic and in general, data network applications where no connection is set up before
data is transferred. Either AAL3/4 or AAL5 can be used to support this class of
service.

Operation Administration and Maintenance (OA&M) - OA&M is defined for

supervision, testing, and performance monitoring. It uses loop-back for maintenance
and ITU TS standard CMIP, with organization into 5 hierarchical levels: Virtual
Channel (F5 - Between VC endpoints), Virtual Path (F4- Between VP endpoints),
Transmission Path (F3- Between elements that perform assembling, disassembling of
payload, header, or control), Digital Section (F2 Between section end-points,
performs frame synchronization) and Regenerator Section (F1- Between
regeneration sections).

Network Monitoring and Technical books, quick guides

Troubleshooting
Easy to use tool with comprehensive
features at a fraction of the cost of
others.
Click here for free demo.
and posters
Networking, telecom, computing,
wireless, information technologies,
security and much more ...
Click here for details.
Protocol Structure - AAL: ATM Adaptation Layer (AAL0, AAL2, AAL3/4,
AAL5)

AAL0 PDU:

AAL0 payload consists of 48 bytes without special field, is also referred to as raw
cells.

AAL1 PDU:

1 3 bits 3 bits 1 47 Bytes

SN SNP SAR
CSI SC CRC P Payload

• SN- Sequence number. Numbers the stream of SAR PDUs of a CPCS PDU
(modulo 16).
• CSI- Convergence sublayer indicator. Used for residual time stamp for
clocking.
• SC- Sequence court.
• NP- Sequence number protection.
• CRC- Cyclic redundancy check calculated over the SAR header.
• P- Parity calculated over the CRC.
• SAR PDU payload- 47-byte user information field.

AAL2 PDU : AAL2 is perfect for low-rate voice traffic, with compression, silent and
idle channel suppression. AAL type 2 is subdivided into the Common Part Sublayer
(CPS ) and the Service Specific Convergence Sublayer (SSCS ).

AAL2 CPS Packet

The CPS packet consists of a 3 octet header followed by a payload. The structure of
the AAL2 CPS packet is shown in the following illustration.

8bits 6bits 5bits 5bits 1-45/64 bytes

CID LI UUI HEC Information payload
AAL2 CPS packet

• CID- Channel identification.

• LI- Length indicator: the length of the packet payload associated with each
individual user. Value is one less than the packet payload and has a default
value of 45 bytes (may be set to 64 bytes).
• UUI- User-to-user indication. Provides a link between the CPS and an
appropriate SSCS that satisfies the higher layer application.
 • HEC- Header error control.
• Information payload- Contains the CPS/SSCS PDU.

AAL2 CPS PDU

The structure of the AAL2 CPS PDU is shown as follows:

6bits 1bit 1bit 0-47 bytes 0-47 bytes

OSF SN P AAL2 PDU payload PAD
AAL2 CPS PDU

• OSF - Offset field. Identifies the location of the start of the next CPS packet
within the CPS-PDU.
• SN - Sequence number. Protects data integrity.
• P - Parity. Protects the start field from errors.
• SAR PDU payload - Information field of the SAR PDU.
• PAD - Padding.

AAL2 SSCS Packet

The SSCS conveys narrowband calls consisting of voice, voiceband data or circuit
mode data. SSCS packets are transported as CPS packets over AAL2 connections.
The CPS packet contains a SSCS payload. There are 3 SSCS packet types: Type 1
Unprotected; this is used by default; Type 2 Partially protected; and Type 3 Fully
protected: the entire payload is protected by a 10-bit CRC which is computed as for
OAM cells. The remaining 2 bits of the 2-octet trailer consist of the message type
field.

AAL2 SSCS Type 3 Packets:

The AAL2 type 3 packets are used for Dialled digits, Channel associated signalling
bits, Facsimile demodulated control data, Alarms and User state control operations.
The general sturcture of AAL2 SSCS Type 3 PDUs is shown as follows. The format
varies according to the actual message type.

2bits 14bits 16bits 6bits 10bits

Redundancy Time stamp Message dependant information Message type CRC-10
AAL2 SSCS Type 3 PDU - General Structure

• Redundancy - Packets are sent 3 times to ensure error correction. The value
in this field signifies the transmission number.
• Time stamp - Counters packet delay variation and allows a receiver to
accurately reproduce the relative timing of successive events separated by a
short interval.
 • Message dependant information
Packet content that varies, depending on the message type.
• Message type - The message type code.
• CRC-10 - The 10-bit CRC.

AAL3/4 PDU:

2 4 10 bits 44 Bytes 6 bits 10 bits

ST SN MID PDU Payload LI CRC

• ST -Segment Type: BOM (Begin of Message), COM (Continuation of

Message), EOM (End of Message), SSM (Single Segment Message).
• SN -Sequence number. Numbers the stream of SAR PDUs of a CPCS PDU
(modulo 16).
• MID - Multiplexing Indication
• PDU payload -44-byte user information field.
• LI -Length indicator.
• CRC -Cyclic redundancy check calculated over the SAR header.

AAL3/4 CS PDU:

1 1 2 bits 40 Bytes 1 1 2 bits

CPI BTag BAsize PDU Payload + PAD AL ETag LEN

• CPI - Common Part Indication

• BTag -Beginning Tag
• BAsize -Buffer Allocation Size
• PDU payload -Variable length user information field up to 40 Bytes
• PAD -Padding (up to 3 bytes) used to cell align the trailer.
• AL -Alignment. A filling byte coded with zero
• ETag -End Tag.
• LEN -Length of Information Field

AAL5 CS PDU:

0-48 Bytes 0-47 1 1 2 4 Bytes

PDU payload PAD UU CPI LI CRC-32

AAL5 is the simple and efficient AAL (SEAL) which is the one used most for data
traffic; it has no per-cell length nor per-cell CRC fields.

• PDU payload -Variable length user information field

 • PAD -Padding used to cell align the trailer which may be between 0 and 47
bytes long.
• UU -CPCS user-to-user indication to transfer one byte of user information
• CPI - Common Part Indication
• LI -Length indicator.

For OA&M cells, there are pre-defined (reserved) VPI/VCI numbers:

• 0/0 Unassigned or Idle0/1 Meta-signaling

• 0/3 Segment F4 Flow0/4 End-to-end F4 flow
• 0/5 Signaling 0/15 SMDS
• 0/16 Interim Layer Management Interface (ILMI)

F4/F5 OA&M PDU format:

4 bits 4 bits 45 Bytes 6 bits 10 bits

OAM Type Function Type Function Spec Reserve CRC-10

• OAM type / Function type- The possible values for OAM type and function type
are defined for Fault, Performance, Activation/Deactivation
• CRC-10 -Cyclic redundancy check calculated over the SAR header. G(x) =
x10+x9+x5+x4+x+1
ATM Adaptation Layer 2
From Wikipedia, the free encyclopedia
(Redirected from AAL Type 2)

ATM Adaptation Layer 2 (AAL2) is an ATM adaptation layer for Asynchronous Transfer Mode (ATM), used primarily

intelecommunications; for example, it is used for the Iu interfaces in the Universal Mobile Telecommunications System,

and is also used for transporting digital voice. The standard specifications related to AAL2 are ITU standards I.363.2 and

I366.1.

Contents
[hide]

• 1 What is AAL2?

• 2 AAL2 and the ATM Cell

o 2.1 OSF

o 2.2 SN

o 2.3 P

• 3 AAL2u

• 4 ATM AAL2 Cell Diagram

• 5 AAL2 and the CPS Packet

o 5.1 CID

o 5.2 LI

o 5.3 UUI

o 5.4 HEC

• 6 ATM AAL2 CPS Packet Diagram

• 7 References

• 8 External links

[edit]What is AAL2?

AAL2 is a variable bitrate, connection-oriented, low latency service originally intended to adapt voice for transmission over

ATM. Like otherATM adaptation layers, the purpose of AAL2 is to define how to segment and reassemble higher-layer
packets into ATM cells, in this case packets of data containing voice and control information. AAL2 is further separated

into two sub-layers that helps with the mapping from upper layer services to ATM cells: the Service Specific Convergence

Sub-layer (SSCS) and the Common Part Sub-layer (CPS).

The objective of the AAL2 protocol, as compared to other ATM Adaptation Layers, is to pack lots of small packets

efficiently into one standard-sized ATM cell (53 bytes). This way, if you have a one-byte packet, you don't have an

overhead ratio of 52/53 (i.e. 98%). With this smallest packet size of 1 byte, there can be a total of 11 CPS packets (plus

3/4 of a 12th CPS packet) squeezed into a single cell. Of course, there can be a mixture of other CPS packet sizes with

other CIDs, too, and when the transmission is ready, the CPS packets are all multiplexed together into a single cell which

is then transported over existing standard ATM network infrastructure. The transport networks for ATM are well

standardized fiber optic (SDH/Sonet, i.e. STM-1/OC-3 or higher) or copper cable (PDH, i.e. E1/T1/JT1 or higher

bandwidth fixed lines) based synchronous networks with built-in redundancy and OAM-related network features which

Ethernet networks never had originally (in order to keep things simple) but are sorely missed in metro Ethernet standard

networks.[citation needed]

Efforts to improve Ethernet networks are in a sense trying to reinvent the wheel à la ATM.[citation needed] AAL2 is one example

of a useful benefit of ATM, as a general standard for Layer 2 protocols. This is because ATM/AAL2 handles small packets

efficiently, whereas with Ethernet, there is a minimum payload size of 48 bytes vs a 1-byte minimum size for an AAL2

CPS packet.

AAL2 is the standard layer 2 protocol used in all Iu interfaces, i.e. the interfaces between UMTS base stations and

UMTS Radio Network Controllers (RNCs) (Iu-B), inter-RNCs (Iu-R), UMTS RNCs and UMTS Serving GPRS Support

Nodes (SGSNs) (Iu-PS), and UMTS RNCs and media gateways (MGWs) (Iu-CS).[1]

[edit]AAL2 and the ATM Cell

The basic component of AAL2 is the CPS packet. A CPS packet is an unanchored unit of data, that can cross ATM cells,

and starts from any location within the payload of the ATM cell, other than the STF (start field) which is the first byte of the

48 byte ATM payload. The STF tells which byte index into the ATM cell (of 48 bytes) the first CPS packet in this cell

begins. The data from byte 1 ... (STF+1), [where byte 0 is the location of the STF itself] would be the remaining straddled

portion of the previous ATM cell's final CPS packet. If the STF is 0, then the first byte of the cell after the STF is also the

location of the start of the first CPS packet.

The format for the 1 byte STF at the beginning of the ATM cell is the following:

 6 bits - OSF (offset field)

 1 bit - SN (sequence number)

 1 bit - P (parity)
[edit]OSF

This is the Offset Field and carries the binary value of the offset in octets between the end of the P bit and the start of the

CPCS-PDU Payload. Values of greater than 47 are not allowed.

[edit]SN

This is a Sequence Number used to number the stream of CPCS-PDUs.

[edit]P

This is a Parity bit used to detect error in the OSF and SN fields.

Additionally, if the ATM cell has less CPS packet data than 47 bytes, the remainder of the ATM cell will be filled by

padding.

[edit]AAL2u

One common adaptation of AAL2 is known as AAL2u which doesn't use the STF field at all. In this case, there will be one

single CPS packet which is aligned to the beginning of the cell. AAL2u is not used in standardized interfaces, but rather in

proprietary equipment implementations where the multiplexing/demultiplexing, etc. that needs to be done for standard

AAL2 is either too strenuous, unsupported, or too much overhead (i.e. the 1 byte of STF) from the internal system point of

view. Most computer chips do not have AAL2 support in them. And therefore stripping this layer away makes it easier to

interwork between the ATM interface and the rest of the network equipment computer system.

[edit]ATM AAL2 Cell Diagram

The following is diagram of the AAL2 ATM cell:

[edit]AAL2 and the CPS Packet

A CPS packet has a 3 byte header and a 1-45 octet payload. There is also a 64 octet mode defined by the standard, but it

is not commonly used in real 3G networks.

The 3 byte CPS header has following fields

 8 bits - CID (channel identifier)

 6 bits - LI (length indicator)

 5 bits - UUI (user to user indication)

 5 bits - HEC (header error control)

[edit]CID

This is a Channel Identifier which identifies the user of the channel. The AAL2 channel is a bi-directional channel and the

same value of channel identification is used for both directions.

[edit]LI

This is a Length Indicator that indicates the length of the CPCS information field between 1 and 45 (default) or 1 and 64

octets. For a given CID all channels must be of the same maximum length (either 45 or 64 octets)

[edit]UUI

This is User to User Indication. It conveys specific information transparently between the users. For example, in SSSAR,

UUI is used to indicate that this is the final CPS packet for the SSSAR PDU.
[edit]HEC

This is Header Error Control and checks for errors in the CID, LI and UUI fields. The generator polynomial for the CPS

HEC is the following:

G(x) = x5 + x2 + 1

[edit]ATM AAL2 CPS Packet Diagram

The following is diagram of the CPS packet:

AAL - ATM Adaptation Layer
Providing the glue to support the full range of ATM services.

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.

AAL protocols have been defined to support five classes of service:

• Class X: Control Sigalling - supports the in-band service

characteristics.
• Class A: Constant Bit Rate - supports transfer of synchronous
circuit services
• Class B: Variable Bit Rate - supports delivery of isochronous
services such as variable rate video and voice
• Class C: Connection Oriented data
• Class D: Connectionless Data

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 1 - AAL Service Classes & AAL Types

Figure 2 shows the internal components of the AAL. The services

provided by each of these components is as follows:

• The Service Specific Functions (SSCS) sublayer provides

additional functions and mechanisms that may be required for the
a specific service. This layer is not required for all AAL services,
and may be represented as a NULL layer.
• The Common Part Convergence Layer (CPCS) operates on the
complete AAL frames, providing header and trailer record control
as well as ensuring the integrity of delivered information.
• The Segmentation and Reassembly Layer (SAR) converts the
CPCS frames to and from ATM cell payload information.

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.
 Figure 2 - AAL Sublayers

AAL-0 NULL AAL

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.

AAL-1 Supports Class A Constant Bit Rate Traffic

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

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

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 Variable Rate Synchronous Service

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.

AAL-3/4 End-To-End Data Transport

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:

• CPI - Common Part Indicator: Acts as a protocol identifier that

defines how the remaining fields of the PDU are to be processed.
At this point, it is largely a placeholder to support future changes
to the protocol, the CPI is specified to be always zero by ITU-T
I.363.
• Btag - Beginning Tag. This value is used to determine whether or
not the CPCS-PDU has been properly delivered. When the
CPCS-PDU is constructed, the same value is entered into both
the Btag and Etag fields. If a reassembled CPCS-PDU is received
with these values being different, the PDU is assumed to have
been corrupted. The tag value is incremented (with a wrap at all
ones) as each PDU is constructed.
 • BASize - Buffer Allocation Size Indication. Tells the receiver the
amount of buffer space to allocate to process the PDU. This value
is equal-to or greater than the PDU size.
• Pad - Ensures that the PDU is a multiple of 4 octets in length. This
simplifies processing of the PDU in 32-bit chunks.
• AL - Alignment Field. This is unused pad space with the sole
purpose of padding the trailer to 4-octets
• Etag - End Tag. Matches the beginning tag. Used for data
integrity verification
• Length - Field Length. Specifies theactual length of the CPCS-
PDU (in octets when CPI=0). As the SAR is responsible for
framing the data, this is provided to support additional error
checking.

Figure 4 - AAL-3/4 CPCS PDU Format

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:

• ST - Segment Type (2-bits) defines where the segment belongs in

the SAR-SDU (essentially the CPCS-PDU). Possible values
include: (10) beginning of the message, (00) continuation of the
message, (01) end of the message, and (11) single segment
message.
• SN - Sequence Number (4-bits). Used to ensure the in-order
delivery of segments.
• MID - Multiplexing Identification Field. (10-bits) Provides
compatibility with SMDS, this field carries multiplex channel
identification, allowing for the transmission of multiple channels of
information over a single ATM VC.
• Payload - (44-octets) the segment of the CPCS-PDU information
to be transferred within this cell.
• LI - length Indication. (6 bits) Identifies the amount of information
in the payload portion of the cell. Only the last cell in a
transmission should have less than 44 octets of information.
Therefore, this value will be 44 for all segments with the exception
 of the end-of-message segment, in which case it is an even
multiple of 4 between 4 and 44 (remember the CPCS padding).
• CRC - cyclic redundancy check (10-bits). Calculated over the
complete SAR-PDU with the exception of the CRC field.

Figure 5 - SAR-PDU Format

AAL-5 Simple Data Transfer

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.

Figure 6 - AAL-5 CPCS-PDU

Components of the AAL-5 CPCS-PDU are:

• Pad - rounds the data length to an even multiple of 4-octets.

• UU - user to user indication. Used to pass information between
CPCS users.
• CPI - always zero, and provides boundary alignment
• Length - indicates the number of legitimate octets within the PDU.
• CRC (32-bits).

Through services provided by the AAL protocols, user applications are

able to realize the full scope of services promised by ATM.
ATM Adaptation Layer 5
From Wikipedia, the free encyclopedia
(Redirected from AAL5)

ATM Adaptation Layer 5 (AAL5) is an ATM adaptation layer used to send variable-length packets up
to 65,535 octets in size across anAsynchronous Transfer Mode (ATM) network.

Unlike most network frames, which place control information in the header, AAL5 places control
information in an 8-octet trailer at the end of the packet. The AAL5 trailer contains a 16-bit length field,
a 32-bit cyclic redundancy check (CRC) and two 8-bit fields labeled UU andCPI that are currently
unused.

Each AAL5 packet is divided into an integral number of ATM cells and reassembled into a packet
before delivery to the receiving host. This process is known as Segmentation and Reassembly (see
below). The last cell contains padding to ensure that the entire packet is a multiple of 48 octets long.
The final cell contains up to 40 octets of data, followed by padding bytes and the 8-octet trailer. In
other words, AAL5 places the trailer in the last 8 octets of the final cell where it can be found without
knowing the length of the packet; the final cell is identified by a bit in the ATM header (see below), and
the trailer is always in the last 8 octets of that cell.

Contents
[hide]

• 1 Convergence, segmentation, and reassembly

• 2 Packet type and multiplexing

• 3 Datagram encapsulation and IP MTU size

• 4 References

[edit]Convergence, segmentation, and reassembly

When an application sends data over an ATM connection using AAL5, the host delivers a block of data
to the AAL5 interface. AAL5 generates a trailer, divides the information into 48-octet pieces, and
transfers each piece across the ATM network in a single cell. On the receiving end of the connection,
AAL5 reassembles incoming cells into a packet, checks the CRC to ensure that all pieces arrived
correctly, and passes the resulting block of data to the host software. The process of dividing a block
of data into cells and regrouping them is known as ATM segmentation and reassembly (SAR).
By separating the functions of segmentation and reassembly from cell transport, AAL5 follows the
layering principle. The ATM cell transfer layer is classified as "machine-to-machine" because the
layering principle applies from one machine to the next (e.g., between a host and a switch or between
two switches). The AAL5 layer is classified as "end-to-end" because the layering principle applies from
the source to the destination - AAL5 presents the receiving software with data in exactly the same size
blocks as the application passed to the AAL5 on the sending end.

The AAL5 on the receiving side knows how many cells comprise a packet because the sending AAL5
uses the low-order bit of the "PAYLOAD TYPE" field of the ATM cell header to mark the final cell in a
packet. This final cell header can be thought of as an "end-to-end bit". Thus, the receiving AAL5
collects incoming cells until it finds one with an end-of-packet bit set. ATM standards use the term
"convergence" to describe mechanisms that recognize the end of a packet. Although AAL5 uses a
single bit in the cell header for convergence, other ATM adaptation layer protocols are free to use
other convergence mechanisms.

[edit]Packet type and multiplexing

The AAL5 trailer does not include a type field. Thus, an AAL5 frame is not identifying its content. This
means that either the two hosts at the ends of a virtual circuit must agree a priori that the circuit will be
used for one specific protocol (e.g., the circuit will only be used to send IP datagrams), or the two
hosts at the ends of a virtual circuit must agree a priori that some octets of the data area will be
reserved for use as a type field to distinguish packets containing one protocol's data from packets
containing another protocol's data.

RFC 2684, Multiprotocol Encapsulation over ATM, describes two encapsulation mechanisms for
network traffic, one of which implements the former scheme and one of which implements the latter
scheme.

The former scheme, in which the hosts agree on the high-level protocol for a given circuit, is referred
to in RFC 2684 as "VC Multiplexing". It has the advantage of not requiring additional information in a
packet, which minimises the overhead. For example, if the hosts agree to transfer IP, a sender can
pass each datagram directly to AAL5 to transfer, nothing needs to be sent besides the datagram and
the AAL5 trailer. The chief disadvantage of such a scheme lies in duplication of virtual circuits: a host
must create a separate virtual circuit for each high-level protocol if more than one protocol is used.
Because most carriers charge for each virtual circuit, customers try to avoid using multiple circuits
because it adds unnecessary cost.

The latter scheme, in which the hosts use a single virtual circuit for multiple protocols, is referred to
in RFC 2684 as "LLC Encapsulation". The standards suggest that hosts should use a standard IEEE
802.2 Logical Link Control (LLC) header, followed by aSubnetwork Access Protocol (SNAP) header if
necessary. This scheme has the advantage of allowing all traffic over the same circuit, but the
disadvantage of requiring each packet to contain octets that identify the protocol type, which adds
overhead. The scheme also has the disadvantage that packets from all protocols travel with the same
delay and priority.

RFC 2684 specifies that hosts can choose between the two methods of using AAL5. Both the sender
and receiver must agree on how the circuit will be used, the agreement may involve manual
configuration.

[edit]Datagram encapsulation and IP MTU size

Internet Protocol (IP) can use AAL5, combined with one of the encapsulation schemes described
in RFC 2684, to transfer datagrams across an ATM network, as specified in RFC 2225. Before data
can be sent, a virtual circuit (PVC or SVC) must be in place to the destination host and both ends must
agree to use AAL5 on the circuit. To transfer a datagram, the sender passes it to AAL5 along with the
VPI/VCI identifying the circuit. AAL5 generates a trailer, divides the datagram into cells, and transfers
the cells across the network. At the receiving end, AAL5 reassembles the cells, checks the CRC to
verify that no bits were lost or corrupted, extracts the datagram, and passes it to the IP layer.

AAL5 uses a 16-bit length field, making it possible to send 65,535 (2^16-1) octets in a single packet.
However, RFC 2225 specifies a default MTU of 9180 octets per datagram, so, unless the hosts on
both ends of the virtual circuit negotiate a larger MTU, IP datagrams larger than 9180 octets will be
fragmented.

Segmentation and Reassembly

From Wikipedia, the free encyclopedia
This article does not cite any references or sources.
Please help improve this article by adding citations to reliable sources. Unsourced material may
be challenged andremoved. (December 2009)

Segmentation and Reassembly refers to the process used to fragment and

reassemble variable length packets into fixed length cells so as to allow them to be
transported across Asynchronous Transfer Mode networks or other cell based
infrastructures. Since ATM's payload is only 48 bytes, nearly every packet from any
other protocol has to be processed in this way. Thus, it is an essential process for
any ATM node. It is usually handled by a dedicated chip, called the SAR.
The process is conceptually simple: an incoming packet from another protocol to be
transmitted across the ATM network is chopped up into segments that fit into 48-byte
chunks carried as ATM cell payloads. At the far end, these chunks are fitted back
together to reconstitute the original packet.

The process is analogous to the fragmentation of IP packets on reaching an

interface with a Maximum Transmit Unit (MTU) size less than the packet size and the
subsequent reassembly of the original packet once the fragments have reached the
original packet's destination.

Since different types of data are encapsulated in different ways, the details of the
segmentation process vary according to the type of data being handled. There are
several different schemes, referred to as ATM Adaptation Layers (AAL). The
schemes are:

 AAL0 - Raw cells with no special format

 AAL1 - Constant bitrate, circuit emulation (T1, E1, etc.)
 AAL2 - Variable bitrate synchronous traffic, e.g. voice data
 AAL3/4 - Variable bitrate asynchronous traffic, e.g. Frame Relay transport
 AAL5 - Used for most data traffic, such as IP

[edit]

ATM adaptation layer

From Wikipedia, the free encyclopedia
(Redirected from AAL3/4)
This article does not cite any references or sources.
Please help improve this article by adding citations to reliable sources. Unsourced material may
be challenged andremoved. (March 2008)

The use of Asynchronous Transfer Mode (ATM) technology and services creates the
need for an adaptation layer in order to support information transfer protocols, which
are not based on ATM. This adaptation layer defines how to segment and
reassemble higher-layer packets into ATM cells, and how to handle various
transmission aspects in the ATM layer.

Examples of services that need adaptations are Gigabit Ethernet, IP, Frame
Relay, SONET/SDH, UMTS/Wireless, etc.

The main services provided by AAL (ATM Adaptation Layer) are:

 Segmentation and reassembly

 Handling of transmission errors
 Handling of lost and misinserted cell conditions
 Timing and flow control

The following ATM Adaptation Layer protocols (AALs) have been defined by the ITU-
T. It is meant that these AALs will meet a variety of needs. The classification is
based on whether a timing relationship must be maintained between source and
destination, whether the application requires a constant bit rate, and whether the
transfer is connection oriented or connectionless.

 AAL Type 1 supports constant bit rate (CBR), synchronous, connection

oriented traffic. Examples include T1 (DS1), E1, and x64 kbit/s emulation.
 AAL Type 2 supports time-dependent Variable Bit Rate (VBR-RT) of
connection-oriented, synchronous traffic. Examples include Voice over ATM.
AAL2 is also widely used in wireless applications due to the capability of
multiplexing voice packets from different users on a single ATM connection.
 AAL Type 3/4 supports VBR, data traffic, connection-oriented, asynchronous
traffic (e.g. X.25 data) or connectionless packet data (e.g. SMDS traffic) with an
additional 4-byte header in the information payload of the cell. Examples include
Frame Relay and X.25.
 AAL Type 5 is similar to AAL 3/4 with a simplified information header
scheme. This AAL assumes that the data is sequential from the end user and
uses the Payload Type Indicator (PTI) bit to indicate the last cell in a
transmission. Examples of services that use AAL 5 are classic IP over ATM,
Ethernet Over ATM, SMDS, and LAN Emulation (LANE). AAL 5 is a widely used
ATM adaptation layer protocol. This protocol was intended to provide a
 streamlined transport facility for higher-layer protocols that are connection
oriented.

AAL 5 was introduced to:

 reduce protocol processing overhead.

 reduce transmission overhead.
 ensure adaptability to existing transport protocols.

The AAL 5 was designed to accommodate the same variable bit rate, connection-
oriented asynchronous traffic or connectionless packet data supported by AAL 3/4,
but without the segment tracking and error correction requirements.

[edit]

ATM Adaptation Layer 5

From Wikipedia, the free encyclopedia
(Redirected from AAL5)

ATM Adaptation Layer 5 (AAL5) is an ATM adaptation layer used to send variable-
length packets up to 65,535 octets in size across anAsynchronous Transfer
Mode (ATM) network.

Unlike most network frames, which place control information in the header, AAL5
places control information in an 8-octet trailer at the end of the packet. The AAL5
trailer contains a 16-bit length field, a 32-bit cyclic redundancy check (CRC) and two
8-bit fields labeled UU andCPI that are currently unused.

Each AAL5 packet is divided into an integral number of ATM cells and reassembled
into a packet before delivery to the receiving host. This process is known
as Segmentation and Reassembly (see below). The last cell contains padding to
ensure that the entire packet is a multiple of 48 octets long. The final cell contains up
to 40 octets of data, followed by padding bytes and the 8-octet trailer. In other words,
AAL5 places the trailer in the last 8 octets of the final cell where it can be found
without knowing the length of the packet; the final cell is identified by a bit in the ATM
header (see below), and the trailer is always in the last 8 octets of that cell.
 Contents
[hide]

• 1 Convergence, segmentation, and reassembly

• 2 Packet type and multiplexing

• 3 Datagram encapsulation and IP MTU size

• 4 References

[edit]Convergence, segmentation, and reassembly

When an application sends data over an ATM connection using AAL5, the host
delivers a block of data to the AAL5 interface. AAL5 generates a trailer, divides the
information into 48-octet pieces, and transfers each piece across the ATM network in
a single cell. On the receiving end of the connection, AAL5 reassembles incoming
cells into a packet, checks the CRC to ensure that all pieces arrived correctly, and
passes the resulting block of data to the host software. The process of dividing a
block of data into cells and regrouping them is known as ATM segmentation and
reassembly (SAR).

By separating the functions of segmentation and reassembly from cell transport,

AAL5 follows the layering principle. The ATM cell transfer layer is classified as
"machine-to-machine" because the layering principle applies from one machine to
the next (e.g., between a host and a switch or between two switches). The AAL5
layer is classified as "end-to-end" because the layering principle applies from the
source to the destination - AAL5 presents the receiving software with data in exactly
the same size blocks as the application passed to the AAL5 on the sending end.

The AAL5 on the receiving side knows how many cells comprise a packet because
the sending AAL5 uses the low-order bit of the "PAYLOAD TYPE" field of the ATM
cell header to mark the final cell in a packet. This final cell header can be thought of
as an "end-to-end bit". Thus, the receiving AAL5 collects incoming cells until it finds
one with an end-of-packet bit set. ATM standards use the term "convergence" to
describe mechanisms that recognize the end of a packet. Although AAL5 uses a
single bit in the cell header for convergence, other ATM adaptation layer protocols
are free to use other convergence mechanisms.
[edit]Packet type and multiplexing
The AAL5 trailer does not include a type field. Thus, an AAL5 frame is not identifying
its content. This means that either the two hosts at the ends of a virtual circuit must
agree a priori that the circuit will be used for one specific protocol (e.g., the circuit will
only be used to send IP datagrams), or the two hosts at the ends of a virtual circuit
must agree a priori that some octets of the data area will be reserved for use as a
type field to distinguish packets containing one protocol's data from packets
containing another protocol's data.

RFC 2684, Multiprotocol Encapsulation over ATM, describes two encapsulation

mechanisms for network traffic, one of which implements the former scheme and
one of which implements the latter scheme.

The former scheme, in which the hosts agree on the high-level protocol for a given
circuit, is referred to in RFC 2684 as "VC Multiplexing". It has the advantage of not
requiring additional information in a packet, which minimises the overhead. For
example, if the hosts agree to transfer IP, a sender can pass each datagram directly
to AAL5 to transfer, nothing needs to be sent besides the datagram and the AAL5
trailer. The chief disadvantage of such a scheme lies in duplication of virtual circuits:
a host must create a separate virtual circuit for each high-level protocol if more than
one protocol is used. Because most carriers charge for each virtual circuit,
customers try to avoid using multiple circuits because it adds unnecessary cost.

The latter scheme, in which the hosts use a single virtual circuit for multiple
protocols, is referred to in RFC 2684 as "LLC Encapsulation". The standards suggest
that hosts should use a standard IEEE 802.2 Logical Link Control (LLC) header,
followed by aSubnetwork Access Protocol (SNAP) header if necessary. This scheme
has the advantage of allowing all traffic over the same circuit, but the disadvantage
of requiring each packet to contain octets that identify the protocol type, which adds
overhead. The scheme also has the disadvantage that packets from all protocols
travel with the same delay and priority.

RFC 2684 specifies that hosts can choose between the two methods of using AAL5.
Both the sender and receiver must agree on how the circuit will be used, the
agreement may involve manual configuration.
[edit]Datagram encapsulation and IP MTU size
Internet Protocol (IP) can use AAL5, combined with one of the encapsulation
schemes described in RFC 2684, to transfer datagrams across an ATM network, as
specified in RFC 2225. Before data can be sent, a virtual circuit (PVC or SVC) must
be in place to the destination host and both ends must agree to use AAL5 on the
circuit. To transfer a datagram, the sender passes it to AAL5 along with the VPI/VCI
identifying the circuit. AAL5 generates a trailer, divides the datagram into cells, and
transfers the cells across the network. At the receiving end, AAL5 reassembles the
cells, checks the CRC to verify that no bits were lost or corrupted, extracts the
datagram, and passes it to the IP layer.

AAL5 uses a 16-bit length field, making it possible to send 65,535 (2^16-1) octets in
a single packet. However, RFC 2225 specifies a default MTU of 9180 octets per
datagram, so, unless the hosts on both ends of the virtual circuit negotiate a larger
MTU, IP datagrams larger than 9180 octets will be fragmented.

[edit]

---------------------------------------------------------The End----------------------------------------------------------
ATM Adaptation Layer Protocols
Overview
Introduction

The following ATM Adaptation Layer protocols (AALs) have been defined for
Asynchronous Transfer Mode. These protocols are loosely associated with the
various classes of traffic expected to be carried:

AAL 1
Supports constant bit rate, connection-oriented, synchronous traffic (e.g.,
uncompressed voice).
AAL 2
Definition never completed, but was envisioned to be assigned for
variable bit rate, connection-oriented, synchronous traffic.
AAL 3/4
Supports variable bit rate, connection- oriented, asynchronous traffic
(e.g., X.25 data) or connectionless packet data (e.g., SMDS traffic) with
an additional 4-byte header in the information payload of the cell.
AAL 5
Similar to AAL 3/4 with a simplified information header scheme; this
AAL assumes that the data is sequential from the end user and uses the
PTI bit to indicate the last cell in a transmission Examples of services
that use AAL 5 are Classic IP over ATM, and LAN Emulation (LANE).
AAL 5 is the most widely used ATM Adaptation Layer Protocol.

The ATM Adaptation Layer Protocols are formally defined in ITU-T Standard
I.363 available from the International Telecommunications Union (ITU).

AAL TYPE 1

This section addresses ATM Adaptation Layer protocol type 1 (AAL 1), which
is designed to accommodate constant bit rate, connection-oriented, synchronous
traffic. A good example of this type of traffic is uncompressed video.

Like all of the AAL protocols, AAL 1 is designed to accept the data from the
upper-layers (i.e., USER layers) of the end user and prepare it for handoff in
48-byte segments to the ATM Layer of the ATM protocol stack. The ATM
Layer then provides each segment with an appropriate header and hands the 53-
byte ATM cell down to the Physical Layer for transmission over the ATM
network.

The preparation offered by the AAL 1 protocol includes support for the
following functions required by the upper layer:

• Timing recovery
• Timing indication
• Synchronization
• Indication of information loss

In order to provide these services, AAL 1 adds a one-byte (8 bit) header to each
Protocol Data Unit segment generated at the Segmentation and Reassembly
Sublayer. This information includes Convergence Sublayer specific
information (when required) as well as an error checking mechanism. No trailer
is added with this AAL protocol type.

AAL 1 Data Flow

LAYER
+----------------------------------------------+
| Service Data Unit | ----- USER
+----------------------------------------------+
V
+----------------------------------------------+ ---+
| Convergence Sublayer Protocol Data Unit | |
+----------------------------------------------+ |
V |
+--------------++--------------++--------------+ |
| SAR-PDU || SAR-PDU || SAR-PDU | |- AAL
+--------------++--------------++--------------+ |
\ 47 Bytes \ \ 47 Bytes \ |
+---+--------------+ +---+--------------+ |
| H | SAR-PDU | | H | SAR-PDU | |
+---+--------------+ +---+--------------+ -+
V 48 Bytes V
H = SAR HEADER +-----------------------+
AH = ATM HEADER | AH | ATM PAYLOAD | --- ATM

AAL 1 SAR Header Format

The 1 byte (8 bit) header added at the Segmentation and Reassembly Sublayer
is divided into two 4-bit fields:

• Segment Number (SN)

• Sequence Number Protection (SNP)
The SN field is further subdivided into the 1-bit Convergence Sublayer
Indication (CSI) subfield and the 3-bit Sequence Count (SC) field. The CSI
subfield is used to convey Convergence Sublayer-specific information and is
not used for all AAL implementations. The SC subfield carries the sequence
number for the entire CS_PDU; this is generated by the Convergence Sublayer.

The other field (SNP) functions as the error check for the SAR header. The first
three bits of this field are a Cyclical Redundancy Check (CRC) for the SN
portion of the header. The polynomial used to generate this CRC is x3 + x + 1

The remaining bit is an even parity check over the previous 7 bits (i.e., the SN
field and the CRC subfield).

These fields are illustrated below:

+-------------+-----------------------+
| SAR HEADER | SAR-PDU |
+-------------+-----------------------+
| |
+------+------+
| SN | SNP | EPC = Even
+------+------+ Parity
/ | \ Check
+---+------+------+---+
|CSI| SC | CRC |EPC|
+---+------+------+---+
^ ^ ^ ^
| | | |
1 Bit ---+ | | +--- 1 Bit
3 Bits --+ +-- 3 Bits

AAL TYPE 3/4

This section addresses ATM Adaptation Layer protocol type 3 and protocol
type 4. These two types are merged into a single protocol, AAL 3/4, which is
designed to accommodate both variable bit rate, asynchronous traffic (type 3)
or connectionless packet data (type 4). Good examples of these types of traffic
are X.25 Pacekt-Switched Data and SMDS respectively.

Like all of the AAL protocols, AAL 3/4 is designed to accept the data from the
upper-layers (i.e., USER layers) of the end user and prepare it for handoff in
48-byte segments to the ATM Layer of the ATM protocol stack. The ATM
Layer then provides each segment with an appropriate header and hands the 53-
byte ATM cell down to the Physical Layer for transmission over the ATM
network.
AAL 3/4 provides for full sequencing as well as error-control and error-
recovery mechanisms. This is accomplished both at the Convergence Sublayer
and the Segmentation and Reassembly Sublayer of the AAL Layer.

AAL 3/4 DATA FLOW

The first step in the data flow for AAL 3/4 is the Service Data Unit (SDU)
being passed down from the Upper (User) Layer to the Convergence Sublayer
of the AAL Layer.

AAL 3/4 subdivides the Convergence Sublayer into the Service Specific
Convergence Sublayer (SSCS) and the Common Part Convergence Sublayer
(CPCS). The Upper Layer SDU is passed through the SSCS Sublayer
unchanged.

The CPCS Sublayer adds a 4-byte header and a 4-byte trailer; at this point, the
User SDU is also padded, with 0-3 bytes as necessary, to assure that the entire
CPCS Protocol Data Unit (PDU) length is divisible by 4.

The CPCS-PDU is then passed down to the Segmentation and Reassembly

(SAR) sublayer of the AAL Layer. At this point, the entire CPCS-PDU,
including the added header, trailer, and pad, is segmented in 44-byte pieces.
The SAR then adds a 2-byte header and a 2-byte trailer to each segment; this
48-byte SAR-SDU segment is passed down to the ATM Layer for processing.

The ATM Layer adds the 5-byte ATM header to each segment received from
the SAR and passes each segment to the Physical Layer for transport over the
ATM network.

This process is illustrated below:

+----------------------------------------------+
| Service Data Unit |
+----------------------------------------------+
| |
V V
+----+----------------------------------------------+----+----+
| CH | Convergence Sublayer Protocol Data Unit | PAD| CT |
+----+----------------------------------------------+----+----+
| |
V V
+-------------------++-------------------++-------------------+
| | || || | | |
+-------------------++-------------------++-------------------+
| Segment 1 || Segment 2 || Segment 3 |
V (BOM) VV (COM) VV (EOM) V
CH = CPCS Header CT = CPCS Trailer BOM = Beginning of Message
COM = Continuation of Message EOM = End of Message
++------------------++-------------------+
|| || | | |
++------------------++-------------------+
|| Segment 2 (COM) || Segment 3 (EOM) |
VV VV V
+---+-------------------+---+
| H | | | | T |
+---+-------------------+---+
| SAR-SDU |
V V
+-----+---------------------------+
| AH | | | | | |
+-----+---------------------------+
|_______ ATM Payload ______|

|_______ 53-Byte ATM Cell _______|

H = SAR Header T = SAR Trailer AH = ATM Header

AAL 3/4 CPCS-PDU FORMAT
+----+----------------------------------------------+----+----+
| CH | Convergence Sublayer Protocol Data Unit | PAD| CT |
+----+----------------------------------------------+----+----+
| \ / |
| \ / |
| \ / |
+---+----+------+ +--+----+------+
|CPI|Btag|BASize| |AL|Etag|Length|
+---+----+------+ +--+----+------+

The Convergence Sublayer adds a 4-byte header, a 4-byte trailer, and extra
bytes as necessary to maintain the size requirements for even ATM
segmentation.

AAL 3/4 CPCS-PDU FORMAT

The CPCS header that is added to the data passed down from the Upper Layer
(end user) consists of the following three fields:

CPI
Common Part Indicator. This 1-byte field is used to interpret the
remainder of the fields in the header and trailer added for this sublayer.
Btag
Beginning Tag. This 1-byte field acts as an error check for this segment.
The value in this field is also placed in the Etag (End Tag) field of the
trailer, allowing a quick comparison after receipt to determine if the
segment has been corrupted.
BASize
 Buffer Allocation Size. This 2-byte field is encoded to indicate the
length of the CPCS-PDU (segment) payload.

The CPCS trailer also is divided into three fields:

AL
Alignment. This 1-byte field is used to make the trailer size 4 bytes, in
order to maintain the divisibility of the segment by 4. It is passed
through the network transparently.
Etag
This 1-byte field contains the same information as the Btag field in the
header. (See Btag above.)
Length
This 2-byte field indicates the length of the PDU payload. It is encoded
to indicate the number of COUNTING UNITS in the length of the
payload, with the counting unit size indicated in the CPI of the header.

AAL 3/4 SAR-SDU FORMAT

+---+-------------------+---+
| H | SAR Payload | T |
+---+-------------------+---+
/ | / |
/ | / |
/ | / |
+----+----+------+ +-----+--------+
| ST | SN | MID | | LI | CRC-10 |
+----+----+------+ +-----+--------+

The Segmentation and Reassembly header and trailer adds information

concerning the segment order and provides a cyclical redundancy check (CRC)
for the segment. Each is 2 bytes in length.

The SAR header is divided into three fields:

ST
Segment Type. This 2-bit field is used to indicate one of four segment
types: Beginning of Message (BOM), Continuation of Message (COM),
End of Message (EOM), or Single-Segment Message (SSM).
SN
Sequence Number. This 4-bit field allows the stream of SAR SDUs to be
numbered using modulo 16. It is used to provide a "loss of segment"
check for each full PDU that is segmented.
MID
 Multiplexing Identification. This 10-bit field is used to multiplex CPCS
connections on a single ATM Layer connection, when applicable.

The SAR trailer contains two parts:

LI
Length Indication. This 6-bit field is binary- encoded to indicate the
number of bytes of the CPCS-PDU (received from the Convergence
Layer above) that are contained in the payload portion of this segment.
For BOM and COM segments, this value MUST be 44. For EOM
segments, the value can range from 4 to 44, as appropriate. For SSM
segments, permitted values range from 8 to 44.
CRC
Cyclical Redundancy Check. This 10-bit sequence functions as an error
check for the entire SAR-SDU, including the header, payload, and LI
field of the trailer.

AAL TYPE 5

This section addresses ATM Adaptation Layer protocol type 5 (AAL 5), which
is designed to accommodate the same variable bit rate, connection-oriented
asynchronous traffic or connectionless packet data supported by AAL 3/4, but
without the segment tracking and error correction requirements. It is used to
transfer non-SMDS data, such as classical IP over ATM and LAN Emulation
(LANE). It is also known as the Simple and Efficient Adaptation Layer
(SEAL).

Like all of the AAL protocols, AAL 5 is designed to accept the data from the
upper-layers (i.e., USER layers) of the end user and prepare it for handoff in
48-byte segments to the ATM Layer of the ATM protocol stack. The ATM
Layer then provides each segment with an appropriate header and hands the 53-
byte ATM cell down to the Physical Layer for transmission over the ATM
network. For all cells except the last, the low order bit in the Payload Type
Indicator (PTI) is set to zero to indicate the cell is not the last cell is a series
that represents a single frame. For the last cell, the low order bit in the PTI field
is set to one.

AAL 5 is geared for a streamlined transmission. It assumes that error recovery

is performed by the higher layers, so that all 48 bytes of the payload may be
allocated to carry data. It also assumes that only ONE message is transmitted
over the UNI at one time. (If there is more than one user at a time, messages are
queued for sequential transmission.)
AAL 5 DATA FLOW

The first step in the data flow for AAL 5 is the Service Data Unit (SDU) being
passed down from the Upper (User) Layer to the Convergence Sublayer of the
AAL Layer.

Like AAL 3/4, AAL 5 subdivides the Convergence Sublayer into the Service
Specific Convergence Sublayer (SSCS) and the Common Part Convergence
Sublayer (CPCS). The Upper Layer SDU is passed through the SSCS Sublayer
unchanged.

The CPCS Sublayer adds an 8-byte trailer to the SDU and pads the SDU with
0-47 bytes of data in such a manner that the SDU may be divided evenly into
48-byte segments, with the trailer occupying the last 8 bytes of the last
segment.

At this time, the CPCS-PDU is handed down to the SAR Sublayer, where it is
divided into 48-byte segments. THE SAR SUBLAYER PERFORMS NO
ADDITIONAL FUNCTIONS WITH AAL 5.

Each of the segments is then handed (unchanged) to the ATM Layer for
incorporation into an appropriate ATM cell. The ATM Layer then sends the
cell to the Physical Layer for transmission over the ATM network.

This process is outlined below:

+----------------------------------------------+
| Service Data Unit |
+----------------------------------------------+
| |
V V
+----------------------------------------------+-------+------+
| Convergence Sublayer Protocol Data Unit | PAD | CT |
+----------------------------------------------+-------+------+
| |
V V
+-------------------++-------------------++-------------------+
| || || | | |
+-------------------++-------------------++-------------------+
| First Segment || Second Segment || Last Segment |
V VV VV V

CT = CPCS Trailer
-++-------------------++-------------------+
|| || | | |
-++-------------------++-------------------+
|| Second Segment || Last Segment |
VV VV V
 +-------------------+
| | | |
+-------------------+
| SAR-SDU |
V V
+-----+-------------------+
| AH | | | |
+-----+-------------------+
|___ ATM Payload ___|

|____ 53-Byte ATM Cell ___|

AH = ATM Header

AAL 5 CPCS-PDU FORMAT

+----------------------------------------------+-------+------+
| Convergence Sublayer Protocol Data Unit | PAD | CT |
+----------------------------------------------+-------+------+
/ |
/ |
/ |
/ |
+----+----+------+--------+
|U-U |CPI |Length| CRC-32 |
+----+----+------+--------+

The 8-byte CPCS trailer is divided into four fields:

CPCS-UU
CPCS User-to-User Indication. This 1-byte field is used to transparently
transfer information from the origination user to the destination user.
CPI
Common Part Indicator. This is a 1-byte field used to align the CPCS-
PDU trailer to the 32-bit boundary.
Length
This 2-byte field indicates the length of the CPCS payload, not including
the PAD bytes.
CRC-32
Cyclical Redundancy Check. The 4-byte CRC-32 field is a 32-bit error
check for the entire contents of the CPCS-PDU, including the payload,
PAD field, and first 4 bytes of the trailer. The CRC-32 generating
polynomial is: x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 +
x4 + x2 + x + 1.