WTF is SDN?

Buzzword alert! Like “Cloud” before it, “SDN” is quickly becoming all the rage, and, just like your favorite Gotye song – it’s overplayed. Also like “cloud”, SDN has some potentially very interesting (if not entirely new or well defined) implications. More and more folks are bandying the acronym about and only some of them seem to have any clue. So, of course, I’ve finally broken down and decided to start chiming in on the subject (I leave judgement on whether or not I have a clue to you – please feel free to call me out where I’m wrong).

In this first-for-me post on SDN I will try to take a pragmatic look at what SDN actually is. I then plan to dive into some more details and deeper analysis in future posts.

So, WTF is SDN?

SDN in our current context stands for Software Defined Networking, although some are using the acronym to mean Software Driven Networks. Either way, what we are talking about here is network programability; the ability for networked applications (software) to more directly interact with (and control) network elements (routers, switches, etc.). Some believe that this is the “Third Epoch” of computer networking, while others see it as “an emerging concept that proposes to disaggregate traditional vertically integrated networking stacks to improve network feature velocity or customize network operation for specialized environments.”

Let’s look at some examples to help illustrate the SDN concept:

OpenFlow

OpenFlow (OF) kick-started this recent hype and thus should serve as a good example of what SDN might mean. According to the Open Networking Foundation (ONF – the current home of the OpenFlow specification): “OpenFlow enables networks to evolve, by giving a remote controller the power to modify the behavior of network devices, through a well-defined ‘forwarding instruction set’.” In other words, OF defines an interface between an external controller and a network device. It was originally developed by researchers to allow them to run experiments on a live network without disrupting production traffic. It is now being played with as a method to supplant internal control-planes altogether. OF can completely decouple the software that controls routing and switching from the hardware that does the actual forwarding.

The broad results are fourfold: First, this has the potential to allow commodity switching hardware to replace expensive, proprietary network devices and to allow commodity compute platforms (the “cloud”) to take over control operations – thus reducing the overall cost of networking (maybe – you still need high efficiency hardware and complex software, you just don’t have to buy them together). Second, this decoupled control-plane-in-the-cloud has the potential to interface directly with applications (think order, fulfillment, and assurance systems first, then maybe Angry Birds later) – thus reducing human intervention and increasing service optimization. Third, once you’re running “standard” software to control your network, the potential to add features and functionality expands; standard interfaces allow third parties (or internal developers) to create new software on-demand – no need to wait for all hardware vendors to implement the feature/function/fix in their myriad proprietary OS’. Finally, because your control-plane is independent of individual network devices, it can have a full and truly global view of the entire network, and make routing and forwarding decisions based on that topological understanding – thus increasing efficiency (this increased efficiency is, IMO, much more likely to provide significant cost savings than the hope of cheaper equipment).

IRS

No, we’re not talking taxes here. The Interface to the Routing System (IRS) is a new SDN concept, laid out in a recent IETF problem statement. To start off, think OpenFlow for routing instead of switching. The differences are actually more varied and subtle though. While OF replaces the network device’s control-plane altogether, IRS seeks to simply provide a comprehensive and responsive interface into the network device’s control-plane. An IRS wouldn’t replace routing (or switching) protocols, it would simply provide a means to interact with them. In the words of the authors of draft-ward-irs-framework, the IRS would be “a standard, programmatic interface for full-duplex, streaming state transfer in and out of the Internet’s routing system.” In yet other words, it has the definite potential to provide the second and fourth results listed above (interface with applications / provide global network view), possibly the third (allow third-party networking apps (although this would look quite different in a control-plane enhancing protocol like IRS than it would in a control-plane replacing protocol like OF)), but likely not the first (commoditize network technology).

SDNP

Here, SDN translates to Software Driven Networks and SDNP is the SDN Protocol. Administratively, SDNP is currently a BOF within the IETF that has produced at least one draft ([draft-stiliadis-sdnp-framework-use-cases] although it has expired for now) explaining the framework and some use cases. From that draft: “The goal of SDNP is to define a method where applications can request services from the network and these services can be automatically deployed.” They go on to lay out a four block generic framework to meet this goal:

         +------+  +--------------+
         |      |  |Application   |
         |  P   |  |Definition    |
         |  O   |  +------|-------+
         |  L   |         |
         |  I   |  +------|-------+
         |  C   |  |Network       |
         |  I   |  |Mapping       |
         |  E   |  +------|-------+
         |  S   |         |
         |      |  +------|-------+
         |      |  |Network       |
         |      |  |Binding       |
         +------+  +--------------+

                        Figure 1 Generic Framework

     o Application Definition: This is a generic representation of the
        requirements of an application without specifying the
        underlying technology.
     o Network Mapping: This function translates the requirements of
        the application to an actual network service that can be
        implemented by a specific network technology.
     o Binding: This function maps the abstract network service on
        control planes and specific network elements.
     o Policies: Provides the repository of policies that will drive
        the translation between generic requirements and network
        technologies as well as the binding to specific elements.

While the framework is logical and will likely be quite useful going forward, its focus on network configuration and mostly one-way communication highlights (through absence) the need for enhanced network visibility, in addition to network control. The goal of a comprehensive SDN solution then should be more along the lines of: …a method where applications can request services [and information] from the network and these services can be automatically deployed [and comprehensively monitored].

Other Examples

• SNMP – Simple Network Management Protocol: “The Internet Standard Management Framework” It may be old, but it’s still the de-facto standard method for programatically interacting with network devices on most networks today, call it SDNv1 perhaps.
• NETCONF – Network Configuration: “The NETCONF protocol defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated.“
• ForCES – Forwarding and Control Element Separation: “ForCES aims to define a framework and associated mechanisms for standardizing the exchange of information between the logically separate functionality of the control plane, including entities such as routing protocols, admission control, and signaling, and the forwarding plane, where per-packet activities such as packet forwarding, queuing, and header editing occur. By defining a set of standard mechanisms for control and forwarding separation, ForCES will enable rapid innovation in both the control and forwarding planes.“
• PCE – Path Computation Element: “The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on each head-end LSR.“
• CDNI – Content Delivery Networks Interconnection: “The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents).“

 No Really, WTF is SDN?

Often understanding what something is not is just as important as knowing what it is. In that light, I think we can draw a couple useful conclusions from the above examples:

1. SDN is not OpenFlow – While OpenFlow appears to have great potential, SDN is not any one protocol. It’s bigger than that. Software Defined Networking is a methodology, not a method. It is a broad discipline, not a specific technique. It’s a place to seek answers, not an answer itself.
2. SDN is not new – SNMP was first defined by RFC 1067 in August of 1988 (yes, 24 years ago). While the primary goal was to enable management by remote users (not directly by applications) it is still clear that from the very early days of networking and the Internet, network management was a concern and software was a solution.

Combining these conclusions, we can see that SDN is more of a trend than a tool, more of a continuum than a single solution. In fact, any talented network engineer who has written a script to make configuration changes, to evaluate network inventory, or to do any other network management task, has developed an SDN solution. Every network with a service activation or provisioning system of some sort (or any OSS/BSS really) has deployed SDN. Every NMS and EMS out there is a precursor to more advanced SDN tools.

While SDN is not as new (or as well defined) as some would have you believe, it’s still very exciting. The exciting part is extrapolating the SDN trend into the future as we make these programs and languages more fully featured and more standardized. SDN is no magic pill, but it does have the potential to drastically simplify network operations while simultaneously increasing network efficiency. The important part is to focus on real problems and finding the best solutions, rather than falling under the spell of the newest buzzword.

Wait, WTF is SDN?

In short, Software Defined Networking (SDN) is the current name for a continuing trend towards greater network virtualization through software abstraction.