OpenFlow is project coming out of Stanford University that offers a new way of using software to manage networks. The term “Software Defined Networking” sums it up. The question is whether OpenFlow will become mainstream. While Ivan at IOSHINTS isn’t so sure, I’m a bit more bullish. Here’s why.
There are a number of key aspects of OpenFlow that may help to cross the adoption gap.
The first is University networks are a perfect fit for this technology. Matt Davy from Indiana University has 4000 wireless access points and over 3000 switches in a single network – and managing the configurations on this network is a significant challenge. They see OpenFlow as a way to apply configuration more consistently to devices _anywhere_ in the network.
And the educational kudos that a University can get from adding it to the CompSci PhD and master students means that more Universities are likely to jump on board.
Note that OpenFlow can work alongside existing networks, it’s not a complete
In my experience, technologies that Universities adopt and deploy tend to move into the Enterprise. And because Enterprise networks are reluctant to adopt new technologies, but something that has been proven in Universities can offer a level of comfort, provided that the gains from the technology are significantly valuable to their business.
As protocol, TCP/IP isn’t very good at being billed. There isn’t any accounting data or extensions that assist telephone companies to charge by the packet. OpenFlow offers a framework that has opportunities for control, management and chargeback of data.
At Interop, there has been significant vendor commitment. NEC is showing their switches and controller in a powerful demonstration of OpenFlow functionality. I’ve seen a very cool demonstration from Juniper on their OpenFlow implementation on JunOS being controlled by a BigSwitch controller. Cisco is part of the ONF, and I believe has previously demonstrated a C6500 in 2008 with an R&D OpenFlow implementation.
It’s worth noting that existing software on networking products needs limited extensions to support OpenFlow today in the V1.1 form as the OpenFlow 1.1 specification is somewhat limited.
HP has contributed a QoS actions – En-queue on a specific queue and Rate limit using a specific meter – to OpenFlow and have a the only major vendor providing hardware since 2008 (I think) via the ProCurve 5400 switch.
KC: HP Labs developed the first commercial, hardware-based switch implementation of OpenFlow and demonstrated it with Stanford University at the ACM SIGCOMM conference in 2008. Today, HP has more than 50 academic and commercial researchers worldwide using our experimental software on HP’s current E8200zl Series, E6600yl Series, E5400zl Series, and E3500yl Series of switches. We are also a member of the Open Networking Foundation and will continue to be a key contributor and leader in advancing the standard.
Is this enough ?
OpenFlow is still a couple of years from being used in Enterprise Networks but I fully expect it to arrive. With University networks acting as proto-Enterprise deployments, and 3G/4G carriers looking for solutions to traffic management at large scale we could see a technology that is coming from the bottom up and top down.
With the Open Network Foundation now guiding the standards effort, and Indiana University offering interoperability testing, many of the process issues are also being addressed.
The EtherealMind View
I’ll write more about the technology in OpenFlow in the next couple of weeks, but frankly I haven’t been this giddy about a networking technology is a long time. Moving from managing a discrete element set of network equipment to software defined network with programmatic interfaces offers a huge step forward for your business.
If you want a simple metaphor, consider what VMware did for server – software management of server hardware and operating systems. OpenFlow is the same concept applied to network equipment, offer methods to shephard and manage our vast network sprawl.
Give me a large portion of that, oh yes.