EN5360 Advanced Networking Concepts

Assignment

SDN Summary Report

Group Members

Name : Dinushika Gunasekera

Index No. : 169222J

Name : Kithmini Weththasinghe

Index No. : 169225V

Name : Kokila Hettiarachchi

Index No. : 169223M

1|Page
Summary Report – Dinushika Gunasekera

Table of Contents
1. Executive Summary
2. The Need for a New Network Architecture
3. Limitations of Current Networking Technologies
4. Introducing Software-Defined Networking
5. Inside OpenFlow
6. Benefits of OpenFlow-Based Software-Defined Networks
7. Conclusion

2|Page
 1. Executive Summary
Traditional network architectures are ill-suited to meet the requirements of today’s enterprises, carriers,
and end users. 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.

OpenFlow-based SDN is currently being rolled out in a variety of networking devices and software,
delivering substantial benefits to both enterprises and carriers, including:

 Centralized management and control of networking devices from multiple vendors;

 Improved automation and management by using common APIs to abstract the underlying
networking details from the orchestration and provisioning systems and applications;
 Rapid innovation through the ability to deliver new network capabilities and services without
the need to configure individual devices or wait for vendor releases;
 Programmability by operators, enterprises, independent software vendors, and users (not just
equipment manufacturers) using common programming environments, which gives all parties
new opportunities to drive revenue and differentiation;
 Increased network reliability and security as a result of centralized and automated management
of network devices, uniform policy enforcement, and fewer configuration errors;
 More granular network control with the ability to apply comprehensive and wide-ranging
policies at the session, user, device, and application levels; and
 Better end-user experience as applications exploit centralized network state information to
seamlessly adapt network behaviour to user needs

2. The Need for a New Network Architecture

Some of the key computing trends driving the need for a new network paradigm include:

Changing traffic patterns: Today’s applications access different databases and servers, creating a flurry
of “east-west” machine-to-machine traffic before returning data to the end user device in the classic
“north-south” traffic pattern. Users are changing network traffic patterns as they push for access to
corporate content and applications from any type of device (including their own), connecting from
anywhere, at any time.

The “consumerization of IT”: Users are increasingly employing mobile personal devices such as
smartphones, tablets, and notebooks to access the corporate network. IT is under pressure to

3|Page
accommodate these personal devices in a fine-grained manner while protecting corporate data and
intellectual property and meeting compliance mandates.

The rise of cloud services: Enterprises have enthusiastically cloud services, resulting in unprecedented
growth of these services. IT’s planning for cloud services must be done in an environment of increased
security, compliance, and auditing requirements, along with business reorganizations, consolidations,
and mergers that can change assumptions overnight.

“Big data” means more bandwidth: 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

3. Limitations of Current Networking Technologies

Existing network architectures were not designed to meet the requirements of today’s users, enterprises,
and carriers; rather network designers are constrained by the limitations of current networks, which
include:

Complexity that leads to stasis: Networking technology to date has consisted largely of discrete sets of
protocols designed to connect hosts reliably over arbitrary distances, link speeds, and topologies. To
meet business and technical needs over the last few decades, the industry has evolved networking
protocols to deliver higher performance and reliability, broader connectivity, and more stringent
security which lead the networks to be very complex.

Inconsistent policies: To implement a network-wide policy, IT may have to configure thousands of

devices and mechanisms. The complexity of today’s networks makes it very difficult for IT to apply a
consistent set of access, security, QoS, and other policies to increasingly mobile users, which leaves the
enterprise vulnerable to security breaches, non-compliance with regulations, and other negative
consequences.

Inability to scale: As demands on the data center rapidly grow, so too must the network grow. However,
the network becomes vastly more complex with the addition of hundreds or thousands of network
devices that must be configured and managed.

Vendor dependence: Lack of standard, open interfaces limits the ability of network operators to tailor
the network to their individual environments.

4|Page
 4. Introducing Software-Defined Networking
Software Defined Networking (SDN) is an emerging network architecture where network control is
decoupled from forwarding and is directly programmable. The network appears to the applications and
policy engines as a single, logical switch. 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. Network operators and administrators can programmatically
configure this simplified network abstraction rather than having to hand-code tens of thousands of lines
of configuration scattered among thousands of devices

SDN focused solely on separation of the control plane of the network, which makes decisions about
how packets should flow through the network from the data plane of the network, which actually moves
packets from place to place. When a packet arrives at a switch in the network, rules built into the switch's
proprietary firmware tell the switch where to forward the packet.

In a classic SDN scenario, rules for packet handling are sent to the switch from a controller, an
application running on a server somewhere, and switches (also known as data plane devices) query the
controller for guidance as needed, and provide it with information about traffic they are handling.

Controllers and switches communicate through a controller's south bound interface, usually OpenFlow,
although other protocols exist like OVSDB(open virtual switch database)SDN deploys an application
that uses the controller to manage data plane behavior. Applications talk to the controller though its
north-bound interface.

Software-defined networking uses an operation mode that is sometimes called adaptive or dynamic, in
which a switch issues a route request to a controller for a packet that does not have a specific route.

5|Page
 5. Inside OpenFlow

OpenFlow is the first standard communications interface defined between the control and forwarding
layers of an SDN architecture. This allows direct access to and manipulation of the forwarding plane of
network devices such as switches and routers, both physical and virtual (hypervisor-based). OpenFlow
is needed to move network control out of the networking switches to logically centralized control
software.

The OpenFlow protocol is implemented on both sides of the interface between network infrastructure
devices and the SDN control software. OpenFlow uses the concept of flows to identify network traffic
based on pre-defined match rules that can be statically or dynamically programmed by the SDN control
software. It also allows IT to define how traffic should flow through network devices based on
parameters such as usage patterns, applications, and cloud resources.

6. Benefits of OpenFlow-Based Software-Defined Networks

The benefits that enterprises and carriers can achieve through an OpenFlow-based SDN architecture
include:

Centralized control of multi-vendor environments: SDN control software can control any OpenFlow-
enabled network device from any vendor, including switches, routers, and virtual switches.

Reduced complexity through automation: OpenFlow-based SDN offers a flexible network automation
and management framework, which makes it possible to develop tools that automate many management
tasks that are done manually today.

Higher rate of innovation: SDN adoption accelerates business innovation by allowing IT network
operators to literally program—and reprogram—the network in real time to meet specific business
needs and user requirements as they arise.

Increased network reliability and security: SDN makes it possible for IT to define high-level
configuration and policy statements, which are then translated down to the infrastructure via OpenFlow.
An OpenFlow-based SDN architecture eliminates the need to individually configure network devices
each time an end point, service, or application is added or moved, or a policy changes, which reduces
the likelihood of network failures due to configuration or policy inconsistencies.

More granular network control: OpenFlow‘s flow-based control model allows IT to apply policies at
a very granular level, including the session, user, device, and application levels, in a highly abstracted,
automated fashion.

6|Page
Better user experience: By centralizing network control and making state information available to
higher-level applications, an SDN infrastructure can better adapt to dynamic user needs.

7. Conclusion

Software-Defined Networking provides a new, dynamic network architecture that transforms traditional
network backbones into rich service-delivery platforms. By decoupling the network control and data
planes, OpenFlow-based SDN architecture abstracts the underlying infrastructure from the applications
that use it, allowing the network to become as programmable and manageable at scale as the computer
infrastructure that it increasingly resembles.

The future of networking will rely more and more on software, which will accelerate the pace of
innovation for networks as it has in the computing and storage domains. SDN promises to transform
today’s static networks into flexible, programmable platforms with the intelligence to allocate resources
dynamically, the scale to support enormous data centers and the virtualization needed to support
dynamic, highly automated, and secure cloud environments. With its many advantages and astonishing
industry momentum, SDN is on the way to becoming the new norm for networks.

7|Page
Summary Report – Kithmini Weththasinghe

Referenced Paper: http://archive.openflow.org/documents/openflow-wp-latest.pdf

Introduction

OpenFlow is the proposed solution for researchers to run experimental protocols in their campus
network. The biggest problem was find a way to run experimental protocols within the campus network
without disrupting existing users in the network, which means that researchers have to control a portion
of network in a way that does not disrupt users and to put experimental equipment into the existing
network. As earlier there was no separated control pane and data pane so researchers have to change
hardware always to match experimental protocols. The answer was introduction to OpenFlow and
encourage networking vendors to add OpenFlow to their switch products for deployment in college
campus backbones.It is based on an Ethernet switch, with an internal flow-table, and a standardized
interface to add and remove flow entries. OpenFlow could serve as a useful campus component in
proposed large-scale testbeds like GENI.

The Need for Programmable Network

There was almost no practical way to experiment with new network protocols in sufficiently realistic
setting to gain the confidence needed for their widespread deployment. These programmable networks
call for programmable switches and routers that can process packets for multiple isolated experimental
networks simultaneously. Virtualized programmable networks could lower the barrier to entry for new
ideas, increasing the rate of innovation in the network infrastructure.

8|Page
Specifications of OpenFlow

OpenFlow is a specification that is an initial attempt to meet the goals of high-performance and low-
cost implementations, capable of supporting a broad range of research, assured to isolate experimental
traffic from production traffic and consistent with vendors’ need for closed platforms.

OpenFlow Switches

OpenFlow switch consist of flow table, secure channel and OpenFolw protocol. A Flow Table consists
of actions associated with each flow entry, to tell the switch how to process the flow. A Secure Channel
connects the switch to the controller, allowing commands and packets to be sent between a controller
and the switch. The OpenFlow Protocol provides an open and standard way for a controller to
communicate with a switch.

There are two types of switches

 Dedicated OpenFlow switches

 OpenFlow-enabled switches

Dedicated OpenFlow switch does not support normal Layer 2 and Layer 3 processing. It is a dumb
datapath element that forwards packets between ports, as defined by a remote control process. Flows
are broadly define, Switch is limited only by the capabilities of the particular implementation of the
Flow Table.

Actions used in Dedicated OpenFlow switch

1. Forward packets to a given port (or ports)

This allows packets to be routed through the network. In most switches this is expected to take place at
line rate.

2. Encapsulate and forward packets to a controller

Packet is delivered to Secure Channel, where it is encapsulated and sent to a controller. Typically used
for the first packet in a new flow, so a controller can decide if the flow should be added to the Flow
Table. Or in some experiments, it could be used to forward all packets to a controller for processing.

3. Drop packets

Can be used for security, to curb denial of service attacks, or to reduce spurious broadcast discovery
traffic from end-hosts.

9|Page
An entry in the Flow-Table has 3 fields

 A packet header – To define the flow

 The action – To define how the packets should be processed

 Statistics – to keep track of the number of packets and bytes for each flow, and the time since
the last packet matched the flow (to help with the removal of inactive flows). Statics is used as
feedback mechanism to the switch.

OpenFlow-enabled Switches

Some commercial switches, routers and access points will be enhanced with the OpenFlow feature by
adding the Flow Table, Secure Channel and OpenFlow Protocol. Flow Table will re-use existing
hardware, such as a TCAM; the Secure Channel and Protocol will be ported to run on the switch’s

10 | P a g e
operating system. All the Flow Tables are managed by the same controller. The OpenFlow Protocol
allows a switch to be controlled by two or more controllers for increased performance or robustness.

OpenFlow-enabled switches must isolate experimental traffic (processed by the Flow Table) from
production traffic that is to be processed by the normal Layer 2 and Layer 3 pipeline of the switch.
There are two ways to achieve this separation. Add a fourth action other than previously mentioned 3
actions.

4. Forward this packets through the switch’s normal processing pipeline

Or define separate sets of VLANs for experimental and production traffic.Both approaches allow
normal production traffic that isn’t part of an experiment to be processed in the usual way by the switch.
All OpenFlow enabled switches are required to support one approach or the other, some will support
both.

11 | P a g e
Controllers

A controller adds and removes flow-entries from the Flow Table on behalf of experiments. For an
example, a static controller might be a simple application running on a PC to statically establish flows
to interconnect a set of test computers for the duration of an experiment. In this case the flows resemble
VLANs in current networks—providing a simple mechanism to isolate experimental traffic from the
production network. OpenFlow is a generalization of VLANs. The controller should be seen as a
platform that enables researchers to implement various experiments. The exact nature of these
permission-like mechanisms will depend on how the controller is implemented. NOX is an example for
a controller.

If someone want to try their protocol in a network of OpenFlow Switches, without changing any end-
host software. The protocol will run in a controller; each time a new application flow starts that
protocol picks a route through a series of OpenFlow Switch, and adds a flow entry in each switch
along the path.

If someone is testing a new protocol in a network used by lots of other people. It will have two additional
properties as mentioned below.

 Packets belonging to users other than the researcher should be routed using a standard and
tested routing protocol running in the switch or router from a “name-brand” vendor.
 The researcher should only be able to add flow entries for his traffic, or for any traffic his
network administrator has allowed her to control.

Examples for using OpenFlow

Examples of how OpenFlow enabled networks could be used to experiment with new network
applications and architectures are briefly discussed below.

 Network Management and Access Control

A controller associates packets with their senders by managing all the bindings between names and
addresses—it essentially takes over DNS, DHCP and authenticates all users when they join, keeping
track of which switch port (or access point) they are connected to.

12 | P a g e
  VLANs

OpenFlow can easily provide users with their own isolated network, just as VLANs do. The simplest
approach is to statically declare a set of flows which specify the ports accessible by traffic on a given
VLAN ID. Traffic identified as coming from a single user (for example, originating from specific switch
ports or MAC addresses) is tagged by the switches (via an action) with the appropriate VLAN ID.

 Mobile wireless VOIP clients

In an experiment of a new call- handoff mechanism for WiFi-enabled phones. In the experiment VOIP
clients establish a new connection over the OpenFlow enabled network. A controller is implemented to
track the location of clients, re-routing connections — by reprogramming the Flow Tables — as users
move through the network, allowing seamless handoff from one access point to another.

 A non-IP network

Previous examples have assumed an IP network, but OpenFlow doesn’t require packets to be of any
one format — so long as the Flow Table is able to match on the packet header. This would allow
experiments using new naming, addressing and routing schemes. There are several ways an OpenFlow-
enabled switch can support non-IP traffic. Flows could be identified using their Ethernet header (MAC
src and dst addresses), a new EtherType value, or at the IP level, by a new IP Version number.

 Processing packets rather than flows

The examples above are for experiments involving flows — where a controller makes decisions when
the flow starts. There are, of course, interesting experiments to be performed that require every packet
to be processed.

an intrusion detection system that inspects every packet, an explicit congestion control mechanism, or
when modifying the contents of packets, such as when converting packets from one protocol format to
another.

Two basic ways to process packets in an OpenFlow-enabled network

 Force all of a flow’s packets to pass through a controller.

Controller doesn’t add a new flow entry into the Flow Switch. It just allows the switch to default to
forwarding every packet to a controller. Advantage of this method is its flexibility, at the cost of
performance and its simplicity. It might provide a useful way to test the functionality of a new protocol,
but is unlikely to be of much interest for deployment in a large network.

 Process packets

13 | P a g e
Here route packets to a programmable switch that does packet processing. As an example a NetFPGA-
based programmable router which is a PCI board that plugs into a Linux PC. Advantage in this method
is that the packets can be processed at line-rate in a user-definable way.

Conclusion

OpenFlow allows for rapid app development in network layer. Controller act as an abstract layer. It
communicates with network devices using OpenFlow protocol. And also OpenFlow provides open
interface or open API managing flow table of the device without considering the vendor or OS of the
network devices. OpenFlow is a pragmatic compromise that allows researchers to run experiments on
heterogeneous switches and routers in a uniform way, without the need for vendors to expose the
internal workings of their products, or researchers to write vendor-specific control software.

14 | P a g e
Summary Report – Kokila Hettiarachchi - 169223M
Topic: On Controller Performance in Software-Defined Networks
Referenced Paper:
https://pdfs.semanticscholar.org/316a/bee19b57af2d85bf09b56350e29fa426412f.pdf
Summery:

1. Introduction

Software Defined Networking(SDN) is a modern architecture that helps to split the data plane and
control plane in a network. It provides structured software environment to deploy network wide
abstractions while potentially simplifying data plane. The delegation of control to a remote system has
raised following questions:
(a) How fast can the controller respond to data path requests?
(b) how many data path requests can it handle per second?
But there were no any in-depth researches done till this one. Most published results were got from the
systems never optimized on performance. Therefore, these researchers developed a more effective new
network controller named NOX-MT and compared its performance with already developed controllers
NOX, Beacon, and Maestro.

2. NOX - MT

The already available controller NOX, an open source controller for OpenFlow networks, is not
optimized for performance and is single-threaded. Newly presented NOX-MT is a modified multithreaded
successor of NOX. NOX-MT is also optimized using various techniques. It has performance more than 30
times further.

3. Experiment Setup

They created a custom tool ‘cbench’ to measure the number of flow setups per second that a controller
can handle. It measures various performance issues related to flow setup time. Cbench emulates a
configurable number of OpenFlow switches that all communicate with a single OpenFlow controller. It
supports two modes of operation: latency and throughput mode to measure parameters related with
above (a) and (b) questions.

4 Controller Throughput

15 | P a g e
According to the result of the experiment NOX-MT shows a significantly better performance compared to the
other controllers. And all the multi-threaded controllers achieve near-linear scalability with the number of threads
(cores), because the controller’s workload is mostly read-only minimizing the amount of required serialization.
Increasing the number of switches beyond a threshold reduces the overall throughput. And, as per the research the
average delay with unlimited outstanding requests is almost an order of magnitude larger than the limited ones
even though they achieve the same level of throughput.

Write-intensive workloads increase the contention in the network control applications. Both Maestro and Beacon
are significantly affected by this workload. But NOX-MT does not exhibit a similar behaviour. That is because
its switch application minimizes contention in such scenarios.

4 Controller Response Time

Average minimum response times of all controllers are between 100 and 150 microseconds. Since NOX-MT has
the highest throughput, it has the least maximum response time compared to others. The same workload adding
more threads decreases the response time. Also, doubling the number of outstanding requests doubles the response
time, but does not significantly affect the throughput. Adding more CPUs beyond the number of switches does
not improve latency, and serving far larger number of switches than available CPUs results in a noticeable increase
in the response time.

16 | P a g e