sdn - beyond the obvious

Software Defined Networking – Beyond the Obvious

Peter van der Voort

Senior Solution Architect

[email protected]

January 2014


2 of 23

Everyone working in the field of networking, or even somehow being involved in IT, can not have missed it: there’s a new hype on

its way, Software Defined Networking (SDN).

At first glance, this designation seems a bit strange. Surely, every random router or switch is controlled by software, and so the

network is controlled by software. Thus, has networking ever been NOT software defined?

Executive Summary

If trying to define “Software Defined Networking” it could

be said that SDN is an approach in which control of

routing/switching is decoupled from switch hardware and

control is being passed on to a software application, a

controller. In other words, the data-plane is decoupled from

the control-plane.

Following this definition, the subject is touched in many

presentations, documents and whitepapers, which deal

with the decoupling of data- and control-plane in great

detail. And although that indeed is the basis for SDN, there’s

much more to tell about it, like practical applications, but

also the current state of affairs. Because when reading

different articles, one could get the impression that a fully

functional SDN solution can be bought off the shelf and

implemented. But the question is whether that is really the

case.

Another question that can be asked in relation to SDN: Is it

a hype? Or is “hype” perhaps not the right word? The fact of

the matter is that everyone is talking about SDN and how

this is going to change the future of networking. But what

does it really mean for a company which wants to adopt

this technology?

When looking at the adoption of IPv6, we could conclude

that many companies did not (yet) do much with it, even

though IPv6 will truly become a necessity. So if companies

do not line up to get this implemented, what does that

mean for the adoption of SDN? For now, it’s mainly the

suppliers of network equipment who are really into SDN

and its derivatives.

This whitepaper highlights other items than just the

obvious. But since the separation of data- and control-plane

is still the basis, there will be a word about that as well.

Further, we’ll have a look at different initiatives from

different vendors and see what they really support at this

moment in time, at least based on the information (or the

lack thereof) on their own websites.

Next, there will be an overview of use-cases, limitations,

security and practice, followed by a brief look into the

future.


3 of 23

Table of Contents

Executive Summary ................................................................................................. 2

Woods and trees ..................................................................................................... 4

Software Defined Networking (SDN) .................................................................. 4

OpenFlow ............................................................................................................ 4

OpenStack ........................................................................................................... 5

Cisco ONE and OnePK ......................................................................................... 5

Application Centric Infrastructure (ACI) .............................................................. 6

Application Policy Infrastructure Controller (APIC) ............................................. 6

Cisco ONE SDN Controller ................................................................................... 6

Cisco eXtensible Network Controller (XNC) ......................................................... 6

OpenDaylight ...................................................................................................... 7

Floodlight ............................................................................................................ 7

Network Functions Virtualization (NFV) ............................................................. 7

The obvious ............................................................................................................. 8

Initiatives ................................................................................................................ 9

Cisco .................................................................................................................... 9

Cisco SDN switches ......................................................................................... 9

HP ..................................................................................................................... 10

HP SDN switches ........................................................................................... 11

Juniper Networks .............................................................................................. 11

Juniper SDN switches .................................................................................... 12

Brocade ............................................................................................................. 12

Brocade SDN switches ................................................................................... 13

Plexxi ................................................................................................................. 13

Plexxi SDN switches ....................................................................................... 14

Big Switch .......................................................................................................... 14

Big Switch SDN switches ................................................................................ 14

Use cases ............................................................................................................... 15

Network Access Control..................................................................................... 16

Multi tenant network ........................................................................................ 17

Quality of Service (QoS) ..................................................................................... 17

Layer 2 connectivity ........................................................................................... 18

Limitations ............................................................................................................. 18

Collateral damage ................................................................................................. 18

Security .................................................................................................................. 19

Practice .................................................................................................................. 21

Future .................................................................................................................... 21

References ............................................................................................................. 23


4 of 23

Woods and trees

When diving into SDN it quickly becomes clear that there

are many new terms associated with it. Some terms are

generic, others are made up by the vendors. Some

abbreviations describe specific techniques. This chapter

provides an overview of the most important terms and

relevant techniques.

Software Defined Networking (SDN)

This is most likely the most important abbreviation,

Software Defined Networking. SDN is about decoupling

data- and control plane of a switch, in which control is

being delegated to an external controller. SDN is an

umbrella term for several different initiatives.

OpenFlow

OpenFlow is an open standard which is managed by the

“Open Networking Foundation”1 (ONF) and is defined on

their site as follows:

OpenFlow is an open standard that enables researchers to

run experimental protocols in the campus networks we use

every day

This is a pretty abstract description but another description

on the same site says:

OpenFlow enables networks to evolve, by giving a remote

controller the power to modify the behaviour of network

devices, through a well-defined "forwarding instruction

set".

This description makes more sense already. But what does

it actually mean in the real world? It means that a

controller has the possibility to push flow entries to a

switch. These flow entries decide how a specific packet is

going to be forwarded.

So what OpenFlow does is the following: When a switch (an

OpenFlow switch) receives a packet which is part of a flow

of which the switch does not yet have a flow entry in its

flow table, the switch will forward the packet to the

controller. The controller then decides about what to do

with the packet (or rather, the flow of which this packet is

part of). It can be dropped or an entry is going to be made

in the flow table of the switch so that the switch knows how

to handle consecutive packets of the same flow.

OpenFlow is not the same as SDN. SDN is the umbrella term

and OpenFlow is part of SDN. The OpenFlow protocol is

maintained by the Open Networking Foundation.

The OpenFlow switching specification was created in 2008

by several universities and the ONF was launched in 2011


5 of 23

by Deutsche Telekom, Facebook, Google, Microsoft, Verizon

and Yahoo!. The initial members of ONF were: Broadcom,

Brocade, Ciena, Cisco, Citrix, Dell, Ericsson, Force10, HP,

IBM, Juniper, Marvell, NEC, Netgear, NTT, Riverbed and

Verizon. Today, the ONF has more than 100 member

companies.

Version 1.0 of OpenFlow was released on December 31,

2009. The current version of OpenFlow is version 1.4

(released October 15, 2013). That being said, there are

currently no switches which support version 1.4 so for real

implementations version 1.3 (released June 25, 2012) is

used.

The first version of OpenFlow had some serious limitations

which were resolved in version 1.1. Because of these

limitations, the recommendation is to use at least version

1.3. However, only a few vendors actually support this

version on their hardware.

OpenStack

The official description of OpenStack2 is:

OpenStack is a global collaboration of developers and cloud

computing technologists producing the ubiquitous open

source cloud computing platform for public and private

clouds

Just as with OpenFlow, this is quite a broad concept.

Basically it’s a solution for creating, managing and

deploying cloud services, specifically “Infrastructure as a

Service” (IaaS). With this, it becomes easy to create and

deploy virtual servers. OpenStack also adopted SDN which

makes it possible to not only create virtual servers but also

define network characteristics. So OpenStack is combined

with SDN, specifically with OpenFlow.

Cisco ONE and OnePK

The “Cisco Open Network Environment” (ONE) 3 was

announced by Cisco in June 2012. ONE is an extensive

solution to open up networks, make them better

programmable and above all, make them application aware.

Cisco ONE is a programmable framework which consists of

three parts:

1. Controllers and agents

2. Programmable interfaces

3. Virtual network overlays

Cisco ONE provides a real-time feedback loop based on

these three parts, giving the application the possibility to

directly communicate with the network, giving the network

the opportunity to interactively respond.

In cases where there is much demand from the application

side, for example because many users want to view a


6 of 23

specific video, ONE takes care (by the means of

orchestration, or programmable interfaces) that the virtual

infrastructure (virtual machines) is scaled up as needed

and there is enough bandwidth available on the network.

ONE complements the current SDN approach. As part of

ONE there is the “One Platform Kit” (OnePK) which

provides an API platform for developers. The OnePK

platform offers, according to Cisco, more possibilities than

OpenFlow can.

Application Centric Infrastructure (ACI)

In November 2013 Cisco introduced the “Application

Centric Infrastructure” (ACI)4.

ACI is, according to Cisco’s description, a comprehensive

architecture with centralized automation and application

profiles which are based on policies. ACI is developed as an

open architecture and Cisco is working with about 20

companies amongst which are BMC, F5, Microsoft, NetApp

and Red Hat.

Application Policy Infrastructure Controller (APIC)

The “Application Policy Infrastructure Controller” (APIC) is

the central point of automation en management for the

Application Centric Infrastructure. The Cisco APIC provides

central access to switch-fabric information, optimizes the

application lifecycle (for scaling and performance) and

supports flexible application provisioning of physical and

virtual resources. The APIC will be released in the second

quarter of 2014.

Cisco ONE SDN Controller

In February 2013, Cisco expanded the OpenFlow approach

with the new Cisco ONE Software Controller. The ONE

controller supports both OpenFlow and OnePK. The ONE

controller was developed by Cisco but also supports

OpenFlow switches from other vendors.

In April 2013, Cisco donated a large part of the code of their

ONE controller to the OpenDaylight project.

Cisco eXtensible Network Controller (XNC)

The “eXtensible Network Controller”5 (XNC), part of the

“Open Network Environment”, is a software application

and is the first commercial version of the OpenDaylight

controller. It runs on a Linux-based server, like the Cisco

“Unified Computing System” (Cisco UCS). The XNC is based

on the OpenDaylight controller but has a few additions to it.

At this point in time, the XNC only supports OpenFlow

version 1.0


7 of 23

OpenDaylight

OpenDaylight6 is an Open Source project, organized by the

Linux foundation, and was announced in February 2013.

The common goal is to promote the adoption and

innovation of Software Defined Networking by creating a

common, industry supported framework.

OpenDaylight supports, but is not limited to OpenFlow. The

OpenDaylight project has supporters like Arista Networks,

Brocade, Cisco, Dell, IBM, HP, Juniper, Microsoft, etc.

In April 2013, Cisco donated a large part of the code of their

ONE controller to the OpenDaylight project. The company

“Big Switch Networks” (an SDN start-up) went into

disagreement with Cisco about this and stepped back from

their leadership position in the OpenDaylight project.

BigSwitch’s argument was that the ONE controller is a year

behind on the controller of themselves.

Floodlight

Floodlight7 is a project which was launched by “Big Switch

Networks”8 in January 2012. Floodlight is a Java-based,

Open Source SDN controller, developed by an open

community of developers, and forms the core of the “Big

Network Controller”, the commercial controller of Big

Switch Networks.

The Floodlight controller supports OpenFlow v1.0 and

works with physical- and virtual switches.

The Floodlight controller is capable of handling mixed

OpenFlow and non-OpenFlow networks. It can manage

multiple “islands” of OpenFlow hardware switches.

Additionally, there is support for the OpenStack cloud

orchestration platform.

Network Functions Virtualization (NFV)

The idea behind “Network Functions Virtualization” (NFV),

as presented in a whitepaper from a group of network

operators in October 20129, is to virtualize network

functions and have them run on generic server hardware.

So network functions are being virtualized and move from

purpose-built appliances to generic server hardware. The

functions can then be started at random places in the

network, there were it’s needed, without the need to install

specific (physical) appliances.

The advantages are, amongst others, a reduced Capex and

Opex because less appliances need to be purchased or

managed, reduced time-to-market for new services,

increased flexibility to scale up or scale down and savings

on power consumption.


8 of 23

Network Functions Virtualization complements SDN but

both do not depend on each other. NFV can be deployed

without SDN and vice versa. However, when deployed

together they can strengthen each other.

Despite the fact that the functions are virtualized, these

functions still need to be controlled. This controlling can

well be done by an SDN controller. And so SDN can be

utilized regardless of the network being physical or virtual.

Yet, there are functions that can be executed by either SDN

or NFV. NFV could do tasks which are equal to tasks of the

SDN controller. But since both SDN and NFV are still under

development, all options are open.

Although NFV gained visibility in October 2012, and ETSI

published10 the first specifications for it in October 2013,

the concept is obviously not new. For a long time there has

been virtual firewalls (although not always running on

general purpose hardware) and virtual router software like

Mikrotik’s RouterOS11 or Quagga12.

The obvious

The principle of Software Defined Networking is

decoupling the control plane and data plane of a switch, see

below figure.

The data plane is always located within the physical switch.

With a traditional switch, also the control plane is located

in the physical device and this control plane makes

decisions about how and where to send packets.

In the SDN model, the control plane is detached from the

physical switch and is located, in the form of a software

application, on separate hardware. This is called the “SDN

controller”. The SDN controller is capable of

communicating with business applications so that these

applications can request (for example) network resources

with the SDN controller.

In a traditional switch, when a packet arrives at the switch,

the control plane inside the switch decides what needs to

happen with the packet, like forwarding out a specific

switch port. Every packet with the same destination will

always be switched out of the same switch port.


9 of 23

With SDN, when a packet arrives at the switch, the switch

will forward the packet to the SDN controller to decide

what needs to happen with the packet. Then, with a

protocol like OpenFlow, the controller will configure the

switch with a flow entry in the flow table (or forwarding

table) so that the switch knows what to do with

consecutive packets. Actions that can be taken include

forwarding out of a specific switch port or dropping the

packet so that effectively a firewall is created.

Because the SDN controller has a complete overview of the

entire network, all other switches in the path of the flow

can be configured at the same time.

The SDN controller will monitor the entire network and can

at any desired moment adjust a flow entry, based on for

example the utilization of a specific path within the

network.

Initiatives

Many manufacturers of networking equipment jumped on

the SDN train. Additionally, many new companies seeing

possibilities in SDN, were born. Below is an (non

exhaustive) overview of companies which are developing

initiatives.

Cisco

As described above, Cisco has the “Open Network

Environment” which is focussed to make networks more

open, better programmable and make networks application

aware. Coupled with this is OnePK, the API platform for

developers.

In November 2013 Cisco introduced the “Application

Centric Infrastructure” (ACI) which should even better

collaborate with applications to make resources on-

demand available. ACI is mostly positioned at datacenters.

Cisco makes use of the “eXtensible Network Controller”

(XNC) which currently supports OpenFlow version 1.0.

Cisco SDN switches

Going by the information on the Cisco site, several switches

can be utilized for SDN. When looking at, for example, the

Catalyst 3850, its description says:

The heart of Cisco Catalyst 3850 is the new ASIC with

programmability for future features and intelligence with

investment protection. The new ASIC provides a foundation

for converged APIs across wired and wireless, software-

defined networking (SDN) support, and Cisco One Platform

Kit (OnePK).


10 of 23

A similar statement can be found with other switch models

as well. However, looking at the datasheets of these

switches, nothing can be found about SDN or the support

for OpenFlow or ONE. So it’s not clear to what extend these

switches can really be deployed in an SDN infrastructure.

The same goes for the Nexus 3000 and Nexus 3100 series

of switches. The general description mentions support for

OpenFlow and OnePK but nothing in this regard in the

datasheet.

The Nexus 9000 series is built for Application Centric

Infrastructure (although these switches can also be

deployed in non-ACI mode, then these switches are

“regular” Nexus switches). So far, the Nexus 9000 is the

only product line which can be deployed for ACI-mode.

Control of the Nexus 9000 switches in ACI-mode happens

via the “Application Policy Infrastructure Controller”

(APIC). The APIC is expected to be available in the second

quarter of 2014.

The Southbound protocol between APIC and switches is

Cisco proprietary so this does not leave room for other

switch manufacturers. However, there are southbound

APIs by which firewalls or load balancers of other

manufacturers can be integrated (providing these

manufacturers make their equipment suitable) and as such

can be part of the ACI network.

HP

HP is member of the Open Network Foundation and

participates in OpenStack and the OpenDaylight project.

HP’s SDN solution is not just positioned at the datacenter

but is also suited for campus and branch offices.

The SDN strategy of HP is based on open standards and

delivers an SDN solution via a framework called “Virtual

Application Networks”. HP was one of the first companies

to announce support for OpenFlow on their Ethernet

switches. The result is that currently more than 40 HP

switch types support OpenFlow.

In contrast to Cisco, HP implemented OpenFlow in a hybrid

mode, making it possible to easily migrate from a

traditional network to an SDN solution, without having to

bulk-replace all routers and switches.

An own SDN controller was developed, the “HP Virtual

Application Networks SDN Controller”13. This controller is

available as software or as an appliance and communicates

with switches using OpenFlow. Besides this, support for

OpenStack and CloudStack is integrated for fully automated

provisioning of network, storage and compute.

HP is one of the few who actually provides specifications of

their SDN controller. It is claimed that the controller is

capable of handling a maximum of 80000 OpenFlow ports

(1000 – 2000 being typical), a maximum of 2000 OpenFlow


11 of 23

devices (100 – 200 being typical) and is able to handle 1.8

million new flows per second.

Security is one of the main things with SDN. HP is using the

“Sentinel Security Application” which is capable of stopping

threats even before these reach the network. One of the

possible applications of Sentinel is a DNS firewall which can

stop threats at the moment a user wants to visit a malicious

website.

HP SDN switches

The portfolio of HP holds several switches which provides

support for OpenFlow: 2920 series, 3500 series, 3800

series, 5400 series, 8200 series, but also the HP Flexfabric

12900 datacenter core switch (although this switch is not

available yet). HP supports OpenFlow version 1.3 on their

switches since May 2013.

The HP Virtual Application Networks SDN Controller can be

downloaded from the HP website (60-day trial version) and

supports both version 1.0 and version 1.3 of the OpenFlow

protocol.

Juniper Networks

In December 2012, Juniper acquired “Contrail Systems”, a

company that was founded earlier in 2012 and in which

Juniper was a strategic investor.

At September 16, 2013, Juniper announced the “Contrail”14

SDN solution being available. Juniper Networks Contrail

(previously “JuniperV Contrail”) entails all components

needed to create a virtual overlay network. This solution

was tested at more than 40 clients worldwide.

Juniper looks beyond just OpenFlow. Where OpenFlow

mainly speaks about separation of flow control and packet

forwarding, Juniper adds another two dimensions: Network

Services and System Management. OpenFlow is being seen

as “just a protocol and probably not the most important

one”, where OpenFlow can not solve the most important

problems, which can be done with a broader SDN approach.

The Contrail system consists of two main components: The

Contrail SDN controller and the Contrail vRouter. The

Contrail SDN controller is a logically centralized, but

physical distributed SDN controller which is responsible for

management, control and analytical functions of the

virtualized network.


12 of 23

The Contrail vRouter is a forwarding plane (of a distributed

router) which runs on the hypervisor of a virtual server. It

extends the network of physical routers and switches in a

datacenter to a virtual overlay network.

The protocol between the Contrail SDN controller and the

Contrail vRouters (Southbound protocol) is based on the

XMPP protocol which was already supported as a control

protocol by most of the Juniper hardware.

Contrail is designed to operate in an Open Source cloud

environment and integrates with, for example, OpenStack

and CloudStack. By using open standards, vendor lock-in is

prevented.

Contrail is available under the Apache 2.0 license. This

means that everyone can use and modify the code without

being obliged to disclose the modifications. Additionally,

there is a commercial version of Contrail for which Juniper

can provide support. The Open Source version has exactly

the same functionality and scalability as the commercial

version.

Juniper SDN switches

Because Juniper is using XMPP as Southbound protocol

which is already used as control protocol for Juniper

hardware, several different switches are compatible.

In March 2013 Juniper introduced its first “programmable

core switch”, the EX9200. Unfortunately, there is no

upgrade path from the existing EX8200 core switch to the

EX9200 and line cards of the EX8200 are not forward

compatible.

Juniper also has the “MX Series 3D Universal Edge Routers”

which are closely aligned with Juniper’s SDN and NFV

strategy. The architecture of these routers provides

separation between control, management, services and

forwarding planes.

Brocade

Brocade is one of the first members of the OpenDaylight

project and follows a hybrid approach in regards to the

implementation of OpenFlow on the MLXe platforms. This

ensures that one switch port can use traditional routing or

routing via OpenFlow at the same time. This is called

hybrid-port mode.

Brocade is supporter of open solutions and believes that

openness is crucial for the success of SDN. The

OpenDaylight project is in line with this vision.

Because Brocade is compliant to the OpenFlow standard

they can work with every controller, Open Source or

proprietary, which also complies to this standard. Brocade

works with OpenDaylight to design and build a common

and open controller.


13 of 23

Brocade SDN switches

Brocade uses virtual routers which can be deployed for

Network Functions Virtualization. These virtual routers

were developed by a company called “Vyatta”, which was

acquired by Brocade in November 2012.

At this moment, the “Vyatta 5400 vRouter” is already

available. The “Vyatta 5600 vRouter” will be available in

spring 2014. These virtual routers are more related to NFV

rather than SDN.

With respect to physical devices offers the MLX series

support for OpenFlow version 1.0 in hybrid-port mode.

Additionally, OpenFlow (v1.0) is supported by the NetIron

XMR series, the NetIron CER2000 series and the NetIron

CES2000 series.

Plexxi

The starting point of Plexxi is that conversations on the

network should be able to determine how the network

looks like, or at least how the path between two endpoints

look like. And although network conversations are

important, some conversations are more important than

others. Therefore it is important to determine relationships

between communicating elements en determine what is

important within these conversations, like bandwidth,

jitter, latency, security or something else.

With this in mind, Plexxi developed an SDN controller, the

“Plexxi Control”15, which has a real-time, comprehensive

overview of the entire network to determine the most

efficient path for a specific communication flow. Plexxi has

named this “Affinity Driven Networking”.

Affinity refers to different resources within a datacenter

network which are needed to run a specific application or

to provide a specific service. These resources are (physical

or virtual) compute, storage and networking. This

collection of resources is called an “Affinity Group”.

A traditional network strives to make these affinities

irrelevant so that a uniform network can be deployed and

all applications can have the same resources available.

However, it would probably be better when resources are

made available based on what is needed for specific

applications. Therefore, the network should be organized

non-uniform so that the largest amount of available

resources is there where it is needed most (and average at

places where capacity is less needed).

The software of the Plexxi Controller discovers

automatically which capacity is needed for specific

affinities and configures the network dynamically to meet

this capacity requirements. The affinities can be configured

manually or being discovered automatically, for example

based on TCP/UDP port numbers.


14 of 23

The affinities look like what Cisco is doing with ACI with

the configuration of policies and the mapping of

relationships and flows. Both the policies of Cisco and the

affinities of Plexxi specify things like priority of a specific

flow.

It is striking to see that both Plexxi and Cisco talk about

“Application Centric infrastructure”.

Plexxi SDN switches

Plexxi offers two types of switches for connecting servers:

the “Plexxi Switch 1” and the “Plexxi switch 2”. The first one

provides a switching capacity of 1.28 Tbps, the second

switch a capacity of 2.56 Tbps. Both switches are controlled

by the Plexxi Controller using a proprietary protocol.

Next to these two switches there’s the “Plexxi Switch

Interconnect” switch, which is connected in a ring-topology.

The server switches are in turn connected to this ring.

Communication between controller and switches is done

via a proprietary protocol. In contrast to many other

manufacturers, Plexxi does not use OpenFlow.

Big Switch

Big Switch Networks is an SDN start-up and was founded in

2010. To their own saying, they are market leader in Open

Source SDN products.

Big Switch has developed their own, commercial SDN

controller, the “Big Network Controller”16. This controller

forms the basis for the “Open SDN Suite” which provides

for network-wide automation en dynamic response to real-

time events. The “Big Network Controller” is based on the

Floodlight controller of the Project Floodlight.

The Big Network Controller is a centralized control system

with a distributed data store for redundancy and

scalability. Multiple controller nodes can be configured in a

cluster for high-availability. These controllers can then

switch-over to each other in case of issues. The controller

comes in both a virtual edition and a physical appliance.

As the Big Network Controller is based on the Floodlight

controller, both support the same version of the OpenFlow

protocol, which is version 1.0.

Big Switch SDN switches

Big Switch does not build any hardware switches

themselves but provides, in the form of “Switch Light”, an

Open Source software platform for physical, bare-metal

switches and switches within hypervisors. Switch Light

provides an OpenFlow data plane for SDN.

Besides the Switch Light, there’s the “Big Virtual Switch”, a

network virtualization appliance for the datacenter, based

on an OpenFlow switching fabric. This switch dynamically


15 of 23

segments the network and when being used with, for

example, the OpenStack plugin, the Big Virtual Switch can

dynamically discover whether there are new workloads or

whether existing workloads have changed. Following this,

new virtual network segments can be created, in line with

previously defined policies. Each virtual network segment

supports broad security possibilities, Quality of Service and

other policies.

Use cases

Before diving into possible applications for SDN, let’s see

what the actual reason is for SDN.

In the past 20 years there were many innovations in

equipment that is used to interact with applications and

services. Additionally, individuals are using more and more

devices per person and all of these devices need access to

the network.

The network itself however, has never changed. And while

in the area of server virtualization there has been great

progress in, for example, speed of deployment, the network

has lagged behind. Therefore, it is time for change so that

the network can adopt quickly to necessary changes.

From a traditional point of view, the best performing and

most stable networks are those which are built with

purpose-built hardware, like routers and switches. But it

takes a lot of time to design this kind of hardware, build it,

and write appropriate software for it. That means that

adding features on an ad-hoc basis is nearly impossible. So

customers in need of some new functionality almost always

get to deal with the roadmap of manufacturers.

These limitations with respect to hardware, and this

limitations with respect to flexibility are the main reasons

why companies are not able to innovate at the speed they


16 of 23

would like and are not able to respond to changes and

customer demand.

However, now is the time to change. Thanks to advances in

“off the shelf” hardware, it becomes possible to make a shift

from “networking in hardware” to “networking in

software”. And this shift is what forms the basis of SDN and

NFV technologies: software can be detached from

hardware.

The resulting benefits include, but are not limited to:

• Reduction of Capex: Network functionality runs on

standard, off the shelf hardware;

• Reduction of Opex: Because network components

are easy to program, it becomes easier to design,

deploy and manage infrastructures;

• Flexibility: Organisations are able to quicker deploy

new applications to respond to changing demands;

• Innovation: Organizations become able to design

new types of applications, new services and new

business models;

• It becomes possible to provide new network services

without the need to configure individual devices and

without being dependant on manufacturers for

providing new functionality.

With this is mind, possible uses of SDN can be explored.

The emphasis is on “possible” because some uses may not

be easy, or even impossible to implement in real networks.

Network Access Control

The idea behind SDN is that every allowed flow should be

defined on forehand. This way, one can determine which PC

(or user) is allowed access to which server, application,

internet, etc.

When a PC wants to send data via the network, the first

packet that reaches the (OpenFlow) switch will be

forwarded to the SDN controller. The SDN controller will

check who the originator of the packet is, what the

destination is, and whether the flow is allowed or not.

This form of access control can be used to allow or deny

users access to the network or specific resources. But this

form of access control can also be used for wireless clients

and Bring Your Own Device (BYOD) applications. Also

allowing guests to the company network will become quite

easy because these guests can be placed in a virtual

network within the company network and allowed access

to, for example, only the internet. In this situation, there is

no need to create separate vlans or to do any device-

specific configuration at all. It will still be necessary to

authenticate users but this action can be delegated by the

SDN controller to an authentication server.

For an additional level of security, traditional vlans make

use of private vlans so that devices within the same vlan

are not able to communicate with each other. With SDN,

configuration of private vlans is no longer needed and the


17 of 23

desired (layer 2) separation can be realized with the SDN

controller.

Because the security policy is defined centrally on the SDN

controller, it is easy to audit this policy. Or at least easier

than having to audit multiple rule bases on multiple

physical firewalls and access-lists on routers.

Multi tenant network

One of the most obvious applications of SDN is probably the

multi tenant network. As described above, when guest-

users can be placed inside their own virtual network, that

of course is also possible with multiple tenants inside a

datacenter.

On a logical level, tenants can be completely separated from

each other while still using the same physical

infrastructure. The advantage over the configuration of

vlans (besides the fact that device-level configuration is no

longer needed) is that tenants are now allowed to use

overlapping IP-space, something that is not just possible

inside a traditional network.

Quality of Service (QoS)

As mentioned in the “Network Access Control” section, it is

the aim that every allowed flow is specified in advance.

With this configuration it is also specified which priority

should be given to a specific flow. In other words, what the

QoS settings should be.

In traditional networks, QoS can be configured quite well.

But once configured, it is static. With SDN is becomes

possible to execute specific policies based on different

circumstances.

Internet Service Providers (ISPs) would get the possibility

to easily rate-limit Over The Top (OTT) traffic (like video)

and it would become easier to enforce the “Acceptable Use

Policy”.

But also other types of companies could benefit from a

dynamic QoS, like:

• Prioritize video traffic when there’s an in-company

webcast;

• Prioritize HTTP traffic during lunch time;

• Prioritize SAP traffic during an end-of-month run;

• Prioritize Citrix traffic when many people are

working from home.

The possibilities are probably endless. And the result is that

resources are available there where the business needs it to

be.


18 of 23

Layer 2 connectivity

When an enterprise is comprised of multiple,

geographically dispersed datacenters, it may be useful to

have layer 2 connectivity between the different locations.

When layer 2 connectivity is established, it no longer

matters where a (virtual) server is active. The only possible

drawback is the location of the layer 3 gateway. It could be

possible that a server runs in one datacenter while the

layer 3 gateway is active in another datacenter, causing

traffic to travel across the interconnect between the

datacenters.

When using SDN, it doesn’t matter where a specific server

runs. Because routing is provided by the SDN controller,

there is no need for a layer 3 gateway. This makes it

possible to stretch layer 2 across multiple locations and

still route traffic in an optimal way.

Limitations

When using OpenFlow as a protocol to configure flow

entries in a switch, it should be realized that a specific entry

is for a specific flow. All consecutive packets in the same

flow will follow the same path as the initial packet. It is not

possible to do “per packet” forwarding, for example to load

balance. Because if that would be done, not only the first

packet of a flow would need to be sent to the SDN

controller but also all following packets. The SDN controller

would therefore be in the forwarding path of the flow, and

would most likely become the bottleneck in regards to

performance.

Another limitation, or at least a challenge, is

troubleshooting. Because traffic flows are determined in a

dynamic way, it is possible that traffic from source A to

destination B will be routed via another path than a flow

from source A to destination C, even though destinations B

and C are in the same subnet. And it’s also possible for a

flow to follow path A at one point in time, but go via path B

a moment later, based on (external) circumstances.

Collateral damage

Some functions which are traditionally taken care of by

specific appliances can now be done using SDN. For

example, functions like firewalling and load balancing. But

also routing is done by SDN. So are these types of

appliances become obsolete when SDN is going to be

introduced?

When looking at a firewall as a simple packet filter, it seems

like that functionality can easily be handled by the SDN

controller. After all, it’s the SDN controller where a flow is

defined – and thus permitted.

In regards to load balancing it is not possible to do per-

packet load balancing. But balancing per flow is possible.

And with that functionality in the SDN controller, a


19 of 23

traditional load balancer may possibly become superfluous.

When SDN goes one step further and actively monitors how

busy a specific server is, and can balance flows based on

that information, then also for that kind of functionality a

load balancer is no longer needed.

Routers make decisions about where to send a packet. That

intelligence is taken over by the SDN controller, so no

router is needed anymore.

Looking at these examples it is clear that some

functionalities are going to be replaced by SDN. But when

more is needed than just packet filtering (like deep packet

inspection) there is still going to be a need for a dedicated

appliance. The SDN controller will then just make the

decision to route a certain flow via a firewall for inspection.

In this setup, by the way, it is not necessary for the firewall

to be in the “physical” path of the flow.

The need for load balancers will probably decrease, for

sure when more intelligent SDN solutions will be

implemented in which the SDN controller gets feedback

from the network and from the applications.

Within a LAN environment, routers will not really be

needed anymore, all that is needed is SDN enabled

switches. For connections with the outside world things

may not be so obvious. BGP peerings will still be needed as

a way to exchange external route information. This

functionality could still be provided by a router. Then again,

software like “Quagga” (previous “Zebra”) makes it possible

to do BGP peering on general-purpose hardware.

Security

Why would security be of extra concern with SDN? Well,

one of the reasons is that SDN technology is still very

premature. So almost guaranteed there will be security

flaws. Besides, when all control about flows is with one

device, it is clear that this device needs protection. Because

he who controls the controller, controls the network and

thus the application behaviour.

The OpenDaylight controller can be configured with

different types of users like “System Admin”, “Network

Admin” and “Network Operator”. HP’s SDN controller does

not (yet) support any form of role-based access.

Before controller and switch can communicate with each

other, they need to know about each others existence.

Therefore, a switch will be (manually) configured with the

IP-address of the controller. Then, a switch can initiate a

TLS-encrypted connection with the controller and both the

switch and controller authenticate using certificates. This

process prevents someone from installing a rogue

controller in the network.


20 of 23

Communication between switches and controller can also

be run over standard TCP. In this case, additional security

measures should be taken to prevent eavesdropping.

It could be possible for some internal server to be

compromised after which an attacker could use this server

as step stone to the rest of the internal network. In a

traditional environment, access to systems is controlled

with for example an access-list of firewall. However, if such

a measure is not in place the attacker would have free

access due to the fact that routing is just available.

In an SDN infrastructure, there is only routing for defined

flows. That means that a random server does not have

routing to the SDN controller. So because of the lack of

routing, it could be argued that an SDN infrastructure is

more secure than a traditional infrastructure.

An attacker could cause quite some damage when taking

over the SDN controller, like shutting down the entire

network. But it’s also possible that the attacker has other

goals and only wants to manipulate specific flows, which

can be of importance with stock-trading.

It is also important to look at the security of the APIs that a

controller has to have for communicating with applications.

Besides the fact that the SDN controller itself is a software

application which will undoubtedly contain bugs, also

software applications of third parties will contain bugs,

making it possible for such an application to claim

disproportionate resources with the SDN controller.

In the context of security it is also important to think about

availability. What happens when the controller fails? The

OpenFlow protocol describes two failure modes: “fail

secure mode” and “fail standalone mode”. One of these

modes will be chosen, depending on the configuration of

the switch. It is up to the switch to detect failure of the

connection with the controller, for example using timeouts

for echo-requests.

In “fail secure mode”, the existing flows will continue to be

active but creation of new flows won’t be possible because

there won’t be any communication with the SDN controller.

The existing flows are subject to configured timeouts, so

eventually all flows in a switch may be gone.

In “fail standalone mode”, the switch will behave like a

traditional switch and all packets will be forwarded as with

a traditional Ethernet switch. The “failure standalone

mode” is usually only available on hybrid switches.

Related to availability is the question about how to make a

backup of the SDN controller configuration, and especially

how to restore this backup. Because, when the controller is

down, there is no routing in the network so how is a file

from the backup server going to be send to a new

controller. The conclusion that follows is that a controller

should never be a single machine.


21 of 23

The OpenFlow specification allows the use of multiple SDN

controllers in which one can take the role of “master”. The

Cisco ACI solution dictates the use of at least three

controllers.

Practice

Although Google is one of the companies that implemented

SDN, it seems like there are not many real implementations

besides some setups in university networks. One of the

reasons for this is probably the lack of real

implementations causing companies to be reluctant to

implement SDN. So a chicken-and-egg situation.

Also, there are some serious issues to be resolved first

before an extensive implementation can take place. One

thing is scalability, how many switches is a controller

capable of programming within an acceptable timeframe?

Or how many flow entries can be pushed to a switch within

a reasonable amount of time?

Obviously it is possible to define flows on forehand and

push these to the switches. In that way, there is central

control over flow entries but after that it’s a relatively static

environment. Probably comparable with a traditional

network.

Also the migration path will play an important role. Some

manufacturers offer hybrid switches, making it possible to

gradually migrate. Other manufacturers do not offer a

hybrid solution so there would need to be a “big bang”

scenario rather than a migration. And that may be a

frightening thought.

In regards to a hybrid solution, this should not only go for a

switch but there should also be the possibility to combine

OpenFlow switches with traditional networking equipment

like routers, switches and firewalls.

Future

Despite the fact that SDN is still in its infancy, it most

definitely offers new possibilities. It’s just the question

whether companies will need these possibilities or at least

recognize the value of it. And although SDN is still in the

“hype-phase” there is also a clear movement to reality.

Nevertheless, as described in the introduction, looking at

the speed of adoption of IPv6 it remains the question how

fast SDN will be adopted. The usefulness and necessity will

have to become very clear.

SDN will most likely add real value when implemented as

complete framework in which virtual servers can be

spinned up automatically, and in which there is a solid

feedback loop from the network.


22 of 23

Many manufacturers jumped onto SDN. Many of those

support open standards like OpenFlow and develop their

own standard at the same time. The question remains

which system will end up as best.

Cisco with it’s ACI platform uses a proprietary Southbound

protocol but offers APIs so that third parties can interface

as well. Juniper uses XMPP as Southbound protocol and

although that is an open protocol, if no other controller- or

switch manufacturer is going to adopt it, there will still be

a reasonable chance to vendor lock-in.

HP opened an “AppStore” for SDN applications, offering

unlimited possibilities for developers.

Undoubtedly many new, SDN related companies will be

born over the next few years, providing more and new

applications which no one has thought of before. To date,

there are a lot of SDN flavours already and many will

appear in the coming years. For companies which want to

adopt SDN, it is not going to be easy to make a choice

between all the vendors and all the offerings without

running the risk to vendor lock-in and without running the

risk to an unsupported network when a start-up company

doesn’t survive. For now, the marketing machines will run

at full speed!

References

1 www.opennetworking.org

2 www.openstack.org

3 www.cisco.com/go/one

4 www.cisco.com/go/aci

5 www.cisco.com/go/xnc

6 http://www.opendaylight.org/

7 www.projectfloodlight.org/

8 www.bigswitch.com

9 http://portal.etsi.org/NFV/NFV_White_Paper.pdf

10 http://www.etsi.org/news-events/news/700-2013-10-etsi-publishes-first-nfv-specifications

11 http://www.mikrotik.com/software.html

12 http://www.nongnu.org/quagga/ 13 http://h17007.www1.hp.com/us/en/networking/products/network-

management/HP_VAN_SDN_Controller_Software/index.aspx#tab=TAB1

14 http://www.juniper.net/us/en/products-services/sdn/contrail/

15 www.plexxi.com/products/plexxi-control/

16 http://www.bigswitch.com/products/SDN-Controller

All opinions expressed in this paper are my own and do not reflect those of the company I work for

© 2014 – Peter van der Voort – [email protected]

sdn - beyond the obvious

Technology