Get documents about "Performance Evaluation for Scalable Recursive Multicast Protocol using ns2 simulator
W
Shared by: ijcsiseditor
Categories
Tags
IJCSIS, call for paper, journal computer science, research, google scholar, IEEE, Scirus, download, ArXiV, library, information security, internet, peer review, scribd, docstoc, cornell university, archive, Journal of Computing, DOAJ, Open Access, May 2012, Volume 10, No. 5, Impact Factor, engineering, international, proQuest, computing, computer, technology
-
Stats
- views:
- 55
- posted:
- 6/22/2012
- language:
- English
- pages:
- 4
Document Sample
Performance Evaluation for Scalable Recursive
Multicast Protocol using ns2 simulator applications
important for internet are still
1 1
2 1
Jafar Ababneh, Firas E.Albalas, Nidhal Kamel Taha El-Omari, Abdel Rahman A.Alkarabsheh, Abd Alsalam Obiadat, 3[5],
1
open such as scalability [4], billing Mahmood Baklizi
address allocation [6] and security [7],
1
Faculty of science and information technology, The World Islamic Sciences and Education much
where the scalability has drawn
(W.I.S.E.) University, Amman, 11947, P.O. Box 1101, Jordan
attention among these issues.
1
{ jafar.ababneh, nidhal.omari, Ar.karabsheh}@wise.edu.jo
The main issue that causes the scalability
2
Faculty of science and information technology, Jadara University, Amman – Irbid main Road, the
problem is the increasing in the size of
21110 , P.O. Box 733, Jordan
Multicast Forwarding Table (MFT) because
2
falbalas@jadara.edu.jo
of the increase in multicast group members
3
National advanced IPV6 center (NAV6) university sains Malaysia,11800 USM, penang, malaysia
3
mbaklizi@wise.edu.jo, mbaklizi@nav6.org
or the increase in the number of multicast
ABSTRACT
groups. So there are two main aspects that
can be used to evaluate the scalability in
In multicast routing the scalability issue multicast protocols: scalability with regard
should be considered, this issue comes to the number of group members and to the
because the increasing in the size of the number of multicast groups in the network.
Multicast Forwarding Table (MFT) because Recently, there are a number of proposed
of the increase in multicast group members mechanisms to solve the scalability issue in
or the increase in the number of multicast multicast protocols, which can be
groups. SReM[1] is a multicast routing categorized into tunnelling techniques,
protocol that addressed this issue by forwarding state reduction and explicit
explicitly encode the building the multicast multicast.
tree.
An extensive evaluation performance is The main aim for this paper is to perform an
considered for this protocol in this paper. As extensive performance evaluation of a novel
a result, this protocol gave an improvement explicit multicast protocol; Scalable
in the scalability issue by minimizing the Recursive Multicast Protocol (SReM)
header size and gave an improvement in the [8];and compare this protocol with most
packet delivery ration and the end to end well-known explicit multicast protocols.
delay.
SREM Overview
INTRODUCTION
Due to the scarce resources in the Internet,
Due to the scarce of resources in the
multicast provides an efficient solution to
internet, multicast provides an efficient
use these recourses fully and efficiently.
solution to use these recourses fully and
Because of the explosive increasing in
efficiently. Also because of the explosive
traffic over the Internet, multicasting
increasing in traffic over the Internet,
became an important issue in routing
multicasting became an important issue in
protocols [2, 3]. Some issues are still open
routing protocols [2, 3]. Some issues
such as scalability [4], billing [5], address
allocation [6] and security [7], where the
scalability has drawn much attention for
Internet application.
In this paper a protocol called SReM[1] is
discussed and an extensive performance
Corresponding author. E-mail address: jafar.ababneh@wise.edu.jo
84 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
evaluation using ns2 simulator [9]is selection of Xcast+ is done for the following
considered. The basic idea behind SReM is reasons:-
to forward data between dynamically • Xcast+ is widely referenced in the area of
selected nodes called Branching Node explicit multicast protocols.
Routers (BNRs). Its goal is to reduce the • This protocol (Xcast+) is relatively close
state information kept for the multicast to the proposed protocol (SReM), so the
group members and to reduce the routing comparison will give good indication of
overhead by providing a local join/leave and the performance of SReM.
tree maintenance procedures using fixed size PERFORMANCE METRICS
messages. Hence, it is achieving higher
degree of scalability. A detailed description The following metrics are used to
and the detailed SReM process in joining evaluate the performance of proposed
and leaving nodes can be found in [1]and a work:-
detailed cost analysis for this protocol can
• Average Packet Header Size represents the
be found in [1].
size of the header included in the data
PERFORMANCEEVALUATION packet in bytes. It represents the size of
each data packet header in order to deliver
Performance evolution is an idea used to this packet to all destinations.
measure and evaluate the performance of • Average End To End Delay: is the average
routing protocols. The simulation runs on time that takes the data packet sent by
different scenarios and evaluating different source node to reach its destination node.
metrics. The results obtained from this part Total end to end delay = SUM (time_received(pkt) –
of evaluation are also compared with other time_sent(pkt)) for all data packets
protocols in the same area of SReM.
Avg. End To End Delay (AED) = Total end to end
SIMULATION ENVIROMENT delay / no. of data packets received
The proposed protocol is implemented using SIMULATION RESULTS
ns2 simulator [9] (version 2.29). The
The simulation results will be discussed in
simulation environment consists of 60
this section, this discussion is organized
nodes, these nodes represent the number of
with regard to the metrics used for protocol
LMRs, and each LMR can carry any number
evaluation. At each part, the results are
of receivers depending on its configuration.
presented in figure form and then a
In our simulation, each LMR can connect up
discussion and explanation for these figures
to 10 receivers so the maximum number of
is mentioned.
receivers is 600 nodes. The number of Packet header size
multicast group members (LMRs) varies
from 5, 10, 15, 20, 25, 30, 35, 40, and 45 Figure 1 shows the results obtained for the
nodes; these nodes represent LMRs in first part of packet header size evaluation. It
SReM and Designated Router (DR) for can be noticed that SReM has got static
xcast+ protocol. header size even when the group size is
Traffic generation considered at this increasing. This result comes because
simulation is CBR traffic with payload size whatever the group size SReM will only
512 bytes. Data packets are generated at include the next Branching Node Router
source at a rate of 8 packets per second; this (BNR) addresses in the header of each data
will introduce 4096 byte per second. Each packet. In Xcast+ the results show that an
simulation runs for 200 second. exponential increase of header size when the
In this protocol evaluation, SReM is group size increases. In conclusion, SReM
compared with Xcast+ protocol, the improve the scalability feature because the
Corresponding author. E-mail address: jafar.ababneh@wise.edu.jo
85 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
header size is constant even when the group Delay
size increases. 8
7
Header size for data packets initialized in the source 6
node
5
D elay(s)
SReM
200
4
Xcast+
3
Header Size (Bytes)
150
2
SREM
100 1
Xcast+
0
50 5/50 10/100 15/150 20/200 25/250 30/300 35/350 40/400 45/450
Group size(LM Rs/Receivers)
0
5/50 10/100 15/150 20/200 25/250 30/300 35/350 40/400 45/450
Group Size (LM Rs/Receivers)
Figure(3) End to End Delay.
CONCLUSION
Figure (1) Extra packet header size as a function of group
size In this paper a performance analysis study is
The results for the second part of evaluation done for SReM[1]. SReM is a scalable
is shown in Figure 2, the size of packet multicast protocol for fixed networks. The
header for SReM increases slightly but in scalability issue is an important feature for
Xcast+ a high increase of packet header is wireless networks.
happens again. This result proofs that SReM The performance analysis shows that SReM
improves the scalability feature in wired scales well when the multicast group size
networks. becomes large. The results show that SReM
performs a fixed header size in data packets
Header size for each received data packet
where the header size for Xcast+ protocol
250
increases exponentially when the group size
200
Header size (Bytes)
150 xcas t++
increases. These results show that SReM
100 SReM
improves the scalability feature in networks.
50
Other results obtained shows that SReM
0
performs less end to end delay and overhead
5/50 10/100 15/150 20/200 25/250 30/300 35/350 40/400 45/450
Group size (LM Rs/Receivers) in addition to scalability feature.
Figure (2) Average header size as function of group
size REFERENCES
End To End Delay 1. Cao, Y. and K. Al‐Begain. SREM: A Novel
Multicast Routing Algorithm‐
Figure 3 shows the average end to end Comprehensive Cost Analysis. in5th
delays as a function of group size with error World Wireless Congress (WWC 04).
rate because of random generation for 2004. San Francisco, USA.
simulator. The bigger value of delay the less 2. Ballardie, T., P. Francis, and J.
efficient the protocol. In reality, SReM Crowcroft, Core Based Trees (CBT) An
shows lower delay in comparison with Architecture for Scalable Inter‐Domain
Xcast+. This is because scalability feature in Multicast Routing. Computer
SReM make the intermediate nodes to Communication review, 1993. 23: p. 85‐
forward the data packets faster where in 85.
Xcast+ the data packets will take high 3. Waitzman, D., C. Partridge, and S.E.
processing time in the intermediate nodes Deering, Distance Vector Multicast
which lastly will increase the delay for the Routing Protocol.RFC Editor 1075 ,
data packets arrival at the end nodes. United States, 1988.
4. El‐Marakby, R. and D. Hutchison.
Scalability Improvement of the Real‐
Corresponding author. E-mail address: jafar.ababneh@wise.edu.jo
86 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
time Control Protocol (RTCP) Leading to avoidance at network routers using discrete and
Management Facilities in the Internet. continuous time, also his research interests
inComputer Communications. 2005. includes computer networks design and
5. Dondeti, L., et al. MBA: a tool for
architecture, wire and wireless communication,
multicast billing and accounting.
inProceedings Sixth IEEE Symposium on artificial intelligence and expert system,
Computers and Communications. 2001. knowledge base systems, security systems, data
6. Bhattacharyya, S., D. Towsley, and J. mining and information.
Kurose. The loss path multiplicity
problem in multicast congestion
control.in18th Annual Joint Conference
of the IEEE Computer and
Communications Societies INFOCOM'99.
1999.
7. Judge, P. and M. Ammar, Security issues
and solutions in multicast content
distribution: a survey. IEEE Network,
2003. 17(1): p. 30‐36.
8. Al‐Begain, K., Y. Cao, and K. Alameh, A
DBT‐Based Mobile Multicast Protocol.
Systems Communications., 2005: p.
255‐260.
9. The network simulator ‐ NS2 in
URL:http://www.isi.edu/nsnam/2005.
Authors Information
Dr. jafar Ababneh is an
assistant professor. He received
his PhD degree from Arab
Academy for Banking &
Financial Sciences (Jordan) in
2009. He received his M.Sc
degree in computer engineering from University
of the Yarmouk (Jordan) in 2005. He earned his
B.Sc in Telecommunication engineering from
University of Mu'ta (Jordan) in 1991. In 2009, he
joined The World Islamic Sciences and
Education (WISE) University as a head of the
departments of computer information systems
and network systems in the school of
information technology(CISN). He has published
many research papers and book chapters in
different fields of science in refereed journal
and international conference proceedings.
His field research lies in development
and performance evaluation of multi‐queue
nodes queuing systems for congestion
Corresponding author. E-mail address: jafar.ababneh@wise.edu.jo
87 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
Related docs
Other docs by ijcsiseditor
Digital Images Encryption in Spatial Domain Based on Singular Value Decomposition and Cellular Automata
Views: 0 | Downloads: 0
Agent Behavior in Multiagent Systems: Issues and Challenges in Design, Development and Implementation
Views: 1 | Downloads: 0
Optimizing Cost, Delay, Packet Loss and Network Load in AODV Routing Protocols
Views: 2 | Downloads: 0
