The Business Case for Software Defined Networking: Part 1

Is SDN a Fad or Can It Really Help Enterprise Businesses?
Terry Slattery

This is part 1 of a multi-part blog series on making the business case for SDN. Read part 2 and part 3.

Defining SDN

Before we can talk about whether software defined networking (SDN) would help a business, we need to define what it is. Unfortunately, there seem to be about as many definitions of SDN as there are vendors who say they have an SDN product. Let’s look at the components of SDN and perhaps you can learn how to decipher the vendor hype around it.

The original definition of SDN, published by the Open Networking Foundation says:

The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

Related Video: What is SDN and Why is it Important?

In other words, a centralized (typically redundant) control system determines the forwarding path of packets and programs the network devices to implement that path. This leaves a lot of other factors open for interpretation. I prefer to describe SDN by its characteristics.

Policy-based Software Control

Networks have always been controlled by software, so what’s up with this new SDN terminology? A key differentiator is that SDN uses policies to define packet flow paths. Non-SDN networks rely on detailed configuration statements that add path controls on top of standard protocols (e.g. OSPF, BGP, Spanning Tree). SDNs hide the complexity of detailed configuration statements, so the network operator configures the network with policies. Policies are applied across multiple network devices, avoiding the problem of inconsistent configurations that exists with a box-by-box configuration approach.

Forwarding Based on Policy, Not Destination IP Address

SDNs forward packets based on more than just destination IP address. Policies might specify that all voice traffic follow a dedicated path that has characteristics like low jitter, low latency, and low packet loss, marked with EF QoS settings to that it can be prioritized above other traffic. Business-critical application policies may dictate that its traffic be handled just below voice/video traffic, but perhaps with no jitter and latency restrictions. A bulk traffic policy could allow for any other traffic, up to the remaining bandwidth of the path. This simple set of policy directives in SDN replaces many lines of configuration in a non-SDN model.

The implementation of SDN makes forwarding decisions based on at least a 5-tuple: IP Source Address, IP Source Port, IP Destination Address, IP Destination Port, and IP Protocol ID. Some SDN implementations include other packet header elements like MAC address, DSCP values (for QoS), and packet size, which allows for finer grained control of packet flows.

White-list Security Model

An SDN only forwards packets along defined paths. If no path is defined, the packets are dropped. This security model, also called zero trust networking, provides the functionality to implement multi-tenant networks. An example is End Point Groups, which are collections of endpoints that can communicate with each other.

Software-based Configuration

To achieve the operational efficiencies that are attributed to SDNs, the configuration of the SDN configuration must be automated. Policy definitions are used to create the configurations for the network devices. Policy changes would then require pushing new detailed configurations to the network devices. The network administrator is working at the policy definition level, not at on a per-box configuration level.

This is where the definition of SDN can be confusing. The existence of automated configuration, while implemented via software, does not necessarily make a network “software-defined”. We’ve had network orchestration and automation systems for many years and we still find organizations that are not using them. Even if an organization is using configuration automation, if the network does not have the attributes of policy-based configuration and forwarding on more than destination IP address, then I maintain that it is not a true SDN.

SD-WAN: A Clear Example

SD-WAN products have the characteristics I described above, making them really good examples of how SDN can work. These products are essentially an enhancement of WAN accelerators of the past. They take advantage of multiple WAN connections to provide resilience and to segregate different types of traffic (e.g., UC, business apps, and bulk data). Policy is defined at a central control system, which pushes specific configurations to each SD-WAN device. Packet forwarding is done based on policies and link performance measurements.

For more information, the NetCraftsmen website has a good amount of information about how SD-WAN products work.

I’ll continue the thought process on defining the business case for SDN in part 2 of this blog series.

Video: What is SDN and Why is it Important?
Video: What is SDN and Why is it Important?

Share This Post

Most Popular