SlideShare a Scribd company logo
978-1-4799-7961-5/15/$31.00 ©2015 IEEE
The Transmission Time Analysis of IPTV Multicast
Service in SDN/OpenFlow Environments
Pornnipa Rattanawadee
Wireless Network and Future Internet
Research Group
Department of Electrical Engineering
Faculty of Engineering
Chulalongkorn University
Bangkok, Thailand
Pornnipa.R@student.chula.ac.th
Natchaphon Ruengsakulrach
Faculty of Engineering
Georgia Institute of Technology
Atlanta, USA
nruengsa@gatech.edu
Chaiyachet Saivichit
Wireless Network and Future Internet
Research Group
Department of Electrical Engineering
Faculty of Engineering
Chulalongkorn University
Bangkok, Thailand
chaiyachet.s@chula.ac.th
Abstract—Software Defined Network has a centralized controller
that regulates packet forwarding by updating flow tables of switches.
The sole responsibility of these OpenFlow-enabled switches is to
forward packets according to rules in their flow tables. The function
of Software Defined Network is similar to the traditional IPTV
protocol that there are Rendezvous Point be the intermediate node.
Rendezvous Point is a node in the network that creates routing
between servers and clients. This paper proposes an application of
SDN/OpenFlow in IPTV multicasting implementation. An important
function of IPTV multicasting is the Joint/Leave request of client in a
multicast group. In order to obtain an efficient IPTV service routing,
Dijkstra’s and Prim’s algorithms were used to comparatively
calculate minimum total edge weight. Mininet environment is used to
emulate our system, which consists of Open vSwitch and a POX
controller. Our experiments compare the transmission time of the first
joint/receive packet to a client when using Dijkstra’s and Prim’s
algorithms. We define the edge weight as the distance between two
adjacent nodes.
Keywords—OpenFlow; IPTV multicast; Dijkstra’s algorithm;
Prim’s algorithm
I. INTRODUCTION
Communication network is composed of interconnecting
devices such as switches and routers. Traditional switches are
self-learning. A self-learning switch broadcasts packets to
discover other switches within the same network and
associates MAC addresses of these neighbor switches with
their interfaces. The switch’s packet broadcasting method
could cause redundant traffic flows and delay routing time.
There has been a research on OpenFlow to tackle this
broadcasting problem. OpenFlow is a protocol used in
Software Defined Networking or SDN, which utilizes a
centralized controller. This controller controls packet routing
by populating flow tables of the switches. Thus, the
responsibility of switches in the OpenFlow network is to
perform routing action on data packets according to their flow
tables.
IP multicast service is a popular technique for enhanced
traffic efficiency, especially in Internet Protocol Television or
IPTV multicasting. Several protocols have been designed to
discover an efficient way to transmit multicast packets. One
research proposes Hybrid Tree Based Explicit Routed
Multicast or HT-ERM [1] which combines advantages of
Rendezvous Point (RP) based shared tree and specific source
based shortest path tree of traditional multicast network. HT-
ERM improves multicast group’s admission control, reducing
blocking ratio and delay time of channel switching. Another
research proposes PIM-SM protocol [2], which eliminates
unnecessary steps of changing from RP to Shortest Path Tree
(SPT). The elimination allows packets to be efficiently
transmitted without relying on central data node and
consequentially minimizes bandwidth consumption.
SDN researches are interesting, especially in the area of
packet routing. One research proposes Green Minimum
Spanning Tree (GreenMST) [3] which focuses on routing
algorithm in SDN. The research aims to reduce an energy
consumption of a forwarding device by using an SDN
controller that implements Kruskal’s algorithm to calculate
minimum spanning tree. Moreover, some researches extend to
SDN application in delivering IPTV packets such as [4] a
controller that re-routes when paths become congested. This
can be achieved by having a switch provide its controller with
a congestion message and traffic statistics. The result is fewer
number of packets dropped due to overflow. Another research
proposes Multiflow [5] which calculates an efficient route for
multicast packets using Dijkstra’s algorithm. Multiflow uses
Dijkstra’s algorithm to discover shortest paths, assigning edge
weight based on the distance between two nodes. This
Multiflow application matches with our interest.
The traditional multicast protocols use RP as a center of
the network to route and transmit data among servers and
clients. Since the RP is a switch, its self-learning capability
becomes its routing disadvantage. The RP spends a
considerable amount of time to collect the data of other
switches and calculate appropriate data transmission routes.
Therefore, in this paper, we aim to improve the efficiency of
IPTV multicast routing by applying central controller concept
deployed in SDN. We deploy Dijkstra’s and Prim’s
algorithms in the POX controller to calculate the shortest
paths with delay time as the edge weight. Our POX controller
This research has been supported by the Special Task Force for
Activating Research (STAR) Funding in Wireless Network and Future
Internet Research Group, Chulalongkorn University, Thailand, and is based on
the collaborations of OF@TIEN project.
has been designed to handle UDP packet sending and
receiving among IPTV server and clients.
II. IPTV MULTICAST SERVICE IN SDN/OPENFLOW
A. Proposed model
We propose an application of Multiflow model [5] as a
part of routing algorithm in Fig.1. We apply Prim’s and
Dijkstra’s algorithms to achieve minimum delay of UDP
packet delivery between IPTV server and clients. We then
compare the performance of Dijkstra’s and Prim’s algorithms
in our POX controller.
Server Client Network Equipments OF Controller
Forward IGMP Query
IGMP Query
IGMP Join
Flood IGMP Query
to all switches
Q
U
E
R
Y
J
O
I
N
Forward IGMP Join
Calculate route
Forward rules to each switch
Add rules into
Flow table
IGMP Leave
L
E
A
V
E
Forward IGMP Leave
Remove client depart
the group
Forward remove client
Delete rules depart
Flow table
Forward rules to each switch
Add rules into
Flow table
Fig. 1. Multiflow model [5]
The Multiflow model composes of three steps
1) IGMP query
The IPTV server sends IGMP query to Open vSwitch to
announce its service. The IGMP query packet is composed of
IP multicast group. When the Open vSwitch receives IGMP
query packet for the first time, it forwards the packet to the
POX controller, which calculates the route of that packet and
adds that route to the Open vSwitch’s flow table.
2) IGMP join
When the client receives IGMP query packet and wishes to
join the multicast group, it sends IGMP join packet to the
nearest Open vSwitch. The IGMP join packet is then
forwarded to the POX controller, where a user’s program
performs route calculation.
3) IGMP leave
When the client wishes to leave the multicast group, it
sends an IGMP leave packet to Open vSwitch, which will
forward the packet to the controller. The controller then
removes the multicast route to the client from the flow table.
TABLE 1. DIJKSTRA FUNCTION ALGORITHM
Algorithm 1 Dijkstra function
Input: R_G (set of Open vSwitches and port numbers)
S (initial Open vSwitch), SW (set of Open vSwitches)
Output: TREE (Dijkstra path)
1: let TREE be an empty dictionary
2: let Q be an empty list
3: for END is in R_G.keys():
4: if S is END : continue
5: else :
6: call Dijkstra function and return value to DIJ and ROT
7: let PART be an empty list
8: while 1 :
9: add END to the end of PATH
10: if END = S : break
11: add value of END in ROT to END
12: reverse the elements of PATH
13: add the number of elements in PATH to LEN
14: for L in range (LEN-1) :
15: add the value of position L in PATH to SW1
16: add the value of position L+1 in PATH to SW2
17: if SW2 is None : continue
18: else :
19: add the value of G[SW1][SW2] to PORT
20: add set of SW1,SW2,PORT to TREE
21: return TREE
TABLE 2. SHORTEST FUNCTION ALGORITHM
Algorithm 2 Shortest function
Input: G = (V,E), S (initial Open vSwitch), E (destination Open vSwitch)
Output: DIJ,ROT
1: let G be the graph of proposed topology that composes of V, pair of
nodes(Open vSwitch), and E, edge weight between 2 nodes
2: let N_W be the initial edge weight of node S, equal to {S,0}
3: let DIJ and ROT be an empty dictionary
4: for node v is in N_W :
5: let value of DIJ equal to N_W
6: if node v is node E :
7: break:
8: for node w is the value of node v in G :
9: find weight of (vi,wi) = DIJ[v] + weight of (v,w) in G
10: if node wi is already in DIJ :
11: if weight of (vi,wi) < the value of node w in DIJ :
12: show Value Error
13: elif node wi is not already in N_W or
weight of (vi,wi) < value of node w in N_W :
14: add set of node wi and weight of (vi,wi) to N_W
15: add set of node vi and node wi to ROT
16: return (DIJ,ROT)
B. Routing algorithms
This paper proposes the use of Dijkstra’s and Prim’s
algorithms to calculate shortest path tree of IPTV network.
While Dijkstra’s algorithm finds the shortest paths of the
chosen node to every other nodes resulting in the minimum
distance tree from the chosen node, Prim’s algorithm finds the
shortest paths among all nodes, represented as the minimum
spanning tree.
When the POX controller receives IGMP join packet for the
first time, it calculates using the assigned routing algorithm.
1) Dijkstra’s algorithm
There are two functions, Dijkstra and Shortest functions, in
Dijkstra’s algorithm code, shown in Table 1 and 2,
respectively. Dijkstra function defines the source and
destination Open vSwitch pair, which is input into the Shortest
function. The Shortest function then calculates the shortest
path between the initial and destination Open vSwitches.
Dijkstra function collects the shortest paths of all Open
vSwitches to create Dijkstra path.
2) Prim’s algorithm
We design Prim function to calculate Prim’s algorithm,
shown in Table 3. The operation of Prim function relies on the
heap function [6] to choose the minimum edge weight of the
pair of Open vSwitches. Prim function collects the minimum
edge weight of each edge to create Prim path.
TABLE 3. PRIM FUNCTION ALGORITHM
Algorithm 3 Prim function
Input: G = (V,E), VER
Output: MST
1: let G be the graph of proposed topology that composes of V, pair of
nodes(Open vSwitch), and E, edge weight between 2 nodes
2: let VER be the list of Open vSwitches
3: let ADJ be an empty dictionary
4: for node n1, node n2, edge weight c in G :
5: add c, n1, n2 be the value of n1 to ADJ
6: add c, n2, n1 be the value of n2 to ADJ
7: let MST be an empty list
8: add the value of VER[0] to USED
9: add the value of ADJ[0] to EDG_U
10: convert EDG_U to heap function
11: while EDG_U :
12: return the smallest value of EDG_U to COT, N1, N2 and remove it
13: if N2 is not already in USED :
14: add N2 to USED
15: add COT, N1, N2 to the end of MST
16: for E in ADJ[2] :
17: if value of E[2] is not already in USED :
18: push E onto EDG_U
19: return MST
III. RESULT
A. Experiment Setup
The software in the experiment are shown in Table 4
TABLE 4. SOFTWARES AND VERSIONS
Software Version
Mininet 2.2
OpenFlow 1.0
Open vSwitch 1.4.6
POX 3.0
In the experiment, Mininet, a network emulator, is used to
create virtual hosts, switches, and controllers. We use POX
controller, which is programmed in Python.
Fig.2 and 3 illustrate the experimental network topology,
which consists of two IPTV servers (h1,h2), four clients (h3-
h6), twelve Open vSwitches (s1-s12) and an OpenFlow
controller (c0). The POX controller connects with all Open
vSwitches.
This experiment measures transmission time between
IPTV server 1 to each client. The POX controller can run one
algorithm at a time. The method follows these steps below:
Step 1: IPTV server 1 announces its service by sending
IGMP query to adjacent Open vSwitches. The POX controller
calculates the route of IGMP query, which is shown in Fig.2.
Step 2: All clients send IGMP join packets to join the
multicast group of IPTV server 1. The POX controller
calculates routes and adds a flow entry to each Open vSwitch.
The routes calculated by Dijkstra’s and Prim’s algorithms are
shown in Fig.3.
Step 3: IPTV server 1 sends UDP packet to each client. We
use Wireshark to capture the transmission time between IPTV
server and client.
Fig. 2. IGMP packet routes
Fig. 3. IPTV packet routes
Dijkstra’s algorithm computes the minimum distance from
the server to each client and returns a minimum distance tree
from the server. Prim’s algorithm returns a minimum
spanning, a tree which connects all nodes and keeps minimum
overall distance. From Fig.3, the routes from IPTV server 1 to
client 2 are different. The number of hops on the route
obtained from Dijkstra’s algorithm is only 4 hops whereas that
obtained from Prim’s algorithm is 6 hops
(a)
(b)
(c)
(d)
Fig. 4. The time of client sends IGMP join and receives the first packet:
(a) server 1 to client 1 , (b) server 1 to client 2,
(c) server 1 to client 3, (d) server 1 to client 4.
Fig. 5. The time of route calculation.
B. Result and discussion
The transmission time between IPTV server 1 to each
client shown in Fig.4. The X-axis is the number of the
experiments. We experiment by sending the joint/receive
packet from IPTV server 1 to clients. For each client, we send
100 joint/receive packets. The Y-axis is the transmission time
which composes of the time of route calculation and time of
UDP packet delivery.
The transmission time of Fig.4 (b) shows the result of
packet transmission time from IPTV server 1 to client 2. The
transmission time values of Prim’s algorithm are higher than
Dijkstra’s algorithm around 4.9 milliseconds. The
transmission times of client 4 conform to the number of hops
in Fig.3 that Prim’s algorithm has the number of hops more
than Dijkstra’s algorithm. In other case, the results show the
same routes obtained from Prim and Dijkstra but little
different in transmission time. This is because of different
route calculation time of two algorithms. The route calculation
time of two algorithms are also shown in Fig. 5. We
performed experiments by sending joint packet 500 times. The
average route calculation of Dijkstra’s algorithm is 1.53
milliseconds and the average route calculation of Prim’s
algorithm is 0.37 milliseconds. Thus, the route calculation
values of 2 algorithms are different around 1.16 milliseconds.
IV. CONCLUSION AND FUTURE WORK
This paper proposes an application of SDN/OpenFlow with
IPTV multicasting application. In order to obtain an efficient
IPTV service routing, Dijkstra’s and Prim’s algorithms are
selected to comparatively calculate the minimum total edge
weight. Our experiments compare the transmission time of the
first joint/receive packet of client when using Dijkstra’s and
Prim’s algorithms. We define the edge weight as the distance
between two adjacent nodes. We can implement Dijkstra’s and
Prim’s algorithm in POX controller to IPTV multicast service.
This paper is the starting point of our IPTV experiment on
SDN. The future experiment will involve a larger network
topology and more IPTV servers/clients to test the limit of the
POX controller in calculating routes. Transmission time will
be analyzed and PSNR value will be used to determine the
quality of videos sent from the IPTV server.
ACKNOWLEDGMENT
This research has been supported by the Special Task
Force for Activating Research (STAR) Funding in Wireless
Network and Future Internet Research Group, Chulalongkorn
University, Thailand, and is based on the collaborations
of OF@TIEN project.
REFERENCES
[1] C. C. Wen, C. S. Wu and M. T. Yang, “Hybrid Tree Based Explicit
Routed Multicast for QoS Supported IPTV Service,” Global
Telecommunications Conference, GLOBECOM 2009, IEEE, pp. 1-6,
Nov-Dec 2009.
[2] J. Ko, S. Park and E. Lee, “An Extended PIM-SM for Efficient Data
Transmission in IPTV Services,” Proceeddings of 2010 2nd
International
Conference on Network Infrastructure and Digital Content, IC-NIDC
2010, pp. 115-119, September 2010.
[3] L. Prete, F. Farina, M. Campanella and A. Biancini, “Energy efficient
minimum spanning tree in OpenFlow networks,” European Workshop
on Software Defined Networking, EWSDN, pp.36-41, October 2012.
[4] P. McDonagh, C. Olariu, A. Hava and C. Thorpe, “Enabling IPTV
Service Assurance using OpenFlow,” 27th International Conference on
Advanced Information Networking and Applications Workshops,
WAINA, pp.1456-1460, March 2013.
[5] L. Bondan, L. F. Muller and M. Kist, “Multiflow: Multicast clean-slate
with anticipated route calculation on OpenFlow programmable
networks,” Journal of Applied Computing Research, vol.2, n.2, pp.68-
74, Jul-Dec 2012.
[6] Heap queue algorithm [Online]. Avalible from
https://docs.python.org/2/library/heapq.html

More Related Content

What's hot

Performance analysis of tunnel broker through open virtual private network
Performance analysis of tunnel broker through open virtual private networkPerformance analysis of tunnel broker through open virtual private network
Performance analysis of tunnel broker through open virtual private network
TELKOMNIKA JOURNAL
 
transport layer protocols
transport layer protocolstransport layer protocols
transport layer protocols
BE Smârt
 
udp , tcp ,sctp
udp , tcp ,sctpudp , tcp ,sctp
udp , tcp ,sctp
AKSHIT KOHLI
 
Network Layer
Network LayerNetwork Layer
Network Layer
reshmadayma
 
Transport layer
Transport layerTransport layer
Transport layer
Jinank Jain
 
Performance Analysis and Simulation of OLSR Routing Protocol in MANET
Performance Analysis and Simulation of  OLSR Routing Protocol in MANET Performance Analysis and Simulation of  OLSR Routing Protocol in MANET
Performance Analysis and Simulation of OLSR Routing Protocol in MANET
ijcnac
 
Transportlayer tanenbaum
Transportlayer tanenbaumTransportlayer tanenbaum
Transportlayer tanenbaum
Mahesh Kumar Chelimilla
 
IRJET- Performance Improvement of Wireless Network using Modern Simulation Tools
IRJET- Performance Improvement of Wireless Network using Modern Simulation ToolsIRJET- Performance Improvement of Wireless Network using Modern Simulation Tools
IRJET- Performance Improvement of Wireless Network using Modern Simulation Tools
IRJET Journal
 
Network Layer
Network LayerNetwork Layer
Network Layer
reshmadayma
 
Transport layer (computer networks)
Transport layer (computer networks)Transport layer (computer networks)
Transport layer (computer networks)
Fatbardh Hysa
 
Transport layer
Transport layerTransport layer
Transport layer
Sisir Ghosh
 
Chapter4 l4
Chapter4 l4Chapter4 l4
Chapter4 l4
Tushar Mendhe
 
Stcn presentation
Stcn presentationStcn presentation
Stcn presentation
Sutanu Paul
 
Transport Layer Part 1
Transport Layer Part 1Transport Layer Part 1
Transport Layer Part 1
Tutun Juhana
 
TCP & UDP Streaming Comparison and a Study on DCCP & SCTP Protocols
TCP & UDP Streaming Comparison and a Study on DCCP & SCTP ProtocolsTCP & UDP Streaming Comparison and a Study on DCCP & SCTP Protocols
TCP & UDP Streaming Comparison and a Study on DCCP & SCTP Protocols
Peter SHIN
 
MC0087 Internal Assignment (SMU)
MC0087 Internal Assignment (SMU)MC0087 Internal Assignment (SMU)
MC0087 Internal Assignment (SMU)
Krishan Pareek
 
Transport Layer Services : Multiplexing And Demultiplexing
Transport Layer Services : Multiplexing And DemultiplexingTransport Layer Services : Multiplexing And Demultiplexing
Transport Layer Services : Multiplexing And Demultiplexing
Keyur Vadodariya
 
Transport layer protocol
Transport layer protocolTransport layer protocol
Transport layer protocol
N.Jagadish Kumar
 
Transport layer
Transport layerTransport layer
Transport layer
reshmadayma
 
Design and implementation of low latency weighted round robin (ll wrr) schedu...
Design and implementation of low latency weighted round robin (ll wrr) schedu...Design and implementation of low latency weighted round robin (ll wrr) schedu...
Design and implementation of low latency weighted round robin (ll wrr) schedu...
ijwmn
 

What's hot (20)

Performance analysis of tunnel broker through open virtual private network
Performance analysis of tunnel broker through open virtual private networkPerformance analysis of tunnel broker through open virtual private network
Performance analysis of tunnel broker through open virtual private network
 
transport layer protocols
transport layer protocolstransport layer protocols
transport layer protocols
 
udp , tcp ,sctp
udp , tcp ,sctpudp , tcp ,sctp
udp , tcp ,sctp
 
Network Layer
Network LayerNetwork Layer
Network Layer
 
Transport layer
Transport layerTransport layer
Transport layer
 
Performance Analysis and Simulation of OLSR Routing Protocol in MANET
Performance Analysis and Simulation of  OLSR Routing Protocol in MANET Performance Analysis and Simulation of  OLSR Routing Protocol in MANET
Performance Analysis and Simulation of OLSR Routing Protocol in MANET
 
Transportlayer tanenbaum
Transportlayer tanenbaumTransportlayer tanenbaum
Transportlayer tanenbaum
 
IRJET- Performance Improvement of Wireless Network using Modern Simulation Tools
IRJET- Performance Improvement of Wireless Network using Modern Simulation ToolsIRJET- Performance Improvement of Wireless Network using Modern Simulation Tools
IRJET- Performance Improvement of Wireless Network using Modern Simulation Tools
 
Network Layer
Network LayerNetwork Layer
Network Layer
 
Transport layer (computer networks)
Transport layer (computer networks)Transport layer (computer networks)
Transport layer (computer networks)
 
Transport layer
Transport layerTransport layer
Transport layer
 
Chapter4 l4
Chapter4 l4Chapter4 l4
Chapter4 l4
 
Stcn presentation
Stcn presentationStcn presentation
Stcn presentation
 
Transport Layer Part 1
Transport Layer Part 1Transport Layer Part 1
Transport Layer Part 1
 
TCP & UDP Streaming Comparison and a Study on DCCP & SCTP Protocols
TCP & UDP Streaming Comparison and a Study on DCCP & SCTP ProtocolsTCP & UDP Streaming Comparison and a Study on DCCP & SCTP Protocols
TCP & UDP Streaming Comparison and a Study on DCCP & SCTP Protocols
 
MC0087 Internal Assignment (SMU)
MC0087 Internal Assignment (SMU)MC0087 Internal Assignment (SMU)
MC0087 Internal Assignment (SMU)
 
Transport Layer Services : Multiplexing And Demultiplexing
Transport Layer Services : Multiplexing And DemultiplexingTransport Layer Services : Multiplexing And Demultiplexing
Transport Layer Services : Multiplexing And Demultiplexing
 
Transport layer protocol
Transport layer protocolTransport layer protocol
Transport layer protocol
 
Transport layer
Transport layerTransport layer
Transport layer
 
Design and implementation of low latency weighted round robin (ll wrr) schedu...
Design and implementation of low latency weighted round robin (ll wrr) schedu...Design and implementation of low latency weighted round robin (ll wrr) schedu...
Design and implementation of low latency weighted round robin (ll wrr) schedu...
 

Similar to Ruengsakulrach_ECTI2015

MANET Routing Protocols , a case study
MANET Routing Protocols , a case studyMANET Routing Protocols , a case study
MANET Routing Protocols , a case study
Rehan Hattab
 
07 coms 525 tcpip - udp
07    coms 525 tcpip - udp07    coms 525 tcpip - udp
07 coms 525 tcpip - udp
Palanivel Kuppusamy
 
Data Communication and Networking(DCACN)
Data Communication and Networking(DCACN)Data Communication and Networking(DCACN)
Data Communication and Networking(DCACN)
Uttam Singh Chaudhary
 
Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks
Optimization of Low-efficiency Traffic in OpenFlowSoftware Defined NetworksOptimization of Low-efficiency Traffic in OpenFlowSoftware Defined Networks
Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks
Jose Saldana
 
Traffic Engineering in Software Defined Networking SDN
Traffic Engineering in Software Defined Networking SDNTraffic Engineering in Software Defined Networking SDN
Traffic Engineering in Software Defined Networking SDN
ijtsrd
 
Network layer u3
Network  layer u3Network  layer u3
Network layer u3
IndrajaMeghavathula
 
4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf
4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf
4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf
mrcopyxerox
 
Distributed gateway-based load balancing in software defined network
Distributed gateway-based load balancing in software defined networkDistributed gateway-based load balancing in software defined network
Distributed gateway-based load balancing in software defined network
TELKOMNIKA JOURNAL
 
LTE-EPC
LTE-EPCLTE-EPC
LTE-EPC
Faw Yas
 
Understanding Network Routing Problem and Study of Routing Algorithms and Heu...
Understanding Network Routing Problem and Study of Routing Algorithms and Heu...Understanding Network Routing Problem and Study of Routing Algorithms and Heu...
Understanding Network Routing Problem and Study of Routing Algorithms and Heu...
IRJET Journal
 
TCP Vs UDP
TCP Vs UDP TCP Vs UDP
TCP Vs UDP
Ahmed Elnaggar
 
DSR,LSR,IGMP,RIP,OSPF.ppt
DSR,LSR,IGMP,RIP,OSPF.pptDSR,LSR,IGMP,RIP,OSPF.ppt
DSR,LSR,IGMP,RIP,OSPF.ppt
Munnakumar518378
 
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
AIRCC Publishing Corporation
 
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
ijcsit
 
A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...
A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...
A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...
AIRCC Publishing Corporation
 
IRJET- Survey on Adaptive Routing Algorithms
IRJET- Survey on Adaptive Routing AlgorithmsIRJET- Survey on Adaptive Routing Algorithms
IRJET- Survey on Adaptive Routing Algorithms
IRJET Journal
 
unit 3 ns.ppt
unit 3 ns.pptunit 3 ns.ppt
unit 3 ns.ppt
Kamesh486870
 
Chapter Five - Transport Layer.pptx
Chapter Five - Transport Layer.pptxChapter Five - Transport Layer.pptx
Chapter Five - Transport Layer.pptx
GirT2
 
UNit-4 Transport Layer and its protocols.pdf
UNit-4 Transport Layer  and its protocols.pdfUNit-4 Transport Layer  and its protocols.pdf
UNit-4 Transport Layer and its protocols.pdf
ManimegalaM3
 
Icfcc conference real
Icfcc conference realIcfcc conference real
Icfcc conference real
UM
 

Similar to Ruengsakulrach_ECTI2015 (20)

MANET Routing Protocols , a case study
MANET Routing Protocols , a case studyMANET Routing Protocols , a case study
MANET Routing Protocols , a case study
 
07 coms 525 tcpip - udp
07    coms 525 tcpip - udp07    coms 525 tcpip - udp
07 coms 525 tcpip - udp
 
Data Communication and Networking(DCACN)
Data Communication and Networking(DCACN)Data Communication and Networking(DCACN)
Data Communication and Networking(DCACN)
 
Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks
Optimization of Low-efficiency Traffic in OpenFlowSoftware Defined NetworksOptimization of Low-efficiency Traffic in OpenFlowSoftware Defined Networks
Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks
 
Traffic Engineering in Software Defined Networking SDN
Traffic Engineering in Software Defined Networking SDNTraffic Engineering in Software Defined Networking SDN
Traffic Engineering in Software Defined Networking SDN
 
Network layer u3
Network  layer u3Network  layer u3
Network layer u3
 
4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf
4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf
4af46e43-4dc7-4b54-ba8b-3a2594bb5269 j.pdf
 
Distributed gateway-based load balancing in software defined network
Distributed gateway-based load balancing in software defined networkDistributed gateway-based load balancing in software defined network
Distributed gateway-based load balancing in software defined network
 
LTE-EPC
LTE-EPCLTE-EPC
LTE-EPC
 
Understanding Network Routing Problem and Study of Routing Algorithms and Heu...
Understanding Network Routing Problem and Study of Routing Algorithms and Heu...Understanding Network Routing Problem and Study of Routing Algorithms and Heu...
Understanding Network Routing Problem and Study of Routing Algorithms and Heu...
 
TCP Vs UDP
TCP Vs UDP TCP Vs UDP
TCP Vs UDP
 
DSR,LSR,IGMP,RIP,OSPF.ppt
DSR,LSR,IGMP,RIP,OSPF.pptDSR,LSR,IGMP,RIP,OSPF.ppt
DSR,LSR,IGMP,RIP,OSPF.ppt
 
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
 
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
A COMPARISON OF CONGESTION CONTROL VARIANTS OF TCP IN REACTIVE ROUTING PROTOC...
 
A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...
A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...
A Comparison of Congestion Control Variants of TCP in Reactive Routing Protoc...
 
IRJET- Survey on Adaptive Routing Algorithms
IRJET- Survey on Adaptive Routing AlgorithmsIRJET- Survey on Adaptive Routing Algorithms
IRJET- Survey on Adaptive Routing Algorithms
 
unit 3 ns.ppt
unit 3 ns.pptunit 3 ns.ppt
unit 3 ns.ppt
 
Chapter Five - Transport Layer.pptx
Chapter Five - Transport Layer.pptxChapter Five - Transport Layer.pptx
Chapter Five - Transport Layer.pptx
 
UNit-4 Transport Layer and its protocols.pdf
UNit-4 Transport Layer  and its protocols.pdfUNit-4 Transport Layer  and its protocols.pdf
UNit-4 Transport Layer and its protocols.pdf
 
Icfcc conference real
Icfcc conference realIcfcc conference real
Icfcc conference real
 

Ruengsakulrach_ECTI2015

  • 1. 978-1-4799-7961-5/15/$31.00 ©2015 IEEE The Transmission Time Analysis of IPTV Multicast Service in SDN/OpenFlow Environments Pornnipa Rattanawadee Wireless Network and Future Internet Research Group Department of Electrical Engineering Faculty of Engineering Chulalongkorn University Bangkok, Thailand Pornnipa.R@student.chula.ac.th Natchaphon Ruengsakulrach Faculty of Engineering Georgia Institute of Technology Atlanta, USA nruengsa@gatech.edu Chaiyachet Saivichit Wireless Network and Future Internet Research Group Department of Electrical Engineering Faculty of Engineering Chulalongkorn University Bangkok, Thailand chaiyachet.s@chula.ac.th Abstract—Software Defined Network has a centralized controller that regulates packet forwarding by updating flow tables of switches. The sole responsibility of these OpenFlow-enabled switches is to forward packets according to rules in their flow tables. The function of Software Defined Network is similar to the traditional IPTV protocol that there are Rendezvous Point be the intermediate node. Rendezvous Point is a node in the network that creates routing between servers and clients. This paper proposes an application of SDN/OpenFlow in IPTV multicasting implementation. An important function of IPTV multicasting is the Joint/Leave request of client in a multicast group. In order to obtain an efficient IPTV service routing, Dijkstra’s and Prim’s algorithms were used to comparatively calculate minimum total edge weight. Mininet environment is used to emulate our system, which consists of Open vSwitch and a POX controller. Our experiments compare the transmission time of the first joint/receive packet to a client when using Dijkstra’s and Prim’s algorithms. We define the edge weight as the distance between two adjacent nodes. Keywords—OpenFlow; IPTV multicast; Dijkstra’s algorithm; Prim’s algorithm I. INTRODUCTION Communication network is composed of interconnecting devices such as switches and routers. Traditional switches are self-learning. A self-learning switch broadcasts packets to discover other switches within the same network and associates MAC addresses of these neighbor switches with their interfaces. The switch’s packet broadcasting method could cause redundant traffic flows and delay routing time. There has been a research on OpenFlow to tackle this broadcasting problem. OpenFlow is a protocol used in Software Defined Networking or SDN, which utilizes a centralized controller. This controller controls packet routing by populating flow tables of the switches. Thus, the responsibility of switches in the OpenFlow network is to perform routing action on data packets according to their flow tables. IP multicast service is a popular technique for enhanced traffic efficiency, especially in Internet Protocol Television or IPTV multicasting. Several protocols have been designed to discover an efficient way to transmit multicast packets. One research proposes Hybrid Tree Based Explicit Routed Multicast or HT-ERM [1] which combines advantages of Rendezvous Point (RP) based shared tree and specific source based shortest path tree of traditional multicast network. HT- ERM improves multicast group’s admission control, reducing blocking ratio and delay time of channel switching. Another research proposes PIM-SM protocol [2], which eliminates unnecessary steps of changing from RP to Shortest Path Tree (SPT). The elimination allows packets to be efficiently transmitted without relying on central data node and consequentially minimizes bandwidth consumption. SDN researches are interesting, especially in the area of packet routing. One research proposes Green Minimum Spanning Tree (GreenMST) [3] which focuses on routing algorithm in SDN. The research aims to reduce an energy consumption of a forwarding device by using an SDN controller that implements Kruskal’s algorithm to calculate minimum spanning tree. Moreover, some researches extend to SDN application in delivering IPTV packets such as [4] a controller that re-routes when paths become congested. This can be achieved by having a switch provide its controller with a congestion message and traffic statistics. The result is fewer number of packets dropped due to overflow. Another research proposes Multiflow [5] which calculates an efficient route for multicast packets using Dijkstra’s algorithm. Multiflow uses Dijkstra’s algorithm to discover shortest paths, assigning edge weight based on the distance between two nodes. This Multiflow application matches with our interest. The traditional multicast protocols use RP as a center of the network to route and transmit data among servers and clients. Since the RP is a switch, its self-learning capability becomes its routing disadvantage. The RP spends a considerable amount of time to collect the data of other switches and calculate appropriate data transmission routes. Therefore, in this paper, we aim to improve the efficiency of IPTV multicast routing by applying central controller concept deployed in SDN. We deploy Dijkstra’s and Prim’s algorithms in the POX controller to calculate the shortest paths with delay time as the edge weight. Our POX controller This research has been supported by the Special Task Force for Activating Research (STAR) Funding in Wireless Network and Future Internet Research Group, Chulalongkorn University, Thailand, and is based on the collaborations of OF@TIEN project.
  • 2. has been designed to handle UDP packet sending and receiving among IPTV server and clients. II. IPTV MULTICAST SERVICE IN SDN/OPENFLOW A. Proposed model We propose an application of Multiflow model [5] as a part of routing algorithm in Fig.1. We apply Prim’s and Dijkstra’s algorithms to achieve minimum delay of UDP packet delivery between IPTV server and clients. We then compare the performance of Dijkstra’s and Prim’s algorithms in our POX controller. Server Client Network Equipments OF Controller Forward IGMP Query IGMP Query IGMP Join Flood IGMP Query to all switches Q U E R Y J O I N Forward IGMP Join Calculate route Forward rules to each switch Add rules into Flow table IGMP Leave L E A V E Forward IGMP Leave Remove client depart the group Forward remove client Delete rules depart Flow table Forward rules to each switch Add rules into Flow table Fig. 1. Multiflow model [5] The Multiflow model composes of three steps 1) IGMP query The IPTV server sends IGMP query to Open vSwitch to announce its service. The IGMP query packet is composed of IP multicast group. When the Open vSwitch receives IGMP query packet for the first time, it forwards the packet to the POX controller, which calculates the route of that packet and adds that route to the Open vSwitch’s flow table. 2) IGMP join When the client receives IGMP query packet and wishes to join the multicast group, it sends IGMP join packet to the nearest Open vSwitch. The IGMP join packet is then forwarded to the POX controller, where a user’s program performs route calculation. 3) IGMP leave When the client wishes to leave the multicast group, it sends an IGMP leave packet to Open vSwitch, which will forward the packet to the controller. The controller then removes the multicast route to the client from the flow table. TABLE 1. DIJKSTRA FUNCTION ALGORITHM Algorithm 1 Dijkstra function Input: R_G (set of Open vSwitches and port numbers) S (initial Open vSwitch), SW (set of Open vSwitches) Output: TREE (Dijkstra path) 1: let TREE be an empty dictionary 2: let Q be an empty list 3: for END is in R_G.keys(): 4: if S is END : continue 5: else : 6: call Dijkstra function and return value to DIJ and ROT 7: let PART be an empty list 8: while 1 : 9: add END to the end of PATH 10: if END = S : break 11: add value of END in ROT to END 12: reverse the elements of PATH 13: add the number of elements in PATH to LEN 14: for L in range (LEN-1) : 15: add the value of position L in PATH to SW1 16: add the value of position L+1 in PATH to SW2 17: if SW2 is None : continue 18: else : 19: add the value of G[SW1][SW2] to PORT 20: add set of SW1,SW2,PORT to TREE 21: return TREE TABLE 2. SHORTEST FUNCTION ALGORITHM Algorithm 2 Shortest function Input: G = (V,E), S (initial Open vSwitch), E (destination Open vSwitch) Output: DIJ,ROT 1: let G be the graph of proposed topology that composes of V, pair of nodes(Open vSwitch), and E, edge weight between 2 nodes 2: let N_W be the initial edge weight of node S, equal to {S,0} 3: let DIJ and ROT be an empty dictionary 4: for node v is in N_W : 5: let value of DIJ equal to N_W 6: if node v is node E : 7: break: 8: for node w is the value of node v in G : 9: find weight of (vi,wi) = DIJ[v] + weight of (v,w) in G 10: if node wi is already in DIJ : 11: if weight of (vi,wi) < the value of node w in DIJ : 12: show Value Error 13: elif node wi is not already in N_W or weight of (vi,wi) < value of node w in N_W : 14: add set of node wi and weight of (vi,wi) to N_W 15: add set of node vi and node wi to ROT 16: return (DIJ,ROT) B. Routing algorithms This paper proposes the use of Dijkstra’s and Prim’s algorithms to calculate shortest path tree of IPTV network. While Dijkstra’s algorithm finds the shortest paths of the chosen node to every other nodes resulting in the minimum distance tree from the chosen node, Prim’s algorithm finds the shortest paths among all nodes, represented as the minimum spanning tree.
  • 3. When the POX controller receives IGMP join packet for the first time, it calculates using the assigned routing algorithm. 1) Dijkstra’s algorithm There are two functions, Dijkstra and Shortest functions, in Dijkstra’s algorithm code, shown in Table 1 and 2, respectively. Dijkstra function defines the source and destination Open vSwitch pair, which is input into the Shortest function. The Shortest function then calculates the shortest path between the initial and destination Open vSwitches. Dijkstra function collects the shortest paths of all Open vSwitches to create Dijkstra path. 2) Prim’s algorithm We design Prim function to calculate Prim’s algorithm, shown in Table 3. The operation of Prim function relies on the heap function [6] to choose the minimum edge weight of the pair of Open vSwitches. Prim function collects the minimum edge weight of each edge to create Prim path. TABLE 3. PRIM FUNCTION ALGORITHM Algorithm 3 Prim function Input: G = (V,E), VER Output: MST 1: let G be the graph of proposed topology that composes of V, pair of nodes(Open vSwitch), and E, edge weight between 2 nodes 2: let VER be the list of Open vSwitches 3: let ADJ be an empty dictionary 4: for node n1, node n2, edge weight c in G : 5: add c, n1, n2 be the value of n1 to ADJ 6: add c, n2, n1 be the value of n2 to ADJ 7: let MST be an empty list 8: add the value of VER[0] to USED 9: add the value of ADJ[0] to EDG_U 10: convert EDG_U to heap function 11: while EDG_U : 12: return the smallest value of EDG_U to COT, N1, N2 and remove it 13: if N2 is not already in USED : 14: add N2 to USED 15: add COT, N1, N2 to the end of MST 16: for E in ADJ[2] : 17: if value of E[2] is not already in USED : 18: push E onto EDG_U 19: return MST III. RESULT A. Experiment Setup The software in the experiment are shown in Table 4 TABLE 4. SOFTWARES AND VERSIONS Software Version Mininet 2.2 OpenFlow 1.0 Open vSwitch 1.4.6 POX 3.0 In the experiment, Mininet, a network emulator, is used to create virtual hosts, switches, and controllers. We use POX controller, which is programmed in Python. Fig.2 and 3 illustrate the experimental network topology, which consists of two IPTV servers (h1,h2), four clients (h3- h6), twelve Open vSwitches (s1-s12) and an OpenFlow controller (c0). The POX controller connects with all Open vSwitches. This experiment measures transmission time between IPTV server 1 to each client. The POX controller can run one algorithm at a time. The method follows these steps below: Step 1: IPTV server 1 announces its service by sending IGMP query to adjacent Open vSwitches. The POX controller calculates the route of IGMP query, which is shown in Fig.2. Step 2: All clients send IGMP join packets to join the multicast group of IPTV server 1. The POX controller calculates routes and adds a flow entry to each Open vSwitch. The routes calculated by Dijkstra’s and Prim’s algorithms are shown in Fig.3. Step 3: IPTV server 1 sends UDP packet to each client. We use Wireshark to capture the transmission time between IPTV server and client. Fig. 2. IGMP packet routes Fig. 3. IPTV packet routes Dijkstra’s algorithm computes the minimum distance from the server to each client and returns a minimum distance tree from the server. Prim’s algorithm returns a minimum spanning, a tree which connects all nodes and keeps minimum overall distance. From Fig.3, the routes from IPTV server 1 to
  • 4. client 2 are different. The number of hops on the route obtained from Dijkstra’s algorithm is only 4 hops whereas that obtained from Prim’s algorithm is 6 hops (a) (b) (c) (d) Fig. 4. The time of client sends IGMP join and receives the first packet: (a) server 1 to client 1 , (b) server 1 to client 2, (c) server 1 to client 3, (d) server 1 to client 4. Fig. 5. The time of route calculation. B. Result and discussion The transmission time between IPTV server 1 to each client shown in Fig.4. The X-axis is the number of the experiments. We experiment by sending the joint/receive packet from IPTV server 1 to clients. For each client, we send 100 joint/receive packets. The Y-axis is the transmission time which composes of the time of route calculation and time of UDP packet delivery. The transmission time of Fig.4 (b) shows the result of packet transmission time from IPTV server 1 to client 2. The transmission time values of Prim’s algorithm are higher than Dijkstra’s algorithm around 4.9 milliseconds. The transmission times of client 4 conform to the number of hops in Fig.3 that Prim’s algorithm has the number of hops more than Dijkstra’s algorithm. In other case, the results show the same routes obtained from Prim and Dijkstra but little different in transmission time. This is because of different route calculation time of two algorithms. The route calculation time of two algorithms are also shown in Fig. 5. We performed experiments by sending joint packet 500 times. The average route calculation of Dijkstra’s algorithm is 1.53 milliseconds and the average route calculation of Prim’s algorithm is 0.37 milliseconds. Thus, the route calculation values of 2 algorithms are different around 1.16 milliseconds. IV. CONCLUSION AND FUTURE WORK This paper proposes an application of SDN/OpenFlow with IPTV multicasting application. In order to obtain an efficient IPTV service routing, Dijkstra’s and Prim’s algorithms are selected to comparatively calculate the minimum total edge weight. Our experiments compare the transmission time of the first joint/receive packet of client when using Dijkstra’s and Prim’s algorithms. We define the edge weight as the distance between two adjacent nodes. We can implement Dijkstra’s and Prim’s algorithm in POX controller to IPTV multicast service. This paper is the starting point of our IPTV experiment on SDN. The future experiment will involve a larger network topology and more IPTV servers/clients to test the limit of the POX controller in calculating routes. Transmission time will be analyzed and PSNR value will be used to determine the quality of videos sent from the IPTV server.
  • 5. ACKNOWLEDGMENT This research has been supported by the Special Task Force for Activating Research (STAR) Funding in Wireless Network and Future Internet Research Group, Chulalongkorn University, Thailand, and is based on the collaborations of OF@TIEN project. REFERENCES [1] C. C. Wen, C. S. Wu and M. T. Yang, “Hybrid Tree Based Explicit Routed Multicast for QoS Supported IPTV Service,” Global Telecommunications Conference, GLOBECOM 2009, IEEE, pp. 1-6, Nov-Dec 2009. [2] J. Ko, S. Park and E. Lee, “An Extended PIM-SM for Efficient Data Transmission in IPTV Services,” Proceeddings of 2010 2nd International Conference on Network Infrastructure and Digital Content, IC-NIDC 2010, pp. 115-119, September 2010. [3] L. Prete, F. Farina, M. Campanella and A. Biancini, “Energy efficient minimum spanning tree in OpenFlow networks,” European Workshop on Software Defined Networking, EWSDN, pp.36-41, October 2012. [4] P. McDonagh, C. Olariu, A. Hava and C. Thorpe, “Enabling IPTV Service Assurance using OpenFlow,” 27th International Conference on Advanced Information Networking and Applications Workshops, WAINA, pp.1456-1460, March 2013. [5] L. Bondan, L. F. Muller and M. Kist, “Multiflow: Multicast clean-slate with anticipated route calculation on OpenFlow programmable networks,” Journal of Applied Computing Research, vol.2, n.2, pp.68- 74, Jul-Dec 2012. [6] Heap queue algorithm [Online]. Avalible from https://docs.python.org/2/library/heapq.html