During a lecture, Professor N. Erd once said: "A network is an ensemble of hardware and software that allows users to connect to resources."
The way I (Norm Al Dude) see it, it's hard to understand what networks and computers do unless one makes analogies with people and human institutions such as the Postal Service, UPS or Federal Express. Computers have been modeled after humans; computer networks after Package Delivery services like those mentioned.
Did you ever move your household? If you're like the average American, you bet you have!
User messages are split into manageable pieces (called packets) by some piece of network software called the Transport Layer, exactly like you would prepare your household goods to be shipped across the country. The pieces are carefully wrapped and numbered (using a 'transport header' and labeled so that at destination the household can be put back together (kitchen packet nr. 1 of 10, 2 of 10, etc...10 of 10). A note is written on each label showing who's the owner of this packet, and possibly special instructions such as 'handle with care,' 'don't send it upside-down,' etc.
Oops! Professor Erd heard me and says "We don't need these silly analogies! It's obvious that the packetizing is needed to share links and trunks in a fair way: short inquiry-response messages and long file-transfer ones can't be sent over the same link unless they are exposed to excessive delays and with very inefficient error control!" I would like to smack him, but he keeps all the money. Shut up, N. Erd!
So, listen to me, folks: a little message behind a very large one on the same link feels just like you, when having to copy one sheet, and this mule in front of you with the whole unabridged Webster's dictionary to reproduce would not yield.
And then, after transmission of a very large file, would you like to be told that something went wrong and you have to retransmit the whole silly thing? Better to check packet-by-packet, no?
Now, how do we know where and how to send the packets? Look at a map and you'll see what I mean! There are so many ways to get from here to there! That's when we start needing the Postal Service. They sure know how to direct all packages. And if they miss some, we'll use UPS or Fed Ex instead!
They all have offices that route (oops - I didn't want to use this techie term here). Now that I did it, I might as well tell you: a router is nothing but a Post office (or a UPS or Fed Ex office) for data packets.
Think about the Postal Service: you put a letter to Mom in an envelope with your and her 'local' street address (source and destination), and the two ZIP-codes, pay the 32-cent fee and leave it in a mailbox. Similarly, in the source PC, the transport layer who did the packing, then calls the network layer that will construct the source and destination network addresses (in the form network.host, where network is the ZIP-code where Mom the host lives).
PCs put their packets in the mail box of their post offices, the 'default router', or some other 'specified router' whose host number and physical address they must know.
At the post office, nobody is looking at anything else but the ZIP-code where Mom lives (destination). The packet will be sent via the best possible route, and will reach Mom's ZIP-code from post office to post office, until the last post office reading Mom's ZIP-code recognizes it as its own.
Each post office enroute examines the destination ZIP-code: is it the one served by this office? If it is, Mom lives here and the letter has to be carried to her. If not, send the letter to another post office that can reach Mom's ZIP-code.
Routers do exactly the same: each one makes a simple decision when a packet arrives from another network: Is the destination network number of this packet the number of the network the router serves? If yes, the router must deliver the packet over the locally attached network. If not, the packet must be routed to some other router that knows how to reach that destination network.
Once at the destination network, the mail carrier has to read not only the host number (Mom's), but also has to find her street address (Mom needs a host number because Dad might live at the same address, and this letter is for Mom's eyes only) and physically deliver the letter by whatever means are available in that town: car in Chicago, bicycle in Peking, gondola in Venice.
The last router will do just that. It will deliver the packet to the destination host via Ethernet (car and highway), or token ring (bicycle), or FDDI (gondola), depending on what kind of LAN the router and host are attached to.
To do so, the router must know the physical LAN address of the host. If it's on the packet itself (in its network header), no problem - the router reads it and sends the packet there.
If the header does not have it, the router has to look in some address directory to find it, or has to broadcast over the LAN a request to find the host's physical address. Sort of like the mail person would take a bullhorn and shout on each street: "Can anyone tell me where Mom lives?"
When the answer comes (probably from Mom or some other helpful neighbor - her proxy), everybody on the LAN takes notes and fills the directories they keep, so when they have to send something later to the same host, they do not have to use the bullhorn again. This is called ARP (Address Resolution Protocol), and as a result, the router and each PC smart enough to support ARP builds its own ARP cache table. But they only have a limited number of spaces in these tables, so entries used very seldom are erased after reaching a certain 'age' and have to be relearned later if written to. Time for the bullhorn (broadcasting) again.
Now, remember that each router had to make a routing decision for the packet?
Just like in the post office, this is done by examining some tables and finding from these tables what's the best route for this packet. How these tables are built depends on how smart the routers are: some are simply told by management what path to use to get any packet from here to Mom's network; these are said to use static routes. Some other routers are so smart that they can send little 'hello' and 'I heard you' messages to each other from time to time, and measure how long it took for the response to come back, and choose the path over which packets are suffering the shortest delay at the time (dynamic routing). Cool, heh?
The real routers speak their own languages (protocols) to build these tables: RIP (Route Information Protocol), OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System). Sounds like Greek to me.
Well, do you think Fed Ex or UPS or the Postal Service have different businesses? Of course not; they all are in the packets delivery business. But take, say, a Postal Service employee and put him or her in a UPS office without any training - he's totally lost!
The same way, the network architectures (schemes) of TCP/IP, Netware NCP/SPX/IPX, Apple's Appletalk, IBM's SNA or APPN, DEC's DECnet, OSI, etc., are doing all the same thing: sending packets from here to there -- but they are all incompatible with each other. Like the Tower of Babble of networking!
Amazing what some folks can come up with sometimes: they made something called a 'multiprotocol router', sort of like having a Fed Ex and a UPS and a post office in the same building.
This saves on hardware: one building instead of many. And on bureaucracy: one management instead of three! That does not mean that UPS packets will be handled by Postal Service workers. They still route their own.
To have the Postal Service workers trained and willing to handle UPS or Fed Ex packets you need a gateway (a translator) , not a router. But, beware: some call routers gateways (TCP/IP), some call routers bridges (old Novell networks) and some call their bridges routers (IBM). What a mess! - it's a good thing that I've explained it all to you.
Professor N. Erd is bugging me to review it all in PHD-ish. I better let him do it or he won't take me to lunch later. And he's the guy with all the dough!
You're welcome to peruse a list of publications that offer more information on routers and related topics.
So long, folks.
Yours,
Norm Al Dude
Tutorial indexThe tutorial index page lists other articles on the technology of data communications.
HomeReturn to the main DataComm-US index page.
Copyright © 1996 SCAN Technologies.
All rights reserved.
Authors: Dan Stern and Frank Mazella