1 / 67

CMPE 257: Wireless and Mobile Networking

CMPE 257: Wireless and Mobile Networking. Spring 2002 Week 5. Multicast Communication in Ad Hoc Networks. Group Communications Conference Scenario Rescue/Disaster Scenario Battlefield Scenario …. Multicast routing classification. Routing Protocols. Table Driven - Proactive.

daw
Télécharger la présentation

CMPE 257: Wireless and Mobile Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMPE 257: Wireless and Mobile Networking Spring 2002 Week 5 CMPE 257 Spring 2002

  2. Multicast Communication in Ad Hoc Networks • Group Communications • Conference Scenario • Rescue/Disaster Scenario • Battlefield Scenario … CMPE 257 Spring 2002

  3. Multicast routing classification Routing Protocols Table Driven - Proactive On Demand -Reactive AMRoute CAMP/WRP M-AODV AMRIS ODMRP CMPE 257 Spring 2002

  4. Overview • AMRoute • AMRIS • ODMRP • M-AODV • CAMP • Flooding and Variations CMPE 257 Spring 2002

  5. Multicasting • A multicast group is defined with a unique group identifier • Nodes may join or leave the multicast group anytime • In traditional networks, the physical network topology does not change often • In MANET, the physical topology can change often CMPE 257 Spring 2002

  6. Multicasting in MANET • Need to take topology change into account when designing a multicast protocol • Several new protocols have been proposed for multicasting in MANET CMPE 257 Spring 2002

  7. On-Demand Multicast Routing Protocol (ODMRP) • ODMRP requires cooperation of nodes wishing to send data to the multicast group • To construct the multicast mesh • A sender node wishing to send multicast packets periodically floods a Join Data packet throughout the network • Periodic transmissions are used to update the routes CMPE 257 Spring 2002

  8. On-Demand Multicast Routing Protocol (ODMRP) • Each multicast group member on receiving a Join Data, broadcasts a Join Table to all its neighbors • Join Table contains (sender S, next node N) pairs • next node N denotes the next node on the path from the group member to the multicast sender S • When node N receives the above broadcast, N becomes member of the forwarding group • When node N becomes a forwarding group member, it transmits Join Table containing the entry (S,M) where M is the next hop towards node S CMPE 257 Spring 2002

  9. On-Demand Multicast Routing Protocol (ODMRP) • Assume that S is a sender node A M N S Join Data C B T D Multicast group member CMPE 257 Spring 2002

  10. On-Demand Multicast Routing Protocol (ODMRP) A M N S Join Data Join Data Join Data C B T D Multicast group member CMPE 257 Spring 2002

  11. On-Demand Multicast Routing Protocol (ODMRP) A M N S Join Table (S,M) C B T D Join Table (S,C) Multicast group member CMPE 257 Spring 2002

  12. On-Demand Multicast Routing Protocol (ODMRP) F Join Table (S,N) A M N S F C B T D Join Table (S,N) F marks a forwarding group member CMPE 257 Spring 2002

  13. On-Demand Multicast Routing Protocol (ODMRP) F Join Table (S,S) A M N S F F C B T D Multicast group member CMPE 257 Spring 2002

  14. On-Demand Multicast Routing Protocol (ODMRP) F A M N S F F C B T D Join Data (T) Multicast group member CMPE 257 Spring 2002

  15. On-Demand Multicast Routing Protocol (ODMRP) F A M N S F Join Table (T,C) F F C B T D Join Table (T,T) Join Table (T,D) Join Table (T,C) Multicast group member CMPE 257 Spring 2002

  16. ODMRP Multicast Delivery • A sender broadcasts data packets to all its neighbors • Members of the forwarding group forward the packets • Using ODMRP, multiple routes from a sender to a multicast receiver may exist due to the mesh structure created by the forwarding group members CMPE 257 Spring 2002

  17. ODMRP • No explicit join or leave procedure • A sender wishing to stop multicasting data simply stops sending Join Data messages • A multicast group member wishing to leave the group stops sending Join Table messages • A forwarding node ceases its forwarding status unless refreshed by receipt of a Join Table message • Link failure/repair taken into account when updating routes in response to periodic Join Data floods from the senders CMPE 257 Spring 2002

  18. AODV Multicasting [Royer00Mobicom] • Each multicast group has a group leader • Group leader is responsible for maintaining group sequence number (which is used to ensure freshness of routing information) • Similar to sequence numbers for AODV unicast • First node joining a group becomes group leader • A node on becoming a group leader, broadcasts a Group Hello message CMPE 257 Spring 2002

  19. AODV Group Sequence Number • In our illustrations, we will ignore the group sequence numbers • However, note that a node makes use of information received only with recent enough sequence number CMPE 257 Spring 2002

  20. AODV Multicast Tree Multicast tree links E Group leader L C J G H D K A B N Group and multicast tree member Tree (but not group) member CMPE 257 Spring 2002

  21. Joining the Multicast Tree: AODV E Group leader L C J G H D K A B N wishes to join the group: it floods RREQ N Route Request (RREQ) CMPE 257 Spring 2002

  22. Joining the Multicast Tree: AODV E Group leader L C J G H D K A B N N wishes to join the group Route Reply (RREP) CMPE 257 Spring 2002

  23. Joining the Multicast Tree: AODV E Group leader L C J G H D K A B N N wishes to join the group Multicast Activation (MACT) CMPE 257 Spring 2002

  24. Joining the Multicast Tree: AODV Multicast tree links E Group leader L C J G H D K A B N N has joined the group Group member Tree (but not group) member CMPE 257 Spring 2002

  25. Sending Data on the Multicast Tree • Data is delivered along the tree edges maintained by the Multicast AODV algorithm • If a node which does not belong to the multicast group wishes to multicast a packet • It sends a non-join RREQ which is treated similar in many ways to RREQ for joining the group • As a result, the sender finds a route to a multicast group member • Once data is delivered to this group member, the data is delivered to remaining members along multicast tree edges CMPE 257 Spring 2002

  26. Leaving a Multicast Tree: AODV Multicast tree links E Group leader L J wishes to leave the group C J G H D K A B N CMPE 257 Spring 2002

  27. Leaving a Multicast Tree: AODV Since J is not a leaf node, it must remain a tree member E Group leader L J has left the group C J G H D K A B N CMPE 257 Spring 2002

  28. Leaving a Multicast Tree: AODV E Group leader L C J G H D K A MACT (prune) B N N wishes to leave the multicast group CMPE 257 Spring 2002

  29. Leaving a Multicast Tree: AODV E Group leader L C J G H D K MACT (prune) A B N Node N has removed itself from the multicast group. Now node K has become a leaf, and K is not in the group. So node K removes itself from the tree as well. CMPE 257 Spring 2002

  30. Leaving a Multicast Tree: AODV E Group leader L C J G H D K A B N Nodes N and K are no more in the multicast tree. CMPE 257 Spring 2002

  31. Handling a Link Failure: AODV Multicasting • When a link (X,Y) on the multicast tree breaks, the node that is further away from the leader is responsible to reconstruct the tree, say node X • Node X, which is further downstream, transmits a Route Request (RREQ) • Only nodes which are closer to the leader than node X’s last known distance are allowed to send RREP in response to the RREQ, to prevent nodes that are further downstream from node X from responding CMPE 257 Spring 2002

  32. Handling Partitions: AODV • When failure of link (X,Y) results in a partition, the downstream node, say X, initiates Route Request • If a Route Reply is not received in response, then node X assumes that it is partitioned from the group leader • A new group leader is chosen in the partition containing node X • If node X is a multicast group member, it becomes the group leader, else a group member downstream from X is chosen as the group leader CMPE 257 Spring 2002

  33. Merging Partitions: AODV • If the network is partitioned, then each partition has its own group leader • When two partitions merge, group leader from one of the two partitions is chosen as the leader for the merged network • The leader with the larger identifier remains group leader CMPE 257 Spring 2002

  34. Merging Partitions: AODV • Each group leader periodically sends Group Hello • Assume that two partitions exist with nodes P and Q as group leaders, and let P < Q • Assume that node A is in the same partition as node P, and that node B is in the same partition as node Q • Assume that a link forms between nodes A and B P A B Q CMPE 257 Spring 2002

  35. Merging Partitions: AODV • Assume that node A receives Group Hello originated by node Q through its new neighbor B • Node A asks exclusive permission from its leader P to merge the two trees using a special Route Request • Node A sends a special Route Request to node Q • Node Q then sends a Group Hello message (with a special flag) • All tree nodes receiving this Group Hello record Q as the leader CMPE 257 Spring 2002

  36. Merging Partitions: AODV P A B Hello (Q) Q CMPE 257 Spring 2002

  37. Merging Partitions: AODV RREQ (can I repair partition) P A RREP (Yes) B Q CMPE 257 Spring 2002

  38. Merging Partitions: AODV P A B RREQ (repair) Q CMPE 257 Spring 2002

  39. Merging Partitions: AODV P A Group Hello (update) B Q Q becomes leader of the merged multicast tree New group sequence number is larger than most recent ones known to P and Q both CMPE 257 Spring 2002

  40. Summary: Multicast AODV • Similar to unicast AODV • Uses leaders to maintain group sequence numbers, and to help in tree maintenance CMPE 257 Spring 2002

  41. CAMP • Uses Mesh instead of Tree • Assumes the underlying unicast routing protocol can provide correct distance to known destination within a finite time • Ensure reverse shortest paths from receivers to sources are part of a group’s mesh • Strongly depends on the underlying unicast protocol to work correctly in presence of router failure and network partition CMPE 257 Spring 2002

  42. Core in CAMP.. • Extends the basic receiver-initiated approach introduced in CBT to create multicast mesh • Core is used to limit the control traffic needed for receivers to join the group • Cores need not to be part of mesh of their group CMPE 257 Spring 2002

  43. Join the group • Is any of my neighbors a member of group ? • Else send a Join Request towards a Core • Only members of the group can reply with a Join-Ack • Cores are not reachable => expanding ring search (flooding) CMPE 257 Spring 2002

  44. core d b i c g h j k CMPE 257 Spring 2002

  45. core d b c g h CMPE 257 Spring 2002

  46. Ad Hoc Multicast Routing Protocol utilizing Increasing id-number(AMRIS) CMPE 257 Spring 2002

  47. ..Overview • Sid initiates a multicast session by broadcasting a NEW-SESSION message • All nodes that receive NEW-SESSION generate their own “multicast session member id” (msm-id) based on the value found in NEW-SESSION message , then rebroadcast NEW-SESSION with its msm-id • NEW-SESSION travels in an expanding ring fashion outwards from Sid, so nodes closer to Sid will generally have smaller msm-ids than those further away CMPE 257 Spring 2002

  48. Join the Tree • If the requesting node X has a neighbor who is already on the tree • send JOIN-REQ to that neighbor Y • neighbor Y will send back JOIN-ACK to confirm now X is its child • If the neighbors are not on the tree, but have smaller msm-id • X send JOIN-REQ to one of the neighbor Y CMPE 257 Spring 2002

  49. ..Join the Tree • After receiving a JOIN-REQ, neighbor Y sends out its own JOIN-REQ • If the parent node Y can successfully join the tree, then it sends a JOIN-ACK to X , otherwise, it will sends a JOIN-NACK to X • X will send a broadcast JOIN-REQ with limited ttl range, in turn will trigger all the nodes within that range will send out their JOIN-REQ • X might possibly receive several JOIN_ACK from its potential parent . It will choose one of them and sends a JOIN-CONF to that parent CMPE 257 Spring 2002

  50. AMRoute • Bidirectional shared-tree (1 tree per group) • Create a mesh to establish connectivity before tree creation • Only group sender and receiver are tree nodes (replication/forwarding only performed by group members, and state only in tree node) • No support needed from network nodes who are not interested/capable of multicast CMPE 257 Spring 2002

More Related