It’s a
common trend among writers and filmmakers to offer up their particular take on
a theme such as mistaken identity, opposite attraction or revenge. Similarly,
the technology realm is populated with vendors offering their own blend of a
common concept such as a Linux distribution, handheld tablets or networking

fictional stories, where genuinely new plots are excruciatingly difficult to
find, new advances in technology continually open new possibilities as well as
markets for vendors who demonstrate evolutional agility (of course, one might
argue that “new themes” such as cloud computing and thin clients are just
recycled topics from the past).

One such example in the networking realm is software defined networking, or SDN. It’s a
relatively young concept that was projected in 2012 by the market intelligence company
IBC to become a multi-billion dollar industry in 2016.

What is Software
Defined Networking?

Well, would
you like the technical answer or the functional answer? Let’s start with the
first option. provides a definition of SDN: “the physical separation of the
network control plane from the forwarding plane, and where a control plane
controls several devices.” A good document on the site explains the topic further by stating “in the SDN architecture, the
control and data planes are decoupled, network intelligence and state are
logically centralized, and the underlying network infrastructure is abstracted
from the applications. As a result, enterprises and carriers gain unprecedented
programmability, automation, and network control, enabling them to build highly
scalable, flexible networks that readily adapt to changing business needs.”

Say what? Let’s
break it down further and get at that functional explanation. The purpose of
SDN is to separate traditional network traffic (this can apply to wired or
wireless) into three components: raw data,
how the data is sent, and what purpose the data serves. This involves
a focus on data, control, and application (aka management) functions or
“planes” which map to the infrastructure, control and application layers in the
following diagram:


Those readers
familiar with the OSI model (a staple from MCSE and Novell
certification courses I took in my younger days) will recognize the separation
of functions at play here.

states the above diagram “depicts a logical
view of the SDN architecture. Network intelligence is (logically) centralized
in software-based SDN controllers, which maintain a global view of the network.
As a result, the network appears to the applications and policy engines as a
single, logical switch. With SDN, enterprises and carriers gain
vendor-independent control over the entire network from a single logical point,
which greatly simplifies the network design and operation. SDN also greatly
simplifies the network devices themselves, since they no longer need to
understand and process thousands of protocol standards but merely accept
instructions from the SDN controllers.”

So, to

Infrastructure layer (“Data plane”)

switches and routers and the data itself as well as the process of forwarding data
to the appropriate destination.

Control layer (“Control plane”)

intelligence in devices which works in true “middle-man” fashion, determining
how traffic should flow based on the status of the infrastructure layer and the
requirements specified by the application layer. The model here is centralized
(either physical or logical) rather than distributed across various and possibly
disparate devices.

Application layer (“Application

services, utilities and applications which interface with the control level to
specify needs and requirements. These may be what is known as “network aware.”

The network
hardware you’re probably familiar with performs much or all these functions;
the goal of SDN is to offload the handling of traffic and the way it meets the
needs of the applications involved. For instance, the control layer might
reside on a server and the application layer as a software-based application programming
interface (API). This means the hardware which handles the network traffic
doesn’t need to direct it or deal with management, making the environment more
flexible and adaptable.

A more
complex diagram can be found in a follow-up piece by titled “SDN
Architecture Overview”:


If you’re
not a full-time network engineer (or maybe even if you are) the above image may
be a bit overwhelming. Look, I realize networking can be a bit dry without
subjective, contextual examples. Here’s a real-world analogy for SDN that hits
close to home (for me, anyway).

Let’s say I
go on a car trip with my wife and children. As is usually the case when I drive
on a road trip, I’m just operating on autopilot, representing the data (our
van) on its journey down the network (the highway). This includes the molecules
of the vehicle, the occupants, the juice boxes and the stale goldfish traveling
along. That would be the infrastructure

My wife has
her iPhone and sees that there’s a traffic jam up ahead, so she directs me to
get off the main highway onto a secondary road. “Go 7 miles and then turn right
onto Route 110,” she instructs. She serves as the actual intelligence on where
we’re going and therefore is the control
layer for our trip (this in no way is intended to represent any other area of
our involvement, of course!).

In the back
seat, our younger son politely asks for twelfth time when we’re going to be
there (yes, kids really do this). After we reply “in a couple of hours” he asks
us to buy him dinner. My wife checks her iPhone to see which restaurants are
nearby and explains the detour I’ll need to take to get us there. This is the application layer, since it defines our
purpose at the moment and the requirements being made of my wife, aka the
control layer.

Why SDN?

So, we’ve
established SDN can make the network more flexible and adaptable, but what
else? Why is this such a big deal? Well, by taking this approach you can have a
more diverse, scaled-out environment that can add benefit to your local
datacenter traffic or when extending the network outside the organization.

Can you
guess two exploding trends which have the potential to greatly benefit from
SDN? If you answered “the cloud” and “virtualization” you win the Kewpie doll! With
both of these functions comes the need for better traffic management to handle
scalability, delivery of critical data, increased bandwidth requirements, and faster
provisioning of network services. SDN is intended to fit that need through
these possibilities:

The ability to apply higher level
“bird’s eye” policies to shape and reorder network traffic based on users,
devices and applications.

  • A cloud application might handle the
    direction of network traffic to ensure load balancing across servers or to
    deliver data via the fastest and most efficient routes.
  • Automation can help enhance the
    reliability and simplify the network framework by implementing a more
    consistent, predictable environment.
  • No longer are network resources
    limited to a device-by-device configuration with a weak link in the chain that
    just might be ready to snap.
  • Open-source SDN APIs can be used or
    written by networking staff to help further the capabilities.
  • Security is also touted as another
    advantage to SDN and certainly that’s another issue of tremendous importance

SDN is based
upon open standards. OpenFlow is one such example and has been defined by the
Open Networking Forum. It utilizes virtual device control and a standard
instruction set. Policies can be applied to network traffic and APIs are
available for use or can be programmed by users.

Since SDN
standards are open, no one vendor holds the key to it, but this concept is
being built into vendor devices as they enter the space. Since Cisco holds the market share lead in the networking space, let’s take
a look at how they’ve begun getting their feet wet.

What is
Cisco’s approach to SDN?

approach is both software and hardware based.

On the software
side, Cisco states they are embracing the OpenFlow standard, though they feel
it has some limitations in the areas of management/monitoring, data forwarding,
data packet and service administration and the concept of distributed control. To
clarify this last, “Direct access to decentralized
device APIs opens a broad range of application possibilities that are not
available in an OpenFlow centralized model. A hybrid approach, combining direct
API access on a device to augment API access via a controller, may well be the
optimal balance between centralized and decentralized control planes.”

With that in
mind, Cisco developed the Cisco Open Network Environment (ONE) for network
programmability which is intended to solve the limitations referenced
above and “address challenges of WANs and data centers, as well as campus
networks.” An entry on the Cisco blog states one of the strategies of ONE
is to “build scalable multi-tenant cloud infrastructures with operational
experience between physical and virtual.”


ONE allows
direct programmability of the Cisco environment. It comes with a toolkit called
One Platform Kit (OnePK) which
allows you to create automation policies, set up route instructions and build
network services.

Despite the
phrase “software defined networking,” Cisco feels software isn’t enough. It
lacks scalability, manageability and reliability without the hardware
infrastructure, in their view. So on the hardware side, a concept called Application Centric Infrastructure (ACI) is the name of their game and
they’re playing it through a spinoff company called Insieme.

ACI is based
on a new line of Nexus 9000 switches which run at high-density 10 Gb Ethernet
(10GbE) or 40 Gb Ethernet (40GbE). It will be possible later in 2014 to
retrofit ACI support onto existing Nexus
7000 switches, however, which will eliminate the need to upgrade physical
hardware for customers currently using the Nexus 7000 series. Insieme
switches use optical transceivers to permit the use of existing 10GbE cabling
as customers upgrade to 40GbE Ethernet, which will help them avoid having to
recable their environment during this process.

ACI includes
an SDN controller called the Application
Policy Infrastructure Controller (APIC). The APIC resides between the network
and the applications and implements application policies to permit data
center switches to act as a single network and provide the capability to manage
thousands of ports. ACI can automatically provision network segments for specific
applications and apply a range of policies and networking services to these (such
as Quality of Service or QOS).

Cisco says that APIC will accept homegrown APIs and customers
can obtain “open device packages” to allow existing network hardware not part
of the ACI infrastructure to be governed by the APIC. Two of the APIs which ACI will support are XML and JSON for
network management, for instance.

VMware and Nuage Networks provide similar functionality to
ACI via software-only environments (Take note of this; it will be important
later in this article!). They are strongly involved in the virtualization
space. Cisco’s approach includes network virtualization, but the overall scope
is based on the concept that applications are the most important focus of the
network and these therefore should drive the purpose of the network.

of Cisco’s SDN implementation

Cisco’s approach
is not without some controversy, although it’s important to note
that some of this controversy has been produced by Cisco competitors with a
stake in the game.

Gewirtz Little of reported in November that Nuage CEO Sunil

a problem] with Cisco ACI [in] that it creates ‘pods’ of programmable networks
but doesn’t go beyond the internal data center to address the WAN or
inter-cloud connectivity. Nuage uses IP networking to peer routers at the edge
of a data center, essentially extending network overlays through a VPN. This
stretches the control plane across multiple domains.

we are talking about is not a single data center problem; we are talking about
[connecting] multiple data centers,’ Khandekar said. ‘They haven’t talked about
how to connect data centers back to users over a VPN. There are a lot of things
missing here.’

these ‘islands’ of automation will make it difficult to integrate networks into
a larger orchestration framework within a data center, and even more difficult
to extend orchestration among multiple data centers, he said.”

Mike Banic,
vice president of global marketing at HP Networking pointed out that the full
benefits of Cisco ACI are only made available in an all-Cisco shop. Banic stated “Cisco should have embraced emerging
industry standards that would allow controllers to work across multivendor

Not only is
the Cisco outlook under scrutiny, but SDN itself has been subjected to
skepticism along with it. Steve Mullaney, senior vice president and general
manager of VMware’s Networking & Security Business Unit, stated in a January 13 interview
that SDN was more of a “philosophy” rather than a “thing” and that a properly executed
virtualization strategy would render it unnecessary to “have to touch the
physical infrastructure.” In Mullaney’s view the SDN “vision will never happen”
due to a lack of necessity, since a properly implemented virtual environment
would eliminate it.

In comparing
the VMWare approach to Cisco’s, Mullaney stated “How we go about it couldn’t be
any more different. It’s the complete opposite. We believe in the
software-defined data center. We believe in the power of virtualization to
enable that. We believe in the power of decoupling software from the physical
infrastructure. Cisco came out and said, “We believe in the hardware-defined
data center. We believe in the power of ASICs. We believe in the power of
coupling the software to the hardware. We believe in coupling the software not
just to any hardware but to our hardware. And oh, by the way, it is also our
new hardware so you will need to rip out your existing infrastructure and
replace it.”

Frank D’Agostino, senior director of technical marketing and solutions
engineering, presented a lengthy rebuttal to Mullaney’s statement in the comments section of the article. Among other things he stated the
VMWare pricing model is “flawed,” that VMWare is equally guilty of proprietary
lock-in, and ACI was a lot more open than Mullaney had given it credit for.

Here is a full rundown on thecompeting views towards SDN between VMWare and Cisco.

Mike Fatto
of stated in 2012 that the SDN concept would fade away
in 2014 due to growing pains and it “will be reborn as network management.”

control away from the network devices can lead to significant problems if the
unexpected pops up (when does THAT ever happen in IT?) Of course, if the
controller(s) have an issue, the whole arrangement can also belly-flop. There’s
no ironclad guarantee against loss of service if the focal point is merely
switched from one place to another without sufficient accompanied redundancy.


I’ve been
searching for some time for details on the percentage of technology trends
which thrive versus those which fail. It’s an elusive subject; some concepts
fail and are then reborn later (the way Apple breathed new life into the stale
tablet space is a perfect example) whereas others die out entirely (Netbooks
are likely on their way out).

doesn’t gain traction it will likely become subsumed into something else. I
don’t see that as likely, however. There’s a networking evolution (revolution?)
going on right now which is turning the classic LAN/WAN environment into a
bigger, more complex and needier sort of beast and so SDN will likely gain
momentum as vendors stake their claims and the advantages are realized.

hardware/software approach is deemed by some as too top-heavy but by covering
more bases may prove the resilient contender. Software-only vendors may prove
otherwise if their products succeed, however, rendering hardware more of a “dumb
driver operating on autopilot” (no comparison to yours truly).

of who comes out on top, it will be interesting to see how the various possibilities
and vendors versions fare in the months and years ahead… and quite likely SDN
will play a factor across many disciplines of IT so I recommend keeping an eye
on the subject.