A Performance Comparison of Multicast Routing Protocols ... - CiteSeerX

0 downloads 0 Views 43KB Size Report
MANETs do not support multicast communications, even though wireless links ... to reconnect the tree; if it fails a global reconnect procedure is used. Moreover ...
A Performance Comparison of Multicast Routing Protocols In Ad hoc Networks Hasnaa MOUSTAFA and Houda LABIOD ENST - INFRES Department - 46 Rue Barrault – 75634 Paris cedex 13 – Paris - France Tel: +33 (0) 1.45.81.74.36 Fax: +33 (0) 1.45.81.31.19 Email: [email protected] , [email protected]

Abstract Multicast Routing in Mobile Ad hoc NETworks (MANETs) is a recent research topic. In this paper, we present a performance study of three multicast protocols: ODMRP, ADMR, and SRMP. Source Routing-based Multicast Protocol (SRMP) is a new on-demand multicast routing protocol that applies a source routing mechanism and constructs a mesh to connect group members. The strength of SRMP lies on its nodes selection criteria during mesh construction. Instead of using the shortest path as most of the other protocols, SRMP provides paths in terms of connectivity strength, higher battery life, and links’ availability. A performance comparison with ODMRP and ADMR shows that SRMP provides better route lifetime and battery lifetime. Keywords: multicast routing, mobile ad hoc networks, forwarding-group-concept, link availability, energyconserving.

I.

Related Work

Ad hoc communication concept allows users to communicate with each other in a temporary manner with no centralized administration and in a dynamic topology that changes frequently. Each node participating in this network acts both as a host and a router and must therefore be willing to forward packets for other nodes. For this purpose, routing protocols used in wired networks are not appropriate and there is a need for new routing protocols. Despite the fact that nodes in ad hoc networks are often very limited in resources (CPU capacity, storage capacity, battery power and bandwidth), a fundamental challenge in the design of such networks is the development of routing protocols fulfilling some key features like robustness, simplicity and energy conserving. Through extending the multicast technology to the ad hoc domain, applications such as videoconferencing, distributed games and computer supported collaborative work can be provided with enhanced performance thanks to the optimization of network resources. However, most MANETs do not support multicast communications, even

though wireless links have a broadcasting nature suitable to such communications. To provide efficient multicast routing in MANETs, a different kind of protocols should be designed. These protocols should modify the conventional tree structure, or deploy a different topology between group members [1]. Some technical challenges of multicast routing are as follows [2]: minimizing network load, providing basic support for reliable transmission, designing optimal routes, providing robustness, efficiency, active adaptability, and unlimited mobility. Due to the complexity of multicast routing, few propositions have been made. Actually, we notice two main categories, tree-based protocols (e.g. MAODV, ADMR, ABAM) and mesh-based protocols (e.g. ODMRP, PatchODMRP). The multicast extension of Ad Hoc On Demand Distance Vector (MAODV) routing protocol [3] uses destination sequence number for each multicast entry requiring a lot of control messages. Associativity-Based Multicast Routing (ABAM) protocol [4] has been advocated to improve routing performance, based on choosing more stable routes. However, this method could not avoid frequent rerouting due to mobility of nodes. Adaptive Demand-Driven Multicast Routing (ADMR) protocol [5] creates source-based forwarding trees connecting each source with the receivers of the multicast group. The multicast forwarding state for a given multicast group and a source is conceptually represented as a loosely structured multicast-forwarding tree routed at the source. The forwarding mechanism is based on the shortest-delay path through the tree to the receiver members of the multicast group. A sequence number is included in the packet’s header. This sequence number uniquely identifies the packet and is generated as a count of all ADMR packets flooded in any way that originated from the source. Packets forwarding is based on two types of flooding: tree flood and network flood. Tree flood occurs among nodes of the multicast tree, this is indicated by the source address (original sender) and destination address (multicast group address) in the packet. While network flood is flooding among all nodes in the network. ADMR sends Keep-alive messages to maintain the existing forwarding state for the multicast distribution tree for the source and the group. The

absence of data packets and Keep-alive messages within a certain period of time is an indication of forwarding tree disconnection. Firstly, a local repair procedure is performed to reconnect the tree; if it fails a global reconnect procedure is used. Moreover, ADMR defines a pruning mechanism if a lack of passive acknowledgements from downstream nodes occurred. The On-Demand Multicast Routing Protocol (ODMRP) [6] is based on a mesh structure for connecting multicast members using the concept of forwarding group nodes. Flooding within the mesh is applied. ODMRP operates by periodically flooding control packets to create and maintain the multicast forwarding state. In particular, while a multicast source using ODMRP is active, the source periodically floods Join-Data control packets. A node receiving a Join-Data packet stores the upstream node ID (backward learning) and rebroadcasts the packet. When the Join-Data packet reaches a multicast receiver, the receiver creates a Join-Table and broadcasts it to the neighbors. A node receiving the Join-Table becomes a member of the forwarding group if the next node ID of one of the entries of the Join-Table matches its own ID. It then broadcasts its own Join-Table. Each forwarding group member propagates the Join-Table until it reaches the multicast source via the shortest path. This process constructs and updates the routes from the source to the receivers, building a mesh of nodes. Multicast sources refresh the membership information and update the routes by sending Join-Data periodically. Group maintenance takes place through a soft state approach. PatchODMRP [7] extends the ODMRP providing a more efficient way to deal with small number of multicast sources and high mobility. However, it still considers the shortest path criteria. Obviously, multicast routing is a young research domain, no standard has been adopted yet and many issues have to be addressed and more studies are needed. Actually, most existing multicast protocols face several problems in tree maintenance and frequent reconfiguration when link failures occur. These protocols depend on upstream and downstream nodes requiring storage and control overhead. Moreover, some protocols consider the shortest path as a criterion for path selection, which is not usually suitable to the high and unpredictable variation of the topology. In this context, we propose a new on-demand multicast routing protocol, named SRMP. Section II describes briefly SRMP. A performance analysis is outlined through relevant simulation results compared to ODMRP and ADMR in section III. Finally, section IV provides concluding remarks and highlights our future work.

II.

SRMP A. Motivation

Source Routing-based Multicast Protocol (SRMP), is an ondemand multicast routing protocol [8,9]. This protocol is

anchored on new idea exploiting source and mesh routing as well as ad hoc features in order to provide robustness against mobility, and improving delay and throughput. It guarantees nodes’ stability with respect to their neighbors, strong connectivity, availability of the used links and higher battery lifetime. The path availability concept allows the protocol to distinguish between available and unavailable paths according to wireless link quality and nodes’ stability. The higher battery life concept biases the protocol toward choosing a link that tends to power conserving. The combination of these two criteria allows the selection of available and power conserving links.

B. Protocol Overview SRMP is a mesh-based multicast routing protocol. A mesh structure (an arbitrary sub-network) is established ondemand to connect group members [10], providing richer connectivity among multicast members. By building a mesh, packets can be efficiently delivered to multicast receivers in the case of node movements and topology changes. In addition, drawbacks of multicast trees can be avoided (ex, intermittent connectivity, traffic concentration, frequent tree reconfiguration, non-shortest path in a shared tree). SRMP is based on a new source routing approach, in which the source route accumulates in the reply packet. The source routing concept is used by DSR unicast protocol [11], allowing each data packet to carry in its header the list of nodes’ addresses through which this packet must be transmitted. During mesh establishment, SRMP uses the Forwarding Group (FG) nodes concept [12]. The FG is a set of nodes responsible for forwarding multicast data between any member pairs. This scheme can be viewed as a “limited scope” flooding within a properly selected forwarding set. The key innovation of SRMP is to handle effective criteria in selecting FG nodes in order to achieve a compromise between the number of the selected nodes, the availability and the stability of the selected paths. Four metrics are considered to establish the mesh structure: association stability, link signal strength, link availability, and higher battery life [9]

C. Operation A request phase and a reply-phase comprise the protocol. The request phase invokes a route discovery process to find routes to reach the multicast group. Different routes to the multicast group are setup during the reply phase through FG nodes selection and mesh construction. SRMP maintains four data Structures: Neighbor_Stability_Table, Multicast_ Message_Duplication_Table, Multicast_Routing_Cache, and Reciever_Multicast_Routing_Table. The request phase starts when a source node, which is not a group member, wishes to join the group. It invokes a route discovery procedure towards the multicast group, through

broadcasting a Join-request packet to neighbors. To eliminate the possibility of receiving multiple copies of Join-request, each node detects duplication in reception and drops it. A reply phase starts at each multicast receiver receiving a Join-request. It first checks for stability among its neighbors based on the four selection metrics mentioned previously. A neighbor is selected as an FG node, if these metrics satisfy predefined thresholds. The receiver starts sending Join-reply messages to the selected neighbors setting their types as member nodes in its Neighbor_Stability_Table. Each neighbor, receiving a Join-reply, creates an entry in its Multicast_Routing_Cache for the multicast group setting its state as FG node and storing the reve rsed accumulated route in the received Join-reply. The source route from the multicast receiver to the requesting node is accumulated in a route record field in each Join-reply packet. The process continues until reaching the source of request constructing a mesh of FG nodes connecting group members. After group establishment, the source floods its data packets along the FG mesh via the routes stored in its Multicast_Routing_Cache towards the multicast receivers. Mesh refreshment in SRMP is a simple mechanism; it requires no extra control overhead. The multicast source refreshes the corresponding route entries in its Multicast_Routing_Cache for each data packet it transmits to the multicast group. Each FG node forwarding this packet scans the packet header for the used route, refreshing the corresponding route entry in the Multicast_Routing_Cache. In addition, a multicast receiver scans the header of each received data packet, refreshing the corresponding entry in the Receiver_Multicast_Routing_Table. SRMP reacts to nodes’ mobility on-demand, such that it detects link failure during data transmission through the use of MAC layer support. Two mechanisms are addressed: (a) link repair between two FG nodes, and (b) link repair between a multicast receiver and an FG node, making use of a Multicast-RERR message. In addition, SRMP employs an effective pruning mechanism allowing a member node to leave the multicast session. It deals with two cases: FG node pruning, and multicast receiver pruning. A multicast source revokes its member status simply through stopping data transmission, and removing entries concerning the group from its Multicast_Routing_Cache. A multicast receiver may prune itself by sending a Leave-Group message to all member neighbors, and deleting from its receiver table all corresponding entries.

III.

Performance Analysis

Network Simulator2 (ns2) is used, it is a discrete event simulator developed at Berkeley University targeted at networking research [13]. The aim of our performance analysis is to evaluate the behavior of SRMP and to compare its performance to both ODMRP and ADMR protocols. We chose ODMRP because it uses the mesh

structure in forwarding multicast packets, and ADMR as it is more classical based on using multicast forwarding trees.

A. Simulation Model and Scenarios The overall goal of our simulation study is to analyze the behavior of our protocol under a range of various mobility scenarios. Our simulations have been run using a MANET composed of 20 nodes moving over a rectangular 1200 m x 300 m space, and operating over 600 seconds of simulation time. The radio and MAC models used are described in [13]. Nodes in our simulation move according to the Random WayPoint mobility model [14]. The movement scenario files used in each simulation are characterized by pause times; we studied 6 different pause times (0, 30, 60, 120, 300, 600). A pause time of 600 represents a stationary network, while a pause time of 0 represents a network of very high mobility in which all nodes move continuously. Our performance evaluation is a result of 120 different simulations, using 20 different simulations for each pause time. At each pause time, we study runs with a max nodes movements’ speed of 20 m/s and others with a max nodes movements’ speed of 1 m/s. For each pause time and max nodes movements’ speed, we randomly generated 10 different scenarios. The multicast traffic sources in our simulation are constant bit rate (CBR) traffic. Each traffic source originates 64 bytes data packets, using a rate of 4 packets/second. We used two different combinations of number of multicast groups, sources, and receivers. In order to observe the behavior of the routing protocol in a simple environment, we considered a first scenario with 1 multicast source and 10 multicast receivers. The second scenario consists of 3 groups with 1 source and 3 receivers each.

B. Results and Analysis As a first step, we evaluated the performance of SRMP and compared it with ODMRP and ADMR in terms of end-toend delay, delivery ratio, and control packets and bytes overhead. The obtained results are illustrated in Figure 1 and Figure 2. Figure 1, shows the evaluation of the cited performance metrics as a function of pause time in the 1-source and 10 receivers scenario. Regarding the delivery ratio, ODMRP and ADMR shows nearly the same behavior. SRMP shows incremental delivery ratio starting from intermediate mobility, and outperforms ODMRP and ADMR starting from pause time 500, when the network tends to be stationary. This refers to the links’ quality compared to ODMRP and ADMR. The signal strength metric used in the selection criteria while constructing the mesh, allows SRMP links in this case to react better towards interference and distortion that is frequent in ad hoc environment. In case of continuously moving nodes and intermediate mobility nodes, SRMP exerts less delivery ratio with no great impact.

flood together with the overhead in its local and global repair mechanisms and the keep-alive messages adding to protocol overhead. On the contrary, SRMP shows few overheads thanks to its source routing approach. In fact, the use of extra header packets fields in ADMR and the large size Join-table in ODMRP compared to SRMP Join-reply packet, causes a worst performance compared to SRMP.

This returns to the fact of network flood use in ODMRP, which reduces the latency of link breakage discovery increasing the delivery ratio. Similarly, the use of tree and network flood in ADMR to forward multicast packets, together with the shortest-delay path, increase the delivery ratio. In terms of both packets and bytes overheads, SRMP provides better results. This is due to the frequent network flood use in ODMRP. For ADMR, this refers to the network Delivery Ratio

Delay

1,2

18 16

0,8

0,6

SRMP

0,4

ODMRP 0,2

SRMP

14

Delay (milliseconds)

Delivery Ratio

1

ODMRP

12

ADMR

10 8 6 4

ADMR

2

0

0 0

100

200

300

400

500

600

0

100

200

Pause Time

Packets Control O/H

300 Pause Time

400

500

600

Bytes Control O/H

4000

160000

3500

140000

3000

120000

ODMRP

2000

Bytes No.

Pkts. No.

SRMP 2500

ADMR

1500

100000

SRMP ODMRP

80000

ADMR 60000

1000

40000

500

20000

0 0

100

200

300 Pause Time

400

500

0

600

0

100

200

300 Pause Time

400

500

600

Figure 1: 1 source and 10 multicast receivers

able to assure more stable, longer route lifetime, and higher battery life paths consuming less energy compared to the other two protocols. Using these paths, the probability of links’ failure and paths reconstruction is minimized, minimizing the protocol’s overhead by a realized difference and providing more quality links reacting better in a radio environment.

Considering the transmission delay, ODMRP and ADMR show nearly the same behavior. SRMP shows an increase of delay in the case of very high mobility, this comes from the frequent application of the selection criteria to set up new links due to the high link failure rate. It is clearly noticed that this increase in delay drops fast with the little decrease in mobility. But thanks to these selection criteria, SRMP is Delivery Ratio

Delay

1

7

0,9

6 Delay (milliseconds)

Delivery Ratio

0,8 0,7 0,6 0,5 0,4

SRMP

0,3

ODMRP

0,2

ADMR

SRMP

5

ODMRP

4

ADMR

3 2 1

0,1 0

0 0

100

200

300

400

500

600

0

100

200

300

400

500

600

Pause Time

Pause Time

Bytes Control O/H

Packets Control O/H 10000

350000

9000

300000

8000

Bytes No.

Pkts. No.

SRMP

250000

7000 6000 5000 SRMP

4000

ODMRP

200000

ADMR

150000

ODMRP

3000

100000

ADMR

2000

50000

1000

0

0 0

100

200

300 Pause Time

400

500

600

0

100

200

Figure 2: 3 sources and 3 multicast receivers per source

300 Pause Time

400

500

600

For the 3 sources and 3 receivers’ scenario, SRMP depicts out nearly the same behavior as clearly illustrated in Figure 2. In particular, the delay difference with respect to ODMRP and ADMR is minimized compared to the first scenario. This is due to the lower number of receivers for each source, decreasing the delay consumed during paths’ selection. Moreover, SRMP outperforms ODMRP and ADMR at intermediate and low mobility, this refers to the strength and availability of the used links showing better effect for this mobility cases.

IV.

Conclusion and Future Work

In this paper, we introduce the Source Routing-based Multicast Protocol (SRMP). SRMP uses no periodic network flood of control packets. Thanks to its selection criteria in mesh construc tion, stable paths with future links availability and higher battery life are provided. This assures better quality of links and minimizes the possibility of links’ failure and the overhead needed to re-construct the paths. We have presented an initial performance evaluation of SRMP and compared it to ODMRP and ADMR protocols. Our protocol shows significant decrease in the control overhead; its impact on the delay is acceptable depending on the mobility type, and outperforming ODMRP and ADMR at intermediate and low mobility cases. SRMP provides an incremental delivery ratio starting from intermediate mobility. For future work, we intend to compare it with other multicast routing protocols, considering new performance metrics such as energy-based mobility and link stability metrics. We also intend to implement the protocol with different group mobility models that are suitable for multicast applications.

References [1] Sung-Ju Lee. “Routing and Multicast Strategies in Wireless Mobile Ad hoc Networks“, PhD Thesis, University of California, 2000. [2] K. Obraczka, G. Tsudik. “Multicast Routing Issues in Ad Hoc Networks“, IEEE International Conference on Universal Personal Communication (ICUPC’98), October 1998. [3] E. M. Royer, C. E. Perkins. “Multicast Operation of the Ad-hoc OnDemand Distance Vector Routing Protocol“, Proceeding of the fifth annual ACM/IEEE international conference on mobile computing and networking, pp. 207-218, 1999. [4] C-K. Toh, G. Guichal, and S. Bunchua. “ABAM: On-Demand Associativity-Based Multicast Routing for Ad Hoc Mobile Networks“, IEEE Vehicular Technology Conference 2000. 52nd Volume: 3, pp. 987-993, 2000. [5] J.G. Jetcheva, D. B. Johnson. “Adaptive Demand-Driven Multicast Routing in Multi-hop Wireless Ad Hoc Networks“, ACM MobiHoc 2001, Long Beach, CA, USA, 2001. [6] S. Lee, W. Su, and M. Gerla. “On -Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks“, ACM/Baltzer Mobile Networks and Applications, 2000. [7] M. Lee, Y. K. Kim. “PatchODMRP: An Ad-hoc Multicast Routing Protocol“, Proceedings of the 15th international conference on information networking, pp. 537-543, 2001.

[8] H. Moustafa and H. Labiod. “SRMP: A mesh-based protocol for multicast communication in ad hoc networks”, 3Gwireless'2002, may 28-31, 2002. [9] H. Moustafa and H. Labiod. “Source Routing-based Multicast Protocol for Mobile Ad hoc Networks”, Tenth International Conference on Telecommunication Systems Modeling and Analysis, October 03-06, 2002. [10] H. Labiod and H. Moustafa, “The Source Routing-based Multicast Protocol for Mobile Ad Hoc Networks (SRMP)”, Internet draft, IETF, November 2001. [11] D. Johnson, D. Maltz. “Dynamic source routing in ad hoc wireless networks”, in Mobile Comp uting, T. Imielinski and H. korth, Eds. Norwell, MA: Kluwer, 1996. [12] C. Chiang, M. Gerla, and L. Zhang. “Forwarding Group Multicast Protocol (FGMP) for Multihop, Mobile Wireless Networks “, Baltzer Cluster Computing, Vol.1, no. 2, pp. 187-196, 1998. [13] K. Fall and K. Varadhan. “NS Notes and Documentation”. The VINT project, UC Berkeley, LBL, USC/ISI, and Xerox PARC, May 1998. Work in progress. [14] C. Bettstetter, H. Hartenstein, and X. Pérez-Costa. “Stochastic Properties of the Random Waypoint Mobility Model: Epoch Length, Direction Distribution, and Cell Change Rate”, ACM MSWiM’02, 2002.