Presentation at International Conference on Intelligent and Innovative Computing Applications (ICONIC) 2018

1. Multipath Load Balancing for SDN
Data Plane
For ICONIC 2018, 6-7 Dec 2018, Mon Tresor, Mauritius
Authors: Mpho Nkosi*, Albert A. Lysko, Sabelo Dlamini
CSIR Meraka Institute, Pretoria, South Africa
Email: mnkosi2@csir.co.za

2. 2
Contents
• Introduction
• Focus of the work
• System Setup and Methodology
• Multi-path load balancing algorithm
• Results
• Conclusion

3. 3
Introduction (1 of 2)
• SDN is a key enabling networking paradigm for 5G communications
• Core function of SDN is to separate the control from the data plane based
on abstract representation of network
• Abstraction is achieved through the use of SDN controller which defines the
behaviour of the forwarding plane and routing policies
• For each path, the controller defines a flow together with flow routing
policy. Thus, for each path, only one flow is defined

4. 4
Introduction (2 of 2)
• Load balancing is the method of managing incoming traffic by distributing
and sharing the load fairly among available resources
• In SDN, load balancers are program codes which can easily be
implemented on the SDN controller to efficiently manage network load
• Most SDN controllers come with built in static network load balancers
• Load balancing in SDN controllers is implemented using two approaches: the
stateless or the state-full load balancing

5. 5
Related Work
• Khan et. al, studied dynamic load balancing based on traffic volume by
monitoring link usage and load balancing traffic among available links to
avoid link over loading [1].
• Gupta et. al studied flow statistics based load balancing using POX controller
[2]. In their method, load balancing is performed to avoid server overloading
by fairly sharing server connection requests among multiple servers

6. 6
Focus of this work
• This work studies multi-path load balancing mechanism to reduce network
response time and maximize the overall network performance
• To measure the performance of multipath-based load balancing in a single
centralized OpenDayLight controller network
• The main contribution of this work is a load balancing mechanism for SDN
centralized controller environments which can be employed at any point in
time in a network

7. 7
System setup (1 of 2)
• Two different scenarios with different network topologies were considered:
Scenario 1: a single centralised SDN controller connected to 7 OpenFlow
switches and 8 hosts
Scenario 2: a single centralised SDN controller connected 40 OpenFlow
switches and 81hosts
• Nitrogen version of the open source Opendaylight controller was used in
both scenarios
• Karaf dlux features were used to monitor the topologies, nodes and
controller-switch communications

8. 8
System setup ( 2 of 2)
• PC with Linux Ubuntu 18.04 with 8GB RAM and 2.7GHz processing speed
was used to implement this study
• Mininet SDN emulation tool was used to emulate the network topologies
• Iperf was used to create TCP data streams and to measure the throughput of
the data flow before load balancing and after load balancing.
• Wireshark was also used to analyse packet routing before and after load
balancing

9. 9
Implementation Methodology ( 1 of 2)
• Emulate a network topology using mininet and run mininet ping all to ensure
that nodes and links are up and running.
• Identify a source-destination pair
• Verify that the path is indeed used for transmission for the source-destination
pair using Wireshark
• Create a ping on the source-destination pair to generate traffic and flow
congestion
• Perform an iperf and another ping to measure the latency and bandwidth
utilization on the over loaded flow

10. 10
Implementation Methodology ( 2 of 2)
• Perform load balancing on the congested source-destination pair)
• Perform an iperf and ping again on the source-destination pair to measure
the performance of the load balancing.

11. 11
The multi-path load balancing algorithm
• Takes source-destination pair as input
• Extracts network topology using JSON and REST APIs and perform link,
port MAC and IP mappings together with switch and port connections.
• Extracts ports transmissions rates and stats to understand load on each
port for each flow
• Possible best alternative paths are defined based on lowest flow cost
• Flow cost is calculated as the sum of number of transmitted and received
packets at that time
• Traffic for the source-destination pair is pushed down on to the alternative
flows until all alternative Flows have equal flow cost

12. 12
Scenario 1
h1
h8
OF-switch 2
OF-switch 3 OF-switch 6OF-switch 4
OF-switch 7
h2
h3 h4 h5 h6 h7
OF-switch 1 OF-switch 5
Source-destination pair: h1- h8
Path: [S3-S2-S1-S5-S7] alternative path: [S3-S2-S1-S7]

13. 13
Scenario 2
OF-switch 6
OF-switch 7
OF-switch 8
OF-switch 5
OF-switch 2
OF-switch 3
OF-switch 4
OF-switch 1
OF-switch 10
OF-switch 11
OF-switch 12
OF-switch 9
OF-switch 14
OF-switch 15
OF-switch 16
OF-switch 13
OF-switch 18
OF-switch 19
OF-switch 20
OF-switch 17
OF-switch 37
OF-switch 38
OF-switch 40
OF-switch 22
OF-switch 23
OF-switch 24
OF-switch 21
OF-switch 30
OF-switch 31
OF-switch 32
OF-switch 29
OF-switch 26
OF-switch 27
OF-switch 28
OF-switch 25
OF-switch 39
h79-h81
h4 -h6
h7 -h9 h10 -h12
h13 -h15
h16 -h18
h22 -h24 h25 -h27
h19 -h21 h28 -h30
h31 -h33
h34 -h36
h37 -h39
h40 -h42
h43 -h45
h46 -h48
h49 -h51
h52 -h54
h55 -h57
h61 -h63h58 -h60
h69 -h71
h66 -h68
h64 -h65h76 -h78
h72 -h75
h1-h3
OF-switch 34
OF-switch 35
OF-switch 36
OF-switch 33
Source-destination pair: h7-h54 Path: [S7-S5-S37-S39-S40-S25-S28]
Alternative Paths: [S7-S5-S37-S38-S40-S25-S28],
[S7-S5-S37-S38-S39-S40-S25-S28],[S7-S5-S37-S39-S38-S40-S25-S28]

14. 14
Results (1 of 4)
0
1
2
3
4
5
6
7
8
9
10
MIN AVG MAX MDEV
Time in ms
average ping for 10packets of size 10240byte
Scenario1: Ping results
Before Load Balancnig
After load balancing

15. 15
Results (2 of 4)
0
1
2
3
4
5
6
7
Transfer(GBytes) Bandwidth(Mbits/sec)
GBvs.MBits/sec
averageiperf for timeinterval of 15sec
Scenario 1: Iperf results
Before Load balanacing
After load balalncing

16. 16
Results (3 of 4)
0
1
2
3
4
5
6
7
8
9
10
MIN AVG MAX MDEV
Timeinms
Averageping for 10 packets of size10240 Byte
Scenario 2:Pingresults
Before Load balancing
After Load Balancing

17. 17
Results (4 of 4)
0
1
2
3
4
5
6
7
Transfer(GBytes) Bandwidth(Mbits/sec)
GBvs.MB/sec
averageiperf for timeinterval of 15sec
Scenario 2: Iperf results
Before Load balanacing
After load balalncing

18. 18
Conclusion
• From scenario 1 and 2, it can be concluded that the load balancer is flexible
for both smaller networks and larger networks. It also can improve network
performance and avoid overall network delay
• However, it was found that for better network improvement, the data plane
should have multiple alternative links so that multiple path paths can be
defined for a routing path

19. 19
References
[1] S. Bhandarkar and K. A. Khan, “Load Balancing in Software-defined Network
( SDN ) Based on Traffic Volume,” vol. 2, no. 7, pp. 72–76, 2015
[2] K. Kaur, S. Kaur, and V. Gupta, “Flow statistics based load balancing in
OpenFlow,” 2016 Int. Conf. Adv. Comput. Commun. Informatics, pp. 378–381,
2016

20. Thank you