SDN APIs: A New Vocabulary for Network Engineers

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, OPENSTACK and OSGI 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 system 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 benefits of the SDN. 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 applies here. 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 API is part of the Apache software foundation under the Networking API modules with multiple attributes for network objects. It essentially provides management of isolated virtual Layer-2 domains (called “networks”), subnets (either IPv4 or IPv6 addresses) and ports (virtual switch port or logical network switch). It is a 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 systems 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 continues to be a set of system components, including a controller, a protocol and API definitions (northbound and southbound) intended to work together – not being only an API.

Currently, there is no API standardized for OpenFlow. The OpenStack API is certainly placing itself as a strong contender for that role.

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

So, be 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.