SDN/SDDC Retreat in Miami, Florida (November 4th-6th)
Separate SDN hype from real life!

SDN Controller northbound API is the crucial missing piece

Imagine you’d like to write a simple Perl (or Python, Ruby, JavaScript – you get the idea) script to automate a burdensome function on your server (or router/switch from any vendor running Linux/BSD behind the scenes) that the vendor never bothered to implement. The script interpreter relies on numerous APIs being available from the operating system – from process API (to load and start the interpreter) to file system API, console I/O API, memory management API, and probably a few others.

Now imagine none of those APIs would be standardized (various mutually incompatible dialects of Tcl used by Cisco IOS come to mind) – that’s the situation we’re facing in the SDN land today.

If we accept the analogy of OpenFlow being the x86 instruction set (it’s actually more like the p-code machine from UCSD Pascal days, but let’s not go there today), and all we want to do is to write a simple script that will (for example) redirect the backup-to-tape traffic to secondary path during peak hours, we need a standard API to get the network topology, create a path across the network, and create an ingress Forwarding Equivalence Class (FEC) to map the backup traffic to that path. In short, we need what’s called SDN Controller Northbound API.

There is no standard northbound API

I have some bad news for you: nobody is working on standardizing such an API (read a great summary by Brad Casemore, and make sure to read all the articles he linked to).

Are you old enough to remember the video games for early IBM PC? None of them used MS-DOS. They were embedded software solutions that you had to boot off a floppy disk (remember those?) and then they took over all the hardware you had. That’s exactly what we have in the SDN land today.

Don’t try to tell me I’ve missed Flowvisor – an OpenFlow controller that allocates slices of actual hardware to individual OpenFlow controllers. I haven’t; but using Flowvisor to solve this problem is like using Xen (or KVM or ESXi) to boot multiple embedded video games in separate VMs. Not highly useful for a regular guy trying to steer some traffic around the network (or any one of the other small things that bother us), is it?

Also, don’t tell me each SDN controller has an API. While NEC and startups like Big Switch Networks are creating something akin to a network operating system that we could use to program our network (no, I really don’t want to deal with the topology discovery and fast failover myself), and each one of them has an API, no two APIs are even remotely similar.

I still remember the days when there were at least a dozen operating systems running on top of 8088 processor, and it was a mission impossible to write a meaningful application that would run on only a few of them without major porting efforts.

Let’s speculate

There might be several good reasons for the current state of affairs:

The reality is probably a random mixture of all four (and a few others), but that doesn’t change the basic facts: until there’s a somewhat standard and stable API (like SQL-86) that I could use with SDN controllers from multiple vendors, I’m better off using Cisco ONE or Junos XML API, otherwise I’m just trading lock-ins (as ecstatic users of umbrella network management systems would be more than happy to tell you).

On the other hand, if I stick with Cisco or Juniper (and implement a simple abstraction layer in my application to work with both APIs) at least I could be pretty positive they’ll still be around in a year or two.


  1. Yes, it's a true story what you say, it seems like we're back in 80's and the problem of standardization of programming languages i.e.
    One organization needs to take place over here and start a standard for all the following SDN APIs. It happens to C before ANSI C reach us and now it's happening here.
    Other solution could be a compiler (like gcc) for all the platforms that want to support SND (joking but it wouldn't be strange at all that someone think in this as a possible solution).
    Thanks for share to the rest of the world this enormous problem that no ones cares about.

  2. Hi Ivan,

    Please can you briefly explain "umbrella network management" for those people like me that have not heard of this before.

    Thank you,


    1. Google for the "umbrella (network)? management system" and read the fine white papers you get in the results. You'll get the idea ;)

  3. Nice post Ivan, reading it really got my wheels turning on something. If the attempt at southbound standardization falls apart, the Northbound primitives would be the last stand but in some miracle that the NB API became homogenous across vendors it could still be crushed on the whim of a vendor controlling the API or DK. Hell Twitter sorta did that a couple of weeks ago.

    I think people are and will be more so interested in OF or anything standard as soon as products start getting developed. Few can manage DevOps or the buzzword coming out now NetOps. Haven't we had NetOps for years? How much silicon can vendor x y z convince us is needed in edge equipment is something I am wrangling with. I reckon Quantum is I think the first NB "ecosystem" api, and that came from grass roots, maybe it is doable. In that case the Quantum API is only as effective as the vendors commitment to developing product hooks into their gear which are all wildly different. Anything but horizontalization. Great post!

  4. Ivan, I believe Cisco has OnePK to address this, correct?

    1. I had OnePK in mind ... and to be precise, Cisco has announced it will have OnePK. Haven't seen it yet.

  5. Nice blog.
    I agree that it would be highly desirable to have the API’s published but I’m not sure it’s critical to standardize them. We don’t have standard API’s across any type of operating system today (server, PC, tablet, smartphone), so one could argue why it should be done only for network o/s’s. API’s related to OF will likely converge to some extent and apps will figure out a way to be portable across multiple controllers.

    I’m sure no controller vendor wants to remain just the "man-in-the-middle". The apps provide the real value and every controller vendor will therefore want to have their own apps. Maybe that’s what’s holding back publishing of the APIs. Of course the reasons you’ve mentioned likely hold as well.

  6. Since we are entering software world, then why not use the standard software methods to get around multiplicity of APIs. We need an App Server on top of controllers that interfaces with the various controllers and offers an IDE to the developers essentially hiding the controller eccentricities from the app developer.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.