Multicast Routing Protocols in Mobile Ad Hoc Networks: A Comparative Survey and Taxonomy <s> On-Demand Global Hosts for Ad Hoc Multicast (OGHAM) <s> This memo specifies the extensions required of a host implementation ::: of the Internet Protocol (IP) to support multicasting. Recommended ::: procedure for IP multicasting in the Internet. This RFC obsoletes RFCs ::: 998 and 1054. [STANDARDS-TRACK] <s> BIB001 </s> Multicast Routing Protocols in Mobile Ad Hoc Networks: A Comparative Survey and Taxonomy <s> On-Demand Global Hosts for Ad Hoc Multicast (OGHAM) <s> Abstract Recent advances in pervasive computing and wireless technologies have enabled novel multicast services anywhere, anytime, such as mobile auctions, advertisement, and e-coupons. Routing/multicast protocols in large-scale ad-hoc networks adopt two-tier infrastructures to accommodate the effectiveness of the flooding scheme and the efficiency of the tree-based scheme. In these protocols, hosts with a maximal number of neighbors are chosen as backbone hosts (BHs) to forward packets. Most likely, these BHs will be traffic concentrations or bottlenecks of the network and spend significant amount of time forwarding packets. In this paper, a distinct strategy is proposed for constructing a two-tier infrastructure in a large-scale ad-hoc network. Hosts with a minimal number of hops to the other hosts rather than those with a maximal number of neighbors will be adopted as BHs in order to obtain shorter multicast routes. The problem of determining BHs can be formulated with linear programming. BHs thus found have the advantages of shorter relay and less concentration. Besides, BHs are selected on-demand and can be globally reused for different multicast groups without flooding again. Simulation results show that the proposed protocol has shorter transmission latency, fewer control/data packets and higher receiving data packet ratios than other existing multicast protocols. Besides, the two-tier infrastructure constructed by the proposed protocol is more stable. <s> BIB002
Protocol Description. OGHAM BIB002 constructs a two-tier architecture by selecting backbone hosts (BHs) on demand for multicast services. Each multicast member must be attached to a BH. Hosts with a minimal number of hops to the other hosts, rather than those with a maximal number of neighbors, will be adopted as BHs in order to obtain shorter multicast routes. BHs are responsible for determining multicast routes, forwarding data packets, handling dynamic group membership (the nodes can dynamically join or leave the group), and updating multicast routes due to host movement. When a source S wishes to create a multicast group, it first tries to find a BH within a region with a radius of 2r-hops (r ≥ 1 is a predefined integer) centered at S. If such a BH can be found, then S is attached to it. Otherwise, S broadcasts a message in a larger region, called a multicast region, with a radius of γ-hops (γ ≥ 2r is a predefined integer) centered at S for collecting neighboring information. Upon receiving the message, hosts in the multicast region reply their neighboring information to S. With this information, S then selects BHs and attaches neighbor BHs (NBHs) to BHs. After BHs in the multicast region are selected, receiver nodes can join the multicast group by asking the attached BHs to query the location of the source. The BH attached to the source then replies to the queries. Through round-trip communication (querying and replying), the BH attached to the source can determine the multicast routes from the source to the receiver nodes. This is depicted in Figure 25 . If a node outside a multicast region 1 in Figure 26 is attempting to join the multicast group created by the source node S in Figure 25(b) , it creates a multicast region (see Figure 26 ). There are two BHs (BH BIB001 and BH 5 ) selected in the new multicast region and R 3 is attached to BH BIB001 . In order to locate the source node S, BH 4 floods a message. Upon receiving the message, BH 2 replies to R 3 . Through the message exchange, a multicast route Discussion. OGHAM minimizes transmission time and lost packets because BHs minimize the total number of hops to all hosts (receivers). In OGHAM, once the infrastructure for a particular multicast group has been constructed, the selected BHs are globally available for the other ad hoc multicast groups. Therefore, it is not necessary for followup multicast groups to flood again in order to construct additional infrastructures. Hence, as the group size or the group number increases, the ratio of control packets declines (very scalable).