This is the third post in this series. The first post is at http://sigma5.blogspot.com/2015/09/internet-bits-bytes-and-numbers.html. The second post is at http://sigma5.blogspot.com/2015/09/internet-tcpip.html. In the second post I talked about computers having either a local or a remote (in the IPv4 sense) connection. Leaving aside remote connections for the purposes of this post, if two computers are local to each other it means that either one can send a message directly to the other one. How does this work? Let's start by looking at some very early networks.
As discussed in the second post in this series, early networks were hub and spoke networks. They consisted of a bunch of terminals (spokes) connected to a computer (the hub). In the earliest of these networks wires ran directly from the terminal to the computer. Then modems were introduced. This turns a terminal-type signal into one that telephone (or Teletype or TELEX) equipment can handle. This allowed the terminal to be positioned perhaps thousands of miles away from the computer. Nice but still pretty inflexible. The next variation was a multi-drop connection. Here you still have the single computer (with perhaps many connections) at one end of the connection. But by means of clever techniques several terminals could share that one connection.
This helped some more but you still had two problems. In most cases you needed a separate terminal for each computer and the computers could not talk directly to each other. Oh, the "modem" scheme meant you could use one terminal to dial into several computers, if they all supported dial up and the same kind of terminal. But in many cases the computer maker made you use a special type of terminal that only worked on his computers so the whole thing was clunky. And the computer makers didn't see any reason to make things easier. All this incompatibility was good for business.
ARPANET tackled a large part of this problem. It got the computers talking to each other. But in its early incarnation it left the terminal part to the computer companies. With ARPANET, assuming your computer was connected to it, you used a manufacturer supported terminal to connect to your local computer. Then you could with some difficulty ARPANET over to that other computer. That was an improvement but it still left a lot of hassle.
And by this time computers were getting cheaper and more powerful and terminals were getting cheaper and more powerful. But the result was a lot of terminals connected to each large computer. Assume for the moment that your computer is not connected to ARPANET and all you are dealing with is hooking a lot of terminals to your one big "mainframe" computer. It was still hard. You ended up running wires all over your building. And every time you wanted to remodel or move people around it was a big pain in the butt. That's where Ethernet came in.
Imagine you are using radio circuits instead of wires to hook everything together. Then you can move things around within reason and there is no problem. The radio waves still connect everything together. And imagine you use a radio system where the radio receiver on every device, terminal and computer alike, can hear the transmitter of every other device. If this could be pulled off it would be magic. There are some technical details to work out (see below) and the whole thing would be very expensive. But gee wouldn't it be great? That was the fundamental insight of the inventers of Ethernet.
Instead of radio they would use a single common wire, a wire that everyone would hook up to. Since everyone was hooked up to the same wire everyone could listen to (receive) and talk to (transmit) everyone else. It would work just like radio. A bunch of technical details needed to be worked out and a catchy name was needed. The name derives from a long abandoned (because it turned out to be wrong) physics theory about how radio waves worked. The idea was that they were vibrations in something called the "luminiferous aether". The "luminiferous" part was dropped and the modern spelling of ether (the "a" on the front was dropped) was combined with the ubiquitous "net" suffix to get Ethernet. With the name issue solved let's move on to the technical details.
The developers came up with an acronym to describe some of the key technical details. It is CSMA/CD. This mouthful stands for Carrier Sense Multiple Access with Collision Detect. A radio-like signal would be put out on the wire. A radio signal is a modulated carrier. The "carrier" is a standard frequency and the "modulated" part just means you jigger it a little to add in the data. The first decision they made was that every device would use the same carrier frequency (and the same modulation system). That meant everyone could hear all the messages. But it also meant that you could end up with two devices trying to transmit at the same time. The specification was carefully designed to make it easy to sense when that happened.
Multiple Access just meant that many devices could be hooked to the same wire. And Collision Detect just meant that when two devices tried to send a message at the same time everybody (all the devices) could easily and reliably detect it. This situation was called a Collision. Since all the devices used the same carrier frequency and modulation technique these components could be easily and cheaply manufactured. The system did require that the Ethernet network card had to be complex. Specifically, it had to have some computer smarts built in. This increased the expense. But by the time Ethernet came along the required amount of computer power could be manufactured cheaply and would fit on a standard computer card. (Now, everything fits into a single chip.)
Let's dig into what goes on a little more deeply. The computer sends the Ethernet card a message. The card monitors the wire. If it sounds like no one else is using it the card starts sending out the message. While it is sending the message it monitors things for a collision. If everything goes out ok then we are done. But if a collision is detected a "jam" signal is sent out to make sure all the other cards know that a bad thing just happened. Then the card waits for a "random back off delay time". The back off time doesn't have to be very random. The idea is simply to avoid the situation where two cards keep trying to resend their messages after waiting exactly the same amount of time. If the card detects another card starting to send a message during the back off time it politely waits till the message finishes. Then it waits another random back off interval and tries again. If the wire is not too busy ("busy" is being active more than 30% of the time) then all messages should get through without much delay.
The "wire" part of Ethernet has gone through several generations of evolution. The original Ethernet wire was a 1/2" diameter coaxial cable. That was strung around the building. A very clever device called a "tap" was used to hook network cards up to the cable. You could fasten the tap to the cable at any point along the way. A clever design that I am not going to get into, allowed taps to be hooked and unhooked well after the cable was installed. So you had to string the heavy cable around your building once. That was expensive and a hassle. But after that you could tap any number of devices into the cable on an "as needed" basis. And, if you were careful, you could even un-tap them. This was a big improvement over the necessity to string wire all over the place every time you wanted to add or move a terminal.
But the cable was heavy, expensive, and hard to work with. It didn't bend well so it was hard to snake around. This led to a second generation "thin coax" specification. A much lighter and smaller cable was specified. A new generation of taps, etc. was also developed. This was an improvement over the first generation but it was still a pain. Neither the thick coax or the thin coax versions of Ethernet garnered wide acceptance.
Computers have almost since the beginning been about smoke and mirrors. If you can come up with a new system that acts from the outside just like the old system then there is really nothing stopping you from swapping the new system in to replace the old one. And that's what happened with Ethernet. What are the key attributes of Ethernet? (1) This business of all equipment seeing all the messages. (2) This business of collision detection and retry. (3) A third attribute turns out to be fast. It needs to be able to handle a lot of messages quickly. If we can swap out our old Ethernet card (and all the downstream equipment) and replace it with a new "Ethernet" card (and downstream equipment) that behaves just like the old card as far as the computer can tell, who cares if it actually works differently? Nobody! And that's what happened.
The simple "string a single wire all over the place and go from there" idea was replaced by a more complex system that emulated the old system. But this additional complexity ultimately turned out to be more flexible and cheaper. The three components of the new system were: (1) A new NIC (Network Interface Card); (2) A different kind of wire (CAT-n) and lots of wires instead of a single one; and (3) A new component, an Ethernet switch. (Again, don't get hung up on the nomenclature. I will define what I mean by an "Ethernet switch" shortly.)
The new NIC behaved exactly the same way as the old one from the computer's perspective so the fact that it was quite different under the covers didn't make any difference. In this new scheme a separate CAT-n cable connected each NIC to a nearby Ethernet switch. The same type of CAT-n cable was also used to connect the switches together. The secret sauce was in the switch. The switch contained several ports, say 8. Each port had an RJ-45 Jack that fitted an RJ-45 plug on the end of the CAT-n cable. So, for instance, NIC 1 could be connected by a CAT-n cable to port 1 of switch 1. So far so good. But the only device that looks like it would be visible to the NIC is the switch on the other end of the cable. What gives?
The switch cross connected all the ports together. Whatever message came in on one port it was echoed out all the other ports. More than that, the switch monitored what was going on. If it saw an incoming signal on more than one port it sent a Jam signal out all of the ports. If a Jam signal came in on one port it was immediately copied to all the other ports. This behavior was the secret to making this collection of many cables and potentially many switches behave just like the old coax based Ethernet system.
And let me address one piece of complexity right now. A CAT-n cable actually has 8 separate wires in it. This version of Ethernet actually uses separate transmitters and receivers. The transmitter uses certain wires and the receiver uses other different wires. It is important to hook the transmitter on one end to the receiver on the other end. How is this done? A standard CAT-n cable is "straight through". Pin 1 on one end is hooked to pin 1 on the other end. But if the jacks on the NIC and the switch are wired the same then using a straight through cable will connect the transmitter on one end to the transmitter on the other end. That won't work.
The original solution was to have the jacks on switches wired backwards. The receiver would listen on the transmitter wires and vice versa. And that worked fine if you always had switches connected to computers. But then you couldn't hook a switch to another switch. The solution here was a custom "cross over" cable. The cable would be wired so that the "transmit" pins on one end were crossed over to connect to the "receive" pins on the other end. If the network installer people used the right CAT-n cable in the right place then everything would be fine. But sometimes they didn't and everybody would get very confused.
The second generation solution was to have a special port on the switch. It was wired backward so that it could be used to connect with the other switch. That meant that sometimes you had a port you couldn't use and sometimes you didn't have enough "switch" ports. The third generation solution was to put a switch on the special port. The switch would cause the port to use the standard pin configuration or the cross over configuration. That was a little more flexible but it still meant that the network people could screw up. The fourth (and final) generation solution was autosensing ports. The port would sense whether it should be in normal mode or cross over mode. Network people could throw all their cross over cables away and always use straight through cables. They could still screw up by hooking two switches together with two cables (or some more complicated version of the "loop" problem) but it was now much easier to get things right and keep them that way.
But how are devices kept track of? Would it surprise you to learn that the answer is again a number. In this case the number is called a MAC address. A MAC address is 48 bits long so there are lots more of them than IPv4 addresses. In fact, there are 64,000 times as many. So there are 256 trillion of them. That sounds like plenty. But it looks like it is not enough. So this is now called a MAC-48 address. There is a new MAC-64 specification where the number is now 64 bits long. I'll let you figure out how big this number is all by yourself, if you care. For me, it seems big enough.
And in most cases the MAC address is pre-assigned. The way this works is that the 48 bit MAC address is broken into two 24 bit pieces. NIC card vendors go to a central authority and request a MAC block. They get a 24 bit number that goes into the first 24 bits of the MAC address. They then make sure that each NIC they make has a unique 24 bit sub-address number that goes into the last 24 bits. When they run out of a 24 bit group (that's 16 million addresses but it happens to the high volume guys) they request a new block.
Think about every NIC card that has ever been made. And while you are thinking try to remember all the devices you own or have owned that had a sticker on it listing a MAC address. Then think about all the manufacturers that have gone out of business, etc. You can see why 16 million "manufacturer numbers" might not last forever. There are tricks where MAC addresses can be changed or spoofed or dynamically assigned. But this is rarely done so I am going to ignore it.
As with IPv4 messages Ethernet messages are sent from a device with one MAC address to a device with another MAC address. There is a difference. There is no such thing as a gateway. All messages are sent directly to wherever they are going in one hop. There is also something called a "broadcast" message. As with IPv4, there is a "from" MAC address and a "to" MAC address in each message. But there is a way to flag a message as a "broadcast". That means that everybody gets it.
One thing NIC cards do is listen to all the traffic going by. They look at the "to" MAC address of each message. If the MAC address does not match the MAC address of the NIC the message is thrown away and the computer never knows it was there. But the exception to this is a broadcast message. It is received and sent along to the computer in a manner similar to a message that was addressed to the computer.
These broadcast messages are used for several purposes. But one of them is for something called ARP, Address Resolution Protocol. This is how computes find each other on an Ethernet network. Let's say you need to send a message to "computer 5". You send out a broadcast message that asks "are you computer 5?". If everything is working ok then exactly one computer sends a "yes - I'm computer 5" message back. Your NIC can now remember the "from" MAC address of this response. The next time your NIC wants to send a message to "computer 5" it sends a direct message to the NIC card with the right MAC address. All the other NIC cards see this message but all of them except computer 5 silently discard it.
Let's step back now and ask how one computer sends an IPv4 message to another local (in the IPv4 sense) computer over an Ethernet network. It first sends out the appropriate ARP broadcast message asking what NIC card handles the IP address in question. If everything is working ok then one computer sends back an "It's me" message. After that anything going to that IPv4 address is sent as an Ethernet message directly to the appropriate MAC address.
Now is probably an appropriate time to talk about "encapsulation". This too is a popular computer trick. Let's say we want to send a query to a web site. Our browser sends a request to the IPv4 component of Windows (say) to "send this message to IPv4 address 10.20.61.12". The message is "encapsulated". The message itself is left unchanged but IP stuff is added to the front and back of it. This information includes the "from" and "to" IPv4 addresses involved. This bigger message is now sent down another level to the Ethernet component. There Ethernet stuff is added onto the front and back of the bigger message. It is then sent to the NIC card to be transmitted.
In this case what goes out over the Ethernet network is an Ethernet header followed by an IPv4 header followed by the original message followed by an IPv4 trailer and finally an Ethernet trailer. We have encapsulated the original message twice. It is possible to encapsulate three or more times, if circumstances warrant. The benefit is that each "layer" only needs to know about its part of the overall process. And usually it only has to process its own header and trailer information. The part in the middle, the "payload", just needs to be passed along intact.
And now let me revisit Ethernet switches. Computer power keeps getting cheaper and cheaper. So what I have described above is a "classic" Ethernet switch. (Warning: The terminology is about to get warped yet again.) They don't work that way any more. Modern switches have store and forward capability. Each port is monitored separately. As each message comes in it is sent to a common buffer inside the switch. This buffer has enough storage capacity to handle several messages. That means if two messages come on two ports at the same time no Jam is generated. Instead each goes separately into the buffer.
And most messages are no longer sent out all ports. If it is a broadcast message it is sent out all ports. But as messages come in the switch monitors their "from" MAC addresses. That allows the switch to build up a list that tells the switch that a certain specific MAC address is hooked to a specific port. If the "to" MAC address is in the MAC table in the switch messages for that MAC are only sent out the correct port. That cuts way down on traffic. If the switch can't find the MAC address in its MAC table it reverts to sending the message out all ports as before.
This buffering capability allows modern switches to perform another very nice trick. Why have I been saying CAT-n so far? Because there are several "CAT" specifications. The ones that are important to us are the ones that have to do with speed. CAT-3 is designed to handle a 10 megabit speed. CAT-5 is designed to handle a 100 megabit speed. It turns out that both CAT-5E and CAT-6 are designed to handle 1000 megabit speed. You can safely run a lower speed signal down a wire that is designed to handle a higher speed. But it is asking for trouble to send a higher speed signal down a wire that is designed for a lower speed. This problem can be avoided by always using CAT-5E or CAT-6 wire. That's what I do. But beyond that, modern Ethernet switches can now be used to do speed matching.
I used to have a old printer that ran at 10 megabits. But most of my network devices wanted to run at 100 megabits or 1000 megabits. But besides sensing whether a port should run as a straight through port or a cross over port, the ports on modern switches can speed sense. They can figure out whether the NIC on the other end is running at 10, 100, or 1000 megabits. Since all messages are received into the switch buffer and sent from the switch buffer it is no longer a problem if one port is running at one speed while another port is running at a different speed.
My computer could send a message to my printer at 1000 megabits. It would actually go first to the buffer in the switch so this link could and did run at 1000 megabits. The switch would then forward it along to the printer at 10 megabits. The same thing would be true going the other way. The printer might send a status message at 10 megabits. It would go into the buffer in the switch at 10 megabits. It would then go out of the buffer and into my compute at 1000 megabits. Devices can now run at whatever speed is appropriate for that device.
So that's a quick look at Ethernet. But remember the "smoke and mirrors" discussion above. There are now lots of other technologies that parrot Ethernet behavior. The most obvious example of this in the home environment is Wi-Fi. In practical terms Wi-Fi works just like Ethernet. The Wi-Fi card in your laptop behaves just like an Ethernet NIC. It probably even has a MAC address. And a Wi-Fi base station behaves pretty much like an Ethernet switch. And radio signals behave like the CAT-n wires and there is a CSMA/CD-like process for detecting and dealing with collisions. That's why Wi-Fi can be spliced seamlessly into an Ethernet network.
And it turns out it's not just Wi-Fi. You may or may not have heard of SONET or FDDI or ATM or Token Ring or a number of other technologies. They all more or less parrot Ethernet behavior. If you have to administer them then you need to know the details of exactly how each works. For the rest of us we just need to know that they provide an Ethernet-like capability and we need to have some idea of how fast they can move data under real world conditions. The rest we can leave to the experts.
No comments:
Post a Comment