When stations transmit to each other on a LAN, they format the data in a structured manner so that devices know what octets signify what information. Various frame formats are available. When you configure a device, you must define what format your station will use, realizing that more than one format might be configured, as is true for a router.
Figure 1-2 illustrates four common frame formats for Ethernet. Some users interchange the terms packets and frames rather loosely. According to RFC 1122, a subtle difference exists. Frames refer to the entire message, from the data link layer (Layer 2) header information through and including the user data. Packets exclude Layer 2 headers and only include the IP header (Layer 3 protocol header) through and including user data.
Figure 1-2. Four Ethernet Frame Formats
The frame formats developed as the LAN industry evolved and differing requirements arose for protocols. When XEROX developed the original Ethernet (which was later adopted by the industry), a frame format like the Ethernet frame in Figure 1-2 was defined. The first 6 octets contain the destination’s MAC address, whereas the next field of 6 octets contain the source’s MAC address. Two bytes follow that indicate to the receiver the correct Layer 3 protocol to which the packet belongs. For example, if the packet belongs to IP, then the type field value is 0x0800. Table 1-1 lists several common protocols and their associated type values.
Table 1-1. Common Routed Protocols and Their Hex Type Values Protocol
|Protocol||Hex Type Value|
Following the type value, the receiver expects to see additional protocol headers. For example, if the type value indicates that the packet is IP, the receiver expects to decode IP headers next. If the value is 8137, the receiver tries to decode the packet as a Novell packet.
IEEE defined an alternative frame format. In the IEEE 802.3 formats, the source and destination MAC addresses remain, but instead of a type field value, the packet length is indicated. Three derivatives to this format are used in the industry: raw 802.3, 802.3 with 802.2 LLC, and 802.3 with 802.2 and SNAP. A receiver recognizes that a packet follows 802.3 formats rather than Ethernet formats by the value of the two-byte field following the source MAC address. If the value falls within the range of 0x0000 and 0x05DC (1500 decimal), the value indicates length; protocol type values begin after 0x05DC.
Ethernet’s rules govern how stations operate in a CSMA/CD environment. The rules constantly keep in mind the need to detect collisions and to report them to the participants. Ethernet defines a slotTime wherein a frame travels from one network extreme to the other. In Figure 1-3, assume that Station 1, located at one extreme of the network, transmits a frame. Just before the frame reaches Station 2, located at the other extreme of the network, Station 2 transmits. Station 2 transmits because it has something to send, and because Station 1’s frame hasn’t arrived yet, Station 2 detects silence on the line. This demonstrates a prime example of a collision event between devices at opposite extremes of the network. Because they are at opposite ends of the network, the timing involves worst case values for detecting and reporting collisions.
Figure 1-3. A Worst Case Collision Example
Ethernet rules state that a station must detect and report collisions between the furthest points in the network before the source completes its frame transmission. Specifically, for a legacy 10 Mbps Ethernet, this must all occur within 51.2 microseconds. Why 51.2 microseconds? The time is based on the smallest frame size for Ethernet, which corresponds to the smallest time window to detect and report collisions. The minimum frame size for Ethernet is 64 bytes, which has 512 bits. Each bit time is 0.1 microseconds in length, which is calculated from one over Ethernet’s data rate (1/106). Therefore, the slot time for Ethernet is 0.1 microseconds/bit x 512 bits or 51.2 microseconds.
Next, the Ethernet specification translates the slotTime into distance. As the Ethernet signal propagates through the various components of the collision domain, time delays are introduced. Time delay values are calculated for copper cables, optical fibers, and repeaters. The amount of delay contributed by each component varies based upon the media characteristics. A correctly designed network topology totals the delay contribution for each component between the network extremes and ensures that the total is less than one half of 51.2 microseconds. This guarantees that Station 2 can detect the collision and report it to Station 1 before Station 1 completes the transmission of the smallest frame.
A network that violates the slotTime rules by extending the network to distances that require more than 51.2 microseconds experience late collisions, which can cause the network to malfunction. When a station transmits, it retains the frame in a local buffer until it either transmits the frame successfully (that is, without a collision) or the deferral counter threshold is exceeded. We previously discussed the deferral counter situation. Assume that a network administrator overextends the network in Figure 1-3 by inserting too many repeaters or by deploying segments that are too long. When Station 1 transmits, it assumes that the frame successfully transmitted if it experiences no collision by the time that it transmits 64 octets. Once the frame believes that it was successfully transmitted, the frame is eliminated from buffers leaving no opportunity to retry. When the network overextends the slotTime, the source might learn of a collision after it transmits the first 64 octets. But no frame is in the buffer at this point to resend, because the source thought that the transmission was successful!
Ethernet Frame Rates/Performance
Debates rage over Ethernet performance. Specifically, network administrators focus on the question, “What is the average loading that should be supported on a network?” Some administrators claim that the network load should not exceed about 30 percent of the available bandwidth. Some state as high as 50 percent. The answer really depends upon your users’ application needs. At what point do users complain? When it is most inconvenient for you to do anything about it, of course! Networks rarely support a sustained loading over 50 percent due to bandwidth loss from collisions. Collisions consume bandwidth and force stations to retransmit, consuming even more bandwidth. If the network were collisionless, up to 100 percent utilization could be achieved. This is not likely.
To provide some guidelines though, consider the theoretical frame rates for Ethernet. Frame rates depend upon the size of the frame. To calculate the packets per second for various frame sizes, use the following formula:
Packets/second = 1 second/(IFG + PreambleTime + FrameTime)
- Inter Frame Gap (IFG) is equal to the amount of time required between each frame. This is specified as 9.6 microseconds.
- PreambleTime is equal to the number of microseconds to transmit the 64-bit preamble. This is 6.4 microseconds.
- FrameTime is equal to the number of microseconds to transmit the frame. For a 64-octet frame, this is 51.2 microseconds.
The packet per second (pps) rate for a 64-octet frame is, therefore, as follows:
1 second/(9.6 + 6.4 + 51.2) microseconds per packet = 14,880 pps
At the other extreme, consider the pps rate for the largest frame size, 1,518 octets:
1 second/(9.6 + 6.4 + 1,214.4) microseconds per packet = 812 pps
A 30 percent average loading implies that a network analyzer measures about 3 Mbps of sustained traffic on the system. This in and of itself is not enough to determine how well or how poorly the network is functioning. What size packets are creating the load? Usually numerous packet sizes are involved. How many collisions are there on the network? If there are few, only some of the stations are transmitting. This might provide a clue for you that more transmitters can be supported on the network. In any event, a good measurement is needed of your network and what users perceive the current network response to be.