ATM Adaptation Layer 5 (AAL5) is an ATM adaptation layer used to send variable-length packets up to 65,535 octets in size across an Asynchronous 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 and CPI 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.
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.
Packet type and multiplexing
The AAL5 trailer does not include a type field. Thus, an AAL5 frame does not identify 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 a Subnetwork 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.
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.
