IEEE 802.2 is the original name of the ISO/IEC 8802-2 standard which defines Logical Link Control (LLC) as the upper portion of the data link layer of the OSI Model. The original standard developed by the Institute of Electrical and Electronics Engineers (IEEE) in collaboration with the American National Standards Institute (ANSI) was adopted by the International Organization for Standardization (ISO) in 1998, but it still remains an integral part of the family of IEEE 802 standards for local and metropolitan networks.
LLC is a software component that provides a uniform interface to the user of the data link service, usually the network layer. LLC may offer three types of services:
- Unacknowledged connectionless mode services (mandatory)
- Connection mode services (optional)
- Acknowledged connectionless mode services (optional)
Conversely, the LLC uses the services of the Media Access Control (MAC), which is dependent on the specific transmission medium (Ethernet, Token Ring, FDDI, 802.11, etc.). Using LLC is compulsory for all IEEE 802 networks with the exception of Ethernet. It is also used in Fiber Distributed Data Interface (FDDI) which is not part of the IEEE 802 family.
The IEEE 802.2 sublayer adds some control information to the message created by the upper layer and passed to the LLC for transmission to another node on the same data link. The resulting packet is generally referred to as LLC Protocol Data Unit (PDU) and the additional information added by the LLC sublayer is the LLC HEADER. The LLC Header consist of DSAP (Destination Service Access Point), SSAP (Source Service Access Point) and the Control field.
The two 8-bit fields DSAP and SSAP allow to multiplex various upper layer protocols above LLC. However, many protocols use the Subnetwork Access Protocol (SNAP) extension which allows using of EtherType values to specify the protocol being transported atop IEEE 802.2. It also allows vendors to define their own protocol value spaces.
The 8 or 16 bit HDLC-style Control field serves to distinguish communication mode, to specify a specific operation and to facilitate connection control and flow control (in connection mode) or acknowledgements (in acknowledged connectionless mode).
IEEE 802.2 provides two connectionless and one connection-oriented operational modes:
- Type 1 is an unacknowledged connectionless mode for a datagram service. It allows for sending frames
The use of multicasts and broadcasts reduce network traffic when the same information needs to be propagated to all stations of the network. However the Type 1 service provides no guarantees regarding the order of the received frames compared to the order in which they have been sent; the sender does not even get an acknowledgment that the frames have been received.
- Type 2 is a connection-oriented operational mode. Sequence numbering ensures that the frames received are guaranteed to be in the order they have been sent, and no frames are lost.
- Type 3 is an acknowledged connectionless service. It supports point-to-point communication only .
Each device conforming the IEEE 802.2 standard must support service type 1. Each network node is assigned an LLC Class according to which service types it supports:
|Supported Service Types|
Any 802.2 LLC PDU has the following format:
|802.2 LLC Header||Information|
|DSAP address||SSAP address||Control|
|8 bits||8 bits||8 or 16 bits||multiple of 8 bits|
When Subnetwork Access Protocol (SNAP) extension is used, it is located at the start of the Information field:
|802.2 LLC Header||SNAP extension||Upper layer data|
|8 bits||8 bits||8 or 16 bits||24 bits||16 bits||multiple of 8 bits|
The 802.2 header includes two eight-bit address fields, called service access points (SAP) or collectively LSAP in the OSI terminology:
- SSAP (Source SAP) is an 8-bit long field that represents the logical address of the network layer entity that has created the message.
- DSAP (Destination SAP) is an 8-bit long field that represents the logical addresses of the network layer entity intended to receive the message.
The DSAP and SSAP can have the following values:
|2||02||Individual LLC Sublayer Mgt|
|3||03||Group LLC Sublayer Mgt|
|4||04||SNA Path Control (individual)|
|5||05||SNA Path Control (group)|
|6||06||Reserved for DoD IP|
|66||42||IEEE 802.1 Bridge Spanning Tree Protocol|
|126||7E||ISO 8208 (X.25 over IEEE 802.2 Type LLC)|
|128||80||Xerox Network Systems (XNS)|
|142||8E||ProWay-LAN (IEC 955)|
|152||98||ARPANET Address Resolution Protocol (ARP)|
|166||A6||RDE (route determination entity)|
|170||AA||SNAP Extension Used|
|244||F4||IBM LAN Management (individual)|
|245||F5||IBM LAN Management (group)|
|248||F8||IBM Remote Program Load (RPL)|
|254||FE||OSI protocols ISO CLNS IS 8473|
|255||FF||Global DSAP (cannot be used for SSAP)|
Despite the SAP fields being 8-bit long, some bits have specific significance, so that there is room for only 64 distinguished SAP numbers, which are globally assigned by the IEEE to uniquely identify well established international standards.
The low-order bit of the DSAP indicates whether it contains an individual or a group address.
- If the low-order bit is 0, the remaining 7 bits of the DSAP specify an individual address, which refers to a single local service access point (LSAP) to which the packet should be delivered.
- If the low-order bit is 1, the remaining 7 bits of the DSAP specify a group address, which refers to a group of LSAPs to which the packet should be delivered.
The low-order bit of the SSAP indicates whether the packet is a command or response packet;
- if it's 0, the packet is a command packet, and
- if it's 1, the packet is a response packet.
The remaining 7 bits of the SSAP specify the LSAP from which the packet was transmitted.
The protocols or families of protocols which have assigned one or more SAPs may operate directly on top of 802.2 LLC. Other protocols may use the Subnetwork Access Protocol (SNAP) with IEEE 802.2 which is indicated by the hexadecimal value 0xAA (or 0xAB, if the low-order bit of the field is set) in SSAP and DSAP. The SNAP extension allows using EtherType values or private protocol ID spaces in all IEEE 802 networks. It can be used both in datagram and in connection-oriented network services.
Ethernet (IEEE 802.3) networks are an exception; the IEEE 802.3x-1997 standard explicitly allowed using of the Ethernet II framing, where the 16-bit field after the MAC addresses does not carry the length of the frame followed by the IEEE 802.2 LLC header, but the EtherType value followed by the upper layer data. With this framing only datagram services are supported on the data link layer.
Internet Protocol and 802.2 LLC
Although IPv4 has assigned SAP value of 6 and there is even a SAP value of 98 hex for ARP, IP traffic is almost never encapsulated in IEEE 802.2 LLC frames without SNAP. Instead, the Internet standard RFC 1042 is usually used for encapsulating IP version 4 traffic in IEEE 802.2 frames with LLC/SNAP headers in FDDI and IEEE 802 networks. In Ethernet/IEEE 802.3 networks using Ethernet II framing with EtherType 800 hex for IP and 806 hex for ARP is more common.
It is possible to use diverse framings in a single network. It is possible to do it even for the same upper layer protocol, but in such a case the nodes using unlike framings cannot directly communicate. IPX protocol used in the Novell NetWare networks allows an additional Ethernet frame format supporting 4 frame types in Ethernet and 2 frame types in IEEE 802 networks and FDDI.
- Unnumbered format PDUs, or U-format PDUs, with an 8-bit control field, which are intended for connectionless applications;
- Information transfer format PDUs, or I-format PDUs, with a 16-bit control and sequence numbering field, which are intended to be used in connection-oriented applications;
- Supervisory format PDUs, or S-format PDUs, with a 16-bit control field, which are intended to be used for supervisory functions at the LLC (Logical Link Control) layer.
To carry data in the most-often used unacknowledged connectionless mode the U-format is used. It is identified by the value '11' in lower two bits of the single-byte control field.
- IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements. Part 2: Logical Link Control. New York: The Institute of Electrical and Electronics Engineers. May 7, 2008. ISBN 1-55937-959-6.
- Miller, Philip; Cummins, Michael (2000). LAN Technologies Explained. Digital Press. p. 506. ISBN 1-55558234-6.
- The BACnet Standard—Standard 135-2012, Ashrae.
- Final Text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service, RFC (994), IETF.
- LKML, 2011-07-27.
- 802.2 (online ed.), IEEE.