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 problemsfor example, a user 's net.cfg or Windows network settings configured with the wrong frame type can prevent the workstation from connecting to a server. Recently, however, Novell pushed the topic into the foreground. By changing the default Ethernet frame type from 802.3 to 802.2 for its NetWare operating systems 3.12 and 4.x, the company 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 networkswhich often have devices from several vendors connected to the same network, using several different protocolsprompted 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 structurehence the term 802.3 Raw.

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 typesEthernet_802.2, Ethernet_II, and Ethernet_SNAPsince 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 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 (see Figure 1). 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.

Figure 1: Ethernet II and 802.3 Raw packets have similar structures, except for Frame Type and Frame Length fields. The different fields can coexist because all assigned frame types are greater than 05FE.

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 networknot 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 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 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). (See Figure 2 for a description of 802.2 and 802.2 SNAP frame types.) 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).

Figure 2: IEEE 802.2 and 802.2 SNAP packets start with the basic 802.3 Physical-layer frame type and add 802.2 LLC headers.

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.

This tutorial, number 90, by Dave Fogle, was originally published in the February 1996 issue of LAN Magazine/Network Magazine.