SDN Is Business, OpenFlow Is Technology
November 15, 2012
The northbound APIs from the services to the controller aren't defined yet. I see three reasons. First, big vendors haven't been able to hit on use cases that are substantial enough for them to invest in. Second, only a few controllers have come to market, and they have yet to be proven as robust platforms for production traffic. Third, different applications may need different APIs to the controller depending on their requirements. For example, a firewall application may need a high-performance, low-latency, low-complexity data exchange, while a monitoring application might only need to read flows as they pass.
The industry is working on different options. It seems likely that there are forums within the ONF that will start to deliver some guidelines in the near future, and the IETF has published a draft from the Network Working Group on the topic.
- Closing the Book on Windows Server 2003: Planning for Windows Server 2012 Opens New Possibilities
- Deeper Network Security: Protection Tips Revealed
- Forrester Study: The Total Economic Impact of VMware View
- Beyond Native Tools: Auditing SharePoint Across the Enterprise
The lack of a standard API means software developers have to decide which platform they will develop for. Does F5 develop for a Cisco or a Big Switch controller? What about a security company developing a firewall for OpenFlow? Would they choose the HP OpenFlow controller or the IBM version? The northbound API must be standardized at some point, but the format, performance and data structures are probably not well understood. There will be more to come on this topic.
Where the Pieces Fit
When examining the difference between OpenFlow and SDN, consider their position in the infrastructure. OpenFlow is a technical-to-technical service because it links the controller and network devices. It's not visible to users or to the business. By contrast, SDN is a business-to-technology interface. SDN presents services to users and the business before transforming them into abstractions that the controller can translate into network actions.
And now we have reached the point where we can talk about the revolution in networking. We don't have SDN in today's networks. Today's "network management" platforms are insufficient and fail to provide visibility and control to network owners. Most of this failure is due to the limitations of the SNMP protocol, which is the only standard method for extracting data from the network (although some tools have attempted to extract data from the command line interfaces).
Business and Technology Platforms
SDN has a complete set of abstractions from the physical and virtual networks. The southbound APIs have a well defined basis in OpenFlow and NETCONF that gives developers confidence that products are not limited to just a single vendor. And the market is moving to converge on northbound APIs in the next few months. Look for a lot of marketing and innovation from SDN vendors. This innovation will take the form of controllers and applications.
Vendors have announced OpenFlow supports in their physical devices and virtual switches such as Open vSwitch and Cisco Nexus 1000V. The next move in the market place is to identify OpenFlow controllers and applications that will deliver services to the business. That's already started to happen. As mentioned earlier, Big Switch Networks announced two applications along with its OpenFlow controller. HP has announced applications that should be available in 2013. As more applications start to arrive, SDN adoption will grow.