Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 13961-2: Logical Link Control (LLC) Protocol in Local and Metropolitan Area Networks – Scope and Technical Requirements
A comprehensive technical overview of the CAN/CSA ISO/IEC 13961-02 standard covering LLC sublayer services, protocol specifications, and compliance guidelines
1. Scope of ISO/IEC 13961-2
ISO/IEC 13961-2 is an international standard that defines the Logical Link Control (LLC) sublayer, positioned at the upper part of the data link layer in the OSI reference model. This standard is also adopted by the Canadian Standards Association as CAN/CSA ISO/IEC 13961-02 and is technically identical to IEEE 802.2. It specifies the functions, services, and protocol for the LLC sublayer to facilitate data exchange between network layer entities across local (LAN) and metropolitan area networks (MAN).
The LLC sublayer acts as a common interface between the Medium Access Control (MAC) sublayer and the network layer, independent of the underlying MAC topology (e.g., Ethernet, Token Ring, or FDDI). ISO/IEC 13961-2 defines three types of LLC services: Connectionless (Type 1), Connection-Oriented (Type 2), and Acknowledged Connectionless (Type 3). It also provides for the Subnetwork Access Protocol (SNAP) extension, enabling the identification of higher-layer protocols through a protocol discriminator.
This standard is essential for ensuring interoperability among devices from different vendors in a heterogeneous LAN environment. It supports the transport of protocol data units (PDUs) with varying priorities and reliability levels, making it a critical component for time-sensitive and mission-critical applications.
Tip: ISO/IEC 13961-2 is functionally identical to IEEE 802.2-1998. When implementing LLC services, always refer to the latest edition (e.g., ISO/IEC 13961-2:2005) for the most current definitions of Type 3 services and SNAP extensions.
2. Technical Requirements and Key Specifications
2.1 LLC Service Access Points and Addressing
The LLC sublayer uses Service Access Points (SAPs) to identify the network layer entity above it. Each data link station can have multiple LSAPs, each assigned a unique address. The standard defines LSAP addresses, including the globally administered individual and group addresses, as well as the 0xAA SNAP extension address used for protocol multiplexing.
2.2 LLC Protocol Data Unit (LPDU) Format
An LPDU consists of a header and an information field. The header contains the Destination and Source SAP addresses (each 1 byte) and a control field (1 or 2 bytes, depending on the type of operation). The control field encodes the format (information, supervisory, or unnumbered) and contains sequence numbers and commands/responses. For SNAP, the header is extended by a 2-byte Organization Code and a 2-byte Protocol Identifier.
| LLC Type | Service Type | Control Field Length | Key Features |
|---|---|---|---|
| Type 1 | Connectionless (Unacknowledged) | 1 byte (UI frame) | No flow control, no acknowledgment; best-effort delivery. |
| Type 2 | Connection-Oriented | 2 bytes (I, S frames) | Sequencing, flow control, error recovery; reliable delivery. |
| Type 3 | Acknowledged Connectionless | 1 byte (AC frames) | Limited acknowledgment without connection; suitable for real-time control. |
2.3 Operation of LLC Types
Type 1 (Unacknowledged Connectionless): The most widely used LLC service. It provides a simple datagram service where PDUs are sent without acknowledgment. It is used by network layer protocols such as IP (over Ethernet’s SNAP encapsulation). The control field carries the Unnumbered Information (UI) command.
Type 2 (Connection-Oriented): Establishes a logical data link connection between two LSAPs before data exchange. It uses flow control and windowing mechanisms, similar to HDLC. The control field formats are Information (I) frames for carrying data, Supervisory (S) frames for flow control, and Unnumbered (U) frames for connection management. Type 2 is used in environments requiring guaranteed delivery and ordered data.
Type 3 (Acknowledged Connectionless): Introduced to satisfy the needs of time-critical applications such as industrial automation. It provides an acknowledgment per PDU without maintaining a connection. It uses Acknowledged Connectionless (AC) frames. Each command requires a response, ensuring simple reliability.
Warning: Mixing Type 1 and Type 2 LLCSAPs on the same station requires careful buffer management, as Type 2 can consume significant resources with large windows. Ensure that the implementation supports both types concurrently if required.
2.4 SNAP Extension
The Subnetwork Access Protocol (SNAP) is an extension defined in ISO/IEC 13961-2 that allows the identification of the network layer protocol type when using a standard LSAP address (0xAA). It appends a 5-byte header containing a 3-byte Organization Code and a 2-byte Protocol Identifier (EtherType). This enables any protocol stack to be encapsulated over IEEE 802 networks.
3. Implementation Highlights
Implementing LLC services according to ISO/IEC 13961-2 requires careful attention to the state machines for Type 2 connections, time-out values, and buffer allocation strategies. Below are key implementation considerations:
- Selecting the appropriate LLC Type: Most modern LAN deployments rely on Type 1 with SNAP for TCP/IP. Type 2 is rarely used due to the prevalence of TCP at the transport layer. Type 3 is relevant for industrial Ethernet protocols (e.g., PROFINET RT/IRT).
- Address management: LSAP addresses must be configured consistently. The use of well-known LSAPs (e.g., 0xFE for SNAP) is standardized.
- Interworking with MAC: The LLC sublayer relies on the MAC sublayer to provide data transfer, addressing, and error detection. Ensure that the MAC (e.g., IEEE 802.3) is correctly configured to support the required LLC frame length.
- Performance optimization: For Type 2, window size and time-out values should be tuned according to the network delay and error rate. For Type 1, avoid excessive reassembly buffer sizes to prevent memory exhaustion.
- Conformance testing: Use approved test suites (e.g., ISO/IEC 9646-based) to verify LLC behavior. Pay special attention to the state transitions of Type 2 connections and the response to error conditions.
Good Practice: When introducing new protocol layers over IEEE 802 networks, always register the protocol ID with the appropriate authority and ensure the SNAP header is correctly formatted. Refer to the IEEE Registration Authority for EtherType assignments.
4. Compliance Notes
Compliance with ISO/IEC 13961-2 is mandatory for conformance to many IEEE 802-based networking standards, including Ethernet (IEEE 802.3) and Wi-Fi (IEEE 802.11). The standard is adopted globally, including the Canadian adoption CAN/CSA ISO/IEC 13961-02. Key compliance points are:
- Mandatory elements: Every LLC implementation must support at least Type 1 (connectionless) service, as it is required for IP-based communication. Support for Type 2 and Type 3 is optional but must adhere strictly to the defined protocol state machines and timers.
- Interoperability testing: Devices from different vendors claiming LLC conformance should pass basic interoperability tests (e.g., exchanging Type 1 UI frames with correct LSAP addressing and responding to Type 2 connection requests).
- Version awareness: The current edition (as of 2026) is ISO/IEC 13961-2:2005, which includes clarifications for SNAP and Type 3 services. Older editions (e.g., 1998) are still referenced in many systems. Ensure that the implementation notes the year of the standard.
- National variances: The Canadian adoption includes minor editorial differences but no technical deviations. In other countries, adoptions may require additional testing marks (e.g., UL, CSA).
Important: Non-compliant LLC implementations may cause protocol misidentification (due to incorrect SNAP headers) or cause data link layer errors that propagate to the network layer. Always validate LLC control field parsing and LSAP address handling with thorough unit tests.
Frequently Asked Questions
Q: What is the relationship between ISO/IEC 13961-2 and IEEE 802.2?
A: They are technically identical. ISO/IEC 13961-2 is the international adoption of the IEEE 802.2 standard for Logical Link Control. The Canadian adoption (CAN/CSA ISO/IEC 13961-02) also aligns with this. The IEEE 802.2 standard is maintained by the IEEE 802 LAN/MAN Standards Committee, while ISO/IEC JTC 1/SC 6 maintains the ISO version.
A: They are technically identical. ISO/IEC 13961-2 is the international adoption of the IEEE 802.2 standard for Logical Link Control. The Canadian adoption (CAN/CSA ISO/IEC 13961-02) also aligns with this. The IEEE 802.2 standard is maintained by the IEEE 802 LAN/MAN Standards Committee, while ISO/IEC JTC 1/SC 6 maintains the ISO version.
Q: Do I still need to implement Type 2 LLC for modern networks?
A: Generally, no. Most modern LAN protocols (IP, IPv6) run over Type 1 LLC with SNAP. Type 2 LLC is rarely used today because reliable delivery is handled at the transport layer (TCP). However, Type 2 may still appear in legacy systems (e.g., IBM Token Ring networks). Some industrial protocols use Type 3 for deterministic, acknowledged unicast services.
A: Generally, no. Most modern LAN protocols (IP, IPv6) run over Type 1 LLC with SNAP. Type 2 LLC is rarely used today because reliable delivery is handled at the transport layer (TCP). However, Type 2 may still appear in legacy systems (e.g., IBM Token Ring networks). Some industrial protocols use Type 3 for deterministic, acknowledged unicast services.
Q: How does SNAP work with LLC?
A: SNAP uses the LSAP address 0xAA in both the Destination and Source SAP fields. The LLC header is followed by a 5-byte SNAP header: a 3-byte organization code (typically 0x000000 for EtherType) and a 2-byte protocol identifier (e.g., 0x0800 for IP). This allows the network layer to demultiplex encapsulated protocols over IEEE 802 networks.
A: SNAP uses the LSAP address 0xAA in both the Destination and Source SAP fields. The LLC header is followed by a 5-byte SNAP header: a 3-byte organization code (typically 0x000000 for EtherType) and a 2-byte protocol identifier (e.g., 0x0800 for IP). This allows the network layer to demultiplex encapsulated protocols over IEEE 802 networks.
Q: Is CAN/CSA ISO/IEC 13961-02 still relevant in 2026?
A: Yes. Even though newer editions of IEEE 802.2 have been reaffirmed, the core specifications for LLC remain unchanged. The standard is still invoked by many IEEE 802 networking standards and is essential for backward compatibility. Its coexistence with modern Ethernet implementations (using Ethernet II framing) requires careful configuration in hybrid environments.
A: Yes. Even though newer editions of IEEE 802.2 have been reaffirmed, the core specifications for LLC remain unchanged. The standard is still invoked by many IEEE 802 networking standards and is essential for backward compatibility. Its coexistence with modern Ethernet implementations (using Ethernet II framing) requires careful configuration in hybrid environments.
Article prepared for technical documentation purposes. All standard references are current as of 2026. For official compliance, always consult the latest edition of CAN/CSA ISO/IEC 13961-02 from CSA Group or the corresponding ISO/IEC publication.