The IEEE standard adds this sublayer which adds the standard 8-bit DSAP (Destination Service Access Point) and SSAP (Source Service Access Point) labels to a given packet regardless of network type. There is also an 8 or 16 bit control field for use in auxiliary functions such as flow control. There is room for 64 globally assigned SAP numbers, and the IEEE does not assign them lightly. IP does not have an assigned SAP number, because only “international standards” could be given globally assigned SAP numbers. Protocols which are not international standards can use a SAP number from the locally administered SAP number space. The Subnetwork Access Protocol (SNAP) allows EtherType values to be used to specify the protocol being transported atop IEEE 802.2, and also allows vendors to define their own protocol value spaces.
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.
802.2 defines a special header that includes a SNAP (subnetwork access protocol) header. Some protocols, particularly those designed for the OSI networking stack, operate directly on top of 802.2 LLC, which provides both datagram and connection-oriented network services. This 802.2 header is currently embedded in modern 802.3 frames (Ethernet II frames, aka. DIX frames).
The LLC header includes two additional eight-bit address fields, called service access points or SAPs in OSI terminology; when both source and destination SAP are set to the value 0xAA, the SNAP service is requested. The SNAP header allows EtherType values to be used with all IEEE 802 protocols, as well as supporting private protocol ID spaces. In IEEE 802.3x-1997, the IEEE Ethernet standard was changed to explicitly allow the use of the 16-bit field after the MAC addresses to be used as a length field or a type field.
Novell NetWare used this frame type by default until the mid nineties, and since Netware was very widespread back then, while IP was not, at some point in time most of the world's Ethernet traffic ran over "raw" 802.3 carrying IPX. Since Netware 4.10 Netware now defaults to IEEE 802.2 with LLC (Netware Frame Type Ethernet_802.2) when using IPX. (See "Ethernet Framing" in References for details)
The 802.2 variants of Ethernet are not in widespread use on common networks currently, with the exception of large corporate Netware installations that have not yet migrated to Netware over IP. In the past, many corporate networks supported 802.2 Ethernet to support transparent translating bridges between Ethernet and IEEE 802.5 Token Ring or FDDI networks.
There exists an Internet standard for encapsulating IP version 4 traffic in IEEE 802.2 frames with LLC/SNAP headers. It is almost never implemented on Ethernet (although it is used on FDDI and on token ring, IEEE 802.11, and other IEEE 802 networks).
IP traffic can not be encapsulated in IEEE 802.2 LLC frames without SNAP because, although there is an LLC protocol type for IP, there is no LLC protocol type for ARP. IP Version 6 can also be transmitted over Ethernet using IEEE 802.2 with LLC/SNAP, but, again, that's almost never used (although LLC/SNAP encapsulation of IPv6 is used on IEEE 802 networks).
Of these three formats, only the U-format is commonly used. The format of a PDU frame is identified by the lower two bits of the first byte of the control field. IEEE 802.2 was conceptually derived from HDLC, which explains these aspects of its design.