ATM Adaptation Layer type 5

From Hill2dot0
(Redirected from AAL5)
Jump to: navigation, search

ATM Adaptation Layer type 5 (AAL5) is designed to provide higher line efficiency and better bit error detection capabilities than the other AAL types. In fact, AAL was once known as the Simple Efficient Adaptation Layer (SEAL). AAL5 has almost replaced AAL3/4, which is used only in some “historic” SMDS networks. AAL5 is designed for class C service, although it also applies to class D.

AAL5 fields are described below.

  • User Data (up to 65,536 octets): Data from the higher layer protocol.
  • Pad (0–47 octets; any bit pattern): Aligns the entire CS-PDU on a 48-octet boundary.
  • Control (2 octets): The first octet, the User-to-User (UU) or Convergence Function (CF) field, can contain any information that AAL5 end-users want to transfer transparently across the network. The second octet, the Common Part Indicator (CPI) field, provides 8-octet alignment of the trailer. Currently this field is unused and set to 0.
  • Length (2 octets): Indicates the number of octets in the User Data field.
  • CRC-32 (4 octets): Provides bit error detection for the entire CS-PDU.

The AAL5 SAR-PDU always contains exactly 48 octets of the CS-PDU; there is no additional SAR overhead. A special SDU type coding of the PTI field in the cell header indicates which cell contains the last fragment of a CS-PDU. The trailer always occupies the last 8 octets of the last cell composing the CS-PDU.

AAL5 was developed for a number of CPU-related reasons. One is that 44-octet payloads are not as well suited as 48-octet payloads to the combination of 16-, 32-, and 64-bit processor and memory architectures. Another is that ATM has important applications in the Internet and with TCP/IP protocols. Several studies suggest that typical TCP/IP traffic produces a large number of small packets (around 48 octets in length). Quite a few otherwise empty TCP acknowledgment segments are floating on the Internet, and all are 40 bytes long. Several studies also suggest that running TCP/IP over ATM using 44-octet payloads would result in a 55–60 percent line rate efficiency, while increasing the payload length to 48 octets could improve efficiency by up to 20 percent. The relationship between AAL5 and the TCP/IP community is also seen by the fact that the maximum user data size of 64 kilobytes corresponds to the maximum size of an IP datagram.

As an example of how the best-laid plans often go astray, consider this. The Internet standard for IP encapsulation over AAL5 (RFC 1483) defines a technique in which multiple protocols can be multiplexed over the same ATM virtual connection using an 8-byte multiprotocol encapsulation header. Since IP and ARP tend to go hand in hand, it is common to see this multiprotocol encapsulation technique used over ATM connections supporting IP. When the 8-byte AAL5 CPS trailer is appended to the now 48-byte PDU, we find ourselves back in a “two cell” garage when needing to send a TCP/IP acknowledgment. That means needing 106 bytes to send what was a 40-byte message.

AAL5 Applications

The AAL5 protocol provides a best-effort data service over an ATM connection. Data applications that use AAL5 pass frame-oriented traffic to the AAL. The traffic is passed, in order, through the ATM network to the destination AAL5 device. The AAL5 protocol provides a bit error detection capability only. Any error recovery is performed end to end by the traffic-generating devices; no edge-to-edge error recovery is performed by ATM edge devices.

AAL5 has become the “Utility” Adaptation Layer—it can support any type of traffic in the corporate intranet. LAN traffic, SNA traffic, and voice traffic are all mapped to the AAL5 protocol.

Specific applications are listed below.

  • LAN traffic: LAN traffic is encapsulated in AAL5 using the multiprotocol encapsulation protocol defined in RFC 1483.
  • Signaling traffic: Both the ITU-T and the ATM Forum defined signaling on UNI and NNI encapsulated in AAL5 frames. Signaling messages are encapsulated in a special signaling ATM adaptation layer and then AAL5 frames.
  • ILMI traffic: Both the ITU-T and the ATM Forum defined management messaging between UNI and NNI encapsulated in AAL5 frames. These messages use the SNMP-encoded MIB statements carried in AAL5 frames.
  • Cisco voice traffic: Cisco IOS supports voice and telephony in its access concentrator devices. In these devices, AAL5 transports voice and signaling over ATM. Cisco supports multiple voice-encoding standards from 8 kbps to 64 kbps, all encapsulated in AAL5 frames.