An Ethernet frame consists of three parts:
When a frame arrives at an interface, the interface does not pass anything but the packet part on to the operating system. The preamble is a fixed bit pattern used to synchronize the circuitry to the incoming data. The data in a 10 Mbps Ethernet should be coming with 100 nanoseconds between each bit, but no two clocks are every synchronized perfectly. The preamble allows the sender and receiver to tolerate small differences in their bit rate. The trailer contains a cyclic redundancy check (CRC) checksum so that the interface can check the CRC it receives against the CRC in calculates to help guard against corrupted packets (typically due to electrical interference).
An Ethernet packet consists of two parts:
The header contains information only of interest to the Ethernet protocol itself while the data typically contains the network-layer data. The header consists of three fields:
The destination address indicates the address of the interface that should receive the data. Normally, all other interfaces ignore a packet with a destination address not their own. The interface with the matching address will read the packet into an internal buffer and then interrupt the CPU so the operating system can grab the buffered packet and process it.
Three exceptions exist to the basic rule that only the destination address corresponds to a single machine that will process it. First, a destination address consisting of all 1 bits corresponds to the standard "broadcast" address. A packet being broadcast is processed by all machines with interfaces on the network. Second, by mutual agreement, a subset of machines can form a "multicast" group and intercept all packets with a particular destination address that does not correspond to any machine on the network. An machine may belong to several multicast groups. Third, a machine may put its interface(s) into "promiscuous" mode and process all packets being sent on the Ethernet. This is commonly referred to as "sniffing the ether," and is used both to eavesdrop and to do diagnostics.
The differentiation between different frame times comes by looking at the length/type field.
In an IEEE 802.3 frame, the packet will have a length/type field which designates the length (in 8-bit bytes) of the data in the packet. No more than 1500 bytes of Ethernet data are allowed, so a 16-bit data field is sufficient to hold this value. If less than 46 bytes of data are being carried, some data bytes will be ignored since Ethernet frames must be at least 64 bytes long to deal with collision detection. The minimum size for a packet would be larger if the data rate or maximum propagation delay were larger. 64 bytes is 512 bits which takes 51.2 microseconds to transmit at 10 Mpbs. The maximum propagation delay must be half of this (25.6 microseconds) in order for collisions to be detected.
While we are looking at frame length, it is worthwhile noting that a 1 Gbps Ethernet would require a minimum frame size of 6400 bytes is 25.6 microsecond delays were permitted. Alternatively, if a 1 Gbps Ethernet permitted a 64 byte frame, it would require a 256 nanosecond maximum delay, limiting the maximum distance between nodes to about 200 feet (since light travels about 1 foot per nanosecond).
Below, we have output produced by a sniffer on the Ball State Computer Science Ethernet network of IEEE 802.3 frames. Each line correponds to the first 16 bytes of an Ethernet packet in hexadecimal.
ffff ffff ffff 0000 c078 252d 0060 ffff 0000 c063 332d 0040 3321 f00a 002e ffff 0040 3321 f00a 0000 c063 332d 0026 ffff 0900 07ff ffff aa00 0400 bc06 025c aaaa 0900 07ff ffff aa00 0400 bc06 008b aaaa ffff ffff ffff 0000 c028 332d 0060 ffff ffff ffff ffff 0000 c0ee a86b 0060 ffff ffff ffff ffff 0000 c005 a140 0060 ffff ffff ffff ffff 0000 c0e4 9e40 0060 ffff 0300 0000 0001 0800 36d2 5302 00bf f0f0
We see the first packet is a broadcast (destination address ffff ffff ffff) with 96 bytes of data (0060 hex). The next pair of packets are a request-response pair: the destination address of the first packet in the pair is the source address of the second packet in the pair. It is likely that these packets are the result of one machine making a request of another and the other sending its response to the request back. Request-response pairs are not always adjacent in the flow of data since it might take some time to process the request. During the processing time, other machines will use the Ethernet.
In this example, the packets with the leading data bytes (shown at the end of each line after the header bytes) of ffff are Novell Netware IPX packets. On the Ball State Campus, IPX is encapsulated directly by IEEE 802.3 packets. IPX may also be encapsulated by Ethernet II or 802.2/LLC packets.
Some, but certainly not all, IEEE 802.3 Ethernet packets also conform to an additional protocol called the Logical Link Control (LLC) protocol. The IEEE 802 system divides the data-link layer into two sublayers: the Media Access Control (MAC) and LLC layers. Packets participating in the LLC protocol contain an LLC header after the previously described 14 byte Ethernet MAC header. LLC protocol data is the same for other IEEE 802 protocols such as 802.4 token bus and 802.5 token rings even though those protocols have different MAC headers.
LLC is used when it is desired to have a reliable, flow-controlled data-link layer. LLC uses some of the same techniques used by TCP in managing reliability and flow control. However, if the upper layer protocols are going to manage these properties themselves, having a lower layer protocol do so will just cause extra network traffic carrying low-level acknowledgments, high-level acknowledgments, and low-level acknowledgments of the high-level acknowledgments.
While some Ethernet frames carry IEEE 802.3 packets, other frames on the same Ethernet network may carry Ethernet II packets. In an Ethernet II packet, the length/type field carries a packet type indicator rather than a length. It is left to the interface to determine the actual termination of a packet by detecting an end-of-frame signal that is also present in IEEE 802.3 frames. It is left to the upper layer protocols to determine how much of the data part of the packet should be ignored.
The two types of packets can coexist on the same Ethernet without confusion because the protocol types are always specified by values larger than the maximum data size (1500). The packet type is used by the operating system to decide which network protocol subsystem should process the packets.
Again, we have sniffer output to illustrate the point:
ab00 0401 0101 aa00 0400 5004 6007 7000 Type=6007 (DEC Local Area VAX Cluster (LAVC)) 0800 200f c73e 0000 c0b9 d9e4 0800 4500 Type=0800 (Internet Protocol (IP)) 0000 c0b9 d9e4 0800 200f c73e 0800 4500 Type=0800 (Internet Protocol (IP)) 0900 2b00 000f aa00 0400 0804 6004 2808 Type=6004 (DEC Local Area Transport (LAT)) 0900 2b01 0001 aa00 0400 bc06 8038 e119 Type=8038 (DEC LanBridge Management) 0900 2b04 0000 0800 2b2d bb6f 8041 3300 Type=8041 0100 8100 0100 0000 8109 7c80 0013 aaaa Type=8003 (Cronus VLN) ab00 0003 0000 aa00 0400 bc06 6003 1b00 Type=6003 (DECNET Phase IV, DNA Routing) ab00 0002 0000 aa00 0400 5004 6002 8700 Type=6002 (DEC Remote Console) ffff ffff ffff 0000 c035 9940 0806 0001 Type=0806 (ARP/RARP)
Again, we see what looks like a request-response pair in the second and third packets. In this case, these packets represent telnet/TCP data being sent from the Web server to the machine on my desk followed by a TCP acknowledgment. The last packet is a broadcast packet, and although there is no way to tell just by looking, several of these packets are multicast packets with destinations that do not correspond to any particular machine on the network. This variety of Ethernet type field values was gathered in about a minute of activity on the Ball State Computer Science Ethernet network. Some of the multicast packets cross a bridge between Computer Science (CS) and University Computing Services (UCS) which operates a DEC VMS cluster. The bridge is not able to filter out the multicast packets because it never sees a packet with those addresses in the source address field. If it did, then it could know where to limit the delivery.
Actually, the device that joins CS and UCS is a "brouter" - a combination bridge/router. The device attempts to determine the protocol type that is in each packet it sees on each of its 24 Ethernet interfaces. If it knows how to route that protocol, it routes it. If it knows that the protocol should not be routed, it doesn't route it. Otherwise, it treats the packet like a bridge/switch would treat the packet. Some of the DEC protocols in the above illustration fit into the category of protocols the brouter deals with as if it were a bridge. Such a device costs tens of thousands of dollars and are only made by a very few manufacturers. Simple networks with only a few modern protocols do not need them.
The key to interoperation between the two main types of Ethernet frames on the same Ethernet is that each frame type is encapsulating a disjoint set of higher layer protocols. In the case of Ball State, IPX travels on IEEE 802.3 and IP travels on Ethernet II. Each machine is configured as to what lower layer protocols will encapsulate each upper layer protocol. If the same upper layer protocol were encapsulated in two different lower layer protocols by different machines, they could not communicate directly using that protocol.
The TCP/IP standards for Ethernet encapsulation state that Ethernet II should be used on any machine in which it is available. Hence, Ethernet II is almost always used. When installing Novell Netware, one is presented with a list of possible encapsulations. The default choice on the list is direct IEEE 802.3 encapsulation, but it is also possible to use Ethernet II. The important thing is that all Netware machines use the same encapsulation on the same Ethernet.
Some operating systems have difficulty dealing with multiple frame types and/or multiple protocols on the same Ethernet. Some systems use the trick of having one physical hardware interface, but separate logical software interfaces for each frame type.