Protocol Directory - ATM Encapsulation Methods

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 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.

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

SNAP

802.2 LLC

AAL5

ATM

Physical

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.

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.

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.

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 Header
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.

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.

8	16	24		32
Hardware type			Protocol type
Type and length of source ATM number	Type and length of source ATM subaddress	Operation
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)

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.

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

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)

NLPID (OxCC)

IP PDU
(up to 2¹⁶-5 bytes)

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.

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
PID		PID
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.

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.