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.