Multicasting Multicasting is the process by which data

Multicasting • Multicasting is the process by which data is set to multiple recipients. • Simplest but a very inefficient way is to initiate multiple unicast sessions. • Usually multicast is receiver driven – a receiver becomes a multicast group member and receives multicast data; but it could also be source driven. • Reliability difficult – UDP usually used for disseminating data. • An extreme example of multicast is global broadcast wherein data is relayed to all users in the network. • Two popular methods: Source based, Core based. • A multicast group does not necessarily have a single source group communications

Popular Multicast Protocols • DVMRP –Distance Vector Based – built on top of RIP. • CBT – Core Based Tree – choose a core at the center of the network – all packets are routed through core. • PIM – Protocol Independent Multicast : application layer; two modes; sparse mode and dense mode; each mode is similar to one of the two above schemes. • None are dynamic enough for the ad hoc network. . cannot cope with mobility.

Multicasting in Ad Hoc Networks • Receivers usually join the multicast session by issuing something like a join message. • In ad hoc networks, the protocol should minimize the overhead consumed in maintaining the multicast session. • Various protocols have been proposed. We will look at a few.

Multicast using AODV • By Elizabeth Royer and Charlie Perkins • Multicasting using AODV uses messaging similar to that used in unicast. • RREQ and RREP messages. • The protocol is geared towards receiver initiated multicast. • Each multicast group has with it an associated group leader. • This leader is responsible for maintaining the multicast “group sequence number”. • Nodes can join and leave the group at any time.

Multicast group member Route Discovery Multicast tree member Group Leader R R • Node that wishes to join or wishes to send data to a multicast group creates an RREQ. • The destination address is the IP address of the multicast group and the RREQ includes the last known sequence number of the group. • JOIN is indicated via a flag. • It broadcasts RREQ to neighbors. ? • If it is a join request, only a group member may respond. Else, a node with a route to the group may reply. • If no route is available, the node receiving the RREQ creates a reverse route entry and forwards the RREQ.

• Source node would wait for a certain period and if no response is received it would reply with the broadcast ID increased by 1. • This is done for some pre-specified number of times. • When a node receives a join RREQ it adds an “unactivated” entry for the source of the RREQ in its multicast route table. • Each next-hop entry also has an associated ACTIVE flag. • If this flag is false the node does not forward packets along that link.

• The route reply message propagates as in AODV for unicast operations. • How is that ? R R • Respond if it is a router for the multicast group tree (either member or tree node) and if its recorded sequence number for the multicast group is at least as great as that in the RREQ (why? ). • Naturally group leader can always respond. ? • The recipient node would include the requesting node’s multihop info in its table and generates an RREP. • It unicasts the RREP along the reverse path recorded. • Each intermediate node adds a forward entry into its multicast route table.

Activation/De-activation of Multicast Route • The source of the Join message receives multiple RREP messages. • Thus, an explicit message is required to ensure that one of the paths is grafted onto the tree. • This is done at the end of the discovery interval by the source node. • It keeps track of the route with the largest multicast group sequence number. • If there are ties, it chooses the shortest hop count to the multicast tree.

R R R • It then issues a Multicast activation message (MACT) to the selected next hop and sets its Activated flag for this next hop. • The next hop it activates the route (sets flags for both links) and sends its own MACT message to the next hop. • This continues until the originator of the RREP message is reached. • At this point, the new path to the multicast tree has been determined.

Leaving the group • This MACT message is also used if a node wishes to revoke its multicast group member status. • If it is a leaf node and it wishes to leave the group it may do so and prune itself out from the tree. • Non-leaf nodes can leave the group, but they cannot prune themselves out of the tree. • A leaf node that wishes to leave, unicasts a MACT message and sets the PRUNE flag set to its next hop. • It deletes this info from its multicast routing table. • If this makes the next hop a leaf, and the node is not a group member, it may prune itself out of the tree.

Pruning R R R Path of MACT message with PRUNE flag set R R R

Multicast Tree Maintenance • As nodes move, the links in the multicast tree are prone to failure. • Each multicast link requires ongoing maintenance to ensure that other multicast tree members are always reachable. • Two forms of maintenance: • Repairing a broken tree branch following a link-break. • Reconnecting after a network partition.

Link breaks • If no data packets have been seen recently, a node should hear hello packets from each of its next hops (on either side) every hello interval. • The data could be anything –RREQ, RREP, actual data • If no message (of any type) is received within certain time (called hello_life), it is inferred that the node is now out of range – repair is required. • When a link breaks, the node downstream of the break, that is, the node away from the multicast group leader is responsible for the repair. • This distinction is required since, if nodes on both sides try to repair the tree, it may lead to a loop.

• The downstream node that we just mentioned, broadcasts an RREQ message. • It also includes its distance from the group leader. • Only those member nodes that are at least that close can respond to this RREQ. • This prevents nodes from the same side of the tree from responding – thereby creating loops. • Notice here – why not generate sequence number ? • A small TTL can be set to begin with to make sure that the repair is local. • If nothing is received, then the RREQ can be broadcast across the network.

• A node can respond to the RREQ by sending a RREP if : • It is a part of the multicast tree. • It has a fresh enough multicast group sequence number. • Its hop count to the multicast group leader is smaller than that indicated by the extension field of the RREQ. • At the end of the discovery period, our “downstream” node selects its next hop and unicasts a MACT message to it to activate the link.

Link Repair Group Leader R R R R • The node that is responsible for the repair also informs its downstream nodes of the new hop count.

• In order to indicate this new hop count, the message sent will have the UPDATE Flag set. • It is possible that due to this link breakage, some upstream nodes become leaf nodes. If these nodes are not multicast group members, they may prune themselves from the tree. • If the node initiating the repair fails in its first attempt to reconnect, it re-tries for a predetermined additional number of attempts. • If after this, it does not receive a response, it deems that the network is partitioned.

Upon Network Partition • When the Network is partitioned, if the node attempting to repair the link is a group member, it becomes the group leader. • If it is not a group member, and the failure of the link has caused the node to become a leaf node, it prunes itself from the tree by sending a prune message to its next-hop. • This node, would then, if it is a group member, becomes the group leader. Else it proceeds as the previous node. • If the node initiating the repair is not a group member, and it has more than one downstream link, it cannot prune itself from the tree. Of course, it is not eligible to become the group leader.

• It then selects one of its next hops and unicasts a MACT message with the Group Leader flag set. • This would indicate that the next group member who receives this message should become the group member. • If the next hop is a group member, it becomes the leader. • If not, it unicasts it to one of its next-hop neighbors. • Finally a group leader is selected. • Note now, that there are two leaders for the multicast group.

Re-Connecting Partitioned Trees • It is possible that two partitions can reconnect in time due to topological changes in the network. • The Group Hello (GRPH) message is used in such a case to reconnect the partitioned trees. • This GRPH message is periodically broadcast by the group leader across the network. • It contains the IP address of the leader and the network. • If a multicast group member from a different partition receives this message, it notices that this contains group leader info. that is different from its own records.

• The repair of the multicast tree is now initiated by the group leader who has the lower IP address. • Why not both try ? To avoid loops. • The group leader with this lower IP address (GL 1) unicasts a RREQ message to the other group leader (GL 2) using the node from which the GRPH was received. • The RREQ message has a sequence number and the REPAIR flag is set. • Any nodes from GL 2’s partition who receive this, should forward the message along the tree towards GL 2.

• When GL 2 receives this message, it chooses the larger of the two sequence numbers (the one received and the one it has currently) and then it increments this value by 1. • It includes this in the RREP message and unicasts it back to GL 1. The REPAIR flag is set. • The RREP message, they add the next-hop entry to their multicast route table and activate it. • If any node on GL 1’s multicast tree receive this RREP message they will forward this towards GL 1. • When GL 1 receives’ this message, the two trees are re-connected.

References • Chapter 6 of book. • Elizabeth M. Royer and Charles E. Perkins. "Multicast Operation of the Ad-hoc On-Demand Distance Vector Routing Protocol. " Proceedings of Mobi. Com '99, Seattle, WA, August 1999, pp. 207218. • http: //www. cs. ucsb. edu/~eroyer/publications. html

ADVANTAGES: • Retains good properties of AODV. Can inter-operate with it. • Fairly simple. No need to continually send multicast info – on-demand. DISADVANTAGES: • Not scalable. • Location of group member could cause performance to differ.

On Demand Multicast Routing Protocol (ODMRP) • Invented by Mario Gerla’s group at UCLA. • Maintains a mesh instead of a tree. • This would avoid control overhead required for tree maintenance. • Group membership and multicast routes are established by the “source” and updated on demand. • Like most on-demand protocols this procedure requires a route request and a route reply.

The JOIN REQUEST message • When a multicast source has packets to send, it periodically advertises to the entire network, a member advertisement packet called the “JOIN REQUEST”. • Notice here that it is the source that initiates the multicast ! • When a node receives the JOIN REQUEST, it stores the ID of the upstream node from which it received the message (if it is not a duplicate) and does a local re-broadcast of the packet. • When this JOIN REQUEST reaches a multicast receiver it creates or updates its entry in its “Member Table” includes next hop neighbor from whom the packet was received.

Forming the Forwarding Group • When a node finds valid entries in its Member Table, it locally broadcasts a JOIN TABLE to its neighbors. • When a node receives this JOIN TABLE message it checks if the next-node entry of one of the entries matches its own ID. • If it does, the receiving node realizes that it is on the path to the source and therefore joins the “Forwarding Group”. • It sets what is known as the forwarding group flag FG-flag and broadcasts its own JOIN TABLE message. • JOIN TABLE is propagated all the way to the source.

Forming a Mesh Structure • Although the data forwarding is done along the shortest path, redundant information is stored during the flooding process. • This mesh would include all paths between any source receiver multicast pair. (Note: there could be multiple sources and receivers). • Note that a multicast member could be a forwarding group member for other multicast members. • This mesh provides richer connectivity among multicast tree members.

Example S 1 I 1 R 2 S 2 I 2 R 3 Sender Next Node S 1 I 1 S 2 I 2 Sender Next Node S 1 Join Table of R 1 Join Table of I 1 • The arrows indicate the flow of JOIN TABLE messages. • Note that I 2 forwards packets to all three receivers but from different sources. • However, if the need arises, it can also forward packets from the second source to R 1.

Soft State • In ODMRP no control messages are required to be sent to join or leave the group. • If a multicast source wants to leave the group it simply stops sending the JOIN REQUEST packets. • If a receiver wants to leave, it removes the corresponding entries in the Member table and does not transmit the JOIN TABLE for that group. • Nodes in the forwarding group are demoted to nonforwarding nodes if not refreshed (no JOIN TABLES received) before they time-out. • However, this process may be expensive.

ADVANTAGES OF ODMRP: • Simple to implement. • On-Demand advantages. • Mesh structure would offer alternate paths more robust than a tree. DISADVANTAGES OF ODMRP • Not scalable • Soft state maintenance might result in significant overhead. • For mesh structure redundant info. may be significant.

References • S. Lee, M. Gerla and C-C. Chiang, “On Demand Multicast Routing Protocol”, Proceedings of IEEE WCNC (Wireless Communications and Networking Conference), 1999. • S. Lee et al, “A Performance Comparison Study of Ad Hoc Wireless Multicast Protocols”, Proceedings of INFOCOM 2000. (contains info about other multicast protocols as well).

Other Multicast Protocols • CAMP: Core Assisted Mesh Protocol – by JJ et al. uses multiple core nodes. Better than CBT. • AMRIS: Ad hoc Multicast Routing Protocol using Increasing ID Numbers: by C-K Toh et al. Establishes a shared tree for data forwarding. • More details in Reference 2, in previous slide and references mentioned therein.

Because of ICNP, no class next Tuesday which is 11/13.