Academia.eduAcademia.edu

Figure 15 – uploaded by Journal of Computer and Knowledge Engineering

See full PDFdownloadDownload figure
Fig. 18.OpenDaylight and ONOS performance without a routing protocol against different network scales

Figure 18 OpenDaylight and ONOS performance without a routing protocol against different network scales

Related Figures (21)

Fig. 1. Three-layered SDN architecture OpenFlow controllers: OpenFlow was first introduced at Stanford University in 2008 and it made research on real campus and large scale networks like GENI possible [13]. OpenFlow [14][15] encouraged manufacturers towards supporting this protocol in their future switching products. An OpenFlow controller manages flow tables in network devices, while the controller and hardware connect by SSL or TLS encryptions through a secure channel [17][18]. An OpenFlow switch consists of one or more flow tables, a secure channel, and a controller. Also, each flow table consists of multiple flow entries each of which include three parts including a header field, an action, and flow counters. Every incoming flow is reviewed to match against existing flows in a flow table by their header fields. According to the matched flow, the action dictates what happens with the
Fig. 1. Three-layered SDN architecture OpenFlow controllers: OpenFlow was first introduced at Stanford University in 2008 and it made research on real campus and large scale networks like GENI possible [13]. OpenFlow [14][15] encouraged manufacturers towards supporting this protocol in their future switching products. An OpenFlow controller manages flow tables in network devices, while the controller and hardware connect by SSL or TLS encryptions through a secure channel [17][18]. An OpenFlow switch consists of one or more flow tables, a secure channel, and a controller. Also, each flow table consists of multiple flow entries each of which include three parts including a header field, an action, and flow counters. Every incoming flow is reviewed to match against existing flows in a flow table by their header fields. According to the matched flow, the action dictates what happens with the
Table. 1. Qualitative comparison of general-purpose controllers
Table. 1. Qualitative comparison of general-purpose controllers
Table. 2. qualitative comparison of distributed controllers
Table. 2. qualitative comparison of distributed controllers
Table. 3. controllers used in our qualitative evaluation Centralized controllers: These controllers were the first introduced SDN structures in which a single controller manages all the devices in a network. Each flow is received at the controller as a packet-in and after the controller processes the packet based on the defined policies by the application layer and defines an action for that flow, it sends the requesting switch packet-out and flow-add packets. There are various controllers developed by java and python programming languages namely, RYU [29], Beacon [9], floodlight [16], POX [28] and NOX [23]. The main concept of these networks refer to the physical centrality which means each controller is aware of the overall state of the network and is connected to all the switches in topology. These types of controllers mostly have academic and research use in small scale networks. Among POX, NOX, and RYU, three python-based controllers, we only evaluate POX and RYU as POX is the improved version of NOX. Between Floodlight and Beacon that are java-based and require large memory allocations, we chose Floodlight as according to [2] it requires less memory than Beacon. re Sat tig wae a: S we ate 1) Determining the appropriate evaluation criterion QoS performance in centralized controllers: End-to-end delay and network bandwidth are two very effective factors on QoS and performance of centralized controllers. Network delay refers to the transmission time from source to destination, and bandwidth between two hosts refers to the available bandwidth for data transmission. The lowest end- to-end delay and highest bandwidth results in the highest QoS. For centralized controllers in our study namely POX, RYU, and Floodlight, we analyze QoS in different scales and topologies and introduce the controller with the highest QoS in each of the scenarios. In each stage we perform tests 0 times and take the average of these 10 outcomes as the final result. Also, we gradually increase the size of the network from | to 63 OpenFlow switches. According to Fig. 4, RYU performs better than POX and Floodlight in terms of latency as the scale increases, while POX has the highest delay in networks with more than seven switches. According to Fig. 5, all three controllers have similar decreasing patterns of bandwidth but again RYU closely out performs the other two and thus is the best choice in an increasing- scale network. application layer and defines an action for that flow, it sends
Table. 3. controllers used in our qualitative evaluation Centralized controllers: These controllers were the first introduced SDN structures in which a single controller manages all the devices in a network. Each flow is received at the controller as a packet-in and after the controller processes the packet based on the defined policies by the application layer and defines an action for that flow, it sends the requesting switch packet-out and flow-add packets. There are various controllers developed by java and python programming languages namely, RYU [29], Beacon [9], floodlight [16], POX [28] and NOX [23]. The main concept of these networks refer to the physical centrality which means each controller is aware of the overall state of the network and is connected to all the switches in topology. These types of controllers mostly have academic and research use in small scale networks. Among POX, NOX, and RYU, three python-based controllers, we only evaluate POX and RYU as POX is the improved version of NOX. Between Floodlight and Beacon that are java-based and require large memory allocations, we chose Floodlight as according to [2] it requires less memory than Beacon. re Sat tig wae a: S we ate 1) Determining the appropriate evaluation criterion QoS performance in centralized controllers: End-to-end delay and network bandwidth are two very effective factors on QoS and performance of centralized controllers. Network delay refers to the transmission time from source to destination, and bandwidth between two hosts refers to the available bandwidth for data transmission. The lowest end- to-end delay and highest bandwidth results in the highest QoS. For centralized controllers in our study namely POX, RYU, and Floodlight, we analyze QoS in different scales and topologies and introduce the controller with the highest QoS in each of the scenarios. In each stage we perform tests 0 times and take the average of these 10 outcomes as the final result. Also, we gradually increase the size of the network from | to 63 OpenFlow switches. According to Fig. 4, RYU performs better than POX and Floodlight in terms of latency as the scale increases, while POX has the highest delay in networks with more than seven switches. According to Fig. 5, all three controllers have similar decreasing patterns of bandwidth but again RYU closely out performs the other two and thus is the best choice in an increasing- scale network. application layer and defines an action for that flow, it sends
Network scale in centralized controllers: Increases in network scale mean more switches and more hosts which leads to more requests towards the controller directly affecting controllers’ performance.
Network scale in centralized controllers: Increases in network scale mean more switches and more hosts which leads to more requests towards the controller directly affecting controllers’ performance.
Fig. 12. Bandwidth against topology type Fig. 11. En-to-end delay against topology type
Fig. 12. Bandwidth against topology type Fig. 11. En-to-end delay against topology type
Fig. 10. Tree topology structure
Fig. 10. Tree topology structure
Fig. 13. End-to-end delay against MTU in facebook fat-tree topology
Fig. 13. End-to-end delay against MTU in facebook fat-tree topology
Fig. 15. End-to-end delay against network scale in google fat- tree topology
Fig. 15. End-to-end delay against network scale in google fat- tree topology
Fig. 17. End-to-end delay against network scale in facebook fat- tree topology
Fig. 17. End-to-end delay against network scale in facebook fat- tree topology
Fig. 19. OpenDaylight and ONOS performance with bgp against different network scales
Fig. 19. OpenDaylight and ONOS performance with bgp against different network scales
Fig. 20. Routing in ONOS with BGP
Fig. 20. Routing in ONOS with BGP
Related topics:
Software Defined Networking (SDN),
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved