An Interview With The Router Man 94
Angry_Admin writes "For Network World's 20th anniversary, they've published an interview with William (Bill) Yeager, the creator of the multiprotocol router, with some history on how Cisco came to be. As he says in the interview : 'This project started for me in January of 1980, when essentially the boss said, "You're our networking guy. Go do something to connect the computer science department, medical center and department of electrical engineering."' 6 months later he had his first working 3MBit router shoved in a closet."
Re:I'll say it again (Score:4, Informative)
The protocol version number is probably different now. The hardware didn't care about the protocol on top. I worked on converting a system from 3MBit to the new 10MBit ethernet in 1980 but I never knew or cared about IP addresses.
Christ on a Locomotive?! (Score:5, Informative)
I saw Heron of Alexandria [wikipedia.org] on Discovery a while back. He was quite the mechanical engineer, apparently. One of his inventions, called an "aeolipile", pictured in the Wikipedia article, is the first recorded steam engine. The upshot is that he invented it sometime between 150 BC to 0 AD.
Quoth that article:
the first recorded steam engine, (known as Hero's Engine) which was created almost two millennia before the industrial revolution, which was powered by steam engines. Apparently Hero's steam engine was taken to be no more than a toy, and thus its full potential not realized for quite some time.
My point is that, just because something seems inevitable doesn't mean that it is. People miss the obvious all the time, and due to the most incredibly mundane reasons. If not for inexplicable lack of imagination in an otherwise incredibly imaginative and inventive guy, the industrial revolution could conceivable started in Greece around the time of Christ.
It took almost 2000 years before it was obvious to someone else. Inevitable? Maybe. But it might have been your grandkids' grandkids who created the internet, if this guy hadn't hit the right set of circumstances.
Re:I'll say it again (Score:3, Informative)
Re:Things have come so far. (Score:3, Informative)
Well take it from a networking 4 th year Phd. your description of layering and encapsulation is totally wrong. I don't blame you, I blame the ignorant mod who gave you +1.
TCP/IP segment-> ethernet frame or TCP/IP segment-> ATM -> SONET (perhaps) or TCP/IP->MPLS
there is no need to encapsulate ethernet frame in ATM, since in the case of IP traffic both ATM and Ethernet are layer 2 protocols. you either have a 802.3 LAN or point to point ATM links.
Re:I'll say it again (Score:2, Informative)
When TCP/IP was added, the 32-bit value was formed as 36.nnn.0.hhh where nnn was the Pup net address and hhh was the Pup host address.
Routing the past (Score:2, Informative)
By the way, the whole issue is one that everybody should read, even if only for the timelines. Most issues have at least one interesting article in them, although this is by far the most interesting.
Just my 2 cents
Re:Things have come so far. (Score:3, Informative)
The application data is packaged into the 1472-byte payload of a TCP/IP packet. That TCP/IP packet is handed off to the network interface adapter. For this example lets assume it's an Ethernet nic. The Ethernet nic (its driver or the actual ASIC on a fancy server nic) encapsulates the TCP/IP packet and stuffs it in the 1500-byte payload of an Ethernet frame (again we're glossing over the possibility of jumbo frames). Lets gloss over all of the network stuff between your nic, your LAN switch, your core router, and your WAN router (and everything else in between, assuming of course that your LAN is entirely composed of Ethernet-based technologies). Your WAN router will accept the Ethernet frame on an Ethernet-based interface. The ASICs deconstruct the Ethernet frame to extract the TCP/IP packet inside. The TCP/IP packet's header give the WAN router the destination IP address of the TCP/IP packet. Gloss over the routing decision process. Also for simplicity's sake lets assume that your router connects to the Internet via one of a couple dozen methods that involve ATM. The WAN router now takes the TCP/IP packet and fragments it, stuffing the fragments into 53-byte ATM cells (48-byte payload). Toss in some POS, MPLS, etc, etc, yadda, yadda. And finally you more or less reverse these steps for the remote end. Again, we're glossing over a lot here. This is a little more technically accuratee than your summarization. The only time that I can recall Ethernet frames being fragmented and stuffed into ATM cells (complete with the Ethernet frame's payload contents) is some implementations using LANE.
But yes it is impressive how far things have come.