each MAC SAP, a single LSAP. Thus, each protocol using SNAP must employ a protocol identifier. Thus, the Subnetwork Access Protocol (SNAP) is a mechanism for multiplexing, on networks using IEEE 802.2 LLC, more protocols than can be distinguished by the 8-bit 802.2 Service Access Point (SAP) fields. SNAP supports identifying protocols by Ethernet type field values; it also supports vendor-private protocol identifier spaces. It is used with IEEE 802.3, IEEE 802.4, IEEE 802.5, IEEE 802.11 and other IEEE 802 physical network layers, as well as with non-IEEE 802 physical network layers such as FDDI that use 802.2 LLC. Use The SNAP is an extension of the 802.2 LLC specified in the IEEE 802 Overview and Architecture document. The 5-octet SNAP header follows the 802.2 LLC header if the destination SAP (DSAP) and the source SAP (SSAP) contain hexadecimal values of AA or AB: The SNAP header consists of a 3-octet IEEE organizationally unique identifier (OUI) followed by a 2-octet protocol ID. If the OUI is zero, the protocol ID is the registered EtherType value for the protocol running on top of SNAP. If the OUI is an OUI for a particular organization, the protocol ID is a value assigned by that organization to the protocol running on top of SNAP. SNAP is usually used with Unnumbered Information 802.2 protocol data units (PDUs), with a control field value of 3, and the LSAP values are usually hexadecimal AA, so the 802.2 LLC header for a SNAP packet is usually AA AA 03; however, SNAP can be used with other PDU types as well. On Ethernet, the 8 octets occupied by the LLC and SNAP headers reduce the size of the available payload for protocols such as the Internet Protocol to 1492 bytes, compared to the use of the Ethernet II framing; therefore, for protocols that have EtherType values, packets are usually transmitted with Ethernet II headers rather than with LLC and SNAP headers. On other network types, the LLC and SNAP headers are required in order to multiplex different protocols on the link layer, as the MAC layer doesn't itself have an EtherType field, so there's no alternative framing that would have a larger available payload. One might ask, "why is a separate sub-network header necessary?". The answer is that it was to augment a decision made during the layout of the LLC header. At the time that the LLC