ATM Encapsulation Methods

View this file in pdf format.

A number of standards have been developed which describe the encapsulation of LAN and WAN protocols over ATM. These standards allow users to integrate ATM into existing WANs and/or LANs, thus providing various cost-effective upgrade routes. This chapter describes the various encapsulation methods in general; specific information concerning the analysis or decoding of particular protocols may be found in the respective protocol chapters.

The following methods are used for encapsulation or transporting LAN or WAN protocols via ATM:

  • VC-based Encapsulation
    Uses predefined VPI/VCI values for specific protocols. Used for WAN or LAN protocols.
  • Multiprotocol Encapsulation over ATM Adaptation Layer 5 (IETF RFC1483)
    Covers encapsulation of LAN protocols over ATM with the use of the LLC header.
  • Classical IP and ARP over ATM (IETF RFC1577)
    Covers ARP/RARP encapsulation.
  • Frame Relay over ATM
    Describes transmission of Frame Relay via ATM.
  • LAN Emulation
    Emulates Ethernet or Token Ring LANs.


VC-Based (null) Multiplexing

VC-based multiplexing uses one Virtual Channel (VCI/VPI pair) for each protocol. In this way, the protocol is carried directly over the AAL5 PDU. Since no additional information is added to the protocol, this is sometimes called null encapsulation.

For routed protocols e.g., TCP/IP, IPX, the PDU is carried directly in the payload of the AAL5 CPCS PDU. For bridged protocols e.g., Ethernet, Token Ring, FDDI, all fields following the PID field are carried in the payload of the AAL5 CPCS PDU.


Multiprotocol Encapsulation over ATM

One method of transmitting LAN protocols over ATM is by using LLC encapsulation with the IETF RFC1483 standard. In this instance, the LLC and SNAP headers within the AAL5 PDU are used to identify the encapsulated protocol. This protocol stack is shown in the following illustration.

Upper-layer applications
Upper-layer protocols

Ethernet or TCP/IP


802.2 LLC




LAN protocols encapsulated over ATM

In multiprotocol encapsulation, the PDUs are carried in the Payload field of the Common Part Convergence Sublayer (CPCS) PDU of ATM Adaptation Layer type 5 (AAL5). In this encapsulation method, the LLC header is always 0xAA-AA-03, which indicates that the LLC header is followed by a SNAP header.




LLC header

The format of the SNAP header is as follows:

Organizationally Unique Identifier (OUI)

Protocol Identifier (PID)

3 bytes

2 bytes

SNAP header

Non-ISO PDUs e.g., TCP/IP, IPX, are identified by an OUI value of 0x00-00-00, followed by the PID, which represents the 2-byte EtherType field. For example, an EtherType value of 0x08-00 identifies an IP PDU.

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType (2 bytes)

(up to 65527 bytes)

Payload format for routed non-ISO PDUs

Non-routed bridged protocols are identified by an OUI value of 0x00-80-C2 followed by the 2-byte PID which specifies the protocol which follows. The following table lists some possible values for the PID field in this instance.

PID Value . . . Protocol . . .
0x00-01/0x00-07 Ethernet/802.3
0x00-03/0x00-09 Token Ring/802.5
0x00-04/0x00-0A FDDI

The following diagrams represent the payload format for the Ethernet, Token Ring, FDDI and SMDS PDUs.

LLC 0xAA-AA-03 LLC 0xAA-AA-03
OUI 0x00-80-C2 OUI 0x00-80-C2
PID 0x00-01 or 0x00-07 PID 0x00-03 or 0x00-09
PAD 0x00-00 PAD 0x00-00-xx
MAC destination address Frame Control (1 byte)
remainder of MAC frame
MAC destination address
remainder of MAC frame
LAN FCS (if PID is 0x00-01) LAN FCS (if PID is 0x00-03)

Payload format for bridged Ethernet/802.3 PDUs

Payload format for bridged Token Ring/802.5 PDUs

LLC 0xAA-AA-03 LLC 0xAA-AA-03
OUI 0x00-80-C2 OUI 0x00-80-C2
PID 0x00-04 or 0x00-0A PID 0x00-0B
PAD 0x00-00-00 Reserved BEtag Common PDU


Frame Control (1 byte) BAsize
MAC destination address MAC destination address

remainder of MAC frame

remainder of MAC frame
LAN FCS (if PID is 0x00-01) LAN FCS (if PID is 0x00-01)

Payload format for bridged FDDI PDUs

Payload format for bridged SMDS PDUs

The following capture display in multi-protocol mode lists the LLC protocol followed by encapsulated IP.

image26.gif (9238 bytes)

Decode of LLC with encapsulated IP


IP Addressing over ATM

The standard IETF RFC1577 describes a version of ARP and InARP which is appropriate for ATM. According to this standard, the LLC and SNAP headers identify the encapsulated protocol as described above in Multiprotocol Encapsulation over ATM. The LLC header has the value 0xAA-AA-03, which indicates that the LLC header is followed by a SNAP header. The OUI value for ARP is 0x00-00-00, followed by the EtherType field of value 0x08-06.

Internet addresses are assigned independently of ATM addresses. Each host implementation must know its own IP and ATM address(es) and must respond to address resolution requests appropriately. IP members must also use ATMARP and InATMARP to resolve IP addresses to ATM addresses when needed.

The ATMARP PDU is shown in the following illustration.





Hardware type

Protocol type

Type and length of source ATM number

Type and length of source ATM subaddress


Length of source protocol address

Type and length of target ATM number

Type and length of target ATM subaddress

Length of target protocol address

Source ATM number (q bytes)

Source ATM subaddress (r bytes)

Source protocol address (s bytes) (IP=4 bytes)

Target ATM number (x bytes)

Target ATM subaddress (y bytes)

Target protocol address (z bytes) (IP=4 bytes)

Payload format for ATMARP PDU

ATMARP and InATMARP use the same hardware type, protocol type and operation code data formats as ARP and InARP. The location of these fields within the ATMARP packet are in the same byte position as those in ARP and InARP packets. A unique hardware type value has been assigned for ATMARP.


Frame Relay over ATM

Multiprotocol Encapsulation

In multiprotocol encapsulation, a Frame Relaying Service Specific Convergence Sublayer (FR-SSCS) is used on top of the Common Part Convergence Sublayer (CPCS) of the AAL type 5 for Frame Relay/ATM internetworking. The service, offered by FR-SSCS, corresponds to the Core service for Frame Relaying as described in I.233.

An FR-SSCS PDU consists of Q.922 Address field followed by Q.922 Information field. The Q.922 flags and the FCS are omitted, since the corresponding functions are provided by the AAL. The figure below shows an FR-SSCS PDU embedded in the Payload of an AAL5 CPCS PDU.

Q.922 Address field
2-4 bytes

FR-SSCS PDU header

Q.922 Information field

FR-SSCS PDU payload

AAL CPCS PDU trailer

FR-SSCS PDU in payload of AAL CPCS PDU

Routed and bridged PDUs are encapsulated inside the FR-SSCS PDU as defined in IETF RFC1294. The Q.922 Information field starts with a Q.922 Control field followed by an optional Pad octet that is used to align the remainder of the frame to a convenient boundary for the sender. The protocol of the carried PDU is then identified by prefixing the PDU by an ISO/CCITT Network Layer Protocol ID (NLPID).

In the specific case of an IP PDU, the NLPID is 0xCC. According to IETF RFC1294 the Q.922 Address field should be either 2 or 4 octets, i.e., a 3 octet Address field is not supported. In the case of ISO protocols, the NLPID field forms the first octet of the PDU itself and should not be repeated.

Q.922 Address field
(2 or 4 bytes)

0x03 (Q.922 Control)


(up to 216-5 bytes)

FR-SSCS PDU format for routed IP PDUs

The above encapsulation applies only to those routed protocols that have a unique NLPID assigned. For other routed protocols (and for bridged protocols), it is necessary to provide another mechanism for easy protocol identification. This can be achieved by using an NLPID value of 0x80 to indicate an IEEE 802.1a SubNetwork Attachment Point (SNAP) header.

Frame Relay/ATM Internetworking

Mapping between ATM PDUs and Frame Relay PDUs requires examination of the incoming ATM AAL5 CPCS PDU payload header or Frame Relay Q.922 PDU payload header to determine the type, and then to overwrite the incoming header with the outgoing header.

The following diagram show the translation between the Frame Relay Q.922 PDU payload header and the ATM AAL5 CPCS PDU payload header.

Control 0x03 Pad 0x00 LLC 0xAA-AA
NLPID 0x80 OUI 0x00 0x03 OUI 0x00
0x80-C2 0x80-C2
Remainder of MAC frame Pad 0x00-00
Remainder of MAC Frame

Frame Relay payload header

ATM AAL5 CPCS PDU payload header

Refer to Frame Relay Forum FRF.8 for detailed information concerning the provisions for traffic management between the two protocols.


LAN Emulation

The LAN emulation protocol uses control messages to set up the LAN. LAN Emulation provides for two possible data packet formats: Ethernet and Token Ring. The LAN emulation data frames preserve all the information contained in the original 802.3 or 802.5 frames, but add a 2-byte LEC ID (the source ID), which is unique to each LEC.

Refer to LAN Emulation for a more detailed description.

search ][ protocols by family ][ index of protocols