Ethernet Frame Structure

Ethernet Frame Structure

We can learn a lot about Ethernet by examining the Ethernet frame, which is illustrated in Figure 1. To give this discussion about Ethernet frames a tangible context, lets consider sending an IP datagram from one host to another host, with both hosts on the same

 Ethernet Frame Structure

Ethernet LAN (for instance, the Ethernet LAN in "Ethernet" Figure 2). (Although  the payload of our Ethernet frame is an IP datagram, we note that an Ethernet frame can carry other network-layer packets as well). Let the sending adapter, adapter A, have the MAC address AA-AA-AA-AA-AA-AA and the receiving adapter, adapter B, have the MAC address BB-BB-BB-BB-BB-BB. The sending adapter encapsulates the IP datagram within an Ethernet frame and passes the frame to the physical layer. The receiving adapter receives the frame from the physical layer, extracts the IP datagram, and passes the IP datagram to the network layer. In this context, lets now examine the six fields of the Ethernet frame, as illustrated in Figure 1.

●  Data field (46 to 1,500 bytes). This field carries the IP datagram. The maximum transmission unit (MTU) of Ethernet is 1,500 bytes. This means that if the IP datagram exceeds 1,500 bytes, then the host has to fragment the datagram, as discussed in "The Internet Protocol (IP)". The minimum size of the data field is 46 bytes. This means that if the IP datagram is less than 46 bytes, the data field has to be "stuffed " to fill out to 46 bytes. When stuffing is used, the data passed to the network layer contains the stuffing as well as an IP datagram. The network layer uses the length field in the IP datagram header to remove the stuffing.

●  Destination address (6 bytes). This field contains the MAC address of the destination adapter, BB-BB-BB-BB-BB-BB. When adapter B receives an Ethernet frame whose destination address is either BB-BB-BB-BB-BB-BB or the MAC broadcast address, it passes the contents of the frames data field to the network layer; if it receives a frame with any other MAC address, it discards the frame.

●   Source address (6 bytes). This field contains the MAC address of the adapter that transmits the frame onto the LAN, in this example, AA-AA-AA-AA-AA-AA.

●  Type field (2 bytes). The type field permits Ethernet to multiplex network-layer protocols. To understand this, we need to keep in mind that hosts can use other network-layer protocols besides IP. In fact, a given host may support multiple network-layer protocols using different protocols for different applications. For this reason, when the Ethernet frame arrives at adapter B, adapter B needs to know to which network-layer protocol it should pass (that is, demultiplex) the contents of the data field. IP and other network-layer protocols (for instance, Novell IPX or AppleTalk) each have their own, standardized type number. Moreover, the ARP protocol (discussed in the previous section) has its own type number, and if the arriving frame contains an ARP packet (i.e., has a type field of 0806 hexadecimal), the ARP packet will be demultiplexed up to the ARP protocol. Note that the type field is similar to the protocol field in the network-layer datagram and the port-number fields in the transport-layer segment; all of these fields serve to glue a protocol at one layer to a protocol at the layer above.

●  Cyclic redundancy check (CRC) (4 bytes). As discussed in "Error-Detection and -Correction Techniques", the purpose of the CRC field is to allow the receiving adapter, adapter B, to detect bit errors in the frame.

●  Preamble (8 bytes). The Ethernet frame begins with an 8-byte preamble field. Each of the first 7 bytes of the preamble has a value of 10101010; the last byte is 10101011. The first 7 bytes of the preamble serve to "wake up" the receiving adapters and to synchronize their clocks to that of the senders clock. Why should the clocks be out of synchronizatin? Keep in mind that adapter A aims to transmit the frame at 10 Mbps, 100 Mbps, or 1 Gbps, depending on the type of Ethernet LAN. However, because nothing is absolutely perfect, adapter A will not transmit the frame at exactly the target rate; there will always be some drift from the target rate, a drift which is not known a priori by the other adapters on the LAN. A receiving adapter can lock onto adapter As clock simply by locking onto the bits in the first 7 bytes of the preamble. The last 2 bits of the eighth byte of the preamble (the first two consecutive Is) alert adapter B that the "important stuff" is about to come.

Ethernet uses baseband transmission; that is, the adapter sends a digital signal directly into the broadcast channel. The interface card does not shift the signal into another frequency band, as is done in ADSL and cable modem systems. Many Ethernet technologies (e.g., 10BASE-T) also use Manchester encoding, as illustrated in Figure 2. With Manchester encoding, each bit contains a transition; a 1 has a transition from up to down, whereas a 0 has a transition from down to up. The reason for Manchester encoding is that the clocks in the sending and receiving adapters are not perfectly synchronized. By including a transition in the middle of each bit, the receiving host can synchronize its clock to that of the sending host. Once the receiving adapters clock is synchronized, the receiver can delineate each bit and determine whether it is a 1 or 0. Manchester encoding is a physical-layer operation rather than a link-layer operation; however, we have briefly described it here because it is used extensively in Ethernet.

Manchester Encoding

An Unreliable Connectionless Service

All of the Ethernet technologies provide connectionless service to the network layer. That is, when adapter A wants to send a datagram to adapter B, adapter A encapsulates the datagram in an Ethernet frame and sends the frame into the LAN, without first handshaking with adapter B. This layer-2 connectionless service is similar to IPs layer-3 datagram service and UDPs layer-4 connectionless service.

Ethernet technologies provide an unreliable service to the network layer. Particularly, when adapter B receives a frame from adapter A, it runs the frame through a CRC check, but neither sends an acknowledgment when a frame fails the CRC check. When a frame fails the CRC check, adapter B simply discards the frame. Thus, adapter A has no idea whether its transmitted frame reached adapter B and passed the CRC check. This lack of reliable transport (at the link layer) helps to make Ethernet simple and cheap. But it also means that the stream of datagrams passed to the network layer can have gaps


If there are gaps due to discarded Ethernet frames, does the application at Host B see gaps as well? As we learned in "Transport Layer", this depends on whether the application is using UDP or TCP. If the application is using UDP, then the application in Host B will indeed see gaps in the data. On the other hand, if the application is using TCP, then TCP in Host B will not acknowledge the data contained in discarded frames, causing TCP in Host A to retransmit. Note that when TCP retransmits data, the data will eventually return to the Ethernet adapter at which it was discarded. Thus, in this sense, Ethernet does retransmit data, although Ethernet is unaware of whether it is transmitting a brand-new datagram with brand-new data, or a datagram that contains data that has already been transmitted at least once.


ethernet frame, ip datagram, host, network layer

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.