Good News: I’ve Defined the High-Level SDN API, Bad News: Nobody Cares

Some of Cisco’s bigwigs have been talking SDN at the Cisco Tech Editor’s conference, and the sum of their perspectives validates our view that Cisco’s plan for SDN is to seize its benefits without embracing much of its technology.  Before you decide I’m off on another rant, let me add that I think that’s perfectly fine.

Before Cisco started singing its SDN tune, the whole SDN movement was a technology in search of a value proposition.  We were hearing about goals like “separate control plane” or protocols like “OpenFlow” but we weren’t hearing much about business value, or even about how software was doing all this network-defining stuff.  Cisco has stepped up and put some substance around the top of SDN, and as I blogged at the time that’s a good thing.

There are, they say, many ways to skin a cat, and Cisco found (or knew all along) that it would be possible to meet SDN higher-level goals without doing anything much to the way that routers in particular behave.  In fact, they found that if you do some extensions to current Internet protocols like BGP you can make an argument for more routing in the future by making it easier to drive specific network behaviors through current network technology.  The thing that’s still at least vague if not missing in Cisco’s vision is the details on the software-to-“SDN” interface.  Exposing all of the current network features in a bazaar-like hodgepodge of APIs isn’t going to make software control possible, it’s going to make network stability questionable.

Alcatel-Lucent is expected to make an SDN announcement on April 2nd, and Light Reading is reporting it will likely integrate Network Functions Virtualization (NFV) as well.  They also reported on a financial-industry report that’s asking whether NFV might have an impact on the network equipment market.  Good question, not only for NFV but for SDN, and the big step needed to move toward answering it is the step of defining that central process.

The logical template for everyone in the SDN and NFV space to use as their “descriptor” or high-level APIs is OpenStack’s Quantum interface, not because Quantum has all the answers but because 1) Quantum is likely to represent a cloud’s-eye view of SDN service requests and 2) what Quantum doesn’t do well can show us what the best complete strategy would look like.  Quantum focuses on creating an “application network”, meaning one that can host applications and then offer application services to the masses.  The logical model is a subnet (a virtual LAN) that includes IP-addressed entities and the service components above the network (DHCP, DNS) that make the application network a part of the glorious IP whole.  Obviously we can’t have SDNs that are only part of IP networks or that obey a pure subnet model because we have demonstrations already (Google in the IP core, Ericsson in the metro) that don’t fit that model.

Cisco, Alcatel-Lucent, Ericsson, and pretty much everyone are committed to Quantum, and so it seems to me that everyone should be speaking out and promising to bind their vision of SDN via high-level APIs to the Quantum interface.  That at least would make SDNs work as cloud application hosts.  It also seems to me that all these players would recognize that we need to be thinking about all the services SDNs might offer, which means all the service models.  We know of three connection topologies, for example; LINE, LAN, and TREE.  Why not start by defining three connection models, and then define a series of “service models” (IP, Ethernet, whatever) that ride these connection models.  At that second level you can start to define components like DHCP that are needed for the service you define.  You could also look at introducing NFV “virtual functions” where they are appropriate to a service level, as a firewall would be to an IP service.

Taking things to this level would define a simple high-level SDN API.  Think of it as being a command that looks something like this:

BuildSDN(connectionModel, serviceProtocol, endpointList)

So you tell me—is this not an example of a useful highest-level description of an SDN service?  Does it not easily take us to the next level, which is defining what it takes to create the connection model and extend the service protocols to the listed endpoints?  Could application developers use an interface at this level?  If all of this is true, and I think it is, then you have to wonder how we’ve avoided saying something so simple as this for all this time, and how we’ve thus avoided drilling down from need to implementation in a useful way.  It’s time to make all these SDN players start at the top.

Leave a Reply