Assuming we forget the ONF-promoted definition of SDN and define SDN as “network programmed from a central controller”, it’s obvious we had SDN for decades, starting (at least) from the early 1990s.

We Had SDN in 1993 … and Didn’t Know It

I had three SDN 101 presentations during last week’s visit to South Africa and had tried really hard to overcome my grumpy skeptic self and find the essence of SDN while preparing for them. As I’ve been thinking about controllers, central visibility and network device programmability, it struck me: we already had SDN in 1993.

In 1993 we were (among other things) an Internet Service Provider offering dial-up and leased line Internet access. Being somewhat lazy, we hated typing the same commands in every time we had to provision a new user (in pre-TACACS+ days we had to use local authentication to have autocommand capability for dial-up users) and developed a solution that automatically changed the router configurations after we added a new user. Here’s a high-level diagram of what we did:

Internet service provisioning architecture from 1993

Internet service provisioning architecture from 1993

HTML user interface (written in Perl) gave the operators easy access to user database (probably implemented as a text file – we were true believers in NoSQL movement in those days), and a back-end Perl script generated router configuration commands from the user definitions and downloaded them (probably through rcp – the details are a bit sketchy) to the dial-up access servers.

Next revision of the software included support for leased line users – the script generated interface configurations and static routes for our core router (it was actually an MGS, but I found no good MGS images on the Internet) or one of the access server (for users using asynchronous modems).

How is that different from all the shiny new stuff vendors are excitedly talking about? Beats me, I can’t figure it out ;) … and as I said before, you don’t always need new protocols to solve old problems.

Latest blog posts in What Is SDN? series

5 comments:

  1. You're the best Ivan! Perl ran a lot of networks, let's be honest...
  2. I try to separate "SDN" and "Network Automation." Automation has been around for decades now and I'd put this one under that, not necessarily SDN, even though people seem to like to spin it as SDN. SDN to me is driven by dynamic variables including applications.

    Now back in the mid-90s we did have RADIUS options controlling things like L2TP tunnels to redirect users to a certain path like walled gardens, web-filtering boxes, etc. Maybe you could call that SDN? Still a tortured interpretation IMHO.
  3. "We Had SDN in 1993 … and it didn´t make it" ;)
  4. We also had "cloud" computing in 1993-1995 Novell teamed up with AT&T to host Novell servers and lotus notes service from AT&T connected via frame relay.
    Worked then but slow fat protocol over thin VCs.. But it was touted in the old rags back then. How funny,
  5. There is a point here, this stuff is not "new". What about GSMP, MSF, FORCES, and even MEGAGO (diff. use context), etc. 10+years ago efforts, some of which are still superior in many ways (in terms both architecture, functionality and to the current "new" OpenFlow does it all for you BS ? For Stanford folks to market this as a new invention of theirs and take credit is ignorant and irresponsible - folks like Nick Mckeowns surely remember the previous attempts. The key problem with the industry is that everyone seems to have a self appointed "right" to come up with "new" protocol/interfaces for old things, and call it solution. No wonder folks get frustrated on the height of the RFC and other spec pile.
Add comment
Sidebar