Performability Evaluation of Software Defined Networking Infrastructures

Full text

Performability Evaluation of Software Defined Networking
Infrastructures
Mario Di Mauro
University of Salerno
Via Giovanni Paolo II, 132,
I-84084, Fisciano (SA), Italy
mdimauro@unisa.it
Maurizio Longo
University of Salerno
Via Giovanni Paolo II, 132,
I-84084, Fisciano (SA), Italy
longo@unisa.it
Fabio Postiglione
University of Salerno
Via Giovanni Paolo II, 132,
I-84084, Fisciano (SA), Italy
fpostiglione@unisa.it
ABSTRACT
An innovative model in traffic engineering, named Software
Defined Networking (SDN), has been recently proposed to
simplify network management and control by means of pro-
grammability concepts. This emerging strategy addresses
the recent network challenges by decoupling the packet for-
warding features, namely the data plane, from the decision
system, namely the control plane, via OpenFlow, a specific
standardized protocol. The controller element of an SDN
infrastructure represents the core entity in charge of man-
aging the whole service logic and, being this module failure-
prone, its performance and its availability are crucial issues
for an accurate plan of an SDN-based network. The ap-
proaches considering both performance and availability as-
sessment in data and telecommunication networks are fre-
quently referred to as the performability evaluations. Thus,
aperformabilityevaluationispresentedinthisworktothe
aim of selecting the most convenient redundancy scheme of
the SDN controller, where the controller has been modeled
by a finite number of virtual operator instances serving dif-
ferent network zones. By assuming that the SDN controlling
unit is described by a Continuous-Time Markov Chain with
a vector state, the availability in long runs of the SDN con-
troller in parallel redundancy configuration is computed by
an approach based on the Universal Generating Function
tailored for the vector case, and the minimal cost redundant
configuration for the SDN controller is found out.
Keywords
Software Defined Networking, Performability Evaluation, Mul-
tivariate Universal Generating Function.
1. INTRODUCTION
Recently, a ground-breaking networking model named Soft-
ware Defined Networking (SDN) has b een proposed in or-
der to decouple control protocols from network forwarding
mechanisms and thus to simplify network management and
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commerc ial advantage and that copies bear this notice and the full cita-
tion on the first page. Copyrights for components of this work owned by others than
ACM must be ho nore d. Abstr acti ng wit h cre dit is pe rmitted. To copy othe rwise, or re-
publish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
to reinforce the provisioning and configuration of telecom-
munication services. This separation addresses a new vision
of the network concepts where the switches are now assum-
ing the basic role of packet forwarding devices containing
the flow tables, a set of rules imposed by a central element
called controller acting as depository of the network intel-
ligence. In the SDN environment, a crucial role is played
by OpenFlow [14], a novel protocol aiming to enable the
communication between the control entity, named the SDN
control ler,andthedevices(switches in the SDN jargon) at
the data level.
Such a new vision, where control and forwarding entities
are strongly decoupled, allows for an extensive set of flexi-
ble network solutions. A logically centralized controller in
fact provides a unified programmable interface for software
and higher level applications deployment, by offering an ab-
straction level similar to the Operating System (OS) where,
mutatis mutandis,thecontrolleractsastheOSkernel[1].
In this paper, the authors address a performance evalua-
tion model in an SDN environment, with focus on the Con-
troller designed as an appliance hosting some (virtual) oper-
ator instances that manage a set of network devices through
the OpenFlow protocol when random failures occur.
An overview about the performance evaluation methods
for multi-state systems and the availability issues and mod-
els is offered in [12, 13], whereas an application in the context
of innovative network and telecommunication scenarios has
been presented in [8, 9].
This paper is organized as follows: in Section 2, an overview
of the SDN paradigm by describing the main features of the
proposed infrastructure is offered. Section 3 provides a vec-
tor performance model of the controller in the presence of
random failures. Section 4 introduces the Multivariate Uni-
versal Generating Function (MUGF) concept, expressly de-
signed for a multivariate environment, aiming to finding out
the minimal cost SDN configuration in terms of redundant
elements. Section 5 provides an evaluation of an exemplary
SDN scenario by applying the proposed MUGF approach
and by using realistic telecommunication data. Finally, Sec-
tion 6 concludes the paper.
2. AN OVERVIEW OF THE SOFTWARE DE-
FINED NETWORKING APPROACH
The SDN paradigm has been systematized starting from
two seminal works: the SANE Ethene project [4], and the
Routing Control Platform [3]. Basically, the SDN archi-
tecture includes a set of network entities with switching
functionalities, managed and supervised by a critical entity










SDN CONTROLLER !"#$%#&'()
*"(+#",
Application
Figure 1: An SDN architecture, Forwarding (red solid lines)
and Control (green dashed lines) planes.
named Controller through the OpenFlow protocol. The key
idea of the SDN approach relies on a network view based on
some centralized control agents devoted to elaborate rout-
ing service logic, such as access control agent, routing agent,
and trafficmanagementagent,andlight-weightednetwork
appliances (i.e. switches, firewalls, routers) designated to
communicate with the Controller and execute commands.
2.1 OpenFlow
The OpenFlow protocol, proposed and maintained by Open
Networking Forum (ONF), describes a set of specifications
that represent a standard communication interface between
data and control layers on a OpenFlow capable device.
Such a protocol allows the communication between con-
troller and SDN devices (usually named switches) by im-
plementing some messages and interoperability formats. In
particular, the standard proposes three types of messages:
Asynchronous,Controller-to-Switch and Symmetric,with
variou s su b-types. Asynchronous messages are sent by switches
to warn the SDN controller about critical events (node fail-
ures, network issues etc.). Controller-to-Switch messages
come from SDN controller and are exploited to govern or
audit the state of a single switch. Symmetric messages are
sent by switches or controller and do not need to be trig-
gered by specific events. Ultimately, OpenFlow defines the
behaviour that SDN switches should have when solicited by
the controller element; it is based on TCP and, if required,
it supports Transport Layer Security (TLS) as an asymmet-
rical encryption standard.
AsketchofanSDNarchitectureisdepictedinFigure1,
where Forwarding (or Data) and Control Planes are marked
by continuous red lines and dashed green lines, respectively.
The OpenFlow protocol acts through che control messages
exchanged between the SDN controller and the SDN devices.
On top of the controller lies an application layer offering the
possibility to extremely customize the control logic on behalf
of dedicated dashboards and command line interfaces.
Specific Application Program Interfaces (APIs) allow to
!"#$%&'()*+, -$#(./, 0#"#,
1.2/#)3 ,
-$#(./,&#.&4)&)5)$2#)+&./&#%)&6"$7)#,
08(#$%
9.3#
!-1
,3$
!-1
+,#
:#%
#;6)
<=->
?@
?9
03$
?9
@,#
?9
93.#
A19
,6.3#
A19
+6.3#
?9
A.0
Figure 2: Example of OpenFlow table with a specific flow
entry.
deploy some functionalities on board the SDN devices such
as: abstraction layers, communication interfaces to guaran-
tee an interaction with the controller, and packet-processing
engines [6]. When dealing with physical elements, the latter
feature is embodied in the hardware design logic while in
case of virtual appliances it is deployed as a software-based
agent. The abstraction layer is in charge of managing the
flow tables that, after a packet inspection operation, instruct
the SDN device to perform specific actions including packet
forwarding, packet dropping and so forth. A representation
of a flow table is offered in Figure 2, where two elements
emerge: match fields devoted to packet comparison and ac-
tions denoting the operations to perform on packets.
2.2 The core element of the architecture: SDN
Controller
As before said, the controller is responsible for remotely
managing the switch rules playing the same role of a router
that, on behalf of specific routing algorithms, is in charge of
programming and filling (or deleting) the forwarding tables.
More in details, once the controller loads a specific flow table
in an SDN switch, the latter is able to fastly manage every
packet flow that results in an exact match. On the con-
trary, when a table entry is missed, the following sequence
is activated:
1. The first un-matched packet of the flow is sent from
the switch to the controller;
2. The forwarding path for the flow is computed by the
controller;
3. The controller sends the appropriate forwarding entries
to the device by filling the corresponding flow table;
4. All ensuing packets that belong to the pertaining flow
are forwarded with no further intervention of the con-
trol plane.
OpenFlow is able to support three different configura-
tion schemes of connection between controller and switches:
Master,Slave,andEqual.Theseoperatingmodescanbe
appropriately combined in order to build certain redundant
configurations to satisfy high availability constraints and/or
implement load balancing schemes. Master and Equal schemes
allow the SDN controller to actively instruct the switch. The
main differences is that only one controller can play the Mas-
ter role, while multiple (eventually synchronized) SDN con-
trollers can be configured in Equal mode. In Slave mode,
SDN controller can just collect data for statistics but no
changes in switches configurations are p ermitted.

2.3 Related Works
An interesting work focused on a complete refactoring of
network management functionalities in a distributed envi-
ronment appears in [7]. More in details, a novel architec-
ture is proposed in which the decision logic and the pro-
tocols governing the interactions among network elements
are completely separated. Moreover, main challenges of the
SDN paradigm are identified:
•Security.ThecentralizedSDNcontrollershouldbe
adequately protected being the most sensitive element
of the entire architecture.
•Scale.SDNcontrollerisinchargeofmanagingthe
whole topological infrastructure of the network and the
computation of best routes, resulting in a scalability
problem that has to be necessarily considered.
•Latency.ThepresenceofSDNcontrollerentailsthat
some (eventually critical) decisions will be affected by
non negligible round-trip delay.
•High availability.Someredundancypolicieshavetobe
taken into account with regard to the SDN controller,
so to avoid a single-point-of-failure issue.
Awireless-basedSDNinfrastructurehasbeenpointedin
[2], where the authors discuss about the Control and Pro-
visioning of Wireless Access Points (CAPWAP), a protocol
that exploits a generic encapsulation method, making it in-
dependent of a specific radio technology. On behalf of such
aprotocol,controlframesaredeliveredtoacentralnetwork
element responsible for MAC layer control in a way similar to
the mechanisms operated by the OpenFlow protocol when
it delivers to the controller messages about new incoming
flows.
In [16], the authors propose HyperFlow,alogicallycen-
tralized and physically distributed SDN-based control plane.
The decision making logic is transferred via HyperFlow,to
individual controllers thus minimizing the response time from
the control plane.
Still based on a distributed architecture, the framework
DIFANE,presentedin[20],introducesadedicatedrouting
protocol aimed at fostering the switch interactions with no
need of controller supervision.
Another branch of works, concerns the reliability eval-
uation of SDN infrastructures by taking into account the
controller placement issue. Accordingly, in [10], the authors
introduce some placement algorithms based on a novel re-
liability metric (expected percentage of CPL - control path
loss) and find out that the simulated annealing algorithm
provides an almost optimal solution. More specifically, the
problem of placing kcontrollers among |V|locations is faced;
the proposed algorithm first produces a list of the possible
locations, say L,increasinglyrankedaccordingtoswitches
fault probabilities, and then picks one location at time from
the first w|V|(0 <w≤1) in L,indicatedasentrantloca-
tions for hosting controllers.
Afurthertrack,instead,concernstheinteractionbetween
SDN infrastructures and the virtualization concepts intro-
duced by recent NFV paradigm. In line with this latter per-
spective is the Google SDN Wireless Area Network project,
described in [11]. The key idea behind such project relates
with setting up a WAN network connecting multiple data
centers with significant bandwidth requirements governed
by an SDN-based infrastructure.
Again, a module named FlowVisor that acts as an hyper-
visor in a virtualized environment, is introduced in [15]. Ba-
sically, such a module plays the role of a transparent proxy
between OpenFlow switches and multiple OpenFlow con-
trollers.
Furt h e rmor e , t h e a uthor s i n [19] p r o p o se an an a l ytica l
performance model of OpenFlow networks based on queue-
ing theory. In particular, they model the packet forward-
ing mechanism of SDN switches and the packet-in message
processing of the SDN controller as the queueing systems
MX/M/1 and M/G/1, respectively. A queueing model of
the whole SDN networks in terms of packet forwarding per-
formance is then presented by solving its closed-form expres-
sion.
3. SDN CONTROLLER PERFORMABILITY
EVALUATION
By considering benefits and advantages a virtualized SDN-
based solution can offer (as discussed in a recent work of the
same authors [5]), we consider an architecture where a sin-
gle SDN controller hosts and manages a number of virtual
software instances as depicted in Figure 3. Each software
instance Sacts for the Master controller related to a spe-
cific provider; it is named Virtual Provider Instance (VPI)
in the SDN jargon and is in charge of managing a bunch of
OpenFlow-enabled devices. In the following, we use Siin
lieu of VPI i.Suchanapproachprovidesalotofbenefitsin
terms of managing in a ductile way the whole network in-
frastructure that can be effectively rearranged according to
the quality of service requirements of the providers, after ne-
gotiating opportune Service Level Agreements (SLAs). On
the contrary, the principal flaw concerns the possibility that
the SDN controller might become a unique point-of-failure
so that some redundancy procedures have to be established.
We model an SDN controller as formed by:
•acore part,comprisingeverykindofhardwareequip-
ment (e.g. power supply, blades, processors, memories
etc.) and generic software (e.g. hypervisor, operating
system etc.);
•asoftware part,correspondingtotheVPIs,ableto
handle a given number of sessions providing instruc-
tions to the switches.
It is worth noting that the proposed SDN controller model
is generic, but it can be adapted to describe peculiar imple-
mentations. Starting from it, we build a performance model
for the controller based on the number of coexisting Open-
Flow sessions that each (virtual) operator is able to control.
Firstly, we suppose that a single SDN controller is able to
govern kVPIs and every VPI is in charge of managing n
OpenFlow concurrent sessions. We assume also that: i) the
main elements (VPIs and core) are modelled as a two-state
system (up/down), ii) VPI iand core failures are statisti-
cally independent Homogeneous Poisson processes (HPPs),
characterized by indep endent and exponentially-distributed
inter failure arrivals and constant hazard rates λiand λc,re-
spectively, iii) repair times are independent and exponentially-
distributed with rates µsand µc,respectively.
By conveying in each state the information on the VPIs
working conditions (up/down), the model of the considered

!"#$$%&#'(&))*(
!"#$%& '%()*$+%(,-./01'23014%56)$701%5+89
:;'</2=;>2<;?4=2@A'
!"#$%&'() !"#$%&'(* !"#$%&'(!
")"*"'
Figure 3: A set of kVPIs supervised by an SDN Controller.
Tab l e 1 : Co r r e sp o ndence map b etwe en state s , V P I s c o n di-
tion and performance triples.
State number VPIs condition Performance
7(S1,S
2,S
3)(n, n, n)
6!S1,S
2,S3"(n, n, 0)
5!S1,S2,S
3"(n, 0,n)
4!S1,S
2,S
3"(0,n,n)
3!S1,S2, S3"(n, 0,0)
2!S1,S
2,S3"(0,n,0)
1!S1, S2,S
3"(0,0,n)
0!S1, S2, S3"(0,0,0)
−1(corefault) !S1,S2, S3"(0,0,0)
controller results in a multi-state Continuous-Time Markov
Chain (CTMC) where:
•2k+1 represents the total number of states. Table 1
contains information about the mapping among states
and VPIs condition/performance for the case k=3,
namely from the state −1tothestate2
k−1=7. Si
and Siindicate up and down conditions (see second
column), whereas the corresponding serving capacity
is indicated by nor 0 (see third column), respectively.
•state −1takesintoaccountthenot-workingcondi-
tion of the core component (co re f aul t )implyingthat
no VPI can be up, and corresponding to the k-tuple
!S1,...,Sk".Fromthisstate,onlyonetransitionto-
wards a completely repaired controller is presumed.
AexemplaryCTMCmodelofanSDNcontrollerwithk=
3VPIsisshowninFigure4,wherethestateprobabilities
pj(t), j=−1,0,1,..,7arederivedbysolvingthesystem
(1), with the initial conditions p7(0) = 1 and pi(0) = 0,
∀i=−1,0,...,6, representing a fully working system at the
starting time t=0.
4
7
5
6
1
2
3
0
−1
λ1µsλ3
µs
λ2µs
λ2µs
λ3
µs
λ1
µs
λ3
µs
λ1
µs
λ2µs
µs
λ3
µs
λ2
µs
λ1
λc
λc
λc
λc
λc
λc
λc
λc
µc
Figure 4: CTMC representing an SDN controller supervising
3VPIs.























































































dp7(t)
dt =µs[p4(t)+p5(t)+p6(t)] + µcp−1(t)+
−(λ1+λ2+λ3+λc)p7(t)
dp6(t)
dt =µs[p2(t)+p3(t)] + λ3p7(t)+
−(λ1+λ2+λc+µs)p6(t)
dp5(t)
dt =µs[p1(t)+p3(t)] + λ2p7(t)+
−(λ1+λ3+λc+µs)p5(t)
dp4(t)
dt =µs[p1(t)+p2(t)] + λ1p7(t)+
−(λ2+λ3+λc+µs)p4(t)
dp3(t)
dt =µsp0(t)+λ3p5(t)+λ2p6(t)+
−(λ1+λc+2µs)p3(t)
dp2(t)
dt =µsp0(t)+λ3p4(t)+λ1p6(t)+
−(λ2+λc+2µs)p2(t)
dp1(t)
dt =µsp0(t)+λ2p4(t)+λ1p5(t)+
−(λ3+λc+2µs)p3(t)
dp0(t)
dt =−(λc+3µs)p0(t)+
+λ3p1(t)+λ2p2(t)+λ1p3(t)
dp−1(t)
dt =−µcp−1(t)+λc
7
'
i=0
p(i)(t)
(1)

It is worth noting that the performance levels pertaining
to states of the proposed model of the SDN controller are
described by a vector enclosing the number of coexisting
sessions that each VPI is able to handle (see Table 1).
Since some redundancy is needed for the SDN controller
in real-case applications, the vectors of node rare in the set
g(r)={g(r)
−1,g(r)
0,...,g(r)
2k−1},(2)
where the k-dimensional vector g(r)
j=(g(r)
1,j ,...,g
(r)
k,j)con-
tains the serving capacities g(r)
i,j offered by VPI i,∀i=
1,...,k,whenSDNcontrollernoderis in the state j=
−1,0,...,2k−1. Accordingly, the vector stochastic process
G(r)(t)∈g(r)describes the performance level of node r,
∀t≥0, whose probability p(r)
j(t)=Pr{G(r)(t)=g(r)
j}is
derived by solving the system (1).
Therefore, the steady-state probabilities of the CTMC de-
scribing controller node rare:
p(r)
j=lim
t−→ ∞ Pr{G(r)(t)=g(r)
j},(3)
that can be computed by (1), with all the derivatives equal
to 0 and p(r)
j(t)replacedbyp(r)
j,alongwiththecondition:
2k−1
'
j=−1
p(r)
j=1.(4)
4. MULTIVARIATE UNIVERSAL GENER-
ATIN G F UN CT I ON F OR AVAI LA B I LI TY
EVALUATION
We start by considering the SDN controller as fully work-
ing when a needed demand (a minimal performance level
for a correct service delivery) is met, thus a demand vector
W(t)=(W1(t),...,W
k(t)) is advanced.
In many realistic deployments, for instance in order to sat-
isfy SLAs, a certain redundancy level for the SDN controller
has to be planned. In our work, we consider a Master-Slave
scheme, where replicas of a single controller (composed by
core and VPIs) are allowed: in such scenario, all VPIs as-
sociated to each domain are aligned and have all the infor-
mation about the flows traversing the switches they control.
Thus, it becomes irrelevant which is the specific VPI replica
to have managed a certain flow entry.
Besides, the SDN controller is modeled as a network node
having hparallel units without flow dispersion [12], and the
stochastic process accounting for the performance level (co-
existing OpenFlow sessions) provided to network iis the
maximum performance level offered by all the VPIs replicas
responsible of managing network domain i,viz.
Gi(t)= max
r=1,...,h G(r)
i(t),(5)
where G(r)
i(t)representstheelementiof the vector random
process G(r)(t).
For l o n g r uns (t→∞), the values of random processes
Gi(t), for i=1,...,k,canbeexpressedbyarandomvector
G=(G1,...,G
k)characterizedbyamultivariateprobability
function pG(·), represented by the steady-state distribution
pertaining to the CTMC describing the dynamic behavior of
the parallel redundancy configuration of the SDN controller.
Conforming to [12], the controller instantaneous availabil-
ity ASDN(t)representstheprobabilitythat,att>0, the
controller is in one of the possible states characterized by
aperformancelevelnotlessthandemandWi(t)foreach
network domain i=1,...,k, namely,
ASDN(t)=Pr{Gi(t)−Wi(t)≥0,∀i=1,...,k}.(6)
As t→∞,theinitialstateoftheSDNcontrollerhasno
sensible effect on its availability. If we consider one and
the same constant demand level Wi(t)=w, i =1,...,k,
the steady-state availability ASDN(w)ofthecontrollerisex-
pressed by:
ASDN(w)=*m
j=1 pG!gSDN
j"·
1!gSDN
i,j ≥w, ∀i=1,...,k
",(7)
where gSDN
jidentifies the state jof the controller with par-
allel units, whose overall model is a CTMC composed by m
states, and where 1(A)=1whentheconditionAis true, 0
otherwise.
In order to perform the availability evaluation of the SDN
controller in a parallel redundancy configuration, we exploit
the Universal Generating Function (UGF) methodology that
appeared for the first time in [17].
The UGF can be considered a kind of hierarchical ap-
proach that avoids to solve the overall CTMC model de-
scribing the performance of the whole system under anal-
ysis, whose solution is typically unfeasible due to the high
dimension of the state space. The UGF allows to combine
the performance distribution of the subsystems (much sim-
pler to be solved) composing the complex series-parallel sys-
tem, by means of some suitable operators for both parallel
and series configurations of subsystems. Further details are
available in [12].
A(discrete)randomvariableYadmits the following UGF
representation:
u(z)=
A
'
i=1
αizyi,(8)
where αi=Pr{Y=yi}and Yhas Avalues yi.TheUGF
of a random variable represents the performance levels of a
system with multiple states thus allowing availability eval-
uation. In addition, the UGF of a complex system can be
proficiently calculated by applying series and parallel oper-
ators to the UGF functions of the subsystems, according to
their logical connections.
In this work we propose an extension of classical UGF
to a multivariate case to manage performance vectors G
and G(r).SuchanextensioniscalledMultivariate UGF
(MUGF) and is defined for a vector G,havingkdimensions
and values in {g1,...,gm},bythefollowingexpression:
u(z)=
m
'
j=1
pG(gj)
k
+
i=1
zgi,j
i,(9)
where pG(·)isthemultivariateprobabilityfunctionofG,
and z=(z1,...,z
k).
Denoting by hthe number of parallel units (without flow
dispersion) that constitute the controller with performance
levels (in terms of concurrent OpenFlow sessions) governed
by (5), it is possible to express the MUGF of the SDN con-

troller via the πoperator defined as follows:
uSDN(z)='
r
pr
k
+
i=1
zgSDN
i,r
i(10)
=π(u1(z),...,u
h(z))
=
2k−1
'
j1=−1
···
2k−1
'
jh=−1
h
+
r=1
p(r)
jr
k
+
i=1
zmaxr=1,...,h g(r)
i,jr
i,
where the steady-state probabilities p(r)
jrare derived by (3),
being related to the performance levels vector g(r)
jrin (2).
The SDN controller steady-state availability is obtained by
(7), by using prand gSDN
i,r derived from the MUGF (10).
The final objective is to compute the minimal number of
SDN controller units h∗in parallel redundancy configuration
so that a given steady-state availability level A0is reached,
that is provided by:
h∗= arg min
h∈N(ASDN(w, h)≥A0).(11)
The problem in (11) is a simple version of ”redundancy
optimization problem” [18].
5. A NUMERICAL EXPERIMENT
In the present section, we provide a numerical example
of the proposed methodological approach. We assume one
and the same serving capacity of n= 5000 sessions per time
unit (stu) for all the three VPIs (k= 3). We assume also the
same SLAs for every Service Provider, so the same number of
coexisting sessions are to be handled by the SDN controller
for each VPI, and we require a pretty high service level to
consider available a VPI: we choose w=4800stu.
To the aim of accou n t ing for a plau s i b l e d i fferentiation in
terms of capabilities allocated for every single service oper-
ator, we consider diverse failure rates for every VPI in our
model. On the other hand, we consider the same value µs
by guessing common repair actions for all software instances
and then for all VPI. Thus, the following failure and repair
rates are adopted: λ1=3.858 ×10−7s−1(equivalent to 1
fault per month for S1), λ2=7.716 ×10−7s−1(equivalent
to 2 fault per month for S2), λ3=1.157 ×10−6s−1(equiv-
alent to 3 fault per month for S3), and µs=1.388 ×10−4
s−1(equivalent to a mean repair time of 2 hours for every
VPI).
According to the SDN controller model presented in Fig-
ure 3, we recall that all the VPI software instances run on
the top of a core part (virtualization layer, operating system
and shared hardware resources). The core part failure rate
is assumed to be λc=1.268 ×10−7s−1(equivalent to 4
core faults per year), while the rate of the repair activity on
afailedcorepartisµc=3.472 ×10−5s−1(equivalent to
ameanrepairtimeof8hours). Thisactivityissupposed
to completely restore the node functionalities by eventually
reactivating also VPI instances in down conditions, as mod-
eled in Figure 4 and remarked in Section 3.
In Table 2, all the parameters values adopted in the nu-
merical experiment are listed. It is worth noting that all the
selected values, although arbitrarily chosen, are in keeping
with the experience of system engineers.
By solving (1) with all the derivatives equal to 0 and by
using the condition (4), the steady-state probabilities p(r)
jin
(3) are computed for a single node r,whose3-dimensional
Tab l e 2 : Pa r a m eters va l ues in the nu m e r i cal experim e nt
Parameter Value
k3
n5000 stu
λ13.858 ×10−7s−1
λ27.716 ×10−7s−1
λ31.157 ×10−6s−1
µs1.388 ×10−4s−1
λc1.268 ×10−7s−1
µc3.472 ×10−5s−1
w4800 stu
A00.999999
performance vectors g(r)
jare reported in Table 1, for each
state j=−1,0,...,7. Subsequently, the MUGF of the vec-
tor performance distribution of node ris derived after (9).
The redundancy optimization problem (11) is solved by
implementing the MUGF πoperator in (10) and by comput-
ing the steady-state availability (7) directly from the MUGF
of the system composed by the nodes connected in parallel.
Given A0=0.999999, the “six 9s” availability condition (in-
creasingly desirable in telecommunication systems) of the
SDN controller is reached (and even exceeded) with at least
h∗=4parallelelements;indeed,thesteady-stateavailabil-
ity of this redundant configuration of the SDN controller
is:
ASDN(w, h∗),
,w=4800
h∗=4
=p7=0.999999971.
Tab l e 3 r e p o r t s t h e comple t e l i st of the perfor m a n ce vect o r s
and the corresponding steady-state probabilities for an SDN
controller in the same redundant configuration.
The numerical experiment has been performed by a Math-
ematica routine implementing the MUGF approach. The
execution time of the said routine, running on a notebook
based on an Intel Core i7-4960 HQ CPU@2.6GHz, is about
0.0327 s, which shows that the proposed MUGF approach
is very fast to apply.
In order to evaluate and appreciate the differences in terms
of availability by varying the number hof redundant ele-
ments, we refer to Figure 5 where, for sake of simplicity,
we consider the steady-state unavailability of the system
1−ASDN(w, h). The horizontal dashed line in the aforemen-
tioned figure represents the required steady-state unavail-
ability 1−A0=10
−6.Itisworthnotingthatincaseofh=3
redundant elements, the resulting ASDN value amounts t o
0.999997403 that is considered by now not fully compliant
Tab l e 3 : Pe r forma n c e v ectors a n d s t eady-st a t e p r obabil i t ies
of an SDN controller composed by 4 parallel units
Probability Performance vectors
1.755 ×10−10 (0,0,0)
8.903 ×10−12 (5000,0,0)
4.410 ×10−12 (0,5000,0)
1.964 ×10−8(5000,5000,0)
2.931 ×10−12 (0,0,5000)
6.789 ×10−9(5000,0,5000)
1.491 ×10−9(0,5000,5000)
0.999999971 (5000,5000,5000)

Figure 5: Unavailability 1 −ASDN(w, h)oftheSDNcon-
troller architecture for h=1,2,3,4parallelelements. The
horizontal dashed line represents the required steady-state
unavailability 1 −A0=10
−6of the SDN controller architec-
ture.
with the modern standard requirements of very high avail-
ability. Besides, some changes in the values of the repair
rates µcand µsdoes not weaken the “six 9s” availability
condition, as shown in Figures 6 and 7, respectively.
6. CONCLUSIONS
In an SDN environment, the network control and forward-
ing functions are decoupled, and the network intelligence is
centralized and managed by the controller, the most critical
element on the entire SDN infrastructure. Being the con-
troller a failure-prone network element, we propose a per-
formability analysis aiming to obtain the so called “six 9s”
availability condition, increasingly required by the telecom-
munication world. In our modeling, some virtualized soft-
ware instances (representing different virtual telecom oper-
ators) are managed by the SDN controller. Such instances,
referred to as VPIs, are supposed to manage a set of SDN
switches via OpenFlow protocol. Therefore, the number of
coexistent OpenFlow sessions has been selected as perfor-
mance metric and the minimal cost redundant configuration
of the SDN controller was found. The performability analy-
sis of the controller has been faced by the Multivariate UGF,
anovelextensionofUGFintroducedtodealwithperfor-
mance vectors. Such an approach results advantageous in a
multi-operator environment where different VPIs can share
the same information. In a future work, the authors will try
to consider a more challenging environment that accounts
for Network Function Virtualization (NFV) paradigm and
its interaction with the considered SDN infrastructure.
7. REFERENCES
[1] S. Ali, V. Sivaraman, A. Radford, and S. Jha. A
survey of securing networks using software defined
networking. IEEE Transactions on Reliability,
64(3):1086–1097, 2015.
[2] C. Bernardos, A. De La Oliva, P. Serrano, A. Banchs,
L. Contreras, H. Jin, and J. Ziga. An architecture for
Figure 6: Influence of core repair rate on an SDN controller
composed by 4 parallel units.
Figure 7: Influence of software instances (VPIs) repair rate
on an SDN controller composed by 4 parallel units.
software defined wireless networking. IEEE Wireless
Communications,21(3):52–61,2014.
[3] M. Caesar, D. Caldwell, N. Feamster, J. Rexford,
A. Shaikh, and J. van der Merwe. Design and
implementation of a routing control platform. In
Proceedings of 2nd Symposium on Networked Systems
Design & Implementation - Volume 2,pages15–28,
2005.
[4] M. Casado, T. Garfinkel, A. Akella, M. J. Freedman,
D. Boneh, N. McKeown, and S. Shenker. Sane: A
protection architecture for enterprise networks. In
Proceedings of 15th Conference on USENIX Security
Symposium - Volume 15,2006.
[5] M. Di Mauro, F. Postiglione, and M. Longo.
Reliability analysis of the controller architecture in
Software Defined Networks. Safety and Reliability of
Complex Engineered Systems: ESREL2015,pages
1503–1510, 2015.

[6] P. Goransson and C. Black. Software Defined
Networks: A Comprehensive Approach.Morgan
Kaufmann, Burlington, 2014.
[7] A. Greenberg, G. Hjalmtysson, D. Maltz, A. Myers,
J. Rexford, G. Xie, H. Yan, J. Zhan, and H. Zhang. A
clean slate 4d approach to network control and
management. Computer Communication Review,
35(5):41–54, 2005.
[8] M. Guida, M. Longo, and F. Postiglione. Reliability
analysis of next generation mobile networks. In Briˇs,
G. Soares, and Martorell, editors, Reliability, Risk an d
Safety, three volume set:Theory and Applications,
volume 3, pages 1999–2006. Taylor & Francis Group,
London, 2010.
[9] M. Guida, M. Longo, F. Postiglione, K. Trivedi, and
X. Yin. Semi-Markov models for performance
evaluation of failure-prone IP multimedia subsystem
core networks. Proceedings of the Institution of
Mechanical Engineers, Part O: Journal of Risk and
Reliabi lity,227(3):290–301,2013.
[10] Y. Hu, W. Wendong, X. Gong, X. Que, and
C. Shiduan. Reliability-aware controller placement for
software-defined networks. In Proceedings of
IFIP/IEEE International Symposium on Integrated
Network Management (IM 2013),pages672–675,2013.
[11] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski,
A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu,
J. Zolla, U. H¨
olzle, S. Stuart, and A. Vahdat. B4:
Experience with a globally-deployed Software Defined
Wan. ACM SIGCOMM Comput. Commun. Rev.,
43(4):3–14, 2013.
[12] G. Levitin and A. Lisnianski. Multi-state system
reliabil ity: asses sment, opt imiza tion an d appli cation s.
World Scientific, Singapore, 2003.
[13] Y. Liu and K. S. Trivedi. Survivability quantification:
The analytical modeling approach. International
Journal on Performability Engineering,2(1):29–44,
2006.
[14] N. McKeown, T. Anderson, H. Balakrishnan,
G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and
J. Turner. Openflow: Enabling innovation in campus
networks. Computer Commununication Review,
38(2):69–74, 2008.
[15] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller,
M. Casado, N. McKeown, and G. Parulkar. FlowVisor:
ANetworkVirtualizationLayer.Technicalreport,
Deutsche Telekom Inc. R&D Lab, Stanford, Nicira
Networks, 2009.
[16] A. Tootoonchian and Y. Ganjali. Hyperflow: A
distributed control plane for OpenFlow. In Proceedings
of Internet Network Management Conf. on Research
on Enterprise Networking,pages3–3,2010.
[17] I. A. Ushakov. A universal generating function. Soviet
Journal of Computing System Science,24(5):37–49,
1986.
[18] I. A. Ushakov. Optimal standby problems and a
universal generating function. Soviet Journal of
Computing System Science,25(4):79–82,1987.
[19] B. Xiong, K. Yang, J. Zhao, W. Li, and K. Li.
Performance evaluation of openflow-based
software-defined networks based on queueing model.
Computer Networks,102:172–185,2016.
[20] M. Yu, J. Rexford, M. J. Freedman, and J. Wang.
Scalable flow-based networking with difane. Computer
Commununication Review,41(4):351–362,2010.
View publication statsView publication stats