Software-Defined Networks
Steve Goeringer
Abstract
This white paper provides an introduction to software-defined network concepts. It covers related areas
of work, discusses deficiencies of current networking practices, and defines software-defined networking
(SDN). Discussion includes a review of SDN architecture, components, interfaces, and applications.
©2015 Polar Star Consulting, LLC™
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information
Introduction
Software-defined networking continues to be one of the most hyped technology evolutions in
information and communication technology. It’s been forecasted to achieve massive market growth, in
one study touching a market of $1T US by 2019. Certainly, the market will not achieve $1T by 2019, but
the study certainly emphasizes how very excitable the market has become about software-defined
networking. Behind the hype, however, is a technology with profound benefits to industry and possibly
essential to intelligent evolution of today’s massive and complicated network infrastructures.
Software-defined networking (SDN) centralizes network control, moving it from switches and routers to
SDN controllers. This allows network traffic to be managed in the context of an entire network rather
than from interconnected but locally controlled devices. SDN controllers use a standard interface, often
OpenFlow, to program tables in controlled network elements. These tables, called flow tables, allow
very granular control of network traffic, much more so than Ethernet based switching or IP based
routing. Finally, SDN allows network operators to programmatically interface with controllers. See Figure
1.
This white paper reviews SDN at a very high level. It discusses problems of current network solutions.
Then it reviews SDN as a concept and shows how it mitigates some current problems. General
architectural considerations are shown, and SDN components are defined. The paper concludes with a
discussion of the challenges of implementing SDN and recommends that new information and
communications technology initiatives consider SDN.
Figure 1: Open Network Foundation’s software-defined network
architecture (11)
P a g e |2
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
Related work
Polar Star Consulting has multiple on-going research efforts on SDN. Several white papers are available
upon request. A lab tutorial has been prepared and we continue to do research into the myriad of SDN
use cases.
The driving organization behind SDN is the Open Network Foundation (ONF). The ONF published
standards, recommended practices, and published case studies. Two critical documents are “SoftwareDefined Networking: The New Norm for Networks” (1) and “OpenFlow Switch Specification”, now on
version 1.5 (2).
Implementation of SDN, however, varies widely and the hype cycle is in full swing. Each information and
computing technology solutions provider has their own notion of how their customers can best
implement and benefit from SDN. However, their ability to deliver must be scrutinized carefully with
many providers offering SDN solutions that you can’t actually buy yet. However, there are important
initiatives that can give insight and from which insights can be earned. Specifically, open source software
solutions for creating SDN controllers and switches.
The most impactful SDN controller today is probably OpenDaylight (3), a Linux Foundation collaborative
project. OpenDaylight (ODL), in fact, is breathtakingly audacious when the full scopes of their initiatives
are understood.
SDN switches are as important as SDN controllers. There are three initiatives to understand and track
here. One is the OpenWrt initiative(4). Initially targeted at providing an open distribution to create Linux
firmware for consumer grade wireless routers, several modern system on a chip (SoC) routers are able
to implement rather complete Linux networking solutions. Consequently, some researchers have
integrated OpenFlow versions 1.0 and 1.3 into OpenWrt. This puts doing SDN experimentation in the
hands of the hobbyist or serious scientist at prices that are remarkable ($35 for a fully featured
OpenFlow router is compelling). A more notable initiative is Open vSwitch (5)(6). This largely
independent open source software project provides a virtual switching solution suitable for deployment
on a wide range of platforms, including Linux. It opens the door to developing high performance open
SDN switching solutions on bare metal switches. A final open switch initiative that must be understood
is still in infancy. Open Network Linux (7) is a subproject of the Open Compute Project (8).
Network Functions Virtualization (NFV) is a key related work area to SDN. The European
Telecommunications Standards Institute (ETSI) is spearheading work on NFV. NFV compliments SDN
nicely, but they are mutually independent – NFV can be implemented without SDN solutions, and SDN
does not require NFV (9). Polar Star has prepared white papers on NFV that are available on request.
P a g e |3
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
Problem statement
Enterprises and service provider’s information and
computing technology infrastructure encompass
thousands of network elements and tens of
thousands of servers supporting hundreds of
applications. These applications each have diverse
information and computing technology
requirements. And the information and computing
infrastructure installed to support them has
typically been deployed over one or two decades.
The result is complexity, and complexity leads to
stasis. (1)
Figure 2: Complexity as illustrated by the Concorde Cockpit
Consider a typical IT environment. Traditional IT solutions require a great deal of activity to make any
change. To add, move, or configure any device, staff must touch multiple network elements (switches,
routers, firewalls, and more) and server support applications (authentication portals, identity databases,
etc…) and configure interdependent access control lists (ACLs), virtual local area networks (VLANs),
quality of service (QoS), and many other mechanisms using device-level interfaces and tools.
Interdependencies of all these policy elements are context specific, needing to account for network
topology, proprietary network element uniqueness (including which versions of software and firmware
are on each network element). Service providers, enterprises, carriers, and solutions providers (both
hardware and software) find it increasingly difficult to scale IT and network solutions to provide the
applications employees and processes need to satisfy customers and execute missions.
Enterprises today cannot be static. Traffic patterns within modern networks are highly varied and
change rapidly. Most enterprises must support access to corporate infrastructure from mobile devices
such as smartphones, tablets, and notebooks – both locally and remotely. Rapidly evolving IT strategies
and business needs require agile and dynamic access to applications, telecommunications
infrastructure, and a wide range of IT resources on demand. Managing operations expenditures require
streamlined staffing which drives a need for self-service provisioning and trouble resolution. Big data
applications need unprecedented numbers of connections supporting large flows of data on demand.
Service providers and carriers have similar requirements. They need to deploy capabilities and services
in response to the needs of enterprises. If the enterprise environment is dynamic, so must be the service
provider environment. Unfortunately, traditional service provider services are enabled by proprietary
solutions limited according to solution providers’ product release cycles (hardware and software).
Moreover, scalability requires solutions to support concurrent customers (multi-tenancy) each requiring
different combinations of services implemented using diverse policies with industry unique performance
requirements. Achieving high-performance, low-cost connectivity supporting millions of devices requires
scalability (hyper-scale) that cannot be achieved through traditional network methods and practices.
P a g e |4
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
Solution
Software-defined networking (SDN) employs a few
fundamental engineering concepts to achieve
flexibility and agility. It centralizes network control
so that traffic can be managed in context of
multiple network elements rather than one. This
control is facilitated by fine grain control at
network elements using a flow table that defines
flows on which to take specific action. Flows are
defined in terms of packet characteristics (10)
relevant to the application supported (see side
bar). Finally, SDN introduces interfaces for
interacting with network control and
interconnecting network control with network
elements. The overall architecture as defined by
the Open Network Forum (11) is shown Figure 3.
Does this solve the problems outlined previously?
It does to at least some degree. The network
appears to the applications using the network as a
single, logical switch. Centralizing network state
and providing interfaces to interface with network
control provides network managers the features
they need to programmatically interface with the
network to configure, manage, secure, and
optimize network resources dynamically. (1)
What is a flow?
The concept of a flow is not defined in the body of
SDN standards and other supporting
documentation. Given the nature of OpenFlow,
the definition for a traffic flow (10) as defined by
the IETF is insufficient. Nor are the definitions of
flow as applied to traffic characterization (e.g.,
NetFlow and sFlow).
Why is such a fundamental and pervasive term
missing in the body of SDN documentation?
Because flows are application specific, in terms of
which OpenFlow version is employed, in terms of
the actual ICT applications being supported (e.g.,
Microsoft Office, Web Servers, Hadoop, etc…), and
the SDN functions being invoked.
For a given SDN service, the notion of flow should
be explicitly defined. This should include packet
header elements, protocol state considerations,
and more. Thorough research of OpenFlow
standards is highly recommended.
Design goals
SDN will exhibit several characteristics. These are
identified by the ONF as follows (11):







Direct programmability
Agility
Central management
Reliable
Secure
Granular network control
Open standards-based
 Vendor-neutral
P a g e |5
Figure 3: ONF’s software-defined network (11)
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
Architecture
The SDN architecture is not
much more complicated than
the concepts defined above.
Architecture components are
organized functionally into
three planes – the application
plane, controller plane, and
data plane. These are
nominally referred to as levels
to differentiate from OSI layers
in the data plane. The layers
Figure 4: ONF’s SDN architecture
are interconnected by
controller plane interfaces –
the Application-Controller Plane Interface (A-CPI) and the Data-Controller Plane Interface (D-CPI).
Management interfaces will inevitably be necessary to administer many features of each plane. The
resulting architecture is illustrated in Figure 4. (12) It’s essential to view this architecture as a functional
representation – actual implementation may have a given physical device participate in multiple planes.
Components
Conceptually, SDN encompasses only a few components. Components are realized primarily as software
elements, but are often distinct physical devices.
 Controllers – The primary element of the controller plane. Implemented as software on a
server, controllers have exclusive control over a set of resources exposed by the D-CPI. The
purpose of the control plane is to provide network services to the applications it supports. A
controller may support many applications. A given SDN control plane may contain multiple
controllers organized as necessary for reliability and scalability. Controllers can be implemented
as stand-alone servers or installed on virtual machines in a virtualized environment.
 Network elements – The data plane is comprised of network elements. Network elements
contain traffic forwarding and processing capabilities. These capabilities are locally controlled by
a flow table as specified in ONF’s OpenFlow standards. Controllers interface to network
elements (and specifically the flow table) via the D-CPI interface. The most common examples of
SDN network elements are routers and switches, but network appliances should be included as
well. Examples include firewalls, application delivery controllers, SSL accelerators, WAN
optimizers, load balances, and more.
 Applications – Applications bridge business and mission needs to the SDN infrastructure.
Applications may be very primitive and encompass very basic features – such as the SDN
equivalent of the Internet Protocols “ping” functionality or creating a MAC learning domain such
P a g e |6
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
as an Ethernet hub. Applications might also leverage other applications and implement complex,
transformational services such as a business aware connectivity manager that considers current
business bandwidth needs against available network resources and optimizes connectivity of
key business centers in real time. Applications interface with controllers via the A-CPI.
Applications may run remotely from controllers, or may even run on the controller server or
virtual machine.
Interfaces
As described above, the SDN architecture includes both an application-controller interface (A-CBI) and a
data-controller interface (D-CBI). The ONF specifies D-CBI interfaces under their OpenFlow technical
specifications, available on-line at https://www.opennetworking.org/sdn-resources/technical-library.
The A-CBI is not specified by the ONF. However, SDN components may support additional interfaces as
well.
ONF specifies two D-CBI interfaces – the OpenFlow Switch
Protocol (OF-SWITCH) and the OpenFlow Management and
Configuration Protocol (OF-CONFIG). There are already several
versions of each of these, with the most recent switch protocol
being version 1.5 and the most recent management and
configuration protocol being version 1.2. When most people talk
about OpenFlow, they are usually referring to the switch
protocol; the management and configuration protocol is usually
explicitly referred to as OF-CONFIG.
OF-SWITCH provides an SDN controller an interface to add,
update, and delete flow entries of flow tables in SDN network
elements (nominally switches). See Figure 5. Each flow table
contains a set of entries and each entry consists of match fields,
counters, and actions to apply to matching packets (flows). (13)
OF-SWITCH is the only standard protocol supporting this
functionality.
Figure 5: ONF OF-Switch components (13)
OF-CONFIG provides a management interface to SDN network elements. It connects an OpenFlow
configuration point process, which is not required to be associated with an SDN controller, to an
operation context of the network element. Network elements must implement NETCONF as the
transport protocol for management functions to support OF-CONFIG. OF-CONFIG implements a UML
compliant data model encoded in XML for SDN network elements. OF-CONFIG has a companion YANG
module distributed separately to aid in implementation of this data model. (14)
P a g e |7
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
The A-CBI interface is not specified by ONF. Typical implementations use RESTful (Web 2.0) interfaces,
Java, and Python. Some SDN controllers also include a graphical user interface, though functionality will
be relatively limited. OpenDaylight uses a full Java code management system, including YANG support.
Applications
Given all the abstraction included in describing SDN, it might be hard to understand what an SDN
application (service) might be or look like. At the most fundamental level, SDN applications are
everything you may want a network element to do. This is very important to understand. Without
specifically configuring a flow table, an SDN network element will not do anything. Some of the first
applications an SDN network programmer might create are these basic applications (15):
 Network connectivity (“ping”).
 A basic hub that will flood any packet that arrives on a particular port of a switch out all the
other ports (it’s interesting to do this at both Ethernet and IP layers).
 A MAC learning switch that keeps track of where the host with each MAC address is located and
accordingly sends packets towards the destination and not flood the packet like a hub (e.g., SDN
network elements don’t just “know” ARP).
 Stateless load-balancer for HTTP.
 Content-aware load balancer.
Basic is relative – there is a lot to learn and do when programming these applications. Fortunately, many
of the basic switching and routing services are already written and available for inclusion in your
network. Integrating these are controller specific, however.
At a more meaningful level, SDN applications allow development of highly sophisticated services very
hard to create in legacy networks. For example, an SDN programmer could create a service that
interfaced with OSPF routing logic and packet header information to determine which flows should be
forwarded to an encryption device.
Fortunately, the ONF provided support for hybrid operation. Hybrid operations allow legacy switching
and routing functions to be used for some ports and SDN applications applied to other ports. After all, it
took a long time and a lot of work to build Ethernet and IP to work as well as they do today. Network
operators should be reluctant to move to SDN unless there is specific functionality legacy network
technologies cannot achieve.
Analysis
Does SDN fulfill its design goals? Within the enterprise environment where campuses, data centers, and
cloud environments prevail, the SDN design goals are expected to achieve very specific benefits.
Campuses should benefit from converged infrastructure, eliminating multiple overlay networks to
support different services, including support of mobile environments. User experience in campus
P a g e |8
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
networks should also be more
managed. Data centers should
achieve hyper-scalability, automated
VM migration, improved integration
and efficiency. (1) See Figure 6.
Service providers and carriers have
different needs but can also expect to
achieve important benefits. SDN
should enable service providers to
implement a utility compute model
approach to services, enabling an ITas-a-Service (ITaaS) paradigm. They
should be able to orchestrate custom
and on-demand services, and also
enable a wide range of self-service
capabilities. And they should be able
to improve cost management by multitenancy, improved resource efficiency,
Figure 6: SDN benefits in the enterprise environment
proactive and service oriented cost
management, and improved service
delivery intervals. (1) See Figure 7.
SDN is not essential to achieving these
goals, however. Even using legacy
techniques, many of these features
can be implemented by programming
mediation environments. In fact, this is
largely what OSS/BSS (Operations and
Business Support Systems) do.
Figure 7: SDN benefits in the service provider environment
However, adaptation interfaces need
be written for every equipment and
application vendor and updated for each version of vendors’ software or hardware.
The ONF summarizes how SDN is essential to evolving networks in the foundation white paper,
“Software-Defined Networking: The New Norm for Networks.” (1) Some specific feature benefits
highlighted in the white paper are quoted below:
P a g e |9
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
 “Providing self-service provisioning, whether in a private or public cloud, requires elastic scaling
of computing, storage, and network resources, ideally from a common viewpoint and with a
common suite of tools.”
 “Handling today’s “big data” or mega datasets requires massive parallel processing on
thousands of servers, all of which need direct connections to each other.”
 “By centralizing network state in the control layer, SDN gives network managers the flexibility to
configure, manage, secure, and optimize network resources via dynamic, automated SDN
programs.”
 SDN architectures support a set of APIs that make it possible to implement common network
services, including routing, multicast, security, access control, bandwidth management, traffic
engineering, quality of service, processor and storage optimization, energy usage, and all forms
of policy management, custom tailored to meet business objectives.”
There remain, however, significant challenges in realizing an SDN. Equipment and software providers
have very smart people and many years bringing value to their customers. Proprietary implementations
can provide key competitive advantages to enterprises and service providers. Hardware support varies
dramatically. Many commercial switches and routers support only the first OF-Switch version 1.0
implementation, which is much less capable than OF-Switch version 1.3.2 which is supported by only a
few. Very few network appliances (load balancers, SSL hardware accelerators, WAN optimizers,
encryption devices, etc…) support any version of OpenFlow. It is possible to integrate an SDN using
open source tools and bare metal servers and switches. However, this moves all development
responsibility to the IT enterprise or service provider. Moreover, achieving terabit/second scales as
many environments now require may not be feasible with open hardware and software today.
There are some fundamental issues to track in the SDN standards. Some level of control locality must
continue to exist at each layer of SDN. Interaction and state management of distributed control is largely
not resolved. This may not be a major issue for many network applications, however.
A much more fundamental concern is deployment of SDN controllers in environments requiring high
availability. The primary resiliency schemes used by industry seem to be traditional clustering and
protection mechanisms at the link layer. This does not seem suitable for environments where service
behavior is dependent on network state (such as agile management of shared risk groups or security
domain management).
Conclusions and Recommendations
SDN promises specific and fundamental improvements in information and communication technology
applicable to a wide range of environments. Benefits may include improved cost effectiveness, faster
service delivery, improved customer experience, enhanced scalability, and simplified operations. Most
equipment and software vendors in the ICT space are providing SDN solutions. Recommendations:
P a g e | 10
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
 Current infrastructure should be evaluated to see how SDN can be employed for incremental
improvements
 New initiatives should be required to consider SDN in the solution space, including complete
cost benefit analyses.
References
1.
Software-Defined Networking: The New Norm for Networks [Internet]. Open Networking Foundation; Apr, 2012.
Available from: https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdnnewnorm.pdf
2.
OpenFlow Switch Specification Version 1.5.0 (Protocol version 0x06) [Internet]. Open Networking Foundation; Available
from: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onfspecifications/openflow/openflow-switch-v1.5.0.noipr.pdf
3.
Meyer D. The OpenDaylight Project: Introduction and Overview [Internet]. Linux Foundation; 2014 Jan. Available from:
http://www.1-4-5.net/ dmm/talks/OpenDaylight_SDN_Workshop_AZ.pdf
4.
OpenWrt [Internet]. 2015. Available from: http://wiki.openwrt.org/about/start
5.
OpenvSwitch [Internet]. 2015. Available from: http://openvswitch.org/
6.
WhyOVS [Internet]. 2014. Available from: https://github.com/openvswitch/ovs/blob/master/WHY-OVS.md
7.
ONL [Internet]. 2014. Available from: http://opennetlinux.org/#
8.
OCPNetwork [Internet]. Open Compute Project; 2015. Available from: http://www.opencompute.org/wiki/Networking
9.
Network Functions Virtualisation – Introductory White Paper [Internet]. ETSI; 2012 Oct. Available from:
https://portal.etsi.org/nfv/nfv_white_paper.pdf
10.
Traffic flow (computer networking) [Internet]. Wikipedia; 2015. Available from:
http://en.wikipedia.org/wiki/Traffic_flow_(computer_networking)
11.
Software-Defined Networking (SDN) Definition [Internet]. Open Networking Foundation; Available from:
https://www.opennetworking.org/sdn-resources/sdn-definition
12.
Hood D. SDN architecture [Internet]. TR-502 Open Networking Foundation; Jun, 2014. Available from:
https://www.opennetworking.org/images/stories/downloads/sdn-resources/technicalreports/TR_SDN_ARCH_1.0_06062014.pdf
13.
Anders Nygren ZLK Ben Pfaff Bob Lantz Brandon Heller Casey Barker Curt Beckmann Dan Cohn Dan Talayco David
Erickson David McDysan David Ward Edward Crabbe Fabian Schneider Glen Gibb Guido Appenzeller Jean Tourrilhes
Johann Tonsing Justin Pettit KK Yap Leon Poutievski Lorenzo Vicisano Martin Casado Masahiko Takahashi Masayoshi
Kobayashi Navindra Yadav Nick McKeown Nico dHeureuse Peter Balland Rajiv Ramanathan Reid Price Rob Sherwood
Saurav Das Shashidhar Gandham Tatsuya Yabe Yiannis Yiakoumis. OpenFlow Switch Specification Version 1.3.2 (Wire
Protocol 0x04) [Internet]. Open Networking Foundation; Apr, 2013. Available from:
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflowspec-v1.3.2.pdf
P a g e | 11
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.
14.
Daniel Pitt AS Deepak Bansal Stuart Bailey Thomas Dietz Car Moberg Juergen Quittek Anantha Ramaiah. OF--CONFIG 1.2
OpenFlow Management and Configuration Protocol [Internet]. TS-016 Open Networking Foundation; 2014. Available
from: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflowconfig/of-config-1.2.pdf
15.
Pseudo code of sample applications [Internet]. SDN Hub; 2105. Available from: http://sdnhub.org/tutorials/app-pseudocode/
P a g e | 12
14900 Conference Center Drive
Suite 280
Chantilly, VA 20151
703-955-7770
This paper includes Polar Star Consulting Proprietary Information.