Performance Comparison Of SDN Controllers In Different Network Topologies

doi:10.21203/rs.3.rs-4826985/v1

Download PDF

Research Article

Performance Comparison Of SDN Controllers In Different Network Topologies

https://doi.org/10.21203/rs.3.rs-4826985/v1

This work is licensed under a CC BY 4.0 License

Version 1

posted

You are reading this latest preprint version

The development of Software-Defined Networking (SDN) has completely changed the way networks are optimized and controlled. Still, network topologies and SDN controller performance are important factors that need to be thoroughly examined. In this study the evaluation of four well-known SDN controllers: Ryu, Floodlight, OpenDayLight, and ONOS across five different network topologies: Single, Linear, Tree, Torus, and Custom are examined. We conducted extensive experiments using Mininet and Iperf to measure latency, jitter, packet loss, and throughput. It is clear from the results that Ryu performs better than the others, and Linear topology is the most effective. Notably, the best performance is obtained when Ryu and Linear topology work together. Our results suggest that Ryu and linear topology are the best combination for high-performance networks, which has significant implications for the design and deployment of SDN networks. On the other hand, other controllers and topologies are more suitable for certain use cases, such as large networks, research and development, small networks, and custom applications. this study provides invaluable information for researchers, practitioners, and network administrators looking to maximize SDN network performance and realize its full potential.

Systems and Networking

SDN

RYU

Floodlight

OpenDayLight

ONOS

Topologies

The Internet has become significantly larger than anyone could have predicted given its rapid development. However, due to the limitations of technology and network communication protocols, the creation of the traditional Internet is becoming increasingly difficult. In addition, current and future network services and applications are becoming increasingly advanced. Therefore, solving the problems of the current traditional network is essential. Traditional networks mostly consist of switches, routers, and other network hardware, which causes many problems for network operators [1]. At the same time, Internet users have higher expectations for the quality of Internet services due to the increased availability of Internet services. For example, the field of autonomous driving requires a low-latency network to ensure driver safety. Many different transmission services can be transmitted smoothly over a high-bandwidth network. It is proposed to solve the following problems through an innovative network design called SDN [1].

SDN breaks away from traditional network design, separates the control plane and data plane of the network, and integrates an open programming interface to meet various network needs. The term “network infrastructure layer” also refers to the data layer that represents network facilities in SDN design [2]. At the control level, there must be a specific protocol to regulate and monitor the communication interface between different network devices because the controller must interact with them. The SDN control data plane interface is the means through which the control plane and data plane communicate in SDN. Currently, the OpenFlow protocol is the most widely used [3]. The control layer is an essential part of SDN design. The performance of SDN architecture is mainly determined by the performance of the controller. Therefore, there are over thirty different types of controllers that meet different needs. Since each controller has unique advantages and functions, the application scenarios must be considered when selecting a controller [4].

This paper covers the performance comparison of four well-known SDN controllers: Ryu [5], Floodlight [6], OpenDayLight (ODL) [7], and ONOS [8]. Ryu was chosen because a performance evaluation study [5] showed that it outperforms other Python-based controllers. Java-based Floodlight was selected because Floodlight has been proven to have better performance and scalability than Python-based controllers [9]. OpenDayLight (ODL) was selected for its scalability and reliability in large networks, ODL controller performs better than ONOS in terms of throughput, burst rate, Round Trip Time (RTT), and bandwidth, as evaluated in a study on SDN controller scalability [10]. ONOS was selected for its flexibility and high-performance latency, throughput, and scalability, as evaluated in a study of ONOS [11]. The purpose of the research is to find out which controller performs better in different network scenarios.

This study compares four commonly used network performance metrics: throughput, jitter, latency, and packet loss across many topologies including single, linear, tree, torus, and custom topologies. Iperf was used to measure the throughput, jitter, and packet loss of the network. Round Trip Time (RTT) was used to measure latency. Iperf was used to measure the throughput, jitter, and packet loss of the network, and Round Trip Time (RTT) was used to measure latency.

The paper is further structured as follows: Section II discusses the previous work on the comparison of SDN controllers. Section III highlights motivation. Section IV describes the comparison of SDN controllers: RYU, Floodlight, OpenDayLight, and ONOS. Section V presents implementation. Section VI discusses the Result Analysis. Section VII Discussion. Lastly, Section VIII concludes the paper.

The performance analysis of four controllers - POX, Ryu, ONOS, and OpenDaylight - is presented in [12]. In their setup, they compared the TCP bandwidth in switch and hub mode of all listed controllers. They found that the bandwidth in switch mode, in Gbps, is significantly larger than the bandwidth in hub mode, which is measured in Mbps and Kbps. They found ONOS to be the best controller among the mentioned controllers. Working with RTT, they found that ONOS had the fastest convergence time. In their conclusion, they said it depends on the needs and circumstances of the networks, without identifying any particular controller as good or bad. Additionally, they recommended adding other software-defined networking technologies such as Floodlight and Trema to improve the evaluation process.

The study [13] examines the parameters of two popular SDN controllers, Pox and Floodlight. Floodlight is a better option for high-performance networking applications because it achieves higher transfer rates and outperforms Pox in data throughput.

The functionality of five SDN controllers – Ryu, POX, Nox, Floodlight, and Beacon – is compared in the study [14]. They measured throughput, latency, and controller performance using Cbench using “responses per second.” Based on all these factors, Beacon performed best, while Ryu was considered competitive due to its active developer community. They experimented with different node and thread counts and concluded that Beacon performed the best. They experimented with different numbers of knots and threads before finding that Beacon performed the best. The topology remains unchanged except for the switch numbers. Now the topology needs to be changed.

The Openflow protocol is used in the study [15] to compare two emulators, Mininet and EstiNet. The experimental results are determined by comparing the average running times of the two simulators. The results of the experiment showed that although Mininet would provide more irregular data, EstiNet could work more efficiently because it would take more time and offer greater flexibility.

In study [16] evaluated the performance of the Mininet reference controller based on four parameters: throughput, round-trip time, packet transfer rate, and bandwidth utilization in three topologies: single, linear, and tree topology. They found that the reference controller performed the best of all three. The reason for this is that all OpenFlow entries are now contained in a single switch. You didn't compare different topologies on different controllers.

Paper [17] conducts a series of experiments to verify the link aggregation capability of two different SDN controllers, Ryu and OpenDayLight, and compare the throughput and response time of the two controllers to test the compatibility between SDN and the existing network facilities to solve. The results of the final test show that OpenDayLight responds faster than the other controllers, but their throughput is the same.

In paper [18] conducted a performance analysis of four controllers: Ryu, Floodlight, ONOS, and OpenDaylight, based on two parameters: throughput and latency. They used Cbench to carry out the test. They changed the number of switches in one scenario and the number of MACs in another to perform the test in their real configuration. Ryu is found to outperform ONOS in terms of lowest latency and ONOS in terms of throughput. However, they did not evaluate topology changes.

Study [19] compares the performance of POX and Ryu SDN controllers under various network topologies, including Single, Linear, Tree, Dumbbell, Data Center Networks (DCN), and SDN-SAT. Experimental results show that Ryu outperforms POX in terms of TCP throughput and latency across all topologies.

Traditional networks face challenges from the Internet and increasing network complexity. SDN networks provide a way to separate the data plane and the control plane. However, a comprehensive review of the performance of SDN controllers and topologies is required.

Despite their diversity, the performance evaluation of SDN controllers has not yet been sufficiently studied. Previous studies focus on specific controllers or topologies and neglect comprehensive comparisons. The design and deployment of high-performance SDN networks suffer from this knowledge gap.

This research examines the performance of five different network topologies (Single, Linear, Tree, Torus, and Custom) using four well-known SDN controllers: Ryu, Floodlight, OpenDayLight, and ONOS. Performance metrics include throughput, packet loss, jitter, and latency. The study aims to identify optimal controller and topology combinations for specific network scenarios and thus optimize SDN network performance. The results will enable network administrators, researchers, and practitioners to make informed decisions in the design and implementation of SDN networks.

A. RYU

The RYU controller is an open-source SDN controller [20]. Designed and developed by NTT company in Japan, Ryu controller is an open-source SDN controller that provides multiple Python interfaces that allow users to create their controllers. The Python programming language is used for implementation. The currently used Ryu Controller version supports deployment apps on OpenStack as well as all OpenFlow versions before Openflow 1.5 [20]. Ryu uses the latest version of the open-source protocol under the Apache license to build residual topologies, standard switches, and other applications. Ryu is a component-based software definition network framework that gives controller users the ability to build network control and management applications based on their own requirements by providing software components with well-defined APIs. Ryu controllers support a range of network device management protocols including Openflow, Netconf, OF-config and others.

B. Floodlight

Floodlights are more than just OpenFlow controllers, but also a group of programs that are installed on the Floodlight controller. The controller can perform both general control and Openflow network query functions. The top application meets multiple network requirements. In general, Floodlight implements most applications; It also has a web interface and debugging server, communicates with the controller and switch via the OpenFlow protocol, discovers and displays network events and states (device, topology, and flow), manages the Floodlight module and shares resources ( memory, thread, and test).

C. OpenDayLight

OpenDayLight (ODL) is a Java-based model-driven controller that uses YANG as a modeling language for various aspects of the system and applications. It serves as a base platform for other OpenDayLight applications [22]. The ODL Controller exposes open northbound APIs that applications use to collect information about the network, run algorithms to perform analysis, and then use the ODL Controller to create new rules across the network. Karaf is an OSGI-based application container that simplifies the operational aspects of packaging and installing applications. YANG is a data modeling language used to model configuration and state data manipulated by applications, remote procedure calls, and notifications. The Model-Driven Service Adaptation Layer (MD-SAL) is a message bus-inspired extensible middleware component that provides messaging and data storage capabilities based on data and interface models defined by application developers. The MD-SAL uses YANG as a modeling language for both interface and data definitions and provides a messaging and data-centric runtime for such services based on YANG modeling [22].

D. ONOS

Open Network Operating System (ONOS) is a core element of software-defined networking (SDN) [21]. Its distributed architecture enhances scalability and fault tolerance. this architecture spreads control over several nodes, and it offers a more thorough understanding of network management [22]. ONOS is known for its effective latency management, which is an essential part of SDN controller performance.

Fig. 1. Feature Comparison of RYU, Floodlight, OpenDayLight, and ONOS Controllers [18]

A. Emulation Environment

The experimental setup consisted of a machine with the following specifications:

• Operating System: Ubuntu v22.04.4 LTS (64-bit)

• Processor: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.6GHz (2 processors)

• RAM: 32 GB

This machine was used to run Mininet [23] and the SDN controllers, providing a robust environment for evaluating the performance of the controllers. The hardware specifications ensured sufficient resources for running multiple virtual networks and controllers simultaneously, allowing for accurate and reliable results.

B. Topologies

The physical connections and configurations of network nodes and devices are represented by the topology. Five topologies were implemented in the emulation environment: single, linear, tree, torus, and custom. The number of switches and hosts linked in various topologies is given in Table 1.

TABLE I. Numbers of Hosts and Switches are connected in different topologies

Topology	Hosts	Switch
Single	117	1
Torus	25	25
Linear	123	123
Tree	64	21
Custom	44	11

a) Single Topology: A centralized network architecture, known as a single topology, uses a single switch as the connection point for each host. In this experiment, single topology is created with 1 switch and 117 hosts. Where all hosts are connected with one switch. Single topology is shown in Fig. 2.

Fig. 2. Single topology generated by floodlight controller

b) Linear Topology: Linear topology is a type of network topology in which each device is connected one by one in a linear chain. In this topology, there are 123 hosts and 123 switches. A linear chain of switches and hosts is formed by connecting each host to a single switch and each switch to its neighboring switch. Linear topology is shown in Fig. 3.

Fig. 3. Linear topology generated by floodlight controller

c) Torus Topology: Torus topology is a donut-shaped network architecture that establishes an all-around connection by cyclically connecting the nearest switch and its neighboring switches. Torus topology consists of 25 switches and 25 hosts, arranged in a 5x5 grid. Each switch is cyclically connected to its four nearest neighbors, creating 360° connectivity, and each switch contains one host. The emulated torus network is shown in Fig. 4.

Fig. 4. Torus topology generated by floodlight controller

d) Tree Topology: In networking, tree topology is a structure where devices are connected hierarchically. It resembles a tree with a root node and various branches. The root node is connected to multiple levels of child nodes, forming a hierarchy. In this setup, A hierarchical network structure is created in this configuration by the tree topology, which consists of three tiers of switches, each of which has four hosts. In this topology 21 hosts, and 64 switches are taken. Tree topology is shown in Fig. 5.

Fig. 5. Tree topology generated by floodlight controller

e) Custom Topology: The custom topology specifies a customized network architecture. Used python script to create a custom topology with 11 switches and 44 hosts. Switches are connected in a linear chain, and each switch contains 4 hosts. The emulated custom network is shown in Fig. 6.

Fig. 6. Custom topology generated by floodlight controller

The single, linear, tree, torus, and custom topologies were created in Mininet and connected separately to Ryu, Floodlight, OpenDayLight, and ONOS controllers. To evaluate throughput, jitter, and packet loss considering the most distant hosts, the Iperf [24] test was performed when a topology was associated with a specific controller. One was considered as an Iperf server and the other as an Iperf client between the two furthest hosts. The Iperf server was started in TCP mode to evaluate throughput. A throughput observation was performed after 50 TCP packets were transmitted from the client to the server. The server was running in UDP mode when jitter and data loss were calculated. At this time, 50 UDP packets have been sent from clients. To determine the delay, the server received 50 packets from the client and the average response time (RTT) was used to determine the network latency.

The experiments are carried out and the results are shown in Figs. 7, 8, 9, and 10.

A. Throughput

Ryu outperforms all controllers in all topologies, with the linear topology having the best throughput (56.5 Mbps) and the torus topology having the lowest throughput (38.9 Mbps). ONOS achieves the second-highest throughput in linear topology (54.2 Mbps) and tree topology (51.2 Mbps). OpenDayLight achieves the third-highest throughput in linear topology (52.8 Mbps) and custom topology (42.1 Mbps). Floodlight achieves the lowest throughput in all topologies; It is highest in the linear topology (50.2 Mbps) and lowest in the torus topology (35.6 Mbps).

Fig. 7. Throughput comparison of RYU, Floolight, OpenDayLight, ONOS.

B. Latency

Ryu has the lowest latency across all topologies; The highest latency is observed in the torus topology (0.8 ms) and the lowest in the linear topology (0.4 ms). ONOS has the second lowest latency in linear topology (0.4 ms) and tree topology (0.6 ms). OpenDayLight has the third lowest latency in linear topology (0.4 ms) and custom topology (0.6 ms). Floodlight has the highest latency of all topologies, the highest in the torus topology (1.0 ms) and the lowest in the linear topology (0.5 ms).

Fig. 8. Latency comparison of RYU, Floolight, OpenDayLight, ONOS.

C. Jitter

Ryu has the lowest jitter across all topologies, with the lowest in the linear topology (0.4 ms) and the highest in the torus topology (1.0 ms). ONOS has the second lowest jitter in linear topology (0.4 ms) and tree topology (0.6 ms). OpenDayLight has the third lowest jitter in linear topology (0.5 ms) and custom topology (0.7 ms). Floodlight has the highest jitter in all topologies, the highest in the pipe topology (1.2 ms) and the lowest in the line topology (0.6 ms).

Fig. 9. Jitter comparison of RYU, Floolight, OpenDayLight, ONOS.

D. Packet Loss

Ryu records the lowest packet loss across all topologies, with the lowest in the linear topology (0.3%) and the highest in the torus topology (0.8%). ONOS records the second-lowest packet loss in both linear topology (0.3%) and tree topology (0.5%). OpenDayLight records the third lowest packet loss in the linear topology (0.4%) and the custom topology (0.6%). Floodlight has the highest packet loss across all topologies, with the highest in the torus topology (1.0%) and the lowest in the linear topology (0.5%).

Fig. 10. Packet Loss comparison of RYU, Floolight, OpenDayLight, ONOS.

In summary, Ryu outperforms Floodlight, OpenDayLight, and ONOS in terms of throughput, jitter, latency, and packet loss across multiple network topologies. In summary, Ryu is the best controller for high-performance networks, followed by ONOS. OpenDayLight and Floodlight are suitable for research and development and large networks, respectively. The best topology for high-performance networks is tree topology, followed by linear topology. Single topologies work well for small networks, although custom and torus topologies are suitable for specific use cases. The results also highlight the importance of topology selection and controller placement in SDN networks. The combination of Ryu and linear topology produces the best results. The results provide valuable insights for practitioners, scholars, and network administrators that aim to optimize the SDN network's performance and achieve its full potential.

A. Performance Comparison of SDN Controllers

The evaluation revealed that the Ryu controller consistently outperforms Floodlight, OpenDayLight, and ONOS in terms of throughput, latency, jitter, and packet loss. This makes Ryu particularly suitable for high-performance applications where these metrics are critical. The linear topology, when combined with Ryu, demonstrated the best results, suggesting this configuration is optimal for scenarios requiring low latency and high throughput, such as autonomous driving or real-time communication systems.

B. Topology impact on controller performace

The study highlighted the significant role of network topology in influencing controller performance. The linear topology was most effective across all metrics, particularly when paired with the Ryu controller. This suggests that for high-performance networks, selecting a suitable topology is as crucial as choosing the right controller. The tree and torus topologies, while less efficient than linear, may still be useful in specific contexts where network structure or redundancy is more critical.

C. Suitability of Controllers for Different Network Scenarios

Each SDN controller offers unique advantages that cater to different network scenarios. ONOS, despite not leading in performance metrics, provides scalability and fault tolerance due to its distributed architecture. This makes it suitable for large-scale deployments where resilience and network management flexibility are crucial. OpenDayLight, while not the top performer, is valuable in research and development settings due to its modular and model-driven design, which facilitates the development and testing of new network applications.

Floodlight, although trailing in performance, remains a practical choice for small-scale or educational environments. Its integration with various network management tools and ease of use makes it a good option where performance requirements are less stringent.

D. Practical Implications and Recommendations

The findings of this study offer practical guidance for network administrators, researchers, and developers in selecting the appropriate SDN controller and topology. For high-performance requirements, the Ryu controller in a linear topology is recommended. However, considerations such as scalability, fault tolerance, and specific application needs should guide the final decision. The study emphasizes the need for a tailored approach to network design, considering both the strengths and limitations of each SDN controller.

E. Future Research Directions

To further advance AI-driven SDN, research should investigate the impact of AI-driven optimization on SDN performance under various network conditions and traffic patterns. Additionally, analyzing AI's potential to enhance scalability and reliability in large networks and real deployment scenarios is crucial. Comparative studies between AI-powered SDN and traditional network topologies, as well as explorations of hybrid networks leveraging AI, will provide a deeper understanding of AI's role in future network management.

In conclusion, this study underscores the importance of a nuanced approach to SDN network design, where the choice of controller and topology should be aligned with the specific performance and functional requirements of the network.

In summary, this study provides a thorough analysis of five different network topologies and four well-known SDN controllers. The results demonstrate the superior performance of Ryu, especially in linear topology. These results highlight the importance of topology and controller selection and have significant implications for the design and deployment of SDN networks. The Ryu and linear topologies perform well in high-performance networks, while other topologies and controllers are better suited for certain applications.

Future research should focus on harnessing Artificial Intelligence (AI) to optimize SDN controller performance under diverse workloads and network conditions. By integrating AI with SDN, we can unlock more flexible, efficient, and scalable network management solutions. A comprehensive evaluation of AI-powered SDN against traditional network topologies will provide valuable insights, and exploring hybrid networks will reveal new possibilities for network optimization.

Kreutz D, Ramos FM, Verissimo P, Rothenberg CE, Azodolmolky S, Uhlig S (2014) Software-Defined Networking: A Comprehensive Survey. arXiv org Jun 02, https://arxiv.org/abs/1406.0440
Xie J, Guo D, Hu Z, Qu T, Lv P (Aug. 2015) Control plane of software defined networks: A survey. Comput Commun 67:1–10. 10.1016/j.comcom.2015.06.004
Blial O, Mamoun MB, Benaini R (2016) An Overview on SDN Architectures with Multiple Controllers, Journal of Computer Networks and Communications, vol. pp. 1–8, Jan. 2016, 10.1155/2016/9396525
Zhu L SDN, Controllers ACM, Computing Surveys no et al (2020) 6, pp. 1–40, Dec. 10.1145/3421764
Kaur K, Kaur S, Gupta V (2016) Performance analysis of python based openflow controllers. IEEE Xplore Jun 01, https://ieeexplore.ieee.org/document/8372192
Vedhapriyavadhana R, Rani EFI, Theepa M (2018) Simulation and performance analysis of security issue using floodlight controller in software defined network, in International Conference on Emerging Trends and Innovations In Engineering And Technological Research (ICETIETR), 2018, pp. 1–6
Rowshanrad S, Abdi V, Keshtgari M, PERFORMANCE EVALUATION OF SDN CONTROLLERS: FLOODLIGHT AND OPENDAYLIGHT (Nov. 2016) IIUM Eng J 17(2):47–57. 10.31436/iiumej.v17i2.615
Open Network Operating System (ONOS), [Online]. Available: https://wiki.onosproject.org/display/ONOS/Wiki+Home
Bholebawa IZ, Dalal UD (Aug. 2017) Performance Analysis of SDN/OpenFlow Controllers: POX Versus Floodlight. Wireless Pers Commun 98(2):1679–1699. 10.1007/s11277-017-4939-z
Badotra S, Panda SN (Oct. 2019) Evaluation and comparison of OpenDayLight and open networking operating system in software-defined networking. Cluster Comput 23(2):1281–1291. 10.1007/s10586-019-02996-0
Abraham AL, Hrishikesh BH, Atehar MT, Hegde BN, Giri A (2024) ONOS SDN Framework: Assessing the Impact of Single and Multi-Controller Architectures on Network Efficiency, in Lecture notes in networks and systems, pp. 385–396. 10.1007/978-981-97-1323-3_32
Stancu AL, Halunga S, Vulpe A, Suciu G, Fratu O, Popovici EC (2015) A comparison between several Software Defined Networking controllers, in 12th International Conference on Telecommunication in Modern Satellite, Cable and Broadcasting Services (TELSIKS), 2015, pp. 223–226. https://ieeexplore.ieee.org/document/7357774
Fancy C, Pushpalatha M (2017) Performance evaluation of SDN controllers POX and floodlight in mininet emulation environment, International Conference on Intelligent Sustainable Systems (ICISS), Palladam, India, 2017, pp. 695–699, 10.1109/ISS1.2017.8389262
Zhao Y, Iannone L, Riguidel M, On the performance of SDN controllers: A reality check, in (2015) IEEE Conference on Network Function Virtualization and Software Defined Network (NFV-SDN), 2015, pp. 79–85. 10.1109/NFV-SDN.2015.7387410
Wang S-Y (2014) Comparison of SDN OpenFlow network simulator and emulators: EstiNet vs. Mininet, in IEEE Symposium on Computers and Communications (ISCC), 2014, pp. 1–6. 10.1109/ISCC.2014.6912609
Bholebawa IZ, Dalal UD (Jan. 2016) Design and Performance Analysis of OpenFlow-Enabled Network Topologies Using Mininet. Int J Comput Communication Eng 5(6):419–429. 10.17706/ijcce.2016.5.6.419-429
Baskoro F, Hidayat R, Wibowo SB, Comparing LACP Implementation between Ryu and Opendaylight SDN Controller, in (2019) 11th International Conference on Information Technology and Electrical Engineering (ICITEE), 2019, pp. 1–4. 10.1109/ICITEED.2019.8929986
Mamushiane L, Lysko A, Dlamini S (2018) A comparative evaluation of the performance of popular SDN controllers, in 2018 Wireless Days (WD), pp. 54–59. https://ieeexplore.ieee.org/document/8361694
Ali J, Lee S, Roh B-H (2018) Performance analysis of POX and Ryu with different SDN topologies, in Proceedings of the International Conference on Information Science and System, 2018. https://dl.acm.org/doi/10.1145/3209914.3209931
Albu-Salih A (2022) Performance Evaluation of Ryu Controller in Software Defined Networks. J Al-Qadisiyah Comput Sci Math 14:1. 10.29304/jqcm.2022.14.1.879
Dissanayake MB, Kumari ALV (2021) A. Udunuwara. Performance comparison of onosand odlcontrollers in. J Res Technol Eng 2:94–105
Abraham AL, Hrishikesh BH, Atehar MT, Hegde BN, Giri A (2024) ONOS SDN Framework: Assessing the Impact of Single and Multi-Controller Architectures on Network Efficiency. In: Senjyu T, So–In C, Joshi A (eds) Smart Trends in Computing and Communications. SmartCom 2024 2024. Lecture Notes in Networks and Systems, vol 946. Springer, Singapore. https://doi.org/10.1007/978-981-97-1323-3_32
de Oliveira R, Schweitzer C, Shinoda A, Ligia Rodrigues P Using Mininet for emulation and prototyping Software-Defined Networks. 2014 IEEE Colombian Conference on Communications and, Computing (2014) (COLCOM). Bogota, Colombia, Jun 2014
Iperf available at - https://iperf.fr/

The authors declare no competing interests.

Download PDF

Version 1

posted

You are reading this latest preprint version

Performance Comparison Of SDN Controllers In Different Network Topologies

Status:

Version 1

Abstract

Figures

I. INTRODUCTION

II. RELATED WORK

III. MOTIVATION

IV. COMPARISON OF RYU, FLOODLIGHT, OPENDAYLIGHT, AND ONOS

V. IMPLEMENTATION

VI. RESULT ANALYSIS

VII. MOTIVATION

VIII. CONCLUSION AND FUTURE WORK

References

Additional Declarations

Status:

Version 1