[this is a reprint of a blog entry in 2013 — and it is still applicable ]

Whiteboards and slides have been instrumental for networking discussions for a long time! Color-coding markers and those fancy “glass whiteboards” are awesome tools to have around whenever networking design discussions among network engineers arise.

Most of us are accustomed to quickly convey an idea using rectangles, circles and lines. Cloud pictures, which are almost a must-have in today’s system designs, are great examples of how we abstract or, should I say, hide or assume some concepts in designs. SDN network design diagrams are definitely not an exception in this regard.

SDN whiteboarding sessions often reference APIs, which are usually represented with innocent looking lines. As these lines begin making their way onto network engineers’ whiteboards, so do a slew of API acronyms – ones programmers have been using for years.

SDN has expanded the Network Engineer’s vocabulary, making typical programmer and sys-admin terminology necessary as they begin describing how to support today’s networks. Words like CORBA, SOA, REST, XMPP,  JAVA, OSGI and OpenFlow are joining the must-know list of words in addition to more well-known terms like Ethernet, BGP, EIGRP, OSPF, IS-IS, RIPng, MPLS, IPv6, VPNs, Class-of-Service, Multicast, SNMP, GRES and NSR.

But wait… What on earth is an API these days? 

Great place to start! The acronym stands for Application Programming Interface (API). In practical terms, APIs define the software-driven interaction among “systems.”

Within the context of SDN, the term “systems” mainly refers to applications, network processes, router nodes, switching nodes, firewalls, load-balancers or service servers (e.g. DNS, DHCP, RADIUS, etc.).

A critical differentiator of an API is the middle word found in the acronym – the “programming” feature of APIs. It is this programmable functionality that distinguishes and gives APIs their flexibility in contrast to other systems information exchanges. APIs allow a “system” to essentially ask or send a request or reply to information queries.

A huge benefit of an API is that it allows a querying system to “not care” about certain things like:

• knowing a remote system’s query commands
• how information is organized
• cli structures or restrictions in order to obtain information

A“querying” system just needs to know “the programmable way” of how to ask the remote system for information and how to read it. It is intended to be simple (like we all like it). And this is really the huge plus behind APIs.

As a point of comparison, in the past, there were non-API methods used to obtained information from remote systems such as “screen scraping.” Screen scraping occurs when one system remotely logs into another remote system, pretending to be a human user. Then, by executing commands as a user would, the desired information is displayed on the monitor. Once the remote system presents the information on the screen, the querying system is able to “read” it via coordinates.

The emergence of APIs was a long leap forward due to their flexible programmable nature as well as their security, directionality – unidirectional or bi-directional – and tunable synchronicity. Now, these API benefits are coming to a network near you!

In short, if an SDN implementation defines objects and attributes, the way to “expose” these to querying systems is via APIs.

But more specifically, what would be an object or attribute in the context of SDN networks?

We can think of SDN objects as interfaces, policies, protocols, virtual-instances and the like. Attributes are like states or values of these objects such as inactive, administratively down, BGP neighbor IPs (an IP address being attributes of the BGP neighbor), etc.

The “rules of engagement” for fetching networking information via APIs from a system (such as a router or a switch), are usually defined by how a system decides to expose such information via its APIs.

OK. This is essentially the SDN API concept.

Now we can readily see why APIs are arguably the “doors” to the SDN benefits. These benefits being: flexibility, simplicity and efficiency.

To clarify this point, consider this: If a system – like an application, router, switch, firewall, etc. – is very effective as a stand-alone system in doing what it does best, but it has poorly defined APIs; then, it is limited by how remote systems can interact with it. Consequently, an SDN implementation will most likely be limited. The “you-are-as-good-as-your-weakest link” warning would apply. In short, those “lines” representing APIs in SDN designs are very important design components!

Let’s go over a few SDN API definitions being quoted these days:

• SOAP: The Simple Object Access Protocol leverages XML structures for its message formats, HTTP and SMTP for message negotiations and exchanges, and RPCs (remote procedure calls) used for accessing remote procedures. SOAP APIs are common among languages that support web services, and since most operating systems support some form of web services, this makes SOAP a likely available API.

• CORBA: The good ol’ Common Object Request Broker Architecture. Yes… I say “old” because it was introduced in 1991. The goal is to allow different software modules to work with each other even if written in different programming languages. This goal is accomplished via – yet another – “Interface Definition Language” (IDL), as well as the implementation of “object request brokers” for each programming module. Thus, IDL-mappings to the different programming languages such as Phyton, C, C++ and Java are needed. CORBA could very well be the first clear origin of how APIs work today.

• REST: Called a Representational State Transfer API. The idea behind REST APIs is to “reuse and simplify” what is available in HTTP for client-server information exchange by using such definitions for system-to-system calls. This HTTP “re-use” simplifies the way REST APIs work given that HTTP is a proven and known protocol most programmers are familiar with.

• XMPP: The extensible message and presence protocol is an open standard originally used for jabber applications in support of real-time online communication. If you used Google talk, you used it. It is also based on XML structures. XMPP can either establish TCP connections or HTTP connections over which XML messages are exchanged.

• OSGi: It is an open standard framework intended to support java modules as a way to reduce complexity. An important benefit is that it allows for dynamic loading and unloading of Java modules supported by a series of Java interfaces. It was first conceived as an SDK and these days has expanded its extensibility.

• OpenStack: This not an API – (almost got you ? lol ) but just to make a comparison at this point – Openstack is more an ecosystem under the Apache software foundation with its own Networking API modules for multiple attributes for network objects. The Openstack network module (called “Neutron”)  essentially provides management of overlay virtual Layer-2 (or Layer-3) domains (called “virtual networks”),. subnets (either IPv4 or IPv6 addresses) and ports (virtual switch port or logical network switch). Openstack has APIs which are REST-HTTP-based API focused on the manipulation of the state of four networking objects.

The above list is in no way comprehensive – just common APIs found in the marketplace. SDN continues to be in such an evolving state that open and proprietary API definitions are also evolving. Networking vendors and open source communities continue improving existing ways of implementing APIs. Also, the above APIs are not mutually exclusive, and in fact, some SDN implementations make multiple APIs available. It all depends on how flexible a system is intended to be.

So where is OpenFlow on this list? This seems like a big miss given that OpenFlow has been all over the SDN literature lately.

Great point. OpenFlow is a term that has been associated with a few different concepts (probably the reason for much confusion). I would argue that OpenFlow is a “southbound” API for SDN system components – yes, essentially a Southbound API from a controller as defined today but there is no reason that it has to be only a Southbound API exclusively from a controller.

Currently, there are a few versions of the standardized OpenFlow API. However, there is competition for the Openflow API – such as using XMPP for implementing Southbound APIs. Nonetheless, Openflow is certainly placing itself as a strong contender as the de-facto Southbound API role.

To expand the same point with another example, it is possible to consider the static flow pusher “API”, which is actually a Floodlight I/O module exposed via a REST API definition. The static flow API allows a user to manually configure network traffic flows in an SDN network. The manual traffic configuration via this API has been often configured via Python code.

So, it is worth being careful when drawing those innocent-looking lines during SDN whiteboarding. They’re often not as simple as they seem when it comes to API definitions, associated protocols and system I/O modules.