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 (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 |
SNAP
|
802.2 LLC
|
AAL5
|
ATM
|
Physical
|
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) |
Non-ISO PDU
(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
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.
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.
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)
|
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) |
NLPID (OxCC)
|
IP PDU (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 |
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.
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
|