SDN Introduction

©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

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.

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.

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)



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

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



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)

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.

Figure 2: Complexity as illustrated by the Concorde Cockpit



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)

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

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.

Figure 3: ONF’s software-defined network (11)



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

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

Figure 4: ONF’s SDN architecture



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.

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)

Figure 5: ONF OF-Switch components (13)

https://www.opennetworking.org/sdn-resources/technical-library



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



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

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

tenancy, improved resource efficiency,

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.

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:

Figure 6: SDN benefits in the enterprise environment

Figure 7: SDN benefits in the service provider environment



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



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-sdn-newnorm.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/onf-specifications/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/technical-reports/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/openflow-spec-v1.3.2.pdf



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/openflow-config/of-config-1.2.pdf

15. Pseudo code of sample applications [Internet]. SDN Hub; 2105. Available from: http://sdnhub.org/tutorials/app-pseudo-code/

SDN Introduction

Documents

Transcript of SDN Introduction