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

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.
496
MULTICASTING: FROM FIXED NETWORKS TO AD HOC 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-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 mobile 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 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 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
498
MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS
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 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-
500
MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS
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 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. 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 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 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 member of the multicast tree for a specified peri-
od 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-
502
MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS
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 multicast 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 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
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.
504
MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS
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 bidirec-
tional shared multicast tree using unicast tunnels to provide connections between multi-
cast group members. Each group has at least one logical core that is responsible for mem-
ber 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 vari-
ety 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 “effi-
ciency” and “effectiveness” of the protocols. The reported results show that mesh proto-
cols performed significantly better than the tree protocols in mobile scenarios. Similarly,
[23] compared MAODV and ODMRP and found that ODMRP performs significantly bet-
ter than MAODV under very adverse conditions (high traffic and node mobility). Howev-
er, 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 flood-
ing 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 uti-
lizing 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 mobili-
ty is moderate and the network is large.
23.6 MANET-INSPIRED MULTICAST PROTOCOLS 505
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 envi-
sioned. Within the wired network, well-established routing protocols exist to offer effi-
cient multicasting service. As nodes become increasingly mobile, these protocols need to
evolve to provide similarly efficient service in the new environment. For cellular architec-
tures, multicast protocols are typically based on extensions to mobile IP, with trade-offs
between tree optimality and protocol overhead due to mobility. Adding infrastructure ele-
ments 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 infra-
structure, appears less promising. These protocols, having been designed for fixed net-
works, 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 oper-
ate 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 envi-
ronment, 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 pack-
et 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
1. S. Deering, Host extensions for IP multicasting, RFC 1112, August 1989, available at
/>2. S. Paul, Multicasting on the Internet and Its Applications, Norwell, MA: Kluwer Academic
Publishers, 1998.
3. S. Corson and J. Macker, Mobile ad hoc networking (MANET): Routing protocol performance
issues and evaluation considerations, RFC 2501, January 1999, available at
/rfc/rfc2501.txt.
4. C C. Chiang, Wireless Network Multicasting, PhD dissertation, University of California, Los
Angeles, Department of Computing Science, 1998.

5. C. E. Perkins, Mobile IP Design Principles and Practices, Reading, MA: Addison Wesley, 1997.
6. C. E. Perkins, IP mobility support, RFC 2002, October 1996, available at />rfc/rfc2002.txt.
7. 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.
8. T. Ballardie, P. Francis, and J. Crowcroft, Core based trees (CBT), in Proceedings of the
506
MULTICASTING: FROM FIXED NETWORKS TO AD HOC NETWORKS
SIGCOMM Symposium on Communications Architectures and Protocols, San Francisco, Sep-
tember 1993, pp. 85–95.
9. 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 Net-
works and Applications (MONET), 3, No.4, pages 365–379, 1998.
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.
15. C C. Chiang, M. Gerla, and L. Zhang, Adaptive shared tree multicast in mobile wireless net-
works, Proceedings of Globecom ‘98, Sydney, Australia, November 1998, pp. 193–207.
16. E. Royer and C. E. Perkins, Multicast operation of the ad-hoc on-demand distance vector rout-

ing protocol, in Proceedings of the 5th Annual ACM/IEEE Annual Conference on Mobile Com-
puting and Networking, Seattle, August 1999, pp. 207–218.
17. S. H. Bae, S J. Lee, W. Su, and M. Gerla, The design, implementation, and performance evalu-
ation of on-demand multicast routing protocol in multihop wireless networks, IEEE Network,
14, 1, 70–77, 2000.
18. 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.
19. R. Talpade, T. McAuley, J. Xie, and M. Liu, AMRoute: Ad hoc multicast routing protocol, to ap-
pear in Mobile Networks and Applications, special issue on multipoint communication in wire-
less mobile networks.
20. 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.
21. 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.
22. UCLA Computer Science Department Parallel Computing Laboratory and Wireless Adaptive
Mobility Laboratory, GloMoSim: A scalable simulation environment for wireless and wired net-
work systems, available at />23. 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.
24. 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.
REFERENCES 507