Content uploaded by Imad J. Mohammed
Author content
All content in this area was uploaded by Imad J. Mohammed on Nov 07, 2017
Content may be subject to copyright.
Research Journal of Applied Sciences, Engineering and Technology 14(10): 361-371, 2017
DOI:10.19026/rjaset.14.5128
ISSN: 2040-7459; e-ISSN: 2040-7467
© 2017 Maxwell Scientific Publication Corp.
Submitted: December 12, 2016 Accepted: March 19, 2017 Published: October 15, 2017
Corresponding Author:
Saif S. Shihab, Computer Science Department, College of Science, Baghdad University, Baghdad, Iraq
This work is licensed under a Creative Commons Attribution 4.0 International License (URL: http://creativecommons.org/licenses/by/4.0/).
361
Research Article
Optimization of IPv6 Protocol Independent Multicast-Sparse Mode Multicast Routing
Protocol based on Greedy Rendezvous Point Selection Algorithm
Saif S. Shihab and Dr. Imad J. Mohammed
Computer Science Department, College of Science, Baghdad University, Baghdad, Iraq
Abstract: Forming of the Multicast tree with the best root considered as center selection problem (typically
classified as NP-complete type). Alternatively called center Rendezvous Point (RP) due to the direct impact on the
multicast routing protocol in terms of the performance. This research article introduces a new compound solution for
multicast RP selection called Greedy based RP Selection Algorithm (GRPSA) to select the best RP for PIM-SM
multicast routing protocol in IPv6 multicast domain based on Fitness or cost criteria supported by Dijkstra
algorithm. The paperwork passes through two phases. First, MATLAB phase used for GRPSA implementation
assisted by Fitness calculation to select the best RP called Native-RP. The second phase investigates the
performance of GRPSA using QoS metrics compared to another candidate RPs. Validated using the GNS3 emulator
for the core IPv6 multicast network and realized using UDP streaming data sourced from Jperf traffic generator via
virtual machines at the network edges. The multicast technology implements a very high-efficiency point-to-
multipoint data transmission over IP networks (IPv4 and IPv6). The results show GRPSA-RP performs better than
other possible RPs by 25.2%, 25.3%, 46.2% and 62.9%, in terms of data received, bandwidth, jitter and loss
respectively on average.
Keywords: IPv6, multicast, PIM-SM routing protocol, Rendezvous Point (RP)
INTRODUCTION
The Rapid growth of Internet communications
continues to create new services and network
applications. Meanwhile, the massive growth in the
number of concurrent users who want simultaneously
access shared data in corporate intranets with
competitive cost drives the global Internet to provide
more shared services. In addition, many real-time
applications appeared, such as video conferencing,
audio, collaborative environments, IPTV (Lloret et al.,
2011). Most multicast applications include a source
send messages to a selected group of receptors, but the
broadcast and unicast network communication are not
optimal for this application kind. So appeared
technology called IP multicast (Bartczak and
Zwierzykowski, 2012; Joseph and Mulugu, 2011).
Multicast utilizes network infrastructure efficiently by
requiring the server or source to send out a stream of
packets only once to the multicast group’s address, the
nodes in the network take care of replicating the packet
to reach multiple receivers only where necessary
(Taqiyuddi et al., 2008). Moreover, the multicast can
scales to a larger receiver population by not requiring
prior knowledge of who the receivers are or how many
there are. In addition, multicasting preserves bandwidth
on the network and eliminates traffic redundancy. IP
multicast available for both versions of Internet
Protocols, IPv4 multicast and IPv6 multicast, but due to
the low address space of IPv4 cannot provide the
necessary support for multicast communication
multicast (Bartczak and Zwierzykowski, 2012; Joseph
and Mulugu, 2011). It may happen that multicast will
be the main driving force behind the widespread use of
the IPv6 protocol (Bilicki, 2006). Multicasting also
provides enhanced efficiency by controlling the traffic
on your network and reducing the load on network
devices. The clients on your network are able to decide
whether to listen to a multicast address, so packets only
sent to where they are required. In addition,
multicasting is scalable across different sized networks
but is particularly suited to WAN environments. It
enables people at different locations access to streaming
data files, like a video, film or lives presentation
without taking up excessive bandwidth or broadcasting
the data to all users on the network. Multicast
communication uses multicast distribution tree for data
routing. Typically, defined as either source or share
based tree. Source-based tree creates separate multicast
routing tree for each source, while shared multicast tree
creates one tree for the whole group and shared among
all sources. In addition, shared tree has an advantage
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
362
over source tree because only one routing table needed
for the group. Shared multicast trees require the
selection of a central router called "Core Point" in the
case of CBT multicast protocol (Ballardie, 1997) and
"Rendezvous point or RP" in the case of PIM-SM
(Fenner et al., 2006).
The current paper focuses on shared tree type using
PIM-SM in which the right selection of RP router is
very important and considered as an NP-complete
problem (Wang et al., 2010; Zappala et al., 2002),
which advised to be resolved with a heuristic algorithm.
Also, an optimized Greedy-based RP Selection
Algorithm (GRPSA) is proposed and implemented to
achieve the research contribution. It presents an
adaptive approach to evaluating the Defects and
Features of the multicast tree through considering both
cost and QoS factors, by realizing RP selection with the
local search algorithm.
Bartczak and Zwierzykowsk (2009) described the
comparison between different multicast routing
protocols for different approaches. It focuses on
similarities and differences between PIM-SM protocol
that uses source tree and PIM-DM protocol that practice
shared tree. The research covered IPv4 multicast only.
Wang et al. (2010) suggested tabu search algorithm
in PIM-SM multicast routing to select multicast RP
because PIM-SM uses shared tree and the main
problem is how to determine the position of the RP.
The algorithm selects multicast RP by considering both
cost and delay. The outcome of Wang’s proposed
algorithm indicates good performance in multicast cost,
ETE delay and having good expansion and practical
feasibility. However the paper doesn’t consider RP
reselection after the dynamic join and leave of group
members (Wang et al., 2010).
Youssef Baddi, Mohamed Dafer, introduces D2V-
VNS-RPS (Delay and delay variation constrained
algorithm based on Variable Neighborhood Search
algorithm for RP Selection problem in PIM-SM
protocol). This algorithm selects the RP router by
considering tree cost, delay and delay variation. The
main motivation behind the use of VNS search
algorithm was to solve core selection problem using
several neighborhoods to explore different
neighborhood structures systematically. Simulation
results show that D2VVNS-RPS got better average
delay compared to other tested algorithms such as
TRPS, DDVCA and Random. The algorithm shows the
less cost compared with the tested algorithms (Baddi
and El Kettani, 2012) but still, the experiments require
further validation using emulators behind simulators for
further QoS investigation such as throughput and
available bandwidth.
Youssef Baddi, Mohamed Dafer, presented 2DV
GRASP-RP (Delay and Delay Variation) algorithm
based on Parallel GRASP Procedure (Greedy
Randomized Adaptive Search Procedure) using PIM-
SM multicast routing protocol to select the right RP by
considering cost, delay and delay variation functions.
As a result, the algorithm shows good performance in
terms of multicast cost, end-to-end delay and other
aspects compared to other three algorithms; AKC,
DDVCA and Tabu RP Selection algorithm (or TRPS)
(Baddi and El Kettani, 2013). It focused on IPv4
multicast only.
Compared to the related works, the current paper
introduces further investigation to the effect of the right
RP selection on the performance of IPv6 multicast
domain using QoS metrics such as throughput,
available bandwidth, jitter and loss. Besides, a new
algorithm tested and a real traffic generator is deployed
for validation.
MATERIALS AND METHODS
Construction of IP Multicast tree and identifying
the right RP selection criteria could considered as two
most significant traffic-engineering factors in PIM-
SMmulticast performance. To achieve our optimization
target, the following steps discuss the proposed method:
Multicast PIM-SM problem and motivation: The
essential problem in building multicast routing tree is
how to find a low-cost tree covering all group members
plus the path from source. This problem was attributing
to a Steiner tree problem (Mehlhorn, 1988) in
mathematics and considered as an NP-complete
problem (Wang et al., 2010; Zappala et al., 2002). PIM-
SM divides the multicast tree into two sub-problems: an
RP selection problem and a routing selection problem.
RP selection using PIM-SM protocol classified into two
types: static and dynamic. When static selection is
active, the IP address of RP must define on all routers.
Unlike static, the dynamic depends on several ways, but
the most important is abootstrap router (BSR) (Bhaskar
et al., 2008). It works by sending the relevant
information comprising priority and IP address of
candidate-RP to all routers of the network. This
information obtained from candidate-RP that
willingness to be an RP. All routers use a hash function
to select one RP address based on IP address, priority
and hash-mask-length prepared by BSR. However,
these steps do not guarantee the selection of the best RP
position. In addition, the static and dynamic
mechanisms for RP selection designed without care of
cost (or distance of multicast group members). These
limitations motivate us for further research
contribution.
Basic greedy local search algorithm: A Local Search
(LS) algorithm is an iterative search procedure begins
from an initially suitable solution and this solution
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
363
Fig. 1: Pseudo code for basic greedy local search
improves progressively through execution a series of
local modifications (or moves). The search then
transitions to a “neighbor” that is “best” than the current
candidate solution according to an objective function.
The search halts when it faces a local optimum solution
in relation to the transformations that it considers. The
significant restriction of the method: unless one is quite
lucky, this local optimum is often a mediocre solution.
In LS, The quality of the solution obtained in addition to
the computing times is commonly highly dependent
upon the “richness” of the set of transformations
(moves) considered at each iteration of the heuristic
(Gendreau and Potvin, 2010). The basic LS (Eiben and
Smith, 2015) algorithm is described in Fig. 1.
The proposed algorithm GRPSA for RP selection:
The main goal of the proposed algorithm GRPSA is to
solve/optimize the RP selection problem in IP multicast
domain. The design, implementation and evaluation of
GRPSA are achieved by dividing the research work into
two phases; MATLAB phase for RP selection with the
best tree rout computationally. The last is performance
evaluation phase using GNS3-Jperf for testing and
validation in terms of QoS metrics such as, jitter, loss
and data received (Total throughput)with consideration
of available bandwidth.
The rest of this section discusses the MATLAB
implementation phase of GRPSA. Many transitions
followed to get the best RP selection guided by a
greedy approach based on the Fitness function. The
formulation of the fitness function depends on
assigning two weights; one weight signifies the impact
of the distance from the source node to the selected RP,
while the second weight determines the importance of
the distance between RP and the destination nodes. The
designed fitness function combines these two weights
together to find the fitness values Eq. (1). If the
calculated fitness for child-RP is smaller than the
corresponding value of the parent-RP, it will select the
child-RP as the new parent-RP, else parent-RP is
selected (no change in parent RP):
ܨ݅ݐ݊݁ݏݏ = ݓ
ଵ
∗ ݀݅ݏݐሺܵܿݎ, ܴܲ ሻ+ ݓ
ଶ
∗
ௗ௦ሺோ,௦௧
ሻ
సభ
(1)
where,
ݓ
ଵ
: The weight associated to the impact of
distance between source node and RP
ݓ
ଶ
: The weight associated to the impact of
distance between RP and a destination
node
dist ሺ݊1, ݊2ሻ: Shortest path distance between node n1
and n2.
Dest
: List of n destination nodes Dest =
{Dest
ଵ
,Dest
ଶ
,……Dest
}.
The following outline activities of GRPSA
algorithm, which are detailed next:
1. Set multicast topology (including source, receiver
and links)
2. Find adjacency matrix of the network.
3. Compute shortest path (using Dijkstra algorithm)
between every pair of nodes in the network
4. Randomly select an initial RP node (Parent-Rp)
from all network nodes for the 1
st
round of the
algorithm. The selected RP node should not belong
to the source or destination nodes.
5. Then calculates the fitness value for the selected
RP using Eq. (1).
6. RP mutation: It generates (Child-RP) from Parent-
RP. The mutation operator depends on the
proposed fitness function.
7. Calculate fitness of Child-RP.
8. Compare Parent-RP with Child-RP and select the
best one according to the fitness values.
9. Iteration = iteration + 1.
10. If (iteration<max iteration) go to step 6 else end.
In summary of MATLAB phase, GRPSA produces
the best-shared tree root (Native-RP) that optimizes the
routes along the paths from source to destinations via
the selected native-RP. The following pseudo-code
structure outlines GRPSA algorithm.
GRPSA algorithm (pseudo code)
Input:
AdjNet // Adjacency network represents adjacency nods
Src //Source node
Dest //Set of destination nodes
MaxRun //Maximum number of iterations
Output:
Native RP
//It is Rendezvous point identified based on fitness
values//represents the best shared tree root that
optimizes the routes//along the paths from source to
destination via this native-RP
Begin //main Func
//Apply Dijkstra Alg. Func to find the shortest distance
(cost)
Set Distance ← DijkstraShortestPath (AdjNet)
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
364
//Find best RP called Native-RP node that gives the
smallest fitness
For all Run Number Do (where 1≤RunNumber
≤MaxRun)
//Select initial RP node randomly
Set RP ← InitialRP (AdjNet, Distance, Src, Dest)
// find a 2
nd
candidate RP node and compute fitness
value for it
Set RP ←Greedy (AdjNet, Distance, Src, Dest, RP)
//Save RP node number and fitness values per each
RunNumber
Set BestRP (RunNumber) ← RP.Node;
Set BestFitness (RunNumber) ← RP.Fitness;
End For all RunNumber
// Sort the resulted candidate RP nodes in ascending
order //according to //their best fitness values and then
select the /node //(native RP) that gives minimum
fitness(i.e. the first minimum //fitness node)
Set RP.Node ← BestRP(1).Node
Set RP.Fitness ← BestFitness(1).Node
End main Func
…………………………………………………………
………….
FunctionInitialRP(AdjNet, Distance, Src, Dest)
Begin // Generate random node as initial RP node
Set RP←Rnd (Length (AdjNet))
// Repair RP if it belongs to Src or Dest
If Src = RP Or RP belongs to Dest Then
While RP = Src Or RP belongs to Dest Do
RP←Rnd(Length(AdjNet))
End While
End If
End InitialRP Func
…………………………………………………………
………….
// find a 2
nd
candidate RP node and compute fitness
value for it
Function Greedy (AdjNet, Distance, Src, Dest, RP)
Begin Set MaxIter ← 100;
ForallIterDo{where 1≤ Iter ≤ MaxIter }
//compute Mutate function to select a new RP
Set ChildRP ← Mutate(AdjNet, Distance, Source, Dest,
ParentRP, Iter,MaxIter)
// compute fitness value to evaluate RP node
Set RP ← Fitness(AdjNet, Distance, Src, Dst, RP)
If (ChildRP.Fitness < ParentRP.Fitness) then
ParentRP.Node ←ChildRP.Node
ParentRP.Fitness ← ChildRP.Fitness
RP←ParentRP.Node
Fitnes←ParentRP.Fitness
End //Greedy Func
…………………………………………………………
………….
// Mutate Func to select a candidate ChildRP
Function Mutate (AdjNet, Distance, Src, Dest,
ParentRP, Iter, MaxIter)
Begin // At earlier generations mutate is calculated from
whole
// AdjNet, whereas at late generations, mutate is
//calculated from neighborhood nodes
If ((Rnd>= (iter/MaxIter)) Then
Set RP←Rnd (Length (AdjNet))
Else
Set temp ← (Find (ParentRP, *) ==1)
Set child ← Temp (length (AdjNet))
End if
// Repair RP if it belongs to Src or Dest
If Src = RP Or RP belongs to Dest Then
While RP = Src Or RP belongs to Dest Do
RP←Rnd(Length(AdjNet))
EndWhile
EndIf
End Mutate
Func……………………………………………………
……………….
// compute fitness value to evaluate RP node
Function Fitness (AdjNet, Distance, Src, Dest, RP)
Begin
// set Weight to Src to RP and from RP to Dest based on
// assumed distances
Set wSrc2RP ← 0.5
Set wRP2Dest ← 1- wSrc2RP
// calculate Distance from Src to RP
Set DisSrc2RP ← Distance (Src, RP.Node)
// calculate Distance from RP to Dest
Set DisRP2Dest ← 0
Forall DstCounter Do{where 1≤ DstCounter ≤ length
(Dest}
DisRP2Dest ←DisRP2Dest+Distance(RP.Node, Dest
(DstCounter)
End for
// calculate Fitness
RP.Fitness←(wSrc2RP * DisSrc2RP +
wRP2Dest*DisRP2Dest)
End Fitness Func
To provide fairness as well as to maximize the
advantages of multicast among receptors. The design of
GRPSA assumes that the expected right RP (of the
multicast tree) found close to the middle distance (cost)
among the source and receptors. Thus, the RP distance
weight set to 0.5 in Fitness function.
Figure 2 to 7 depict the running process of the
GRPSA algorithm. It starts by generating a random
network topology with 20 nodes (Fig. 2). The symbolic
representation of graphs as follows: nodes in the figure
denote routers, whereas the directed edges stand for
directed links. The initial weights between source to RP
and between RP and destination are set to two
parameters; wSrc2RP = 0.5, wRP2Dest = 0.5
respectively. Node 11 represents source node (or
multicast server) marked with a solid square circle,
nodes 2,4,13,14,18 and 20 denote destination nodes,
marked with a solid triangle and candidate RP nodes are
marked with a solid black circle, child RP denoted by.
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
365
Fig. 2: Initial IPv6 multicast topology
Fig. 3: Nodes (19 and 6) selected as Parent-RP and Child-RP initially and randomly
Fig. 4: Node 6 becomes Parent-RP (the less fitness), and node 3 promoted as Child-RP
In Fig. 3, the trace for GRPSA implementation
shows that node 19 selected as Parent-RP, then node 6
as Child-RP initially and randomly (represents 1
st
two
rounds). The calculated fitness value for them are (10
and 8.5) respectively using Eq. (1). Through preferring
the minimum fitness value, node 6 replaces the current
Parent-RP (node 19) and starts the next search which
leads to promoting Node 3 as a new Child-RP as
illustrated in Fig. 4.
However, the calculated fitness of node 3 was (12)
which is greater than node 6 fitness (8.5), so node 3
discarded; as a result, node 6 stays as Parent-RP (Fig. 5).
Next, GRPSA search for the next Child-RP node, thus
node 16 is selected with calculated fitness value (8).
Byfitness comparison, node 16 got Parent-RP vocation
temporarily (8 less than 8.5), whereas node 9 promoted
as new Child-RP as shown in Fig. 6.
Next, GRPSA greedy algorithm continues
discovering all possible Parent-RPs of the topology.
Finally, node 1 selected by GRPSA as Native-RP since
it has a minimum Fitness value (7) as shown in Fig. 7.
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
366
Fig. 5: Illustration node 6 is still RP
Fig. 6: Node 16 stays as Parent-RP (the less Fitness), Node 9 selected as Child-RP with Fitness (10.5)
Fig. 7: Node 1 selected as final (Native-RP) with fitness = 7
Table 1. Illustrate the tracking of fitness values for both
the Parent and Child RPs per round until node 1 selected
as Native-RP represents GRPSA outcome.
GRPSA PERFORMANCE EVALUATION USING
GNS3 AND JPERF (QOS VALIDATION)
This section introduces the performance evaluation
phase using GNS3 and Jperf. The environment for more
complex tested network topology composes 20 virtual
Cisco 7200 routers interconnected via serial links as
shown in Fig. 8. Six virtual computers realized as
VMWARE virtual machines with 1GB RAM and 10GB
HDD per virtual machine. End-to-end connection
realized using the server as a source for UDP media
streaming, then received by clients over theIPv6
multicast network using GNS3. Window 7 is used in
virtual machines.
Typically, PIM-SM Multicast protocol depends on
unicast routing table to perform the reverse path
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
367
Table 1: Trace for GRPSA rounds to select the best RP based on fitness using Eq. 1 (Multicast topology in Fig. 2 to 7)
GRPSA Alg. round
Parent-RP
-------------------------------------------------------------------
Child-RP
-------------------------------------------------------------------
Node no. Fitness Node no. Fitness
Initial round 19 10 - -
Round 1 19 10 6 8.5
Round 2 6 8.5 3 12
Round 3 6 8.5 16 8
Round 4 16 8 9 10.5
Round 5 16 8 1 7
Round 6 1 7 15 9
Round 7 1 7 8 9
Round 8 1 7 7 13.5
Round 9 1 7 5 10
Round 10 1 7 17 15.5
Round 11 1 7 12 11.5
Round 12 1 7 10 8.5
Alg. Stop 1 7 - -
Fig. 8: IPv6 multicast network topology (one source and six receivers) using UDP streaming over GNS3 and JPERF
forwarding (RPF) check, which identifies the closest
interface of the multicast router to the source. Thus,
OSPF unicast protocol is used in the tested topology.
The GNS3setting and configuration steps for the tested
IPv6-multicast network topology are listed as follows:
Enable IPv6 and Multicast routing:
•
Enable IPv6 Unicast routing:
Router (config) # IPv6 unicast-routing
•
Enable multicast:
Router (config) #IPv6 multicast routing
• Configure OSPF unicast protocol:
The following two configuration commands
represent OSPF unicast routing protocol activated in
Router 1as a requirement of IPv6 PIM-SM protocol.
Router1 (config) # IPv6 routing ospf <1-65535>
process id
Router1 (config-router) # router-id 1.1.1.1
Moreover, the configuration commands (fragment)
of IPv6 addressing, OSPF and clock rate for Router 1
interfaces (serial and Ethernet) looks like:
Router1 (config) # interface fast Ethernet 0/0
Router1 (config-if) # IPv6 add 2001:1111:: 1/64
Router1 (config-if) # no shut
Router1 (config-if) # IPv6 ospf 1 area 0
Router1 (config) # interface serial 2/0
Router1 (config-if) # IPv6 add 2001:2222::1/64
Router1 (config-if) # no shut
Router1 (config-if) # clock rate 1612800
Router1 (config-if) # IPv6 ospf 1 area 0
Router1 (config) # interface loopback 0
Router1 (config-if) # IPv6 add 2001:DB8:1::1/64
Router1 (config-if) # IPv6 ospf 1 area 0
Router1 (config) # interface serial 2/1
Router1 (config-if) # IPv6 add 2001:5555::1/64
Router1 (config-if) # no shut
Router1 (config-if) # clock rate 1612800
Router1 (config-if) # IPv6 ospf 1 area 0
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
368
Configure IPV6 PIM-SM: RP in PIM-SM acts as
shared root between source and receiver of multicast
data streaming. Typically, RP can configure in
multicast IPv6 using three ways; static-RP, Embedded-
RP, or BSR-RP. The core design for all of these ways
does not care or irresponsive of best RP selection. The
focus of this study on is priority-based BSR-RP
configuration. Basically, candidate-BSR router selected
randomly and configured manually indoors of the
multicast network. Where the Candidate-BSR with
highest-priority must elect, which in turn informs the
rest routers of the network using BSM (Bootstrap
message) to response once any of them configured as
candidate-RP. Also, candidate RPs are selected
randomly and configured manually.
Furthermore, the job of the selected BSR is to
distribute information among candidate-RPs inside the
network using BSM (such as RP address, priority,
group IPv6 address and a hash mask length between 0-
128 for IPv6). Finally, all network routers use a hash
function to select the native-RP under the control of
BSR. However, most probably the process outcomes a
native-RP that is not the right RP selection. For that, it
is expected that the proposed algorithm GRPSA may
well contribute and stretch the BSR job for better or
optimum Native-RP selection.
For example, the Configuration steps for two
candidates as BSR and RP with their priority are
defined bellow respectively:
• Configuration command for Candidate-BSR
with priority 20:
Router (config) # ipv6 pimbsr candidate
bsr<Candidate-BSR IPv6 address> priority 20
• Configuration command for Candidate-RP with
priority 5:
Router (config) # ipv6 pimbsr candidate RP
<Candidate-RP IPv6 address>priority 5
Configure IPv6 MLD-join multicast group: Since
IPv6 is activated in the tested multicast topology. Each
router-interface connected to the multicast receiver
must configure with MLD (multicast listener discovery)
protocol to understand the join or leave commands
within the multicast group. The configuration command
for MLD is:
Router (config-if) # IPv6 MLD join-group FF08:8::1
Deployment of Jperf traffic generator for QoS
validation: The Source denoted in Fig. 8 is configured
as a multicast source (server) for UDP traffic streaming
received by the rest Receivers (Receivers: 1-6), all
configured as a multicast group (Fig. 8). Jperf server
generates CBT/UDP multicast traffic that passes
through theGNS3 core network and then received by
Jperf receivers at the other end of the network. Jperf
setting parameters conclude UDP bandwidth which set
to 700 kbps, TTL set to 128 and the IPv6-multicast
group set to FF08:8::1. The main concern is how to
evaluate the QoS metrics for different cases of RP
selection compared to or validates GRPSA-RP
selection.
RESULTS AND DISCUSSION
The keynote that characterizes the current research
is that it focuses on the fact, which says the output of
any available RP selection algorithms would be one of
the possible RPs within a multicast network under
investigation. For the sake of performance, evaluation
and competition among other developed RP selection
algorithms, the authors of current research believe that
the results should compare using two factors. The first
compare it to the optimally calculated RP selection,
whereas the second should compare it to the average of
all possible RPs (which may choose by whatever RP
selection algorithms).
The result obtained from six receivers and one
source for the same multicast group through a 5-
minutes period (Table 2 and 3). The tested IPv6
multicast topology composes 20 routers except for the
source and receivers. Table 2 shows the setting of
server side for the generated UDP streaming traffic.
Since GRPSA promoted router 19 as Native-RP or best
RP selection using MATLAB. Table 3 shows the effect
of selecting RP by GRPSA algorithm compared to the
average of rest possible RPs in terms of the data
received (Total throughput)in KB, Bandwidth
(Average)in kbps, jitter in ms and the percentage of lost
datagrams over the total sent datagrams. The traffic
comparison covers the six receivers from one multicast
source. When GRPSA-RP considered (Node 19), it was
noted that receiver no. 5 got the maximum traffic
support (data received is 23590 out of 24881 KB with
5.2% loss) compared to the less received traffic by
receiver 6 (received 19611 out of 24881 KB with 21%
loss). Whereas when the average received traffic of the
other possible RPs is considered, it was found that the
maximum advantage in receiving UDP streaming got at
got at receiver 3 (received 18001 out of 23907 KB with
25% loss) compared to the less traffic received at
receiver 6 (15150 out of 23907 KB with 37% loss). The
variation in data received due to the difference in path
distances from the RP to each receiver including the no.
of hops.
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
369
Table 2: Server side (source)
Source RP Transfer (KB) Bandwidth (kbps) Sent data grams
Source Native-RP using GRPSA (node 19) 24881 679 17382
Average of rest RPs 23907 653 16654
Table 3: Receivers side (Receivers 1 -6)
Receiver RP Data Received (KB) Bandwidth (kbps) Jitter (ms) (Lost/ Datagram)
Rcvr1 GRPSA-RP Node 19 22125 604 28.65 11 %
Avg. of rest RPs 17208 469 49.08 28 %
Rcvr2 GRPSA-RP Node 19 23556 643 12.94 5.3 %
Avg. of rest RPs 16421 448 33.93 31 %
Rcvr3 GRPSA-RP Node 19 19989 545 19.99 20 %
Avg. of rest RPs 18001 491 32.04 25 %
Rcvr4 GRPSA-RP Node 19 23079 630 24.1 7.2 %
Avg. of rest RPs 15596 425 43.05 35 %
Rcvr5 GRPSA-RP Node 19 23590 644 13.98 5.2 %
Avg. of rest RPs 16334 445 34.76 32 %
Rcvr6 GRPSA-RP Node 19 19611 535 25.57 21 %
Avg. of rest RPs 15150 413 39.70 37 %
Fig. 9: GRPSA-RP vs. other-RPs (Data received for 6 receivers in KB)
Fig. 10: GRPSA-RP vs. other-RPs (Throughput for 6 receivers in kbps)
Fig. 11: GRPSA-RPs vs. other-RPs (Jitter for 6 receivers in msec.)
Figure 9 to 12 show the results summary for the
comparison between GRPSA-RP selection compared to
the average results for the rest RP selection in terms of
QoS parameters represented by data received (Total
throughput), Bandwidth (Average), jitter and
datagramloss respectively. The results in all tested QoS
parameters shows GRPSA-RP wins the average of the
rest possible RPs.
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
370
Fig. 12: GRPSA-RP vs. other-RPs (Data loss for 6 receivers using %)
Fig. 13: GRPSA-RP vs. other-RPs) based on the four QoS
metrics for 6 receivers (on average as %)
Figure 13 shows GRPSA-RP versus other-RPs
based on the four QoS metrics for 6 receivers (on
average). The noticed gain in Jitter (decreased up to
46.2%) with less datagram loss (decreased up to
62.9%). Both contributed to the increase of data
received (Total throughput) at the 6 receivers on
average (25.2%) with average bandwidth up to (25.3%).
CONCLUSION
This study introduced a new deployment for IPv6
greedy algorithm called GRPSA based on Fitness
criteria to solve RP-selection problem for theIPv6
multicast domain. This minimization problem
considered as an NP-complete problem that requires
further research investigation. The MATLAB
implementation test of the proposed algorithm
(GRPSA) depicts the behavior and calculation for
finding the best or Native-RP choice among other
possible RPs. This choice validated using GNS3
supported with Jperf based on QoS metrics. It is found
that the right selection of RP router is very significant
due to the direct impact on the tree structure rooted by
RP. Furthermore, it affects the performance
of multicast routing protocol. Consequently, the
received quality and quantity of multicast streaming
traffic shows variations in data received(Total
throughput),Bandwidth (Average),jitter anddatagram
loss, with the distinguished result using GRPSA-RP
comparatively. Finally, to save the cost calculations, it
could mix the GRPSA target in selecting the best RP
for IPv6 multicast with anexisting routing protocol such
as OSPF as future work.
REFERENCES
Baddi, Y. and M.D.E.C. El Kettani, 2012. VNS-RP
algorithm for RP selection in multicast routing
protocol PIM-SM. Proceeding of the IEEE
International Conference on Multimedia
Computing and Systems (ICMCS).
Baddi, Y. and M.D.E.C. El Kettani, 2013. Parallel
GRASP algorithm with delay and delay variation
for core selection in shared tree based multicast
routing protocols. Proceeding of the IEEE 3rd
International Conference on Innovative Computing
Technology (INTECH).
Ballardie, A., 1997. Core Based Trees (CBT version 2)
multicast routing--protocol specification. Inter-
Domain Multicast routing, 1997
InternetDraft,<draft-ietf-idmr-cbt-spec-v2.txt.
Bartczak, T. and P. Zwierzykowski, 2009. Validation of
PIM DM and PIM SM protocols in the NS2
network simulator. Proceeding of the IEEE
AFRICON 2009.
Bartczak, T. and P. Zwierzykowski, 2012. Performance
evaluation of source-specific multicast routing
protocols for IP networks. Proceeding of the 8th
International Symposium on Communication
Systems, Networks and Digital Signal Processing
(CSNDSP).
Bhaskar, N., A. Gall,J. Lingard and S. Venaas, 2008.
Bootstrap Router (BSR) mechanism for Protocol
Independent Multicast (PIM). Network Working
Group.
Bilicki, V., 2006. Testing and verifying an ipv6 based
multicast network. Proceeding of the IEEE
International Multi-Conference on Computing in
the Global Information Technology (ICCGI'06).
Eiben, A.E. and J.E. Smith, 2015. Introduction to
Evolutionary Computing. 2nd Edn., Springer-
Verlag, Berlin, Heidelberg.
Res. J. Appl. Sci. Eng. Technol., 14(10): 361-371, 2017
371
Fenner, B., M. Handley, H. HolbrookandI. Kouvelas,
2006. Protocol independent multicast-sparse mode
(PIM-SM): Protocol specification (revised).
Network Working Group, Retrieved from:
https://tools.ietf.org/html/rfc4601.
Gendreau, M. and J.Y. Potvin, 2010. Handbook of
Metaheuristics. 2nd Edn., Springer, New York.
Joseph, V. and S. Mulugu, 2011. Deploying Next
Generation Multicast-enabled Applications: Label
Switched Multicast for MPLS VPNs, VPLS and
Wholesale Ethernet. 1st Edn., Morgan Kaufmann,
Waltham, MA.
Lloret, J., M. Garcia, A. Canovas and C. Turro, 2011. A
stereoscopic video transmission algorithm for an
IPTV network based on empirical data. Int. J.
Commun. Syst., 24(10): 1298-1329.
Mehlhorn, K., 1988. A faster approximation algorithm
for the Steiner problem in graphs. Inform. Process.
Lett., 27(3): 125-128.
Taqiyuddi, A., M.Z. Arifin, A.H. Abdalla, F. Anwar
and S. Al-Irhayim, 2008. A comparative study of
source specific multicast and aggregated source
specific multicast. Proceeding of the IEEE
International Conference on Computer and
Communication Engineering (ICCCE, 2008).
Wang, H., X. Meng, M. Zhang and Y. Li, 2010. Tabu
search algorithm for RP selection in PIM-SM
multicast routing. Comput. Commun.,33(1): 35-42.
Zappala, D., A. Fabbri and V. Lo, 2002. An evaluation
of shared multicast trees with multiple cores.
Telecommun. Syst., 19(3-4): 461-479.
