Abstract
Software-defined networking (SDN) represents a new structure of computer network that
simplifies and improves network management by splitting the control plane and data plane.
Since SDN is regarded as a new research issue, the application of SDN in practice faces
some barriers. Most network devices such as routers and switches that implement SDN
functionalities are expensive. An alternative solution in SDN research and experiments is to
use network emulators. By using Mininet, an open source network emulator, this study
simulates SDN implementations in different environments. Results show that the simulation
environment affects building network topology time.
13 trang |
Chia sẻ: thanhle95 | Lượt xem: 473 | Lượt tải: 1
Bạn đang xem nội dung tài liệu Emulation of software-defined network using mininet, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
DALAT UNIVERSITY JOURNAL OF SCIENCE Volume 11, Issue 1, 2021 80-92
80
EMULATION OF SOFTWARE-DEFINED NETWORK
USING MININET
Do Van Khoaa*, Tran Ngo Nhu Khanha
aThe Faculty of Information Technology, Dalat University, Lam Dong, Vietnam
*Corresponding author: Email: khoadv@dlu.edu.vn
Article history
Received: February 20th, 2020
Received in revised form: October 4th, 2020 | Accepted: December 29th, 2020
Available online: February 5th, 2020
Abstract
Software-defined networking (SDN) represents a new structure of computer network that
simplifies and improves network management by splitting the control plane and data plane.
Since SDN is regarded as a new research issue, the application of SDN in practice faces
some barriers. Most network devices such as routers and switches that implement SDN
functionalities are expensive. An alternative solution in SDN research and experiments is to
use network emulators. By using Mininet, an open source network emulator, this study
simulates SDN implementations in different environments. Results show that the simulation
environment affects building network topology time.
Keywords: Control plane; Controller; Data plane; Mininet; Software-defined networking.
DOI:
Article type: (peer-reviewed) Full-length research article
Copyright © 2021 The author(s).
Licensing: This article is licensed under a CC BY-NC 4.0
DALAT UNIVERSITY JOURNAL OF SCIENCE [NATURAL SCIENCES AND TECHNOLOGY]
81
1. INTRODUCTION
The vigorous growth of the internet and information communication technology,
along with novel technologies such as mobile, cloud computing, big data, and the rapidly
increasing demand for digital transformation, require a proportional development of
infrastructure for bandwidth, convenient access, and flexible management (Masoudi &
Ghaffari, 2016). Expansion of network infrastructure to meet these requirements will
probably make management and configuration tasks more complicated and time-
consuming (Xia et al., 2015). Software-defined networking (SDN) is designed to simplify
and improve network management, prioritizing flexibility by isolating two components:
the control plane and the data plane. This new generation of network architecture has
received much attention by researchers. However, since it is only in the early stages of
development, the lack of support for SDN by network devices (such as routers and
switches) and the high costs are impediments to research and development of SDN (de
Oliveira et al., 2014). One solution for testing and researching SDN is to use emulators.
This study simulates SDN using the Mininet emulation tool in different simulation
environments. Through the implementation of many network topologies in different
environments, the results are analyzed and evaluated to determine the impact on the
execution time when simulating SDN using Mininet.
1.1. Software-Defined Networking Overview
For SDN technology, control is centralized at the control layer, with the idea of
separating the control plane and the forwarding (or data) plane, allowing the network
control to be simpler for programming. Furthermore, the network infrastructure is
independent of network applications and services. For the user, the configuration of
network devices does not necessarily need to be done directly, but only through APIs to
build applications for the whole network (Masoudi & Ghaffari, 2016).
The SDN architecture (Figure 1) has two main components: the control plane
above and the data plane below. The forwarding component includes forwarding devices
such as routers or switches, and it communicates with the network control component via
APIs called the Southbound API. The network control section consists of the Network
Operating System and abstracted objects. Users can interact directly with the controls
through APIs called Northbound APIs. In particular, Kreutz et al. (2014) define SDN
architecture with four pillars:
• The control plane and the data plane of a network device are no longer tied
together as usual but separated. Control has been removed from network
devices, and the network device will focus on simple packet transport.
• Network devices make forwarding decisions based on the data stream, rather
than on the destination the MAC address or destination IP. A data stream
defines a set of values to match and the set of actions that will be imposed on
packets that have corresponding fields in the header matching the values. In
an SDN architecture using the OpenFlow protocol, a data stream is a
Do Van Khoa and Tran Ngo Nhu Khanh
82
collection of packets that are transferred from the source device to the target
device. All data stream packets are subject to identical service policies at the
forwarding devices. The data flow abstraction allows the behavior of
different types of network devices to be unified, including routers, switches,
firewalls, and intermediaries. Programming data flows permits
unprecedented flexibility compared to previous data flows, which were
limited to the performance of a flow table.
• Logic control is transferred to an external entity, called the SDN controller
or the Network Operating System (NOS). The NOS is a software platform
that runs on servers and provides the resources and levels of abstraction
needed to facilitate the programming of transition devices by a logical
centralized management model and the general diagram of a virtual network
system. Its purpose, therefore, is similar to that of a traditional operating
system.
• The network can be programmed through the application software running on
the NOS, interacting with the underlying data relay devices. This is a
fundamental characteristic of SDN and considered the most advantageous part.
Figure 1. Architecture overview of software-defined networking
Source: Kreutz et al. (2014).
1.2. Mininet and Controllers
1.2.1. Mininet
Presently, only a handful of tools support emulation of SDN. Among them,
Mininet is one of the most commonly used tools because of its open nature and free,
DALAT UNIVERSITY JOURNAL OF SCIENCE [NATURAL SCIENCES AND TECHNOLOGY]
83
relatively full support for the OpenFlow protocol. This tool enables creating and building
SDN quickly, customizing the network topology, and supporting functional software such
as a web server, packet analysis, and custom packet forwarding. Mininet is also user-
friendly and can be executed on a variety of hardware platforms. Operationally, Mininet
permits running multiple hosts and switches on a single operating system kernel. The
virtual hosts and switches associated with the controllers on Mininet are real entities that
are emulated in the form of software instead of hardware. A Mininet host can perform
remote access (secure shell–SSH) and execute any software installed on the system
environment where Mininet is running. Mininet not only helps users to create and
simulate network topologies simply, but it also allows them to customize network
topologies programmatically.
1.2.2. Controller
In the SDN architecture, the controller acts as the "brain" of the system, providing
a comprehensive view of the overall network and allowing the administrator to decide
how the underlying systems (e.g., routers and switches) handle network traffic. These
days, there are various controllers available, which are classified into two groups: open
source and commercial products. In addition to the default controller pre-installed in
Mininet, this study also uses two other controllers, POX and Ryu.
POX controller: an SDN controller developed on the Python platform and widely
used in research on account of its easy programming ability. POX renders a platform for
rapid prototyping and development of OpenFlow-enabled network device control
applications. POX can connect remotely to Mininet and other applications, such as
firewalls, intrusion detection and prevention systems, leftover balancing, routing, and
switching.
Ryu controller: An open-source controller based on the Python platform providing
powerful APIs to help developers program, control, and manage applications. Network
devices can be configured based on Ryu execution applications over a variety of
protocols, such as Netconf, OpenFlow, and OF-Config. By using OpenFlow, Ryu can
export statistics of the packet forwarding information of the switches so the firewall,
router, or switch function (Ali et al., 2018) can be configured.
2. RELATED RESEARCH
There have been a great number of studies using Mininet to simulate software-
defined networks. de Oliveira et al. (2014) analyzed the pros and cons of Mininet and
performed scalable testing of the Mininet network emulator tool. Their results showed
that Mininet can play an important role in supporting research on software-defined
networks due to its versatility, ease of use, and connectivity with other applications. It is
also open source, thus saving costs. In terms of practical applications, when tested on a
tree network topology with a large number of nodes (511 nodes), the execution time
increased but was still faster than the real device. Although there are some disadvantages
to network performance and system resource usage, these are acceptable, and Mininet has
become one of the most popular emulator tools. Keti and Askar (2015) evaluated
Do Van Khoa and Tran Ngo Nhu Khanh
84
Mininet's scalability on two environments with different hardware configurations using a
POX controller. Specifically, their study used a simulation environment of two computers
with different configurations to compare and evaluate the execution times needed to
create tree network topologies with different numbers of nodes. The results showed that
the simulation environment affected the topology construction time. The impact was
especially obvious as the number of network nodes in the topology increased. The
common point of these studies, however, is that they have only been tested on personal
computers with Mininet implemented in a virtual machine environment. Furthermore, the
tests used only the tree network topology.
Recently, many studies have affirmed that SDN applied in the Internet of Things
(IoT) field could help to increase network performance while solving security issues that
IoT networks have been facing when combined with other technologies, such as
blockchain or machine learning (Al-Hayajneh et al., 2020; Hu et al., 2020; Restuccia et
al., 2018). This raises the need to test and evaluate the performance of SDN on mobile
devices, which are small, low in hardware configuration, and commonly used in IoT
networks, such as Raspberry Pi computers. Gupta et al. (2018) designed a highly versatile
and low-cost SDN switch using a Raspberry Pi computer. Marzuqi et al. (2019) also tested
the applicability of a single-board computer, namely, the Raspberry Pi in the deployment
of a software-defined network.
On the performance issue of SDN controllers, Ali et al. (2018) and Priya and
Radhika (2019) evaluated and compared the performance of POX and Ryu controllers in
many aspects, such as latency, bandwidth, and packet forwarding throughput. The results
showed that the Ryu controller had better performance metrics than POX.
Based on a comprehensive review of the results of related studies, we aim in this
study to evaluate the implementation of SDN with the Mininet network emulator tool in
different environments and with many types of network topologies. In addition, the study
also compares different controllers in the same hardware environment.
3. TESTING AND RESULTS
3.1. Experimental design
Tests were performed to assess Mininet's scalability in implementing network
topologies. The start/stop time of a network topology was calculated as the time from the
start of topology creation, with parameters such as topology type, host number, controller,
etc., until the topology was stopped. The study conducted two tests.
• Test 1: Compare the execution times of topologies on two different hardware
environments (virtualized environment and Raspberry Pi computer) using the
same controller. The Ryu controller is used in this test with the media
parameters described in Table 1.
DALAT UNIVERSITY JOURNAL OF SCIENCE [NATURAL SCIENCES AND TECHNOLOGY]
85
• Test 2: Compare the execution times of topologies on the same Raspberry Pi
environment (Environment 2 of Test 1) with two different controllers, POX
and Ryu.
Table 1. Parameter two hardware environments
Environment Device Configuration
1 Virtual environment - Virtual Oracle VirtualBox 1 Gb RAM runs on Laptop
Intel® Core™ i5-2430M, CPU 2.40 GHz, 4 GB RAM;
- PC Operating system: Ubuntu 14.04.1 64 bit;
- Mininet 2.2.2.
2 Raspberry Pi 3 - Raspberry Pi 3, Cortex-A53 (ARMv8) 64-bit So @
1.4 GHz, 1 GB RAM;
- Ubuntu PC operating system: 14.04.1 64 bit;
- Mininet 2.2.2
Timing was performed with a program written in the Python language. The
topologies used include
• Single topology: A single topology in which a switch is connected to n hosts.
For example, #sudo mn-topo single, 4 (creating a topology with 1 switch
connected to 4 hosts);
• Tree topology: A topology that depends on the depth of the tree and the
number of hosts connected to each switch at the end of the tree (fanout). For
example, #sudo mn-topo tree, depth = 3, fanout = 2 (creating a tree topology
with the depth of 3 such that each switch at the last floor has 4 hosts);
• Linear topology: A linear topology depending on the number of switches and
the number of hosts connected to each switch. Example: #sudo mn-topo
linear, 3 (creating a topology with 3 switches such that each switch is
connected to 1 host).
3.2. Results
3.2.1. Test 1
This section presents the results of measuring and comparing the execution times
of different types of topologies in two hardware environments with the Ryu controller.
Test results are shown in Figure 1 and Table 2 for the single topology, in Figure 2 and
Table 3 for the tree topology, and in Figure 3 and Table 4 for the linear topology.
Do Van Khoa and Tran Ngo Nhu Khanh
86
Figure 1. Comparison of the execution times for a single topology
Table 2. Test results for the single topology
Topology Node (n) Host (n) Switch (n)
Start/Stop Time Virtualized
environment (seconds)
Start/Stop Time
Raspberry (seconds)
Single 3 2 1 0.13 0.31
Single 7 6 1 0.21 0.57
Single 15 14 1 0.41 1.27
Single 31 30 1 0.79 2.34
Single 63 62 1 1.67 4.97
Single 127 126 1 3.33 10.12
Single 255 254 1 11.20 22.66
Single 511 510 1 19.42 51.18
Figure 2. Comparison of the execution times for the tree topology
DALAT UNIVERSITY JOURNAL OF SCIENCE [NATURAL SCIENCES AND TECHNOLOGY]
87
Table 3. Test results for the tree topology
Topology Node (n) Host (n) Switch (n)
Start/Stop Time Virtualized
environment (seconds)
Start/Stop Time
Raspberry (seconds)
Tree 3 2 1 0.13 0.31
Tree 7 4 3 0.30 0.75
Tree 15 8 7 0.69 1.92
Tree 31 16 15 1.29 3.60
Tree 63 32 31 3.23 7.68
Tree 127 64 63 14.83 17.90
Tree 255 128 127 34.83 39.46
Tree 511 256 255 70.97 86.62
Figure 3. Comparison of the execution times for the linear topology
Table 4. Test results for the linear topology
Topology Node (n) Host (n) Switch (n)
Start/Stop Time Virtualized
environment (seconds)
Start/Stop Time
Raspberry (seconds)
Linear 4 2 2 0.22 0.47
Linear 8 4 4 0.36 1.10
Linear 16 8 8 0.70 1.99
Linear 32 16 16 1.52 4.31
Linear 64 32 32 3.46 7.93
Linear 128 64 64 14.39 17.40
Linear 256 128 128 36.42 39.04
Linear 512 256 256 67.43 87.79
Do Van Khoa and Tran Ngo Nhu Khanh
88
3.2.2. Experiment 2
The results of measuring and comparing the execution times for different
topologies on the same Raspberry Pi environment with two POX and Ryu controllers are
shown in the following tables and graphs. The results for the tree topology are shown in
Table 5 and Figure 4, and the results for the linear topology are shown in Table 6 and
Figure 5.
Figure 4. Execution times for the Pox and Ryu controllers with the tree topology
Table 5. Test results for the tree topology in the Raspberry Pi environment
Topology Node (n) Host (n) Switch (n)
Start/Stop Time–Pox
Controller (seconds)
Start/Stop Time–Ryu
Controller (seconds)
Tree 3 2 1 0.31 0.31
Tree 7 4 3 0.72 0.75
Tree 15 8 7 1.57 1.92
Tree 31 16 15 3.60 3.60
Tree 63 32 31 7.31 7.68
Tree 127 64 63 16.91 17.90
Tree 255 128 127 36.99 39.46
Tree 511 256 255 88.50 86.62
DALAT UNIVERSITY JOURNAL OF SCIENCE [NATURAL SCIENCES AND TECHNOLOGY]
89
Figure 5. Execution times for the Pox and Ryu controllers with the linear topology
Table 6. Test results for the linear topology in the Raspberry Pi environment
Topology Node (n) Host (n) Switch (n)
Start/Stop Time–Pox
Controller (seconds)
Start/Stop Time–Ryu
Controller (seconds)
Linear 4 2 2 0.47 0.47
Linear 8 4 4 0.90 1.10
Linear 16 8 8 1.99 1.99
Linear 32 16 16 4.19 4.31
Linear 64 32 32 8.01 7.93
Linear 128 64 64 17.17 17.40
Linear 256 128 128 37.97 39.04
Linear 512 256 256 88.34 87.79
3.3. Comments
According to the results of Test 1, the simulation environment affects the
execution time (start/stop) of the topology. In all three topologies (single, tree, and linear)
execution time on a lower hardware configuration environment (Raspberry Pi) was higher
than in a virtualized environment with a higher hardware configuration. In addition, the
scalability test also showed that the execution time of each topology increased as the
number of nodes increased. For the single topology, the execution time with the least
number of nodes (3 nodes) was 0.13 s in Environment 1 and 0.31 s in Environment 2.
With the maximum number of nodes (511 nodes) in Environments 1 and 2, the execution
Do Van Khoa and Tran Ngo Nhu Khanh
90
times were 19.42 s and 51.18 s, respectively. Similarly, for the tree topology, the
execution time for the least number of nodes in Environments 1 and 2 was 0.13 s and
0.31 s, and with the number of maximum nodes, it was 70.97 s and 86.62 s, respectively.
For the linear topology, the execution times were 0.22 s and 0.47 s with the least number
of nodes (4 nodes), and 67.43 s, and 87.79 s with the highest number of nodes
(512 nodes). The difference in topology execution time for the two media became clearer
as the number of nodes increased, with the most obvious difference between the two
environments being observed in the single network topology.
This result is in agreement with previous studies that found that the simulation
environment affects the time to build topologies (de Oliveira et al., 2014; Keti & Askar,
2015). Nevertheless, the difference of this study is that by testing and comparing the
virtual machine environment and the Raspberry Pi machine, the results showed that the
current basic hardware configurations fully satisfy the simulation software-defined
network with Mininet. Although previous studies evaluated Mininet as an important tool
in SDN research, there were performance limitations for topologies with a large number
of nodes and differences in simulated and real environments.
In Test 2, the difference in execution time for the two controllers was insignificant
for the topologies with the same hardware environment. The POX controller had an
execution time of 0.31 s for the tree topology with the fewest nodes (3 network nodes)
and 88.50 s with the most nodes (511 nodes). The Ryu controller had execution times of
0.31 s and 86.62 s, respectively, for the same topologies and hardware environment. For
the linear topology, the execution times