Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Slashdot Deals: Deal of the Day - 6 month subscription of Pandora One at 46% off. ×

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."
This discussion has been archived. No new comments can be posted.

An Interview With The Router Man

Comments Filter:
  • Re:I'll say it again (Score:4, Informative)

    by Intron (870560) on Thursday March 30, 2006 @05:47PM (#15030378)
    Look at RFC 675: 16 bits: Destination TCP address

    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.
  • by CrazedWalrus (901897) on Thursday March 30, 2006 @05:51PM (#15030409) Journal
    I'd like to agree with you about the grandparent post, and add a few thoughts, if I may.

    I saw Heron of Alexandria [] 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)

    by C. E. Sum (1065) * on Thursday March 30, 2006 @05:56PM (#15030432) Homepage Journal
    Yeah... But he was specifically talking about IP (As opposed to TCP/Arpanet or whatever). The earliest IEN I can find a softcopy of (111, from 1979) refences IP as 32bits (and at "version 4").
  • by slashdotmsiriv (922939) on Thursday March 30, 2006 @06:23PM (#15030619)
    "Just think of an ethernet frame fractured into ATM frames, put into TCP/IP and and sent over the internet, and then having to be converted back."

    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)

    by Anonymous Coward on Thursday March 30, 2006 @06:29PM (#15030655)
    Stanford's 3MB Ethernet started out using Pup, which was 16-bits (8 bit net and 8 bit host address). The Pup address also function as what we know today as the MAC address.

    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 Idol_Handzz (784370) on Thursday March 30, 2006 @06:50PM (#15030808) Homepage
    I get my Network World every week like clockwork, and they seem to accumulate somewhere around my desk in a little pile. This article caught my eye, and I read it from start to finish twice. It was really quite fascinating. I understand routing, and while it is fairly simple these days, I can't imagine trying to code the first one. There was nothing to base anything on. He didn't just write the code, he invented the theory, tested it, and proved it could work.

    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
  • by macdaddy (38372) on Thursday March 30, 2006 @10:57PM (#15031809) Homepage Journal
    We have come far. However your order of encapsulation steps is a bit off.

    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.

"Love your country but never trust its government." -- from a hand-painted road sign in central Pennsylvania