While in the previous section I established a brief overview of the early history of Ethernet technologies, the purpose of this section is to dig a little deeper and explore what really makes Ethernet work.  In particular, I’ll expand on Ethernet encoding scheme called Manchester Encoding, the structure of Ethernet frames, and finally the Carrier Sensing Multiple Access/Collision Detection protocol, or CSMA/CD for short.

Manchester Encoding
A logical question someone might have at first when considering the technical details of Ethernet could be, how does Ethernet turn the data that comes from the host PC into 0’s and 1’s that the receiving PC can then decode?  It’s actually similar to how transistors work on a central processing unit (CPU).  Ethernet works by varying the voltage when passing electrical signals.  While a transistors either have none or low voltage (off or 0) or a high voltage (on or 1), Ethernet in the same way transmits an electrical signal of varying voltage levels (high or low) to represent 1’s and 0’s.  Naturally, a few problems may arise during the transmission process.  For instance, what happens if the sender and the receiver become out of sync with each other?  In other words, how does one guarantee that the bit string 0101000 passed by sender is not interpreted as 0000101 by the receiver?  The early developers of Ethernet realized this possibility of ambiguity and consequently Manchester encoding was developed.  A diagram with of the Manchester encoding scheme together with the corresponding binary encoding scheme is shown below:

Diagram representing Straight Binary (top) and Manchester Encoding (bottom)

As the reader can see, there are some obvious differences between straight binary encoding and the improved Manchester encoding.  To explain these differences, let the time between adjacent 1’s and 0’s be a called a bit period (the amount of time needed to transfer one bit).  In Manchester encoding, a 0 is marked by a transition from low to high in the middle of the bit period, while a 1 has a transition from low to high in the middle (see the diagram above to verify this).  Notice that with binary encoding no such transition occurs in the middle of the bit periods.  This simple, yet effective, Manchester encoding scheme with its characteristic transitioning in the middle of bit periods allows for synchronization between the sender and the receiver.  However, let it be said that Manchester encoding is not perfect; it has some distinct disadvantages as well that the keen reader may already have picked up upon:  Since the pulse changes every half a bit period (i.e. from low to high or high to low), Manchester encoding requires twice as much bandwidth than normal binary encoding.  To put this into perspective, for a transfer speed of 10Mbit/s the signal would have to change 20 million times per second or equivalently, 20Mhz.  Early Ethernet technologies, namely 10base5 and 10base2, readily embraced Manchester encoding to keep things synchronized, while more recent Ethernet technologies such as 100baseT and 1000baseT (which will be discussed later on), have adopted different schemes to assure synchronization.

In sum, even if you are confused with the technical details, the one important thing to remember about Manchester encoding is that it allows for the sender and receiver of the data to stay synchronized with one another, removing any confusion that may arise in interpreting strings of 1’s and 0’s.

Ethernet Frames
Moving down the street of abstraction a little ways now, let’s consider what kind of traffic is actually sent through an Ethernet network.  Certainly there is the data from the program on the host PC that is destined to another program on the receiver PC, but there has to be some mechanism ensure that the data actually gets to the proper or “right” receiver.  Furthermore, how about error checking?  All this is taken into account in an Ethernet “frame” that is sent from host to another.  The figure below shows the general organization of one of an Ethernet frame:

Diagram of an Ethernet frame

Let’s now examine these different fields in more detail:

Data (46-1500 bytes) – The maximum transmission unit or MTU of Ethernet is 1500 bytes (we can also refer to this as the payload of an Ethernet frame).  If this level is exceeded, the data will have to be fragmented into separate packets or transmission units (frames).  Also notice that the minimum size for the data field is 46 bytes.  Why not just be simple have 0 bytes be the minimum?  It turns out that a minimum size is necessary so that proper collision detection can take place (collision detection will be discussed in the next section).

Destination Address (6 bytes) – This field is six bytes or 48 bits in length and refers to the media access control (MAC) address of the receiving adapter.  Recall that MAC addresses are hexadecimal and each pair of numbers of such an address requires 8 bits – 0-15 (0-F) for the first 4 bits and (0-F) for the second 4 bits.  This applies to each of the 6 pairs that together form the entire MAC address.

Source Address (6 bytes) – Also six bytes in length, this field refers to the MAC address of the host/sender adapter.

Type (2 bytes) – This field references the type of network protocol being used.  Besides the commonly used IP protocol (recall, TCP/IP), there are other protocols as well, including Apple’s AppleTalk and IPX/SPX.  Each of these protocols has unique identification number for this field.

CRC (Cyclic Redundancy Check)(4 bytes) – The CRC field allows the adapter receiving the frame to determine whether any errors were introduced into the frame since it was first sent.  The CRC value is calculated by the sender using the other bytes in the frame and then inserted into the CRC field.  When the Ethernet frame reaches the receiver adapter, it does the same calculation that the sender did and compares this value to the value in the CRC field.  If these fields do not match, the receiver discards the Ethernet frame.

Preamble (8 bytes) – The purpose of the preamble field is to alert the receiving adapter and to synchronize the clocks of the host and receiving adapter.  The first seven bytes of this field have value 10101010, the eighth byte 10101011.

This sums up the structure of Ethernet frames.  Again, realize that I just went a few layers down the abstraction hierarchy to explain this concept.  In reality all this information is just sent as 0’s and 1’s (high and low voltages), but packaged by the sender PC in the above described way and then interpreted in the same way by the receiver PC.