Efficient core selection for multicast routing in mobile ad hoc networks

Tài liệu tham khảo công nghệ thông tin Efficient core selection for multicast routing in mobile ad hoc networks

HANOI NATIONAL UNIVERSITY

UNIVERSITY OF TECHNOLOGY AND ENGINEERING

Binh Minh Nguyen

EFFICIENT CORE SELECTION FOR MULTICASTROUTING IN MOBILE AD HOC NETWORKS

GRADUATION THESIS

Faculty of Information Technology

HA NOI - 2010

HANOI NATIONAL UNIVERSITY

UNIVERSITY OF TECHNOLOGY AND ENGINEERING

Binh Minh Nguyen

EFFICIENT CORE SELECTION FOR MULTICASTROUTING IN MOBILE AD HOC NETWORKS

GRADUATION THESISFaculty of Information Technology

Supervisor: Dr Dai Tho Nguyen

HA NOI - 2010

There are many multicast routing protocols that use the notion of group-sharedtrees, for example: Protocol Independent Multicast (PIM), Core-Based Tree Asconstructing of a minimal-cost spanning tree to all members of the network is nearlyimpossible due to its excessive cost in terms of convergence time and network overhead,the core-based approach is chosen as a heuristic method to cope with multicast routing.The core node, which is also referred as center node or rendezvous point, is chosen from aselective group by different algorithm However, most of protocols for core election instatic networks are not suitable for mobile ad hoc network, since these algorithms requirethe knowledge of the whole network, the total number of nodes participating, the networktopology, link state, Which are not available or too expensive to acquire in mobile adhoc networks There are many proposed protocol for multicast routing in mobile ad hocnetworks, such as PUMA, ODMRP or MAODV In those protocols, PUMA (Protocol forunified multicasting through announcements) has shown to outperform others PUMAuses a single multicast announcement to establish and maintain the mesh However, thereis still a serious drawback, PUMA elects core by selecting the node with the highest IDand the core remains fixed afterwards In this thesis, we present an improvement ofPUMA by integrating an adaptive core selection mechanism into it The result show thatthe new PUMA achieves higher packet delivery ratios, lower delivery times than the oldone, while incurring only a little control overhead increment.

This thesis would not have been possible without the support of many people.

Firstly, I am heartily thankful to my supervisor, Dr Dai Tho Nguyen, whose ment, guidance and support from the initial to the final step enabled me to develop athroughout understanding of the subject

encourageI also would like to convey my thanks to the University of Technology and Engineering Hanoi National University for providing me the knowledge and experience in these fouryears.

-Lastly, I offer my regards and gratitude to all of those who supported me in any respectduring my studies.

Binh Minh Nguyen

Hanoi, May 2010

2.4 Multicast Routing in Internet 13

2.4.1 Distance Vector Multicast Routing Protocol (DVMRP) 13

2.4.2 Multicast Open Shortest Path First (MOSPF) 13

3.2 Core based model 18

3.3 Message structures and connectivity list 19

3.4 Mesh Organization 22

3.5 Core election process 25

3.6 Forwarding data packet 26

3.7 Sequence Numbers Recycle 27

3.8 Conclusion 28

CHAPTER 4: AN ADAPTIVE CORE SELECTION BASED MULTICAST ROUTING PROTOCOL FOR MANETs 29

4.1 Introduction 29

4.2 Core-based multicast routing protocol 32

4.3 Core-based Tree Multicast for MANET 35

4.4 Properties of Centroids in Tree with Weights 36

4.5 Core migration process 37

4.6 Algorithm Outline 38

4.7 Conclusion 39

CHAPTER 5: OUR PROPOSITION AND RESULTS 40

5.1 Motivation 40

5.2 Protocol description 40

5.3 Pseudo code 42

5.4 Network Simulator 2 (NS2) 44

5.5 Peer-to-Peer content distribution in MANETs 44

5.6 Experimental result and analysis 44

TABLE OF FIGURES

Figure 1: Multicast 5

Figure 2: Multicast group 7

Figure 3: Connectivity List 20

Figure 4: Mesh Creation 23

Figure 5: Multicast tree 33

Figure 6: Core Migration 41

Figure 7: Control overhead x Senders 46

Figure 8: Control overhead x Traffic Load 47

Figure 9: Packet loss ratio x Senders 48

Figure 10: Packet loss ratio x Traffic Load 48

Figure 11: Delivery time x Content Size 49

Figure 12: Delivery time x Number of concurrent requesting nodes 50

Figure 13: Delivery time x Mobility 51

TABLE OF ABBREVIATIONS

ADMR Adaptive Demand-driven Multicast Routing

DVMRP Distance Vector Multicast Routing Protocol

ICMP Internet Control Message Protocol

IGMP Internet Grouping Management Protocol

OTcl Object-oriented Tool Command Language

PIM Protocol Independent Multicast

PUMA Protocol for unified multicasting through announcement

CHAPTER 1: INTRODUCTION1.1 Overview

Multipoint communications have been existed for quite a long time According toresearches, the idea of one or more nodes sending data packet to many receiverssimultaneously has been available since at least the early of 1980 The term multicastingonly became widely known after Deering established the first internet request-for-comments on the field (aka RFC) [4]

After being proposed by Deering as the model to be followed by groups of users orcomputers to communicate among themselves simultaneously, IP Multicasting has beendeveloped Since then, a world-wide multicast backbone testbed also known as MBONEhas been constructed to test many protocols and applications.

Multicast communication has been implemented for a large number of applications.Some of these applications are video-conferencing, whiteboard, group communicationtools, and software and information distribution Initially, almost all of these applicationswere being used in intranets or in MBONE, and now, there are some Internet serviceproviders providing supports for these multicast applications in their backbone

1.2 Problem’s description

However, most of the research and development being done so far only considerphysically connected networks, where devices are connected together by the use of cablesand wires Due to the wired connections among them, the locations of nodes are fixed andthe only dynamic aspect in the networks is node and link failures Wireless networks are avery attractive and promising way of computing due to computer and infrastructuredevices and computers are not cabled together These networks constitute an environmentwhere everyone is free to move beyond the scope of his place He can take his devicessuch as computer, cell phone to anywhere and still be able to communicate, exchangeinformation with his colleagues.

The core of the thesis’s approach and contribution is multicasting over wirelessnetwork, which consists of enabling the propagation of multicast data packets overconnected meshes Multicasting over meshes is a significant departure for multicasting

over mobile ad hoc network Meshes have a high tolerance toward faults of node or linkfailures Moreover, the algorithm used to build meshes is rather simpler and easy todeploy.

Among most representative multicast routing protocols, PUMA [5] has shown to bethe most stable and efficient protocol due to its performance compare with other protocolssuch as MAODV or ADMR [10] … The most noticeable aspect of PUMA is that it uses avery simple and effective method to establish and maintain the mesh, this results in a lowcontrol overhead PUMA uses a single control message, a multicast announcement to beprecise, to maintain the mesh All transmissions are broadcast and no unicast protocol isneeded PUMA uses a core-based approach to build the mesh However, the method ofselecting core in PUMA has a serious drawback: PUMA selects the node with the highestcore id to become the core of the multicast group Furthermore, core changes only happenwhen the mesh undergoes partition or the old core leaves the mesh In this thesis, we willconcentrate on improving PUMA in two aspects:

Firstly, create a function to determine which nodes should be the core node of themulticast group The core node should be able to reach every receiving node as quickly aspossible Secondly, due to the mobility of the mobile ad hoc networks, the core nodecould malfunction unexpectedly and no longer fit to be the core of the group As a result,a core change to cope with these exceptions should be implemented

Inspired by the idea of core selection from [9], we propose an improvement ofPUMA with an adaptive core selection mechanism our own algorithm Our work hasmade PUMA perform approximately twenty percent better in term of delivery time thanthe old one The new implementation suffers from roughly two to five percent increase intotal control overhead, which we consider can be compensated by its superior deliverytime and packet delivery ratio As an addition contribution, we also implement thealgorithm for core selection, which is described in [9] to compare with our algorithm.Still, our implementation has shown to have lower control overhead, better packetdelivery ratio, and better delivery time.

1.3 Disposition

The rest of this thesis is organized as follows: Multicast is presented in chapter 2,and in chapter 3, an in-depth description of PUMA is presented Chapter 4 describes the

algorithm, implementation in details Lastly, chapter 5 concludes this thesis with ourproposition, performance results and analysis.

CHAPTER 2: MULTICAST ROUTING2.1 Introduction

Nowadays, a lot of emerging network applications requires the delivery of packetsfrom one or more transmitter to a group of receivers These applications include bulk datatransferring (i.e., the transfer of a software upgrade from software developers to usersneeding the upgrade), streaming of continuous media (e.g., the transfer of the audio, videoand text of a live lecture to a set of distributed lecture participants), sharing dataapplications (i.e., a teleconferencing or whiteboard application that is shared among manydistributed participants), data feeds (e.g., stock quotes), and interactive gaming (i.e.,distributed interactive virtual environments or multi-player games)

For each of these applications, a significantly useful abstraction is the notion of amulticast: the sending of a packet from one sender to multiple receivers with only a single"transmit" operation In this section, we consider the network layer aspects of multicast

2.2 Common mechanism

From the network perspective, multicast abstraction – a send operation that results ina copy of the data sent and delivered to many receivers – can be implemented in severalways One possibility is for the sender to use a separate unicast transport connection toeach receiver An application-layer [4] data unit that is forwarded to the transport-layer[4] is then duplicated at the sender and then transmitted over each individual connection.This approach is an implementation of one-sender-to-many multicast using the basicabstraction layer unicast networks It does not require explicit multicast support from thenetwork layer [4] to implement multicast abstraction but simulates multicast by usingmultiple point-to-point unicasts This is shown on the left of Figure 1, with a networkrouter in the shade of white, which means they are not actively involved in supportmulticast In this example, the multicast sender uses three separate unicast connections tothree receivers.

Figure 1: Multicast

A second alternative provides explicit support for multicast at the network layer Insecond approach, a single datagram passed from the sending host This datagram (or acopy of this datagram) is then replicated in a network router whenever it must be sentover multiple links to reach the recipient The right side of Figure 1 illustrates this secondmethod, with certain routers shaded in green to indicate that they are actively involved insupporting the multicast Here, the sender transmits a single datagram packet The routerwithin network then mirrors this datagram; a copy transfer to a recipient on the other endand the other copy is transferred to the rightmost router At the rightmost router, themulticast datagram that is broadcast over Ethernet with two receivers connected to therightmost router Apparently, this second approach towards multicast make more efficientuse of network bandwidth in which only a single copy of a datagram will ever go througha link Other the other hand, significant network layer support is necessary to make amulticast-aware network layer For the rest of this section we will focus on a multicast-aware network layer, as this approach is done on the Internet and put out some interestingchallenge

For multicast communications, we are immediately faced with two problems aremuch more complicated in the case of unicast - how to determine the recipient of amulticast datagram and how to address a datagram sent to the recipients In the case ofunicast communication, the IP addresses of the recipient (destination) are made for eachIP unicast datagram and determine recipients only However, in the case of multicast, we

now have more collection Does it make sense for each to implement datagram multicastIP address of all the many recipients? While this approach may be feasible with a smallnumber of recipients, it will not scale to the cases of hundreds or thousands of recipients,the amount of information in solving datagram would swamp the amount of data actuallycarried in the datagram's payload field Explicit identification of the receivers by thesender also requires that the sender know the identities and addresses of all of thereceivers We will see shortly that there are cases where this requirement might beundesirable.

For these reasons, the Internet architecture, a multicast datagram aims to addressindirection That is, an "identifier" is used for the group of receivers, and a copy of thedatagram that is addressed to the group with the single "identifier" is supplied to allmulticast receivers associated with that group In the Internet, the single "identifier",which represents a group of receivers, is a class D multicast address The group ofreceivers associated with a class D address is referred to as a multicast group Themulticast group abstraction is illustrated in Figure 2 Here are four hosts (shown in red) inrelation to the group multicast and receives all multicast datagram that address Theproblem that we need is that each host a unique IP address is the unicast address that iscompletely independent of the address of the multicast group in which it participates.

Figure 2: Multicast group

While the multicast group abstraction is simple, it raises many questions How doesa group get started and how does it terminate? How is the group address chosen? Howare new hosts added to the group (as senders or receivers)? Can anyone join a group (andsend to, or receive from, that group) or is group membership restricted and if so, bywhom? Do group members know the identities of the other group members as part of thenetwork layer protocol? How do the network routers interoperate with each other todeliver a multicast datagram to all group members? For the Internet, the answers to all ofthese questions involve the Internet Group Management Protocol [RFC 2236] So, let usnext consider the IGMP protocol and then return to these broader questions.

2.3 Multicast routing in LAN

IGMP (Internet Group Management Protocol) protocol developed from the HostMembership Protocol, described in the documents of Deering IGMP developmentIGMPv1 (RFC1112) to IGMPv2 (RFC2236) and the final version of IGMPv3(RFC3376) IGMP messages are sent inside IP packets with the protocol number of 2, inwhich the TTL value by 1 IGMP packets are transmitted only in the LAN and not befurther transferred to other LAN the TTL value of it Two of the most important goal isIGMP:

- Inform the multicast router is a machine that wants to receive multicast traffic of aspecific group

- Notice that a router is a machine to leave a multicast group (in other words, a computeris no longer interested in receiving multicast traffic again) The IGMP router used tomaintain information for each port of the router is the router multicast group does need tomove and want to get the host

Before a host can do any multicast traffic, a multicast application to be installed andrunning on that host After a host to join a group, the software will calculate a multicastaddress and network card will then start listening to a multicast MAC address Before ahost or a user wants to join a group, users need to know if the group exists and how tojoin that group For application level programs, users simply click a link on a website ormulticast addresses can be preconfigured on the client For example, a user may berequired to log into a server and authenticate with user name and If the username isauthenticated, multicast applications are automatically installed on the user's PC, meaningusers have to participate in the multicast group When users no longer want to usemulticast applications, users must leave the group For example, users simply close theapplication for leave multicast groups For multicast mechanism, a user needs to find outwhat they want to run applications, multicast address used by applications

How a router to know the machine needs to hear the multicast traffic? To receivemulticast traffic from a source, both the source and the receiver must first join to amulticast group This group was identified through a multicast address A host can join amulticast group by sending requests to the nearest router Operations are conductedthrough IGMP protocol IGMPv1 is defined in RFC1112 and its improvements, IGMPv2is defined in RFC2236 When there are few hosts want to join the group, PIM protocolwill inform each other between the router and the multicast tree formed between routers.IGMP and ICMP have many similarities, share some similar functions IGMP is alsopacked in packets (IP protocol number 2), but only IGMP limit in a layer 2 connection.To ensure continued router never transfer packets, the TTL field of IGMP always equal to1.

2.3.1 IGMPv1

Every 60 seconds, a router on each network segment will send the query to all hoststo check if this host is also interested in receiving multicast traffic again This router iscalled query IGMPv1 Querier router and its function is to invite the host to join the group.If a host wants to join a group, or it wants to continue receiving traffic from a groupthat was involved, it must respond with the membership-report message The host canjoin the multicast group at any time

However, IGMPv1 has no mechanism to enable a host to leave a group if that host isno longer interested in the contents of that multicast group Rather, the router willconclude a port of the bundle does not belong to a multicast group if the router does notreceive message-report membership for three consecutive cycles’ queries This meansthat, in default mode, the multicast traffic is sent on a network segment in threeconsecutive cycles after querying all members of the group who no longer listen tomulticast traffic

In addition, the router cannot keep a complete list of machines for each multicast groupmembers Instead, it needs to do is save the multicast group exists on the gate of it A message has IGMPv1 five fields:

1 Version: This field is 4-bit length, always with an assigned value

2 Type: School 4bit value, indicating two types of messages defined by IGMPv1 Type 1is the type Host Membership Query, which is used only by routers Type 2 is the type ofHost Membership report was used only by the host

3 Unused: 8bit length field contains the value 0 when sent and ignored when received 4 Checksum: 16bit checksum value is calculated by the source of the IGMP messages.Equipment typically receives checksum value and check if this value is not exactly equalsthe calculated value, the receiver will remove the frame

5 Group Address: The value assigned to the router 0.0.0.0 Membership query packet sentout This value is the value assigned to the multicast group address when sending aMembership report message

Note that when you combine two versions and the type, the value of a hexadecimalIGMPv1 Host Membership Query packet is 0x11 and a 0x12 IGMPv1 Host Membershipreport These values are compared with the values of IGMPv2

Function send Host Membership Report:

The host used IGMPv1 Host Membership report message to respond to IGMP

query packets and inform the router that the computer wants to receive multicast The hostIGMPv1 report uses multicast messages to communicate with the router, specifies themulticast group address to which it would like to receive In IGMPv1, a host sending amessage IGMPv1 Host membership report under the following circumstances: - When a host receives a packet IGMPv1 Query from the router, the host will assumeHostMembership report sent to all multicast group that it wants to receive traffic Thismessage is called IGMPv1 Solicited Host Membership report

- When a host to join a new group, it wants to send out immediately IGMPv1 HostMembership report to inform the router that it wants to receive traffic for that groupwithout waiting for IGMPv1 Query packet This message is called unsolicited IGMPv1Host Membership report

IGMPv1 Querier Router query:

To increase reserves, we can implement multiple multicast routers on the same network.Nevertheless, if all the routers send packets every 60 seconds, the query would be verywasteful of bandwidth Thus, a router should have assigned the role to send query packetsand multicast traffic transmitted into or out subnet If a router is down, second router canassume responsibility IGMPv1 usually based on the multicast routing information tosolve this problem elect router.

2.3.2 IGMPv2

IGMPv2 version introduces several differences compared with the first version Thequery packet is now known as General Queries These packages can be sent to addressall-hosts or to specific groups Another improvement is that the hosts are allowed to leavethe group When a host leaves a group decided to join it, it sends messages to LeaveGroupall-routers address All routers on a network segment will heed the message and the routerwill continue the query process The router will respond with a message on the messagesent by the group access This message will ask that there is also host to groups that wantto get traffic again Any host should respond by membership report messages Otherwise,the router will safely conclude that moving traffic is not necessary for that group on thatnetwork segment Around this time, the default is 3 minutes One of the reasons fordeveloping the IGMPv2 is that it provides a mechanism to leave the group better.IGMPv2 has added some new features:

- Group-specific Query: allows the router to send query for a specific group rather thanfor all group

- Maximum Response Time: A new field in the query packet, allowing the adjustmentperiod for host membership report message This feature can be useful when a largenumber of groups exists on a subnet and you want to reduce the number of messagesresponded by prolonged response messages over a longer period

- Leave group message: allow hosts to inform routers that hosts want to leave the group - Query router rating: Provide mechanisms for routers to send out the vote message whena query with multiple routers connected to a subnet

Membership report message is sent when a host to join a group Occasionally, thistype of message is also used to answer queries from the query router When a host to joina group, it will not wait for query packet from the router Instead, it will send amembership report Destination address of the membership report is the group destinationaddress To ensure that the router receives this message, hosts will send several messages,each 10 seconds apart.

IGMP v2 has four fields, is defined as follows:

1) Type: 8bit length field, indicating one of four types of messages defined by IGMPv2 The possible values are:

a Membership query (value 0x11): used by routers to find the presence of hosts on a subnet The message of this type of value assigned to the group address as in IGMPv1 0.0.0.0 A query message for a given group will address the group in this field A message of this type is usually sent when the router receives a leave group message from a host IGMPv2 leave group The message type is used to determine if there, still any member of a particular group

b Version 1 Membership report (code 0x12): used by IGMPv2 for compatibility with IGMPv1

c Version 2 Membership report (code 0x16) is sent by the member to notify the router when there is at least one member on the network

d Leave Group (0x17): submitted by members of the group if it is the last member to send membership report messages The router that hosts the message are reported for leaving the group

2) Maximum Response Time (Maximum Response Time): 8bit length of query messages.The default value for this field is 100 (approximately 10 seconds) The value will changefrom 1 to 255 (i.e., from 0.1 seconds to 25.5 seconds)

3) Checksum: Contains 16bit values calculated by machine source IGMP checksumcalculated over the entire load of the IP, not just the first 8bytes although 8bytes IGMPv2length.

4) Group Address: Assign the value of the query packet and assigns the group address ifthe message is specific to each group The membership report messages or leave groupmessages can carry the group's address in this field

If there are multiple routers on the same connection, the router with the smallest IPaddress will send out query packets Therefore, when a router receives a packet from arouter, it will check the source address of the packet there If the source address of therouter is under a local source address in packet arrival, the router will continue to send aquery packet because it knows that it will function as the query If the source address ofquery packets is smaller, the router will abandon the role query

IGMPv2 support backward compatibility with IGMPv1 Code for the type of queryand report messages of IGMPv2 and IGMPv1 are the same as 0x11 and 0x12 This allowshosts and routers running IGMPv2 realized IGMPv1 hosts on the network IGMPv2 helpsreducing the number of report messages sent by the host by allowing the administrator tochange the query time IGMPv1 has no parameters Maximum Response Time (MRT), sothe host simply use the default period is 10 seconds However, IGMPv2 messages includethe MRT; MRT indicates the time used by all hosts on the LAN IGMPv2 The process ofthe host sending the message Report is the same in IGMPv1 and IGMPv2 There is asmall difference is the router IGMPv2 queries sent packets every 125 seconds instead ofevery 60 seconds

The process IGMPv2 query and report use a query mechanism for specific groups.In IGMPv2, when a host leaving a group, it sends out a group of IGMPv2 leave messages.When a router receives messages, IGMPv2 leave group, instead of waiting for a period of

125 seconds, the router will immediately send a query message for that group Thismessage is just to ask if the host also want to receive multicast traffic for that group

The primary advantages compared IGMPv2 with IGMPv1 is that IGMPv2 providesa mechanism for a host to leave the multicast group faster.

2.4 Multicast Routing in Internet

2.4.1 Distance Vector Multicast Routing Protocol (DVMRP)

RFC 1075 describes the first version of DVMRP DVMRP has many versions Theactivities of DVMRP PIM-DM are similar The differences between PIM-DM andDVRMP are defined as follow:

- Cisco IOS does not support DVMRP, but it supports connection to a DVMRP network - DVMRP routing protocol itself, is similar to RIPv2 It sends updates every 60 secondsand 32 is the limit on the hop DVMRP routing protocol should take its own additionalcosts compared with PIM-DM

- DVMRP probe messages used to find neighboring routers

2.4.2 Multicast Open Shortest Path First (MOSPF)

MOSPF is defined in RFC1584, is an extended version of the unicast routingprotocols OSPFv2 MOSPF's basic operations are described as follows:

- MOSPF LSA group use the type 6 address Along with unicast OSPF, all MOSPFrouters in one area must have the same database link so that all MOSPF routers in an areacan be calculated with a SPT algorithm

- SPT algorithm is calculated on demand

- Update the calculation process; all the routers know where the group members based ongroup membership LSAs

- After some SPF calculations are completed, the information will be included inmulticast routing table

- Like OSPF unicast routing, shortest path tree is not a loop and know all the router portsupstream / downstream The result does not need the RPF check

- MOSPF can only work with OSPF unicast routing MOSPF is suitable for smallnetworks When multiple machines start sending multicast traffic, the routers have to

perform some calculations Dijkstra, result in wastage of CPU resources Cisco IOS doesnot support MOSPF.

2.4.3 PIM

2.4.3.1 PIM dense mode (PIM-DM)

The PIM router can be configured by type Dense Mode (also called PIM-DM) if thehosts are participating in multicast group located anywhere within the subnet Multicastsource address becomes the root of the tree and a multicast tree is built from source todestinations This mechanism is also known by the symbol (S, G) in which the path fromsource to group members is unique PIM-DM is useful when sending and receivingmachines are close together and multiple machines send and receives high-density trafficmulticast, but multicast traffic flow did not change Multicast tree is built by allowing thedispersal of traffic from source to all routers in the network Tree will grow from top tobottom In a short time, the unnecessary traffic flow will be like in the broadcast traffic.Nevertheless, when the router receives traffic for a group, the router will decide it wantsthe computer to receive data or not? If yes, the router will remain silent and continue toflow If no host registers for that Multicast group (via IGMP), the router would sendsPrune message to its neighboring routers in the direction of the root of the tree Branch ofthe tree will then be removed so that unnecessary traffic will not be distributed in thatdirection

Multicast tree will be built according to the requirements to join the group Then therouter which can not join the hosts will be deleted from the tree PIM-DM will recognizeneighboring devices by exchanging hello packets Neighbor information is used first tobuild the tree to all its neighbors Then, the branch of the tree will be removed in turn.When a multicast stream starts, the tree will be built Trees will only exist when itsmembers remain active If a new host joins the group, branch of the network segment willbe attached to the tree.

2.4.3.2 PIM sparse mode (PIM-SM)

Multicast routing protocols dense mode is useful when the application is multicastdense traffic and you need to distribute virtually the entire network However, if the userhas only a few subnets, routing protocols dense rule will remain spread over the entire

flow of inter-network, wasting bandwidth and resources In these cases, sparse stylerouting, PIM-SM instance can be used to reduce the wastage of network resources Thebasic difference between dense mode and sparse mode related to its default state Bydefault, the protocol rule of dense traffic continued to pass unless a group of routersbelow indicates that it does not want to get that traffic The sparse mode protocol does nottransmit traffic to any router of the group unless it receives a message request copies ofthe packet for a multicast group Neighboring routers receive packets only require one totwo purposes:

- The router has received a request to receive a packet from the router - A host on a network segment sent IGMP Join message for that group

Operation of the PIM sparse mode began when the packet is pushed on a specialrouter called the Rendezvous Point (RP) When the flow of the RP group, unlike in thedense, no RP router to automatically push any traffic on any router A router must requestthis flow

2.5 Multicast routing in ad hoc networks2.5.1 Tree-based approaches

Tree-based multicast is a well defined concept in cable network Most schemes foroffering multicast in cable networks are either source-or shared-tree-based Variousresearchers have attempted to extend tree-based effort to support multicast in a MANET senvironment This section provides an overview of some of these approaches.

- Ad Hoc Multicast Routing Protocol Utilizing Increasing ID Numbers (AMRIS) isan on-demand protocol that builds a shared multicast delivery tree to support multipletransmitters and receivers in one multicast session AMRIS dynamically assigns an IDnumber to each node in each multicast session Based on the ID number, a multicastdelivery tree - established at a specific node with Smallest-ID (Sid) - is created and IDnumber increases with tree extends from Sid To sum up, Sid is the source or the nodethat initiates a multicast session.

- Multicast Ad hoc On-Demand Distance Vector (MAODV) Protocol – MAODVdetermines multicast routes on demand by a broadcast path discovery mechanism to applythe identical route request (RREQ) and route reply (RREP) messages found in the unicast

AODV protocol A mobile node forms a RREQ message when it wants to join a multicastgroup or has information to send to a multicast group, but exists no route to this group.Only one member of the preferred multicast group may react to a join RREQ If theRREQ is not a JOIN request, whichever node with a new adequate route (based on groupsequence number) to the multicast group can reply If a transitional node receives a joinRREQ for a multicast group to which it is not a member, or, it receives a RREQ and nothas a route to this group; it rebroadcasts the RREQ to its neighbors.

2.5.2 Mesh-based approaches

Unlike a tree approach, mesh-based multicast protocols may have numerous pathsbetween any source and destination Presented studies show that tree-based protocols arenot essentially best for the multicast in a MANET where network topology changesregularly In such a situation, mesh-based protocols seem to do better than tree-basedprotocols due to the availability of alternative paths, which allows multicast datagram tobe transmitted to the recipients even if the links stop working This section presents anoverview of some of the mesh-based approaches in a MANET.

On-Demand Multicast Routing Protocol (ODMRP) — ODMRP is a mesh-basedprotocol that uses a forwarding group concept A soft state advance is taken in ODMRP topreserve multicast group members No unequivocal control message is necessary to leavethe group In ODMRP, group membership and multicast routes are built and updated bydemand of the source When a multicast source has packets to transmit, having no route tothe multicast group, it broadcast a Join-Query control packet to the whole network ThisJoin-Query packet is regularly broadcast to update member information and routes Whena transitional node receives a Join-Query packet, it keeps the source ID and sequencenumber in its message cache to identify any possible duplication Routing table is updatedwith a proper node ID (i.e backward knowledge) from which message is received If themessage is not a replica and TTL is greater than zero, it is rebroadcast.

Core-Assisted Mesh Protocol (CAMP) helps multicasting by creating a commonmesh for each multicast group Meshes then created help maintain connection formulticast users, even with moving node It based on concepts from CBT, but in contrast toCBT where all traffic flows through the central node, the central nodes in CAMP are usedto limit the control traffic The fundamental operation of CAMP includes construction and

maintenances the multicast meshes for a multicast group It requires a mapping servicethat gives routers with the addresses of groups identified by their names It also involvesaccess to router information from a unicast routing protocol Each router maintains arouting table (RT) CAMP adapts this table when a multicast group must be inserted orremoved Based on RT, a multicast routing table (MRT) was built A router can update itsMRT based on topological changes or communication received from its neighbors.

2.6 Conclusion

Steve Deering wrote the first RFC for multicast mechanism in 1986 Nevertheless, afew years later, the huge demand for multicast mechanism has exploded, from acommunication needs such as audio, video, TV programs Multicast also has beenstudied as a component of the Internet, known as Project Multicast backbone, Mbone.Today, as the need for a protocol that can be used for moving devices, such as cell phone,cars, many protocols for MANETs have been proposed such as CAMP, MAODV It willbe interesting to see how the deployment multicast routing in MANETs plays out over thenext decade of computer networking.

CHAPTER 3: AN EFFICIENT AND ROBUST MULTICASTING ROUTINGPROTOCOL FOR MANETS

3.1 Introduction

PUMA [5], as an abbreviation of Protocol for unified multicasting throughannouncement, is a multicast routing protocol PUMA is a receiver-initiated shared mesh.PUMA has shown to perform better than most of the representative multicast routingprotocols PUMA, compares with other multicast routing protocol, achieves a better datadelivery ratio with a very low control overhead Furthermore, all transmissions in PUMAare broadcast, it does not require any unicast protocol to work

Like CAMP [3] and MAODV [10], PUMA uses a receiver initiated approach inwhich a receiver joins a multicast group by using the address of a special node (core inCAMP or group leader in MAODV) without having to perform a network-wide floodingof control and data packets from every sources of the group PUMA also bypasses theneed for a unicast routing protocol and the assignment of cores to multicast groupsbeforehand.

3.2 Core based model

PUMA uses a distributed algorithm in order to select one of the recipients of agroup to be the core of the group, and each router in the network, at the distance of at leastone next-hop to the chosen core of each group is also informed about the core election.Within a limited time proportional to the time needed for the router to arrive to the routerfarthest away from the core of a group, each router almost have one or more path to theelected core.

Each receiver is connected to the core along all of the shortest paths between thereceiver and the elected core All nodes on shortest paths between any receiver and thecore form the mesh collectively A transmitter sends a data packet to the group along oneof the shortest path When a data packet arrived at the mesh, it then will be flooded withinthe mesh As a result, all of the mesh member receive the packet Each node maintains apacket ID cache to prevent packet duplication.

Especially, PUMA only uses a control message to maintain all of its functions,which is call multicast announcement Each multicast announcement contains a sequence

number, the group’s address (group ID), the core’s address (core ID), the distance to thecore, a mesh_member flag which is set when the sending node is a member of the meshand lastly, a parent preferred by the neighbor to reach the core With the informationretrieved by the announcements, nodes elect the core for the mesh, select the best routesto reach the core from outside of a multicast group, notify other nodes about the mesh’state, and maintain the mesh.

3.3 Message structures and connectivity list

A node that believes it is the core of a multicast group periodically transmittedannouncement messages for that group As multicast message passing through thenetwork, it established a connectivity list in every node in the network Using theconnectivity list, a node can set up a mesh, as a result, routes data packets from the senderto the receivers.

Every node store the necessary information acquired from the entire multicastannouncement it received from its neighbors in its connectivity list Newer multicastmessage from a neighbor (for example, with a higher sequence number) will replaceentries in which the sequence numbers are lower for the same group Thus, for a certaingroup, a node will have only one entry in the list of its connections from a given neighbor,and it just keeps that information with the latest sequence numbers for each core

Each item in the connectivity list, in addition to storing multicast announcementmessages, it also stores the time when the packet was received, neighbor from which itreceived The node then creates its own multicast announcement message, by selectingthe best entry in the connectivity list.

For announcement with same core ID, multicast message with the highest sequencenumber is chosen For announcement with same core ID and same sequence number, thenthe message with smaller distances to the core is valid If all of these criteria are the same,the multicast announcement that the first reach the nodes is considered better Afterchoosing the best-multicast announcement message, the node creates its multicastannouncement follow by these rules:

Core ID: best-multicast announcement core-id

Group ID: Group id of the best-multicast announcement

Sequence number: Best-multicast announcement’s sequence numberDistance to core: The distance to core of the best-multicast

announcement plus one

Parent: Neighbor from which this node received the best-multicast announcement

Mesh member: Flag

Figure 3: Connectivity List

The connectivity list stores information on one or more links that exist to reach thecore When a particular group undergoes a core change, then the node deletes all theentries in the old list of connectivity and built a new one Figure 3 show the process ofpropagating multicast announcement messages and constructing the connectivity list Thebold arrows represent the neighbor from which a node gets its best multicastannouncement message Node 6 has three entries in its list of connectivity for theneighbors of 5, 1 and 7 However, it chose the entry that received from 5 as the best entry,because it has the shortest distance to the core, moreover, was received earlier than themessage from node 1 Node 6 uses these inputs to generate its own multicastannouncement, which specifies:

Group ID = 224.0.0.6,Core ID = 11,

Sequence number = 79,Distance to the core = 2And Parent = 5

If a node wants to transmit data packets to the group, it sends to the node that it received its best multicast announcement from If this link is broken, then it will try the next best, the same applies if this link is broken Therefore, each network node has one or more route to the core Multicast announcement sent by the core has the distance to the core set to zero and the parent field is invalid_address By default, multicast

announcements are creating by the core every three seconds When a node receives a multicast announcement with a new sequence number, it waits for a short period (for example, 100 ms) to collect multicast announcement from many neighbors before trying to generate iits own multicast announcement message

When multiple groups exist, nodes gather all multicast announcement they receive,and disseminate them periodically every multicast announcement interval (3 seconds) Onthe contrary, for announcement that belong to the group that was heard for the first time,which will lead to a new core, or changes in mesh membership status, is sentimmediately, without wait for gathering It helps avoid critical situations, such as fight forcore or the establishment of the mesh.

3.4 Mesh Organization

Apparently, only the receiving nodes consider themselves to be the members of thenetwork and set the mesh member flag to true before trying to send the multicastannouncement messages to their neighbor Node who are not receiver will considerthemselves as members of the mesh if only there at least one child in their list ofconnectivity A node in the connectivity list is a mesh child if the following conditions aremet:

(a) mesh_member flag is set,

(b) The distance from the core of the next node is greater than its distance from the core, and

(c) Multicast announcement corresponding to this node has been received within a period equal to two intervals of the multicast announcement

The third condition is used to make sure that a neighbor is still the neighborhood Ifa node has a child and is a member of mesh, then there is a shortest path from a receiverto the core, which crosses the node

Figure 4: Mesh Creation

As shown in Figure 4, the node M is chosen as the core of the group and the networknodes to know their distance to the core by plus one to the best entry in their list ofconnectivity The receivers (in this example: node I, F, A, B, D and M) set the meshmember flag to TRUE in their multicast announcement message Upon receipt of themulticast announcement message from node F, node G and H, they considered themselvesas mesh members Node F is considered a child mesh for each of them, because thedistance from F to the cores (3) is greater than theirs (2) In addition, nodes J, K, L, C andE also consider themselves members of mesh Because mesh-members are considered as amesh child of all nodes, which have the distance to the core smaller than its own,therefore it results in all of them becoming mesh members The above scheme results inthe integration of all shortest paths between the receiver and the core of the network Inthe example, two shortest path of distance 3 from the receiver F to the core M exists F ->G -> L -> M and F -> H -> L -> M Moreover, both paths are one part of the mesh