High-Performance Routing Emulation Technologies Based on a Cloud Platform

Currently, the emergence of edge computing provides low-latency and high-efficiency computing for the Internet of*ings (IoT). However, new architectures, protocols, and security technologies of edge computing need to be verified and evaluated before use. Since network emulation based on a cloud platform has advantages in scalability and fidelity, it can provide an effective network environment for verifying and evaluating new edge computing technologies. *erefore, we propose a high-performance emulation technology supporting the routing protocol based on a cloud platform. First, we take OpenStack as a basic network environment. To improve the performance and scalability of routing emulation, we then design the routing emulation architecture according to the software-defined network (SDN) and design the cluster scheduling mechanism. Finally, the design of the Open Shortest Path First (OSPF) protocol can support communication with physical routers. *rough extensive experiments, we demonstrate that this technology not only can provide a realistic OSPF protocol but also has obvious advantages in the overhead and performance of routing nodes compared with those of other network emulation technologies. Furthermore, the realization of the controller cluster improves the scalability in the emulation scale.


Introduction
e Internet of ings (IoT) technology is an extension of the Internet and refers to the billions of physical devices around the world that are now connected to the Internet. Because of the arrival of super low-cost computer chips and the development of wireless networks [1], it is possible to turn anything into a part of the IoT, such as wearable Pointof-Care Testing (POCT) systems [2], which provides convenience for immediate diagnostic results. With the rapid growth of the IoT, a large amount of edge data has been explosively generated. Edge computing has emerged out of necessity to process these data [3][4][5]. Edge computing avoids problems of the slowdown in broadband expansion and delays in data transmission between central cloud servers and edge devices. A large amount of edge data can be processed at the edge-layer, which realizes low-latency and high-efficiency data processing.
At present, an increasing number of protocols and architectures for edge computing have been proposed [6][7][8].
erefore, there is an urgent need for a testing platform for edge computing that provides network virtualization and computing realism at a low cost to test and verify these new protocols and architectures. Zeng et al. [9] show that a testing platform for edge computing mainly is composed of two aspects: the network and computing. It also proposes EmuEdge, a hybrid emulator based on Linux netns and Xen for full-stack edge computing emulation. Coutinho et al. [10] present a framework architecture to create virtualized fog environments that help researchers test and evaluate fog applications.
Although the above two methods can provide solutions for evaluating and testing edge computing, they have performance bottlenecks in network virtualization. In [9], the approach uses Linux netns and Xen to provide the basic environment for a testing platform for edge computing. However, the Xen virtualization is not as convenient and efficient as the cloud platform [11]. Coutinho et al. [10] use Mininet [12] to build an emulation network for fog virtualized environments. Compared with the cloud platform, Mininet may yield erroneous results if they inadequately manage the interaction between the emulation environment and the operating system that lies beneath the application and the virtual links [13].
Cloud platforms [14,15] can provide a high-fidelity basic network environment for network emulation. OpenStack has become the standard for cloud platforms because it is opensource, scalable, and flexible [16][17][18].
erefore, network emulation based on OpenStack is a research hotspot. At present, there are two routing emulation technologies based on OpenStack. One is to use the "qrouter" component of OpenStack to realize the routing emulation. Mengdong et al. [19] proposes a high-throughput routing emulation solution based on the "qrouter," but due to the lack of routing protocol design, its application scenarios are limited. Another is to integrate virtualization technologies, such as Kernel-based Virtual Machine (KVM) [20] and Docker [21], with routing software technologies, such as Quagga [22], XORP [23], and Click [24], to realize the routing emulation. e solution adopts a closed router architecture closely coupled with physical resources, operating systems, and network applications.
erefore, each routing node requires independent system space and relies on a virtual machine, which means that these solutions need to occupy a large number of physical resources to deploy a large-scale network emulation, thereby increasing costs. In terms of performance, the communication between virtual machines in OpenStack requires multiple forwarding of Linux-bridge [25] and Open vSwitch (OVS) [26], which leads to the problem of poor link performance of the routing emulation solution.
In this case, to reduce the overhead and improve the performance, this paper combines the software-defined network (SDN) [27] and OpenStack technologies to propose a high-performance routing emulation technology. Open-Stack technology can provide a low-cost and realistic basic network emulation environment. SDN technology can optimize the architecture of this routing emulation technology. e routing node of the optimized architecture is responsible only for processing data packets according to flow rules distributed by the controller. erefore, each routing node does not need an independent system space, which reduces the emulation overhead. In terms of the performance, because the routing node of the optimized architecture is implemented by the OVS bridge, it has high forwarding performance. We design the Open Shortest Path First (OSPF) protocol, which is a dynamic protocol and transmits routing information. In addition, we also design a cluster scheduling mechanism to schedule multiple controllers to provide the control service. e main contributions of this paper are summarized as follows: (1) We propose a high-performance routing emulation architecture. is architecture can effectively reduce emulation overhead and improve emulation performance. In addition, the design of the load balancing of links can improve the throughput in the situation of congestion. (2) We realize the OSPF protocol for this routing emulation technology. e realization of the OSPF protocol not only enables the routing node to communicate with the physical router but can also be used to analyse the OSPF attack. (3) We design the controller cluster to strengthen the ability of control. e controller cluster ensures that all routing nodes can be controlled by multiple controllers simultaneously, which significantly improves the scalability in the emulation scale. e rest of the paper is organized as follows. Section 2 describes some related work about network emulation. In Section 3, we introduce the architecture, routing function, and OSPF function. We introduce the load balancing of links in Section 4 and the load balancing of controllers in Section 5. Section 6 evaluates its function and performance. We conclude the paper in Section 7.

Related Work
Network emulation is one aspect of a testing platform for edge computing. e related routing emulation solutions are as follows.
Zeng et al. [9] present a hybrid emulator based on Linux netns and Xen for full-stack edge computing emulation, which is called EmuEdge. EmuEdge adopts netns for network-bounded node virtualization and provides full-system virtualization with Xen to combine the emulation of both the computation and network plane in an edge computing platform. Coutinho et al. [10] present a framework architecture to create fog testbeds in virtualized environments, and it uses Mininet to build an emulation network. Because the two solutions do not combine the cloud platform, they lack convenience, scalability, and scale. NS3 [28], OPNET [29], and Glomosim [30] are widely adopted to simulate the network environment. ough these solutions can provide reproducible and convenient network simulation, they have defects in fidelity and ignore some essential details when acting. erefore, these network simulators cannot offer realistic network results [31]. e cloud platform can provide an excellent essential environment for network emulation. In [19], an emulation technology is proposed based on a centralized routing engine and distributed router deployment. e technology uses the "qrouter" of Neutron [32] to construct a complex emulation network. However, this solution does not support the standard dynamic routing protocol, which leads to the inability of connected physical routers to learn routings from each other through the routing protocol and thus limits its application. Routing emulation software provides essential support for the routing emulation solutions based on cloud computing and virtualization technology. In [33], Quagga is deployed on a virtual machine, providing various routing function emulations. Huang et al. [34] use Linux Containers (LXC) [35] to provide a running environment for virtual routers and use the Xtensible Open Router Platform (XORP) or Click to build a routing node. However, the routing emulation solutions in [33,34] build routing nodes by deploying routing emulation software on virtual machines, which leads to defects in overhead and performance of routing nodes in the routing emulation network.

Routing Emulation Design
3.1. Architecture Design. OpenStack, as the mainstream cloud platform technology, can provide outstanding operation and a basic network environment for network emulation with its high scalability, high fidelity, and low cost [36]. SDN technology optimizes the routing emulation architecture by separating the forwarding layer and the control layer, effectively reducing the emulation overhead and improving the emulation performance [27]. erefore, we propose a high-performance routing emulation architecture based on OpenStack and SDN technology. e architecture consists of a 5-layer structure of the interconnection layer, data forwarding layer, control layer, decision layer, and cluster scheduling layer.
is multilayer structure can refine tasks and improve the scalability and reliability of the system [37]. e interconnection layer is the bottom layer of the architecture and is responsible for interconnecting with the OpenStack virtual network. e data forwarding layer is responsible for processing the data packets according to the flow rules. e control layer and decision layer are a vital part of the architecture.
e control layer processes the information submitted by the data forwarding layer according to the finegrained requirements specified by applications of the decision layer and distributes flow rules to each routing node. e decision layer provides various functions for the system through various applications, including monitoring, routing, and OSPF. e cluster scheduling layer relieves the pressure of the controller by scheduling multiple controllers to provide control services at the same time and improves the scalability of the emulation scale. Figure 1 shows the architecture of routing emulation technology. e detailed introduction is as follows.
(1)  [39] facilitates the study and research of researchers. erefore, we adopt Ryu as the controller of the control layer. Ryu is responsible for processing the information submitted by the data forwarding layer according to the fine-grained requirements specified by applications of the decision layer and distributing flow rules to each routing node. (4) Decision layer: the decision layer is crucial in the routing emulation architecture and consists of a network awareness app, network monitoring app, routing app, OSPF app, and a database. Each app performs its duties to achieve different functions. e network awareness app obtains the topology information of the emulation network and writes it into the database. e network monitoring app monitors the traffic and flow rules information of each routing node in real time and writes it into the database. e routing app is responsible for calculating all forwarding paths in the emulation network and generating flow rules based on these paths. e OSPF app is responsible for providing standard OSPF dynamic routing protocol [40] and supporting routing exchanges with physical routers. e network awareness app and routing app work together to provide the routing function, which will be described in Section 3.2. In Section 3.3, we will introduce how to realize the OSPF protocol with the OSPF app. Section 4 will introduce the load balancing of links realized by the network awareness app, network monitoring app, and routing app. (5) Controller cluster: the control layer and decision layer compose the routing controller, and a group of routing controllers composes the controller cluster. Each routing controller will monitor its load information (including the number of connected nodes and the number of managed IP addresses) and submit it to the cluster scheduling layer through the message queue of RabbitMQ [41]. (6) Cluster scheduling layer: according to the load information of all routing controllers, the cluster scheduling centre can provide the load balancing of controllers, which will be introduced in Section 5.

Realization of High-Performance Routing Function.
e routing function is the primary function of the routing node, which allows different networks to communicate with each other. erefore, we realize the routing function through the network awareness app and routing app of the decision layer. e workflow of each app is shown in Figure 2.
According to Figure 2, the network awareness app is responsible for drawing the topology of the whole network, and the routing app is responsible for generating and distributing flow rules. First, the network awareness app obtains connection information by polling each routing node and draws the topology of the whole network based on this Security and Communication Networks 3 information. en, the routing app parses the data packet to obtain the information of the source and destination node and calculates the optimal path with the Dijkstra algorithm [42] between the two nodes according to the topology. Finally, the routing app generates flow rules based on the path and distributes them to the routing nodes in the path. Figure 3 shows the process of routing and forwarding. As seen from Figure 3, when data packets arrive at the interconnection layer, they will be submitted to the data forwarding layer to match the flow rules (I in Figure 3). At the data forwarding layer, data packets will be matched to the flow rules based on the destination network, protocol type, and other fields. If the packets fail to match, the data forwarding layer will submit the header information of the packet to the control layer (II in Figure 3). en, the control layer calculates the optimal path and generates flow rules with the network awareness app and routing app of the decision layer (III in Figure 3). Finally, the control layer distributes flow rules to routing nodes (IV in Figure 3). If the packets succeed to match, the TTL of the packets will be reduced by 1 to prevent the packets from generating loops in the network. e source media access control (MAC) of packets is modified to the MAC of the exit port. e destination MAC is modified to the MAC of the next hop.
en, the packets are forwarded to the exit port (V in Figure 3).

Realization of the OSPF Protocol.
To support the construction of a complex emulation network with other emulation routers or physical routers through the OSPF protocol, we design the OSPF app at the decision layer. e OSPF protocol relies on five different types of messages to establish an OSPF neighbour adjacency and exchange routing information. e messages include Hello messages, Database Descriptor (DBD) messages, Link-State Request (LSR) messages, Link-State Update (LSU) messages, and Link-State Acknowledgement (LSAck) messages [40]. erefore, the OSPF app also designs these five messages. rough neighbour discovery, database information exchange, routing calculation, and the flow rule distribution of the four steps, the app uses these messages to establish an OSPF neighbour adjacency and exchange routing information. e workflow of the OSPF app is shown in Figure 4. e OSPF app calls different modules according to different message types. According to Figure 4, after the app parses the data packet, it will determine the type of the message. If it is a Hello message, the app will call the Hello module to respond to the message. If it is a DBD message, the app first calls the DBD module to support the exchange of link status information and then calls the LSR module to request detailed link status information. If it is an LSU message, the app will call the Daemon module to store the link status information and call the LSAck module to reply to the message. If it is an LSAck message, the app will call the Daemon module to record the message. Figure 5 shows the establishment process of OSPF.
When the routing node receives OSPF packets, the node will submit the packets to the routing controller for processing and reply to the neighbour router with the OSPF packets issued by the routing controller (I in Figure 5). When the routing controller receives OSPF packets, the OSPF app will construct corresponding reply packets according to the type of the OSPF message and issue them to the routing node (II in Figure 5). e specific process is as follows:    [43] and stores them in the database (III in Figure 5). (4) Flow rules distribution: after traversing the OSPF routes in the database, each route is resolved into forwarding flow table rules and distributed to routing nodes (IV in Figure 5).
rough the above four steps, the routing node establishes an OSPF neighbour adjacency and exchanges routing information with the physical router.

Realization of Load Balancing of Links
is paper proposes a load balancing of links mechanism to ensure that the emulation network can still obtain a highthroughput transmission path in the situation of congestion. e mechanism realizes load balancing of links through the network awareness app, network monitoring app, and routing app. e workflow of each app is shown in Figure 6.
According to Figure 6, the network awareness app is responsible for providing the topology of the emulation network. e network monitoring app is responsible for monitoring the load information of the emulation network (including the used bandwidth and the number of flow rules of a routing node) and calculating the load value of each path according to the topology and the evaluation model of the link. e routing app is responsible for calculating the optimal path according to the congestion avoidance algorithm based on the topology and the load value of each path. In Section 4.1, we will introduce the evaluation model of the link. e congestion avoidance algorithm will be introduced in Section 4.2.

Evaluation Model of the Link.
In the process of network communication, bandwidth is the key factor affecting the transmission quality. e number of flow rules maintained by each routing node can reflect the load of the routing node. erefore, we use the bandwidth and number of flow rules as two parameters of the model. e bandwidth directly affects the speed of data transmission on the link. e ratio of used bandwidth can effectively reflect the busy degree of the link. In general, selecting the link with lower used bandwidth can yield higher-quality data transmission. e bandwidth used in the link can be obtained by the network monitoring app polling each routing node with the OpenFlow protocol [44]. We use (1) and (2) to obtain the bandwidth load value B (i,j) of the link (i,j) (i, j represent routing nodes i, j, and they are two adjacent nodes), where bandwidth i and bandwidth j , respectively, represent the port bandwidth of the nodes i and j, BW (i,j) represents the bandwidth of link (i,j) (since one link has a node on the left and right and the port bandwidth of each node is assumed to be different, we need to obtain the minimum of them as the bandwidth of the link), BW actual(i,j) represents the bandwidth actually used of the link (i,j), BW (x,y) represents the bandwidth of link (x, y) (x, y represent two adjacent nodes), and {nodes} is the set of all routing nodes: Another parameter is the number of flow rules. e more the flow rules are maintained by the routing node, the more the time packets spend matching them. We use (3) and (4) to obtain the flow rule load value F (i,j) of the link (i, j) (i, j represent routing nodes i, j, and they are two adjacent nodes), where f i and f j represent the number of flow rules maintained by the routing nodes i, j (one link has a node on the left and right, so we take the average value of both nodes as fn (i,j) for convenience of calculation), fn x represents the number of flow rules maintained by the routing node x, and {nodes} is the set of all routing nodes: We use (5) to obtain the load value of the link (i, j) named as L (i,j) by weighting the sum of B (i,j) and F (i,j) , where the weights are k 1 and k 2 :

Congestion Avoidance Algorithm.
In this section, we will introduce the congestion avoidance algorithm. First, we obtain the topology of the emulation network through the network awareness app and load values (calculated by (5)) through the network monitoring app. We then use them as the input parameters of the congestion avoidance algorithm to calculate the optimal path in the situation of congestion. e pseudocode of the algorithm flow is shown in Algorithm 1.

Cluster Scheduling Mechanism
is paper adopts a routing emulation architecture that separates the forwarding layer and the control layer. e routing controller undertakes most of the work, including network awareness, network monitoring, and OSPF. erefore, the pressure on the routing controller will increase as the number of routing nodes controlled by it increases. To solve this problem, this paper adopts the idea of distributed control and proposes a cluster scheduling mechanism.
e mechanism balances multiple routing controllers to control more routing nodes simultaneously, which increases the scalability of the emulation network. First, Section 5.1 describes how to realize the cluster scheduling mechanism. en, we propose the evaluation model of the routing controller in Section 5.2 and propose the scheduling algorithm in Section 5.3.

Cluster Scheduling Centre.
e cluster scheduling centre can manage multiple routing controllers simultaneously and evenly distributes the routing nodes in the emulation network to routing controllers for management. (2) dict ← Dijkstra(nodes, weights, s); (3) //nodes and s are used to initialize the sets S and U in the Dijkstra algorithm, S is the initial set of vertices (the initial set is {s}), and U is the set of vertices to be selected. Weights are used to calculate the weight between two nodes (if there is no edge between the two nodes, the weight is infinite). e set of shortest paths from node s to all other nodes can be obtained by the Dijkstra algorithm. (4) If d not in dict en (5) result ← False; (6) Else (7) path ← dict[d]; (8) //Get the shortest path from node s to node d. (9) Traverse all nodes in path and distribute flow rules; (10) End if (11) Return result; ALGORITHM 1: Congestion avoidance algorithm.

Security and Communication Networks 7
As shown in Figure 7, routing controllers submit the load information (I in Figures 7 and 8) to the cluster scheduling centre through RabbitMq. e load information includes the number of routing nodes controlled by the controller, the number of IP addresses managed by the controller (because the routing node composed of the OVS bridge cannot set the IP address, the controller needs to manage the IP address of each access routing node), and the traffic of the southbound (it is the interactive traffic between the routing controller and routing nodes). e terminal is the entry point for creating a routing node. Whenever a routing node needs to be created, the terminal will send a request (II in Figures 7  and 8) to the cluster scheduling centre through API to obtain the idlest controller.
It can be seen from Figure 8 that when the load information is received, the centre will calculate the idlest controller according to the scheduling algorithm. In addition, it will return this controller information when receiving the request information.

Evaluation Model of the Routing Controller.
We propose an evaluation model of the routing controller and calculate the load situation of each controller according to the load information submitted by the routing controller. e routing controller needs to provide the Transmission Control Protocol/IP (TCP/IP) stack [45] and routing calculation function to connect routing nodes. e more routing nodes are connected to the controller, the busier the controller is. erefore, we define the value RM i, which represents the load situation of the ith controller on the number of routing nodes. e formula is shown as (6), where controller i represents the number of routing nodes connected to the ith controller and N represents that there are N controllers: In the emulation network, the IP address of routing nodes is managed by the routing controller. e controller is responsible for answering ARP, ICMP, TCP, and UDP packets of these IP addresses. When the number of IP addresses is too large, it will reduce the speed of packet processing. erefore, we define the value AM i that represents the load situation of the ith controller on the number of IP addresses. e formula is shown as (7), where address i represents the number of IP addresses managed by the ith controller and N represents that there are N controllers: When the southbound traffic is too heavy, the communication between controller and routing nodes will be blocked. erefore, we define the value SF i that represents the load situation of the ith controller on the southbound traffic. e formulas are shown as (8) and (9), where ST i represents the southbound traffic of the ith controller, and it is calculated from the packet size passed within 30 seconds (packet t represents the packet size at t). SF max represents the maximum size of the specified southbound traffic:

Scheduling Algorithm.
is section elaborates on a scheduling algorithm. Combined with the evaluation model in the previous section, we can calculate the current idlest controller. e pseudocode of the algorithm flow is shown in Algorithm 2.
In the process of Algorithm 2, we calculate the busyness of each controller by using (10), where busyness � {id 1 : value(id 1 ), . . ., id i : value(id i ), . . ., id n : value(id n )}: Finally, we traverse busyness to find the least busy controller and return it.

Evaluation
In this section, we verify and evaluate the routing emulation technology of this paper. First, we verify the routing and forwarding function of routing nodes and OSPF function through experiments in Section 6.2. en, we compare the routing emulation technology in this paper (named as highperformance technology), in [33,34] (named as virtualization technology), and in [19] (named as high-throughput technology). Section 6.3 compares the cost of the three routing emulation technologies, and Section 6.4 compares the performance. Finally, in Sections 6.5 and 6.6, we, respectively, evaluated the effects of load balancing of links and load balancing of controllers, respectively.

Experimental Environment.
In this paper, we use four Dell servers to build the OpenStack (version Queens) and use it as the basic environment of the experiment. e environment is shown in Figure 9, and the specifications of the servers are shown in Table 1.
e operating system of all the nodes is Ubuntu 16.04. We deploy the high-performance technology on the Com-pute1 node and deploy the virtualization technology or highthroughput technology on the Compute2 node for comparisons with our high-performance technology separately. R6 and R7 are Cisco's physical routers.

Verification of Routing Function Emulation.
We build the emulation network, as shown in Figure 10, on the Compute1 node.
In Figure 10, VM1, VM2, and VM3, which represent clients, have IP addresses of 192.168.1.3/24, 192.168.6.3/24, and 10.1.9.3/24, respectively. One net represents a virtual network, and the details are shown in Table 2. e emulation network is divided into a high-performance technology network and a physical network. e physical network is composed of two Cisco physical routers and connects to the high-performance technology network through the net7 virtual network. e two networks use OSPF to exchange routing.
We take VM1 and VM2 as an example and use the traceroute tool [46] to test whether they can communicate with each other through forwarding routing nodes and whether the path the packet passes through is correct.
From Figure 11, we know that VM1 can communicate with VM2 and the path is correct. In the high-performance technology network, any two nodes can also communicate through the forwarding routing nodes to build an interconnected routing emulation network on OpenStack. (17) for con in controllers do (18) A ← nodes_num[con]; (19) //Get the number of routing nodes controlled by the controller con from nodes_num. (20) Compute the RM according to A and total_nodes based on formula (6); (21) B ← addresses_num[con]; (22) //Get the number of IP addresses managed by the controller con from addresses_num. (23) Compute the AM according to B and total_addresses based on the formula (7); (24) C ← southbound_flow[con]; (25) //Get the size of the southbound traffic of the controller con from southbound_flow. (26) Compute the SF according to C based on the formulas (8) and (9); (27) Use formula (10) to obtain busyness according to RM, AM, and SF; (28) end for (29)

Security and Communication Networks
We take VM1 and VM3 as an example and use the traceroute tool to test whether they can communicate over two kinds of networks and whether the path the packet passes through is correct.
From Figure 12, we know VM1 can communicate with VM3, and the path is correct. It can be proved that the emulation network constructed by the high-performance technology can exchange routings with the physical network by OSPF. Cluster scheduling centre … Figure 9: Experimental environment.  In this section, we also verify whether the routing emulation technology in this paper supports OSPF protocol attack analysis. e adjacency attack [47] is a typical OSPF protocol attack method. We use VM1 and the routing node Br-R3 as an example to simulate this attack method. e adjacency attack tampered with the routing table by simulating the virtual neighbour node of the OSPF router. Figure 13 shows that VM1 is simulated as the adjacent node of BR-R3 (192.168.3.100) and successfully establishes an OSPF neighbour with BR-R3 by sending OSPF messages, which verifies that the routing emulation technology in this paper supports OSPF protocol attack analysis.

Comparisons of Overhead in Routing Emulation.
e overhead of the routing emulation technology determines the size of the network that can be emulated in the same physical resource. In this section, we compare the CPU and memory consumption of the virtualization technology, high-throughput technology, and high-performance technology. Tables 3 and 4 show the results of comparing how much CPU and memory are occupied when routing nodes are forwarding packets. In terms of CPU, compared with the virtualization technology, high-performance technology and high-throughput technology have a significant advantage.
When there are 10 nodes, the virtualization technology takes up 45.6% of the CPU, which is 50.6 times of the high-performance technology. In terms of memory, high-performance technology has a significant advantage. When there are 10 nodes, the high-performance technology takes up 78 MB of the memory, which is 97.9% less than the virtualization technology and 92.3% less than the high-throughput technology. According to the above comparison results, using high-performance technology to build an emulation network can effectively reduce the costs.

Comparisons of Performance in Routing Emulation.
e throughput, delay, and packet loss rate determine the performance of a routing emulation system. In this section, we compare the virtualization technology, high-throughput technology, and high-performance technology.
To more accurately verify the advantages of the highperformance technology on the performance of the routing node, two experimental scenarios are designed: the multihop situation and concurrent situation. We design a linear topology with 10 routing nodes, as shown in Figure 14, and design a concurrent topology with 5 clients, as shown in Figure 15. We use the iPerf3 [48] tool to test the throughput and packet loss rate and use the Ping tool to test [49] the delay.   Security and Communication Networks Figure 16 shows the comparison of the throughput, delay, and packet loss rate of the three routing emulation technologies in the multihop situation.
In terms of the throughput, in the 2-hop situation, the throughput of the virtualization technology is 11.8 Gbit/s and that of the high-throughput technology is 14.6 Gbit/s. However, the throughput of the high-performance technology is 17.2 Gbit/s, which is 1.46 times that of the virtualization technology and 1.18 times that of the high-throughput technology. With the increase in the number of hops, the high-performance technology still has advantages. In the 10hop situation, the throughput of the high-performance technology is 2.49 times of the virtualization technology and 1.24 times that of the high-throughput technology.
In terms of the delay time, in the 2-hop situation, the delay time of the virtualization technology is 1.071 ms and that of the high-throughput technology is 0.73 ms. However, the delay time of the high-performance technology is 0.456 ms, which is reduced by 57% compared to the virtualization technology and reduced by 38% compared to the high-throughput technology. With the increase in the number of hops, the delay time of the high-throughput technology and high-performance technology appears to be stable, but that of the virtualization technology increases linearly.
In terms of the packet loss rate, the high-throughput technology and high-performance technology tend towards 0, and with the increase in the number of hops, the packet loss rate is still stable at 0. However, in the 2-hop situation, the packet loss rate of the virtualization technology is 10%, and it will increase as the number of hops increases.    erefore, in the multihop situation, the high-performance technology performs well in terms of the throughput, delay, and packet loss rate. Figure 17 shows the comparison of the throughput, delay, and packet loss rate of the three routing emulation technologies in the concurrent situation.
In terms of the throughput, with the increase in the number of concurrencies, the throughput of the highthroughput technology and high-performance technology shows a linear growth, while that of the virtualization technology shows little change. When the number of concurrencies is 5, the throughput of the virtualization technology is 11.92 Gbit/s and that of the high-throughput technology is 39.7 Gbit/s. e throughput of the high-performance technology is 53.5 Gbit/s, which is 4.49 times that of the virtualization technology and 1.35 times that of the high-throughput technology.
In terms of the delay time, the three technologies are stable. e virtualization technology is stable at 0.9 ms, the high-throughput technology is stable at 0.7 ms, and the highperformance technology is stable at 0.46 ms. e delay time of the high-performance technology is reduced by 49% compared to that of the virtualization technology and reduced by 34% compared to that of the high-throughput technology.
In terms of the packet loss rate, high-throughput technology is stable at 0.4%. e high-performance technology will increase slowly as the number of concurrencies increases, but the virtualization technology always has a high packet loss rate. erefore, in the concurrent situation, high-performance technology performs well in terms of throughput and delay. However, because the high-throughput technology uses namespace [50], it can process packets more stably in the concurrent situation, and it has a lower packet loss rate than high-performance technology.
In conclusion, compared with the virtualization technology and high-throughput technology, high-performance technology has obvious performance advantages in multihop and concurrent situations.

Comparisons in Situations of Link Congestion.
In the same environment, we compare the virtualization technology, high-throughput technology, and high-performance technology (with and without the load balancing of links). We design a testing topology, as shown in Figure 18. When C1 transmits many packets to C3 to block the communication link, we test the communication path and throughput of C2 and C4. e results are shown in Table 5 and Figure 19.
From Table 5 and Figure 19, we can see that, compared with the virtualization technology, high-throughput technology, and high-performance technology without the load balancing of links, the high-performance technology with the load balancing of links can select the relatively idle link as the forwarding path in the situation of congestion. Because the congestion link is selected for forwarding paths, the throughput of the virtualization technology is almost 0 Gbit/ s, that of the high-throughput technology is 4.35 Gbit/s, and that of the high-performance technology without the load balancing of links is 9.8 Gbit/s. However, the throughput of the high-performance technology with the load balancing of links is 12.3 Gbit/s. erefore, high-performance technology can provide a high-quality communication path in the situation of congestion through the load balancing of links.

Verification of Advantages of the Controller Cluster.
In this section, we compare the average time for the single controller and the controller cluster (it contains three controllers) to process all packets. e shorter the time is, the more the routing nodes that can be controlled. We design a scenario as Figure 20 and use a single controller or a controller cluster to control all routing nodes.
In Figure 20, all the clients send packets to the controller of the emulation network, so the controller needs to process these packets and return them. Each client calculates the 16      round-trip delay of the packets and obtains the average time T avg by In (11), packet_delay i represents the round-trip time of the packet sent by the ith client, and link_delay i represents the link delay time from the ith client to the controller. e time for the controller to process the packet of the ith client can be obtained by subtracting link_delay i from pack-et_delay i . In (12), N represents the number of clients. Figure 21 shows the comparison of the value T avg between a single controller and a controller cluster in the case of different numbers of concurrent clients.
As the number of concurrent clients increases, the time needed for the single controller to process packets increases dramatically. However, the time needed for the controller cluster to process packets increases slowly. erefore, the controller cluster can control more routing nodes and improve the scalability of the emulation scale.

Conclusions
is paper proposes a high-performance routing emulation technology based on a cloud platform that provides a network environment for edge computing to verify and evaluate new architecture, protocol, and security technologies. First, we combine OpenStack and SDN technology to propose a high-performance routing emulation architecture. en, we implement the routing function, OSPF protocol, and load balancing of links through apps of the decision layer. Finally, we propose a distributed control method and improve the scalability of the emulation scale with the controller cluster. Experiments show that, compared with other routing emulation technologies, this technology achieves less overhead, higher performance, and a realistic OSPF protocol. e controller cluster can also control more routing nodes than the single controller.
However, this paper studies only how to support the OSPF protocol, and other dynamic routing protocols (such as the Routing Information Protocol (RIP) and the Border Gateway Protocol (BGP)) need to be studied further. In addition, how to realize the hot backup of the controller will be the direction of the follow-up research.

Data Availability
e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper. Security and Communication Networks 15