Worcester Polytechnic Institute
EE535 Homework Assignment # 3:
SNAP - Sub-Network Access Protocol
13 March 1996
To Table of Contents
Abstract:
In class we discussed the fact that the use of the field in the original
Ethernet frame which was used to store TYPE information was changed to store a
data size value instead. This change would have caused havoc on the Internet
had it not been for a protocol that was proposed to deal with it. This protocol
was called "SNAP" (Sub-Network Access Protocol) and is in wide use
today. The purpose of this project is to locate information (RFCs (Request For
Comment), standards, etc.) that define SNAP and interpret them. It will also be
shown how the SNAP permits operation of both Ethernet and IEEE 802.3 frames on
the same network.
Table of Contents:
List of Figures:
- Figure 1: Comparison of Ethernet & IEEE 802.3
Frames
- Figure 2: Comparison of LLC PDU and SNAP PDU
- Figure 3: Ethernet and IEEE 802.3 Coexistence
- Figure 4: Ethernet and IEEE 802.3 Translation
Introduction:
During the early to mid-1980s, the IEEE (Institute of Electrical and
Electronics Engineers, Inc.) set forth to define a family of standards for Local
and Metropolitan Area Networks (LANs & MANs) that dealt with the Physical
and Data Link Layers as defined by the International Organization for
Standardization's Open System Interconnection Reference Model (ISO/OSI). These
standards were part of the IEEE 802 project and were initially offered in 1985.
There where initially three Physical Layer standards (802.3 - CSMA/CD, 802.4 -
Token Bus and 802.5 - Token Ring) and one Logical Link Control standard (802.2)
defined. Since then, additional IEEE 802 standards have been defined. [1,6]
The IEEE 802.3 (CSMA/CD - Carrier Sence Multiple Access
with Collision Detect) standard was based on the Ethernet version 2.0 (aka "DIX"
after Digital, Intel and Xerox) standard [6,9]. Although
the names "IEEE 802.3" and "Ethernet" are often used
synonomously, there is a very important difference that makes them incompatible
at the Data Link Layer. The difference is that the field used to store the
Network Layer protocol type information in the Ethernet header is used to store
data length in the IEEE 802.3 header, as shown in Figure 1 below:
Figure 1: Comparison of Ethernet & IEEE 802.3 Frames.
Source:
Class Notes.
The reason that the Ethernet frame did not use a length field was because
the upper level vendor protocols (XNS, IPX, DECnet, IP) all had their own length
fields. The reason why the IEEE changed this, putting the length field directly
in the frame header was to eliminate the dependence on the upper level protocols
to distinguish the end of the data, hence providing better layer separation [9]. This incompatibility brought on concern when considering
issues such as backwards compatability, the evolution of protocols and the
increasing need for internetworking (via the Internet, etc.). Ethernet and IEEE
802.3 networks would need a means for communicating and/or potentially
coextisting on the same network regardless of the upper layer protocols used.
Hence, a problem was born: What can be done to permit the coexistence of
Ethernet and IEEE 802.3 frames on the same network and to allow communication
between Ethernet and IEEE 802 (not just 802.3) stations on different networks?
Also, how can Ethernet and IEEE 802.3 stations that are located on the
same network communcate?
Return to Table of Contents
SNAP:
In order for entities to be able to communicate at a given layer, a mutually
agreed upon protocol needs to be used. Any entity that does not support this
protocol thereby cannot communicate. With that note, it is desirable to allow
multiple protocols to be used, allowing a station to communicate using more than
one mutually agreed upon protocol. This would allow new protocols to be
introduced, while still allowing the existing protocols to operate
simultaneously. In order to support multiple protocols, a way to distinguish
them is needed so that the correct protocol can be invoked in order to process
the data passed up by the layer below. [1]
The SNAP (Sub-Network Access Protocol) was created as an effort by the IEEE
to support the coexistence of multiple standard (published, controlled by
standards body), public (published, controlled by private organization) and
private (privately used and controlled) Network Layer protocols within a single
802 station more adaquately than the original LLC (Logical Link Control) method.
The backwards compatability with Ethernet was then accomplished using the SNAP.
The LSAP (Link Service Access Point) space of the original 802.2 LLC header was
16 bits (8 bits each for source and destination SAP). Since each standard
Network Layer protocol was given a unique SAP (so that a station's Network Layer
could distinguish between multiple protocols) and since each SAP was limited to
8 bits, this lack of SAP space would be sure to cause problems with protocol
evolution (standard, public or private) and problems with the existing Ethernet
standard, which used 16-bit protocol IDs (called EtherTypes) [7,8].
So the SNAP was introduced in order to expand the 8-bit SAP space to a 40-bit
protocol ID, and hence expand the number of public and private Network Layer
protocols that could be supported [1]. In addition to
supporting more Network Layer protocols, a convention that would permit the
coexistence of Ethernet and IEEE 802.3 frames on the same network and a means
for easy translation between Ethernet and IEEE 802 stations were created.
The SNAP is a 40-bit (5 byte) extension to the original
802.2 LLC header. The SNAP uses the first 5 bytes in the LLC PDU (Protocol Data
Unit) data field as the SNAP Protocol ID, as shown in Figure 2 below:
Figure 2: Comparison of LLC PDU and SNAP PDU.
Sources:
[1,2,7].
The first 3 bytes of the SNAP Protocol ID are used to store a vendor ID,
that is, which organization the Network Layer protocol came from. This vendor
ID is actually the OUI (Organizationally Unique Identifier); the same ID used
for the first 24 bits of the 48-bit MAC (or "Ethernet") addresses
associated with NICs (Network Interface Cards). The last 2 bytes of the SNAP
Protocol ID are used to represent the Protocol Type within each vendor, that is,
which protocol is actually being used. [1]
The Network Layer protocol type for every frame can be completely determined
by the information contained in the SNAP Protocol ID. Since the SNAP Protocol
ID is part of the LLC PDU's data field, the LLC sub-layer does not know the
difference between a SNAP encapsulated PDU and a normal LLC PDU. Therefore, a
convention was needed to allow the Network Layer protocols to determine that the
data being passed is SNAP encapsulated. This was accomplished by using a
reserved LSAP value of 170 (0xAA), called the "SNAP SAP," as the
service access point for passing a SNAP encapsulated LLC PDU (SNAP PDU) to the
Network Layer. That is, both the source and destination SAPs of the LLC header
were set to 170, signifying a SNAP encapsulated LLC PDU. Based on the
information contained in the 5 byte SNAP Protocol ID (vendor ID (OUI) and
protocol type), the correct Network Layer protocol can be invoked to process the
data or SDU (Service Data Unit) sent from a peer (different station) Network
Layer via the underlying layers. [1]
Return to Table of Contents
Ethernet and IEEE 802.3:
In Coexistence:
Since many Ethernet (DIX) networks were in operation prior to the release of
the IEEE 802 standards, there was (and still is) a need for both frame formats
to be allowed to coexist on the same network. Recall that the main difference
between an Ethernet frame and an IEEE 802.3 frame is that the field used for
protocol type in Ethernet (EtherType value) is used for data length in IEEE
802.3 (Figure 1 or Figure 3 below). With that note, a
simple solution is to insure that Ethernet frames do not use any EtherType
values that IEEE 802.3 frames would potentially use for data length values, and
vice-versa. This is made possible by insuring that all EtherType numbers are
greater than 1500, which is the maximum data length of an IEEE 802.3
frame. Similarly, since the maximum data length of an IEEE 802.3 frame is 1500,
there would never be a case where an 802.3 frame would have a length value
greater than 1500. As a result, a station using the IEEE 802.3 standard would
discard any frames with a length field greater than 1500 (representing an
Ethernet frame). Similarly, a station using the Ethernet standard would discard
any frames with a type field of less than or equal to 1500 (representing an IEEE
802.3 frame). Figure 3 below is a modification of
Figure 1 showing the allowed type and length field values
thus mentioned: [6,8]
Figure 3: Ethernet and IEEE 802.3 Coexistence.
Sources:
[6,7,8,9]
Recall that although the 8-byte preamble of Ethernet frame was replaced by a
7-byte preamble field followed by a 1-byte start-of-frame delimeter in IEEE
802.3, the bit patterns are identical [Class Notes]. Hence, IEEE 802.3 and
Ethernet frames can coexist on the same network.
Internetworking:
As shown above, Ethernet and IEEE 802.3 frames can coexist on the
same network. Another problem arises, however, when considering the need for
Ethernet and IEEE 802 (not just 802.3) stations to communicate with each
other. This problem can actually be split into two separate cases: (1) How do
Ethernet and IEEE 802.3 stations on the same network communicate?, and (2) How
do Ethernet and IEEE 802 (in general) stations communicate across networks?
This paper shows how Ethernet and IEEE 802.3 stations (in particular)
communicate as stated in case (1) and (2). For more information on how other
IEEE 802 networks (802.4, 802.5, etc.) can internetwork with Ethernet networks,
refer to Other related sources... below the
list of References. Briefly stated, regardless of the
particular IEEE 802 format used, the SNAP is used to store the same EtherType
values used by Ethernet frames. Further action (via translation bridge, router
or gateway) is then taken to translate the frames between Ethernet and the
particular IEEE 802 formats. [1,7,8]
Case 1:
In the case where IEEE 802.3 and Ethernet stations are located on the same
network, a translation bridge or router needs to be used to translate the frame
formats. In other words, if an Ethernet station were to send a frame intended
for an IEEE 802.3 station, the translation bridge or router would have to
actively translate the Ethernet frame into IEEE 802.3 format using the SNAP. In
doing this, the source and destination addresses of the Ethernet frame would be
copied to the 802.3 MAC header. The SSAP and DSAP fields of the IEEE 802.2 LLC
header would be set to the SNAP SAP of 170 (signifying SNAP encapsulation). The
control field in the SNAP PDU would be set to 3 to indicate LLC Type 1
Unnumbered Information format (connectionless service) [7].
The OUI field of the SNAP Protocol ID would be set to zero, which signifies a
mapped Ethernet frame [3,7]. The value stored in the type
field of the Ethernet frame would be move into the protocol type field of the
SNAP Protocol ID. The length field would be calculated and stored in the length
field of the new 802.3 frame. The data from the Ethernet frame is copied to the
data field of the SNAP PDU (See Figure 4 below). Finally,
the new 802.3 frame would be sent back to the physical layer, and the
destination 802.3 station would accept it. A similar process is performed when
translating IEEE 802.3 frames to Ethernet. Figure 4 below shows the translation
of an Ethernet frame to an IEEE 802.3 frame:
Figure 4: Ethernet and IEEE 802.3 Translation.
Sources:
[1,2,3,4,6,7,8,9]
NOTICE: The maximum data size that can be placed in the data field of the
SNAP PDU is now 1492 bytes, not 1500. This is because the LLC & SNAP
headers take up 8 bytes, resulting in a maximum data length of (1500 - 8) = 1492
bytes. Some consideration needs to be given to this fact when transmitting, say
IP packets to and from the same and/or different networks. For more information
regarding this point, refer to
RFC-1042 - "A
Standard for the Transmission of IP Datagrams Over IEEE 802 Networks",
listed in the References section.
Case 2:
Using the method stated above (Case 1), in order to
communicate across the Internet between Ethernet and IEEE 802 stations, the
EtherType value for the IP (Internet Protocol), namely 2048 (0x0800) is used for
both the Ethernet type field and the SNAP Protocol ID's protocol type field.
The IP packet would then be contained in either the data field of the Ethernet
frame or the data field of the SNAP PDU. Similarly, when using ARP (Address
Resolution Protocol), an EtherType number of 2054 (0x806) is used. The use of
other protocols would be accomplished similarly, using their corresponding
EtherType value. A list of EtherType numbers is contained in
RFC-1340 - "Assigned
Numbers", listed in the References section.
Hence it has been shown that Ethernet and IEEE 802.3 Networks on the same
network and on different networks can communicate.
Return to Table of Contents
Conclusion:
When the IEEE first created its 802 standards, their intent was to provide
an international family of local and metropolotan area networking standards. In
doing this, they somewhat overlooked the fact the the existing Ethernet standard
was in wide use and would continued to be for many years to come. They also
underestimated the number of different upper layer protocol families that would
need to be supported in the future, and hence the size of the header fields
needed to accomidate them.
When setting out to correct these problems, rather than treating them
separately, the IEEE 802 group derived a solution that corrected both at once,
namely the SNAP. The SNAP allows the use of the protocol type numbers defined
for Ethernet (EtherType numbers) to be used in IEEE 802 frames. This provides
easy translation between Ethernet and IEEE 802 frames by a translation bridge,
router or gateway. Also, by extending the protocol type space from the 8-bit
LSAP values of the original 802.2 header to a 16-bit field (as in Ethernet),
many more upper layer protocols could be supported, plus all the existing
EtherType numbers could still be used. Hence, the SNAP was paramount in
addressing the conflict between Ethernet and IEEE 802.3 frame formats, the lack
of protocol ID space of the original 802.2 header, and making possible the
communication between Ethernet and IEEE 802 networks.
Return to Table of Contents
References:
Return to Table of Contents
If there is anything is this document that is unclear,
half-right, or just wrong, please bring it to my attention.
Thank you.
Send E-mail to: 
gifford@ee.wpi.edu
HoTMetaL editor for Windows to
create this document.
Return to the WPI EE535 Telecommunications and Transmission Technologies Course Homepage