Insights

Blogs

What is Software Defined Networking (SDN)?

The latest paradigm in computer networking known as Software Defined Networking (SDN) is kicking up a storm, with numerous start-ups going live and several high-profile SDN acquisitions totalling roughly $1.6bn in 2012, driven by VMWare’s $1.26bn purchase of Nicira.

Stay current on your favourite topics

Subscribe

Whilst most organisations are focussing on the benefits of SDN in the domains of cloud computing and virtualisation, I think there are some really interesting opportunities to leverage the technology in eTrading and Market Data space and other IB applications, which I plan to write in some detail on in future posts.

But first, let’s try to understand what SDN is, current market trends and where the market might be going…
What is SDN?

The latest trends in computing are changing the requirements on the networks that support them – server virtualisation, cloud computing, big data, mobile. Traditional, hierarchical networks, optimised for predictable, client-server, north-south network flows with fixed end points, now have to support increasing amounts of unpredictable east-west traffic. Mobility and virtualisation require a level of flexibility that is not supported by static network configuration. Multi-tenancy and mobility creates unpredictable network traffic patterns. Large datasets require parallel processing techniques that create a need for high bandwidth, any-to-any connectivity.

The ability to rapidly scale and react to these requirements with current networks is limited by the amount of static, manual configuration that is inherent in today’s networks as a reaction to the complexity of running many discrete protocols across large numbers of devices. Different hardware from different vendors running different OSes at multiple layers in the network all need to be configured by hand on a per-session and per-application basis.

This level of complexity and manual configuration, coupled with applications and client connections that can move more freely around the network than ever before, means that any inconsistencies in access control, security and quality of service across the network are more likely to be exposed.

Finally, vendors are unable to provide the feature velocity demanded by the market from their closed, hardware-based platforms.

In the beginning there was OpenFlow

The original concepts behind Software Defined Networking came out of Stanford University in 2008, where OpenFlow was proposed to enable secure, isolated experimentation within the campus network based on closed, commodity platforms.

In essence, with OpenFlow the data plane and control plane of the switch(es) are broken out into a distributed “Flow Table”, implemented in the switch hardware, and a central “Controller” implemented in software. The Controller interacts with the Flow Table using the OpenFlow protocol.

With OpenFlow the properties of a flow are defined in the Controller – destination IP address, for example – along with one of three basic actions:

  • Forward to a given port (or set of ports)
  • Encapsulate and forward this flow’s packets to a Controller
  • Drop this flow’s packets

The default action is (2.), where the Controller makes a decision on how to process the packet by either dropping the packet and/or adding an entry into the switch’s flow table allowing the switch to process similar packets without having to consult the Controller every time a packet is received.
SDN evolution

Since the original OpenFlow paper was published in 2008 the concepts of Software Defined Networking and Network Virtualisation have evolved from a niche, academic requirement to the next big thing in networking.

OpenFlow, however, is just one piece of the SDN jigsaw. In order to make network virtualisation a reality a number of key features are required in SDN and virtual networking solutions.

The Open Networking Foundation (ONF) uses the term “Software Defined Forwarding” to generalise the features found in OpenFlow. In addition, the ONF has defined 5 dimensions that SDN solutions need to implement in order to be viable alternatives to current networking technology:

  • Bandwidth – ability to set bandwidth controls on virtual networks
  • Topology – each “slice” of the network should have its own view of network nodes and the connectivity between them
  • Traffic – virtual networks should be segmented such that they can only see each other’s traffic if dictated and allowed
  • Device CPU – the CPU of the SDN devices should be allocated such that each virtual network receives the appropriate number of cycles
  • Forwarding Tables – isolation of forwarding table entries between the different virtual networks being managed by a multi-tenanted device

Stay current on your favourite topics

Subscribe

Common elements in emerging solutions

A number of common elements are emerging in SDN solutions to facilitate the requirements:

Southbound API – Allows for physical and virtual switches to exchange control information with the SDN controller platform. OpenFlow is one example of Southbound API, however most of SDN start-ups have developed their own Southbound API first, due to the lack of feature velocity in OpenFlow and lagging hardware support from “traditional” networking vendors, with OpenFlow support second.

Northbound API – Makes the control information of the network available to higher instance abstractions such as applications. Two types of Northbound APIs are emerging – one at the controller level, exposing more granular information (usually used for network services, such as firewalls, load balancing etc); another at the network virtualisation level for more abstracted applications (e.g. cloud orchestration). Northbound API is one area where vendors are attempting to differentiate themselves and see the most value in developing cool features. Because there is no tie to underlying hardware at this level, unlike the Southbound API that requires the forwarding plane to support features, each vendor has a proprietary offering (although most vendors promote their API as being “open”).

SDN Control Platform – at the control plane level most vendors are offering centralised access to the network control information but with underlying logic distributed across multiple servers, switches and/or appliances for scalability and performance. Clearly if the first packet in any flow needs to be sent back to the Controller a single, monolithic Controller isn’t going to be performant or scalable enough to support many end points in 10- and 40- Gig networks.

Distributed Forwarding Plane – forwarding planes are distributed below the control platform. Some vendors are offering Physical Switch only, others are offering Virtual Switch integration with their controllers.

 

Figure 1. Software Defined Networking Overview

2013…

Although 2013 is unlikely to see wide-scale mainstream adoption of SDN, it is going to be an interesting year for SDN. Even the big incumbents can’t hone in on a consolidated view of what SDN is and should be. There is a huge expectation that 2013 will see more emerging vendors snapped up by incumbents for huge dollar figures, and consolidation in the market. And will an exciting new vendor manage to “do an Arista”? Only time will tell.

My next articles on this topic will look at some interesting applications within the Investment Banking space that could be revolutionised by SDN.

NEWS FLASH: A new SDN Consortium, “Daylight”, led by Cisco and IBM, has been created to create an open source controller under the Apache 2 license. This could be a big disruptor to the currently healthy SDN start-up market.


Would you like to know more about our work?


The author

Ian Tivey

Ian Tivey

Associate Partner, New York

Ian has a broad background across DevOps and Infrastructure disciplines in the design, build and operation of globally-distributed market data distribution and trading platforms. He currently leads Citihub Consulting’s Cloud Practice, having worked with clients in Europe, Asia, and North America to design and build hybrid cloud solutions in highly regulated banking environments.

ian.tivey@citihub.com