Category Archives: ON-SDN

Perspectives on SDN in general

The ABCs of SDN: A Conversation

Leave a reply

[This is a reproduction of a blog entry from 2013]

Ahh – technology hype can be exciting!

When a technology seems promising and looks like it could deliver a lot of benefits, it can exponentially gain momentum. This momentum can often be gauged by the attention it gets. There are so many tech talks, discussions, seminars panels, experts, forums, white papers and new acronyms (can’t live without them!) being mentioned that it can be a bit hard not to be overwhelmed trying to make sense of it all.

Software-Defined Networking is undoubtedly the latest craze in the networking world for both service providers and enterprises. It seems appropriate to succinctly review some basic concepts being thrown around “on the street” regarding SDN.

To keep it simple, I’ll use a conversation between two colleagues – one well-versed in SDN and one who is just hearing about it – to review the concept of SDN, how it changes the way your network functions and what it can do for your environment.

Here it goes:

J: Hi, Doug. I’m glad I ran into you. I’ve been meaning to start learning more about SDN but I have had no time lately to dedicate to it. So, maybe you can help me get going with a brief overview of SDN while we walk. Is that OK?

D: Hi, John. Certainly.

J: Great. Let me start with the main question: What is this SDN stuff everybody is talking about these days? Google reports plenty of links when searching for definitions of the SDN acronym.

D:  Not surprised. SDN in our field stands for Software-Defined Networking – three letters that represent the new “radical” change that networks are experiencing. You know how network vendors have roadmaps for their products, and they quote them often with new “incremental” features or improvements for their line of products?

J: Yep, I know those roadmaps. Quarterly reviews full of goodies and solutions to come…it is in the next release, etc. etc… Yep, I know.

D: Well, those could be considered “incremental changes” to a given product. SDN is not an incremental change – it is more like a disruptive or radical change. A departure from how networks have been deployed for the last few decades.

J: And what is so “radical” or “disruptive” about it?

D: The radical and disruptive part of SDN to current networks is this: SDN changes how networks have been “controlled” as well as how each “node” (like a router, a switch, a firewall, etc.) has been conceived ever since we can remember. It also changes how networks are to provide services. It still involves both software and hardware but, to use a sports analogy which might work, the software and hardware players on the SDN team are now changing the way they implement their role done given a different, more effective game strategy.

One critical component to the SDN recipe is network programmability. Other components include APIs and network protocols. And yet another is hardware. To achieve network programmability, APIs are needed. To move information across the network, protocols are needed. And even though there is plenty of virtualization going on, hardware in the form of physical nodes and interfaces is still needed.

J: It sounds like there are a lot more components to SDN than the current network designs use. Is it worth it?

D: True, there are more components to SDN which could potentially imply more moving parts and failure points. However, the promise of SDN is that networks can be simpler to use and manage from a user perspective. Keep in mind that users in this case referred mostly to applications – not only humans hacking away at the network – Applications are the “royal family” in the SDN society.

So, the SDN promise is that new services can be created, deleted or updated very quickly (within seconds) and with minimal complexity to the user requesting those services all while still preserving the benefits that networks need to offer – fast failure restoration and reliability and efficiency in moving packets from sources to destinations.

J: Network programmability, eh? How would a network be programmed? Aren’t we programming today via CLI when we configure routers and switches? And haven’t we been programming the network gear for years?

D: Well, yes…but not exactly. What we have been doing is configuring each network node in a network using the vendor’s own operating system for each particular node. Each of the nodes is configured to run available networking protocols. Each node is treated as an independent and standalone system that needs to interact with the other entities in the network. In order to speed up the configuration of each of these nodes, management systems have been used, but these have not been widely adopted for various reasons.

The main difference in the SDN network programmability is that fast, simple commands can be used at some central level and service deployments are successfully completed. This programming is to be flexible enough that it can actually be successfully accomplished by other systems or individuals who may be unfamiliar with networking protocols. To get to this point, the “hardware” involved in the network is being treated not like standalone entities but more like servers waiting for control commands from a higher controller system.

J: I see. So, SDN is not really a protocol but rather more like a systems programming architecture where the network hardware nodes are just one system. What about the API’s component of SDN? What are those for?

D: APIs are well known concepts to system programmers. They are software components defining the data and the conditions under which such data can be properly processed by a given system. Since SDN is a centralized architecture where the network control is now in a different system and outside each of the network nodes (routers, switches, etc.), these systems need to interact among themselves in a cohesive, harmonious manner. The way they interact and exchange information among themselves is via APIs.

J: What are some examples of APIs from SDN?

D: SDN is such an emerging technology in networks that many things are still in the exploration and evaluation phase. APIs are definitely one of the things that SDN adopters will experiment with in the near future. Three API protocols being used are NETCONF, REST and XMPP.

Just to review, NETCONF (Network Configuration Protocol), which surfaced in the mid-2000s, uses XML as its base and uses Remote Procedure Calls (RPCs) for data exchange between two systems. NETCONF runs on top of secured connection protocol such as SSH. REST (Representational State Transfer) uses the main HTTP methods at its core for exchanging information. Lastly, XMPP, also based on XML, is the same protocol used for multi-party chats and instant messaging apps such as Facebook chat and Jabber, and other popular applications such as Twitter also have XMPP-based APIs available for external developers . XML gives a lot of flexibility to APIs given that extensions allow new functionality to be easily created. XML can be mainly seen as a “southbound” API – if we were going to get into API details – which is a great topic to discuss regarding SDN. Also, keep in mind that extensions often mean a lot of flexibility. Remember BGP and MBGP in our networking industry and the value offered by BGP-with-extensions?

J: Yeah, great flexibility based on extending BGP’s attributes… by the way, what about OpenFlow. I usually hear it mentioned along with SDN? What is it?

D: Awesome question. OpenFlow definition has caused quite a bit of confusion in the past. In short, it is one protocol and a component with a specific role in the overall SDN architecture for networks. OpenFlow’s important role in the Open Networking Foundation’s SDN definition, which, in simple terms calls for the separation of control and management functions from the data plane functions. In short, it removes the control functionality from each of the nodes and places this control functionality in a more centralized “server”; arguably, playing a role of traffic director in network elements. Consequently, the network node roles (routers and switches) are essentially in charge of moving bits in and out of them as fast as possible while taking control orders from a higher authority – the controller. This abstraction is brought about by the implementation of the OpenFlow model.

J: Ahh…Got it. That makes OpenFlow like a set of protocols and APIs.

D: hmm… more like a Southbound API.. at least for now…who knows how it will evolve in a few years…

J: Where can I find more info on SDN to start getting deeper into this new… should I say… paradigm?

D: There is plenty of literature out there, and the first few books are starting to make their way to the marketplace. Take a look at Jeff Doyle and Doug Marschke’s book Software Defined Networking: Anatomy of an OpenFlow. They are well-known authors in the networking world, and their years of experience as engineers provide a unique perspective.

J: Thank you for this chat. It gave me a kick start to get me going with SDN.

D: Absolutely. Let me know when you want to get deeper into details.

SDN APIs: A New Vocabulary for Network Engineers ?

Leave a reply

[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.