Router man

The creator of the multiprotocol router reflects on the development of the device that fueled the growth of networking.

William (Bill) Yeager is 66 and still gets peeved when someone trots out the Silicon Valley fable about how the founders of Cisco invented the router. He was the guy at Stanford University that made it happen. The history of Network World roughly parallels the commercialization of routing, so we tracked Yeager down for a glimpse into the scene back then.

You're credited with developing the first router while you were a staff researcher at Stanford. Tell us the tale.

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.

What kind of gear did you need to connect?

We had mainframes, of course, DEC10 Systems, a number of Xerox PARC Lisp machines, Altos file servers and printers, and over the next year or so added DEC VAXs, Texas Instruments' Explorers and Symbolic systems. All of these things had to be hooked together, because we were spread across buildings on campus, and people were tired of carrying tapes around.

I thought about this for a bit, and I said, well really what you need is an operating system. So while the cables were being pulled and tested, I developed a network operating system [NOS] and routing code [to run on a] DEC PDP11/05. But the Alan Snyder Portable C compiler generated too much code. So I had to go into the compiler and improve the code generators. And that wasn't even good enough. So then I had to write an optimizer for PDP11/05 assembler so I could reduce the code by about 30%. This was major engineering, because you had your hands into everything. It's important to remember the PDP11/05 only had 56KB of user memory, and was diskless.

The struggle was always a balance between how many input buffers you could have. You really had to squeeze things, because there was no disk and if you ran out of memory for input buffers you were dead in the water. So you had all of these constraints, which actually had a lot to do with how good it ended up being, because I had to do a lot of work to both assure the memory allocation algorithms would never run out of memory, as well as get things scheduled right. I spent an entire summer making sure the NOS scheduling and packet-switching algorithms were optimal.