Professional Documents
Culture Documents
البحث
البحث
Network usage and demands are growing at a very fast rate and to
meet the current requirements, there is a need for automatic infrastructure
scaling.
1
Table of Contents
1 ...................... ................................ ................................ ................................ Abstract.
3 .................................. ................................ ................................ 1. Chapter 1: Overview
3 ........................................ ................................ ................................ 1.1 Introduction
4 ......................................... ................................ ................................ 1.2 Background
5 ....................................... ................................ 1.3 Problem Statement and Motivation
6 ......................................... ................................ ................................ 1.4 Project Aim
6 ............................... ................................ ................................ ject Objectivesٍ1.5 Pr
7 ...................................... ................................ ................................ 1.6 Project Scope
7 ...................... ................................ ................................ 2. Chapter 2: Literature Review
7 ............ ................................ ................................ ................................ 2.1 Introduction
7 ........................................ ................................ 2.2 SDN Architecture and Components
28 .................... ................................ ................................ Methodology 3.
28 .............................. ................................ 3.1 SDN Setup with OpenDaylight Controller
28 .............. ................................ ................................ 3.1.1 Environment Requirements
29 .................... ................................ ................................ 3.1.2 Virtual Machines Setup
29 ................... ................................ 3.1.2.1 Configuring guest OS in Virtual Machines ej:.
33 ...................... ................................ 3.1.2.2 Virtual Machines’ Interface Configurations
31 .............................. ................................ 3.2 Installing and Configuring Open Daylight
35 ............ ................................ ................................ Installing and Configuring Mininet
37 .................. ................................ ................................ 3.3.1 Connect Niininet to ODL
38 ........................................ ................................ ................................ 3.3.2 Topology
39 ............. ................................ ................................ ................................ 4.1 Metrics
39 .................................. ................................ ................................ 4.1.1 Performance
39 .................................. ................................ 4.2 SDN Network vs. Traditional Network
39 .......................................... ................................ ................................ 4.2.1 Latency
41 ............. ................................ ................................ ................................ 4.3 Results
42 .................. ................................ ................................ ................................ Chapter 5
42 ............. ................................ ................................ ................................ Conclusion
44 ............. ................................ ................................ ................................ References
2
1. Chapter 1: Overview
1.1 Introduction
Computer networks are a complex technology that enables end-
devices to communicate with each other. A typical network infrastructure
includes routers, switches, servers, web servers, fïrewalls, load balancers,
intrusion prevention systems and other devices. Efficiency, reliability,
flexibility and robustness are the requirements for processing and
managing the tremendous amount of data sent over the network. That has
made the manufacturing companies of networking devices to implement
complex and resource intensive protocols that enable routers and switches
to communicate with each other by packet switching and creating a
networking topology for routing purposes [3].
3
hardware and share the same resources. This paradigm is adopted by
Software-Defined Networking (SDN), one of the most
Other driving forces for SDN were that the academic community
needed a large scale “sandbox” and data centers required the provisioning
to be fast to meet today‟s requirements. First, the separated data and
control planes enabled the researchers to conduct experiments vo1atng
other layers and traffic — this was a reason why OpenFlow protocol was
developed. Secondly, as long as current data centers are moving to cloud
technologies, the underlying networking infrastructure should be able to
change quickly. Thus, SDN has been an excellent solution for everything
mentioned above. [4]
1.2 Background
The demand for more effective networking environment is required
in today‟s immutable infrastructure to handle with rapidly changing
requirements of the users. Therefore (SDN) Software Defined
Networking was brought in around 2005 to reconstruct current network to
have accelerated innovation, consolidate administration and
4
programmability by separating the data plane and control planes.
Traditionally, the network admin has to control from the network
management plane in order to configure each network‟s devices
separately. This static setup of current • network devices does not permit
control-plane configuration. The Software-defined networking
(SDN)approach allows for open, user-controlled, management of the
forwarding hardware in network elements. SDN implements centralized
control- plane intelligence while keeping the data plane separate, which
in turn enables the administrator to configure network hardware directly
from the controller. This approach of centralizing control of the entire
network makes the network highly flexible. To meet growing demand
and cater for network instability, many researches proposed Software
Defined Networking (SDN) combined with network function
virtualization (NFV). SDN isolates the network control logic from the
hardware which in turn enables the network administrator to have more
control over network. functions and a global view of networks . [ 1]
These protocols in fact have been very helpful to the industry. They
are mostly standard. Different vendors and products can communicate
using standard protocols with each other. A Cisco router can establish a
BGP session with a Huawei switch or an open source Quagga router can
exchange OSPF routes with a Juniper firewall.
5
components such as spanning tree, BGP, OSPF, link aggregation, and so
on. Each device uses these protocols to build a network from its own
perspective.
SDN can help us to come out of the routing protocol cage, look at
different ways to forward traffic. SDN can directly program each switch
or even override a route that is installed by routing protocols.
ject Objectives
. Define SDN architecture — future of networks — and its features
over traditional network.
6
1.6 Project Scope
This project will focus on building SDN topology with mininet
emulator connected with Open daylight controller to show how SDN
network performance i ڑbetter than traditional network where the metric
is the latency.
2.1 Introduction
Tri this chapter we will describes the SDN architecture and its
components. In addition, data and control planes will be covered
separately for a better understanding. To understand how communication
between each layer works, northbound and southbound interfaces will be
described. In the end, we will provide an overview of the existing SDN
controllers and give an introduction to the Open Daylight (ODL)
controller that has been chosen in our project to be the SDN controller.
7
switches and routers, including forwarding components, and
Application Programming Interfaces (API).
8
A southbound interface is defined as the connection between
networking devices and controllers, whereas the northbound interface is
the connection between applications and the controllers [5].
In contrast, the SDN technology uses flow tables, which are not the
same. as FIB tables. The FIB table is a simple set of instructions based on
destination-based switching, whereas the flow table includes a sequential
set of in tructions and actions.
Sometimes, the data plane is referred to as the fast path for packet
management because it requires no further investigation other than an
address extraction of the packet destination relying on preprogramed FIB.
But one exception exists in the above mentioned process if the packet
destination is not found from the lookup tables. In order to proceed, the
detected packet with an unknown address is sent to the control plane
where the controller makes a forwarding decision using the Routing
Information Base (RIB) table, which contains topology, network
destinations and metrics associated with routes. In case of SDN, it resides
on a software-based controller. [1]
9
Depending on a system, a separate discrete tables may exist for these
features or they can act as extensions to the forward-in tables. [1]
Access Control List (ACL): Can specify drop, alter, pass and
b ther actions for a specific matching flow. Quality of
Service (Qos): Mapping a flow to a queue on an egress to
normalize and provide an uninterruptible service. It may
specify packets to be dropped regardless of the forwarding
policy.
Referring to hardware, there are white box switches which exist for
SDN purposes. They represent foundational elements of the networking
infrastructure that enable organizations to choose and use only those
features they need to realize as their SDN objectives.
13
The white box switches can corne with pre-installed OS with
minimal software installed or be sold as a bare metal device. This allows
users and businesses to customize switches according to their needs. [3]
11
ODEN Source SDN Platfoini Littitum:
12
collection. Although, the implementation of the flow tables may vary
from one vendor to another, that run on many exploits them. there is a
common set of functions routers.
The Open Flow As mentioned above, using the Open Flow protocol,
a controller is able to not only set forwarding statistics, by de-tails, ports,
connectivity but learn the status and the Controller the switch to a remote
control process (called the controller), allowing flow network topology of
Ethernet switches. entries, Scope of Open Flow Switch
(1)a Flow Table, with an action associated with each flow entry, to
tell the switch how to process the flows, (2) a Secure Channel that
connects commands and packets to be sent between a controller and the
switch usmg (3) the Open Flow Protocol, which provides an open and
standard way for a controller to communicate with a switch [11].
13
Flow flow tables and group tables and virtual from in table consist of
flow entries a traffic flow coming
the packet to another and again. A flow entry can backwards (see
figure When the packet processing pipeline stops, the Packet In — o
Packet Out -p- Figure 2. 4 Packets match against tables table for a packet
is missing, several instructions that can be set for this dropping the
packet, passing it to a not her Options flow-table or sending controller
over the control channel as shown in figure 2.5.
14
OpenFlow Channel is the interface that is used for a connection
between each Open-Flow switch controller can receive switch generated
events, send packets out of the last but not least, configure connection
between the switch and the controller Transport Layer Security (TLS)
protocol. However, it may be run directly over Transmission Control
Protocol (TCP). [12].
2.6ControlPlane
15
2.7 Northbound Interfaces
The role of the northbound interface is to provide a high-level API
between the controller and applications that can compute network
operations based on the events collected by the control plane. Figure 2.6
represents the existing APIs in the SDN system.
16
DN cotrollers reside on the control plane. They are the “brains” of
the network and Perform management functions over switches or routers
via southbound APIs. There are several open source controllers available
for usage, for example, Open Daylight, Flood-light, Open Contrail and
Flow Vis or.
17
Figure 2. 7 Structure of the OpenDaylight Controller. Copied from(3).
As a southbound protocol, the OpenDaylight can use, for example,
OpenFlow 1 .0- 1 .3 and BGP-LS protocols. [2]
18
modules like Topology Manager are provided by the SAL. As long as
services are constructed using the features exposed by the plugins, the
SAL can map to the appropriate plugin and use the most appropriate
southbound protocol for networkig device interaction based on the
service request. Figure 11 represents the previous mentioned plugin
linking.
19
Scalable in the development process: There is no common
infrastructure subsist-tern, Instead, plugins are developed
idependently of each other. Thus, the controller has short
integration times.
Run-time extensible: The controller can easily adapt to new
data models and dynamically load other plugins.
21
An SDN controller is the single brain of the SDN domain. In fact, an
SDN domain is very similar to a chassis-based switch. You can imagine
the supervisor or management module of a chassis-based switch as an
SDN controller and the rest of the line card and I/O cards as SDN
switches. The main differençe between an SDN network and a chassis-
based switch is that you can scale out the SDN with multiple switches,
where in a chassis-based switch you are limited to the number of slots in
that chassis:
22
It is very important that you understand the main technologies
involved in SDN. These methods are used by SDN controllers to manage
and control the SDN network.
In general, there are two methods available for controlling the fabric:
23
(vendor here is referring to switch vendor such as Cisco or Juniper
or Arista, and so on.):
The switch silicon is like a comparison table. It maps the frames to
ports. When a switch receives a packet, it looks into its content-
addressable memory (CAM) table to find out what needs to be
done to this frame received on port X. The CAM table, which is
already programmed and filled by the switch software, will have an
entry to tell the switch silicon what needs to be done on that frame.
For example, send it out of port Y and change the destination MAC
to switch burned in MAC. Or any other decision such as sending it
to the switch CPU for processing (if it‟s a routing protocol packet,
for example an OSPF LSA).
So in simple terms, in standard switches the CAM table of a switch
is filled by entries that are programmed and controlled by switch
CPU or switch software.
In SDN, we have a slightly different scenario, you can imagine that
th DN• controller will control the CAM table of all switches. The
terms are changed slightly and it is called a flow table. A flow table
is nothing but the same CAM entries in the switch, but it‟s called a
flow table and each entry is called a flow entry.
SDN controller programs each switch CAM table via a protocol
that is called southbound protocol. There are multiple southbound
protocols where the most famous and standard one is Open Flow;
however, the others such as NETCONF and OVSDB also exist in
standard protocol groups. Cisco‟s OpFlex (https ://tools. i etf.
org/html/draftsrnithopflexo3) is also an open source protocol which
is a southbound protocol between Cisco APIC controller and Cisco
Nexus switches. OpFlex is also supported on Open Daylight.
24
Open Flow is a protocol that allows SDN controller to program
each switch in the SDN network. Please remember that the Open
Flow is a piece of software, it‟s a protocol. The Open Flow agent
runs on each switch and starts communicating with the OpenFlow
server piece on SDN controller
You may have heard about overlays. about the SD-WAN,
networking. An overlay is a Especially if you have heard based on
overlay on top of an underlay network. Seems complex? Let me
provide a more familiar example. An SSL VPN tunnel is an
overlay on top of a IP network. InSSL VPN, the underlay is IP, and
an overlay is an SSL.
The real packets are encapsulated as new payload inside the
packets. You can make more examples of overlays, and also the
new overlays such as VXLAN and NVGRE:
25
networks there are two main protocols used for encapsulation:
VXLAN and NVGRE.
VXLAN is a UDP packet, which encapsulates the whole W packet
as a T.JDP payload and sends over the other end. VXLAN
endpoints are called Virtual Tunnel End Points (VTEP). VTEPs
create virtual tunnels between each other and transmit the UDP
packets that are all having the packets encapsulated inside the UDP
payload.
VXLAN uses an identification number for networks called virtual
network ID (VNID), which identifies which packet belongs to
which virtual network.
VXLAN is very common between most of the vendors and are
very well supported.
Network Virtualizatjon using GRE (NVGRE) is another protocol
similar to VXLAN, but it is not very popular. Microsoft is one of
the promoters of NVGRE on their SONIC switch operating system.
The most important overlay solution on the market is VMware
NSX.
Now we have learned very briefly about DN and overlays, let‟s
have a comparison between these two technologies:
Table 2. 1 comparison between DFP and Overlay
26
In summary, SDN and overlays are somehow completing each
other, but they are different. ome people don‟t consider overlays
as SDN, and some do.
27
Chapter 3:
3. Methodology
1. Two Core.
2. Four GB RAMI.
3. 32 GB HDD.
4. Tow virtual network adapters (1 adapter for Secure Shell (SSH)
connection to the VM and 1 for intercommunication between the
controllers and Mininet).
28
1. One Core.
2. Two GB RAM.
3. 12GBHDD.
4. VM, case 1 for intercommunication of connection with with the
controllers and other virtual the 1 spare in such as OpenvS witch).
29
VMs through the console in the Virtual Box. host, but we wanted to have
a remote connectivity to connect from any remote place.
Controller
auto ethû
iface ethO met dhcp
auto ethi
iface ethi met static
address 192.16a.5E.1Q3
netmask 255.255.255.0
network 192.1L.5E.0
gateway 19E.16.56.1
dns—nameservers
Mininet
33
At this stage, the virtual machines setup is completed. Repeat
previous steps to configure other VMs in accordance to the system
requirements.
31
1. Replace the IP address with the address configured to the second
interface of the O in the following fields: “netconf.tcp.address=”,“
netconf.tcp . client. address=” and “of. address=”2.
2. Next, start the controller by executing “./karaf”, which is a binary
file that starts the controller, in the “ODL/bin!” directory. The
controller will start and will be ready for work.
3. 2. 1 . 1 L2Switch Fea tu res In stczlla tb n Steps
karaf@root>feature:jnstall odl—l2swjtch—swjtch—uj
Verify that the components are properly installed:
karaf@root>feature:ljst —j I grep l2switch
32
following architectural components play different roles in the L2Switch
project:
33
The “odi-restconf” provides RE T APIs for applications and
supports “Options “, “GET”, “PUT”, “DELETE “ HyperText Transfer
Protocol (HTTP) commands. The “odl-rndsal-- apidocs “ provides
apidocs explorer and lists all the available APIs on the controller. The
“odi-diux all “ installs the GUI features for the OpenDaylight controller.
In order to verify that the above mentioned features are installed,
Executeufeature: list -j I grep IIIIODULE_NA[IE]J”.
34
Figure 3. 4 Launch Open Daylight CLI
Moreover, we could not find any real hardware that would support
Open Flow protocol. Thus, the Mininet was used.
35
http://mininet.org, but it has additional features that, for example, we
have not used and they would have just wasted computing resources. I !
order to install the Mininet, proceed with the following steps:
36
Afler successful installation and testing, it is now possible to connect
to the OpenDaylight controller installed in the Installing and Configuring
OpenDaylight section.
The result will show that L2 switch features work properly and ،P
connectivity between hosts in the Mininet is successfully established.
Once the GUI has been installed in section 3.3, it is now possible to check
the networking topology created by the L2Switch features.
37
exist because the project is still in the development process. That is why
the topology sometimes is not well structured as shown in Error!
3.3.2 Topology
You are able to specify different topology as mentioned earlier.
38
Chapter 4: performance evaluation
4.1 Metrics
This section presents a brief explanation of the evaluation metrics
used to test the project. The evaluation metrics used is performance
evaluation.
4.1.1 Performance
This metric evaluates the performance of an OpenFlow network and
is composed of latency and throughput measurements.
4.2.1 Latency
The main goal of this metric is to prove that SDN networks basically
have better or equal latency compared to traditional networks. To achieve
this goal a ping that measures the latency was necessary. These pings are
made in SDN.
We have chosen mininet emulator to test ping latency in SDN mode and
se • packet tracer to test in traditional network.
39
Then we implement the same topology in traditional network using
Cisco Packet Tracer, the topology in Figure 4.3 below:
43
Figure 4. 4 Ping statistics in traditional topology
4.3 Results
As shown latency of the packets what is going in traditional
networks is better than the The hosts do not know the network is being
managed, the results obtained show that there are no high latency values
in programmable networks.
41
Chapter 5
Conclusion
The goal of the project, to build an SDN system using OpenDaylight
controller in a virtualized environment, was met. Along with the
controller, an example application including virtual networking devices
was installed.
And finally to prove that SDN networks are better than traditional
network and migration to SDN is an important thing an evaluation was
performed in chapter 4. Tn chapter 2 we analyze the architecture to create
he testbed. This architecture will always have a controller that allows
transmission of instructions, management of the network, among others.
42
This type of architecture is centralized, bringing with it bottleneck
problems. The implementation of this architecture involved the choice of
equipment and software, and justifying the choices made. We also
After doing the network analysis, we found that SDNs are a valuable
asset to the new networking paradigm, because besides being easily
configured, a significant reduction in configuration time was observed as
well reduced frustration comparing to traditional networks, which have to
be configured device by device. Beyond these advantages the results
showed that, SDNs are better than a traditional network, even though the
first packet always has high latency values, because it has to be processed
by the controller, the remaining packets have lower latency comparing to
a traditional network. To close the conclusion, according to demand, the
impleméntation of this type of networks in big enterprises , the network‟s
performance level and reduction of CAPEX and OPEX, among others,
allow us to state that the networking paradigm will change in 10 years‟
time so migration to SDN is the best solution now a days.
43
References
1. Nadeu TD, Gray K. SDN: Software Defined Networks.
ebastopol, CA: O‟Reilly; 2017.
44
7. Open Networking Foundation. OpenFlow Switch Specification
[online]. 14 Octobei‟2 O 1 3 . URL:https ://www. opennetworking.
org/images/stories/downloads/sen..
resources/onfspecifications/openflow/openflowspecv1 .4.O.pdf.,
45
46