You are on page 1of 4


SDN moves into the realm of the practical, as standards and
interoperability ease efforts to automate networks
Software Defined Networking (SDN) has been heralded as the long-term solution for dynamically
provisioning and automatically configuring network resources as applications are deployed. SDN,
though, has moved beyond theory to practical reality, as open standards and growing interoperability among vendors are driving rollouts of new capabilities.
The ongoing virtualization of data center infrastructure and integration of cloud computing
resources make it imperative to be able to dynamically shift and monitor workloads across those
environments. As data center networks have grown to encompass thousands of devices, existing
architectures have proven inadequate for rapid deployment of applications and unable to keep
up with the agility requirements of todays business environment.
This paper reviews the state of SDN today, including key factors in its evolution. It also reviews
the development of standards such as OpenFlow and the more recent OpFlex open policy
protocol that complements it. We will then look at how the Application Centric Networking
model from Cisco has developed to create a more complete solution for SDN that combines
L4 7 services from Citrix using the NetScaler ADC.


While virtualization of compute and storage have made those infrastructures more efficient, the network has not kept pace, leaving
data centers struggling to leverage such advances. Proprietary legacy
networking solutions make it difficult for organizations to adapt new
technologies needed to create innovative services and are barriers to
achieving the full potential of enterprise cloud computing.
Computer networks are complex and difficult to manage, say the
authors of an ACM SIGCOMM Computer Communication Review
paper tracing the history and evolution of SDN. These networks have
many kinds of equipment, from routers and switches to middleboxes
such as firewalls, network address translators, server load balancers,
and intrusion detection systems. Routers and switches run complex,
distributed control software that is typically closed and proprietary.1
In a legacy network, adding new functions typically requires installing
new equipment or contracting a vendor to reprogram old equipment
for new use. In an SDN, the network control and forwarding functions
are decoupled from hardware. Those functions are then directly
programmable so that network architects can dynamically manage
and control the network devices. Thus the network can be virtualized and delivered as a service much as data centers are doing with
compute and storage resources.

Noting that many large enterprises have conducted trials of SDN

and related technologies, Metzler predicts the likelihood that these
very large enterprise shops will drive the adoption of SDN in the shortto mid-term. In fact, given the amount of attention some of these
financial firms have paid to SDN, it is a safe bet that some will start
to deploy SDN in production networks sometime in 2015.

Much of the appeal of SDN is that it provides substantial benefits

both for service providers and the customers they serve. For carrier
and service providers, SDN offers bandwidth on demand, which
gives controls on carrier links to request additional bandwidth when
necessary, as well as WAN optimization and bandwidth calendaring.
For cloud and data centers, network virtualization for multi-tenants is
an important use case as it offers better utilization of resources and
faster turnaround times for creating a segregated network. Enterprise campuses experience network access control and network
monitoring when using SDN policies, says SDxCentral in identifying
common use cases.2

The roots of SDN traced back more than 20 years to research efforts
on active networking and evolved into an industry-wide effort to build
a more open, programmatic approach to network architecture. But
the proprietary locks that network equipment vendors asserted over
their system software stymied researchers attempting to move in that
direction. A group of computer scientists at the University of Stanford
in 2008 proposed the catalyst that would push vendors in a more
open direction.

Many believe SDN will accelerate the merging of software development and IT operations into a modern enterprise DevOps function
that can more quickly create, refine and fix applications. With an SDN
infrastructure enabling dynamic provisioning, developers can rapidly
prototype, build and migrate applications to production mode. This
is why SDN is seen as the key to an automated, application-centric
SDN allows AT&T and its customers to create products and services
quicker than before, with more control and the ability to add services
on-demand and in near real-time, says AT&T. SDN was a key element in
AT&Ts 2014 rollout of its self service network solution for businesses.
Services providers such as AT&T represent one class of SDN
adopters, according to a Network World reality check. Hyperscale
operations such as Google are another. Large financial firms such as
JPMorgan and Goldman Sachs represent a third class of potential SDN
consumer,3 writes Jim Metzler in a Sept. 9, 2014 Network World article.


Frustrated by [the] inability to fiddle with Internet routing in the real

world, Stanford computer scientist Nick McKeown and colleagues
developed a standard called OpenFlow that essentially opens up the
Internet to researchers, allowing them to define data flows using software--a sort of software defined networking, observes Kate Greene,
in the MIT Technology Review the following year.
Installing a small piece of OpenFlow firmware (software embedded
in hardware) gives engineers access to flow tables, rules that tell
switches and routers how to direct network traffic. Yet it protects
the proprietary routing instructions that differentiate one companys
hardware from another, the Technology Review article explains.
OpenFlow and other SDN-related open networking initiatives make it
compelling for network equipment vendors to proactively respond to
data center demands for more flexibility to leverage the potential of
cloud computing. It is only with the advent of SDN that the idea of a
fully scalable, end-to-end, software-based infrastructure can be realized, says Arthur Cole in an article4 in Enterprise Networking Planet.
And now that that flexible networking technology is here, the race is
afoot to deliver on its promise for cloud-based compute environments.


While it spurred more aggressive SDN development, doubts about

the scalability and performance limitations of the OpenFlow
model persisted.
Traditional SDN models today function on the basis of an imperative
control model with a centralized controller and distributed network
entities that support the lowest common denominator feature set
across vendors such as bridges, ports and tunnels, writes Shashi
Kiran, senior director, Market Management for Data Center, Cloud
and Open Networking at Cisco, in a blog. As the network scales,
the controller becomes a bottleneck due to the need to maintain
increased state, and starts to impact performance and resiliency.
Cisco envisions a more distributed, policy driven approach that relies
on the concept of declarative control. Declarative control dictates
that each object is asked to achieve a desired state and makes a
promise to reach this state, without being told precisely how to
do so,5 according to Cisco. As a result, underlying objects handle
their own configuration state changes and are responsible only
for passing exceptions or faults back to the control system. This
approach reduces the burden and complexity of the control system
and allows greater scale.
To enable this new policy driven approach, Cisco, along with Citrix,
led the effort to create the OpFlex open policy protocol, which has
been submitted as an Internet Engineering Task Force draft and was
co-authored with IBM and Microsoft.
Some observers have viewed OpFlex as a competitor to OpenFlow, but
thats an oversimplified and somewhat misleading characterization, as
OpenFlow focuses on managing Layers 2 and 3 of the network while
OpFlex controls Layers 4 7. While OpenFlow centralizes the network
control plane on an SDN Controller and can push commands down to
OpenFlow enabled network devices, OpFlex centralizes policy control
and relies on traditional and distributed network control protocols to
push commands down,6 according to an SDxCentral analysis.
OpFlex is gaining acceptance. TheOpenDaylight Project, a communityled and industry-supported open source platform to advance SDN and
Network Functions Virtualization (NFV), has an OpFlex bootstrap project
underway to define a uniform policy model that can extend across the
data center, access layer, and WAN, and Cisco is also working on an
open source OpFlex agent for Open vSwitch an open source virtual
switch option available under the Apache 2.0 license.
OpFlex also ties into the OpenStack development effort. A group
policy blueprint from Cisco was approved for the OpenStack


Steve Shah, senior director of
product management, Citrix

Neutron networking code base. As Sean Michael Kerner of Enterprise

Networking Planet explains in an article: While OpFlex is the protocol,
the Group Policy API is the mechanism by which the policies are
managed and enabled. By integrating the Group Policy API into
OpenStack Neutron, the open source community will be building
a cloud platform mechanism that supports OpFlex.7


OpFlex stems from Ciscos Application Centric Infrastructure vision
and strategy. In Ciscos view, earlier efforts to implement SDN were
limited because they mimic an old model of networking that focused
on individual networking elements.
Padmasree Warrior, chief technology & strategy officer at Cisco,
writes in a blog that ACI delivers centralized application-driven
policy automation, management and visibility of physical and virtual
networks. Its built upon a fabric foundation that delivers best-in-class
infrastructure by combining hardware, software and ASIC innovations
into an integrated system.
In the ACI realm, network, compute, and storage will operate as one
high-performance resource pool that can be provisioned instantly and
automatically according to the needs of the application and related
IT policies with security pervasive throughout. It will provide a single
point of management for the integrated needs of application, network
and security administrators.


ACI is built on a network fabric designed to support management
automation, programmatic policy, and dynamic workload-anywhere
models. At its heart is the Cisco Application Policy Infrastructure
Controller (APIC), a centralized policy management and control point
for the entire infrastructure.
As organizations roll out SDNs, they will need to implement a more
efficient and effective approach to load balancing, which distributes
incoming traffic among servers hosting the same application content
and prevents any application server from becoming a single point
of failure. As web sites moved beyond static content to application
delivery, users need to be connected to application servers based
on a variety of criteria using policies and advanced application-layer
knowledge to support business requirements. This application-aware
distribution capability is a key element in the ACI architecture.
Citrix introduced its NetScaler line of products to provide a much
more efficient and effective approach replacing the old server load
balancer with a new Application Delivery Controller (ADC). The Citrix
NetScaler ADC combines Layers 4 7 load balancing, high-speed
data compression, content caching, SSL acceleration, application
flow visibility, and a powerful application firewall into a single, easyto-use platform.


NetScaler leverages the Cisco APIC to programmatically automate

network provisioning and control based on application requirements
and policies for both datacenter and enterprise environments. This
gives our customers what they have wanted, which is to be able to
run load balancers and firewalls in line with their application servers
and spin them up and stamp out a configuration, says Steve Shah,
senior director of product management at Citrix. They dont have
to worry about individually configuring thousands of load balancers
or firewalls in the process because they can automate two or
three configurations.
Cisco APIC can dynamically distribute new policies to the ADC
in minutes, without requiring the network be manually changed.
Integration between the Cisco APIC controller and the NetScaler
ADC is achieved through REST- based open APIs. A NetScaler Device
Package imported by the APIC controller enables it to perform
detailed feature level configuration of NetScaler ADC services. This
enables consistent automation and orchestration of critical services
required in bringing up applications in a fast, secure and reliable
manner. Moreover, these applications can run on any device type and
anywhere in the customers environment without causing disruption
to the network.
We dont build networks for the sake of building networks but to
run applications, says Citrix Shah. Workloads today are elastic; as
users move around the world in different time zones, for example,
they need a workload that is naturally stretchy, and ACI brings that
network stretchiness to reality.
NetScaler and ACI integration provides several key benefits to
data centers:
NetScaler appliances and virtual appliances can be configured
from one location, with less time and effort
Changes to configurations are automatically pushed out to all
appropriate NetScaler appliances
Customers can utilize the advanced capabilities of NetScaler,
and are not restricted to lowest common denominator
ADC features

ACI moves beyond SDN theory to advanced implementation, while
accommodating existing infrastructure. On a practical level, virtual or
physical servers on existing Cisco Nexus networks can participate in
the ACI fabric using the Cisco APIC to provision policies and enable ACI
forwarding mechanisms across both the new ACI (Nexus 9000-based)
and existing Nexus fabrics (Nexus 3000-7000).

Another possible implementation is to use Cisco Nexus 7000 Series

Switches running OTV as data center interconnect (DCI) devices
between the Cisco ACI fabric and an existing Cisco Nexus fabric to join
the network domains and facilitate traffic between the two systems.

To bring Level 4 - 7 services into the mix, Cisco Remote Integrated

Services Engine (RISE) technology allows the Citrix NetScaler to be
used as an extension of Cisco Nexus 5000, 6000, and 7000 Series
Switches through embedded intelligent services that securely integrate
the control planes ofthe switch and the ADC appliances. Cisco RISE
provides a generic means of integration that allows a service appliance
(physical or virtual) to be seen as a virtual line card within either a
Cisco Nexus platform switch.


Whether ACI is in your immediate future or still a distant goal, the
demand for 100% application availability, enhanced end-to-end performance, advanced application-layer attack protection, and improved
server efficiency is here now. Choosing the right ADC for the network
as it is used today and supporting the network of the future is key,
making Citrix NetScaler the logical choice.
Citrix NetScaler is the only application delivery controller that fully
integrates into Ciscos Unified Fabric. The Citrix NetScaler 1000V is
recommended by Cisco as a replacement product for the end-of-life
Cisco ACE and provides a smooth migration path for Cisco ACE, GSS
and CSS customers.
NetScaler comprises tightly integrated physical and virtual appliances
that provide core load-balancing capabilities and deliver the highest
levels of security and performance for todays business critical Web
applications, while providing a foundation for tomorrows Application
Centric Infrastructures.

For more information please go to


Nick Feamster, et al, The Road to SDN: An Intellectual History of Programmable Networks, April 2014. ACM SIGCOMM Computer Communication Review.

Whats Software-Defined Networking (SDN)?;

Jim Metzler, SDN and Network Virtualization: A Reality Check, Sept. 9, 2014. Network World.;

Arthur Cole, SDN: The Key to Computing in the Cloud, April 4, 2014. Enterprise Networking Planet.

OpFlex: An Open Policy Protocol, 2014. Cisco;

What is Cisco OpFlex?;

Sean Michael Kerner, Cisco Opflex Protocol Moves Forward at OpenStack and OpenDaylight, May 5, 2014. Enterprise Networking Planet.