LAN Data Link Layer Protocols

 
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? click here

 

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? click here

 

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? click here

 

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? click here

 

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? click here

 

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? click here

 

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? click here

 

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? click here

 

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? click here

 

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? click here

 

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? click here

 

Lan Data Link Layer Protocols Information
CIF | Ethernet | FDDI | GARP | GMRP | GVRP | LLC | Multiprotocol over ATM | SNAP | SRP MAC Protocol | Token Ring | VLAN

 
Additional Information