The Logical Link Control Layer resides in the upper portion of the Data Link Layer. The LLC layer performs these functions:
Managing the data-link communication
Link Addressing
Defining Service Access Points (SAPs)
Sequencing
The LLC provides a way for the upper layers to deal with any type of MAC layer (e.g. Ethernet - IEEE 802.3 CSMA/CD or Token Ring IEEE 802.5 Token Passing).
The Data field of the MAC layer Frame transmits the LLC Protocol Data Unit.
LLC PDU Format
Service Access Ports (SAPs)
SAPs are Service Access Ports. A SAP is a port (logical link) to the Network layer protocol. If we were operating a multi protocol LAN, each Network Layer protocol would have its own SAP. This is the method that the LLC uses to identify which protocol is talking to which other protocol. For example, Unix's TCP/IP, Novell's SPX/IPX and IBM's Netbios would all have different SAPs (to identify which was which).
AddressAssignment00Null LSAP02Individual LLC Sublayer Management
Function03Group LLC Sublayer Management Function04IBM SNA Path Control
(individual)05IBM SNA Path Control (group)06ARPANET Internet Protocol
(IP)08SNA0CSNA0EPROWAY (IEC955) Network Management & Initialization18Texas
Instruments42IEEE 802.1 Bridge Spannning Tree Protocol4EEIA RS-511 Manufacturing Message
Service7EISO 8208 (X.25 over IEEE 802.2 Type 2 LLC)80Xerox Network Systems
(XNS)86Nestar8EPROWAY (IEC 955) Active Station List Maintenance98ARPANET
Address Resolution Protocol (ARP)BCBanyan VINESAASubNetwork Access Protocl
(SNAP)E0Novell NetWareF0IBM NetBIOSF4IBM LAN Management (individual)F5IBM
LAN Management (group)F8IBM Remote Program Load (RPL)FAUngermann-BassFEISO
Network Layer ProtocolFFGlobal LSAP
SAPs ensure that the same Network Layer protocol at the Source talks to the same Network Layer protocol at the Destination (i.e. TCP/IP talks to TCP/IP, Netbios talks to Netbios, and IPX/SPX talks to IPX/SPX).
Types of LLC Operation
LLC defines these two types of operation for data communication:
Type 1: Connectionless
Type 2: Connection Oriented
Type 1: Connectionless
Connectionless service for data communications is very similar to sending mail through the postal system (hand delivered mail): the data is sent and we hope it arrives at its destination. There is no feedback from the destination to indicate whether it arrived or not.
Type 1: Connectionless Service
Type 2: Connection Oriented
Connection Oriented service for data communications is very similar to having a phone conversation. A connection is made and established by dialing the number, waiting for it to ring, then someone picking up the line and saying hello. This establishes the connection. During the conversation, confirmation that the other person is still there and listening (hasn't fallen asleep or died) is given by hearing things like: yeah, oh really, uh huh, etc. This is the acknowledgement of receipt of data. If the destination party did not hear something correctly, they ask to have it repeated (i.e. automatic repeat request, or ARQ).
Connection Oriented service
NOTE: These models for connectionless and connection-oriented can be used for any protocol.
Type 2: Connection-Oriented operation for the LLC layer provides these 4 services:
Connection establishment
Confirmation and acknowledgement that data has been received.
Error recovery by requesting received bad data to be resent.
Sliding Windows (Modulus: 128)
Sliding Windows are a method of increasing the rate of data transfer. Type 2 Connection-Oriented operation calls for every Protocol Data Unit (LLC frame) sent to be acknowledged. If we waited for every PDU to be acknowledged before we sent the next PDU, we would have a very slow data transfer rate.
For example: If we were contacting Microsoft in Sunnyvale California, it might take 2 seconds for our LLC PDU to reach Microsoft, and another 2 seconds for the acknowledgement to return. This would mean that we are only sending 1 PDU every 4 seconds. If our PDU was IEEE 802.3 MAC's limit of 1500 octets (8x1500 = 12 Kbits), we would actually be transferring at 3 Kbps (12 kbits/4 seconds). This would occur regardless of our actual transfer rate. Waiting for an acknowledgement is controlling the data transfer rate!
To overcome this problem, a Sliding Window system of data transmission is used. Each PDU is sequentially numbered (0 - 127). Rather than wait for an acknowledgement, the next PDU is numbered and then sent out. The receive station LLC layer acknowledges (using the received PDU's numbers) back to the transmit station. The LLC will allow up to 128 PDUs to be sent, and not acknowledged, before it sounds an error alarm.
The received station LLC layer keeps track of the PDUs it is receiving: if one should be lost during transit, it requests the Source to restart transmitting at that PDU number. All PDUs after the lost PDU are discarded.
It is called a Sliding Window: the number of unacknowledged PDUs is determined by the time it takes to get to the destination, and for the destination to acknowledge the receipt of the PDU. This time is dependent on both the transfer rate and the physical distance the PDU must travel. It is set automatically: we do not have to worry about it.
Classes of LLC
The 2 Classes of Logical Link Control are defined below:
Class I :Type 1 operation only (connectionless)Class II:Both
Type 1 (connectionless) andType 2 (connection-oriented) operation allowed.
LLC PDU Control Field Formats
These are the 3 LLC PDU Control field formats:
Un-numbered (U-Format PDU)
Information Transfer (I-Format PDU)
Supervisory (S-Format PDU)
Un-numbered (U-Format PDU)
The last 2 bits are set to 1, to indicate a U-Format Control Field.
M - Modifier bits, they are set depending on the mode of operation: Command, Response or Data
P/F - Poll / Final bit: this bit is used by the Source to solicit a response from the Destination. It is used by the Destination to respond to a solicit from the Source.
The Un-numbered LLC Control field is used mainly in Type 1 (connectionless) operation. The PDUs are not numbered: they are sent out and hopefully arrive at their destination. U-Format PDUs can be commands, responses and data. There are only 8 bits in a U-Format LLC PDU. In the U-Format (Unnumbered), there are 8 commands & responses:
UI- Unnumbered information (here's some data - hope it arrives)
DISC- Disconnect (we're done, shut her down)
SABME- Set Asynchronous Balanced Mode Extended (start now)
XID- Exchange IDs(Here's who I am, who are you?)
TEST- Test the link (Here's a test, send me back a test)
UA- Unnumbered Acknowledgement(Yes, I'm still here)
DM- Disconnect Mode (I'm disconnecting)
FRMR- Frame Reject (Bad frame - reject)
Information Transfer (I-Format PDU)
It is used for transferring information or data between Source and Destination in a Type 2 (connection oriented) operation. It is the only LLC PDU allowed to transfer information in a Type 2 operation.
I-Format Control Field Format
The last bit is set to 0, to indicate that it is an I-Format Control Field.
P/F -Poll / Final bit: this bit is used by the Source to solicit a response from the Destination. It is used by the Destination to respond to a solicit from the Source.
N(R) -PDU number received. It is used with the Sliding Window and for acknowledging PDUs.
N(S) - PDU number sent. It is used with the Sliding Window and for acknowledging PDUs.
The N(R) bits are commonly called "Piggyback Acknowledgment" because the response is acknowledged along with the transfer of data. The acknowledgement is piggybacked onto a data transfer.
In the I-Format (Information), there are no commands & responses, but it is typically indicated by the following:
I- Information (data transfer)
Supervisory (S-Format PDU)
Supervisory (S-Format) LLC Control fields are used for Data Link supervisory control functions (handshaking). The S-Format Control fields are used for acknowledging I-Format PDUs, requesting retransmission, and for requesting a temporary suspension of transmission (buffers full - wait).
S-Format LLC PDU Control Field
The last 2 bits are set to 0 1, to indicate that it is a S-Format Control Field
S - Supervisory function bits, determines the purpose of the control field.
The four 0s in a row are reserved bits, and are always set to 0.
P/F - Poll / Final bit, this bit is used by the Source to solicit a response from the Destination. It is used by the Destination to respond to a solicit from the Source.
N(R) - PDU number received. Used with the Sliding Window, and for acknowledging PDUs.
In the S-Format (Supervisory), these are the 3 commands & responses:
RR- Receive Ready (awake & ready to receive)
RNR - Receive Not Ready (got problems, hold off for awhile)
REJ - Reject (received a bad PDU, send the PDU with this number again)
If this section was helpful, why not donate to further development?