Subscribe to our Resources Blog RSS feed to stay up-to-date on latest news.
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:
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:
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.