| The Data Link Layer protocols
described here include: |
| |
|
| CIF |
Cells in Frames |
| Ethernet |
|
| FDDI |
Fiber Distributed Data Interface |
| GARP |
Generic Attribute Registration Protocol |
| GMRP |
Multicast Registration Protocol. |
| GVRP |
GARP VLAN Registration Protocol |
| LLC |
Logical Link Control. |
| Multiprotocol over ATM |
|
| SNAP |
SubNetwork Access Protocol |
| SRP MAC Protocol |
Spatial
Reuse Protocol |
| Token Ring |
|
| VLAN |
|
The Data Link Layer defines how data is formatted
for transmission and how access to the network is controlled.
This layer has been divided by the IEEE 802 standards committee
into two sublayers: media access control (MAC) and logical link
control (LLC).
FDDI, Token Ring and Ethernet may be physical
interfaces or may act as logical protocols encapsulated over
a WAN protocol or ATM.
The Data Link Layer protocols is illustrated
here in relation to the OSI model:
Click the protocols on the map to
see more details.
Ethernet
Ethernet is a widely used data communications
network standard developed by DEC, Intel, and Xerox. It uses
a bus topology and CMSA/CD access method. The terms Ethernet
and the IEEE 802.3 standard are often used interchangeably.
The Ethernet header structure is shown in
the illustration below.
|
Destination |
Source |
Len |
Data unit + pad |
FCS |
|
(6 bytes) |
(6 bytes) |
(2) |
(46-1500 bytes) |
(4 bytes) |
Ethernet
header structure |
Destination address
The address structure is as follows:
|
I/G |
U/L |
Address bits |
|
Ethernet destination address structure |
| I/G |
Individual / group address may be: |
| |
0 |
Individual address. |
| |
1 |
Group address. |
| U/L |
Universal /local address may be: |
| |
0 |
Universally administered. |
| |
1 |
Locally administered. |
Source address
The address structure is as follows:
|
0 |
U/L |
Address bits |
Ethernet
source address structure |
| 0 |
The first bit is always 0. |
| U/L |
Universal/local address may be: |
| |
0 |
Universally administered. |
| |
1 |
Locally administered. |
Length/type
In the Ethernet protocol, the value
(³ 0x0600 Hex) of this field is Ethernet List, indicating
the protocol inside.
In the 802.3 protocol, the value (46-1500
Dec) is the length of the inner protocol, which is the LLC encapsulated
inner protocol. (The LLC header indicates the inner protocol
type.)
Data unit + pad
LLC protocol.
FCS
Frame check sequence.
Interested in more details about testing
this protocol?
Token
Ring
Token Ring is a LAN protocol where all stations
are connected in a ring and each station can directly hear transmissions
only from its immediate neighbor. Permission to transmit is
granted by a message (token) that circulates around the ring.
The Token Ring header structure is shown
in the illustration below.
|
SDEL 1 byte |
|
Access control 1 byte |
|
Frame control 1 byte |
|
Destination address 6 bytes |
|
Source address 6 bytes |
|
Route information 0-30 bytes |
|
Information (LLC or MAC) variable |
|
FCS 4 bytes |
|
EDEL 1 byte |
|
Frame status 1 byte |
Token
Ring header structure |
SDEL / EDEL
Starting Delimiter / Ending Delimiter.
Both the SDEL and EDEL have intentional Manchester code violations
in certain bit positions so that the start and end of a frame
can never be accidentally recognized in the middle of other data.
Access control
The format is as follows:
|
P |
P |
P |
T |
M |
R |
R |
R |
|
Token Ring access control format |
| PPP |
Priority bits: |
|
000 |
Lowest priority. |
|
111 |
Highest priority. |
| T |
Token bit: |
|
0 |
Token. |
|
1 |
Frame. |
| M |
Monitor count: |
|
0 |
Initial Value. |
|
1 |
Modified to active monitor. |
| RRR |
Reservation bits: |
|
000 |
Lowest priority reservation. |
|
111 |
Highest priority reservation. |
Frame control
The format is as follows:
|
Frame type (2) |
0 |
0 |
Attention (4 bits) |
| Token
Ring frame control format |
Frame type may have the following values:
| 00 |
MAC frame. |
| 01 |
LLC frame. |
| 11 or 10 |
Undefined. |
The second 2 bits are always zero.
Attention indicates those frames for which
the adapter does special buffering and processing.
| 0001 |
Express buffer. |
| 0010 |
Beacon. |
| 0011 |
Claim token. |
| 0100 |
Ring purge. |
| 0101 |
Active monitor present. |
| 0110 |
Standby monitor present. |
Destination address
The address structure is as follows:
|
I/G |
U/L |
Address bits |
|
Token Ring destination address structure |
| I/G |
Individual / group address may be: |
| |
0 |
Individual address. |
| |
1 |
Group address. |
| U/L |
Universal /local address may be: |
| |
0 |
Universally administered. |
| |
1 |
Locally administered. |
Source address
The address structure is as follows:
|
RII |
I/G |
Address bits |
|
Token Ring source address structure |
| RII |
Routing information indicator: |
|
0 |
RI absent. |
|
1 |
RI present. |
| I/G |
Individual/group address: |
|
0 |
Group address. |
|
1 |
Individual address. |
Route information
The structure is as follows:
| |
RI
Field |
|
|
| |
RC
Field |
|
|
RD
Fields |
|
RT |
LTH |
D |
LF |
r |
RD1 |
RD2 |
… |
RDn |
| 3 |
5 |
1 |
6 |
1 |
16 |
16 |
|
16 |
bits |
| |
Length
in LTH Field |
|
|
Token Ring route information structure
|
| RC |
Routing control (16 bits). |
| RDn |
Route descriptor (16 bits). |
| RT |
Routing type (3 bits). |
| LTH |
Length (5 bits). |
| D |
Direction bit (1 bit). |
| LF |
Largest frame (6 bits). |
| r |
Reserved (1 bit). |
Information
The Information field may be
LLC or MAC. The MAC information structure is as follows:
|
Major vector |
Subvector 1 |
|
Subvector n |
|
VL |
VI |
SVL |
SVI |
SVV |
… |
SVL |
SVI |
SVV |
|
2 |
2 |
1 |
1 |
n |
|
1 |
1 |
n bytes |
| Token
Ring MAC information structure |
VL
Major vector length. Specifies
the length of the vector in octets.
VI
Major vector identifier. A code
point that identifies the vector. The VI format is as follows:
|
4 |
8 |
16 bits |
|
Destination class |
Source class |
Major vector code |
Token
Ring major vector identifier |
Destination class / source class
Class fields assure proper routing
within a ring station:
| 0 |
Ring station. |
| 4 |
Configuration report server. |
| 5 |
Ring parameter server. |
| 6 |
Ring error monitor. |
Major vector code
The vector code uniquely defines
the vector:
| 0x00 |
Response. |
| 0x02 |
Beacon. |
| 0x03 |
Claim token. |
| 0x04 |
Ring purge. |
| 0x05 |
Active monitor present. |
| 0x06 |
Standby monitor present. |
| 0x07 |
Duplicate address test. |
| 0x08 |
Lobe media test. |
| 0x09 |
Transmit forward. |
| 0x0B |
Remove ring station. |
| 0x0C |
Change parameters. |
| 0x0D |
Initialize ring station. |
| 0x0E |
Request station addresses. |
| 0x0F |
Request station state. |
| 0x10 |
Request station attachment. |
| 0x20 |
Request initialization. |
| 0x22 |
Report station addresses. |
| 0x23 |
Report station state. |
| 0x24 |
Report station attachment. |
| 0x25 |
Report new active monitor. |
| 0x26 |
Report SUA change. |
| 0x27 |
Report neighbor notification incomplete. |
| 0x28 |
Report active monitor error. |
| 0x29 |
Report error. |
SVL
Sub-vector length. Specifies
the length of the sub-vector in octets.
SVI
Sub-vector identifier. A code
point that identifies the sub-vector:
| 0x01 |
Beacon type. |
| 0x02 |
Upstream neighbor addresses next. |
| 0x03 |
Local ring number. |
| 0x04 |
Assign physical drop number next. |
| 0x05 |
Error timer value. |
| 0x06 |
Authorized function classes next. |
| 0x07 |
Authorized access priority. |
| 0x08 |
Authorized environment. |
| 0x09 |
Correlation. |
| 0x0A |
SA of last AMP or SMP. |
| 0x0B |
Physical drop number. |
| 0x20 |
Response code. |
| 0x21 |
Reserved. |
| 0x22 |
Product instance ID. |
| 0x23 |
Ring station version number. |
| 0x26 |
Wrap data. |
| 0x27 |
Frame forward. |
| 0x28 |
Station identifier. |
| 0x29 |
Ring station status. |
| 0x2A |
Transmit status code. |
| 0x2B |
Group address(es). |
| 0x2C |
Functional address(es). |
| 0x2D |
Isolating error count. |
| 0x2E |
Non-isolating error count. |
| 0x2F |
Function request ID. |
| 0x30 |
Error code. |
SVV
Sub-vector value - Variable length
sub-vector information.
FCS
Frame check sequence.
Frame status
Contains bits that may be set
on by the recipient of the frame to signal recognition of the
address and whether the frame was successfully copied.
 |
Token Ring decode |
Interested in more details about testing
this protocol?
FDDI
The Fiber Distributed Data Interface (FDDI)
is a 100 Mega-bit technology using a timed token over a dual
ring of trees. FDDI is standardized by the American National
Standards Institute (ANSI).
The FDDI header structure is shown in the
illustration below.
|
Frame control |
Destination address |
Source address |
Route information |
Information |
FCS |
|
2 |
6 |
6 |
0-30 |
|
4 bytes |
|
FDDI header structure |
Frame control
The frame control structure is
as follows:
|
C |
L |
F |
F |
Z |
Z |
Z |
Z |
| |
bits |
|
FDDI frame control structure |
| C |
Class bit: |
|
0 |
Asynchronous frame. |
|
1 |
Synchronous frame/ |
| L |
Address length bit: |
|
0 |
16 bits (never). |
|
1 |
48 bits (always). |
| FF |
Format bits. |
| ZZZZ |
Control bits. |
|
The following is a description of the various
Frame Control field values (CLFF ZZZZ to ZZZZ): |
|
0x00 0000 |
Void frame. |
|
1000 0000 |
Non-restricted token. |
|
1100 0000 |
Restricted token. |
|
0L00 0001 to 1111 |
Station management frame. |
|
1L00 1111 |
SMT next station addressing frame. |
|
1L00 0001 to 1111 |
MAC frame. |
|
1L00 0010 |
MAC beacon frame. |
|
1L00 0011 |
MAC claim frame. |
|
CL01 r000 to r111 |
LLC frame. |
|
0L01 rPPP |
LLC information frame (asynchronous, PPP=frame
priority). |
|
0L01 rrrr |
LLC information frame (synchronous, r=reserved). |
|
CL10 r000 to r111 |
Reserved for implementer. |
|
CL11 rrrr |
Reserved for future standardization. |
Destination address
The address structure is as follows:
|
I/G |
U/L |
Address bits |
|
FDDI destination address structure |
| I/G |
Individual / group address may be: |
|
0 |
Individual address. |
|
1 |
Group address. |
| U/L |
Universal /local address may be: |
|
0 |
Universally administered. |
|
1 |
Locally administered. |
Source address
The address structure is as follows:
|
I/G |
RII |
Address bits |
FDDI
source address structure |
| I/G |
Individual/group address: |
|
0 |
Group address. |
|
1 |
Individual address. |
| RII |
Routing information indicator: |
|
0 |
RI absent. |
|
1 |
RI present. |
Route Information
The structure of the route information
is as follows:
| |
RI
Field |
|
|
| |
RC
Field |
|
|
RD
Fields |
|
RT |
LTH |
D |
LF |
r |
RD1 |
RD2 |
… |
RDn |
| 3 |
5 |
1 |
6 |
1 |
16 |
16 |
|
16 |
bits |
| |
Length
in LTH Field |
|
|
FDDI route information structure
|
| RC |
Routing control (16 bits). |
| RDn |
Route descriptor (16 bits). |
| RT |
Routing type (3 bits). |
| LTH |
Length (5 bits). |
| D |
Direction bit (1 bit). |
| LF |
Largest frame (6 bits). |
| r |
reserved (1 bit). |
Information
The Information field may be
LLC, MAC or SMT protocol.
FCS
Frame check sequence.
Interested in more details about
testing this protocol?
LLC
The IEEE 802.2 Logical Link Control (LLC)
protocol provides a link mechanism for upper layer protocols.
LLC type I service provides a datalink connectionless mode service,
while LLC type II provides a connection-oriented service at
the datalink layer.
The LLC header structure is shown in the
illustration below.
|
DSAP |
SSAP |
Control |
LLC information |
|
1 byte |
1 bytes |
1 or 2 bytes |
|
LLC
header structure |
DSAP
The destination service access point structure
is as follows:
|
I/G |
Address bits |
|
LLC DSAP structure |
| I/G |
Individual/group address may be: |
|
0 |
Individual DSAP. |
|
1 |
Group DSAP. |
SSAP
The source service access point
structure is as follows:
|
C/R |
Address bits |
LLC
SSAP structure |
| C/R |
Command/response: |
|
0 |
Command. |
|
1 |
Response. |
Control
The structure of the control
field is as follows:
| |
1 |
8 |
9 |
16 bits |
| Information
|
0 |
N(S) |
P/F |
N(R) |
| Supervisory
|
1 |
0 |
SS |
XXXX |
P/F |
N(R) |
| Unnumbered
|
1 |
1 |
MM |
P/F |
MMM |
|
LLC control field structure
|
| N(S) |
Transmitter send sequence number. |
| N(R) |
Transmitter receive sequence number. |
P/F
|
Poll/final bit. Command LLC PDU transmission/
response LLC PDU transmission. |
|
S |
Supervisory function bits: |
|
00 |
RR (receive ready). |
|
01 |
REJ (reject). |
|
10 |
RNR (receive not ready). |
| X |
Reserved and set to zero. |
| M |
Modifier function bits. |
LLC information
LLC data or higher layer protocols.
Interested in more details about testing
this protocol?
SNAP
RFC 1042 http://www.cis.ohio-state.edu/htbin/rfc/rfc1042.html
The SubNetwork Access Protocol (SNAP)
is used for encapsulating IP datagrams and ARP requests and
replies on IEEE 802 networks. IP datagrams are sent on IEEE
802 networks encapsulated within the 802.2 LLC and SNAP data
link layers and the 802.3, 802.4 or 802.5 physical network
layers. The SNAP header follows the LLC header and contains
an organization code indicating that the following 16 bits
specify the EtherType code.
The SNAP header is as shown in the following illustration:
DSAP |
SSAP |
Control |
1 byte |
1 byte |
1 byte |
LLC
header structure |
Organization code |
EtherType |
3 bytes |
2 bytes |
SNAP
header structure
|
When SNAP is present the DSAP and
SSAP fields within the LLC header contain the value 170 (decimal)
each and the Control field is set to 3 (unnumbered information).
Organization code
Set to 0.
EtherType
Specifies which protocol is encapsulated
within the IEEE 802 network: IP = 2048, ARP = 2054.
Interested in more details about testing
this protocol?
CIF
CIF (Cells In Frames) describes the mechanism
by which ATM traffic is carried across a media segment and a
network interface card conforming to the specification for Ethernet
Version 2, IEEE 802.5 Token Ring, or IEEE 802.3. ATM cells can
be carried over many different physical media, from optical
fiber to spread spectrum radio. ATM is not coupled to any particular
physical layer. CIF defines a new pseudo-physical layer over
which ATM traffic can be carried. It is not simply a mechanism
for translation between frames and cells; neither is it simple
encapsulation. CIF carries ATM cells in legacy LAN frames. This
defines a protocol between CIF end system software and CIF attachment
devices ("CIF-AD") which makes it possible to support
ATM services, including multiple classes of service, over an
existing LAN NIC just as if an ATM NIC were in use. CIF specifies
how the ATM layer protocols can be made to work over the existing
LAN framing protocols in such a way that the operation is transparent
to an application written to an ATM compliant API. Over Ethernet,
CIF frames have an Ethernet header and trailer. CIF frames are
encapsulated in Token Ring and LLC by use of a SNAP header.
(Compliant with Cells in Frames Version 1.0 Specification, Analysis
and discussion.)
The format of the header is shown in the
following illustration:
|
1 |
8 |
9 |
11 |
16 |
|
P |
CIF Format |
P |
F F |
Format flags |
|
P |
Format flags |
GFC |
VPI |
|
VPI |
VCI |
VCI |
PT |
C |
HEC |
|
CIF header format |
P
Even Parity bit for an octet.
CIF Format
CIF Format Identifier. Only three
format types are defined. Formats 0 and 1 are used for CIF signalling.
Format 2 is the default format for carrying user traffic. Formats
112-127 are reserved for use in experimentation and for pre-standard
CIF implementations.
FF
CIF format independent flags.
These bits contain flags that are independent of any CIF format
type. These CIF format independent flags are reserved. They
are set to 0 when sent and are ignored when received.
Format flags
CIF format dependent flags. The
CIF format dependent flags differ depending on the CIF format
type.
GFC
Generic Flow Control. The structure
and semantics of octets 3-7 in the CIF header are the same as
those of an ATM UNI cell header. These octets are collectively
known as the "CIF cell header template".
VPI
Virtual Path Identifier.
VCI
Virtual Channel Identifier.
PT
Payload Type.
C
Cell Loss Priority.
HEC
Header Error Check. The sender of a LAN frame always calculates
and fills in the HEC field. The receiver may either rely on
the LAN CRC to detect errors in the frame (i.e., not validate
the received HECs), or it may check the correctness of the HEC.
Interested in more
details about testing this protocol?
GARP
IEEE 802.1P http://standards.ieee.org/catalog/IEEE802.1.html
The Generic Attribute Registration Protocol (GARP) provides
a generic attribute dissemination capability that is used by
participants in GARP applications to register and de-register
attribute values with other GARP participants within a Bridged
LAN. A GARP participant in a bridge or an end station consists
of a GARP application component and a GARP Information Declaration
(GID) component associated with each port of the bridge. The
propagation of information between GARP participants for the
same application in a bridge is carried out by the GARP Information
Propagation (GIP) component. Protocol exchanges take place between
GARP participants by means of LLC Type 1 services, using the
group MAC address and PDU format defined for the GARP application
concerned.
The format of the GARP PDU is shown in the following illustration:
2
bytes |
|
Protocol ID |
Message |
GARP
PDU structure |
| 1
byte |
|
Attribute
type |
Attribute
1 |
. . . |
Attribute
n |
End
mark |
| GARP
message structure |
| 1
byte |
1
byte |
1
byte |
Attribute
length |
Attribute
event |
Attribute
value |
GARP
attribute structure |
Protocol ID
Identifies the GARP protocol.
Identifier
Decimal value which aids in matching requests and replies.
Attribute type
Defines the attribute. Values may be:
1 Group attribute.
2 Service Requirement attribute.
Attribute length
Length of the Attribute.
Attribute event
The values of the attribute event can be:
0
1
2
3
4
5 |
Leave_all
Join_Empty operator
Join_In operator
Leave_Empty operator
Leave_In operator
Empty operator |
The default is reserved.
Attribute value
This is encoded in accordance with the specification for the
Attribute Type.
End mark
Coded as 0.
Interested in more details about testing
this protocol?
GMRP
IEEE 802.1P
http://standards.ieee.org/catalog/IEEE802.1.html
The GARP Multicast Registration Protocol (GMRP) provides a mechanism
that allows bridges and end stations to dynamically register
group membership information with the MAC bridges attached to
the same LAN segment and for that information to be disseminated
across all bridges in the Bridged LAN that supports extended
filtering services. The operation of GMRP relies upon the services
provided by the GARP.
The format of the GMRP packet is that of the GARP. However,
the attribute type is specific to GMRP: it can be as follows:
1 Group Attribute Type.
2 Service Requirement Attribute Type.
Interested in more details about testing
this protocol?
GVRP
IEEE 802.1P
http://standards.ieee.org/catalog/IEEE802.1.html
The GARP VLAN Registration Protocol (GVRP) defines a GARP application
that provides the VLAN registration service. It makes use of
GID and GIP, which provide the common state machine descriptions
and the common information propagation mechanisms defined for
use in GARP-based applications.
The format of the GVRP packet is that of the GARP. However,
the attribute type is specific to GVRP:
1 VID Group Attribute Type.
Interested in more details about testing
this protocol?
VLAN
IEEE 802.1Q
http://standards.ieee.org/catalog/IEEE802.1.html
A VLAN is a logical group of LAN segments, independent of physical
location, with a common set of requirements. VLAN tagged frames
carry an explicit identification of the VLAN to which it belongs.
The value of the VID in the Tag header signifies the particular
VLAN it belongs to. This additional tag field appears in the
Ethernet and SNAP protocols.
The format of the Ethernet encoded Tag header is shown in the
following illustration:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
ETPID |
1 |
| 2 |
| TCI
|
3 |
| 4 |
|
Length/type |
|
|
E-RIF |
7-n |
Ethernet-encoded
tag header |
ETPID
Ethernet-coded Tag Protocol Identifier. Value is 81-00.
TCI
Tag Control Information. The structure of the TCI field is as
follows:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
| User
priority |
CFI |
VID |
1 |
VID |
2 |
TCI
structure |
User priority
3-bit binary number representing 8 priority levels, 0-7.
CFI
Canonical Format Indicator. When set, the E-RIF field is present
and the NCFI bit determines whether MAC address information
carried by the frame is in canonical or non-canonical format.
When reset, indicates that the E-RIF field is not present and
that all MAC information carried by the frame is in canonical
format.
VID
VLAN Identifier. Uniquely identifies the VLAN to which the frame
belongs.
| 0 |
Null VLAN ID. Indicates
that the tag header contains only user priority information,
no VLAN ID. |
| 1 |
Default PVID value used for classifying
frames on ingress through a bridge port. |
| FFF |
Reserved for implementation use. |
All other values are available for
general use as VLAN identifiers.
E-RIF
Embedded RIF format. Present only if CFI is set in TCI. When
present, immediately follows the Length/Type field. E-RIF consists
of two components: 2-octet Route Control (RC) field and 0 or
more octets of Route Descriptors, up to a maximum of 28 octets.
E-RIF may be 2-30 octets.
The format of the RC is as follows:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
| RT |
LTH |
1 |
D
|
LF |
NCFI |
2 |
RC
structure |
RT
Routing type.
LTH
Length field.
D
Direction bit.
LF
Largest frame.
NCFI
Non-Canonical Format Indicator. When reset, all MAC address
information in the frame is in non-canonical format. When set,
all MAC address information in the frame is in canonical format.
The format of the SNAP-encoded Tag header on 802.5 is shown
in the following illustration:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
|
SNAP header
(AA-AA-03) |
1-3 |
|
SNAP PID (00-00-00) |
4-6 |
| Tag protocol
type (81-00) |
7-8 |
TCI |
9-10 |
SNAP-encoded
tag header on 802.5 |
Values of the SNAP header, SNAP PID
and Tag protocol type are given in the illustration. TCI value
is as described for Ethernet-encoded tag header.
The format of the SNAP-encoded Tag header on FIDDI is shown
in the following illustration:
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Octet |
| SNAP
header (AA-AA-03) |
1-3 |
SNAP
PID (00-00-00) |
4-6 |
| Tag
protocol type (81-00) |
7-8 |
TCI |
9-10 |
E-RIF
|
11,
12 |
SNAP-encoded
tag header on FDDI |
Values of the SNAP header, SNAP PID
and Tag protocol type are given in the illustration. The TCI
and E-RIF fields are as described for Ethernet-encoded tag header.
The E-RIF field is present only if CFI is set in TCI and RII
is reset. It may be between 2 and 30 octets long.
Interested in more details about
testing this protocol?
Multiprotocol
over ATM
IETF RFC 2684 http://www.cis.ohio-state.edu/htbin/rfc/rfc2684.html
Multiprotocol Encapsulation over ATM Adaptation Layer 5 (IETF
RFC 2684): covers encapsulation of LAN protocols over ATM with
the use of the LLC header.
One method of transmitting LAN protocols
over ATM is by using LLC encapsulation. 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 applicationsUpper-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.
DSAP
AA |
SSAP
AA |
Ctrl
03 |
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 |
OUI 0x00-80-C2 |
PID 0x00-01 or 0x00-07 |
PAD 0x00-00 |
MAC destination address |
remainder of MAC
frame |
LAN FCS (if PID is 0x00-01) |
Payload
format for bridged
Ethernet/802.3 PDUs |
|
|
LLC 0xAA-AA-03 |
OUI 0x00-80-C2 |
PID 0x00-03 or 0x00-09 |
PAD 0x00-00-xx |
Frame Control (1 byte) |
MAC destination address |
remainder of MAC
frame |
LAN FCS (if PID
is 0x00-03) |
Payload
format for bridged Token
Ring/802.5 PDUs |
|
LLC 0xAA-AA-03 |
OUI 0x00-80-C2 |
PID 0x00-04 or 0x00-0A |
PAD 0x00-00-00 |
Frame Control (1 byte) |
|
MAC destination address |
|
remainder of MAC frame |
LAN FCS (if PID is 0x00-01)
|
Payload
format for bridged
FDDI PDUs |
|
|
LLC 0xAA-AA-03 |
|
OUI 0x00-80-C2 |
|
PID 0x00-0B |
|
Reserved |
BEtag |
Common
PDU
Header |
BAsize |
MAC destination
address |
|
remainder
of MAC frame |
|
LAN
FCS (if PID is 0x00-01) |
|
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.
 |
Decode of LLC
with encapsulated IP |
Interested in more
details about testing this protocol?
Lan
Data Link Layer Protocols
Information
CIF | Ethernet | FDDI | GARP | GMRP | GVRP | LLC | Multiprotocol
over ATM | SNAP | SRP
MAC Protocol | Token Ring | VLAN
|
