Multicast Routing Protocols in Mobile Ad Hoc Networks: A Comparative Survey and Taxonomy <s> Multicast Core Extraction Distributed Ad Hoc Routing (MCEDAR) <s> In this paper, we present the MCEDAR (multicast core extraction distributed ad hoc routing) multicast routing algorithm for ad hoc networks. MCEDAR is an extension to the CEDAR architecture and provides the robustness of mesh based routing protocols and the approximates the efficiency of tree based forwarding protocols. It decouples the control infrastructure from the actual data forwarding infrastructure. The decoupling allows for a very minimalistic and low overhead control infrastructure while still enabling very efficient data forwarding. <s> BIB001 </s> Multicast Routing Protocols in Mobile Ad Hoc Networks: A Comparative Survey and Taxonomy <s> Multicast Core Extraction Distributed Ad Hoc Routing (MCEDAR) <s> CEDAR is an algorithm for QoS routing in ad hoc network environments. It has three key components: (a) the establishment and maintenance of a self-organizing routing infrastructure called the core for performing route computations, (b) the propagation of the link-state of stable high-bandwidth links in the core through increase/decrease waves, and (c) a QoS route computation algorithm that is executed at the core nodes using only locally available state. But preliminary performance evaluation shows that CEDAR is a robust and adaptive QoS routing algorithm that reacts effectively to the dynamics of the network while still approximating link-state performance for stable networks. <s> BIB002
Protocol Description. MCEDAR BIB001 is a Source-Tree-based multicast protocol. It combines the Tree-based protocol and the Mesh-based protocol to provide efficiency. It uses CEDAR BIB002 to construct the mesh. MCEDAR uses a mesh structure called the mgraph as its multicast routing infrastructure. CEDAR creates a minimum dominating set (MDS) of core nodes using a core computation algorithm. In addition, CEDAR provides a mechanism for core broadcast on reliable unicast, which dynamically establishes a source tree. Each core in this set advertises its existence through a beacon signal up to the next 3 hops, and, therefore, each core identifies its nearby cores and builds a virtual link. Every nonmember node located 1 hop away from at least one core node selects one of the core nodes as its dominator node. When a noncore node wants receiver R 1 to become a member of a multicast group, it requests its dominating core node, core 5, to perform the join operation. A node performs the join operation by core broadcasting a JoinReq (MA, joinID), which consists of the address of the group (MA) the node wishes to join and the current joinID of the node corresponding to the multicast group. When a node that is not a member of the multicast group (MA) receives the JoinReq, it forwards the message to its nearby core nodes in accordance with the core broadcast mechanism. In contrast, when an existing MA member receives the JoinReq, it sends a Join-Ack (MA, joinID) only if its joinID is smaller than the joinID that arrives in the request. It then forwards the JoinReq further downstream. However, if its joinID is larger than the incoming joinID, it forwards the request like a nonmember. The joinID in the Join-Ack message sent back to the node requesting the join is that of the replying node. When an intermediate node on the reverse path receives the Join-Ack message, it decides whether to accept it or reject it based on the robustness factor (R). Each mgraph member maintains two other data structures, the parent set and the child set. When a node accepts a Join-Ack, it adds the upstream mgraph member to its parent set. Further, if the downstream node is not already in its child set, it forwards the Join-Ack to the downstream node and adds the downstream node to its child set. However, when the intermediate node decides to reject a Join-Ack, it suppresses the Join-Ack and performs an explicit leave from the upstream node so that its ID is removed from the upstream node's child set. The number of accepting JoinAck packets at the dominator node (core 5) is governed by the robustness factor (R). If R = 2, therefore, core 5 will accept only two Join-Acks and reject the others. The member on accepting a Join-Ack sets its joinID to the maximum of its current joinID and the arriving joinID incremented by one. It then stamps the joinID of the Join-Ack with its new joinID. Figure 8 illustrates the joining process of the new receiver R 1 with joinID = 6. Figure 9 shows how data are forwarded in MCEDAR. Discussion. MCEDAR is robust and efficient, since a receiver node has multiple paths to a multicast tree. However, when used with small and sparsely distributed groups, it may become less efficient and more expensive due to bandwidth constraints, network topology dynamics, and high channel access cost. In a high mobility environment, nodes need to change their cores frequently, thereby increasing control overhead. MCEDAR is also more complex than other multicast routing protocols (Tree-based and Mesh-based).