Big Switch, one of the most active and interesting of the OpenFlow players, has announced a number of new things that may help the market better understand the value of OpenFlow. In particular, they help understand how OpenFlow might be used in conjunction with “normal” network protocols.
To start with, it’s important to understand that OpenFlow forwarding is kind of protocol-neutral, meaning that since the forwarding tables are explicit there’s no control plane context that things have to fit into. You can use this feature of OpenFlow to create new switching/forwarding models that escape the whole adaptive-discovery thing, but you can also use it to augment normal networking, and thirdly to “squash” OSI networking down to a single layer.
The Big Switch announcement is about improved virtualization, and here the goal is to use OpenFlow in a kind of “roundhouse” role to link the physical resources of a virtualized data center or cloud to the logical address space that’s expected by users. If this is properly done, it elegantly solves the problem of managing the reachability of cloud elements. Similarly, it could be employed inside a CDN to address content.
To make this work, you need to be able to interwork between OpenFlow forwarding and traditional networking. Think of every “logical resource” as a central point in our roundhouse, with each position of the turnstile linking that logical resource to a physical one. Or vice versa; one beauty of OpenFlow abstraction is that you can look at most relations symmetrically. But anyway, Version 1.3 of OpenFlow makes the process of interworking more efficient by handling tunnel encapsulation better.
The Big Switch announcement also illustrates the most overlooked and important point in OpenFlow, which is that the standard “Controller” function is really a stub that connects a source of connectivity requirements with a forwarding device. Something higher up has to understand the applications’ needs for connectivity and translate that into a form that can drive creation of paths through successive forwarding table entries. Big Switch is developing these applications, and it’s here that the company’s unique value will have to be created (because the lower level is all open source).
The “squash OSI flat” model is something that Big Switch is looking at/working on but for which there’s no specific announcement. Here the notion is that if “forwarding” is really decoupled from “control” and “applications”, then it should be possible to take all of the decoupled non-forwarding elements and squish them into a single functional entity. Instead of having multiple layers of protocol, which in many cases are all trying to provide common things like fail-over in an independent way, you now have a super-control function that sees the Glorious All of the network and that then exercises coordinated forwarding changes that happen to be in what the OSI world would have called “different layers”. Except there’s no real difference now.
The new vision Big Switch is articulating is less a fork-lift acceptance of OpenFlow than a kind of camel’s-nose creeping commitment. Create missions where it clearly shines, enough to justify using it as an overlay. Over time, as these missions grow and new ones are added, expect the size of the OpenFlow overlay to increase, and eventually for the boundaries to touch and the network become almost totally OpenFlow.
An interesting angle on SDNs yet to be fully explored is their relationship with CDNs, meaning content delivery. There has been a wave of announcements on the content and mobile content space, ranging from Netflix’s roll-your-own approach to Citrix’s buy of Bytemobile, but I wonder if all of this might not be taking second seat while the first chair is still open. If SDN principles really enhance traffic engineering then mobile EPC and CDN applications should be perfect for the application of those principles.