Emulation of software-defined network using mininet

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.

pdf13 trang | Chia sẻ: thanhle95 | Lượt xem: 461 | Lượt tải: 1download
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
Tài liệu liên quan