Tài liệu Sổ tay của các mạng không dây và điện toán di động P23 doc

For hosts that want guaran-teed two-way communication with the multicast group and are unable to acquire a colo-cated address, or hosts that are highly mobile, a different method is need

CHAPTER 23

Multicasting: From Fixed Networks

to Ad Hoc Networks

THOMAS KUNZ

Systems and Computer Engineering, Carleton University, Ottawa, Canada

23.1 INTRODUCTION

Multicasting can efficiently support a variety of applications that are characterized by the close degree of collaboration typical of many ad hoc applications currently envisioned Within the wired network, well-established routing protocols exist to offer efficient multi-casting service As nodes become increasingly mobile, these protocols need to evolve to provide similarly efficient service in the new environment This survey will briefly de-scribe the basic approaches to multicasting in wired networks It then gradually relaxes the requirement that all nodes be stationary, discussing multicast protocols for cellular net-works (which are characterized by a fixed infrastructure with mobile end nodes) and ad hoc networks (completely infrastructureless mobile networks)

23.2 MOTIVATION

Multicasting is the transmission of datagrams to a group of zero or more hosts identified

by a single destination address A multicast datagram is typically delivered to all members

of its destination host group with the same reliability as regular unicast datagrams In the case of IP, for example, the datagram is not guaranteed to arrive intact at all members of the destination group or in the same order relative to other datagrams [1]

Multicasting is intended for group-oriented computing There are more and more appli-cations in which one-to-many dissemination is necessary The multicast service is critical

in applications characterized by the close collaboration of teams (e.g., rescue patrols, mil-itary battalions, scientists, etc.) with requirements for audio and video conferencing and sharing of text and images In the Internet (IPv4), multicasting facilities were introduced via the multicast backbone (MBone), a virtual overlay network on top of the Internet This overlay network consists of multicast-capable islands connected by tunnels Each island contains one or more special routers called multicast routers, which are logically

connect-ed by these tunnels These routers manage group membership and cooperate to route data

to all hosts wishing to participate in a multicast group IP multicast groups are identified

by special IP addresses

495

Handbook of Wireless Networks and Mobile Computing, Edited by Ivan Stojmenovic´

Copyright © 2002 John Wiley & Sons, Inc ISBNs: 0-471-41902-8 (Paper); 0-471-22456-1 (Electronic)

Typically, the membership of a host group is dynamic; that is, hosts may join and leave groups any time There is no restriction on the location or number of members in a host group A host may be a member of more than one group at a time A host does not have to

be a member of a group to send datagrams to it

A host group may be permanent or transient A permanent group has a well-known, ad-ministratively assigned address It is the address not the membership of the group that is permanent; at any time, a permanent group may have any number of members, even zero Those IP multicast addresses that are not reserved for permanent groups are available for dynamic assignment to transient groups, which exist only as long as they have members The use of multicasting within a network has many benefits Multicasting reduces the communication costs for applications that send the same data to multiple recipients In-stead of sending via multiple unicasts, multicasting minimizes the link bandwidth con-sumption, sender and router processing, and delivery delay [2] In addition, multicasting provides a simple yet robust communication mechanism whereby a receiver’s individual address is unknown or changeable transparently to the source

Maintaining group membership information and building optimal multicast trees is challenging even in wired networks However, nodes are increasingly mobile One partic-ularly challenging environment for multicast is a mobile ad hoc network (MANET) A MANET consists of a dynamic collection of nodes with sometimes rapidly changing mul-tihop topologies that are composed of relatively low-bandwidth wireless links There is no assumption of an underlying fixed infrastructure Nodes are free to move arbitrarily Since each node has a limited transmission range, not all messages may reach all the intended hosts To provide communication through the whole network, a source-to-destination path could pass through several intermediate neighbor nodes Unlike typical wireline routing protocols, ad hoc routing protocols must address a diverse range of issues [3] The net-work topology can change randomly and rapidly, at unpredictable times Since wireless links generally have lower capacity, congestion is typically the norm rather than the excep-tion The majority of nodes will rely on batteries, thus routing protocols must limit the amount of control information that is passed between nodes

The goal of MANETs is to extend mobility into the realm of autonomous, mobile, wireless domains, where a set of nodes form the network routing infrastructure in an ad hoc fashion The majority of applications for the MANET technology are in areas where rapid deployment and dynamic reconfiguration are necessary and the wireline network is not available [3] These include military battlefields, emergency search and rescue sites, classrooms, and conventions where participants share information dynamically using their mobile devices These applications lend themselves well to multicast operation In addi-tion, within a wireless medium, it is even more crucial to reduce the transmission over-head and power consumption Multicasting can improve the efficiency of the wireless link when sending multiple copies of messages by exploiting the inherent broadcast property

of wireless transmission However, besides the issues for any ad hoc routing protocol

list-ed above, wireless mobile multicasting faces several key challenges [4] Multicast group members move, thus precluding the use of a fixed multicast topology Transient loops may form during tree reconfiguration, so tree reconfiguration schemes should be simple to keep channel overhead low

This chapter briefly describes the basic approaches to multicasting in wired networks

It then gradually relaxes the requirement that all nodes be stationary In a first step, multi-cast members are allowed to be mobile, connecting to a fixed infrastructure In this cellu-lar architecture, multicast protocols are based on extensions/modifications of the basic mobile IP [5,6] protocol used to provide unicast services to mobile end nodes These mo-bile-IP-based protocols, however, cannot be applied to MANETs, which inherently lack infrastructure We will look at proposed extensions to traditional multicast protocols, as well as multicast proposals developed specifically for MANETs

23.3 MULTICASTING IN FIXED/WIRED NETWORKS

On the Internet, there are two popular wired network multicast schemes, namely, per-source shortest tree and shared tree The per-per-source tree scheme consists of broadcasting the packet from the source to all destinations along the source tree in a manner that avoids loops This is accomplished by using “reverse path forwarding” or RPF In RPF, a router forwards a broadcast packet on its remaining interfaces if and only if the packet is re-ceived on an interface that is on the shortest path from the router to the source Thus, only those packets are forwarded that arrive on the reverse shortest path from the router to the sender Examples of per-source tree protocols commonly used in the Internet are DVMRP and PIM dense mode [7] In the wireline environment, per-source tree multicasting has many attractive properties For example, the shortest tree from each source to all destina-tions is inherent in the routing protocol Furthermore, source tree multicast distributes the traffic evenly in the network (assuming that the source and receivers are evenly distrib-uted), and it does not rely on a control point (rendezvous point)

In the shared tree multicast scheme, each multicast group has a single tree rooted at a special router called the rendezvous point (RP) Each multicast group has its own RP, and

“grows” its own shared tree The intermediate routers in the tree are responsible for for-warding the multicast data to members In this manner, all receivers join the multicast group by explicitly sending a JOIN message toward the RP Senders send data to the RP, and the RP uses a single unidirectional shared tree to distribute the data to the receivers Examples of shared-tree approaches are core based tree (CBT) [8] and PIM sparse mode The shared tree is beneficial if multiple senders transmit data to the same host group, since only one tree needs to be built and maintained However, it also has some drawbacks with respect to the per-source scheme Traffic is concentrated on the backbone, rather than evenly distributed across the network, and paths are often suboptimal

23.4 MULTICASTING IN FIXED INFRASTRUCTURE

CELLULAR NETWORKS

Mobile networks with fixed infrastructure, or cellular networks, consist of stationary base stations and mobile endpoints Each base station is assigned a geographic area, or cell, and

is responsible for connecting mobile endpoints to the wired portion of the network Mo-bile users communicate via a single-hop wireless channel with a base station, which is in turn connected to a wired backbone

23.4 MULTICASTING IN FIXED INFRASTRUCTURE CELLULAR NETWORKS 497

Mobile IP [5, 6] is the basic mechanism currently used to manage mobility to these end hosts In mobile IP, a mobile node may change its location without changing its IP address The way this is achieved is through the use of a home agent and a foreign agent While the mobile node is visiting a foreign network, it is assigned a care-of address that represents the mobile node’s current point of attachment This care-of address is then registered with the home agent to allow the home agent to know where to tunnel datagrams to the mobile node

A home agent represents a router (typically) or other computer on the mobile node’s home network that is responsible for encapsulating datagrams for delivery to the mobile node when it is away from home A foreign agent represents a router or other computer on a mo-bile node’s visited network that provides routing services to the momo-bile node while it is reg-istered The foreign agent decapsulates and delivers to the mobile node datagrams that were encapsulated by the mobile node’s home agent In the reverse direction, for datagrams sent

by the mobile node, standard IP routing is used to deliver the datagrams to their respective destinations; it is not necessary to pass them through the home agent

Achieving multicast service for mobile nodes becomes a challenging problem A node that wishes to receive group multicast datagrams should join the group repeatedly as it changes location The branches and leaves of a multicast tree may change along with the node’s mobility Mobile nodes have to choose a location (IP subnet) to describe their membership The structure and charactistics of the dynamic tree depend on where a mo-bile node chooses to declare its multicast membership Possible choices are the home net-work, the currently visited netnet-work, or several combined networks Different approaches will result in different multicast trees and tree maintenance overheads over time

There are currently two ways to extend mobile IP to support multicast services to mo-bile hosts in a fixed-infrastructure cellular network: foreign-agent-based multicast and home-agent-based multicast In the foreign-agent-based multicast proposal, each mobile node has to obtain a “colocated” care-of address (i.e., a care-of address exclusively used

by the mobile node) when roaming into a foreign network The mobile node will subscribe

to the multicast group at the foreign network The multicast router in the foreign network propagates this information for the mobile node Processing this in the same way as dy-namic group membership changes, the multicast tree will extend to the foreign network This scheme has the advantage of offering an optimal routing path (within the limits of IP routing) and avoids delivering duplicate copies of datagrams However, when a mobile host is highly mobile, its multicast service may be very expensive because of the

difficul-ty in managing the multicast tree Furthermore, the extra delay incurred when rebuilding a multicast tree can create the possibility of a disruption in multicast data delivery There-fore, if the host is likely to be stationary for an extended period of time, this option is pre-ferred As expressed in [9]: “Remote subscription does provide the most efficient delivery

of multicast packets, but this service may come at a high price for the networks involved and the multicast routers that must manage the multicast tree For hosts that want guaran-teed two-way communication with the multicast group and are unable to acquire a colo-cated address, or hosts that are highly mobile, a different method is needed that will not overload the multicast routers.”

In the home-agent-based multicast proposal, when a mobile node is roaming in a for-eign network, multicast packets will be encapsulated by the home agent and delivered to the mobile node as unicast packets The mobile node only subscribes to the multicast

group in its home network Its multicast group membership is transparent to any foreign network There are a number of problems with this approach, however If the mobile node

is far from its home network and in the same network with the source of the multicast tree, the extended branch will be extremely long: the multicast packet will travel to the home network and then travel back to the source network again If the number of mobile nodes

is large, many branches are extended from the home network This will increase the net-work traffic significantly Consider the following scenario: the mobile node roams into a foreign network, which is a member of the multicast group But the mobile node’s mem-bership is transparent to the foreign network; it still receives the multicast packets from its home network via a unicast tunnel If two or more mobile nodes belong to the same home agent and subscribe to the same multicast group, the home agent will duplicate packets from the same multicast packet, and send them separately to the same foreign agent So the main disadvantages of this approach are suboptimal packet routing and unnecessary packet duplication

To address these problems of home-agent-based multicast, the MoM (mobile multi-cast) proposal [9, 10] suggested a number of modifications to this protocol First, a home agent only forwards a single copy of multicast packets to a foreign network even if two or more mobile nodes belonging to this home agent roam in the same foreign network The foreign network uses link-layer multicast to distribute the packets to separate mobile nodes In this way, packet duplication will decrease However, multiple tunnels from dif-ferent home agents can still terminate at one foreign agent When multiple home agents have mobile nodes visiting the same foreign network, one copy of every multicast packet

is forwarded to the same foreign agent by each home agent The foreign agent suffers from the convergence of tunnels set up by each home agent So the second new concept intro-duced by MoM is the designated multicast service provider (DMSP) DMSP is one home agent selected by a foreign agent, forwarding only a single copy of a multicast datagram to

a foreign network The management of the DMSP adds overhead If a mobile node whose home agent works as a DMSP moves out of the foreign network, the foreign agent must select another DMSP

Mobile multicast agent (MMA) is an attempt to improve the optimality of the multicast tree [11] The MMA approach uses a multicast agent (MA) that provides multicast ser-vices to mobile nodes A mobile node receives multicast traffic from the tunneling of a certain MA or directly from the multicast router at the current network Each MA has to support a group service with one multicast forwarder (MF) per group A MF is one of the MAs that are in charge of forwarding multicast data to other MAs For each network, both the MA and the mobile node, which resides in the same network, use the same MF

Initial-ly, if a mobile node wants to join a group in any foreign network, subscriptions are done through the MA on the foreign network, which must be a multicast router This MA be-comes a MF itself, and in this network mobile hosts receive multicast service directly from the multicast router Then, when the mobile node moves to another network, it noti-fies the MA in the new network of its group ID and its MF during registration This MF information is used by the MA in the new network as the previous MF of the visiting mo-bile node If the MA in the new network does not have a group member, then it configures its own MF value with the previous MF of the mobile node Otherwise, if the new network has group members and an MF, the MA executes the MF selection algorithm and selects

23.4 MULTICASTING IN FIXED INFRASTRUCTURE CELLULAR NETWORKS 499

either the current MF of the MA or the MF of the visiting mobile node Both the MA and the mobile node replace their MF value with the newly selected MF From the point of the multicast tree, a MA extends the tree from an MF among adjacent networks that belong to the multicast delivery tree for the group Because the mobility of mobile nodes is

expect-ed to show locality characteristics, this MF is one of the more adjacent multicast tree nodes from the current network

Comparing these proposals, the multicast tree in the foreign-agent based proposal is the most optimal one But frequent movement requires frequent reconfigurations of the multicast tree This puts a high load on the multicast routers The MMA proposal has the second-best tree, and not every movement will cause the multicast tree to change It there-fore provides good multicast support for mobile nodes However, every there-foreign network has to deploy MAs All these schemes assume that the mobile host is just one wireless hop away from the fixed infrastructure, which is characteristic of cellular networks They are therefore not able to handle truly ad hoc networks, in which intermediate nodes are mobile

as well

23.5 MULTICASTING IN MOBILE AD HOC NETWORKS:

ADOPTING WIRELESS PROTOCOLS

In mobile ad hoc networks, there are three basic categories of multicast algorithms A first, naive, approach is to simply flood the network Every node receiving a message floods it to a list of neighbors Flooding a network acts like a chain reaction that can result

in exponential growth The proactive approach precomputes paths to all possible destina-tions and stores this information in routing tables To maintain an up-to-date database, routing information is periodically distributed throughout the network These protocols are discussed in the next few paragraphs The final approach is to create paths to other hosts on demand The idea is based on a query-response mechanism or reactive multicast

In the query phase, a node explores the environment Once the query reaches the destina-tion, the response phase is entered and establishes the path This category of protocols is the subject of the next section

In MANETs, traditional per-source tree approaches for multicasting present a problem Suppose a source moves faster than the routing tables can track it In this case, some of the nodes will have obsolete routing tables pointing in the “wrong direction.” Following the

“reverse path forwarding” principle, multicast packets are discarded at such nodes, and may never reach some of the receivers One way to alleviate this problem is to increase the routing update rate with mobility However, the periodic full broadcast in implementations like DVMRP introduces costly control overhead on the low-bandwidth wireless channel and is not suitable for sparse distributed membership and scaling the network size Chiang

et al [12] propose wireless extensions to DVMRP, whereby each sender selectively

“floods” multicast packets to all nodes within a specified range using RPF However, this approach suffers from the periodic data flooding overhead incurred by the source in order

to reestablish any new or lost connections This periodic flooding causes considerable transmission overhead for the low-bandwidth wireless channel Also, with the RPF

mech-anism, if the shortest path changes and no multicast packets arrive on the new shortest path, the node becomes disconnected from the tree Finally, scalability to a large number

of senders becomes problematic since each internal tree node stores the list of sources and associated timers Storage and processing overheads grow linearly with the number of sources The shared tree eliminates this problem

In general, shared trees are potentially less sensitive to source mobility and can in part overcome the fast-moving source problem Basically, a fast source will send its packet to the RP in unicast mode Packets are correctly delivered to the RP on shortest paths, irre-spective of the speed of the source The RP will then multicast the packet on the shared tree to the intended destinations This works as long as the shared tree is stable and the RP itself is not moving fast If all the nodes are moving fast (relative to the routing table up-dates), the shared tree solution also fails Also, as the entire network moves and the mem-bership changes dynamically, the RP may not be in the center, aggravating the nonopti-mality of the paths Chiang et al [13] propose a shared tree wireless network multicast (ST-WIM) algorithm based on adapting PIM-SM to MANET Several simulations were performed using the ST-WIM protocol measuring metrics like join latency, control packet overhead, throughput when varying multicast group size, and node mobility ST-WIM’s re-sults show that the performance of both hard- and soft-state multicast tree maintenance mechanisms degrades rapidly with increased mobility (beyond 10 m/s) and an increased number of mobile nodes

Chiang and Gerla [14] introduce a modified version of the CBT multicast algorithm Each multicast group has a unique multicast identifier Each multicast address identifies a host group, the group of hosts that should receive a packet sent to that address Each mul-ticast group is initialized and maintained by a mulmul-ticast server that becomes the core of the CBT for this multicast group Initially, the multicast server broadcasts the multicast identifier and its own node identifier using a flooding algorithm When a node receives this information, it will use it when it needs to join or quit the multicast group Simula-tions were performed to evaluate performance based on several criteria like control packet overhead, robustness to mobility, scaling properties with respect to multicast group mem-bership, and response time to joining a group Their simulation results show a rapid de-crease in throughput and an inde-crease in control-packet overhead with inde-creased mobility

of the nodes

Chiang et al [15] discuss an adaptive shared tree multicast that attempts to reduce path costs and distribute traffic more evenly in the network, by allowing a receiver to request, under certain circumstances, that a source deliver the multicast messages to it on the shortest path rather than on the shared tree path Although this approach offers an im-provement over ST-WIM [13], there is still a significant decrease in throughput as node mobility increases As speed increases, throughput decreases, due to the inability of the routing and multicast protocols to keep up with node movements

Results on the two approaches (per source and shared tree) show that these schemes scale well to large network size and can survive moderate speeds In comparison with the per-source-tree solution, the shared tree scheme exhibits lower throughput at heavy load,

as expected, due to higher traffic concentration on the common tree It shows, however, much less control overhead than the per-source tree, since the latter must constantly

re-23.5 MULTICASTING IN MOBILE AD HOC NETWORKS: ADOPTING WIRELESS PROTOCOLS 501

fresh separate trees rooted at different sources It also offers better scalability to large net-work size As node mobility increases, both schemes perform rather poorly, indicating the need to explore alternative multicast strategies

23.6 MULTICASTING IN MOBILE AD HOC NETWORKS:

MANET-INSPIRED MULTICAST PROTOCOLS

The development of specific MANET routing protocols is an open and active research area The following paragraphs briefly describe two distinct on-demand multicast proto-cols currently proposed for standardization to the IETF before results of performance studies are discussed

23.6.1 Multicast Ad Hoc On-Demand Distance Vector

The MAODV (multicast ad hoc on-demand distance vector) routing protocol [16] discov-ers multicast routes on demand using a broadcast route-discovery mechanism A mobile node originates a route request (RREQ) message when it wishes to join a multicast group,

or when it has data to send to a multicast group but does not have a route to that group Only a member of the desired multicast group may respond to a join RREQ If the RREQ

is not a join request, any node with a fresh enough route (based on group sequence num-ber) to the multicast group may respond If an intermediate node receives a join RREQ for

a multicast group of which it is not a member, or if it receives a RREQ and it does not have a route to that group, it rebroadcasts the RREQ to its neighbors

As the RREQ is broadcast across the network, nodes set up pointers to establish the re-verse route in their route tables A node receiving a RREQ first updates its route table to record the sequence number and the next-hop information for the source node This reverse route entry may later be used to relay a response back to the source For join RREQs, an additional entry is added to the multicast route table This entry is not acti-vated unless the route is selected to be part of the multicast tree

If a node receives a join RREQ for a multicast group, it may reply if it is a member of the multicast group’s tree and its recorded sequence number for the multicast group is at least as great as that contained in the RREQ The responding node updates its route and multicast route tables by placing the requesting node’s next-hop information in the tables, and then unicasts a request response (RREP) back to the source node As nodes along the path to the source node receive the RREP, they add both a route table and a multicast route table entry for the node from which they received the RREP, thereby creating the forward path

When a source node broadcasts a RREQ for a multicast group, it often receives more than one reply The source node keeps the received route with the greatest sequence num-ber and shortest hop count to the nearest memnum-ber of the multicast tree for a specified

peri-od of time, and disregards other routes At the end of this periperi-od, it enables the selected next hop in its multicast route table, and unicasts an activation message to this selected next hop The next hop, on receiving this message, enables the entry for the source node in its multicast route table If this node is a member of the multicast tree, it does not

propa-gate the message any further However, if this node is not a member of the multicast tree,

it will have received one or more RREPs from its neighbors It keeps the best next hop for its route to the multicast group, unicasts an activation message to that next hop, and en-ables the corresponding entry in its multicast route table This process continues until the node that originated the RREP (member of tree) is reached The activation message en-sures that the multicast tree does not have multiple paths to any tree node Nodes only for-ward data packets along activated routes in their multicast route tables

The first member of the multicast group becomes the leader for that group The multi-cast group leader is responsible for maintaining the multimulti-cast group sequence number and broadcasting this number to the multicast group This is done through a group hello mes-sage The group hello contains extensions that indicate the multicast group IP address and sequence numbers (incremented every group hello) of all multicast groups for which the node is the group leader Nodes use the group hello information to update their request table

Since AODV maintains hard state in its routing table, the protocol has to actively track and react to changes in this tree If a member terminates its membership with the group, the multicast tree requires pruning Links in the tree are monitored to detect link break-ages When a link breakage is detected, the node that is further from the multicast group leader (downstream of the break) is responsible for repairing the broken link If the tree cannot be reconnected, a new leader for the disconnected downstream node is chosen as follows If the node that initiated the route rebuilding is a multicast group member, it be-comes the new multicast group leader On the other had, if it was not a group member and has only one next hop for the tree, it prunes itself from the tree by sending its next hop a prune message This continues until a group member is reached Once these two partitions reconnect, a node eventually receives a group hello for the multicast group that contains group leader information that differs from the information it already has If this node is a member of the multicast group, and if it is a member of the partition whose group leader has the lower IP address, it can initiate reconnection of the multicast tree

23.6.2 On-Demand Multicast Routing Protocol

ODMRP (on-demand multicast routing protocol) [17] is mesh-based, and uses a forward-ing group concept (only a subset of nodes forwards the multicast packets) A soft-state ap-proach is taken in ODMRP to maintain multicast group members No explicit control message is required to leave the group

In ODMRP, group membership and multicast routes are established and updated by the source on demand When a multicast source has packets to send, but no route to the multi-cast group, it broadmulti-casts a join-query control packet to the entire network This join-query packet is periodically broadcast to refresh the membership information and update routes When an intermediate node receives the join-query packet, it stores the source ID and the sequence number in its message cache to detect any potential duplicates The routing table is updated with the appropriate node ID (i.e., backward learning) from which the message was received for the reverse path back to the source node If the message is not a duplicate and the time-to-live (TTL) is greater than zero, it is rebroadcast

When the join-query packet reaches a multicast receiver, it creates and broadcasts a

23.6 MANET-INSPIRED MULTICAST PROTOCOLS 503

“join reply” to its neighbors When a node receives a join reply, it checks to see if the next hop node ID of one of the entries matches its own ID If it does, the node realizes that it is on the path to the source and thus is part of the forwarding group, and sets the FG_FLAG (forwarding group flag) It then broadcasts its own join table built on matched entries The next hop node ID field is filled by extracting information from its routing table In this way, each forward group member propagates the join reply until it reaches the multicast source via the selected path (shortest) This whole process con-structs (or updates) the routes from sources to receivers and builds a mesh of nodes called the forwarding group

After the forwarding group establishment and route construction process, sources can multicast packets to receivers via selected routes and forwarding groups While it has data

to send, the source periodically sends join-query packets to refresh the forwarding group and routes When receiving the multicast data packet, a node forwards it only when it is not a duplicate and the setting of the FG_FLAG for the multicast group has not expired This procedure minimizes the traffic overhead and prevents sending packets through stale routes

In ODMRP, no explicit control packets need to be sent to join or leave the group If a multicast source wants to leave the group, it simply stops sending join-query packets since

it does not have any multicast data to send to the group If a receiver no longer wants to re-ceive from a particular multicast group, it does not send the join reply for that group Nodes in the forwarding group are demoted to nonforwarding nodes if not refreshed (no join tables received) before they time out

23.6.3 Comparing MAODV and ODMRP

The two on-demand protocols share certain salient characteristics In particular, they both discover multicast routes only in the presence of data packets to be delivered to a multicast destination Route discovery in either protocol is based on request and reply cycles in which multicast route information is stored in all intermediate nodes on the multicast path However, there are several important differences in the dynamics of the two proto-cols, which may give rise to significant performance differences

First, MAODV uses a shared multicast tree for forwarding data packets, whereas ODMRP maintains a mesh topology rooted from each source MAODV uses a multicast group leader to maintain up-to-date multicast tree information, whereas ODMRP source nodes periodically send request messages in order to refresh the multicast mesh

Second, ODMRP broadcasts the reply back to the source, whereas MAODV unicasts the reply back to the source By using a broadcast mechanism, ODMRP allows for multi-ple possible paths from the multicast source back to the receiver Since MAODV unicasts the reply back to the source, if an intermediate node on the path moves away, then the re-ply is lost and the route is lost

Third, MAODV does not activate a multicast route immediately, whereas ODMRP does In MAODV, a potential multicast source must wait for a specified time, allowing for multiple replies to be received before sending an activation message along the multicast route that it selects Again, when an intermediate node on the chosen path moves away be-fore a route activation is sent, the path is lost