Category 5 UTP, token ring, twisted pair, hub, switch, gigabit……….What do all these items have in common? In case you didn’t figure it out right away, all the above listed items are related to Ethernet in some way or another. During the mid to late 1990′s as prices of commodity PC Hardware began to decline, households began to acquire more than one PC, and networking them together became increasingly popular. It wasn’t long thereafter that the Internet really gained steam, resulting in explosive growth of companies that produced networking and home networking products. Most people that own a home network don’t give Ethernet or network cabling too much thought these days. It’s just a cable that plugs into the network interface card on one end and into a modem/switch on the other, and then things work. While it is true that DIY (Do-It-Yourself) home networking has simplified immensely over the years, there is still a lot that must go on behind the scenes for a network to work properly. So, how does Ethernet really work on the technical level and how has it evolved since its invention almost 30 years ago? Is there really Ether involved? What’s the difference between a hub and a switch and how these work together with Ethernet? The purpose of this article serves to answer some of these questions by providing a historical background of Ethernet, an in-depth discussion of how the protocol works, advancements in Ethernet technology, and finally a short discussion of common Ethernet network building blocks, namely hubs and switches.

It should be noted that this is not meant to be a definitive guide to Ethernet. It is mainly my intent to provide a more in depth look of how Ethernet works and how the technology has evolved since its inception. Naturally, given the extensiveness of the subject, I can’t cover every little thing in detail, but I will hit on many of the main points and ideas in the discussion that follows. Should you need/want more information after reading this article, I ask that you please consult the sources I’m listing at the end of the article.

With that bit of a disclaimer out of the way, let’s get started looking at the history of Ethernet.

[hidepost=1]

Part I: Beginnings of Ethernet

The original Ethernet topology was invented in the 1970′s by Bob Metcalfe and David Boggs and was called 10base5 or “thick” Ethernet (thick because it used thick coaxial cabling). What does the notation 10base5 mean? Well, the 10 represents the maximum bandwidth (in this case 10Mbit/s), base just means that baseband signaling is used, and 5 tells the maximum permissible distance (in this case it is 500m). A 10base5 Ethernet setup essentially works as follows: A “tap” or connection is made to the core of the “Ether” (which is really coaxial cable). This tap actually contained in the transceiver that is fastened around the cable. A transceiver is really nothing more than a device that can both receive and transmit electrical signals. Certainly, a device such as this would be critical to have two-way network communication.

A 10base5 Transceiver

Moving along further now, a cable runs from the transceiver to an appropriate interface, which is part of the PC’s controller expansion card. The transceiver/controller cable itself can have up to five twisted copper pairs. Two of these pairs are used for data transfer, two more for control signals, and the last pair may or may not be used to power the transceiver. Besides being able to send and receive signals, the transceiver is also capable of detecting collisions; however, I will examine this concept more later in this article. Suffice it to say at this point that this primitive setup by Metcalfe and Boggs was the first successful Ethernet network. As the matter of fact, their original 10base5 setup ran at a blazing 2.94Mbps with 256 hosts connected over a 1 mile interval. Quite impressive given the time period.

After 10base5 technology had emerged, a couple other Ethernet technologies were invented as well, and deserve to be mentioned here. One of these, 10base2 or “thin” Ethernet (due to the fact that is used thin coaxial cable as opposed to 10base5′s thick cabling), has a few key differences. Most notably is the fact that now simple Bayonet Neill-Concelman (BNC) connections were used to connect to the ether (coaxial cable) as opposed to tapping into the cabling as was done by a transceiver. The transceiver portion itself was now part of the PC’s controller expansion card. As you might have picked up on already, the range of 10base2 Ethernet is significantly shorter than 10base5, coming at just under 200m (185m actually to be exact).

A 10base2 Cable

Closeup of “T” connector w/terminator

While 10base5 and 10base2 Ethernet are similar in that they both allow nodes connected to them to share a common transmission medium, the emergence of 10baseT Ethernet (T meaning twisted pair) brought with it a new device called a hub where data cables would come together (the details of hubs will be discussed later in this article). The advantage of such a setup was that if a cable broke, only the machine with the broken cable would be affected instead of having the whole network go down with a shared medium topology like 10base5 or 10base2. It should also be noted that 10baseT used twisted pair copper cabling from the PC’s controller card to a device called a hub (to be discussed in detail later on), eliminating the need for bulky coaxial cable and BNC connectors. The figure below shows a common 10baseT hub:

A 10baseT Hub

Part II: Technical Details of Ethernet

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.

Collision Detection – CSMA/CD

While by this point I have covered various aspects of the workings of Ethernet, one major issues still remains. What happens when the nodes are sharing the transmission medium and a collision occurs (e.g. two nodes try to send data at the same time)? Luckily, this scenario was taken into account as Ethernet was developed and the CSMA/CD protocol was deployed to handle this type of conflict. CSMA/CD stands for Carrier Sensing Multiple Access/Collision Detection and while this probably sounds confusing to a lot of you right now, it will be cleared up in just a bit. While I could now take a time out and explain this protocol in great detail, I’ve instead decided to keep things within the scope of this article and instead focus on how it ties in with Ethernet, and also why exactly it is necessary. The main components of the CSMA/CD protocol basically breakup as follows:

1. An adapter on a host can start transmitting data at any time.
2. The adapter possesses a means to sense whether other adapters are transmitting and will not do so if this is the case. This is what the term “carrier sensing” refers to.
3. If an adapter does transmit and a collision occurs, that transmission is aborted and a jam signal is sent into the transmission line by the sender making sure other nodes also transmitting on the same transmission medium are aware that a collision has just occurred. Right here is the place now where we need to backtrack just a little bit and explain things in a little bit more detail. Recall that I mentioned earlier that the Ethernet frame’s data field needed to be a minimum size, namely 46 bytes. The reason for this is solely that the sender of the frame can detect that a collision has occurred. Consider the scenario now where the frame sent is too small (e.g. 0 byes). In this case the sender might be done transmitting before the collision occurs in the medium (especially if the transmission distance is long enough, i.e. a long transmission medium). The end result: The sender of the frame thinks the frame was successfully sent, the receiver of the frame senses the collision and drops the frame and the data is not resend. A smart reader might at this point begin to scratch his/her head: If the receiver of the frame senses the collision (e.g., since it’s sending data at the same time), consequently sending a jam signal into the medium, how can the sender of the original frame not be aware of the collision since it would sense the jam signal? The problem with collision detection is that the sender has to be transmitting to properly detect there was a collision with the frame it sent.
   Diagram of a collision during data transmission

   In other words, if the sender of a frame is done transmitting and a collision occurs it is already too late because the sender only becomes aware that there was a collision. It has NO means of knowing that its frame was the one involved in the collision unless the collision happened while it was still transmitting. Thus the only way that a frame will get resend by a sender is when a collision occurs when the sender is still transmitting (allowing the sender to successfully detect the collision). If the frame has already been sent and the collision occurs, the frame is dropped and not resend. Hence a minimum frame size is necessary given a certain specified transmission distance. As can be seen later on the in this article, this whole dilemma of collision detection provides a major hurdle for increased Ethernet speeds. What does one do? Increase the frame size as speeds increase, or decrease the distance between adjacent hosts? More on this later on when I discuss 100baseT and 1000baseT ethernet technologies.

4. If a collision is detected by an adapter, the adapter waits a finite random time interval before transmitting again. The random wait interval is chosen from the following set:(0…….2^n-1)Where n is the nth collision number and can range from 0 to 10. After the 10th collision, n remains at value 10. To put all of this into perspective, after the first collision occurs each adapter chooses a random time from to 0 to 2^0, i.e. (0,1). For the 2nd collision it will be from 0 to 2^2, or (0,1,2). As you can see, when the number of collisions increases, the pool of wait times increases exponentially. Why not increase linearly instead? The main reason for this is that there is no awareness of how many nodes are hooked into the same transmission medium when the collision occurs. By increasing the pool of wait times exponentially, the odds that another collision will occur in the future will decrease since the chance that each of the nodes will pick different wait times increases.

In Conclusion, the CSMA/CD protocol is pretty extensive and well thought out. While it does have its drawbacks it does allow for traffic to flow smoothly across a shared medium. Enough with the technicalities now though, let’s move on to talking about faster Ethernet technologies.

Part III: Faster Ethernet Technologies

In the early 1990′s the IEEE’s 802.3 committee (the committee put in charge of Ethernet standards since 10base2) met again to develop a faster Ethernet. Discussion was carried out as to how this new Ethernet should be structured. Should everything be redone from scratch? Should core attributes stay the same? It was eventually decided do just that and allow the new, faster Ethernet backwards compatible with current Ethernet setups. Thus the only major change from 10Mbit Ethernet to 100Mbit Ethernet, or “fast Ethernet”, was to decrease the time it takes transfer one bit from 100 nanoseconds to 10 nanoseconds (1 bit takes 100 nanoseconds to transfer on 10Mbit Ethernet — verify this simple calculation if you have doubts). This could easily have been done by utilizing a wiring scheme such as the old 10base5 or 10base2 and decreasing the distance by a factor of ten (recall the discussion in the previous section as to why this would have needed to be done). However, 10baseT Ethernet with its twisted copper pair topology and inclusion of hubs provided enough advantages at the end and won out. Thus, 100baseT Ethernet would not be supported on the tap/transceiver or BNC connections of the older 10base5 and 10base2 technologies. However, the real question after deciding to go with 10baseT became what kind of wiring should be supported? Category 3 UTP (unshielded twisted pair) became the obvious choice as it was deployed widely in offices and as phone cables at the time.

The downside was that CAT 3 UTP used a signal speed of only 25MHz (10base5 and 10base2 already used 20MHz!). How is it possible then to achieve the necessary transfer rate of 100Mbit/s? The solution was to use all four twisted pairs of CAT 3 UTP cabling. Doing so would allow for the ability to transfer 4 bits in parallel in each of the 25 million cycles per second (MHz), equaling a transfer rate of 100Mbit/s (4bits x 25MHz). Furthermore, it should also be noted that Manchester encoding is no longer used in fast Ethernet, as technology had improved and distances were short enough, allowing sender and receiver to stay synchronized with one another without it.

Besides category 3 cable, category 5 UTP cable could also be used for fast Ethernet. The advantage of CAT 5 UTP cabling is that the signal rate is increased by factor 5 to up to 125MHz. Consequently, only two twisted pairs would need to be used to achieve the same kind of transfer rates that required four twisted pairs with CAT 3 UTP cable.

Category 5 Ethernet Cable

Manchester encoding is not used here either, but instead a technique called 4B/5B. This basically takes a group of 5 clock periods (e.g. 10101) which can have a total of 32 combinations (2*2*2*2*2). 16 of these combinations are used for transmitting data, while the other 16 are used for control purposes (e.g. determining the frame cutoff etc..). Another advantage of this setup is that it supports full duplex transfers if a switch utilized, i.e. 100Mbit/s receive and 100Mbit/s send at the same time. Why is a switch required for full duplex data transfers? More on this in the next section.

Not soon after the fast Ethernet standard was developed (also known as 802.3u) the IEEE 802 committee got together again to develop an even faster Ethernet. This Ethernet was to be 10 times faster than “fast Ethernet” and still be backwards compatible. Just as 100baseT Ethernet, the new Ethernet would not support the sharing of a transmission medium for multiple devices. Instead if would be point-to-point, i.e. machine to machine or machine to hub/switch. The new Ethernet was born and given the 802.3.z standard. Its transfer rate was 1000Mbit/s and so was quickly dubbed “gigabit” (the metric prefix for 10^3 is Giga). Gigabit, like its predecessor, uses category 5 UTP cabling, however this time all four twisted pairs are used in data transfer. Each pair of copper cables represents two bits, and since there are 4 pairs to choose from there’s the ability to send 4×2 bits = 8 bits in parallel. Recall that the signaling speed of CAT 5 cabling is 125MHz, and after carrying out some simple math we will see that the transfer rate of 1000Mbit/s is achieved (8bits x 125MHz).

Part IV: Hubs and Switches

Hubs first gained popularity as the 10baseT standard was developed. To describe what hub is, another name might fit better, and that is repeater. A hub takes a signal from a node connected to it, boosts the signal’s strength and broadcasts it to all other nodes also connected to the hub. The downside of this becomes that the CSMA/CD protocol still has to be used as collisions will frequently occur. This is what the collision light on all hubs symbolizes in case you were ever wondering. 10Mbit and 100Mbit hubs have been developed, however there are currently no 1000Mbit hubs. Also, hubs only allow for half duplex operation. That is to say traffic can only flow at 10 or 100Mbit/s one way and not at these speeds simultaneously both ways. The figure below shows a common setup with hubs:

A hub based network topology

Notice the inefficiency of this setup. As the node on the right sends traffic into the network it will reach the first hub where it will then be transferred into all outgoing channels including the channel to the 2nd hub, where the signal will once again be strengthened and broadcast further on all outgoing channels. This can lead to a major amount of broadcast traffic as well as numerous collisions.

A switch is similar to a hub, but it does not broadcast the traffic received from one connected node to all the other connected nodes. Rather, the traffic only goes to the node for which it is intended. The advantage of this is that each node is now on its own collision segment and does not have to worry about running the CSMA/CD protocol.

A switch based network topology

Since the traffic can now also be full duplex (full speed send and receive at the same time) collisions can really only occur inside the switch. Thus the switch itself handles all of the collisions and also has buffers for incoming and outgoing traffic for each of the nodes. Furthermore, a switch has the ability to filter traffic. That is to say if the traffic is not meant to go through this particular switch it will not be passed on. To pass or forward data on, a switch builds a table with MAC addresses and the corresponding port on the switch the data traffic would need to go through to reach that corresponding MAC address. At the end, all these novel improvements over hubs present a more efficient network topology that offers better overall performance.

This article’s attempt has been to demystify the workings of Ethernet and provide an insight of how far this networking technology that millions use daily has come from its conception in the 1970′s. What does the future hold in store for Ethernet? 10 gigabit is on the horizon, but will copper be able to provide the necessary signal rate? There’s no doubt in my mind that speeds will continue to ramp up as computers become more powerful and the Internet continues to grow with multimedia content.

[/hidepost]

Like what you read?

If so, please join over 28,000 people who receive our exclusive weekly newsletter and computer tips, and get FREE COPIES of 5 eBooks we created, as our gift to you for subscribing. Just enter your name and email below: