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) 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 multicasting service As nodes become increasingly mobile, these protocols need to evolve to provide similarly efficient service in the new environment This survey will briefly describe the basic approaches to multicasting in wired networks It then gradually relaxes the requirement that all nodes be stationary, discussing multicast protocols for cellular networks (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 applications 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, military 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 connected 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 496 MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS 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, administratively 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 Instead of sending via multiple unicasts, multicasting minimizes the link bandwidth consumption, 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 particularly challenging environment for multicast is a mobile ad hoc network (MANET) A MANET consists of a dynamic collection of nodes with sometimes rapidly changing multihop 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 network topology can change randomly and rapidly, at unpredictable times Since wireless links generally have lower capacity, congestion is typically the norm rather than the exception 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 addition, within a wireless medium, it is even more crucial to reduce the transmission overhead 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 listed 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 23.4 MULTICASTING IN FIXED INFRASTRUCTURE CELLULAR NETWORKS 497 It then gradually relaxes the requirement that all nodes be stationary In a first step, multicast members are allowed to be mobile, connecting to a fixed infrastructure In this cellular 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 mobile-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, persource shortest tree and shared tree The 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 received 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 destinations 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 distributed), 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 forwarding 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 Mobile users communicate via a single-hop wireless channel with a base station, which is in turn connected to a wired backbone 498 MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS 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 mobile node’s visited network that provides routing services to the mobile node while it is registered 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 mobile node chooses to declare its multicast membership Possible choices are the home network, the currently visited network, 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 mobile 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 dynamic 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 difficulty 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 Therefore, if the host is likely to be stationary for an extended period of time, this option is preferred 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 guaranteed two-way communication with the multicast group and are unable to acquire a colocated 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 foreign 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 23.4 MULTICASTING IN FIXED INFRASTRUCTURE CELLULAR NETWORKS 499 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 network 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 membership 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 multicast) 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 different 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 introduced 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 services 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 Initially, 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 becomes 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 notifies 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 mobile 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 500 MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS 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 expected 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 therefore provides good multicast support for mobile nodes However, every 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 destinations 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 destination, 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- 23.5 MULTICASTING IN MOBILE AD HOC NETWORKS: ADOPTING WIRELESS PROTOCOLS 501 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, irrespective 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 updates), the shared tree solution also fails Also, as the entire network moves and the membership changes dynamically, the RP may not be in the center, aggravating the nonoptimality 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 results 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 multicast group is initialized and maintained by a multicast 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 Simulations were performed to evaluate performance based on several criteria like control packet overhead, robustness to mobility, scaling properties with respect to multicast group membership, and response time to joining a group Their simulation results show a rapid decrease in throughput and an increase in control-packet overhead with increased 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 improvement 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- 502 MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS fresh separate trees rooted at different sources It also offers better scalability to large network 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 protocols 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] discovers 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 number) 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 reverse 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 activated 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 number and shortest hop count to the nearest member of the multicast tree for a specified period of time, and disregards other routes At the end of this period, 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- 23.6 MANET-INSPIRED MULTICAST PROTOCOLS 503 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 enables 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 ensures that the multicast tree does not have multiple paths to any tree node Nodes only forward data packets along activated routes in their multicast route tables The first member of the multicast group becomes the leader for that group The multicast group leader is responsible for maintaining the multicast group sequence number and broadcasting this number to the multicast group This is done through a group hello message 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 breakages 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 becomes 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 forwarding group concept (only a subset of nodes forwards the multicast packets) A soft-state approach 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 multicast group, it broadcasts 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 504 MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS “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 constructs (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 receive 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 protocols, 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 multiple 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 reply 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 before a route activation is sent, the path is lost 23.6 MANET-INSPIRED MULTICAST PROTOCOLS 505 Fourth, MAODV sends control messages to repair broken links and to manage network partitions Since there are no redundant links, MAODV needs to recover from breaks in links If two network partitions come together, MAODV requires explicit action to merge two network partitions ODMRP uses a soft-state approach, and lets broken links time out Routes from multicast sources to receivers in ODMRP are periodically refreshed by the source 23.6.4 Performance Comparisons Bagrodia et al [18] simulated several multicast routing protocols developed specifically for MANET: ad hoc multicast routing (AMRoute) [19], ODMRP [17], ad hoc multicast routing protocol utilizing increasing id numbers (AMRIS) [20], and core-assisted mesh protocol (CAMP) [21] These protocols were evaluated under diverse network scenarios using the GloMoSim library [22] AMRoute is a tree-based protocol It creates a bidirectional shared multicast tree using unicast tunnels to provide connections between multicast group members Each group has at least one logical core that is responsible for member and tree maintenance AMRIS establishes a shared tree for multicast data forwarding Each node in the network is assigned a multicast session ID number The ranking order of ID numbers is used to direct the flow of multicast data CAMP supports multicasting by creating a shared mesh structure All nodes in the network maintain a set of tables with membership and routing information To explore the effect of mobility on the protocol performance, the speed of the network hosts was varied The number of data packets sent by senders was varied to emulate a variety of multicast applications Different multicast group member sizes were simulated to investigate the impact on performance Various traffic loads were also applied to study how traffic patterns influence multicast performance Metrics were used to show the “efficiency” and “effectiveness” of the protocols The reported results show that mesh protocols performed significantly better than the tree protocols in mobile scenarios Similarly, [23] compared MAODV and ODMRP and found that ODMRP performs significantly better than MAODV under very adverse conditions (high traffic and node mobility) However, the per-source-based mesh and the periodic refresh messages to update the soft state also resulted in significantly higher protocol overheads, and limited the scalability of ODMRP with respect to number of senders in a multicast group and multicast group size Lim and Kim [24] evaluated multicast tree construction and proposed two new flooding methods that can improve the performance of the classic flooding method Their paper proposes the use of self-pruning and dominant pruning to reduce the flooding cost by utilizing neighborhood information Self-pruning uses direct neighbor information only, whereas dominant pruning uses neighborhood information up to two hops away Based on extended neighborhood information, each node computes a reduced forward list for the next transmissions on the broadcast tree The performance gain from dominant pruning is greater than that from self-pruning However, dominant pruning has larger overheads than self-pruning and the overheads increase with host mobility Thus, the self-pruning method could be more appropriate when the mobility of the host is high and the network is small In contrast, the dominant pruning method could be the method of choice when the mobility is moderate and the network is large 506 MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS 23.7 CONCLUSIONS Multicasting can efficiently support a wide variety of applications that are characterized by a close degree of collaboration, typical of many MANET applications currently envisioned Within the wired network, well-established routing protocols exist to offer efficient multicasting service As nodes become increasingly mobile, these protocols need to evolve to provide similarly efficient service in the new environment For cellular architectures, multicast protocols are typically based on extensions to mobile IP, with trade-offs between tree optimality and protocol overhead due to mobility Adding infrastructure elements can help in reducing protocol overhead while reducing the size of the multicast tree Adopting wired multicast protocols to MANETs, which are completely lacking in infrastructure, appears less promising These protocols, having been designed for fixed networks, may fail to keep up with node movements and frequent topology changes due to host mobility, and substantially increase the protocol overheads New protocols that operate in an on-demand manner are being proposed and investigated Existing studies show that tree-based on-demand protocols are not necessarily the best choice In a harsh environment, where the network topology changes very frequently, mesh-based protocols seem to outperform tree-based protocols, due to the availability of alternative paths, which allow multicast datagrams to be delivered to all or most multicast receivers even if links fail Much still has to be done to improve protocol performance (as measured by the packet delivery ratio) while reducing the associated overhead ACKNOWLEDGMENTS The author would like to thank Prof James P Black and Prof Carey Williamson for their detailed review of an earlier draft of this chapter and their suggestions for improvement REFERENCES S Deering, Host extensions for IP multicasting, RFC 1112, August 1989, available at http://www.ietf.org/rfc/rfc1112.txt S Paul, Multicasting on the Internet and Its Applications, Norwell, MA: Kluwer Academic Publishers, 1998 S Corson and J Macker, Mobile ad hoc networking (MANET): Routing protocol performance issues and evaluation considerations, RFC 2501, January 1999, available at http://www.ietf.org /rfc/rfc2501.txt C.-C Chiang, Wireless Network Multicasting, PhD dissertation, University of California, Los Angeles, Department of Computing Science, 1998 C E Perkins, Mobile IP Design Principles and Practices, Reading, MA: Addison Wesley, 1997 C E Perkins, IP mobility support, RFC 2002, October 1996, available at http://www.ietf.org/ rfc/rfc2002.txt S Deering, D Estrin, D Farinacci, V Jacobson, C.-G Liu, and L Wei, The PIM architecture for wide-area multicast routing, IEEE/ACM Transactions on Networking 4, 153–162, 1996 T Ballardie, P Francis, and J Crowcroft, Core based trees (CBT), in Proceedings of the REFERENCES 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 507 SIGCOMM Symposium on Communications Architectures and Protocols, San Francisco, September 1993, pp 85–95 V Chikarmane, C Williamson, R Bunt, and W Mackrell, Multicast support for mobile hosts using Mobile IP: Design issues and proposed approach, ACM/Baltzer Journal on Mobile Networks and Applications (MONET), 3, No.4, pages 365–379, 1998 C L Williamson, T G Harrison, W L Mackrell, and R B Bunt, Performance evaluation of the MoM mobile multicast protocol, ACM/Baltzer Journal on Mobile Networks and Applications (MONET), 3, 2, 189–201, 1998 H.-S Shin, Y.-J Suh, and D.-H Kwon, Multicast routing protocol by multicast agent in mobile networks, in Proceedings of the 2000 International Conference on Parallel Processing, Toronto, August 2000, pp 271–278 C.-C Chiang, M Gerla, and L Zhang, Tree multicast strategies in mobile, multihop wireless networks, ACM/Baltzer Journal on Mobile Networks and Applications (MONET), 4, 3, 193– 207, 1999 C.-C Chiang, M Gerla, and L Zhang, Shared tree wireless network multicast, in Proceedings of the Sixth International Conference on Computer Communications and Networks, 1997, pp 28–33 C.-C Chiang and M Gerla, Routing and multicast in multihop, mobile wireless networks, in Proceedings of the IEEE International Conference on Universal Personal Communications (ICUPC’97), 1997, pp 28–33 C.-C Chiang, M Gerla, and L Zhang, Adaptive shared tree multicast in mobile wireless networks, Proceedings of Globecom ‘98, Sydney, Australia, November 1998, pp 193–207 E Royer and C E Perkins, Multicast operation of the ad-hoc on-demand distance vector routing protocol, in Proceedings of the 5th Annual ACM/IEEE Annual Conference on Mobile Computing and Networking, Seattle, August 1999, pp 207–218 S H Bae, S.-J Lee, W Su, and M Gerla, The design, implementation, and performance evaluation of on-demand multicast routing protocol in multihop wireless networks, IEEE Network, 14, 1, 70–77, 2000 R Bagrodia, M Gerla, J Hsu, W Su, and S.-J Lee, A performance comparison study of ad hoc wireless multicast protocols, in Proceedings of the Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), March 2000, vol 2, pp 565–574 R Talpade, T McAuley, J Xie, and M Liu, AMRoute: Ad hoc multicast routing protocol, to appear in Mobile Networks and Applications, special issue on multipoint communication in wireless mobile networks C W Wu and Y C Tay, AMRIS: A multicast protocol for ad hoc wireless networks, in Military Communications Conference Proceedings, 1999 (MILCOM 1999), vol 1, pp 25–29 New York: IEEE, 1999 J J Garcia-Luna-Aceves and E.vL Madruga, The core-assisted mesh protocol, IEEE Journal on Selected Areas in Communications, 17, 8, pp 1380–1394, 1999 UCLA Computer Science Department Parallel Computing Laboratory and Wireless Adaptive Mobility Laboratory, GloMoSim: A scalable simulation environment for wireless and wired network systems, available at http://pcl.cs.ucla.edu/projects/domans/glomosim.html E Cheng, On-demand multicast routing in mobile ad hoc networks, M Eng thesis, Carleton University, Ottawa, Canada, Department of Systems and Computer Engineering, 2001 H Lim and C Kim, Multicast tree construction and flooding in wireless ad hoc networks, in Proceedings of the 3rd ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems, Boston, August 2000, pp 61–68  ... describe two distinct on-demand multicast protocols currently proposed for standardization to the IETF before results of performance studies are discussed 23.6.1 Multicast Ad Hoc On-Demand Distance... 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... expensive because of the difficulty in managing the multicast tree Furthermore, the extra delay incurred when rebuilding a multicast tree can create the possibility of a disruption in multicast