Defining SDN (Software Defined Networking)

After my last article about the CCIE Written update, I wanted to take a fresh start with all the new coming SDN technologies. Starting to define the Software Defined Networking (SDN) itself could be a good starting point, that’s what I’m trying to do in this article. I came to the conclusion that the SDN is not that simple to define, it has many definitions and is a kind of concept that is still evolving. More specific articles about SDN technologies will follow with my findings.

I spent some time reading a lot of interesting articles from ipspace.net where Ivan Pepeljniak wrote about SDN and propose some free webinars. I strongly recommend it. There is also a lot of good presentations from Cisco Live about SDN, programmability, cloud and IoT.

At first, the term “Software Defined” can be a little overrated as we all know that since the very beginning, a device behavior has always been defined by its software (OS, firmware…). It seems to me that the “Software Defined” of SDN is more about intelligence, control and abstraction than an OS or firmware can be.

Traditional Network
On traditional network devices, control-plane and data-plane are locally managed. The control-plane learn/computes forwarding decisions, and the data-plane acts on the forwarding decisions. It looks like this:

Control plane learns/computes forwarding decisions
Data plane acts on the forwarding decisions
(Source: Cisco Live BRKRST-1014 from Jason Davis)

You also like Schwarzenegger that moves packets, eh? Jumbo frames of course!

Centralized Control Plane
The first definition of the ONF (Open Networking Foundation) for SDN on their SDN Defined page is the following “SDN is the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices“.

Here is what it looks like on the diagram: an external controller centralizing all the intelligence and network devices only able to push the packets. This is what we can call the “purist” SDN topology.

Control plane becomes centralized
Physical device retains Data plane functions only
(Source: Cisco Live BRKRST-1014 from Jason Davis)

We could think it’s a good idea but the centralized control plane doesn’t really make sense. Why ? Because Centralized control is different than Centralized control plane. Having a totally out-of-band control plane network is dangerous. Without any distributed intelligence, we have no resilience to failure. If we loose the controller, we loose the control-plane (ARP, LLDP, Routing…) and that’s not what we want. In this kind of vision, the controller is the central point of failure.

The vision of controller-plane makes more sense in the following extracts:
“.. Data plane may include the necessary minimum subset of control and management functions ..”
“.. The controller plane may configure the data plane to respond autonomously to events such as network failures or to support functions delivered by, for example, LLDP, STP, BFD or ICMP ..”
“.. Number of functions with control aspects are widely considered as candidate to execute on network elements ..”

The goal is now to have a centralized controller but the devices still retain a localized control-plane intelligence. The following picture represent the “hybrid” SDN topology.

A Controller is centralized and separated from the Physical Device, but devices still retain a localized Control plane intelligence
(Source: Cisco Live BRKRST-1014 from Jason Davis)

Here are some other definitions from the ONF for SDN.

Whitebox switching
“SDN is whitebox switching (running software on third-party cheap hardware”
In order to do simple packet forwarding, we can buy basic merchant silicon (Broadcom, Intel & co…) because the difference seems to be limited in hardware (makes no sense to develop specific ASICs), now the vendors are focusing on software. Some vendors are pushing the software further for all their products like Cumulus Networks and their Linux based operating system built to run on Whitebox hardware you can purchase from a number of partner Original Device Manufacturers (ODMs). The list of compatible hardware is here.

Software/Hardware Disaggregation
The Hardware costs 30/40% of the final product (gross margin of networking vendors is above 60%), software and support are the really expensive parts. Why can’t we buy hardware and software as separate items? This would allow more flexibility for the customer (reuse the same hardware, like with a personal computer) and simplify the management of the sparing (1 spare device in stock, not 15 different).

SDN = API
“SDN is network automation – programmable access to network devices”
An SDN controller must communicate with existing devices in order to configure it and his control plane protocols (BGP, OSPF…). Expect scripts and screen scraping are not good enough for that (netconf, rest api using JSON or XML data format) because there is no current standard out there for configuring a multi-vendor environment. SDN is not an API but the controller needs an API to communicate with the different heterogeneous networking devices.

Standards are a real concern when talking about SDN. A lot of new SDN Controller solutions are entering the market but all (if I’m not mistaken) with a proprietary system, which is a perfect lock-in. Don’t be fooled by the “open” marketing, it’s not because vendors use standards to a greater or lesser degree that we won’t be locked into their proprietary system (they aren’t standard-based themselves). I can’t think about Cisco ACI, VMware NSX, but also all the SD-WAN vendors (SD-WAN will be detailed another time, it’s a really interesting subject allowing enterprises to drastically decrease their telco expenses).

SDN = Abstraction layer
“SDN is an approach to computer networking that allows network administrators to manage network services through abstraction of lower level functionality”
This sentence makes more sense. What is Abstraction ? It’s how can I do something that will present a usable service to the end-user described in term they can understand. Abstraction is a kind of orchestration system, like Openstack or vCenter. It is definitely what the customers needs, shiny dashboards and simple buttons to run his network instead of no vision about what’s going on in his network and unknown Command Line Interfaces.

SDN and NetOps is finally a lifestyle change, from manual work (creating a vlan, deploying it) to automation (serving connectivity from A to B). We need a “single source of truth” which would allow faster and automated execution of processes and workflows with reduced errors.

The conclusion of Ivan in his SDN webinars was that if you need to perform complex-switching decisions, you must go for software. In the other way, if you need to perform basic L2/L3 forwarding, go for ASICs which are cheaper and faster than software.

Sources:

• ipspace.net
• Cisco Live presentations

Note: I will try to reach a broader audience by writing my future articles in english.
Will see what happens, let me know what you think about that in the comments.

Benoit

Network engineer at CNS Communications. CCIE #47705, focused on R&S, Data Center, SD-WAN & Automation.

More Posts - Website

Follow Me: