Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No.

5 & 6, 2006

A Low-Overhead DVR Based Multicast Routing Protocol for Clustered MANET

B. Gupta, S. Rahimi, R. Jandhyala, and V. Doraiswamy Department of Computer Science, Southern Illinois University, Carbondale, IL 62901-4511, U.S.A. E-mail: [bidyut, rahimi]@cs.siu.edu Abstract Recently an efficient clustering protocol has been reported [1] for mobile ad-hoc networks (MANET). The proposed clustered network has been shown to be more stable than the clustered networks as reported in [3] and [4]. In this paper, we have proposed a distance vector based multicast routing protocol for MANETs that are clustered following the idea of [1]. The proposed scheme needs much less amount of information exchange compared to the distance vector routing scheme designed for unclustered network. Because of significant reduction in distance vector routing table size and its adaptable nature to the changing ad-hoc network topology caused by node mobility this proposed multicasting routing protocol has been shown to offer efficient utilization of both limited memory and bandwidth for MANET. Besides, we have also shown how our clustered network can offer efficient resource utilization when CBT routing strategy is used. Keywords: Mobile Ad Hoc Network, Clustering, and Multicast Routing. 1. Introduction Recently some protocols have been reported [3], [4] for dynamically organizing mobile hosts in a mobile ad-hoc network (MANET) [2] into clusters. The main objective of these cluster protocols is to aid in routing. The work in [4] has considered clusters in which every node in a cluster is in the transmission range of every other node in the same cluster. Nanda et.al. [3] have proposed a clustering scheme in which the basic cluster unit is same as in [4]; This work [3] offers smaller number of control messages generated compared to [4] for communication. In [1] a clustering protocol completely different from the above two has been proposed in which the diameter of a cluster is at most 2N (N is a positive integer), a parameter that can be set by the network designer before the network is booted. This protocol [1] offers (a) higher cluster stability than [3], [4] from the viewpoint of the number of new clusters formed out of an existing cluster due to node mobility, and (b) lower number of control message exchanges needed than in [3] when a new node wants to join an existing cluster. In this paper we have considered this kind of clustered mobile ad-hoc networks [1] for its above mentioned advantages and have presented a distance vector based multicast protocol for MANET. This protocol offers much less information exchanges between any two neighboring nodes compared to the distance vector routing (DVR) scheme [5] designed for unclustered networks, thus ensuring efficient utilization of both limited memory of mobile hosts and limited wireless bandwidth. Besides, the presented routing protocol always chooses a better path, if any exists, to reach clusters. We have also discussed how our clustered network can offer efficient resource utilization when CBT routing strategy [6] is used. This paper is organized as follows. Section 2 introduces briefly the architecture of the clustered MANET (a detailed description of the network as well as the cluster formation rules are out of the scope of this paper and can be found in [1]). Section 3 contains the data structures

135

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

needed for multicast routing. In Section 4 we have presented the multicast routing protocol together with an illustration and finally Section 5 draws the conclusion. 2. Architecture A cluster is constructed, maintained, deformed, etc by the movement of the mobile hosts. The cluster restructuring is governed by the data structure, called Cluster Connection (CCT) Packet that is periodically exchanged among the mobile hosts. Structure of the CCT packet that is exchanged among the mobile hosts is stated below [1]. Node-id Cluster Id #hops from cluster head #neighbors Upstream node

where, Node-Id is the mobile hosts unique address. This can also be the hardware address. Cluster-Id is the Identification of the cluster to which the node (mobile host) belongs. Initially, this is set to Null, until the mobile node becomes a member of a cluster. #hops from the cluster head is the distance from the cluster head . Initially, this field is set to zero until the node becomes a member of a cluster. #neighbors is the count of nodes who are at a distance of 1 hop from this mobile host. This value keeps increasing/decreasing whenever a new node is added/ neighboring node moves away. This field is needed during cluster formation. A node in a cluster is termed as cluster head if it has the maximum number of immediate neighbors in the cluster and is responsible for cluster formation. Upstream node is the immediate neighboring node, through which the mobile host is connected to the cluster head. The cluster formation rules can be found in [1]. We assume the following in the present work: (a) an ad-hoc network is a small dynamically configurable network of mobile hosts, (b) every mobile host has the same transmission range, (c) there is no unidirectional link between two nodes. Two nodes can communicate with each other, if they are in the transmission range of each other. As mentioned earlier the entire network of mobile nodes is divided into clusters where a cluster is a group of ad-hoc hosts. The cluster head node in each cluster is chosen as Data Access Point (DAP). Each DAP keeps track of a table called Access Table which is populated to all other DAPs. The Access Table is modified, only when at least one member in that cluster becomes a member of a new multicast group or when it leaves an existing multicast group. Each DAP forwards whatever it has learned to its neighboring DAPs via Access table. The DAP is like an access point in a cluster, where a sender of multicast packet just queries it to know what other clusters have members which are interested in receiving this multicast packets. It holds records of those clusters whose nodes are members of one or more multicast groups. The Access Tables are interchanged among the different clusters in the network. Note that the information exchanged among the DAPs is only the modified part of the Access Table. Within a cluster, distance vector tables are maintained. Each node within a cluster knows how to reach the other nodes within its cluster. Each such table contains an additional field called multicast group, to determine the multicast groups a node is associated with. A node in a cluster is called a gateway, if it is in the transmission range of another node of a different cluster. Each node in the ad-hoc network is identified by two parameters: 1) Node-Id: this is a unique address for each node in the entire ad-hoc network, and 2) Cluster-Id: each cluster in the network is assigned a unique Address called Cluster- Id. When two nodes come in the transmission range of each other, they first exchange their CCT packets. If their cluster ids match, it means that these nodes are from the same cluster. These nodes then exchange their distance vector tables. If their cluster ids mismatch, these two nodes can now become the gateway nodes used for routing between their respective clusters. Each such DAPs first duty is to inform its respective DAP about the gateway node it has come in contact with. The DAP then selects this node to be the gateway node for multicast information exchange to the

136

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

neighboring cluster if either the hop distance of this gateway node from it is less than that of the existing gateway, or there is no existing gateway node to reach that neighboring cluster. If so, while routing, the DAP sends the multicast data to the new gateway node of the other cluster through the gateway node in its own cluster. 3. Necessary Data Structures The fields in Access Table, maintained by each DAP is shown below: Cluster-Ids Multicast Group Routing Nodes

Cluster-Id is the address associated with each cluster having one or more members belonging to a multicast group as specified in the Multicast Group field. Routing node is the node within the cluster from which the foreign cluster can be reached. Each DAP forwards whatever it has learned to its neighboring DAPs , in the form of Access Table. Note that only modified portion of the Access Table is sent to the neighboring clusters. Each DAP, on receiving this table, updates its own Access Table to have the new entries. It also records in its table, the node-id of the node within its cluster, from which the new information was received. The data that is transferred to the neighboring DAPs is only the table containing two fields, namely Cluster-Id and Multicast Group as shown below. This packet is referred as table update packet. Cluster-Ids Multicast Group

Whenever a cluster establishes a link with a new cluster, it sends its entire Access Table to the new clusters DAP . When a sender wants to send multicast data to its receivers a special packet called multicast packet is formed by the DAP, which consists of the fields as shown below: Multicast Clusters Multicast Group Multicast Data

where Multicast Clusters are the different clusters in the network, having members belonging to the multicast group of the sender. Multicast Data contains the multicast information. 4. Multicast Routing Scheme It is known that Distance Vector Routing scheme [5] is one of the most efficient routing schemes for static networks. Attempt has been made to apply it to mobile ad-hoc networks that are not clustered. However, the large routing table size (which is 3n for a network of n nodes) that needs to be maintained by each node in this scheme makes it very memory inefficient. Besides, exchanges of such large tables between neighboring nodes results in very inefficient bandwidth utilization, in particular when n is large. The presented multicast protocol is distance vector based, yet it uses much smaller router table per node and so offers much less amount of information exchange between neighboring nodes since the network is clustered. Therefore, it ensures both better memory and bandwidth utilization. The working of the multicast routing scheme is summarized as follows. The scheme is divided into four protocols. These are: Join Protocol, Inter Cluster Link Setup Protocol, Access Table Interchange Protocol, and Multicast Routing Protocol. When a mobile node decides to join a multicast group it first sends a join request to its DAP. The DAP now registers its respective cluster with the group requested by the mobile host and updates its Access Table with this entry. This is how the Join Protocol works. Whenever two nodes come in the transmission range of each other, they first exchange their CCT packets from which they know whether they belong to different clusters or the same cluster.

137

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

If they belong to different clusters, they can possibly become the gateway routers. This decision is made by their respective DAPs. This protocol is called Inter Cluster Link Setup Protocol. Whenever there is a change in the access table entries, the updates have to be sent to the neighboring clusters. Thus DAP sends a table update packet reflecting the change in its Access Table to its neighboring clusters through the gateway nodes. The receiving cluster updates its access table with the new value and sends the updates to its neighboring cluster. This is how the Access Table Interchange Protocol works. Whenever a sender node wishes to send multicast data to a particular multicast group G, it first requests the DAP, to query for the clusters belonging to group G. The DAP queries and sends multicast packet to each of these clusters of group G through the outgoing gateway nodes which can aid in reaching these clusters. Once this packet reaches the neighboring clusters, the duty of each neighboring cluster is to see whether its cluster entry is present in the multicast packet. If present, it delivers the multicast data to its member nodes. It now reformats the multicast packet and sends this to the clusters present in the Multicast Clusters field of the received multicast packet through its gateway routers. This process is repeated until the clusters present in the Multicast Clusters field of the multicast packet become null. It assures that the multicast data has been delivered to the members of multicast group G. This is the working principle of the Multicast Routing Protocol. Below we have stated formally each of these four protocols of the multicast routing scheme. 4.1 Join Protocol Step 1. When a mobile host mij becomes a member of a multicast group Gk, it informs the DAPj about the multicast group Gk. Step 2. Access Table update inside a cluster Cj will not occur if a node mij informs its DAPj about its being a member of a multicast group Gk, of which an entry has already been recorded in the Access Table. Step 3. The DAPj stores this information in its access table as: a) The cluster-id field is set to the cluster-id of the requesting node as Cj b) The multicast group field is set to the multicast group Gk, of which the requesting node is now a member. c) The routing node field is left blank because the host mij is a part of the same cluster. Proc Join ( mij, Gk, DAPj, Cj ) Begin If ( mij joins Gk ) { if( DAPj already has an entry Gk for Cj ) { updateTable=false; } else { // update the access table; set cluster-id=Cj; set multicast group=Gk; set routing node=null; updateTable=true; } } End Proc.

138

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

4.2 Access Table Interchange Protocol Changes occur in the Access Tables only when a multicast group has been created or destroyed in a cluster. A multicast group is said to be created when at least one node requests for participation in one or more multicast groups. Multicast group is said to be destroyed in a cluster, when no more nodes inside that cluster belong to that multicast group. The following steps are executed in the Access Table Interchange Protocol. Step 1. Updated Access Table, following a join protocol is sent to the neighboring clusters. Step 2. The receiving cluster makes changes to its Access Table and propagates the table update packet to the neighboring clusters . Proc AccessTableInterchange (Cj ) Begin // Let Cn (l<n<p) denote the neighboring clusters of current cluster Cj // DAPj of cluster Cj executes all the steps defined in this code. while (true) { if( updateTable = = true ) { // send an update packet to every neighboring cluster of Cj. for (n = l to p) send TableUpdatePacket to each Cn; } if(received an TableUpdatePacket from any Cn (l<n<p)) { if(Changes Occur in AccessTable) { Construct a new TableUpdate Packet; for (n = l to p) send TableUpdatePacket to each Cn; } else drop the received TableUpdatePacket; } } End Proc 4.3 Inter Cluster Link Setup Protocol Step 1. If a node mij Cj receives a CCT packet from mjk Ck, these two nodes can now become the gateway nodes between clusters Cj and Ck. Step 2. The DAPj of node mij decides whether this node can be the potential node to reach the neighboring cluster Cj. Step 3.If mij becomes the new gateway node to reach cluster Cj , the Access Tables routing node corresponding to Cj is replaced by mij. Step 4. DAPk of node mjk also performs the checks as in steps 2 & 3. Proc InterclusterLinkSetup ( Cj, Ck ) Begin if(mij Cj receives a CCT packet from mjk Ck ) { if(DAPj decides mij as gateway node to Ck) {

139

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

Change AccessTablej routing node for Ck with mij. } if(DAPk decides mjk as gateway node to Cj) { Change AccessTablek routing node entry for Cj with mkj. } } End Proc In the following protocol a sender to a multicast group may or may not be a member of that multicast group. 4.4 Multicast Routing Protocol Step 1. When a sender msj in a cluster Cj wishes to send a multicast packet to group Gk, it first queries DAPj about the clusters, which contain members of the group Gk. It gets a response about the different cluster-ids and the gateway nodes to be visited to reach these clusters. Step 2. If two or more cluster ids, which are interested in receiving multicast packets, are reachable from the same gateway node mgj of cluster Cj , then a multicast packet will be sent to mgj Step 3.The gateway node mgj sends this multicast data to the corresponding clusters. Step 4: When this multicast packet reaches the gateway node, say mgm of cluster Cm, the node mgm checks whether its cluster-id is present in the multicast clusters field. Step 5a: If Cm is present in the multicast cluster field, then the multicast data in the packet is sent by mgm to the nodes Cm, which are the members of the multicast group Gk, by looking at the distance vector tables. Step 5b. Now mgm reconstructs the multicast packet by removing Cm from the multicast clusters field. Step 6. The gateway node mgm, now sends the multicast packet to its DAPm. Step 7. DAPm checks its Access Table for the Routing Nodes needed to reach other clusters specified in the multicast clusters field. Step 8. The DAPm then routes the multicast packets to the gateway nodes mrm (l<r<t), where mrm denotes the gateway node Cm used to reach cluster Cr. Step 9. Every such receiving gateway Cm , repeats steps 3 to 9 until the cluster-id field in the multicast packet it has received becomes null. This is the termination condition for the Multicast Protocol. Proc Multicast ( msj, Gk, C ) Begin // C denoted the set containing all the clusters in the network. If (msj is the sender to group Gk)) { Enquire DAPj for { Cm (l m r) C / such that there exists any mnm ( Cm ) also belonging to multicast group Gk; // DAPj now does the following steps If( | Cm | 0) { for(each routing node mgj Cj for Cn (l n r ) Cm (l m r) ) { DAPj constructs a multicast packet MP[Cn (l m r ),Gk, MulticastData] ; DAPj sends MP[Cn ( l n r ), Gk, MulticastData]) to routing node mgj ; mgj delivers the multicast packet to clusters Cn (l n r );

140

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

} else Cm (l m r) do not have any member Gk ; End Proc

} for(each receiving routing node mrp ) perform MulticastPacketDelivery ( mrp, Cn, MP );

Sub Proc MulticastPacketDelivery ( mrp, Cn, MP ) Begin If ( Cp Cn ( l n r) ) { mrp delivers MulticastData to all members Gk in Cp using the distance vector table entries ; mrp sets MP[Cn ( l n r ) - Cp, Gk,, MulticastData] ; } mrp sends MP to DAPp ; If ( Cn ( l n r ) = NULL ) { End Proc } DAPp retrieves the Routing Nodes for clusters Cn ( l n r ) appearing in the multicast clusters field ; for(each mgp Cp which is the routing node for Cs (l s r ) Cn (l n r) ) { DAPp sends MP[Cs ( l s r ), Gk , MulticastData]) to routing node mgp ; mgp delivers the multicast packet to clusters Cs (l<s<r ); } for(each receiving routing node mrk ) perform MulticastPacketDelivery ( mrk, Cs, MP ); End Proc Observe that the Clustering Protocol [1], Join Protocol, Access Table Interchange Protocol, and Inter Cluster Link Setup Protocol run concurrently with the Multicast Routing Protocol. 4.5. An Illustration Case 1: Multicast Packet Delivery, using the above mentioned protocols. Consider initially two clusters C1 & C2 as shown in Fig. 1.

C1

DAP1 m11

m21

m12

DAP2

C2

Fig. 1 A network of two clusters In C1, m11 wishes to join multicast group, say G1. Then following the Join Protocol, m11 sends this information to DAP1, which then updates its Access Table as follows

141

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

Cluster-Ids C1

Multicast Group G1

Routing Nodes -

DAP1, then initiates the Access Table Interchange protocol and gives the information about the changes to its data structure to Cluster C2, passing only two fields as shown in its table update packet below. Cluster-Ids Multicast Group C1 G1 m12 in Cluster C2 receives this packet and finds that it is a control message for DAP table update from C1. Mobile node m12, sends this information to DAP2, which updates its Access Table as follows: Cluster-Ids Multicast Group Routing Nodes C1 G1 m12

Now, suppose a new cluster named C3 has been formed in the already existing network of Fig.1 and has a gateway node m13 which is in the transmission range of a gateway node, say m22 in C2 (Fig. 5). Now DAP2 sends the access table data it learned to C3. Say, m32 in C2 wishes to join multicast group G1 and also m42 in C2 wishes to join multicast group G2. Thus the DAP2 will record the following information as shown in Fig. 2 below. Cluster-Ids C1; C2 C2 Multicast Group G1 G2 Routing Nodes m12;-

Fig. 2 Information recorded by DAP2 DAP2 unicasts this information to the clusters C1 and C3. The Data Access Points of C1 and C3 respectively record the following information as shown in Fig. 3 and Fig. 4 below. Cluster-Ids C1; C2 C2 Multicast Group G1 G2 Routing Nodes -; m21 m21

Fig. 3 Information recorded by the data access point of C1 Cluster-Ids C1; C2 C2 Multicast Group G1 G2 Routing Nodes m13; m13 m13

Fig. 4 Information recorded by the data access point of C3

142

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

Let m23 of C3 be the sender for multicast group G1. Fig. 5 shows the network at this stage.

C1
DAP1 m11; G1 m21 m12 m22 DAP2 m42; G2

C3
DAP3 m13 m23 ; s

m32; G1

C2

Fig. 5 A new cluster C3 is formed Following the Multicast Protocol, node m23 first queries DAP3 to know the clusters associated with multicast group G1. Then DAP3 , from its Access Table knows that C1 and C2 are the clusters associated with the multicast group G1. DAP3 also knows that the gateway routing node to reach C1 and C2 is m13. So DAP3 sends the multicast packet to m13 with the following information. Multicast Clusters C1; C2 Multicast Data MData

Node m13 sends this packet to the reachable node, here m22. Now, m22 first parses the Multicast Clusters field of the received multicast packet and finds that C2 is present in that field. It then sends the multicast data to the members in C2 G1 . Node m22 now reconstructs the multicast packet by removing C2 from the Multicast Clusters field of the received multicast packet. This packet is represented as follows. Multicast Clusters C1 Multicast Data MData

Node m22 now sends this reconstructed multicast packet to DAP2 which retrieves the Routing Node for clusters C1 in the Multicast Clusters field. This routing node is m12 . DAP2 now sends the multicast packet it has received from m22 , to m12, which is the routing node to reach cluster C1 . The multicast packet eventually reaches cluster C1 through node m21. Node m21 , parses the Multicast Clusters field of the received multicast packet and finds that C1 is present in that field. It then delivers the multicast data to m11 G1 of Cluster C1 . Node m21, after removing C1 , from the Multicast Clusters field of the received multicast packet , finds that now the value in that field is NULL . Thus it does not take any further action. This is the termination condition for the proposed multicast protocol. Case 2: Inter Cluster Link Setup Protocol aiding Multicast Packet Delivery Assume that a new cluster, C4 has been formed in the existing network of Fig. 5, and m14 in cluster C4 is in the transmission range of m31 in cluster C1 (refer to Fig. 6). Thus C4 gets the table about the multicast group from C1. Assume that m24 C4 joins Group G2. Thus there will be a change in the values for the Access Table in DAP4 which is shown in Fig. 7.

143

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

Cluster-Ids C1; C2 C2; C4

Multicast Group G1 G2

Routing Nodes m14; m14 m14; -

Fig. 7 Information recorded by DAP4 Following the Join and Access Table Interchange protocol, changes occur in other clusters in the network. For example, the Access Table of DAP2 of cluster C2 records the following information (Fig. 8). Cluster-Ids C1; C2 C2; C4 Multicast Group G1 G2 Routing Nodes m12;-; m12

Fig. 8 Information recorded by DAP2 Now consider the case, where m33 C3 is the sender for multicast group G2. The multicast packet delivery will be governed similar to Case 1. If m34 ( C4 ) and m32 ( C2) come in the transmission range of each other, then Intercluster Link Setup will be called and each will change its entry corresponding to that neighboring cluster, if there is an entry in the multicast table. The new Access Table for DAP4 will contain the following information (Fig. 9). Cluster-Ids C1; C2 C2; C4 Multicast Group G1 G2 Routing Nodes m14; m34 m34; -

Fig. 9 Latest information recorded by DAP4 And the new Access Table for DAP2 of cluster C2 appears as shown in Fig. 10. Cluster-Ids C1; C2 C2; C4 Multicast Group G1 G2 Routing Nodes m12;-; m32

Fig. 10 Information recorded by DAP2 Assume that during the time the packet took to reach cluster C2, nodes m34 and m32 have come in the transmission range of each other and changed their access table routing node values. From Fig. 6, it is evident that upon reaching cluster C2, the multicast packet will be delivered to cluster C4 now, using the new shorter path setup between C2 and C4. Thus the Inter Cluster Link Setup Protocol has aided in more efficient delivery of the multicast packet, without which the multicast packet would have taken the longer path, that is from C2 to C1 and then finally to C4.

144

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

C3 C1
m31 DAP1 m11; G1 m21 m12 m32; G1

C2
DAP2 m22 m13 m42; G2

DAP3 m23 m33 ; s

m34

m14

DAP4 m24; G2

C4

Fig. 6 Another new cluster C4 is formed

In the above illustration the following important advantages of our proposed multicasting scheme become evident: (1) it always looks for a possible better (shorter) path to reach clusters, and (2) no complete routing table needs to be exchanged. In general, significant reduction of routing table size and less amount of information exchange make the scheme both memory and bandwidth efficient for mobile ad-hoc networks. 4.6 Storage requirement Below we compare analytically the storage requirement for each mobile host considering the following two situations: 1) DVR is applied on unclustered ad-hoc networks and 2) DVR is applied on the presented clustered ad-hoc network. Assume that the network of n nodes is partitioned into Nc number of clusters where Nc<< n. Without any loss of generality, we assume that on an average, the number of nodes in each cluster is m, such that Nc * m = n. When DVR is applied in such a clustered network the distance vector table maintained by each node in a cluster will have a size of 2[m+(Nc-1)] instead of 3n which corresponds to the unclustered network. This value 2[m+(Nc-1)] becomes very small compared to 3n as n becomes large. Thus, because of this significant reduction of the table size the DVR scheme can be effectively applied to clustered adhoc networks offering efficient utilization of both memory and bandwidth. 4.7 Another Efficient Routing Scheme Core Based Tree (CBT) routing scheme is another important routing strategy that has been used in mobile ad hoc networks [6], [7]. In this routing, only one node (Core) with maximum number of neighbors takes the responsibility of routing multicast packets to all other nodes. Problem arises when this node no longer has the maximum number of neighbors due to node mobility or node failures. Therefore a new Core has to be selected considering all nodes in the network. This is not an easy task to accomplish considering the fact that every node is mobile. It will definitely not be bandwidth efficient since all nodes are to be involved in exchanging information necessary for the selection. However, CBT routing can be applied efficiently in the proposed clustered network in a distributed sense, in which each cluster head can act as a local Core, responsible for routing in its own cluster and communicating (if necessary) to its neighboring cluster heads. If the local core moves away or fails, then selection of a new local Core (cluster head) for this cluster becomes much easier than in [6], [7], because now only the nodes in this cluster plus any new nodes currently visiting this cluster need to be considered. Thus bandwidth utilization will also be better than the works [6], [7] because of fewer number of message exchanges needed for the selection of the core.

145

Journal of Computational Methods in Science and Engineering (JCMSE) Vol. 6, No. 5 & 6, 2006

5. Conclusion In this paper, we have proposed a distance vector based multicast routing protocol for clustered MANET. The proposed scheme needs much smaller routing table per host and less amount of (information) exchanges compared to the distance vector routing scheme, applied on unclustered network. These advantages plus its adaptable nature to the changing ad-hoc network topology make this proposed multicasting protocol both memory and bandwidth efficient for MANET. We have also presented an idea about how to apply the CBT routing strategy in our clustered network in order to achieve efficient resource utilization.

References [1] V. Doraiswamy, R. Jandhyala, and B. Gupta, An Efficient Dynamic Clustering Protocol for MANET, Proc. ISCA 19th Int. Conf. Computers and Their Applications, Seattle, March, 2004, pp. 362-367 [2] C.E.Perkins, Mobile Networking in the internet, Mobile Networks and Applications, vol.3, 1998, pp. 319-334 [3] M. Nanda and B. Gupta, Cluster-Based Communication in Mobile Ad-Hoc Networks, Proc. 18th Int. Conf. on Computers and their Applications, Hawaii, March, 2003, pp. 93-97 [4] A.Bruce MacDonald and Taieb Znati, A Mobility Based Framework for Adaptive Clustering in Wireless Ad-Hoc Networks, IEEE Journal on Selected Areas in Communication, vol 17, no. 8, August 1999, pp 1466-1487. [5] Distance Vector Multicasting Protocol draft-ietf-idmr-dvmrp-v3-10.txt (2001). [6] A. Ballerdie, B. Cain, and Z. Zhang, Core Based Trees (CBT version 3) multicast routing protocol specification, Interner Draft, IETF, March, 1998. [7] A. Tewari, X. Dong, and B. Gupta, A Dynamic Self-Adaptive Multicast Protocol for Ad-Hoc Networks, Proc. ISCA 17th Int. Conf. Computers and Their Applications, San Francisco, Apr, 2002, pp. 406-411.

146