I’ve always wondered whether the Open Networking Foundation is the correct caretaker of the standards process for Software Defined Networking. Recently, we’ve seen some questioning of the direction of those standards on OpenFlow, and, now that we are beginning to understand the concepts of controllers, Software Defined Networking these are good questions to ask. it shows that we are moving to seriously consider the technology.
Michael Schipp asks on the Packet Pushers blog – Is OpenFlow Losing Its Openness?:
…a comment from Nicira’s Casado that was written last spring, “you most likely will not have interoperability at the controller level (unless a standardized software platform was introduced).”
And (following a vibrant exchange on Twitter), Brad Hedlund asks whether Nicira’s Open vSwitch is open – Dodging open protocols with open software ?
The story being that of open source networking software minimizing the role of network “protocols” and the diminishing role of standards bodies in building next generation networks.
He makes a good point – are companies using what looks like open standards to produce closed or proprietary systems ?
There are several lines of thinking that lead away from these points so this post kinds of wanders over several areas. Permit me to make a few points.
OpenFlow, Controllers & SDN
Lets recap some basics since OpenFlow/SDN is still new to many.
The purpose of a controller is to provide the following:
- A user interface for configuration of the network.
- A platform for applications that define the configuration of the network.
- Deliver the configuration to network – most likely using OpenFlow but could be SNMP, NETCONF or other protocol.
- Provide the feedback loop and administration of the operational network.
Anyone who has designed and managed a wireless LAN will very familiar to this process.
Nicira and their “Open” Open vSwitch” – Controllers aren’t new
From what I can read & understand, Nicira is using controller based network management system to manage a software switch that uses flow forwarding. This principle is similar to an SDN/OpenFlow design. It’s also conceptually similar as Embrane, and most Wireless LAN networks. And lots of other network technology in history ( such as IBM 3745 FEP network). But that’s where the similarity ends (more on that here).
Nicira isn’t delivering a revolution here, they are filling a rather obvious niche in software networking. VMware & Microsoft haven’t delivered anything useful in their products so there is a big space for an early mover.
Another point is that I don’t think OpenFlow 1.x standards don’t provide enough functionality or features to be used for software switching. Could be wrong here but it might be likely that ONF is moving slower than Nicira would like so they are moving ahead of the ‘standard’.2
Open Networking Foundation
Personally, I think that the OpenFlow protocol and Software Defined Networking is a great idea. But, I have strong concerns about the leadership of the Open Networking Foundation since it’s effectively managed and owned by large, mostly American corporations – Google, Yahoo, Verizon et al. These companies have very narrow interests in the use of the OpenFlow for their hyper scale data centres and it’s easy to question their motivations and whether their “leadership” will benefit the network community as whole. The word “cabal” comes to mind with all the negative connotations therein.
So far, there my opinion is that there are few “signs of evil” but only time will tell. OpenFlow is not an open protocol like the IETF, or even ANSI 1
State of OpenFlow
At this point, the standards process for defining OpenFlow is all hung up. Big companies want the things that they like, the university people are all sticking their noses in, and the incumbent vendors are struggling to either embrace or adopt yet another network transition.
This means that the standards process will be ……. hard. There are no procedures for dispute resolution, or open debate, etc because they are a new organisation that has no bureaucracy or structure.
The state of OpenFlow is not good.
Comparing OpenFlow to other Protocols
Finally, I want to compare OpenFlow to another industry standard protocol – SNMP. It’s probably worth remembering that SNMP has some functional similarities to OpenFlow. SNMP describes a protocol, which uses the Structured Management Interface (SMI) to fetch data contained in the Management Information Base (MIB).
The SNMP Protocol is open, as is the MIB and SMI data structures they contain in ASN.1 notation (hope I got that right).
However, Network Management software that uses SNMP is not open. Network Management Systems(NMS) are all proprietary and rarely, if ever, exchange data with other systems in a meaningful and open way. Have you every attempted to integrate BMC Patrol with anything ?
For all practical terms, an NMS server is a network controller but not for configuration data. NMS are used as controllers for performance and fault data only. That’s a fine distinction, but an NMS is almost never used to configure the network because SNMP isn’t able to handle that.
So when Michael Schipp asks Is OpenFlow Losing Its Openness? I would have to question the concept of open. SNMP is open, but NMS are closed and data is sequestered into closed data silos.
Do we want Controller – Controller interoperability ? Absolutely. But the organisation that could organise that does not appear to be ready, or perhaps capable, of doing that.
The bigger, and much more challenging topic is what sort of controller interoperability do you want ? At this stage of development, there are less than five viable controllers of which only one is commercially available3. And the technical discussion continues about Active/Standby, Clustered or Hierarchical controller designs will be most suitable. It’s difficult to think about interoperability when you still haven’t finalised the best software architecture.
And with OpenFlow led by companies like Google/Yahoo for data centres, and Verizon/AT&T for Service Provider, will they even consider what Enterprise networks want ? At this stage, there are campus OpenFlow implementations at Universities ( such as Indiana University) but whether it’s suitable for corporate/enterprise I can’t say.
The EtherealMind View
Lets say that it’s too early to expect much from Software Defined Networking. A year ago, it was a good idea that showed some promise. The people who led it’s development have chosen to create a new body to define standards and guide development – fair enough, it’s their idea for now. It remains to be seen how that will work out.
My view on interoperability is that we will need usable and working systems before we can consider interoperation between controllers. It’s too early to call proprietary when there are just four or five first generation controllers available today.
It’s up to customers to ask the vendors (now or future) and demand compatibility and drive interoperability. Don’t expect anyone else to do it. Keep writing, blogging and twittering about it so that vendors know it matters. Standards are driven by what we ask for, otherwise vendors will take the easy path and deliver what’s easiest for them. And that’s proprietary, closed systems.
Update – 20130902
As a result of questions, the current state of SDN standards is largely being driven by the OpenDaylight project. Because the OpenDaylight project has participation from nearly all of the vendors and contributing code to build a functional controller. Cisco and IBM have been contributing heavily which has seen a number of odd standards being added to SDN like LISP and PCEP. Still, a working standard creates its own mass and attracts others to it. I’ll take standards from ODP because I can use them and not have to put up with the foolishness of organisations like the IEEE.
The ONF will continue to define OpenFlow and hardware standards that vendor needs – as least, that’s how I see it.
- although that’s a stretch because ANSI exists for American Standards, not everyone and well known for it’s “convenience”. ↩
- Same argument had regularly with critics of Cisco’s proprietary first, standards later. Cisco tends to say we precede standards because it takes time to complete them. Sometimes, they have to create a need for the standard to happen. I will accept your reverse arguments as also valid, I’m just making a point. ↩
- NEC and ProgrammableFlow. Has hardware too. ↩