by Dave Fogle

Tutorial Index

Lesson 90: Ethernet Frame

Types
Getting the Picture on Frames.

For most network administrators, Ethernet frame types rate

little or no attention. If they think about them at all, it's usually
as a possible source of workstation problems-for example, a
user's net.cfg configured with the wrong frame type can
prevent the workstation from connecting to a server. Recently,
however, Novell has been pushing the topic into the
foreground. By changing the default Ethernet frame type from
802.3 to 802.2 for its currently shipping NetWare operating
systems (3.12 and 4.x), the company has forced administrators
of existing networks to at least consider migrating their users to
the newer frame type. The reasons behind Novell's change
center around a need to ensure compatibility of Novell's
IPX/SPX with future demands, such as increased security and
reliability. Also, the increasing diversity of many corporate
networks-which often have devices from several vendors
connected to the same network, using several different
protocols-prompted Novell to encourage its users to move
toward a more standardized frame type-one that readily
coexists with other frame types.

IF IT AIN'T BROKE, WHY FIX IT?

The 802.3 frame type (and the way Novell uses it) isn't really
such a bad thing. In fact, it may offer slight (though probably
negligible) advantages on NetWare-only networks due to its
slightly lower overhead per packet. Furthermore, because the
802.2 standard deals only with the Data-link layer, the newer
frame type uses an 802.3 packet as its Physical-layer skeleton
(or perhaps we should call it an exoskeleton, since the
Physical-layer header is added to the outside of the 802.2
frame). The problem is that Novell used the Physical-layer
802.3 frame type without a standard Data-link layer header
when it created its proprietary IPX/SPX packet structure-hence
the term 802.3 Raw.

1 of 5
In a single-vendor environment, this omission doesn't cause
any problems. But in a corporate network, where several
packet types may coexist, the lack of a clearly defined field
stating the frame's type can make the jobs of routers and
bridges more difficult and may result in lost packets. Keep in
mind that Ethernet packets don't arrive at a workstation with
neat labels above each field describing the contents; a router
or NIC can only examine the contents of predefined locations
to determine which protocol or frame type a packet uses. To
decode and route a packet that doesn't conform to standard
protocols, a router must be designed to specifically search for
the defining characteristics of the nonconforming packet.

Adopting a more standard Data-link layer protocol format gave

NetWare more flexibility in coexisting with other network
operating systems. But Novell's change of default frame type
wasn't a big surprise. NetWare has fully supported other
Ethernet frame types-Ethernet_802.2, Ethernet_II, and
Ethernet_SNAP-since version 3.x. NetWare 2.x was the last
version to require a complete relinking of the operating system
to enable support for other frame types.

For better insight into Novell's reasoning, let's examine the

structure of an 802.3 packet and see how it differs from the
other frame types used on Ethernet networks.

ETHERNET II

The precursor to the IEEE 802.3 frame type was the Ethernet II
packet. This frame type, originally developed by Digital, Intel,
and Xerox, relies on Ethernet's Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) access scheme (the same
as the 802.3 type). To allow all workstations on the network to
synchronize their receiving clocks and to help the transmitting
station detect transmissions from other stations, a seven-byte
preamble and a one-byte Start of Frame Delimiter precede
each frame. The preamble's seven-byte length ensures that
the transmitting stations can detect another transmission (or
the resulting jam signal, indicating a collision), no matter how
far away the competing station resides on the network
segment. (The calculations required for setting the preamble
length depend on the propagation speed of the signal on the
wire and the minimum amount of time required to transmit a
signal that covers the entire length of the network segment.)
The preamble can usually be considered part of the hardware
mechanics used to send a packet of data across the wire,
rather than part of the packet itself.

Immediately following the preamble of the Ethernet II frame

2 of 5
format is a six-byte field that contains the address of the
destination station, a six-byte Source Address field, and a
two-byte Frame Type field. Together, these three fields
compose the Ethernet II header . When transmitting each byte
of the address fields, the least significant (rightmost) bits are
transmitted first. For the destination address, the first bit
transmitted (bit 0 of byte 0) indicates whether the address
represents a single station or a multicast address. Thus, if the
first byte of the destination is odd, the packet is destined for a
group of workstations rather than one unique physical address.

A special kind of multicast is the broadcast, in which all bits of

the address field are set to 1. For individual addresses, the
first three bytes identify the manufacturer of the network
interface card and the last three bytes are a unique number
assigned to the individual card. For example, addresses on
3Com cards all start with the three hexadecimal bytes 02 60
8C. This address is called the physical, or MAC (Media Access
Control), address. The destination address identifies the
immediate recipient on the network-not necessarily the
ultimate recipient.

The Frame Type field identifies the higher-level protocol used

to create the packet, such as TCP, Xerox Network System
(XNS), or AppleTalk. For example, a hexadecimal value of 08
00 indicates a TCP/IP packet, 06 00 indicates an XNS packet,
and 81 37 indicates a Novell NetWare packet formatted for
Ethernet II.

The next field in the frame contains the actual frame data. This
field can contain up to 1,500 bytes, including the headers for
the higher-level protocols used to encapsulate the original
data. Complete Ethernet packets range from 64 bytes to 1,518
bytes. There isn't a minimum size for the actual data, however.
When transmitting smaller data packets, a Pad field must be
added to bring the total size of the Ethernet packet up to at
least 64 bytes.

The last field in the packet definition is the four-byte Frame

Check Sequence (FCS). This value is calculated from the rest
of the packet's data, using a 32-bit cyclic-redundancy check
(CRC-32) algorithm. As it receives the packet data, the
receiving station performs the same calculations, then
compares its results with the FCS transmitted with the packet.
If the results are different, the packet is rejected.

RAW AND PHYSICAL

Closely resembling the Ethernet II format, the IEEE 802.3

3 of 5
specification defines the physical layout of CSMA/CD packets.
For its Ethernet_802.3 packet format, Novell uses the 802.3
frame type without adding an IEEE 802.2 LLC header (in this
case, NetWare adds its own proprietary higher-level
information). This type of packet can be called an 802.3 Raw
format. NetWare's 802.3 format is the only CSMA/CD packet
type that doesn't incorporate a corresponding standard header
for logical-link control or data-link control information.

The main difference between the Ethernet II and IEEE 802.3

specifications is in one two-byte field. Where Ethernet II
specifies a Frame Type field, 802.3 specifies a Frame Length
field. While this may seem to make Ethernet II and IEEE 802.3
packets incompatible on the same wire, they can coexist quite
well. This is possible due to the 1,518-byte limit on the size of
an Ethernet or 802.3 frame and the fact that all Ethernet II
Frame Types (assigned and managed by Xerox) are values
greater than 1,518 (decimal). Thus, if a packet has a decimal
value of 1,518 or less (05 FE hexadecimal) in byte positions 13
to 14, it will be considered an 802.3 packet.

Another difference shows up in the Destination Address and

Source Address fields. Whereas Ethernet II uses one bit to
indicate multicast addresses, 802.3 uses two bits. The first bit
is similar to the multicast bit in that it indicates whether the
address is for an individual or for a group, and the second bit
indicates whether the address is locally or universally
assigned. The second bit is rarely used on Ethernet
(CSMA/CD) networks. Novell's use of a Raw 802.3 packet
format makes bridging between Ethernet and Token Ring
networks difficult. Without specialized instructions for
translating packets into the different frame types, a bridge
cannot transfer 802.3 Raw packets between Token Ring and
Ethernet (CSMA/CD). However, because Token Ring (using
the IEEE 802.5 Physical-layer specification) uses the IEEE
802.2 Data-link layer format, Token Ring-to-Ethernet bridges
need only convert the Physical-layer information for NetWare
packets formatted with the higher-level 802.2 Data-link layer
information.

In Novell's 802.3 Raw format, the Data field begins with IPX
header information. The first two bytes in this header (for this
format) are always hexadecimal FF FF. These two bytes help
confirm that an 802.3 Raw packet contains encapsulated IPX
information, but they correspond to IPX's Checksum field.
Because this static information interferes with use of the IPX
Checksum field, 802.3 Raw packets will not be able to use the
security features, such as packet signing, planned for the IPX
format. Packets incorporating 802.2 link information are free to

4 of 5
use the IPX Checksum feature. Note that IEEE does not
recognize Novell's 802.3 Raw format; it recognizes only 802.3
packets encoded with 802.2 and 802.2 SNAP headers.

A LOGICAL ADDITION

Adding IEEE 802.2 LLC information to an 802.3 physical

packet format requires three additional fields at the beginning
of the Data field: a one-byte Destination Service Access Point
(DSAP) field, a one-byte Source Service Access Point (SSAP)
field, and a one-byte Control field. IEEE assigns Service
Access Point numbers (SAPs); among those currently defined
are E0 for Novell, F0 for NetBIOS, 06 for TCP/IP, and AA for
the Subnetwork Access Protocol (SNAP). NetWare packets
using the Ethernet_802.2 format have DSAP and SSAP values
of E0, and the Control field is set to 03 (denoting the 802.2
unnumbered format).

An additional frame type was developed from the 802.2 format

to provide support for more than 256 protocol types. The
newer type, SNAP, is identical to a standard 802.2, except that
it adds a five-byte Protocol Identification field. On any SNAP
packet, both the DSAP and SSAP fields are set to AA, and the
Control field is set to 03.

THE END PACKET

Novell's conversion of its default packet type from 802.3 Raw

to the 802.2 LLC format on the 802.3 physical packet type may
create more work for administrators of existing networks.
However, the additional chore of converting existing
workstations to the 802.2 format provides healthy returns,
including better support for diverse networks, tighter network
security, and greater flexibility in configuring workstations to
interoperate with multiple network operating systems.

5 of 5