Redes

1. See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/333237818
Design of SDN manageable switch
Preprint · May 2019
DOI: 10.13140/RG.2.2.27582.33600
CITATIONS
0
READS
157
4 authors, including:
Some of the authors of this publication are also working on these related projects:
DNS Miss-configuration Research View project
Networks View project
Petar D. Bojović
Univerzitet Union - Računarski Fakultet
76 PUBLICATIONS 9 CITATIONS
SEE PROFILE
Zivko Bojovic
University of Novi Sad
28 PUBLICATIONS 27 CITATIONS
SEE PROFILE
Nikola Gavrić
University of Novi Sad
3 PUBLICATIONS 0 CITATIONS
SEE PROFILE
All content following this page was uploaded by Petar D. Bojović on 21 May 2019.
The user has requested enhancement of the downloaded file.

2. Design of SDN manageable switch
Petar D. Bojović
The School of Computing Union
University Belgrade
Belgrade, Serbia
petar.bojovic@paxy.in.rs
Živko Bojović
Faculty of Technical Sciences,
Trg D. Obradovića 6, 21000 Novi Sad,
Serbia
zivko.bojovic@uns.ac.rs
Jelena Šuh
Telekom Srbija
Bulevar umetnosti 16a, 11000 Belgrade,
Serbia
jelena.suh@gmail.com
Nikola Gavrić
Faculty of Technical Sciences,
Trg D. Obradovića 6, 21000 Novi Sad,
Serbia
nikolagavric021@gmail.com
Abstract ​- Software Defined Networking is becoming one of
the most important technologies used in modern computer
networks. However, majority of SDN implementations exist in
virtual environments and it lacks implementations in physical
networks. This greatly impacts SDN practical use and slows down
the spread of knowledge about its capability. The goal of this
paper is to show the design of physical device that can act as a
fully controllable SDN switch. The Open vSwitch with the full
support of the OpenFlow protocol is used with the hardware
platform to enable OpenFlow controllable Ethernet ports. We
have measured performance and discussed the results of the
presented solution.
Keywords - Software Defined Networking, OpenFlow, Open
vSwitch, SDN hardware
I. INTRODUCTION
The architecture of computer networks today has been largely
influenced by the expansion of IP traffic, wide application of
new technologies and services based on them. Traditional
computer networks, with a hierarchical design, are unable to
adequately respond to user requests. They are burdened with
numerous problems, caused mainly by the complexity of
heterogeneous computer infrastructure management and a
large number of functions defined in the hardware. The
solution to these problems requires the introduction of a higher
degree of programmability into a computer network using
software-defined networking technology (SDN). The concept
of SDN technology is based on the separation of control plane
and data plane, which enables synthesis and simplifies the
implementation of various advanced technologies, and
provides network administrators and service provider’s easier
management and optimization of resources in networks [1].
The implementation of this technology achieves a high level of
network reliability and elasticity that is required to respond
quickly and efficiently to the constant application
requirements (especially cloud applications) for real-time
changes. A key feature of the SDN network design is the
ability to manage devices and traffic from a centralized
location, and to deploy services were required in real time and
without taking into account the specifics of devices
implemented in the network (Fig. 1).
In traditional IP networks, network switches are used for
traffic switching, namely for a reception, processing, and
forwarding to another network device. With the emergence
and expansion of virtual computing infrastructure, traditional
network switches are gradually being replaced with SDN
switches, which are already in use and have support for the
OpenFlow protocol [2]. This protocol provides communication
between the SDN controller and the network devices on the
infrastructure layer.
Figure 1. SDN architecture
The OpenFlow protocol is an open standard (it is independent
of the manufacturer of the equipment) and guarantees full
interoperability in the operation of equipment from various
vendors. It is implemented in existing physical and virtual
networks, and because of its flexibility in the multi-vendor
environments. Its basic characteristic is that it uses the concept
of data flows for traffic recognition based on predefined rules,
which are statically or dynamically defined in the control
software or inflow tables. The SDN controller, using the

3. OpenFlow protocol, via one or more channels, through secure
communication (via SSL), modifies the existing one or writes
new data flow records into flow tables of OpenFlow switch
and defines the instructions for traffic forwarding. (Fig. 2).
Figure 2. OpenFlow switch
Today SDN networks are realized on the existing physical
infrastructure by replacing existing devices with
OpenFlow-enabled devices, or by building an overlay network
in which the SDN controller communicates with the existing
infrastructure via BGP and SNMP protocols. Wider
implementation is still not at the expected level, and the reason
for this is the high cost of SDN devices. These devices are
mainly used to edit BGP flows on the Core layer in the ISP
networks.
The fact is that there are not yet adequate devices on the
market that would forward packets based on the data flow
tables, and that would use OpenFlow to manage records in
flow tables. Support for the OpenFlow protocol and thus SDN
is still in the development phase and it's quite difficult to find
devices that support the development of OpenFlow standards
(the current OpenFlow version is 1.5.1.).
Therefore, the task of our research was to make an adequate
OpenFlow switch based on Open vSwitch (OVS) software
solution. An experiment was performed with the goal of
having a physical device that can be controlled through the
OpenFlow protocol, and during the experiment, it was using:
● Open vSwitch software for data flow management via
OpenFlow protocol
● Soekris net4801 hardware development platform with
support for Linux OS and a larger number of network
ports and
● Preboot eXecution Environment (PXE) procedure for
booting the operating system via a computer network.
II. OPEN VSWITCH
For the realization of the SDN switch that supports the
OpenFlow protocol, Open vSwitch (OVS), a software
multilayer switch (Linux Foundation project with Apache 2.0
license) was used [3]. It is located within the hypervisor and
allows communication between virtual machines, but also with
the rest of the network through physical interfaces (Fig. 3).
Figure 3. Open vSwitch use case
This software enables dynamic creation of endpoints,
providing continuous logical abstraction and relocation of
certain functions from hardware to software. Its main features
are:
● Support for LACP protocol
● NIC bonding and load balancing (similar to Cisco
EtherChannel)
● Support for 802.1Q VLANs and trunking
● Traffic monitoring of virtual machines (sFlow,
NetFlow, SPAN, RSPAN)
● Fine traffic granulation (Access lists and QoS policy)
● Centralized control via OpenFlow protocol
● Support for Linux Hypervisors: Xen, XenServer,
KVM, VirtualBox
● Kernel and userspace switch implementation
● Tunneling and
● Full functionality L2 switches.
Figure 4 shows the architecture of the OVS with eight key
components and the concept of flow control:
● ovs-vswitchd​ - daemon that implements the switch
● Linux kernel - module for flow-based switching
● ovsdb-server​ - a lightweight database server
● ovs-dpct - a tool for configuring the switch kernel
module
● ovs-vsctl - a utility for querying and updating the
configuration of ovs-vswitchd
● ovs-appctl - a utility that sends commands to running
Open vSwitch daemons
● ovs-ofctl - a utility for controlling the OpenFlow
features of OVS
● ovs-pki - a utility for creating and managing the
public-key infrastructure.

4. Figure 4 Open vSwitch software architecture
As seen in Fig. 4, the main component of the system is the
ovs-vswitchd module that, via the OpenFlow protocol,
manages network flows in each instance and communicates
with the rest of the network. It communicates with the ovsdb
server using the OVSDB protocol and creates and configures
virtual network instances (editing Open vSwitch configuration
[4] via netlink with kernel, while communicating with the
system through the netlink interface. It is important to point
out that the OVS is also used due to the need to enable
communication between various hosted virtual machines
between which the network infrastructure needs to be built. In
this sense, for the encapsulation of traffic and the creation of
overlay networks between the hypervisor hosts the GRE tunnel
is used (Fig. 5). This process consists of three steps:
● An isolated bridge is made to connect virtual
machines
● GRE tunnel endpoints are created on each hypervisor
● GRE interfaces are added and GRE tunnel is
established.
Figure 5. Interconnection between two OVS hypervisors
III. EXPERIMENT
A. Hardware platform
As the main component, we have used Soekris net4801 [5]
hardware platform with characteristics shown in Table 1.
TABLE 1. SOEKRIS NET4801 HARDWARE PLATFORM
CPU AMD SC1100 266 MHz
RAM 128MB PC133 SDRAM
BIOS 512KB FLASH Soekris comBIOS
Bus 1x PCI slot, 1x miniPCI
Ethernet 3x FastEthernet DP83816
Disc CompactFlash
Power Supply 6-28V DC, 15W max
The device is upgraded with an additional LAN card with four
additional Fast Ethernet ports, i.e. with Soekris lan1641 PCI
card. It's all packed in a dedicated box to get a complete
solution. 2GB CompactFlash card has been used to store the
Linux operating system (Fig. 6).
Figure 6. Soekris net4801 hardware platform with lan1614 extension
B. Pre-testing preparations
Installation of the operating system on headless devices
without a graphics card can be performed on a CF/SD card of
a pre-prepared clone image system, by installing a pre-external
media system (USB flash or USB CDROM) or by installing
the system over the network, i.e. PXE Boot [6]. In our
experiment, due to the characteristics of the available
hardware, the installation has performed via PXE boot, and the
old version of Linux Ubuntu Server 10.04.4 LTS was used.
Due to the large repository of already prepared packages,
Linux Ubuntu was selected, and the Open vSwitch package
installation was a simple call of the repository installation. For
measurement of the performance of the switches, the IPref3
toolbox for active measurement and network resource stress
testing [7] was installed. Ports were configured so that the first
port of the device gets an address through the DHCP service
and communicates with the OpenFlow controller, while the
remaining ports were being controlled by instructions from the
flow table of the OVS (Fig. 7).

5. Figure 7 Logical distribution of port roles
C. Testing scenario
For the testing scenario, we have connected Soekris board to a
LAN network over eth0 port. The switch obtained a dynamic
IP address that was used to access it over SSH in order to set
SDN controller parameters like IP and port.
At one of the servers in LAN, we have set a simple POX [8]
SDN controller. On the controller, the L2 forwarding module
was enabled, so SDN switches would perform exactly as
traditional L2 switches (learning and forwarding). Tcpdump
tool was used in order to collect packet logs related to
OpenFlow protocol and to allow further controller traffic
analysis.
Two Linux based PC clients were connected to managed ports
eth1 and eth2 of the SDN switch. Both of them have been
configured with a static IP address for simpler IP
configuration. One of them has been configured as IPerf3
server and the other one has been used as the client for
different IPerf3 tests.
The SDN switch was configured to log states of system
resources into a text file every second. Initially, OVS was
configured to use the default, userspace datapath and to switch
to a better-optimized kernel datapath later.
IV. TEST RESULTS
The main goal of this work is to have full OpenFlow SDN
functionality and by using OVS component this goal is
satisfied. We have got a functional OpenFlow-manageable
hardware switch with 6 manageable ports and one controlling
port and we have tested its performance.
During this research, we have found that OVS supports an
optimized datapath using kernel space module and we have
made a comparison of performance in both datapaths (Fig 8a,
8b).
Figure 8b. Bandwidth test on user datapath
Figure 8a. Bandwidth test on kernel datapath
For further testing, we have used kernel mode datapath due to
greater performance, but even with it, maximal bandwidth
with this solution has been about 50 Mbps. For this reason, our
next step was detailed CPU usage analysis (Fig. 9). This
analysis has shown that even with Kernel datapath, our
hardware platform is not powerful enough to accomplish
wire-speed (100mbps) throughput between just two
manageable ports.
Figure 9. CPU usage analysis
As the part of performance measurements, we have also
recorded and analyzed traffic between SDN switch and
controller. Even during a high load (like bandwidth test), the
amount of data traffic exchanged with the controller was
insignificant and without a large impact on packets RTT (Fig.
10a, 10b, 10c).
Figure 10a. Packets RTT between SDN switch and controller
Figure 10b. Number of packets between SDN switch and controller
Figure 10c. Bandwidth between SDN switch and controller
Bandwidth coming from SDN switch to controller in the
moment of the high load test has not been huge, but the
number of packets has been surprisingly large. Explanation for
this, is the way IPerf is designed to test bandwidth. It creates

6. new and parallel connections each second, so for every new
connection, packets have to be inspected by the controller.
V. DISCUSSION
By implementing the Open vSwitch software solution to
hardware platforms with multiple Ethernet cards, a device with
full OpenFlow SDN functionality can be built. Performance
tests show that OVS is highly dependent on CPU as it is a
software solution. Obtained results show that the performance
of the solution highly depends on CPU performance, therefore,
it might not be the best solution for every use case. More
powerful hardware boards with multiple Ethernet ports would
easily pass limitation of 50Mbps on Soekris net4811 board.
This limitation is not per port, but it is the total throughput of
the entire board. In the case of using multiple ports,
performance would decrease further. There has been some
research on switching chips, that will allow easy management
of the data flows, so in the future, we can expect hardware
offloading and data plane [9].
VI. CONCLUSION
Traditional networks with a hierarchical organization are
largely unable to respond to an increasing number of network
problems and challenges arising from the emergence of new
technologies and services based on them. These problems are
mainly related to the need to ensure an adequate level of
scalability, elasticity, reliability, resistance, security and better
performance in the network. We believe that the
implementation of the SDN networking concept and
OpenFlow protocol will solve many problems, but we are
aware that some problems will remain a great challenge (for
instance, a new design of SDN switch might bring a new
solution and at the same time bring new challenges or issues).
In an attempt to find the appropriate solution, we have
conducted the experiment with SDN switch and measured its
performance. The obtained results have showed, that
hardware driven OVS might not be the best solution if there is
a demand for high performance, but surely it can provide a
starting point in introducing SDN functionality in physical
networks.
REFERENCES
[1] J. Suh, Z. Bojovic., M. Despotovic-Zrakic, Z. Bogdanovic, A.
Labus: Designing a course and infrastructure for teaching
software-defined networking, Computer Applications In
Engineering Education, Vol. 25, No. 4, pp. 554-567, 2017.
[2] J. Matias, J. Garay, N. Toledo, J. Unzilla, E. Jacob: Toward an
SDN-enabled NFV architecture, IEEE Communications Magazine,
Vol. 53, No. 4, pp. 187-193, 2015.
[3] OpenVSwitch (OVS), Multilayer Open Virtual Switch, Linux
Foundation Collaborative Project, https://www.openvswitch.org/
[4] B. Pfaff, B. Davie, The Open vSwitch Database Management
Protocol, VMWare, RFC7047, December 2013,
https://tools.ietf.org/html/rfc7047
[5] Soekris Engineering net4801 series boards and systems, Soekris
Engineering, April 2004,
http://soekris.com/media/manuals/net4801_manual.pdf
[6] W. Miller, The Desktop Files Network-Booting Windows,
Microsoft TechNet, July 2008,
https://technet.microsoft.com/en-us/library/2008.07.desktopfiles.as
px
[7] J. Dugan, S. Elliott, B. A. Mah, J. Poskanzer, K. Prabhu, iPerf3,
tool for active measurements of the maximum achievable
bandwidth on IP networks, https://iperf.fr/
[8] Project POX, Networking software platform written in Python,
https://github.com/noxrepo/pox
[9] Open vSwitch Hardware Offload Over DPDK,
https://www.dpdk.org/wp-content/uploads/sites/35/2018/03/Open-v
Switch-Hardware-Offload-Over-DPDK.pptx
View publication stats
View publication stats