NETWORKS SWITCHING AND ROUTING

Assignment No: 01
SOFTWARE DEFINED NETWORKS
AHSAN RIAZ MS-IT 14
10/4/2013

SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE-NUST

ISLAMABAD
 2

Question No 1:

A) Compare SDN approach with traditional networking approach in terms of complexity,

vendor dependence, programmability and scalability?

The rapid increase in volumes of server virtualization, mobile devices, content, and
cloud computing services are the base for re-examination of the traditional network.
Many networks are based on hierarchical structure that is based on tiers made up of
Ethernet switches forming a tree type structure. This architecture was good when client-
server computing was there and was completely in controls, but such a static network
architecture is not suitable to the storage needs and dynamic computing of today’s
enterprise and carrier environments. The factors contribute to the need of new network
architecture to be designed includes traffic patterns, Cloud Computing Services, Higher
Bandwidth.

SDN allows network engineers to change the internal intelligence of the switches by
prioritization and de-prioritizing or even can block incoming or outgoing traffic/ packets
providing high level of control over networks physical resource. It provides us ability to
program control plane by providing API’s. We can easily program the routers to function
according to our defined software that logically run on network devices. In traditional
networks all these decisions were made at device level, where to send the packet and
how to send its all were decided at device level. As SDN main idea was the separation
of intelligence of device from its hardware and operates it separately to control it with
the help of centralized software based server, providing us great ease to scale our
networks by adding new applications for better bandwidth utilization and better recourse
utilization. By separating control and data planes we can also easily embed new
application and innovations in control plane that will be controlling data plane, without
depending on vendor for new release for our application implementation.

Figure 1.1 and 1.2 shows the graphical representation of ‘Traditional Networks’ and
‘Software Defined Networks.

Control Plane
 Data Plane
3

Figure 1.1, Traditional Network

Centralized Control Plane

Distributed Data Plane

Figure 1.2, Software Defined Networks

Comparison in terms of:

1) Complexity:
In traditional networks physical medium/network devices like switches routers etc
all acts as a single entity. Every network device has its own software installed on
it, performing decisions of routing or switching. Suppose we want to add some
feature form routing algorithm or protocol point of view like installing some new
protocol, we have to configure each and every network device to deploy a new
feature to the networks. However SDN we can decrease our degree of
complexity by separating the network devices and intelligence of these devices in
the form of control and data planes as shown in figure 1.1. If we want to deploy
 4

some new application or feature in networks we can easily configure our network
devices from control plane as control plane have complete administrative hold
over the networks devices like routers switches etc.
2) Vendor dependence:
In SDN Control plane acts as administrator over the network devices. SDN take
network devices as dummy devices having no ability to decide what to do, they
will only perform their function when they will be instructed by control plane. Now
a days in traditional networks we have network devices from different vendors
like TP Link, CISCO etc. Each vendor uses its own version of software/protocols
or algorithms installed on their devices for operation. We are limited to use the
only features installed on the device by vendor. Whenever any new feature
comes we have to wait for the latest release of device to use latest features and
applications of networks. SDN as we know have completely changed the view of
networks by separating hardware and software into two different planes. Now we
can easily install and remove any new/old feature and application to the network
devices on demand.
3) Programmability
SDN ‘Controller plane’ has taken over the control of management of network
devices. We can use Northbound API’s of SDN infrastructure to program our
procedure of network devices from control plane from a single place instead of
programming every single device as in traditional networks. SDN was often
referred to as the "Cisco killer" because it allows network engineers to support a
switching fabric across multi-vendor commodity hardware and use software to
shape traffic from a centralized control console without having to touch individual
switches with programmability.
4) Scalability
SDN enables us to design scalable network solution for future. Control plane can
easily add or remove any new application and feature to the network devices
without affecting the dumb network devices. It will do the modification on the
control plane and all the changes and updating will be accessible to all the
devices instead of installing new feature on every device one by one (traditional
network).

B) Show complete working and architecture of software defined networks?

Basic idea behind SDN architecture is to separating the physical network part and
network intelligence from each other’s. It has been done in SDN architecture by
 5

decoupling the control and data planes, Centralization of network intelligence part and
its state logically and abstraction of network infrastructure from the applications. As a
result, enterprises and carriers gain the ability of programmability, automation, and
network controllability, enabling them to make highly scalable and flexible networks
solutions for future that best meets their business environment.
Most importantly, Decoupling enables network operators and administrators to configure
network abstraction programmatically instead of scattering hand coded lines of codes to
hundreds and thousands of networks devices. Another important factor of SDN is
Centralizing the intelligence of controllers that enables IT to change the behavior of the
networks in real time and deployment of new innovations and applications very fast and
efficiently as compared to traditional network.
By making the state of the network centralized in the control layer, it enables the
network manager to better utilize the resources of the networks, providing them
flexibility with the help of application programs. They can write these programs on their
own and can embed on network devices without waiting of vendor, so that they can
embed this feature in the devices. SDN also provides many API’s that enables the
controllability of many features of the networks including routing, multicast, security,
access control, bandwidth management, traffic engineering, QOS etc.. SDN is based on
three-tier architecture:
1) Northbound open APIs 
2) An open-core controller
3) Southbound standards-based data plane communication protocols.
1) Northbound Open APIs – It provides the interface between the control plane
software modules and application running on the top of the network platform. Open
SDN architecture implements Northbound APIs, for providing the interface to users,
developers and community, so that applications can use the universal network
abstraction data models and the functionality of control plane. These interfaces are
open to public and can be used by community for development.

2) Controller Plane – It provides decoupling by separating the hardware physically

from data forwarding plane. With this as network devices like routers switches can
forward the packet and our controller can run on separate server.  It enables both
control and data planes to be implemented even using different distribution models.
Control plane development and run time tasks can be handled on two different
platforms providing high flexibility.
 6

3) Standards-based Southbound Protocols – It provides control communication

between controller plane and data plane devices, including physical and virtual
switches.

Figure 1.3, SDN Architecture

Question No 2:

A) Discuss the role of ‘Openflow’ in SDN also discuss 3-4 controllers available for
‘Openflow’?
First standard interface designed is called ‘OpenFlow’. It provides granular traffic control
high-performance across multiple network devices. It totally change and replace the
functionality of layer 2 and layers 3 elements like switches, routers etc by providing the
software protocols on control plane..
‘OpenFlow’ based SDN is beneficial to both enterprises and carriers, including:

 It provides Centralized management and control of networking devices using control

plane.
 It uses common APIs to improve automation and management to abstract networking
details from systems and applications.
 With the help of new network services and capabilities, Rapid innovations are
possible without need to configure individual devices.
 7

 It enables the programmability by operators, independent software vendors and

users, not only manufacturers.
Figure 2.1 shows us the component architecture for genereal open source controllers.
Most of the ‘Open flow’ controllers are based on the ‘Onix’ code and ‘Onix’ architecture,
so approximately all most of the open source controllers exhibit the same components.
As we know Floodlight controller is an open flow controllers, it also have same
components as others open source components have.
The ‘Onix’ based controllers relates to SDN in many aspects. For example it provides
variety interfaces (API’s), northbound, south bound for programmatically, configuration,
and for many more functions of controller.
‘Openflow’ provide interfaces, with which we can easily program network devices. With
the ease of programmability we can modify and robust network devices, building
centralize intelligence that was the promise of SDN.

Figure 2.1,Open Source ‘Openflow’ Components

Currently there are two kinds of protocols in Open flow:

 8

1) Wire protocol
Wire protocols are responsible for defining the structure of the messege,
establishing the sessions, defining the logical pipe line of the switches for
efficient flow of packets to and from switches. It define the overall structure of the
tables, interfaces, storing capacity processing etc…Currently version 1.3.x of
wire protocol is available.
2) Configuration and management protocol
Currently version 1.1 of Configuration and management protocol is available.
NETCOF is used for the allocation of physical ports of switches to controller and
controls the behavior when connection fails.

Openflow Controllers

There are following Open Flow controllers:

NOX: (C++/Python) it was developed by NICIRA and become open source in 2008. On
Lab Activities at stand ford university along with contribution of UC Berkeley and ICSI
are providing the support to NOX/POX. It has two purposes, one as a controller and
other as development frameworks for the development of SDN application programs by
providing us the API’s to interact with open flow switches.

Figure 2.2, NOX Architecture

Here are some NOX applications names that includes ‘SANE’ and ‘Ethane’. SANE
attempts the representation of networks as a file system. ‘ETHANE’ was the research
application of Stanford University. It provides services for centralized, network security
in traditional access control list.
POX: (Python) – it was the updated and latest version of NOX. The basic idea behind
the ‘POX’ was to separate ‘NOX’ to its original C++ roots and implementing ‘POX’ in
 9

Python language. Other additional feature of POX includes query-able topology graph
and virtualization.

There are following advantages of ‘POX’ over ‘NOX’:

 ‘POX’ is completely Python based where as ‘NOX’ was based on two langiages C++
and Python.
 ‘POX’ has reusable components like selection of path, topology to discover and
many more.
 ‘POX’ was Platform independent; it can be used runtime for easy development.
 Both ‘NOX’ and ‘POX’ support same GUI and visual aspects.

TERMA: ‘TERMA’ was developed by NEC by multiple open source contribution before
final release. It was actually the programming language plat form for the development of
‘OpenFlow’ controller. As compared to other ‘Openflow’ controllers; TERMA’ provides
basic infrastructure for development of user modules (‘TERMA’ Applications). However
development in ‘TERMA’ is restricted to Ruby or C language.

Trema OpenFlow Controller is an extensible set of Ruby scripts.

By defining their own classes and subclass objects , developers can enhance the basic
functionality of the controller, also ‘TERMA’ provides message bus to applications and
users, so that user modules and core modules can communicate with each other in
point to point fashion as shown in the figure.

Figure 2.3, ‘TERMA’ User Modules Relationship.

 10

Figure 2.4, ‘TERMA’ Structure and API Interface

Other ‘Openflow Controllers’ includes ‘RYO’, ‘MUL’, ‘JAXON’, ‘Big Switch Network/
FloodLight’ etc..

B) Discuss 2 tools that are available for implementing and testing ‘Openflow’
based SDN?

There are following tools available

1) MININET

Mininet is Linux based simulator. It provides the simulation of switches, routers end
hosts on Linux Kernal. Each element is called Host. It provides us testing and
development environment on a single system. With virtualization it shows the single
system to act as complete network. A mininet host can acts like real machine that can
run code/programs as real machines runs. They can send and receive packets as they
are design to appear in the real Ethernet but actually they are virtual switch /Interface.
Packets are processed by virtual switches.

Figure 2.5, ‘MININET’ Network

 11

2) Cbench

Cbunch is the tool for testing Openflow controllers. It provides the testing capability
by generating packets in events for new flows. Showing the simulations of buch of
switches that are connected to the controller can send packet in messege we can
watch the flow mods. If any impact on the performance occur by the changes we
have made cbunch can be helpful to measure it.

C) A user wants to implement a simple firewall using Openflow. Discuss how this
can be implemented / achieved?

Firewall is responsible for the flow between client and server from SYN to ACK end up
in TCP instead of handling packets. Consider firewall that is locked for security
purposes between particular router and server for internet connection.

Figure 2.6

Traffic coming to and from the internet and return session will pass through this firewall
to the server. In the figure 2.7 below yellow line is showing traffic flow.

Figure 2.7
 12

Now if we want to install new firewall/ want to upgrade our firewall to another model, we
need to divert our network traffic to our new Juniper or Cisco firewall. As we assumed
that checkpoint FW-1 is creating problem since last few weeks. So need to upgrade our
firewall and diverted our traffic from it to new juniper as shown in the figure. For
diverting the traffic we have only tool called routing. As we know routing is based on the
destination IP address.

Figure 2.8
Commonly firewall is based on Source IP Address, Destination IP Address and
Destination Port.

Firewall Flow Table

SRC IP DEST IP DST Port Action

172.32.32.3
155.66.77.11 80 Drop
2

172.32.32.3
155.66.77.12 80 Drop
2

155.66.77.13 172.32.32.3 80 Permit

 13

Firewall Flow Table

SRC IP DEST IP DST Port Action

Figure 2.9
From the figure 2.9 we can see firewall rules. As we have redirected our flow so
destination address redirection is same in destination address column of firewall table.
OpenFlow identifies traffic flow by providing traffic engineering services also OpenFlow
device to manipulate the flows. Sample OpenFlow table has been shown in the figure
2.10 with some actions on the data.

Figure 2.10

As we can see from the figure OpenFlow provides us ways to set different criteria for
managing network flows as compared to traditional procedure. Using OpenFlow we can
easily redirect our traffic to different Ethernet ports.
The elements of the solution are:
1. OpenFlow switches
2. OpenFlow Controller
3. Application for Fire Wall Migration
 14

Figure 2.11

Once we have basic elements for operation in place.

 The Fire Wall Migration Application reads the configuration from the old firewall.
 Application that parses the configuration for firewall rules and builds a Fire Wall flow
table based on the rules.
 Application then loads the firewall rules into the new firewall.
The Wall Migration application read the configuration using an API. Starting the cutover
on a rule by rule basis is the second phase. Rough outline of flows is given below:
 Selection button is available for the rules ready to cutover on Fire Wall Migration
Application.
 Select the rules from the list and apply.
 OpenFlow switches will receive OpenFlow rules that are sent.
 Now flow has been diverted to alternative firewall.
This figure 2.11 summaries the overall process.
1. Read the configuration of the legacy Check Point firewall, parse the standard rule
base. Highlight unrecognized rules or actions for user intervention.
2. Push the rules into the new firewall. Engineer performs a manual verification.
 15

3. Engineer selects a few rules for migration to the new firewall and OpenFlow rules
are dispatched to your OpenFlow switches. All IP Flows matching the flow table
are diverted into a different Ethernet port where the new firewall is connected.

Figure 2.12

Now you have forced the flow over to the alternate firewall while other flows continue to
traverse the old firewall.

Figure 2.13
 16

The firewall module also provide reset interface with the help of reset API as
‘RestletRoutable’. It supports multiple actions like get, Post, URI arguments, and data
fields required for action.
Question No 3:
What is network Virtualization, discuss with examples? Also describe the
relationship between NV and SDN?
Combining network resources, software and hardware and network functionality on
single software based administrative entity is called network virtualization. It is done by
separating logical functionality of the network from physical network resources likes
routers, switches etc. It involves platform virtualization along with resources
virtualization. Network virtualization can be categorized in two types, internal and
external; external virtualization involves combination of different physical networks into a
single virtual network that are isolated from each others. Virtualization of networks can
also be done between the virtual servers that will be called internal network
virtualization.
Some vendors provide external network virtualization by combining local physical
networks in to virtual networks. Using VLAN and switches administrator can physically
configure the systems attached to local networks. On the other hand networks are
created in the box by configuring the single system with containers like Xen domain. It
improves the efficiency of single computer by isolating applications to separate
containers. VMware, XenServers and Microsoft products like Hyper-V are the examples
of internal network virtualization.
We can do Network virtualization on a single computer or at a server using Hypervisor
software. Hypervisor provides an abstraction layer that allows the virtual networks to
take appearance of physical networks. Examples includes  VMware ESXi, Citrix
XenServer 5, Virtual Iron from Virtual Iron Software, Microsoft Hyper-V Server 2008 and
the open source VirtualBox. As we need to connect many system the network itself and
network resources like switches also need to support virtualization. They run
Virtualizations software that abstract the physical ports if the switch and networks into
VLAN.

Examples: we can take the example of particular client, suppose he wants separate
network for his business purposes. Traditionally one solution is that we create a new
physical network and hand over to him to use it. On the other hand it can be done by
network virtualization. By NV new logical network can be created using same network
physical resources like switches, routers etc instead of creating new physical network
and wasting network resources. This new logical network will be isolated from other
virtual networks even it is using the same network resources as others are using. More
and more virtual networks can be created by small changes ensuring the security of
virtual networks.
This type of flexibility is not possible when we are using traditional networks. In
traditional networks as we use routers and switches, when our interface ports of routers
and switches become full when number of networks increases in number, we have to
 17

buy new hardware to increases the service capability for the networks. By this
increasing the number of networks required we are wasting networks resources along
with creating the complexities to maintain the large number of networks as networks is
based on physicality. In virtual networks we just increase the size of our logical switch
and will reboot the server again we are back to business.

Relationship with SDN:

Development of SDN based on two problems, firstly increasing number of IP networks,
network traffic management and improving the efficiency of the traffic routing. Secondly
the promise of Cloud Computing organization to share their public data center to
applications in non interfering way. Focusing on these two missions SDN has designed
three models of it:
 Centralized control using OpenFlow controller
 Using networks overlays management of Networks Virtualization
 Distributed model
Network function virtualization is an initiative to carrier driven architecture from purpose
based devices and services to centralized and generic servers. With this we can easily
configure and deploy our new services without relying on devices hence providing them
flexibility.
SDN is not subset of NFV. SDN provides virtualization by decoupling the data plane and
control plane and providing the services with the help of different controllers. We can
easily add or remove applications from control plane providing pure network
virtualization.NFV can define the central function of SDN as virtual functions. For
example OpenFlow switches can be directed using NFV software, SDN controllers are
also implemented as virtual function, firewall, load balancing are also based on
virtualization as they are also core functions of SDN.

Question No 4:
SDN uses different north bound application programming interface (API) to
program the network and get service from it. Discuss why these APIs are needed
and summarize the functions of some of the available APIs?

SDN architecture has decoupled the Control plane and data plane, providing forwarding
functions to be operated separated from control plane through high level policies. South
bound stack like Openflow allows the controller plane to interact and control the
operation of networks data plane from the bottom while northbound API’s enables the
network abstraction from the top. SDN provides great flexibility to development
community to program networks devices (Data plane) by developing new applications
and features in controller plane using Northbound API’s. With these API’s we can easily
change the behavior of data plane can program the network and request services from
it. For example we can easily change rules of routing, switching, traffic engineering and
load balancing etc.
Large number northbound API’s are available now days. More than 20 SDN controllers
are available. Everyone is has different features. No standard have been defined yet for
 18

these API’s. Because SDN is so new, everyone is still learning about what they can do
with northbound APIs, what form they might want it to take and what capabilities they
enable.