What exactly is Software-Defined Networking (SDN)?

Question

I was poring over the docs for Open DayLight, and can't seem to wrap my head around what software-defined networking even is. All the media hype, blogs and articles I can find on SDN are riddled with buzzwords that don't mean anything to me as an engineer. So I ask: What (exactly) is SDN? What are some specific uses cases/problems it solves? Is it:

• Just making proprietary networking hardware serve network APIs, thus allowing programs to configure them (instead of IT guys using a console or web interface)?; or
• Implementing (traditionally proprietary) networking hardware as software; or
• Writing software that somehow integrates with virtual networking hardware used by virtualization platforms (vLANs, vSwitches, etc.)?; or
• Something else completely?!?

BONUS: How does Open DayLight fit into this equation here?

Giess

Take a look at section III of this document: Software-Defined Networking: A Comprehensive Survey. The survey also places the various controllers/platforms/technologies. – Bin

Answer 1

First of all, you are right, there is not official definition from NIST or some similar standardization body and the fact that its meaning is fuzzy is exploited by marketing people.

The main point of SDN is that it allows to program network functions with APIs. In the past, networking devices like switches and routers were only configurable using a proprietary interface (be it vendor specific tools or just the CLI on the device) and there were no APIs which allow to configure OSI L2 - L3 aspects like VLANs and routes but also L6 - L7 aspects like load balancing highly dynamically. Btw. In the case of L6 - L7 functions, the term NVF = Network Virtualized Function seems to be established by now.

This is needed especially for multi tenancy capable virtualized IaaS systems. You can create new VPCs and arrange them together at will. To really isolate tenants from each other, you need to have a L2 isolation and so the same dynamics that is offered for VPCs is propagated to the networking for interconnecting them.

Conclusion: It is about your first bullet with the extension, that the APIs must not necessarily be offered by some hardware appliance, it can also be offered by some pure software implementation.

Regarding OpenDaylight: It is the OpenStack pendant for SDN. They also actively push integration with OpenStack. They say they are an "open, reference framework for programmability and control through an open source SDN and NFV solution". This means it provides (as you say) a façade for the manfold aspects of networking. They have all the big names as members which probably means they have the power to establish a de-facto standard like OpenStack did. Members benefit in that they can provide plugins, integrations and adaptations for their products so that they seamlessly integrate with OpenDayligh and you only need to care about a single standard API.

Cutright

Thanks @Cutright (+1) - this is helping me start to see the forest through the trees here. A few followup questions for you (if you don't mind): Can I assume then that Open DayLight, being a Java project, aims at creating a suite of APIs that Java clients can code against, that ultimately forward the client requests on to specific (proprietary) hardware? In other words: is Open DayLight a facade/wrapper for SDN APIs offered by network hardware vendors? Thanks again! – Giess

Sorry, forgot the OpenDaylight Bonus, I have extended the answer. – Cutright

Answer 2

SDN is programmable networks. Different SDN solutions provide different functions in their APIs towards the app developer.

There is a good overview of SDN for software developers here:

https://github.com/BRCDcomm/BVC/wiki/SDN-applications

The most common elements for SDN solutions are

1. North-bound API: A programming interface used by an application/script to monitor, manage and control the network topology and packet flows within the network.
2. Network elements: Switching or routing network elements that enforce the rules provided by the application via the north-bound API. These elements may be physical (Cisco, Brocade, Tallac, etc) or virtual (Open VSwitch, Brocade Vyatta vrouter, Cisco 1000, etc) or a combination.

Controller-based solutions have a clustered architectural element (the 'controller') that provides the north-bound api towards applications and an extensible set of south-bound APIs to which network devices connect. Some controllers available today are OpenDaylight, Open Network Operating System (ONOS), Juniper Open Contrail, Brocade Vyatta Controller (ODL distribution), HP VAN Controller and more.

Best rules of thumb to understand an SDN offering:

1. Read its north-bound API - this tells you what you will be able to monitor, manage and control in your network.
2. Find out which south-bound APIs it supports - this tells you which switches/routers it might work with.

Some SDN use cases/applications:

• DevOps/Admin automation - Applications and scripts that make a network admin or DevOps life easier through automation. OpenStack Neutron is a common example.
• Security - HP provides 'Network Protector' that learns the topology of the network and then monitors activity providing alerts and/or remediation of non-compliant behaviors.
• Network optimization
  • Brocade offers 'Traffic Manager' that monitors network utilization and modifies traffic flows in real time to optimize quality based on defined policies.
  • HP provides 'HP Network Optimizer' that provides an end-to-end voice optimized path for enterprise Microsoft Lync users.
  • Lyatiss provisions AWS networks in realtime to meet application needs.
• Monitoring classroom time-on-task - Elbrys provides an application that provides a teacher with a dashboard to monitor student's time-on-task in real time and cause redirects of individual students to web pages of their choosing. (Disclaimer: I work for Elbrys Networks)
• OpenDaylight project proposals page - https://wiki.opendaylight.org/view/Project_Proposals:Main

Devinne

Answer 3

The concept of SDN is very simple. SDN decouples control-plane (i.e. decision making) from data-plane (the actual forwarding actions) and provides API between them (e.g. OpenFlow API).

Image source: https://www.commsbusiness.co.uk/features/software-defined-networking-sdn-explained/

With SDN architecture, network engineers no longer have to learn proprietary CLI commands for different vendors. They can focus on developing logically centralized control programs to make network global decisions and send it down to network switches (data-plane). Dumped network switches (data-plane) received controller rules/decisions and process network packets accordingly if no decision found they ask the controller.

For example: In SDN architecture routing algorithms developed as a program in the controller, it collects all required metadata (e.g. switches, ports, host connections, links, speed, etc) from the network then make a routing decision for each switch in the network. While in a conventional network, a routing algorithm is implemented in a distributed fashion in all switches (i.e. generally each switch has its own intelligence and makes its own routing decision).

SDN explained by Nick Feamster

Here is a good paper that illustrates the road map to SDN

Methodize