Introduction to Software-Defined Networks

What is SDN?

I won't probably give you a bottom line answer to this question; SDN has a bunch of definitions that describe some concepts or functions that are not explicitly tied to SDN specifically and are not completely conveying the whole picture.

Another reason for the overall confusion around defining SDN is that there are different flavors and solutions for what is still called SDN and marketed as SDN by different vendors, making it a bit hard to define the boundaries for what SDN is.

The classical and most famous definition, describes SDN as:

The physical separation between control and forwarding plane where the network is managed from a centralized controller.

The problem with this definition is that it doesn’t explicitly describe something that isn’t already  possible before SDN and it also doesn’t emphasis some very important functions of SDN as we will see.

Software-defined networking (SDN) as I think of it, is an umbrella term covering several kinds of network technologies aimed at making the network as agile, flexible and probably as virtualized as possible.

So, When we hear people talking SDN and depending on the model it can include any or all of the following major concepts:

• Planes separation.
• Network functions abstraction (NFV)
• Centralized control and visibility.
• Network automation via programmable interfaces (APIs).
• Virtualization of networking applicances.
• And finally Openness.

One important point to highlight is that, Network function virtualization known as (NFV) shouldn't be confused with SDN. They can exist together as part of a solution or separately, as SDN conceptually doesn’t exactly care if the devices are virtualized or not.

Network Functions Virtualization (NFV): focuses on optimizing the network service themselves. It decouples the network functions from proprietary hardware, placing them on servers or computers so these functions can run in software to provide more flexibility for operation, changes and updates.

Of the many benefits of NFV, one of particular values is the ability to scale the network capacity through a virtualized infrastructure instead of having to purchase and add new machines to increase capacity. Examples include virtual firewalls or virtual CPEs which is going to be a big part of ISP networks.

SDN, but Why?

Social media, mobile networks, and data centers have all pushed traditional networks to their limits. The speed of changes and the need for agility that cloud computing, virtualization and automation have introduced in the data centers is still capped by some the inflexibility of our traditional network operations models.

In a traditional network, it takes time to deploy new equipment, it takes time and effort to roll out configuration across the network, bandwidth utilization is not as efficient as it should be and forwarding policies/rules are configured on a hop by hop basis. All of this making the network far from agile and non-responsive to quick changes  as we don’t maintain a holistic overview of the network end-to-end.

By introducing concepts like programmability of network traffic, abstraction of different network functions and automation on it’s core, SDN comes with the big promise to resolve many of the limitations mentioned above while at the same time reducing the OPEX and the overall administration overhead of the network.

In the simplest terms, SDN deals with the need to scale/descale as quickly as possible, with minimum network disruption as possible and with the least possible cost.

Basic SDN Terminology:

We will look below at an overview for how SDN works, but let’s first define some common SDN terminology for the sake of the discussion.

SDN Device: An SDN device is any device that satisfies the requirements to function in an SDN model, It should support an API for communication with the controller, an abstraction layer for traffic programming, and a packet-processing function to perform data forwarding.

SDN Controller: This is the centralized brain of the software-defined network. The controller is an application that maintains and end-to-end overview of the entire network, does flows management/distribution and it is the middle man between the SDN applications and the SDN devices. The controller allows full control and programmability of the entire network from a centralized location.

OpenFlow: It is a communications protocol that gives access to the forwarding plane of a network switch or router over the network. It is a programmable protocol aimed at directing traffic among routers and switches from various vendors. It separates the programming of routers and switches from underlying hardware. An important thing to note is that openflow isn’t SDN by itself.

Flow Table: A flow table is the rules table that defines packet forwarding decisions, it consists of flow entries, A flow entry header is used to find the matching flow for the packet in order to forward to it’s destination.

SDN Applications: SDN applications perform network functions and programming of flows through the controller. Such functions could be firewalling, load balancing, or any other operation that is supposed to happen on the network.

So briefly, here is How SDN works?

In this description we will look at the most common flavor known as Open SDN model.  There are other SDN flavors as I mentioned before, let's just mention them for the sake of completion without going into much details.

These are SDN via existing APIs and SDN via hypervisor-based overlay networks, which is gaining popularity as it allows the SDN solutions to run over the existing network equipment. And There many commercial solutions available from vendors that uses this model.These models are mostly pushed to increase the lifespan of the existing infrastructures.

 

Looking at the diagram above let’s start from the SDN devices at the bottom. The SDN device's main responsibility is to forward packets based on forwarding rules that are represented by the flows defined by the controller and resides in the flow table on the device.

When the SDN device receives a packet, it checks the flows table for a match. If the SDN device finds a match, it takes the appropriate configured forwarding action. If it does not find a match, the switch can either drop the packet or pass it to the controller to handle it.

A flow simply describes a set of packets transferred from one endpoint to another. The endpoints may be defined using different criteria, as an example it could be IP address-TCP/UDP port pairs, VLAN endpoints, and input ports, among different options. One set of rules describes the forwarding actions that the device should take for all packets belonging to that flow.

The SDN controller maintains a holistic view of the overall network and is responsible for abstracting the network of SDN devices it controls.  It presents an abstraction of the network resources to the SDN applications. The controller allows the SDN application to define flows on devices via a set of APIs maintained by the controller.

The SDN application interfaces with the controller, using it to set proactive flows on the devices and to receive packets that have been forwarded to the controller. Proactive flows are established by the application and persist until some change is made. This kind of proactive flow is known as a static flow. Another kind of proactive flow is where the controller decides to modify a flow based on the traffic load currently being driven through a network device.

SDN has Challenges:

After all, SDN is not that greenfield paradise that is coming without challenges or concerns. There are many concerns and debates in the market regarding many aspects of SDN starting from the definition. Some of the majors are:

• The expenses and the risks involved in investing in new and sometimes non-mature technologies is a concern for SDN adopters.
• SDN is a dramatic change comparing to how we used to do networking, and most likely there is no enough trained expertise with fair skill set in many organizations that are immediatly ready to run SDN solutions with all the new technologies they involve.
• SDN solutions supportability is another concern that comes to my mind. One of the major advantages that we have with today’s proprietary equipment is that it is fairly easy to reach for vendor’s support whenever a problem is faced. This might not be as easy with SDN solutions due to the open nature of the technology.
• Another big concern is related to the security and the availability of the centralized control plane, which should be kept online 100% of the time and at all cost.

In general there are some valid concerns as we speak about SDN solutions, that should be addressed via viable and practical solutions as we see full adoption for the different parts of this technology.

Where to go from here:

In the few paragraphs above, I tried to write a quick summary for SDN overall. If you feel like expanding in the topic, there are many good sources that you can refer to. Here is a list of resources that I think is good for this purpose in the order that I would refer to:

• The following books in order from left to right are very good sources to expand more on the topic:

• IPspace webinars. Ivan Pepelnjak has made very interesting set of free introductory webinars that separates the hype from the reality and is providing a ton of value on those subjects, which will save  you a lot of research time.
• There is also the ONF technical library that contains a long list of white papers and technical documents.
• Lastly there is the open networking forum approved trainings here.

The bottom line:

SDN talk is everywhere; there are adoptions being made for SDN solutions, Network functions virtualizations and automation. We are not definitely going to see complete networks transitioning to SDN just yet but these technologies are strongly hitting the ground, and many datacenters, enterprises and service providers are adopting them more and more. What I mostly appreciate about the open nature of SDN is that it's providing a catalyst for innovation and breaking the monopoly of big vendors in different networks.