13.07.2015 Views

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

90 P.M. Ruiz et al.Access NetworkR 2Remote Networkwith receiversARMIGS 2S 3R 1R 3S 1Multicast Forwarders (MF)L<strong>in</strong>ksMcast routesFig. 2. Multicast mesh after request/reply phasedeliver a MMARP JOIN message to its next hop after four retries, it broadcastsa MMARP NACK message to its one-hop neighbours. Upon the reception ofthis message, the neighbours use their own route to reach that next hop. Shouldany of them not know an alternate path, they repeat the process until a path isfound. Although this recovery process does not offer optimal routes, it offers aquick recovery before the next topology refresh.Once the mesh is established, the data forward<strong>in</strong>g is very simple: data packetsaddressed to a certa<strong>in</strong> multicast group are only propagated <strong>by</strong> ad hoc nodeswhich have their MF FLAG active for that group. When such a data packetarrives at a node whose MF FLAG for that group has not expired, it checksthat it is not a duplicate and <strong>in</strong> that case retransmits the packet. In any othercase the packet is dropped.3.2 Support of Standard IP Multicast ProtocolsThe protocols used <strong>by</strong> standard IP nodes to perform their basic operation (suchas ARP, or IGMP) were designed to operate <strong>in</strong> BMA (Broadcast Medium Access)networks. However, <strong>in</strong> multihop ad hoc networks, the l<strong>in</strong>k layer has a differentsemantics. The neighbours of a node are able to receive the frames it sends but itis not guaranteed that they are able to directly communicate among all of them.In traditional ad hoc rout<strong>in</strong>g protocols without explicit support for standardIP nodes this is not a problem because each ad hoc node sends its own sourceannouncement or jo<strong>in</strong> message. In order to be compatible with the standardIP multicast model, MMARP nodes <strong>in</strong> the neighbourhood of a standard IPnode have to send MMARP SOURCE or MMARP JOIN messages on behalfof the standard IP node. This means that messages generated <strong>by</strong> standard IP

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!