Ryu Controller’s Scalability Experiment on

Software Defined Networks

Saleh Asadollahi Bhargavi Goswami, Mohammed Sameer
Computer Science Computer Science Computer Science
Saurashtra University Christ University Christ University
Rajkot, India Bangalore, India Bangalore, India
asadollahimcitp@gmail.com bhargavigoswami@gmail.com sameersam9519@gmail.com

Abstract—Software defined networks is the future of According to Traditional Architecture, Forwarding

Computer networks which claims that traditional networks plane, Control plane and Management plane all are tied up
are getting replaced by SDN. Considering the number of together in traditional routers. Combination of these three
nodes everyday connecting to the global village of internet, it planes in a same chassis makes it complex and tough to
becomes inevitable to adapt to any new technology before manage. Software Defined Networks simplifies traditional
testing its scalability in presence of dynamic circumstances. routers with main idea of separation of control plane from
While a lot of research is going on to provide solution as data plane, and provide a centralized control by means of
SDN to overcome the limitations of the traditional network, controllers for whole or a part of networks.
it gives a call to research community to test the applicability
and caliber to withstand the fault tolerance of the provided According to SDN Architecture, devices are composed
solution in the form of SDN Controllers. Out of the existing of only forwarding plane that includes a) logical and
multiple controllers providing the SDN functionalities to the physical ports, b) flow and group tables. Based on the
network, one of the basic controllers is Ryu Controller. This configuration specifications of control plane (brain), flow
paper is a contribution towards performance evaluation of tables get filled up by controller. Once device receives
scalability of the Ryu Controller by implementing multiple new packet, look into the flow tables and take proper
scenarios experimented on the simulation tool of Mininet, action. In case of lack of information, forwarding device
Ryu Controller and iPerf. Ryu Controller is tested in the sends the packet to the controller or drops the packet base
simulation environment by observing throughput of the on policy. In accordance to the controller’s configuration,
controller and checked its performance in dynamic new records get added to the flow tables and further
networking conditions over Mesh topology by exponentially
forwarding of the packets happens independently in next
increasing the number of nodes until it supported tested on
high end devices.
cycles.
The key component in SDN is Controller where, POX
[4], OpenDaylight [5], Floodlight [6], Beacon [7], Ryu
Keywords— Software Defined Netwoks (SDN), Mininet, [8], NOX [9], etc, are few of them with different features
OpenFlow, Ryu, iPerf, Gnuplot that were compared by the team of authors in [10].

I. INTRODUCTION There are two another major components: 1)

northbound interface, who is responsible to provide an
IoT, 4G, 5G, VANET [1], etc, are all thirst area of abstract for application layer. It also hides the detail of
network communication that offer more comfort in our down layer and makes writing the network management
life in one side and make computer network complex in and control application easier for developer. 2)
other side by adding more and more users to Internet. Southbound interface, which provides communication
Huge Data Center infrastructure build before 10 years are between the controller and forwarding devices. OpenFlow
still running on complex traditional network equipment [11] is the most well documented SDN protocol that is
such as routers and switches, where administrator are used majorly in research community with current version
supposed to implement high level policy through low of 1.5. Opflex [12], NETCONF [13], ForCES [14], POF
level and pre-defined commands that any company such [15] are other options for southbound interface.
as Cisco, HP, Juniper who have their own commands and
configuration method [2]. Lack of programmability was Separating the forwarding plane from control plan and
resisting programmers, researcher and developers from taking it on a remote system will generate questions on its
writing the custom applications for networks. As a capabilities of scaling on diverse scenarios. To throw light
solution, implementing the idea of research with new upon the scalability of the controller and checking the
approach in the area of network is the major focus of behavior of controllers in multiple diversified networking
researchers to look deeper to this complex equipment situations, the authors of this paper presents here the
architecture and that is why SDN was born [3]. experiments with criteria of scalability and performance
of the controllers.
 The paper is formed in the following manner. Section calls the appropriate event handler. Hence, the event
II is providing helicopter view on Ryu controller. Section handler is called within the context of the event-
III provides details about the simulation test bed set to processing thread, which works in a blocking fashion, i.e.,
perform the experiments on scalability with diversified when an event handler is given control, no further events
networking conditions. Section IV provides the obtained for the Ryu application will be processed until control is
experimental results and evaluation of performance returned.
statistics followed by conclusion and references.
III. SIMULATION ENVIRONMENT
II. RYU SDN CONTROLLER As a simulator, Mininet [16] is used and as a controller
The Ryu Controller is open source and under Ryu. Mininet and Ryu controller, both are installed in a
the Apache 2.0 license, written completely based on same virtual machine. The switch used in this experiment
Python, supported and deployed by NTT cloud data is OpenFlow kernel switch, also known as Open vSwitch
centers. Main source code can be found on GitHub, or OVSK-Switch [17] by enabling OpenFlow protocol
provided and supported by Open Ryu community. It mode.
supports NETCONF and OF-config network management
protocols, as well as OpenFlow. Considering the Python is used as scripting language to write the
compatibility, OpenFlow switches, Hewlett topology instead to accepting the automatic decision of
Packard, IBM, and NEC are tested and certified with Ryu number of host connecting to switch or default command
controller. It supports the OpenFlow protocol up to the provided by Mininet. The code of the python script is
latest version 1.5. provided in Fig. 2. Python script of customized topology
includes the specification of host to switch, switch to
switch and switch to Ryu controller.
from mininet.topo import Topo for s66witch in range(1):
class MyTopo( Topo ): s6Switch = self.addSwitch( 's6' )
"Simple topology example." self.addLink( s1Switch, s6Switch )
def __init__( self ): self.addLink( s2Switch, s6Switch )
"Create custom topo." self.addLink( s3Switch, s6Switch )
# Initialize topology self.addLink( s4Switch, s6Switch )
Topo.__init__( self ) self.addLink( s5Switch, s6Switch )
#Add switches # Add hosts and link to switches
for s11Switch in range(1): for h1_ in range(0,30):
s1Switch = self.addSwitch( 's1' ) h1=self.addHost('h1_%s' % (h1_+1))
for s22witch in range(1): self.addLink( h1, s1Switch )
s2Switch = self.addSwitch( 's2' ) for h2_ in range(30,60):
self.addLink( s1Switch, s2Switch ) h2=self.addHost('h2_%s' % (h2_+1))
for s33witch in range(1): self.addLink( s2Switch, h2 )
s3Switch = self.addSwitch( 's3' ) for h3_ in range(60,90):
self.addLink( s2Switch, s3Switch ) h3=self.addHost('h3_%s' % (h3_+1))
self.addLink( s1Switch, s3Switch ) self.addLink( s3Switch, h3 )
for s44witch in range(1): #for h4_ in range(30,40):
s4Switch = self.addSwitch( 's4' ) #h4=self.addHost('h4_%s' % (h4_+1))
Fig. 1. Ryu SDN controller architecture self.addLink( s1Switch, s4Switch ) #self.addLink( s4Switch, h4 )
self.addLink( s2Switch, s4Switch ) for h5_ in range(90,120):
self.addLink( s3Switch, s4Switch ) h5=self.addHost('h5_%s' % (h5_+1))
Same as other SDN Controllers, Ryu is also creating for s55witch in range(1): self.addLink( s5Switch, h5 )
s5Switch = self.addSwitch( 's5' ) for h6_ in range(120,150):
OpenFlow packets, managing events related to incoming self.addLink( s1Switch, s5Switch ) h6=self.addHost('h6_%s' % (h6_+1))
and outgoing packets. It has abundant list of libraries self.addLink( s2Switch, s5Switch )
self.addLink( s3Switch, s5Switch )
self.addLink( s6Switch, h6 )

which supports packet processing operations. In respect of self.addLink( s4Switch, s5Switch ) topos = { 'mytopo': ( lambda: MyTopo() ) }
support for southbound protocols, Ryu is working hand in
Fig. 2. Python script for generating scenarios
hand with protocols such as XFlow (Netflow and Sflow),
OF-Config, NETCONF, Open vSwitch Database To evaluate the statistics related to the performance of
Management Protocol (OVSDB), etc. VLAN, GRE and controller, mesh topology is implemented over 6 switches
VLAN, etc is also supported by Ryu Packet Libraries. with five different scenario having difference in only
Let us have a look on Ryu Managers and Core- number of nodes connected to each peripheral switch. As
Processes. The main executable is Ryu Manager. Ryu an effort to implement and test the controller’s
runs and listens to peculiar IP and Port, eg. 0.0.0.0:6633 to performance using scalability, we created a custom
connect to Ryu manager which uses RyuApp class using topology with five different scenarios having difference in
inheritance where, the Ryu messaging service does the number of nodes as shown in Table 1.
support components developed in other languages.
Table1: Scenario Table for Experiment
Ryu is distributed with multiple applications such as
a simple_switch, router, isolation, firewall, GRE tunnel, Scenario Number of switch Number of nodes
topology, VLAN, etc. Ryu applications are single- Scenario 1 6 50
threaded entities, which implement various functionalities.
Ryu applications send asynchronous events to each other. Scenario 2 6 100
The functional architecture of a Ryu application is shown Scenario 3 6 150
in Figure 2.
Scenario 4 6 200
To preserve the order of events, each Ryu application Scenario 5 6 250
has a receive queue (FIFO) for events FIFO. The thread’s
main loop pops out events from the receive queue and Scenario 6 6 300
 Table2: Configuration Specification for Experiments content of ‘myresults’ file using command: plot
“myresults” title “Tcp_Flow” with linespoints.
Ubuntu 16.04.3 LTS
In the same way, using the python script all other
Mininet 2.2.1 0dl
scenarios are developed as stated in Table 1 with
OpenFlow ( 0x1:0x4)1.3 configuration provided in Table 2.
iPerf 3.0.7 One by one each scenario is tested using the step 1 to
CPU Intel Core i5 520M step 6 and results are obtained which is discussed in
upcoming section of performance analysis. Kindly note
RAM 6GB DDR3 that simulation execution of experiment needs RAM
support not less than 6GB, especially for the simulations
having nodes more than 200.
Now the step by step procedure is followed to perform
the experiment on Ryu using Mininet. For obtaining IV. PERFORMANCE ANALISIS
statistics tool used is iPerf.
This section provides the results obtained during the
Step 1: The first step is to run the Ryu controller using experimentation. With this paper, authors have made
the script. Here, the name of application program is attempt to address the scalability features of the Ryu
simple_switch_stp_13.py. Simple_switch_stp_13 is an
controller by implementing six scenarios in simulation
application program to develop spanning tree scenario
experimental environment which will be discussed in this
because, we are using mesh topology and mesh topology
has loops. To avoid loops we need spanning tree and thus, section in detail. This section has total 6 graphs which
stplib.py library is used which performs Bridge Protocol represents results for each scenario listed in Table 1. To
Data Unit BPDU packet exchange. Before executing this evaluate performance of Ryu controller in incremental
command, control must be in the folder of ryu. Now, we experiment with respect to scalability, throughput is the
provide Command: best matching parameter which will suffice our aim of
experiment. Thus, in this section, we have limited the
./bin/ryu-manager ryu/app/simple_switch_stp_13.py study to throughput only.
Step 2: Next step is to run the mininet mesh topology Graph of Fig. 3 shows the results obtained by
script, by providing topology name and switch OVSK performing transmission between client and server having
with the following command: sudo mn --custom the strength of nodes supported by network limited to 50.
~/mininet/examples/mymesh.py --topo=mytopo --mac -- It is observed from the graph that average throughput
controller remote --switch ovsk. Once the command is stays at 1.65 Gbps. Graph of Fig. 3 also shows that the
executed, check the connectivity between all the hosts variations are very high within the duration of 100 sec of
using mininet Command: pingall. simulation.
Step 3: Now we define one client and one server
which is done by any two host of the developed network.
The command to perform this task is: xterm h1_1 h6_60.
We have used first and last host with xterm command.
This will open two terminal windows, one as client and
another as server. Check configuration details on both the
windows with command: ifconfig.
Step 4: Now we need to generate the traffic between
client and server and log the events using iPerf tool. First
we go to server window and enter the command: iPerf –s
–p 6633 –i 1 > result. Here, ‘result’ is the filename
provided to store the results. Once the server starts waits
for the client. Now at the client side, to generate traffic,
we need to provide IP address of the server with the port
address by following command: iPerf –c 10.0.0.50 –p
6633 –t 100. Here 100 represent time in seconds.
Fig. 3. Throughput for scenarios with 50 nodes.
Step 5: Next step is filtering the logged file for
obtaining experiment specific results. We can check the Similarly, the stability is a big concern if we look at
content of generated file using command: more result. For the Fig. 4 which demonstrates the throughput graph of
filtering we have used grep and awk command: cat result | scenario with 100 nodes. It is even worst as far as stability
grep sec | head -100 | tr – “ ” | awk ‘{print $3,$5}’ > is concerned in comparison of Fig. 3. Again, if observed
myresults. Here, ‘myresults’ is the name of file where well, Fig. 5 is a bit stable even in presence of number of
filtered results are stored which can be checked for nodes equal to 150. However, there are few instances of
content using ‘more’ command: more myresults. highly volatile behavior of the network in Fig.5. Fig. 6
Step 6: Next step is to plot the graphs of obtained graph describes again excessive variations in the
results for which Gnuplot is used in this experiment. To throughput when the number of nodes reaches to 200.
start gnuplot tool, the command is: gnuplot. Next, plot the Once again, if we observe the graph shown in Fig. 7
having 250 nodes, it seems to be stable in comparison of Fig. 6. Throughput for scenarios with 200 nodes.
graph of Fig. 4 and Fig. 6 with 100 and 200 nodes. Still
few instances does not prove it better in comparison of
Fig.3 and Fig.5 with 50 and 150 nodes. Once, the final
result of 300 nodes scenario was obtained, it was observed
that throughput was increasing will tolerance of few
instance of dropping. For few seconds, simulation was
running well but, by the end of reaching to middle of the
simulation time, slowly, dropping instances were
observed frequently leading to degraded performance in
the second half of the simulation run.

Fig. 7. Throughput for scenarios with 250 nodes.

Fig. 4. Throughput for scenarios with 100 nodes.

Fig. 8. Throughput for scenarios with 300 nodes.

With these graphs shown from Fig. 3 to Fig. 8, it was

observed that Ryu is very much resource demanding
controller which uses CPU and RAM utilization to
optimum and thus results to degraded performance in
presence of increasing number of nodes. Even after
checking the performance with high end systems, the
resource utilization was observed to be too high in
Fig. 5. Throughput for scenarios with 150 nodes.
comparison of scale of nodes support provided by the
controller. We limited the study to 300 nodes because
with even i7 processors with 8GB RAM resources were
proved not enough during the execution of
experimentation.

V. CONCLUSION AND FUTURE SCOPE

With this paper, authors have made attempt to address
the scalability features of the Ryu controller by
implementing various diversified scenarios in simulation
experimental environment. In this paper, authors have
provided the clear idea how to create experimental test
bed along with analysis of obtained statistical results
keeping the throughput performance as the central focus.
We would conclude this paper by providing negative sign
to move forward to the researchers who are looking for
implementation of their idea over Ryu Controller in the
domain of Software Defined Networks without any doubt.
The controller not just provide the simulation [5] Asadollahi, S., Gowsami, B. (2017). Implementation of SDN using
experimental test bed support but, also provides clear OpenDaylight Controller. Proceeding of An International
Conference on Recent Trends in IT Innovations - Tec'afe 2017.
explanation for analysis of obtained statistics after the ISSN(Online) : 2320-9801
experiments are simulated. The tools suggested, [6] Project Floodlight, Floodlight. (2012). from
simulated, shown through figures and graphs will help the http://floodlight.openflowhub.org/
research community to further conduct such experiments [7] Erickson, D. (2013). The Beacon OpenFlow controller.
in the future by implementing their desired parameters Proceedings of ACM SIGCOMM Workshop Hot Topocs Software
though these experiments to improvise Ryu Controllers Defined Network II, 13-18 p, 2013.
which is required as far as current performance is [8] Nippon Telegraph and Telephone Corporation, RYU network
concerned. This paper will also address the programmers, operating system, 2012, from http://osrg.github.com/ryu
developers and new bees in the area of SDN, who are [9] Gude al, N. (2008). NOX: Towards an operating system for
looking forward to touch the practical aspects of the SDN networks. ACM SIGCOMM - Computer Communication Revie.
vol. 38, no. 3, pp. 105–110.
by following implementation details provided in the
[10] Asadollahi, S., Gowsami, B. (2017). Software Defined Network,
paper. Further, the research team will come up with few Controller Comparison. Proceedings of Tec'afe 2017,Vol.5,
more papers on implementation of other SDN controllers Special Issue 2, April 2017. ISSN: 2320-9798.
in the coming future. The team also has planned to [11] McKeown et al, N. (2008). OpenFlow: Enabling innovation in
compare the controllers of SDN, once all the stellar campus networks. ACM SIGCOMM - Computer Communication
controllers are implemented and experimented by them. Revie, vol. 38, no. 2, p. 69–74.
[12] Smith et al, M. (2014). OpFlex control protocol, Internet
Engineering Task Force, from : http://tools.ietf.org/html/draft-
REFERENCES smith-opflex-00
[13] Enns, R., Bjorklund, M., Schoenwaelder, J., Bierman, A. (2011).
[1] Gowsami, B. Asadollahi, S., (2016). “Novel Approach to Network configuration protocol (NETCONF). Internet Engineering
Improvise Congestion Control over Vehicular Ad Hoc Task Forc, form http://www.ietf.org/rfc/rfc6241.txt
Networks (VANET)” Proceedings of the 10th INDIACom; [14] Doria et al, A. (2010). Forwarding and control element separation
International Conference on “Computing for Sustainable Global (ForCES) protocol specification. Internet Engineering Task Forc,
Development”, March 2016. Delhi, India. IEEE Xplore ISBN: 978- from http://www.ietf.org/r/fc/rfc5810.txt.
9-3805-4421-2 [15] Song, H. (2013). Protocol-oblivious forwarding: Unleash the
[2] Gowsami, B. Asadollahi, S., (2017). “Enhancement of LAN power of SDN through a future-proof forwarding plane.
Infrastructure performance for data center in presence of Proceedings of ACM SIGCOMM Workshop Hot Topics Softw
Network Security” Proceedings of Computer Society of India, Defined Netw II. p. 127–132.
Springer, Next-Generation Networks pp 419-432 ISBN: 978-981- [16] Lantz, B. Heller, and N. McKeown. (2010). A network in a laptop:
10-6005-2 Rapid prototyping for software-defined network. Proceedings of
[3] Asadollahi, S., Gowsami, B. (2017). Revolution in Existing ACM SIGCOMM Workshop Hot Topics Netw, 19th. p. 19:1–19:6
Network under the Influence of Software Defined Network. [17] B. Pfaff and B. Davie. (2013). The Open vSwitch database
Proceedings of the INDIACom 11th, Delhi, March 1-3.2017 IEEE management protocol. Internet Engineering Task Force, RFC 7047,
Conference ID: 40353 from http://www.ietf.org/rfc/rfc7047.txt
[4] McCauley, M. (2012). POX, from http://www.noxrepo.org/