To paraphrase one Network Engineer I’ve encountered recently – we’re now seeing driverless cars on the road but we’re still programming our networks from the command line, what’s wrong with that picture?

Today most networks consist of switches and routers that are statically configured either through a command line interface (CLI) or a web interface.  It’s been done like this forever. Increasingly however, the equipment we continue to configure in this way is becoming capable of being programmed using Application Programming Interfaces (APIs). This means an application can send configuration commands to network devices over the network. Typically this still involves sending the same commands used in the CLI but the implication is that software external to the device is exerting some control over its configuration and, therefore, the behaviour of the network.

This software that is exerting some control over our networks could be as simple as a script you wrote on your laptop. Perhaps it’s a network management application, or even a production application being used by the business, which has been made ‘network-aware’. Today it’s more likely to be the two former examples than the latter but all of these are possible.

So, does this constitute a Software Defined Network (SDN)?

No, of course it doesn’t. It might, somewhat generously, be described as a software defined switch configuration. It does, however open up the possibility of a SDN.  And increasingly, this is where the existing network equipment vendors are heading, and the only place where start-up network equipment makers are appearing. There are even software only networking companies like Cumulus Networks and software only network products like NSX from VMware.

What is SDN?
To the definition then.  This is the tricky part, there are so many definitions that it’s difficult to say one encompasses all that is SDN.  In my words, it is simply and broadly:

Software defined networking is the separation of the control plane from the data (or forwarding) plane in the network such that a controller, aware of the network topology, interprets an overarching network policy to provide configuration to the individual hardware and software network elements.

Of course it means different things to different people because, after all, to someone with a hammer, everything looks like a nail. To explain, if a company has traditionally made switches and routers, then SDN is something that controls switches and routers. To a company that makes a hypervisor, SDN would mean software at the hypervisor level. And, to a software start-up, SDN is software that others can run on their hardware or on an open source operating system.

Essentially, the network forwarding equipment, routers and switches, are not programmed individually by a network engineer (in some implementations it is not possible to configure them using the CLI).  Rather, a policy is created on a central network controller and this controller determines the configuration of the individual network elements as shown in Figure 1 below.

The controller is not involved in switching and routing decisions. Policy instructions from SDN controllers are issued using protocols like OpenFlow and OpFlex and interpreted by the forwarding network elements and converted to device configurations.  In attempts to encourage open interfaces between SDN controllers and network elements, the open source community and some vendors have developed these protocols to abstract the individual configuration commands for an element from the SDN controller instructions. In theory, this allows one vendor’s SDN controller to control equipment from other vendors without having the specific knowledge of the configurations commands.

Figure 2

The important perspective, though, is that of the application that ultimately delivers benefit to a business or individual. Today SDN is beginning to deliver benefits to business by providing efficiencies through automation and providing administrators greater visibility of their networks’ performance and faults resulting in faster resolution of issues.

The presence of a central policy controller creates opportunities for the efficiencies mentioned above. Automation is achieved through the APIs mentioned earlier. By granting programmatic access to the policy controller through these APIs, so called “Northbound APIs”, other applications have the ability to control the network. This is a powerful ability allowing automated provisioning of network resources and policies which, when combined with orchestration of virtual or physical compute resources and storage, provides, in data centres, fully automated application platform environment creation. This can reduce the time taken to instantiate an application or customer environment from weeks or even months to hours or minutes. The productivity gains from such a dramatic reduction in provisioning time on the consumers of the services and the network and data centre staff are manifest.

SDN IntegrationOnce these capabilities are available it is possible, using service stitching, to augment these application platform environments with layer 4  to layer 7 services (L4-7) like load balancers and firewalls. This is achieved by creating a network policy to route all traffic though the L4-7 services. These services can be provided by hardware appliances, as is usual today, or virtual appliances.

These virtual appliances can, in some implementations, be created within the hypervisor on a per virtual machine basis providing highly granular control. As with the network, compute and storage, L4-7 services can be instantiated automatically by the policy controller or the orchestration tool.

Implementations of SDN are growing rapidly; some examples I’m aware of are listed below:

  • Cisco Application Centric Infrastructure (ACI) – Cisco puts applications at the centre of its SDN implementation. Using its proprietary Nexus 9000 series switches and the Application Policy Infrastructure Controller (APIC), a VXLAN layer 3 overlay is created on a leaf spine data centre architecture. OpFlex is used as the protocol between the controller and the switches.
  • VMware NSX is a proprietary micro-segmentation approach to SDN with support for firewall-like security within the ESXi hypervisor environment. It can be applied as a software overlay on any vendor’s switching hardware. NSX reproduces the entire network model in software, enabling any network topology to be created and provisioned. It enables a library of logical networking elements and services, such as logical switches, routers, firewalls, load balancers, VPN, and workload security.
  • Arista Networks only produces SDN software and equipment. Their products encompass both the controller software and the switching hardware that is typically deployed in a leaf spine physical configuration.
  • Cumulus Networks is a software only SDN implementation. Their switching software is designed to run on “bare metal” switches under the supervision of their SDN controller. They currently support switches from 7 vendors including Dell and HP Enterprise.
  • OpenDaylight is taking an open approach to SDN by providing the networking engine for OpenStack.
  • Big Switch Networks provide an operating system for bare metal switches and a corresponding SDN controller.

Who Will Use SDN?
In its current form SDN is best suited to data centres with changing environments. The automation of network provisioning will complete the automation picture for enterprises and service providers who have already mostly achieved the predicted equilibrium level for compute and storage virtualisation and automated many of the associated provisioning tasks. This will result in lower turnaround times for the provisioning of new computing environments where the configuration of the network is still, largely, the most time consuming factor.

For those networks that change less often, the initial benefits of implementing SDN are a little harder to see. Automation of provisioning is of questionable benefit if it is seldom performed.  However, SDN should be a serious consideration for any business planning to replace end of life networks to take advantage of SDN’s other benefits such as simplified administration and improved network performance management and capacity planning.

If you’d like to know more on how SDN can be applied within your network, feel free to contact me.