Multiple controller management
in software defined networking
Speaker : Chung-Yi Chao
Advisor : Dr. Kai-Wei Ke
Date:
2015/02/03
1
Overview
• Introduction
• Related Work
• Proposed Scheme
• Architecture
• Algorithm
• Mathematical Modeling
• Join Ratio model
• Connection Ratio model
• Numerical Experiment
• Conclusion
• Reference
2
Introduction
• In SDN, network devices become simple packet forwarding devices
while the “brain” or control logic is implemented in the controller.
• SDN controllers and forwarding devices communicate with each other
by the southbound SDN interfaces ( e.g. OpenFlow ).
• SDN architecture brings about numerous advantages such as high
flexibility, programmability, and the possibility of realizing a
centralized network view.
• However, as the number and size of production networks increases,
relying on a single controller for the entire network might not be
feasible.
3
Introduction(Cont.)
• Much work have been spent in distributed controllers, for examples,
HyperFlow , FlowVisor , Onix , Kandoo , SiBF , Devolved Controllers.
They realize that multiple controllers manage multiple network
devices.
• But in their researches, each network device is only managed by one
controller.
• In fact, different controllers are probably owned by different vendors
under the consideration of encouraging competition.
4
Related Work
• HyperFlow is logically centralized but physically distributed: it provides scalability
while keeping the benefits of network control centralization. HyperFlow makes all
the controllers share the same consistent network-wide view and locally serve
requests without actively contacting any remote node.
• FlowVisor is a special purpose OpenFlow controller that acts as a transparent
proxy between OpenFlow switches and multiple OpenFlow controllers. FlowVisor
hosts multiple controllers in an OpenFlow network by slicing network resources
and delegating one single controller to observe and control its own slice.
• Onix is a platform on top of which a network control plane can be implemented
as a distributed system. The control platform handles state distribution by
collecting information from the switches and distributing the appropriate control
state to them, as well as coordinating the state among the various platform
servers.
5
Related Work(Cont.)
• Kandoo creates a two-level hierarchy for controllers: local controllers
execute local applications as close as possible to switches, and a logically
centralized root controller takes charge of applications that require
network-wide state, and also acts as a mediator for any coordination
required between local controllers.
• SiBF moves away from a centralized controller implementation and
introduces an army of Rack Managers, one per rack and acting as
OpenFlow controllers. It is based on sharing the application state in a
globally available data store.
• Devolved Controllers make one controller look after a portion of the
network only, but all controllers together cover the whole network. When
a controller is asked for a route, it responds with the topology data it has.
6
Proposed Scheme-Architecture
7
Proposed Scheme-Algorithm
• Step1: Users submit the requirement of a network application. The
application can be supported by deploying some virtual networks.
The requirement for virtual networks is sent to the controller. The
controller will choose appropriate network devices to deploy the
virtual network.
• Step2: Network devices initiate connections to controller according to
the number of connected controllers and their current local resource
condition.
• Step3: The controller chooses to accept the connection initiated by
network devices.
• Step4: After a connection is set up, controller sends message to get
the network device’s information.
8
Proposed Scheme-Algorithm( Cont. )
• Step5: If there are un-deployed virtual networks, then the controller
will choose appropriate network devices and send deployment
request messages to them. The deployment process will be carried
out by using 2PC (two-phase commit).
• Step6: If the number of virtual networks that the network device
doesn’t join in deploying is greater than a threshold, then the
connection is tore down.
9
Proposed Scheme-Algorithm( Cont. )
• Step7: When a connection is broken, after a random time interval, the
network device will re-initiate a connection to the controller. Then go
to step3.
10
Mathematical Modeling
• Our model has two parts:
1. The join ratio model
2. The connection ratio model
• The lower join ratio of network device means that the connected
network device often rejects to join in deploying virtual network.
Then it will waste a lot of communication and management overhead.
• The lower connection ratio of network device means that more
network devices cannot play a role for deploying virtual network.
Consequently, more overheads are spent setting up or tearing down
the connection.
11
Mathematical Modeling-symbols table
12
Mathematical ModelingJoin ratio model
• Average number of virtual networks one network device joins is :
𝑛
𝑚=(
𝑚𝑖 )/𝑛
𝑖=1
• Assume each virtual network has the same probability to be deployed,
the probability that a virtual network is deployed is 1/M .
• The probability that one network device joins a virtual network is:
𝑝 = 𝑚/𝑀
13
Mathematical ModelingJoin ratio model (Cont.)
• Then 𝑚𝑥 ’s probability
distributions are showed as
follows( 𝑚 < 𝑀):
• Therefore we have:
+∞
𝐼𝑦 =
𝑃(𝑖 − 𝑟) = 𝑟𝑝/(1 − 𝑝)
𝑖=𝑟
𝐼𝑛 = 𝑟
• The join ratio of network device:
𝐼𝑦
𝜇=
= 𝑚/𝑀
𝐼𝑦 + 𝐼𝑛
14
Mathematical ModelingConnection ratio model
• We regard connection and un-connection between controller and
network device as two-state Markov process .
• The average time interval of a connection from teardown to re-setup
is 𝑡1 .
• According to the join ratio model, the average duration per cycle:
+∞
𝑡2 = 𝑇 ∙
𝑃𝑖 𝑖 = 𝑇𝑟/(1 − 𝑝)
𝑖=𝑟
15
Mathematical ModelingConnection ratio model ( Cont. )
• The two time intervals (𝑡1 and 𝑡2 ) follow exponential distribution[20],
parameter of which are 1/𝑡1 and 1/𝑡2 respectively.
• In order to make it easy to compute, we set α = 1/𝑡1 and β = 1/𝑡2 .
The probability of keeping connection is 𝑒 −𝛼𝑡 , the probability of
keeping un-connection is 𝑒 −𝛽𝑡 . Let connection state be represented
by T, S for un-connection state.
16
Mathematical ModelingConnection ratio model ( Cont. )
• This process can be described by the Ehrenfest model [21], a birthdeath process to explain the second law of thermodynamics. The
model considers N particles in two containers. Particles
independently change container at a rate λ. We consider particles to
be the network devices managed by one controller and two
containers represent two states. Stationary distribution of the
number of network devices connected with a controller follows
binomial distribution
𝐵(𝑛, 𝛽/(𝛼 + 𝛽))
17
Mathematical ModelingConnection ratio model ( Cont. )
• Therefore, when the network is
stable, the average number of
the network devices connected
with a controller :
𝑛𝛽
𝑛𝑎 =
= 𝑛𝑡2 /(𝑡2 + 𝑡1 )
𝛼+𝛽
• The connection ratio of network
device :
𝑛𝑎
𝜂=
= 𝑡2 /(𝑡2 + 𝑡1 )
𝑛
18
Numerical Experiment
19
Numerical Experiment( Cont. )
• 1) set 𝑟 = 10, 𝑇 = 0.6𝑠, 𝑡1 = 6𝑠 , 𝜇 vs. M and 𝜂 vs. M
20
Numerical Experiment( Cont. )
• 2) set 𝑚 = 20, 𝑇 = 0.6𝑠, 𝑡1 = 6𝑠, 𝜂 vs r
21
Numerical Experiment( Cont. )
• 3) set r=10, m = 20, M=50, 𝜂 vs T
22
Conclusion
• The paper presents the scheme that multiple controllers manage
multiple network devices and one network device can be managed by
more than one controller.
• An adaptive connection is introduced in our algorithm. As such, much
overhead spent in computing and managing network device state is
saved.
• The numerical experiment results show:
1. Deploying the virtual networks densely is not good for the overall network.
2. A larger threshold number of virtual networks and a smaller time interval of
a connection from teardown to re-setup can make the network devices
used more effectively.
23
Reference
• Ying Li, Ligang Dong, Jianping Qu, Huafei Zhang, “Multiple controller
management in software defined networking” School of Information
& Electronic Engineering, Zhejiang Gongshang University, Hangzhou,
China
24