David Baumgard
LTEC 4550
Final Term Paper
Software Defined Networking
Software-defined networking (SDN) is not a specific protocol or technology but
instead is a term used to describe the idea of using a network controller to allow network
administrators to control traffic. This allows the ability to configure devices remotely and
creates separation of the controlling device and the actual network.
SDN has the potential to lower the cost of the network by allowing the use of offbrand “white box” networking devices. Implementation of SDN allows a business to
manage the network and application services from a central location. The also provides
flexibility specifically for the implementation of policy and the ability to program and
control traffic flow. OpenFlow is currently the most common specification but competing
strategies are developing to resolve issues that arise when implementing SDN.
Application Centric Infrastructure (ACI) is Cisco’s hardware-based implementation that
is aimed at resolving the issues that are faced when attempting to implement SDN on an
existing network.
OpenFlow is currently the only SDN protocol that is currently standards-based.
Open Networking Foundation (ONF) is the organization that promotes the standard and
emphasizes the need for users to implement and collaborate. This protocol provides the
standard that allows communication between the control plane and the data plane. The
control plane is where the packet forwarding decisions are made. The data plane is the
destination to which the packets are forwarded. When describing this communication
control plane to data plane is south-bound and data to control plane is northbound and
utilizes SSL for a security measure. The abstraction between the networking devices and
the device that makes the routing or switching decision allows for the use of bare-metal
devices.
Application Programming Interface (API) is the tool that allows one application
to talk to another. This makes it possible for information to move between programs. An
API available is the OpenFlow Hardware Abstration API. This programming interface
resides within the software of the OpenFlow switch. The API is what allows the use of
“whitebox” devices. Without an API a network administrator would be required to use a
vendor specific network application such as the CLI within Cisco’s Internetwork
Operating System (IOS). APIs can be created in any number of languages such as Java,
Python or Ruby. The API is used to perform the actions inputting commands and
modifying the instructions of the network.
SDN is network virtualization which eliminates the need to configure each device
in the network topology and instead configure a single controller. This includes switching
and routing technologies which include VLANs, ACLs and many other familiar to the
networking industry. OpenFlow can also be used to configure OpenStack which provides
the ability to build cloud infrastructure which allows access to application services.
Virtualization allows an administrator to quickly change any of these protocols and
change security, flow of traffic or access to cloud technologies from a single device.
David Baumgard
LTEC 4550
Final Term Paper
Below is an image that details the abstraction of the decision making and why
bare-metal device are available when SDN is implemented. Notice that the Network
Operating System, this would be IOS for Cisco, is not within the hardware that is
forwarding the packet. Instead they would use OpenFlow to communicate with the device
that is configured and active makes decisions and implements policies.
[Online Image] http://www.slideshare.net/openflow/openflow-tutorial Available Dec 1,
2015
There several challenges facing the implementation of OpenFlow and SDN, since
there are currently no other protocols at the forefront, most prominent is scalability.
Currently there are no specifications regarding the proximity of the controller to the
switch as well as how many switches can it control. This causes issues regarding speed
and resource usage. SDN would in theory use resources more efficiently in the same way
that server virtualization has done. However, with the controller communicating through
several TCP sessions utilizing SSL there are concerns regarding the CPU usage.
Theoretically modern controllers should be able to server thousands of switches but this
has not been proven in production. Another problem is the amount of flows handled by
the switch. Flow tables are utilized instead of routing tables and currently OpenFlow
specifications say that the flow tables in a switch must match on 12 fields which can
David Baumgard
LTEC 4550
Final Term Paper
cause ternary content addressable memory to be limited to a couple thousand entries. This
leads to next issue of using flows. The flow table concept does not allow packets within
the same flow to be sent to different locations which effectively eliminates loadbalancing. There are also issues regarding the physical ports such as configuring trunks,
port groupings such as etherchannel, virtual ports and VLANs.
Flow Tables are a list of flow instructions, including source and destination, and
is list in order of priority. Flow switches can have multiple flow tables which can be in
the hardware or programmed in the software. Each rule within the table has a datapath. A
port manager exposes the actual hardware of the port to the software of OpenFlow. It also
provides control of the port by configuration of enable or disable, link state, spanning tree
and many others.
Currently SDN is effectively not production and has not seen any real use beyond
small networks the growth of cloud-based services and Big Data requires the
technologies used in the network. SDN does provide the ability to use APIs and quickly
resolve issues regarding bandwidth usage or routing paths in response to the cloud it still
requires resolution of many problems.
ACI is a solution presented by Cisco to resolve the same problems of the
changing network in relation to cloud computing that SDN is intended to resolve. Instead
of relying almost completely on the software involved Cisco has attempted to create
scalability by employing hardware in a spine-and-leaf design. The design incorporates
three parts: Cisco’s Application Infrastructure Controller (APIC), Nexus 9000 switch and
an enhanced version of Nexus Operating System (NX-OS).
The spine-and-leaf infrastructure follows the similar traditional design of Core,
Distribution and Access layer design. The spine is similar to the Core and has switches
with high-throughput and high amount of ports. The leaf switches are similar to the
access layer and provide uplink and connections to the servers and redundancy created by
every leaf switch connected to each spine switch. This design provides the scalability by
providing the option of adding hardware when new servers are deployed.
The APIC provides the single point of configuration and control just as the
controller in SDN. The controllers are distributed clusters and provide a point for
configuration at a unified point. The controllers, recommended minimum of three, and
are connected to leaf switches. Automation can be created by implementing policies
within the controllers.
David Baumgard
LTEC 4550
Final Term Paper
[Online Image] Retrieved from http://www.cisco.com/c/en/us/solutions/collateral/datacenter-virtualization/application-centric-infrastructure/white-paper-c11-731310.html Dec
1, 2015
ACI also utilizes APIs through representational state transfer (REST) interfaces.
Software development kits are available for Python and Ruby. This provides the interface
for the administrator to develop policies and implement the required configurations and
policies removing the need to configure each device.
ACI provide many similar functions of SDN such as changing traffic patterns,
more efficient use of resources, ability to deal with changing traffic patterns due to cloud
services as well as bandwidth uses related to Big Data.
Data Centers are facing the challenges presented by cloud computing and Big
Data and the industry will eventually have to implement protocols and standards to deal
with the traffic. SDN is a protocol stack that offers a possible solution but faces many
challenges in order to become a reliable choice. There are configurations that can be
difficult to implement and software can be difficult to troubleshoot and manage.
OpenFlow is currently the leading protocol and while a single point of configuration is
provided there is no automation built in. Flow control is also limited to a single
destination and the flow tables must be very specific which can be taxing on CPUs.
Currently SDN specific hardware and silicon such as Application Specific Integrated
Circuits are very limited.
Cisco has attempted to resolve these issues with ACI using APICs. The APICs
allow central configuration and policy implementation while also introducing clusters for
redundancy and continues to offer the use of APIs to avoid vender specific interfaces.
Cisco also introduces scalability by providing ACI specific hardware which also for
expansion through additional hardware.
David Baumgard
LTEC 4550
Final Term Paper
Cisco appears to be ahead in providing a solution but like always will be very
expensive. SDN could be the open source solution given that OPN is able to provide a
remedy through fixing current policy or creating a protocol that can provide the
requirements that administrators would need to successfully implement.
References
N.A. (n.d) software-defined networking (SDN) definition Retrieved from
http://searchsdn.techtarget.com/definition/software-defined-networking-SDN
N.A. (n.d.) Is Cisco Application Centric Infrastructure an SDN Technology? Retrieved
from http://www.cisco.com/c/en/us/solutions/collateral/data-centervirtualization/application-centric-infrastructure/white-paper-c11-733456.html
N.A. (n.d.) SDN Technology Retrieved http://www.bigswitch.com/company/sdntechnology
Johnson, S. (n.d.) How Cisco’s ‘Application Centric Infrastructure’ differs from SDN
Retrieved from http://searchsecurity.techtarget.com/feature/How-Ciscos-ApplicationCentric-Infrastructure-differs-from-SDN
Seetharaman, S. (Nov, 2011) OpenFlow/Software-defined Networking Retrieved from
http://www.slideshare.net/openflow/openflow-tutorial
Singh, S. (May 24, 2012) Software-defined networking:OpenStack, Openflow – It is all
about innovation
Lynch, B. (June 15, 2013) OpenFlow – Can It Scale? Retrieved from
https://www.sdxcentral.com/articles/contributed/openflow-sdn/2013/06/
Erickson, D. Hara, M. Heller, B. Lantz, B. Pettit, J. Pfaff, B. Talayco, D. (Sep 16, 2009) Version
0.4 based on OpenFlow 0.9.0 http://archive.openflow.org/wk/images/c/c2/Of-hw-api-draft-0.4.pdf
N.A. (Oct 1, 2013) Cisco Spine and Leaf Architecture Discussion
http://thenetworksurgeon.com/cisco-spine-and-leaf-architecture-discussion-nexus-5500-vs-6001/