2016 8th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)
Analytical Model for Software Defined Network
Delay Estimation
Pavel Abaev, Vitalii Beschastnyi, Alexei Tsarev, Sergey Fedorov
RUDN University
Miklukho-Maklaya 6
117198 Moscow, Russia
{pabaev, vbeschastny, atsarev}@sci.pfu.edu.ru, fyodor-on@mail.ru
Abstract— Traditional IP networks are becoming more
complex to satisfy the demands of modern applications and it
draws communication providers to exploit a wide range of
specialized hardware. Commissioning of a new network service
implies additional room for new equipment, power sources,
cooling systems, etc. Besides, there is need for increase of
qualified stuff. This results in the escalation of capital and
operational expenses that eventually exceeds the revenue growth
rates for which these expenses are initially intended. To overcome
such a deadlock, it is no more sufficient to introduce new
protocols for network enhancement, it is necessary to reconsider
the network architecture. Software-Defined Networking (SDN) is
a new network paradigm that allows managing network services
by separating data and control planes. Herein network planning
and traffic management are performed by software what makes
installation of new network services, such as routing, resource
management and security more simple and agile. Interaction
between the two planes can be provided by means of OpenFlow
protocol that allows manipulating data plane and collecting
various statistics used to form global state of a network. In this
paper we present an overview of SDN and OpenFlow, their key
features and main concepts. Next, we present a model of SDN-
network in the form of a queuing network and propose the
approach to mean delay time estimation.
Keywords—SDN, delay, mean sojourn time, queuing network.
I. INTRODUCTION
At the present communication networks often turn to be a
limiting factor for rapid evolvement of computing
infrastructures. Traditional networks can not provide adequate
agility that is an essential property for modern business. In the
mean time it can be easily achieved by using appropriate
software in conjunction with virtualization technologies that
allow data and resource consuming applications to be
distributed across a large number of virtual machines (VM).
Optimization of server load often requires migration of VMs
leading to abrupt changes in traffic structure. Traditional
schemes for routing and logical network partitioning become
ineffective in such dynamic environments.
As an illustration of traditional networks’ limitations one
may consider installation of a new VM, where reconfiguration
of access control lists at every device in a large network may
take up to several days. The reason of such inflexibility is that
the most of available network management tools are
978-1-4673-8818-4/16/$31.00 ©2016 IEEE
device-oriented: at the best case, automatic parameter setting
can be provided for only a group of devices produced by the
same vendor. As a result, network administrators have to spend
too much time manually reconfiguring the traffic handling
rules for every single device. Similar issues appear while
reconfiguring QoSpolicies when adding a new application in
a multiservice network (e.g., conferencing). In the same
manner it takes inadmissible amount of time to update security
parameters resulting in inability to promptly counter emerging
threats.
Besides the abovementioned challenges, communication
providers even more concern about the uncertainty whether the
network devices installed today would be able to support
applications and services of tomorrow, and to what extent the
future network development would depend on product policy
of a particular vendor. The architecture of traditional network
hardware causes this dependency to be too strong to be
neglected. SDN promises to significantly weaken this
dependency and even to completely release customers from
vendor-specific technologies.
SDN, the way it was designed, will give an opportunity to
configure a large network as a single entity. Network
administrators will not have any necessity to deal with separate
devices. Control functions in SDN architecture are delegated to
controllers - the key elements of the SDN control plane.
SDNcontrollers are able to monitor global state of a network
and assign traffic handling instructions to network devices.
Furthermore, the devices are not required to support the variety
of sophisticated protocols, they only shall follow the
instructions from a respective controller, and therefore it is
possible to use simpler and less expensive equipment.
In practice, implementation of SDN concept will provide
communication providers with vendorindependent control
over the whole network from a single location allowing to
considerably simplify its maintenance and management. It will
be possible to manage network characteristics in real-time
mode reducing the time to market for new applications and
services.
IN Section II we present a survey on SDN architecture and
concepts. In Section III we propose a method of modelling
SDN network delays in the form of a queuing network.
277 ISSN: 2157-023X
 II. SDN OVERVIEW
Initially the concepts of SDN architecture and OpenFlow
protocol were proposed by a research group of Stanford
University as a testing environment for newly-emerging
networking protocols. As the construction of a new
fully-functional network would be expensive, a prototype of
SDN was set up over the available at that moment campus
identifier, TCP and UDP ports, etc. SDN-controller fills in the
tables by means of OpenFlow protocol and likewise assigns the
priority of each flow: the higher priority, the higher the
corresponding note in a flow table.
SDN Controller SDN Device

Communications
Communications
network. Soon commercial circles showed their interest in

Operating
Network
SDN since they needed high-performance infrastructures to

Control
System
Control
Flow

Net App
organize communication among hundreds of servers in giant
data centers. Traditional three-tier network architecture Tables
(access-aggregation-core) seemed too complex and excessive
as it required dozens of actions to process traffic at each node
of a network. In 2011 the six major service providers -
Deutsche Telekom, Facebook, Google, Microsoft, Verizon and
Yahoo – formed Open Networking Foundation (ONF) for Flow Table
further development of SDN technology in whole and Rule Action Stats
OpenFlow in particular. Packet+counters
The main idea of SDN is to separate the functions of traffic 1. Forward packts to port(s)
transmission and control for both traffic and transmitting 2. Encapsulate and forward to controller
devices. The control logic is moved to the so-called controllers 3. Drop packet
4. Send to normal processing pipeline
that are capable of tracking the state of the whole network
(Figure 1). SDN-controller consist of three logical parts (Figure Switch Mac Mac Eth Vlan Ip Ip TCP TCP
port src dst type id src dst psrc pdst
2): network operating system, north-bound and south-bound
APIs. Network operating system is responsible for device
discovery, application-switch interaction and other network Fig. 2. OpenFlow-enabled devices
services such as topology definition and host monitoring. At
present the most wide-spread network OSs are Nox, Pox, Packets IN are processed to find matching with the
MUL, Ruy, Beacon, OpenDaylight, Floodlight, etc. parameters inserted into a table. In case of a match,
OpenSwitch applies the action specified next to the parameters
in same note. One of typical actions is packet forwarding to
one or several OUT-Ports. Furthermore, OpenSwitch can
modify some command fields of a packet, drop or forward the
packet to the controller that will define the way the
corresponding flow will be processed and add a respective note
to a table. Traffic statistics – number of packets, bytes, etc. –
are collected in corresponding fields of a table (‘Packet+’ in
Figure 3). With the use of OpenFlow SDN-controller adds,
modifies and removes notes from the flow tables. Besides, it
can request statistics from a switch as well as to configure the
switch and its ports. In case no match is found in a table, a
‘table miss’ event occurs. This type of events is handled in a
similar way: the packet may be either forwarded to another
table or to a controller or dropped.

Fig. 1. SDN architecture

OpenFlow, as the name implies, operates on flows. The key
element of an OpenFlow switch (OpenSwicth) is flow table.
The set of columns at left of a table form the matching fields
where the main characteristics of a flow are specified
(Figure 3): they may include different parameters such as
MAC- and IP-addresses of source and destination hosts, VLAN
Fig. 3. OpenSwitch packet processing
Separation of data and control planes may be provided even
without affecting available physical network by using virtual
switches like Cisco Nexus 1000v, VMware DVS, IBM 5000v
or Open vSwitch. Programming of such switches with the help

278
of a controller allows setting up a virtual SDN over a given
physical infrastructure.
III. QUEUING NETWORK MODEL
The concurrent operations of SDN switches with diverse
control message processing capacities lead to highly variable
latencies for flow installations and modifications. To address
this issue, Bozakov et al. used a queueing model to characterize
the behavior of the control interface between the controller and
a switch in terms of the amount of serviced messages over
different time scales, and provided a measurement-based
approach to derive an estimate of the corresponding service
curves [3]. They also proposed a simple interface extension for
controller frameworks, which enables operators to configure
time delay bounds for transmitted control messages. In [4, 5],
Azodolmolky et al. presented a mathematical framework based
on network calculus to report the performance of the scalable
SDN deployments. Given the parameters of the cumulative
arriving process and the flow control functionality of the SDN
controller, the network 140 architect or designer is able to
compute an upper bound estimate of the delay and buffer
requirements of SDN controllers. Besides, Osgouei et al.
proposed an analytical performance model of virtualized SDNs
using network calculus to calculate the upper bounds of the
latency of virtualized SDN controller and the service curve of
each virtual network [6].
Closely related to our work, Jarschel et al. derived a basic
analytical model based on M | M |1 queues to estimate the
packet sojourn time and probability of lost packets for the
network scenario, where a SDN controller is responsible for
only a single OpenFlow switch in the data plane [7]. As a
further step, they addressed the challenge of the case with
multiple switches by approximating the 150 data plane as an
open Jackson network with the controller also modeled as a
M/M/1 queue [8]. Nevertheless, their model was lack of the
support of the measurements on the packet arrival process at
the switch and packet-in message arrivals at the controller.
Furthermore, Zuo et al. evaluated the queueing delay of flow
setup requests in the control plane by introducing the multiple
arrivals and single departure queue model [9], but did not reach
a precise delay estimate. Yao et al. also modeled the flow setup
requests to the controller as a batch arrival process to analyze
the controller performance with a M k | M |1 queue [10].
However, the batch arrival could not exactly characterize the
pattern of flow setup requests from multiple switches. Thus we
are motivated to build a better performance model of
OpenFlow network based on the theory of two moments [1].
As a novel network architecture, SDN enables researchers
to test new ideas under realistic conditions on an existing
network infrastructure. To be able to take action in the
switching, OpenFlow separates the control plane from the data
plane and connects them by an open interface, the OpenFlow
protocol. As for OpenFlow deployments, a typical network
scenario is depicted at Fig.4.
279
Packet-in messages SDN Controller
LAN LAN
LAN LAN Edge network
LAN
LAN
LAN
LAN
Core network
Opewflow switch
Internet
Fig. 4. OpenFlow Network Topology
As illustrated in Fig.4, the OpenFlow network can be
distinguished into the edge and the core ones. The edge
network consists of many independent LANs connecting hosts,
terminals and servers. Each LAN connects the core network via
an access switch. The core network switches packet traffic
among LANs and the Internet. To support OpenFlow, all
switches in the core network are connected to a SDN controller
directly or via other switches.
When a packet from a LAN arrives at its access switch in
the core network, the switch performs lookups in its internal
flow tables. If the lookup hits a table entry other than table-
miss, the switch will forward the packet to the next one in a
conventional way. Otherwise, the packet is supposed to belong
to a new flow. In such case, the switch requests the controller
for instructions by sending a packet-in message in
encapsulation of the packet information. The controller
determines the respective flow rule and installs it into all
switches among the flow path. After that, all packets within the
flow is correctly forwarded to their destination without
requesting the controller.
In OpenFlow networks, a SDN controller is usually
implemented as a network operation system, and responsible
for multiple OpenFlow switches. All new flows from a LAN
trigger its access switch to send a sequence of packet-in
messages to the controller. These packet-in messages from all
switches usually form up a waiting queue in the controller.
Meanwhile, each switch keeps a packet queue at each ingress
port. In consequence, we can analytically evaluate the
performance of OpenFlow networks with queueing models.
Considered network topology can be presented as a BCMP
network [2] consists of nodes of set M , M = M and has R ,
R = R customer classes circulating in it. Each customer class
corresponds to data plane message with specific QoS class or
control message. Each node is modeled in the form of a
queuing system of type GI | G |1 or IS model. A recurrent
customer flow arrives at the network nodes from external
source (node 0). Correspondence of the customer classes to the
message types is defined by correspondence matrix.
 We have named the r -class customer served in the node i
as ( i, r ) -call and denoted a set of any admissible customer 1 M
C A2 ( i ) =  λki C A2 ( k , i ), i = 1, M , (2)
types by L = {( i, r ) : i ∈ M , r ∈ R } . Customer routing can be λi k =0

described by a stochastic transition probability matrix

Θ = (θ ir , js ) , i, j ∈ M ; r , s ∈R . Customers leave the system and and the coefficient variation of the decomposition of output
flows from node i is given by
reach “sink” node. We consider that the customer changes its
class for r0 = 0 when transited to “sink” node s . Then, a set
C A2 ( i, j ) = 1 − θij + θij CD2 ( i ) , i = 1, M , j = 0, M . (3)
of all network nodes, M ′ = M  {0, s} , M ′ = M ′ . Transition
between the set L ′ = L ∪ L ′′ where L ′′ additional set due to The coefficient variation of the interdeparture time is given by
addition node 0 and node s , of customers is described by the C 2 , i is IS node,
matrix Θ ′ .  B

The intensity λir can be found from equilibrium equation CD ( i ) = C A2 ( i ) + 2 ρi2 CB2 ( i ) −
2
(4)
 2 2
λir =  λ jsθ js , ir . − ρi C A ( i ) + CB ( i )  , i is G | G |1node.
2
( j , s )∈L

The intensity of the flow to node i is denoted by By substituting (4) into (3) and then into (2) we can obtain
λi =  λir , the mean service time is denoted by μi−1 , the
r∈R M −1

mean waiting time is denoted by wi , and vi denotes the mean λi C A2 ( i ) −  λkiθ ki (1 − ρ ( k ) ) C A2 ( k ) = λ0i C A2 ( 0, i ) +
k =1
sojourn time for node i = 1, M , which satisfies the relation (5)
M −1

vi = wi + μi−1 . The average customer sojourn time can be +  λki (1 − θ ki ) + θ ki ρ ( k ) CB2 ( k )  , i = 1, M − 1,
k =1
calculated as V =  hi vi where hi is the number of node
i
entrance by customer.  λk
 , k is IS node type,
To calculate the mean waiting time wi for each node, we where ρ ( k ) =  μ k

have used the solution technique [2], where the network is 0, k is G|G|1 node.

broken up into subsystems that are analyzed in isolation as a
standalone system. This can be carried out by considering the
related input and output processes of the subsystems. We have applied an approximation Krämer/Langenbach-
Further, we have considered the network without dividing Beltz formula to calculate the mean waiting time as follows:
the messages into classes. Let λij , i = 0, M , j = 1, M be the
(
ρi c A2 ( i ) + cB2 ( i ) )⋅g
intensity of customer flow from node i to node j ; wi =
2 μi (1 − ρi )
( ρi , c A ( i ) , cB ( i ) ) ,
C A ( i, j ) , i = 0, M , j = 1, M be the coefficient of variation of

intervals between customers delivered to node j from node i ;  2 2
(
exp  − 2 (1 − ρ ) 1 − c A  , c 2 ≤ 1, )
and C A ( j ) be the coefficient of variation of intervals between    A (6)
 

3ρ c A2 + cB2 ( 

)
customers delivered to node j . The service intensity in node i g ( ρ , c A , cB ) = 
and the coefficient of variation is μi := μi1 = μi 2 = ... = μiR and   (1 − ρ ) c A − 1 
exp −
2
 2 ( )
CB ( i ) , respectively. The customers, upon completion of  , c A ≥ 1.
  c 2
+ 4c 2

  A B
service at node i with the probability θij that does not depend
on the state and prehistory of the network, instantaneously pass
to node j , i, j = 0, M . Let Θ = θij ( )i, j =0,M
be the transition IV. CONCLUSION
probability matrix. We assume that In this paper, we constructed a model of SDN network in
the form of a queuing network. The method of two moments is
used to estimate mean network delay. The approximate
λi / μi < 1, , (1)
formulas were introduced. Mean response time of SDN switch
and latency are one of the main KPI of SDN network. Obtained
and consequently, the relations λi , = λ,i and λij = λiθij are formulas provide the approach of their estimation. For further
true. study, the investigation of how many switches a controller can
The coefficient of variation of the composition of several handle without much performance penalty will be presented.
arrival processes at node i is given by The optimization problem of maximization of the number of
switches will be solved and mean delay time limitation will be

280
taken into account. The accuracy of the algorithm will be also
estimated by means of simulation.
ACKNOWLEDGMENT
The reported study was funded within the Agreement No.
02.a03.21.0008 dated 24.04.2016 between the Ministry of
Education and Science of the Russian Federation and RUDN
University.
This work was supported in part by the Russian Foundation
for Basic Research grant 15-07-03608.
REFERENCES
[1] Basharin G.P., Tolmachev A.L. Queuing Network Theory and Its
Applications to Information Computation System Analysis // Scientific
and Engineering Results. Theory of Probability. Mathematical Statistics.
Theoretical Cybernetics. –Volume 21. –1983.
[2] F. Baskett, K. M. Chandy, R. R. Muntz, F. G. Palacios. Open, Closed,
and Mixed Networks of Queues with Di erent Classes of Customers //
Journal of the ACM. — Vol. 22, No 2. — 1975. — Pp. 248–260.
[3] Bozakov Z, Rizk A. Taming SDN controllers in Heterogeneous
hardware environments. In: Proceedings of the 2nd European Workshop
on Software Defined Networks (EWSDN), 2013: 50-55.
281
[4] Azodolmolky S, Wieder P, Yahyapour R. Performance evaluation of a
scalable software-defined networking deployment. In: Proceedings of
the 2nd European Workshop on Software Defined Networks (EWSDN),
2013: 68-74.
[5] Azodolmolky S, Nejabati R, Pazouki M, Wieder P. An analytical model
for software defined networking: A network calculus-based approach.
IEEE Global Communications Conference (GLOBECOM), 2013: 1397-
1402.
[6] Osgouei A G, Koohanestani A K, Saidi H, Fanian A. Analytical
perfor¬mance model of virtualized SDNs using network calculus. In:
Proceedings of the 23rd Iranian Conference on Electrical Engineering
(ICEE), 2015: 770–774.
[7] Jarschel M, Oechsner S, Schlosser D, Pries R, Goll S, Phuoc T G.
Modeling and performance evaluation of an openflow architecture. In:
Proceedings of the 23rd International Teletraffic Congress (ITC), 2011:
1-7.
[8] Mahmood K, Chilwan A, Osterbo O, Jarschel M. Modelling of
OpenFlow-based software-defined networks: the multiple node case.
IET Networks, 2015, 4(5): 278-284.
[9] Zuo Q, Chen M, Jiang P. Delay evaluation of OpenFlow control plane
by queue model. Journal Huazhong University of Science and
Technology (Natural Science Edition), 2013, 8(1): 44-49.
[10] Yao L, Hong P, Zhou W. Evaluating the controller capacity in software
defined networking. In: Proceedings of the 23rd International
Conference on Computer Communication and Networks (ICCCN),
2014: 1-6.