SDN: Software Defined Networking Beyond the Obvious

Software Defined Networking – Beyond the Obvious

Peter van der Voort
Senior Solution Architect
peter@yenniq.nl
January 2014

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?

does it really mean for a company which wants to adopt
this technology?

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.

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.

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.

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.

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

Next, there will be an overview of use-cases, limitations,
security and practice, followed by a brief look into the
future.
2 of 23

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

Table of Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Initiatives ................................................................................................................ 9
Cisco .................................................................................................................... 9
Cisco SDN switches ......................................................................................... 9
HP ..................................................................................................................... 10
HP SDN switches ........................................................................................... 11
Juniper Networks .............................................................................................. 11
Juniper SDN switches .................................................................................... 12
Brocade ............................................................................................................. 12

3 of 23

This is a pretty abstract description but another description
on the same site says:

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.

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.

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.

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
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

4 of 23

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

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.

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.

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.

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.

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.

Cisco ONE is a programmable framework which consists of
three parts:
1. Controllers and agents
2. Programmable interfaces
3. Virtual network overlays

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

5 of 23

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

supports flexible application provisioning of physical and
virtual resources. The APIC will be released in the second
quarter of 2014.

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.

Cisco ONE SDN Controller

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.

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.

Application Centric Infrastructure (ACI)

In April 2013, Cisco donated a large part of the code of their
ONE controller to the OpenDaylight project.

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.

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

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
6 of 23

The Floodlight controller supports OpenFlow v1.0 and
works with physical- and virtual switches.

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.

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.

OpenDaylight supports, but is not limited to OpenFlow. The
OpenDaylight project has supporters like Arista Networks,
Brocade, Cisco, Dell, IBM, HP, Juniper, Microsoft, etc.

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.

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

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.

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.

7 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.

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.

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.

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.
8 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.

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 ondemand available. ACI is mostly positioned at datacenters.

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.

Cisco makes use of the “eXtensible Network Controller”
(XNC) which currently supports OpenFlow version 1.0.

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.

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:

Initiatives

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, softwaredefined networking (SDN) support, and Cisco One Platform
Kit (OnePK).

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.

9 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

10 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.

11 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.

12 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.

13 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 realtime 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

14 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

15 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 devicespecific 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

16 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 guestusers 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.

17 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 perpacket load balancing. But balancing per flow is possible.
And with that functionality in the SDN controller, a

18 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.

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
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

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.

19 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.

making it possible for such an application to claim
disproportionate resources with the SDN controller.

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 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 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.

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.

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.

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.

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,

20 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.

21 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!

22 of 23

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 – peter@yenniq.nl

SDN: Software Defined Networking Beyond the Obvious

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (19)

Similar a SDN: Software Defined Networking Beyond the Obvious

Similar a SDN: Software Defined Networking Beyond the Obvious (20)

Último

Último (20)

SDN: Software Defined Networking Beyond the Obvious