Subnetwork Access Protocol: Difference between revisions

Revision as of 14:32, 25 February 2021

Latest revision as of 11:02, 31 October 2024

(23 intermediate revisions by 17 users not shown)

Line 1:

{{refimprove|date=January 2018}}

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 8eight-bit 802.2 [[Service Access Point]] (SAP) fields. SNAP supports identifying protocols by [[EtherType]] 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 layer|physical network layer]]s, as well as with non-IEEE 802 physical network layers such as [[FDDI]] that use 802.2 LLC.

The SNAP and [[IEEE 802.2#LSAP_ValuesLSAP values|LSAP]] fields are [[Encapsulation (networking)|added]] to the [[Network packet|packets]] at the transmitting node in order to allow the receiving node to [[demultiplex|pass]] each received [[Frame (networking)|frame]] to an appropriate [[device driver]] which understands the given [[Communications protocol|protocol]].

==Background==

The Open Systems Interconnect ([[OSI) model]] uses a [[Service Access Point]] (SAP) to define the communication between layers (like Network, Transport, Session, and the other layers of the Sevenseven-Layeredlayer Modelmodel), that is to identify which protocol should process an incoming message. Within a given layer, programs can exchange data by a mutually agreed -upon protocol mechanism. A pair of programs that do not support a common protocol cannot communicate with each other. Thus for multiple protocols to coexist within a layer, it is necessary to determine which protocol is to be invoked to process a service data unit delivered by the lower layer.<br />

The most common reference to SAP, including a Source Service Access Point (SSAP) and a Destination Service Access Point (DSAP) refers to the boundary between the Data Link Layer and the Network Layer. It is common to think of SAP only in terms of its use at Layer 2, specifically in its [[Logical Link Control]] (LLC) sub-layer as defined in the IEEE 802.2 standards. Link Service Access Point (LSAP) includes both Destination Service Access Point (DSAP) and Source Service Access Point (SSAP). It enables a MAC station to communicate with upper layers via different protocols.<br />

Standard Network layer protocols have been assigned reserved LLC addresses, as recorded in ISO/IEC TR 11802-1. One half of the LLC address space is reserved for such assignment. Other protocols are accommodated in two ways. One way is by local assignment of LSAPs, for which the other half of the LLC address space is available.

The second way is through theto use of a particular reserved LLC address value that has been assigned for use in conjunction with the Sub-network Access Protocol (SNAP) which is called the SNAP address. The SNAP address identifies, at 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]] [[Logical Link Control|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 layer|physical network layer]]s, 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.<ref>{{citation |url=http://standards.ieee.org/about/get/802/802.html |archive-url=https://web.archive.org/web/20101129155708/http://standards.ieee.org/about/get/802/802.html |url-status=dead |archive-date=November 29, 2010 |title=IEEE 802 Overview and Architecture |publisher=[[IEEE]] |accessdate=2014-08-02}}</ref> 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:

{| class="wikitable"

Line 33:

|}

The SNAP header consists of a 3-octet [[IEEE]] [[organizationally unique identifier]] (OUI) followed by a 2-octet protocol ID. If the OUI is hexadecimal 000000zero, the protocol ID is the Ethernetregistered type ([[EtherType]]) field value for the protocol running on top of SNAP;. ifIf 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 [[IEEE 802.2#Control_Field|Unnumbered Information]] 802.2 [[protocol data unit]]s (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.

Line 39:

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 that was made during the layout of the LLC header. At the time that the LLC header was being designed, it was thought that a single octet (256 possible values) in the header would be enough to specify all the protocol values that vendors would want to register. As the values began to be reserved, it was discovered that the LLC header would soon run out of open values. The hexadecimal AA and AB values were reserved, and an additional header—the SNAP header—was developed; it can support all EtherType values, as well asand multiple spaces of private protocol values.

As per [[IETF]] RFC 1042, IP datagrams and ARP datagrams are transmitted over IEEE 802 networks using LLC and SNAP headers,{{Ref RFC|1042}} except on Ethernet/IEEE 802.3, where they are transmitted with Ethernet II headers, as per.{{Ref RFC |894.}}

==References==