An Effective Time-Sharing Switch Migration Scheme for Load Balancing in Software Defined Networking

Full text

An Effective Time-Sharing Switch Migration
Scheme for Load Balancing in Software Defined
Networking
Thangaraj Ethilu 1,*, Abirami Sathappan 1, and Paul Rodrigues 2
1 Department of Computer Science and Engineering, Annamalai University, India; Email: reachabisv@gmail.com (A.S.)
2 Department of Computer and Engineering, King Khalid University, Saudi Arabia; Email: drpaulprof@gmail.com (P.R.)
*Correspondence: ethilthangaraj@yahoo.co.in (T.E.)
Abstract—Using distributed Software Defined Networking
(SDN)control, SDN delivers additional flexibility to network
management, and it has been a significant breakthrough in
network innovation. Switch migration is often used for
distributed controller workload balancing. The Time-
Sharing Switch Migration (TSSM) scheme proposed a
strategy in which multiple controllers are allowed to share
the workload of a switch via time sharing during an
overloaded condition, resulting in reduced ping-pong
controller difficulty, fewer overload occurrences, and
improved controller efficiency. However, it requires more
than one controller to accomplish, it has greater migration
costs and higher controller resource usage during the TSSM
operating time. As a result, we presented a coalitional game
strategy that optimizes controller selection throughout the
TSSM phase depending on flow characteristics. The new
TSSM method reduces migration costs and controller
resource usage while still providing TSSM benefits. For the
sake of practicality, the proposed strategy is implemented
using an open network operating system. The experimental
findings reveal that, as compared to the typical TSSM
system, the proposed technique reduces migration costs and
controller resource usage by approximately 18%.
Keywords—switch migration, load balancing, coalitional
game strategy, time sharing switch migration, software
defined networking
I. INTRODUCTION
The fast proliferation of cloud computing, big data
applications, the internet of multimedia things, and
increased data traffic have significantly raised network
management difficulties. The traditional network
architecture system consists of a data plane and a control
plane in each switch, with the former handling packet
processing and the latter handling decision making and
administration. As a result, upgrading the current
algorithms and policies to the switches is quite hard and
time consuming because all the related switches in the
given network must be updated one by one by system
administrators or workers [1].
Manuscript received December 22, 2022; revised February 20, 2023;
accepted May 11, 2023; published August 22, 2023.
Today, the software defined networking method
creates a distinct perspective of network administration in
networking applications by shifting the control plane in
switches to a central device known as the controller. As a
result, the controller may handle many switches in the
network. Monitoring and control of network switches are
simplified in this current method as compared to
traditional network management techniques, because the
controller unit can offer such information about the
switches.
Furthermore, by creating a set of rules in the controller,
the newest algorithms and control policies may be
quickly updated to the switches [2]. Aside from that,
SDN may support a broad range of applications, such as
(i) defending against cyber-attacks, (ii) recognizing
malicious access points, and (iii) offering anonymous
authentication, among others [3–7].
A single controller in a large network is a difficult
option because it creates a bottleneck in network
management performance. As a result, Distributed SDN
Control (DSC) is demanded in network applications, and
it acts as a promising solution in large network
management with many switches [8]. The DSC enables
many controllers to communicate with one another to
administer the whole network. Where each controller
manages a subset of switches (i.e., a subnet), and
processes may be transferred among controllers to
facilitate cooperation. Each controller is responsible for
dividing the workload for the subnets and reassigning the
burden of its switches through the periodical check-up of
each subnet, which is known as controller placement [9].
The controller placement is mostly focused on load
balancing and is carried out using a variety of techniques
such as work group control technique [10], deep
reinforcement learning technique [11], and so on. The
upshot of such control strategies may significantly alter
the switches in the subnet, causing the subnet to become
unstable via ping-pong operation. Furthermore, controller
placement strategies are not thought to be successful for
short-term flows such as distributed denial of service and
impulses [12].
Switch migration allows for a smoother change of
subnets in a shorter amount of time and addresses the
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
846
doi: 10.12720/jait.14.4.846-856

concerns. A switch migration approach examines the
workload state of each controller in the network in each
time frame (or time interval or period) to determine if
they are overloaded (busy) or lightly occupied (available
to share other works). If a network is overloaded, the
migration technique relocates a switch from the heavily
loaded controller subnet to the lightly loaded controller
subnet. Most existing switch migration methods follow
the smallest slice of the migration, which is one single
switch transferred at the start of the period. Once
migrated, the switch remains in the most recent sub-net
until the switch is picked for the following period. Most
crucially, these migration methods always need a
controller to supervise a single switch for the duration of
the migration. As a result, the controller in these systems
encounters ping-pong problems under elephant flow
situations (i.e., flow conveys numerous packets) and
faces the major problem of subnet instability [13].
The following outlines show the structure of the paper:
The literature review and problem definition of this study
are presented in Section II of this paper. Section III goes
through the fundamentals of the distributed SDN control
network, OpenFlow protocol rules, and network model.
Section IV discusses the proposed enhanced TSSM
scheme and matching algorithms, and Section V presents
the performance evaluation of the proposed approach.
Finally, in Section VI, the conclusion statement is
presented.
II. LITERATURE REVIEW
Several studies have been conducted throughout the
years to highlight the numerous difficulties in the DSC
network. Traditionally, dynamic controller placement
methods are used to achieve controller load balancing.
Chan et al. [14] presented a strategy for minimizing
service interruption time by easily moving the process
from one controller to another [15]. describes how a
lightly loaded controller can operate as a leader in the
event of a breakdown of the standard leader controller
unit. Controller placement approaches and issues are
discussed in [9], which emphasizes the need of
controllers maintaining fairness while sharing their tasks.
When compared to previous controller placement
methods, Hu and Zhang et al. [16] provided a dependable
deployment strategy with the goal of minimizing packet
loss and improving network stability. Kim et al. [17]
developed a strategy for improving the output of a
distributed datastore in an Open Daylight controller
cluster by regularly distributing shared leaders to cluster
members. Wang and Chang [18] described a system in
which controllers collaborate to redirect traffic to prevent
congestions during busy or overloaded periods on
switches. Nithya and Sangeetha et al. [19] proposes a
software defined cyber seeking system with a hybrid
controller for cloudlets and local networks. Sahoo and
Mishra et al. [20] presents prediction-based controllers,
which forecast network demand and conduct device
transfers based on prediction. The controller placement
research, such as the work group control approach and
the deep reinforcement learning technique provided
in [10, 11], where these strategies are ineffective during
impulses and distributed denial of service, etc. Aside
from the dynamic controller placement technique,
approaches for DSC workload balancing are classified
into three types: (i) switch migration, (ii) flow migration,
and (iii) flow splitting.
Switch Migration: To reduce burden, switch control
can be migrated from overloaded controllers to lightly
loaded controllers. Dixit and Hao et al. [21] discussed
switch migration in consideration of a controller’s CPU
and memory allocation exceeding its threshold level, but
it does not define the method of selecting the targeted
controllers. Min and Hua et al. [22] discusses switch
migration utilizing the Q-learning approach, which has
lowered the standard deviation of the controller workload.
Cui et al. [23] utilized the controller’s reaction time to
migrate switches. This strategy transfers the switch with
the greatest load of the controller in the shortest amount
of time. Sahoo et al. [24] suggested a strategy for
selecting targeted controllers for switch migration based
on CPU use, memory capacity, and bandwidth, among
other factors. Hu and Lan et al. [25] suggested a
simulated annealing algorithm for selecting the targeted
controller to reduce the cost of switch migration.
Flow Migration: Instead of migrating an entire switch,
the flow migration approach merely transfers the
hardness (i.e., flow beyond the threshold level) of the
flow. Hu and Wang et al. presented an approach in which
a super controller administers each controller in the
system and controls the flow controlled by them [26].
Lan and Li et al. [27] presented a game theory strategy
for managing each controller flow through task exchange.
When compared to standard flow migration methods,
Maity and Misra et al. [28] offered a traffic aware
consistent approach for minimizing flow migration
duration and obtained a 15% reduction in flow migration
time. Furthermore, using a traffic-aware flow migration
technique, Maity and Misra et al. [29] offered a method
to lower data plane load and obtained a 13% reduction
when compared to the two-phase update approach.
(a) Hierarchical method
(b) Flat method
Figure 1. Control methods for the DSC architecture.
Flow Splitting: This approach enables a switch to be
managed by many controllers at the same time. Gorkemli
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
847

and Tatlcıoglu et al. [30] presented a solution for flow
splitting utilizing virtual overlay on the data plane that
switches must negotiate with their controllers. Cheng and
Chen [31] developed a convex quadratic programming-
based solution for load balancing and decreasing new
switch-controller appointments by modelling the mapping
between controllers and switches.
Vikas and Samayveer [32] has proposed a self-
adaptive genetic approach-based particle swarm
optimization as a cluster-based routing to optimize the
control nodes in heterogeneous SDN-enabled free-space
optical under water wireless sensor networks. Moreover,
a novel fitness function is presented to balance the cluster
size by considering the most significant parameters
including energy and distance of network devices. It
shows that the proposed method improves stability period,
fitness value, etc. The control relation graph-based
controller placement method for Software-Defined
Networking (SDN) is presented in [33]. It demonstrates
that the proposed approach reduces management costs
through load balancing and response time in LEO
satellite networks. Zhang et al. proposed an SDN-based
space-terrestrial integrated network architecture. In
addition, it has presented an efficient dynamic controller
placement and adjustment algorithm for better load
balancing and response time [34]. Chen et al. proposed a
dynamical control domain division problem to reduce the
management cost. In addition, it has presented a heuristic
algorithm to choose the best controller for better load
balancing [35].
However, due to synchronization and the complexity
of the design, a switch cannot be operated by more than
one controller at the same time. As a result, flow
migration and flow splitting methods violate the
OpenFlow protocol and cannot be used in the real-time
controller platform.
As described in the literature section, most switch
migration solutions struggle with the ping-pong challenge.
The following example explains the ping-pong difficulty
of the controller. Consider two controllers [ and ]
and three switches [ , , ] in a network with a
maximum manageable workload of 200 PIMs per second
for each controller. Switches , , and  generate 120,
160, and 120 PIMS every period, accordingly. 
manages switches  and  at time t, and controller 
manages switch . Because  󰇛󰇜 󰇛󰇜= 120 +
160 >  (200 PIMS),  is overloaded and requires
switch migration. In most switch migration strategies, an
overloaded controller will request and take over a switch
from other controllers for an extended period. As a result,
at time t+1, Switch  is moved to controller ’s subnet.
However, if  󰇛󰇜 󰇛󰇜 = 120 + 120 > (200
PIMS) at period t+1, controller  will be overloaded. As
a result, controller  requests that  take over a switch
again at time t+2, increasing the complexity of ping-pong.
Lai and Wang et al. [36] recently suggested a Time-
Sharing Switch Migration Technique (TSSM) that
mitigates controller ping-pong by spreading the burden of
a switch that is monitored by two controllers at the same
time during overloaded situations. It proposes a switch
migration approach in which the burden of the switch is
split across two controllers over a certain time period.
Using the preceding example, at time t+1,  handles 40
PIMs of , while  manages the remaining 80 PIMs via
migration. Both controllers  and  are regulating the
workload of switch  currently. As a result, ’s
workload is  󰇛󰇜 󰇛󰇜 = 40 + 160 =  (200
PIMS), while ’s workload is  󰇛󰇜 󰇛󰇜 = 120
+ 80 =  (200 PIMS), indicating that neither controller
is overloaded (busy) in period t+1. Similarly, at time t+2,
 processes 80 PIMs before sending the remaining 20
PIMs to the controller subnet. The TSSM technique
can effectively overcome the controller’s ping-pong issue
using this strategy.
It provides an approach in which two controllers,
namely an overload controller (one) and a lightly loaded
controller (one), are merged and the switch is relocated
from an overloaded to a lightly loaded controller subnet
at an appropriate moment in time. When compared to
existing switch migration methods such as group-based
dynamical controller placement [10], churn-triggered
migration [30], and best-fit migration [32], the results of
this technique show that it significantly reduces overload
occurrences of controllers while effectively balancing the
workload of all controllers with improved controller
efficiency. Nonetheless, more than one lightly loaded
controller operation in the TSSM yields greater controller
efficacy than the original (i.e., stated in the research)
despite the additional switch migration cost. Furthermore,
because the migration switch is managed (i.e., controlled)
by more than one controller in the network, this technique
consumes additional controller resources during TSSM
operation.
As a result, we suggested an approach that optimizes
the lightly loaded controller selection during the TSSM
period and enables for more than one lightly loaded
controller to be used for switch migration during the
TSSM period without increasing migration cost. The
controller is chosen based on flow characteristics using a
coalitional game strategy algorithm, which decreases
controller resource consumption by lowering the number
of controllers involved in flow processing. The new
TSSM method reduces migration costs and controller
resource usage while also providing TSSM advantages.
For its feasibility, the proposed scheme is implemented
using the Open Network Operating System (ONOS),
which can respond to approximately one million flow
processing requests per second.
Figure 2. Switch transferring process in OpenFlow Protocol.
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
848

In summary, Software-Defined Networking (SDN)
leads to an efficient administration process in network
management through easy updating of network policies
and the latest algorithms. Typically, distributed SDN is
adopted in network management, considering bottleneck
issues. Load balancing is a critical factor in the SDN, and
it can be managed through (i) the dynamic controller
placement method, (ii) switch migration, (iii) the flow
splitting method, and (iv) the flow migration method.
Considering the practical viability of Open Flow, a switch
cannot be controlled by more than one controller
simultaneously, considering synchronization and complex
design. Therefore, flow migration and flow splitting
methods are non-compliant with the OpenFlow protocol
and cannot be implemented on the real-time controller
platform. Considering the OpenFlow protocol and its
implementation in the real-time controller platform, the
dynamic controller placement method with switch
migration is a better solution for load balancing.
The conventional switch migration methods suffer
from ping-pong difficulty during the switch migration
process because the whole single switch is migrated in
the beginning period. It causes instability issues in the
switch migration. The ping-pong difficulty is rectified by
a time-sharing switch migration scheme. This method
significantly reduces the overload occurrences of the
controller, which leads to better load balancing. However,
the selection of controllers during the TSSM period is
random. So that it could increase the switch migration
cost and higher controller resource consumption during
TSSM operation since the migration switch is managed
by more than one controller in the network. Therefore,
our paper has proposed an improved TSSM scheme, and
it has the following merits: (i) It contains all the merits of
a conventional TSSM scheme, including the removal of
ping-pong controller action during the switch migration
process, a reduction in controller overload occurrences,
and better controller efficiency, (ii) The selection of
controllers during TSSM is specified and optimized
through the coalitional game strategy, which reduces the
switch migration cost and controller resource
consumption, (iii) It provides better controller efficiency
and load balancing compared with the conventional
TSSM scheme.
III. DISTRIBUTED SDN CONTROLLER
This section discusses the architecture of the
distributed SDN control network, the switch transfer
mechanism in the OpenFlow protocol, and network
models.
A. Distributed SDN Control Network Architecture
In a distributed SDN control network, two popular
control methods are commonly used: (i) hierarchical
control and (ii) flat control, also known as circular chain
control [8]. In the hierarchical technique, the central
distributed controller (called the leader) has a global
perspective of the network and updates network
regulations and newest algorithms to the sub controllers,
as illustrated in Fig. 1(a). The sub controller controls
(oversees) the subnet of its switches and transmits its
status to the leader. It should be emphasized that if the
original leader is broken down in the hierarchical
technique, a new leader will be chosen [15]. In the case of
circular chain control, controllers have information about
the network’s local perspective and authority over its own
subnet. The associated controllers exchange information
in a distributed fashion, as shown in Fig. 1(b).
In this article, the hierarchical technique is used to
implement the suggested switch migration methodology.
The leader oversees monitoring the condition of each sub
controller and implementing the TSSM scheme to pick
the lightly loaded controller over the overloaded
controller during flow variations, flow traffic, impulses,
distributed denial of service, and so on. Following that,
two sub controllers (overloaded and lightly loaded) are
committed to sharing workloads and migrating the switch
as needed.
To avoid undesired switch migrations, the threshold
level of the sub controller is likewise established in the
leader. When the workload of the controller exceeds the
controller’s threshold level, it is deemed overloaded, and
it is selected based on the controller’s maximum capacity
and reserve capacity. Generally, network administrators
recommend that the threshold level be set between 90%
and 95% of the full capacity. The controller’s threshold
level is also stated as its maximum workload, and it is
specified in Eq. (1).
   (1)
 
 
 
B. Switch Transfer Process in Openflow
OpenFlow allows switch transfers between subnets and
establishes connections with many controllers. Each
related controller  determines the following duties from
the perspective of switch .
• OFPCR_ROLE_EQUAL (Equal): This default
role grants controller  complete authority to
switch  and allows  to send commands to 
and receive status information. Similarly, when
 is operating in this capacity, all controllers
have complete access to it.
• OFPCR_ROLE_SLAVE (Slave): When the
controller  role is set to slave,  can only
read the state of switch .
• OFPCR ROLE MASTER (Master): It is similar
to an equal role, and controller  has full power
over . It is insisted, however, that only one
controller (e.g., ) is considered a master
controller for a switch , and all other
controllers are considered slaves to switch .
The OpenFlow protocol defines the switching process,
which is seen in Fig. 2. The master controller initiates the
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
849

switch transferring operation since it has complete control
over the switch. For example, controllers  and  are
the master and targeted (slave) controllers for the switch
, respectively. It is insisted that overloaded controllers
use leader to move a switch to other controllers for
workload balance (controller). After receiving a directive
from the leader, the master controller ( ) sends a
transferring request for switch  to the targeted
controller . Following that, controller  requests that
the switch  alter the role of  control to master rather
than slave using the Role Request (Master) message, and
the switch  responds to  with the Role Reply
message (Master). After all,  sends a notification
message to  indicating the successful migration of
switch , and controller  subsequently operates as a
slave controller for switch .
OpenFlow protocol versions 1.2, 1.3, 1.4, and 1.5
enable switch migration (most recent version). It has been
discovered that OpenFlow regulation simply instructs
how to modify (migrate) the switches between controllers
for their tasks and exchange messages between
controllers. However, OpenFlow does not specify how to
choose target controllers and switches for migration. The
proposed enhanced TSSM method optimises controller
selection and determines when switch migration should
occur during the TSSM period.
C. Network Modelling
Let us imagine an SDN-based network with a
collection  of switches and a collection  of
controllers. A switch (e.g., ) in  is controllable by a
controller in  (e.g., ) with the model of one switch is
controlled by a controller concurrently advocated by
OpenFlow, i.e.,  acts as a master controller for  and
may be altered after the switch migration.
Packet In messages (PIMs) sent from switches
determine each controller’s workload. Switch workload
(󰇛󰇜) is calculated specifically by the number of PIMs
created by a switch during each period “t”. Following that,
controller workload capacity is defined as the maximum
number of PIMS that may be processed in each period.
For example, if controller  manages switches  to ,
the workload of controller  is determined as follows:
󰇛󰇜

 (2)
In general, the controller’s maximum workload ()
should be smaller than its maximum capacity ( ),
considering the need for reserve load under unwanted
scenarios such as flow fluctuation, sudden demand, and
so on. Hierarchical control of DSC architecture is studied
in this study; hence, the leader receives workload from all
controllers at each period and directs switch migration
across controllers, as necessary.
IV. PROPOSED SWITCH MIGRATION SCHEME
The controller placement technique or network
operators are used to set the network switches at the first
stage, with each switch managed by a master controller.
As described in the preceding section, conventional
switch migration methods include migrating a switch at
the start of the period as well as migrating the entire
switch even if it is not necessary. As a result, the link
between controllers and switches remains constant during
whole period.
Algorithms
Process
1
It is used to locate the overloaded and lightly loaded controllers in the SDN domain.
2
Initially, it is sorting the overloaded and lightly loaded controllers based on their overloading and PIMS accessibility. After
that, it performs the whole switch migration from overloaded controllers to lightly loaded controllers.
3
It achieves optimized controller selection based on flow path through a Coalitional game strategy for the TSSM operation.
4
It performs the TSSM operation and achieves better load balancing.
Figure 3. Relationship among algorithms used in the improved TSSM scheme.
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
850

In the case of TSSM, switch migration is enabled via
time-sharing, and switches in the network can
dynamically change their connections with the controller
at any moment. Furthermore, as mentioned in Section II,
the TSSM approach efficiently overcomes the controller
ping-pong challenge. Nonetheless, controller resource
consumption is greater during the TSSM time, which may
raise the method’s migration cost when compared to
other migration techniques since it allows more than one
controller to share their (switch) loads during the TSSM
period. It is discovered that migration costs are
approximated based on the number of controllers and
switches used. As a result, this research suggested an
approach that greatly decreased the number of controllers
associated with switches during time sharing migration
depending on flow characteristics. We developed a
coalitional game strategy to establish the best possible
connection between switches and controllers during the
time-sharing migration phase, reducing the number of
controllers connected with the switch and, as a result,
controller resource consumption and migration cost are
reduced. The algorithms listed below are intended to
ensure the effective completion of the proposed switch
migration method and Fig. 3 briefs their relationships.
A. Algorithm 1: Identifying Overloaded and
LightlyLoaded Controllers
This algorithm ensures that all overloaded (referred to
as busy) and lightly loaded controllers (referred to as
assistant or target controllers) in the given network are
found, as represented by  and  , respectively.
The burden of each controller (e.g., ) is evaluated
using Eq. (2) by adding the loads of each switch in the
subnet (e.g., 
󰇛󰇜  
󰇛󰇜   ) and is specified in the
method code between 3 and 5 lines. Following that, the
controller workload (e.g., ) is compared to the
threshold level ( ), and if it is more than the threshold
level, the controller is deemed overloaded and included in
the overload controllers (described in lines 6–7) unit in
the leader. Then, in line 8, lightly loaded controllers are
chosen based on a lightly loaded coefficient ´´, with a
value between 0.8 and 0.85 (specified by network
managers). Following that, the lightly loaded coefficient
is multiplied by the threshold value, and if the workload
of the controllers is less than the multiply value, it is
regarded a lightly loaded controller and is added to the
leader’s lightly loaded controller unit. It is required that
switch migration take place when both the  and
 controllers are not empty, as shown in line 10.
Algorithm 1: Identifying Overloaded and Lightly Loaded Controllers
1
 ← ø and ← ø ;
2
foreach ϵ do
3
 ← 0 ;
4
foreach ϵ do
5
←  + 
󰇛󰇜 ;
6
if > then
7
 ← U { } ;
8
else if < × then
9
← U { } ;
10
If   ø and   ø then
11
Use Algorithm 2 for load balancing between  and ;
Algorithm 2: Switch Migration Segment for Load Balancing
1
SORT ( ,  );
2
SORT (,   );
3
foreach ϵ do
4
SORT (, 
󰇛󰇜);
5
while>do
6
if= ø then
7
Cease this module;
8
Pick the optimized controllers [, ,...]from ;
9
(Controller-Switch Association Matrix) ← Algorithm 3 (Request PIM´s of Switch, Switches from )
10
(, [ ,  , …] , 󰇟  󰇠) ← Algorithm 4 ( , [, ,...]) ;
11
Transfer  to [, ,...]’s subnet after [ ,  , …] units of time;
12
 ← 󰇟  󰇠;
13
 ←   󰇟   󰇠 ;
 ←   󰇟   󰇠 ;
14
if󰇟󰇠   × 󰇟 󰇠 then
15
← , [, ,...];
16
else
17
SORT (,   );
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
851

Algorithm 3: Selection of Optimised Controller for TSSM Scheme
1
Input: Organised light and busy controllers ={}, {} obtained from Algorithm 2;
2
SORT ( 
󰇛󰇜, 
󰇛󰇜 
󰇛󰇜 );
3
Capacity and redundant load for each controller under a leader
4
Traffic Matrix:  = []
5
Initialization: = [],  = [
], 
6
repeat
7
Every switch performs its most desired migration.
8
Initial migration pair :  ;
9
for all controllers do:
10
if:  ; and      : satisfy migration does not violate capacity constraint.
11
if migration value (, )  0: consider a weight factor between control resource consumption and control traffic
overhead.
12
Implement switch migration selection  
13
Update  = [
];
14
end if
15
end if
16
end for
17
Until no proposals have been made by the switches
Algorithm 4: Time to Switch Migration Estimating Segment
1
  min ( ) &   max (  ) ;
2

  and 
  ;
3
foreach ϵ do
4
if 
󰇛󰇜     then
5

 
 { };
6
else
7

 
 { };
8
if
 then
9
the last switch of 
 ;
10
     󰇛󰇜 ;
11
else
12
the first switch of 
;
13
   then   
󰇛󰇜
14

󰇛󰇜  
󰇛󰇜 –  and 
󰇛󰇜  
15
return (,   );
B. Algorithm 2:Ordering the Overloaded and Assisting
Controllers, as Well as Switch Migration
This algorithm goal is to distribute workload across
controllers by identifying a pair of overloaded and lightly
burdened controllers. The SORT function aids in the
organization of overloaded and lightly loaded controllers
in decreasing workload order. Line 1 of the code sorts the
overload controllers, whereas line 2 sorts of the
information about the lightly loaded controller. As a
result, a controller with very excess capacity will be
prioritized in contributing to the task of an overloaded
(busy) controller. The code in lines 3–17 tackles each
controller in the network using a for-loop, from the most
overloaded to the least overloaded. Line 4 arranges the
switches under  management in decreasing order based
on their workload. The while loop on lines 5–16
continues to reduce the burden of the  by moving a
switch until it reaches the threshold workload. However,
if there is no assistant controller to assist (i.e.,  is
empty) and there are still overloaded controllers in the
domain, Algorithm 2 ends as shown in lines 6–7.
Otherwise, if we wish to pick a lightly loaded controller
 for workload sharing, the time-sharing switch
migration technique must be enabled. Initially, Algorithm
3 is used to determine the best controllers [, ,...]
for TSSM in terms of controller resource usage and
migration cost. Following the discovery of the optimal
controllers, the TSSM scheme based on Algorithm 4 is
run. As seen in line 10, the result of Algorithm 4 gives
three output parameters. In which “” specifies the time
switch  should migrate to other controllers, whilst “”
specifies the number of PIMs to be migrated to each
controller. Following that, workload updates of  and
[, ,...] are performed in lines 11 to 13, and if [,
,...] exceeds the threshold level, these controllers are
removed from the lightly loaded controllers as shown in
line 14, otherwise these controllers are returned to the
lightly loaded controller unit as shown in lines 17 and 2.
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
852

C. Algorithm 3: Optimization of the Controller for the
TSSM Scheme to Save Migration Cost
This algorithm’s goal is to produce efficient controllers
for TSSM operation. The optimized controller is chosen
based on flow characteristics to decrease controller
resource usage and, as a result, switch migration cost.
The coalitional game strategy [37] is used for optimal
controller selection and is shown in Algorithm 3. This
algorithm requires the PIMs of each switch in the
overloaded controller , as well as the controller’s
threshold level, network topology map, and so on.
Between lines 3 and 12, the flow sort function evaluates
the total quantity of flow in each path and sorts it in
ascending order. Lines 4–6 execute and choose a
controller that covers most of the switches in the route.
D. Algorithm 4: Time to Switch Migration Estimating
Segment
After defining the best lightly loaded controllers (,
 ,...) using Algorithm 3, they are paired with an
overloaded controller to accomplish three tasks using
Algorithm 4. The tasks are as follows: (i) choose a switch
(from an overloaded controller) to share their burden with
lightly loaded controllers, (ii) compute the switch
migration time (), and (iii) calculate the number of PIMs
() that lighter loaded controllers will process. Line 1 of
Algorithm 4 is executed, with “” representing the
remaining capacity of the lightly loaded controllers and
“” representing the lowest amount of overload in the
overloaded controllers. Following that, switches in the
overloaded controllers are divided into two subnets, 

and 
, respectively; if the switch load is greater than
“”, it is sorted in 
 with decreasing load order, and 

includes remaining switches in the overloaded controllers;
respecting codes are given in lines 2–7. In order to reduce
the number of migrations (executed in lines 8–9),
switches near “” (might be the very last switch in 

based on load sorting order) are selected in the 
 subnet
for migration. This is because a minimal amount of
overload in the overloaded controllers can easily be
placed in the lightly loaded controllers. The estimated
switch migration time is determined by the number of
PIMs generated in the switch, the  in the optimum
lightly loaded controllers, and the  in the switch. For
example, if  is half the value and the rate of
PIMs created is constant, the switch migration time is
expected to be half the period duration provided in
Eq. (3). If   , switch migration happens at the start of
the period, as shown in line 13. Furthermore, once the
switches in the 
 subnet are empty, the 
 subnet is
evaluated for better load balancing even though it is not
overloaded, as seen in lines 11 and 12. This procedure
will be continued until all the controllers are load
balanced for each switch in the time-sharing scheme
using optimum controller finding (Algorithm 3) and then
returned to Algorithm 2.
V. EVALUATION AND ANALYSIS
The proposed switch migration strategy’s performance
is tested using time domain simulation analysis. As
illustrated in Fig. 4, the ONOS platform is used as the test
platform, and a hierarchical DSC design is used for the
experimental network, which contains 7 controllers and
24 switches. As a result, one controller acts as a leader,
and its major purpose is to oversee the other six
controllers in the network; however, it is not involved in
switch management; the secondary six controllers operate
their switches in their subnet. This test platform considers
simulation duration to be 250 seconds divided into 50
phases. Each secondary controller has a PIMs processing
capacity of 800,000 PIMs every 5 second interval.
Furthermore, the barrier for each controller is set at
640,000 PIMs every period. As a result, the overall
controller affordable load is estimated to be 3.84 106
PIMs each period. The switches loads are divided into
three levels: (i) light load, (ii) medium load, and (iii) big
load. Each switch generates roughly 17,000 PIMs per
second under mild load, whereas a switch producing
33,500 PIMs per second is considered medium load.
However, if a switch generates more than 51,000 PIMs
per second, it is considered a big load. If all switches are
lightly loaded, the overall controller affordable load is 2
106 PIMs per period, which is approximately 48% of
the total controller affordable load. However, if all
switches are deemed heavy loads, the overall load is 6.01
106 PIMs per period, which is significantly greater than
the total controller affordable load.
(a) network topology at “0” second
(b) network topology at 16th second
Figure 4. Network topology used in the simulation test platform.
As a result, in this simulation research, the simulation
begins with a minimal load in all switches, and the load is
randomly raised in the switches using the cbench tool as
simulation duration advances, to evaluate the
performance of the switch migration approach. For
example, at the 16th second time, ten switches (S1, S3,
S4, S6, S7, S8, S9, S10, S22, S23,) are creating about
17,000 PIMS/s, eight switches (S2, S5, S11, S12, S15,
S18, S21, S24,) are generating 33,500 PIMs/s, and the
remaining switches (S13, S14, S16, S17, S19, S20) are
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
853

carrying 51,000 PIMs/s, As a result, the total controller
workload is 3.772 106 PIMs each period, and switch
migration must occur using both the traditional (full
switch) and TSSM schemes. Three examples are studied
for assessing the performance of the suggested method:
(i) work loads of controllers, (ii) overload events, and
(iii) controller resource consumption.
A. Test 1: Workload of Controllers
As previously stated, each controller may process up to
640,000 PIMs every period, and if the controller has
processed more than 128,000 PIMs/s, it is deemed
overloaded. Two standards approach, (i) OpenFlow, and
(ii) TSSM schemes, are studied in this test, and their test
results are compared with the proposed method for
assessing performance.
(a)
(b)
(c)
Figure 5. Comparison of workload of controllers: (a) OpenFlow method,
(b) Conventional TSSM, (c) Proposed method.
Because switch migration is not done in the OpenFlow
technique, controllers C4, and C5 are significantly
overloaded, as seen in Fig. 5(a), based on PIMs generated
in the switches. During this time, controllers C4 and C5
must handle about 932,000 PIMs every period, which
exceeds their maximum capacity (800,000 PIMs per
period) and causes unforeseen challenges in the
networking domain. In the case of the TSSM scheme, it
distributes workload across controllers via time sharing
migration and ensures that all controllers are under their
threshold limits, as illustrated in Fig. 5(b). Furthermore,
the Ping-Pong problem (no high leaps, and often
transmitted switches are treated as nil) is not detected in
the test results. The suggested switch migration scheme’s
test results are shown in Fig. 5(c). When compared to the
TSSM scheme, load sharing between controllers is
substantially flatter (i.e., almost all controllers are sharing
around similar load, which improves efficiency and
reduces downtime or maintenance activities).
B. Test 2: Number of Overload Occurrences
This test is important for determining the performance
of the switch migration technique by evaluating the
number of overload occurrences for the controllers for the
whole duration (250S). Fig. 6 shows a comparison of
overload occurrence for all three approaches. It
demonstrates that the OpenFlow method provides a high
number of over-load occurrences because there is number
of switch migration action, and thus controllers C1, C2,
C3, and C6 are in the lightly loaded range, whereas C4,
and C5 are highly loaded, and these controllers are
completely overloaded during the given period.
Figure 6. Comparison of number of overload occurrences in
conventional and proposed method.
In the case of TSSM, it has considerably decreased the
number of overload events for the controller since it
avoids the ping-pong problem and so switches that are
repeatedly moved are ignored. When compared to the
TSSM system, the proposed method reduces the amount
of overload incidents even more. During time sharing
migration, the suggested technique employs more than
one optimal controller as a lightly loaded controller,
which may minimize the frequency of overload events.
Because, in the conventional TSSM method, if one
controller is not sufficient to share the load of the switch
(this controller may be considered initially as excess in
this situation), then it is necessary to find another
controller for switch sharing. This may occur when the
requirement of load sharing is high in the over-loaded
controller and lightly loaded single converters are
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
854

insufficient to handle this load. The proposed strategy, on
the other hand, selects more optimal controllers based on
load sharing and minimizes unnecessary processing and
overload situations.
C. Test 3: Controller Resource Consumption
This test could be utilized to determine the migration
cost of switch migration techniques based on controller
resource usage. Controller resource consumption
describes how many controllers and switches are used. It
should be noted that minimizing the number of
controllers associated with the switches minimizes the
network’s switch migration cost. Because OpenFlow is
not conducted during the switch migration event, it is
excluded from this assessment research. When compared
to alternative switch migration methods, the standard
TSSM has a lower migration cost. However, it is greater
when compared to the proposed switch migration
technique since the proposed approach selects the
appropriate controllers for workload sharing based on
flow characteristics, which minimizes controller resource
consumption and switch migration cost. Fig. 7 depicts the
control resource usage of the switch migration strategy.
When compared to the conventional TSSM system, the
suggested switch migration approach saves
approximately 18% on switch migration costs. The
overall effectiveness of the proposed method with
existing methods is given in Table I.
Figure 7. Comparison of controller resource consumption between
TSSM and proposed switch migration method.
TABLE I. COMPARISON OF THE EFFECTIVENESS OF THE PROPOSED
METHOD WITH EXISTING METHODS
Ref.
Load
balancing
Strategy
OpenFlow
Complaint
Time
Sharing
Controller
Ping-
pong
difficulty
Switch
Migration
Cost
[22]
Switch
Migration
Yes
No
Yes
High
[24]
Switch
Migration
Yes
No
Yes
High
[25]
Switch
Migration
Yes
No
Yes
Medium
[35]
Switch
Migration
Yes
Yes
No
Medium
Proposed
Method
Switch
Migration
Yes
Yes
No
Low
VI. CONCLUSION
This research offered an enhanced TSSM methodology
that addresses the issue of higher switch migration cost in
the standard TSSM method by locating several optimum
target controllers throughout the time-sharing period. It
used flow characteristics to determine the best controllers
using a coalitional game strategy method. Furthermore,
the suggested switch migration strategy provides TSSM
benefits that have overcome the ping-pong controller
challenge. The ONOS platform was used to evaluate the
performance of this study, and it was discovered that the
modified TSSM scheme outperformed the standard
TSSM approach in terms of controller workload sharing,
number of overload events, and controller resource
consumption. When compared to the typical TSSM, it
decreases controller resource use by 18%.
CONFLICT OF INTEREST
The authors declare no conflict of interest.
AUTHOR CONTRIBUTIONS
Thangaraj Ethilu: data collection, implementation, and
making output. Abrami Sathappan: supervision of the
project work. Paul Rodrigues: proofreading of the paper.
All authors had approved the final version.
REFERENCES
[1] N. Anerousis, P. Chemouil, A. A. Lazar, N. Mihai, and S. B.
Weinstein, “The origin and evolution of open programmable
networks and SDN,” IEEE Commun. Surveys Tuts., vol. 23, no. 3,
pp. 1956–1971, 2021.
[2] Y.-C. Wang and H. Hu, “An adaptive broadcast and multicast
traffic cutting framework to improve Ethernet efficiency by SDN,”
J. Inf. Sci Eng., vol. 35, no. 2, pp. 375–392, 2019.
[3] M. Alsaeedi, M. M. Mohamad, and A. A. Al-Roubaiey, “Toward
adaptive and scalable OpenFlow-SDN flow control: A survey,”
IEEE Access, vol. 7, pp. 107346–107379, 2019.
[4] J. H. Cox, R. Clark, and H. Owen, “Leveraging SDN and
WebRTC for rogue access point security,” IEEE Trans. Netw.
Service Manag., vol. 14, no. 3, pp. 756–770, Sep. 2017.
[5] Y.-C. Wang and S.-Y. You, “An efficient route management
framework for load balance and overhead reduction in SDN-based
data center networks,” IEEE Trans. Netw. Service Manag., vol. 15,
no. 4, pp. 1422–1434, Dec. 2018.
[6] W. Iqbal, et al., “ALAM: Anonymous lightweight authentication
mechnism for SDN-enabled smart homes,” IEEE Internet Things
J., vol. 8, no. 12, pp. 9622–9633, Jun. 2021.
[7] Y.-C. Wang and R.-X. Ye, “Credibility-based countermeasure
against slow HTTP DoS attacks by using SDN,” in Proc. IEEE
Annu. Comput. Commun. Workshop Conf., 2021, pp. 890–895.
[8] F. Bannour, S. Souihi, and A. Mellouk, “Distributed SDN control:
Survey, taxonomy, and challenges,” IEEE Commun. Surveys Tuts.,
vol. 20, no. 1, pp. 333–354, 2018.
[9] J. Lu, Z. Zhang, T. Hu, P. Yi, and J. Lan, “A survey of controller
placement problem in software-defined networking,” IEEE Access,
vol. 7, pp. 24290–24307, 2019.
[10] H. Sufiev, Y. Haddad, L. Barenboim, and J. Soler, “Dynamic SDN
controller load balancing,” Future Internet, vol. 11, no. 3, pp. 1–
21, 2019.
[11] Y. Wu, S. Zhou, Y. Wei, and S. Leng, “Deep reinforcement
learning for controller placement in software defined network,” in
Proc. IEEE INFOCOM Workshop, Toronto, ON, Canada, 2020,
pp. 1254–1259.
[12] Y.-C. Wang and Y.-C. Wang, “Efficient and low-cost defense
against distributed denial-of-service attacks in SDN-based
networks,” Int. J. Commun. Syst., vol. 33, no. 14, pp. 1–24, 2020.
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
855

[13] F. Tang, H. Zhang, L. T. Yang, and L. Chen, “Elephant flow
detection and load-balanced routing with efficient sampling and
classification,” IEEE Trans. Cloud Comput., vol. 9, no. 3, pp.
1022–1036, Jul.–Sep. 2021.
[14] Y.-C. Chan, K. Wang, and Y.-H. Hsu, “Fast controller failover for
multidomain software-defined networks,” in Proc. Eur. Conf.
Netw. Commun., Paris, France, 2015, pp. 370–374.
[15] W. H. F. Aly, “Controller adaptive load balancing for SDN
networks,” in Proc. Int. Conf. Ubiquitous Future Netw., Zagreb,
Croatia, 2019, pp. 514–519.
[16] T. Hu, J. Zhang, L. Cao, and J. Gao, “A reliable controller
deployment strategy based on network condition evaluation in
SDN,” in Proc. IEEE Int. Conf. Softw. Eng. Serv. Sci., Beijing,
China, 2017, pp. 367–370.
[17] T. Kim, J. Myung, and S.-E. Yoo, “Load balancing of distributed
datastore in Open Daylight controller cluster,” IEEE Trans. Netw.
Service Manag., vol. 16, no. 1, pp. 72–83, Mar. 2019.
[18] Y.-C. Wang and E.-J. Chang, “Cooperative flow management in
multidomain SDN-based networks with multiple controllers,” in
Proc. IEEE Int. Conf. Smart Commun. Improving Qual. Life Using
ICT IoT AI, Charlotte, NC, USA, 2020, pp. 82–86.
[19] S. Nithya, M. Sangeetha, K. N. A. Prethi, K. S. Sahoo, S. K.
Panda, and A. H. Gandomi, “SDCF: A software-defined cyber
foraging framework for cloudlet environment,” IEEE Trans. Netw.
Service Manag., vol. 17, no. 4, pp. 2423–2435, Dec. 2020.
[20] K. S. Sahoo, P. Mishra, M. Tiwary, S. Ramasubbareddy, B.
Balusamy, and A. H. Gandomi, “Improving end-users’ utility in
software-defined wide area network systems,” IEEE Trans. Netw.
Service Manag., vol. 17, no. 2, pp. 696–707, Jun. 2020.
[21] A. Dixit, F. Hao, S. Mukherjee, T. V. Lakshman, and R. Kompella,
“Towards an elastic distributed SDN controller,” ACM SIGCOMM
Comput. Commun. Rev., vol. 43, no. 4, pp. 7–12, 2013.
[22] Z. Min, Q. Hua, and Z. Jihong, “Dynamic switch migration
algorithm with q-learning towards scalable SDN control plane,” in
Proc. Int. Conf. Wireless Commun. Signal Process., Nanjing,
China, 2017, pp. 1–4.
[23] J. Cui, Q. Lu, H. Zhong, M. Tian, and L. Liu, “SMCLBRT: A
novel load-balancing strategy of multiple SDN controllers based
on response time,” in Proc. IEEE Int. Conf. High Perform.
Comput. Commun., Exeter, U.K., 2018, pp. 541–546.
[24] K. S. Sahoo, et al., “ESMLB: Efficient switch migration-based
load balancing for multi-controller SDN in IoT,” IEEE Internet
Things J., vol. 7, no. 7, pp. 5852–5860, Jul. 2020.
[25] T. Hu, J. Lan, J. Zhang, and W. Zhao, “EASM: Efficiency-aware
switch migration for balancing controller loads in software-
defined networking,” Peer-to-Peer Netw. Appl., vol. 12, pp. 452–
464, Mar. 2019.
[26] Y. Hu, W. Wang, X. Gong, X. Que, and S. Cheng, “BalanceFlow:
Controller load balancing for OpenFlow networks,” in Proc. IEEE
Int. Conf. Cloud Comput. Intell. Syst., Hangzhou, China, 2012, pp.
780–785.
[27] W. Lan, F. Li, X. Liu, and Y. Qiu, “A dynamic load balancing
mechanism for distributed controllers in software-defined
networking,” in Proc. Int. Conf. Meas. Technol. Mechatronics
Autom., Changsha, China, 2018, pp. 259–262.
[28] Maity, S. Misra, and C. Mandal, “Traffic-aware consistent flow
migration in SDN,”in Proc. 2020 IEEE International Conference
on Communications (ICC), 2020, pp. 1–6.
[29] Maity, S. Misra and C. Mandal, “DART: Data plane load
reduction for traffic flow migration in SDN,” in IEEE
Transactions on Communications, vol. 69, no. 3, pp. 1765–1774,
March 2021, doi: 10.1109/TCOMM.2020.3042271.
[30] B. Gorkemli, S. Tatlcıoglu, A. M. Tekalp, S. Civanlar, and E.
Lokman, “Dynamic control plane for SDN at scale,” IEEE J. Sel.
Areas Commun., vol. 36, no. 12, pp. 2688–2701, Dec. 2018.
[31] G. Cheng and H. Chen, “Game model for switch migrations in
software defined network,” Electron. Lett., vol. 50, no. 23, pp.
1699–1700, 2014.
[32] T. Vikas and S. Samayveer, “A novel energy efficient routing
technique for SDN-enabled underwater WSNs using free-space
optical communication,” Journal of Optical Communications, pp.
1–8, 2022.
[33] L. Chen, F. Tang, and X. Li, “Mobility-and load-adaptive
controller placement and assignment in LEO satellite networks,”
in Proc. the IEEE Conference on Computer Communications, pp.
1–10,2021.
[34] X. Zhang, et al., “Dynamical controller placement among SDN
space-terrestrial integrated networks,” in Proc. the IEEE 22nd
International Conference on High Performance Computing and
Communications, 2020, pp. 352–359.
[35] L. Chen, et al., “Dynamical control domain division for software-
defined satellite-ground integrated vehicular networks,” IEEE
Transaction on Network Science and Engineering, vol. 8, no.4,
2021, pp. 2732–2741.
[36] W.-K. Lai, Y.-C. Wang, Y.-C. Chen, and Z.-T. Tsai, “TSSM:
Time-sharing switch migration to balance loads of distributed
SDN controllers,” IEEE Trans. Network and Service Management,
vol. 19, no. 2, pp. 1585–1597, June 2022.
[37] Y. Zhang, Y. Ran, and Z. Zhang, “A simple approximation
algorithm for minimum weight partial connected set cover,” J.
Combinat. Optim., vol. 34, no. 3, pp. 956–963, 2017.
Copyright © 2023 by the authors. This is an open access article
distributed under the Creative Commons Attribution License (CC BY-
NC-ND 4.0), which permits use, distribution and reproduction in any
medium, provided that the article is properly cited, the use is non-
commercial and no modifications or adaptations are made.
Journal of Advances in Information Technology, Vol. 14, No. 4, 2023
856