Upgrading and Repairing Networks

Ethernet Frames

When referring to the data that is transmitted through the network, it is a common practice to call the bundles of data "packets." However, the actual terminology for the containers of data exchanged between systems on a network varies, depending on which level of the OSI seven-layer reference model you are referring to (see Figure 13.5). For example, at the Network layer a unit of data is called a packet or datagram. The term datagram usually refers to a connectionless service, whereas packet usually indicates a connection-oriented service. You'll find that both terms are used in the literature when discussing the Internet Protocol (IP). At the Data Link layer these datagrams are usually referred to as frames. Each frame contains the information required for it to be transmitted successfully across the network media, as well as the data that is being exchanged. At the physical level, the frame is transmitted as a series of bits, depending on the particular technology used for encoding on the network medium.

	A good explanation of the different layers of the OSI network reference model can be found in Appendix A, "Overview of the OSI Seven-Layer Networking Reference Model."

The data portion of the frame usually consists of bytes of information that were packaged by a higher-level protocol and then delivered to the Data Link layer for transmission inside an Ethernet frame. For example, the IP protocol specifies the header information used by that protocol, as well as the data that is being carried by the IP datagram. When the IP datagram passes down to the Data Link layer, however, all this information is contained in the data portion of the Ethernet frame.

The composition of the frame depends on the type of network. The original Ethernet frame format and Ethernet II format differ only a little from the IEEE 802.3 frame format, and the IEEE 802.5 (Token-Ring) standard defines a frame that is far different from these two. This is because Ethernet and Token-Ring have different methods for granting access to the network media and for exchanging data between network nodes.

In this chapter we will explore several frame types as they evolved with the technology. When heavy-duty troubleshooting is involved, you will need to get down to this nuts-and-bolts information to understand just what is happening on the wire.

XEROX PARC Ethernet and Ethernet II

The original Ethernet frame had defined several fields that were still used in the Ethernet II specification, including the following:

• Preamble An 8-byte sequence of zeros and ones that is used to announce the start of a frame and to help synchronize the transmission.

• Destination MAC ( Media Access Control) address A 6-byte address usually expressed in hexadecimal format.

• Source (Senders) MAC address Another 6-byte field specifying the address of the workstation that originates the frame.

• Type field A 2-byte field used to indicate the client protocol suite in use (such as IPX, IP, and DECnet) that is to be found in the data field.

• Data field A field of unspecified length that holds the actual data.

In this original frame it was left up to the higher-level protocol to determine the length of the frame. Because of this, the Type field was an important part of the frame.

In Figure 13.6 you can see the layout used for the original Ethernet frame.

The 802.3 Standard

When the IEEE 802 project defined a frame format, it kept most of the features found in the Ethernet II frame. There are some important differences, however. In Figure 13.7, you can see the layout of the 802.3 Ethernet frame.

The major changes included the replacement of the Type field with a new field. These 2 bytes were now used to specify the length of the data field that was to follow it. When the value in this field is 1,500 or less, you can tell it is being used as a Length field. If the value is 1,536 or larger, the frame is being used to define a protocol type.

Additionally, the preamble was reduced from 8 bytes to 7 bytes, and following it now is a 1-byte Start of Frame Delimiter (SFD). The SFD is composed of a bit configuration of 10101011 (the last byte of the earlier preamble has 10 for the last 2 bits).

The last part of the frame is a 4-byte frame check sequence (FCS). This is used to store a cyclic redundancy check (CRC) value that is calculated on the frame. The transmitting station calculates this value based on the other bits in the frame. The receiving station calculates the CRC based on the frame's bits and compares it to this value. If they are not identical, the frame must have suffered some damage in transit and must be retransmitted.

The 802.2 Logical Link Control (LLC) Standard

In the OSI seven-layer reference model, the two lower layers are the Physical layer and the Data Link layer. When the IEEE designed its reference model, it took a slightly different approach. In Figure 13.8, you can see that the IEEE version includes a Logical Link Control sublayer and a Media Access Control sublayer on top of the Physical layer, with the Media Access Control layer straddling the boundary of the Physical and Data Link layers as defined by the OSI model.

	For more information about the OSI seven-layer network reference model, see Appendix A.

There is a rationale for incorporating some of the functionality of the OSI Physical layer in the Media Access Control layer and dividing up the Data Link layer to provide for a Logical Link Control sublayer: It is to allow different types of transmission media and methods of media access to exist on the same network.

The LLC Subheader

The Media Access Control sublayer is responsible for using the services provided by the Physical layer to get data transferred to and from remote stations on the network. This includes functions such as basic error checking and local addressing (physical, or MAC addresses).

The LLC sublayer offers services to the layers above it that can be classified into the following three types:

• Unacknowledged connectionless service Some upper-level protocols (such as TCP) already provide flow control and acknowledgment functions that check on whether a packet was successfully sent. There is no need to duplicate those functions here.

• Connection-oriented service This type of service keeps track of active connections and can be used by devices on the network that do not implement the full OSI layers in their protocols.

• Acknowledged connectionless service This service is a mix of the other two. It provides acknowledgment of packets sent and received but does not keep track of links between network stations.

To implement these LLC functions, IEEE 802.2 specifies a subheader that is placed into the frame directly before the data field. This LLC subheader field consists of 3 bytes. The first is the destination service access point (DSAP), the second is the source service access point (SSAP), and the last is the Control field.

The LLC Ethernet Frame

In Figure 13.9, you can see that when the LLC subheader is combined with the standard 802.3 frame, the overall size of the frame doesn't change, but the amount of space remaining in the data portion of the frame does.

Figure 13.9. The 802.3 frame including the LLC subheader.

[View full size image]

The 802.3 SNAP Frame

In the earlier Xerox PARC and Ethernet II frame formats, the 2-byte Type field was used to indicate the higher-level protocol for which the frame was being used. When the 802.3 frame was delineated, this field was replaced with the Length field that indicates the length of the data field.

To provide for backward compatibility with earlier networks that still needed to have something in the frame to identify the protocol that should be used, the SNAP subframe was introduced. The term SNAP stands for Sub-Network Access Protocol. It is constructed by adding additional fields to the LLC subheader, after the LLC fields:

• Organizationally Unique Identifier field (3 bytes)

• Protocol Type field (2 bytes)

The SNAP extensions must be used with the LLC subheader fields. There are no provisions for a SNAP subheader without the LLC subheader. Figure 13.10 shows the full 802.3 frame that includes the SNAP fields.

Figure 13.10. The 802.3 frame including the LLC subheader and SNAP extensions.

[View full size image]