AD HOC NETWORKS Technologies and Protocols phần 5 pps

A compromise between the tree-based and mesh-based protocols is made in MCEDAR [2] builds a mesh structure among multicast members to obtain Multicasting techniques in MANETs can be clas

The mobility of the nodes creates a continuously changing topology forcommunication Routing paths break and new ones are formed dynami-cally.

Unlike the wired network, wireless medium is a broadcast medium; allnodes in the transmission range of a node can hear the packets simulta-neously

In light of the above differences, the issues and challenges for nication in MANETs are more complex than their wired counterpart

intercommu-IP multicasting was first proposed over a decade ago [1] as an extension toInternet architecture to support multiple clients at network layer The funda-mental motivation behind IP multicasting is to save network and bandwidthresource via transmitting a single copy of data to reach multiple receivers si-multaneously A basic principle for the forwarding tree is to branch as close

to the receivers as possible In ad hoc networks, we want to adhere to thisrequirement as closely as possible because of the severe bandwidth limitations

in ad hoc networking environments

Similar to Internet multicasting, it is necessary to deal with dynamic berships in multicast groups in ad hoc networks In both Internet and ad hocmulticasting, dynamic membership refers to the fact that individual clients mayjoin and leave multicasting sessions dynamically As a result, a multicast pro-tocol needs to define operations of member join and leave, and how to recoverfrom routing failure The data forwarding path is constructed either as a tree or

mem-a mesh

What makes ad hoc multicasting distinguished from Internet multicasting isthat mobile nodes could move around freely and rapidly In other words, wehave to deal with high network dynamics due to node mobility, which makes

ad hoc multicasting even more challenging Ad hoc multicasting protocols inexisting literature have either evolved from the Internet multicast protocol, ordesigned specifically for ad hoc networks Most of these protocols attempt toadapt to the network dynamics in ad hoc networks The primary goal of adhoc multicasting protocols should be to construct/maintain a robust & efficientmulticasting route even during high network dynamics By “robust”, we meanthat the protocol should be able to operate correctly in spite of node mobility andtopology changes By “efficient”, we mean both control and data forwardingoverheads should be maintained low

This chapter is organized as follows In Section 4.2, we outline a sification methodology for multicasting protocols The details of the specificprotocols are described in Section 4.3 Broadcasting is discussed in Section 4.4

clas-In Section 4.5, we provide a qualitative comparison of multicasting protocols.Overarching issues such as quality of service, energy conservation, reliability,

and security are addressed in Section 4.6, followed by the concluding remarks

in Section 4.7

4.2 Classifications of Protocols

4.2.1 Dealing with Group Dynamics

General principles for dealing with dynamic membership in ad hoc ticasting protocols are: on demand, receiver initiated, timer-based soft state.The basic idea of on demand approaches is to construct and maintain multicastroutes only when needed In receiver initiated approaches, it is the receiver’sresponsibility to find and keep track of a multicast session If some states must

mul-be maintained to make a multicast session work, it is desirable to use based soft state instead of hard state Soft states are maintained on demandand refreshed from time to time; otherwise, its associated timer expires and thestate is removed from intermediate nodes

timer-A primary issue for managing multicast group dynamics is the routing paththat is built for data forwarding Most existing ad hoc multicasting protocols can

be classified as tree-based or mesh-based In a tree-based protocol, a tree-likedata forwarding path is built with the root at the source of the multicast session.The multicast tree consists of a unique path from the sender to a receiver.This can be extended to a shared-tree when multiple multicast sessions are inparallel in the network and can share some common parts of data forwardingtrees with each other In a mesh-based protocol, in contrast, multiple routes mayexist between any pair of source and destination, which is intended to enrichthe connectivity among group members for better resilience against topologychanges

A major difference between tree-based and mesh-based protocols lies in themanner in which a multicast message is relayed In a tree-based protocol, eachintermediate node on the tree has a well-defined list of next hops for a specificmulticast session It will send a copy of the received message to only theneighboring nodes on its nexthop list In most mesh-based protocols, however,relaying transmission takes a more redundant approach: each node on the meshwill broadcast the message upon its first reception of the message Althoughthis transmission redundancy may lead to higher overheads in many cases, it isstill worth because of its resilience against dynamic topology and link quality

A compromise between the tree-based and mesh-based protocols is made

in MCEDAR [2] builds a mesh structure among multicast members to obtain

Multicasting techniques in MANETs can be classified based on group namics or network dynamics In this section, we describe these two basis ofclassifications Details of the protocols will follow in the next section

dy-redundant connectivity, and extract a data forwarding tree on top of the meshstructure.

To the best of our knowledge, all the existing protocols for ad hoc casting, both tree-based and mesh-based, do not make explicit efforts to takeadvantage of the broadcast nature of wireless medium In an ad hoc networkwith a shared wireless channel, a link between any pair of nodes is not welldefined as in the case of Internet Instead, any two nodes within each other’stransmission ranges may form a link, and a node may form multiple links toits neighbors simultaneously We believe this feature of broadcast media canhelp in reducing transmission overhead if we take it into consideration whenconstructing the multicast routes

multi-4.2.2 Dealing with Network Dynamics

As mentioned earlier, we need to overcome the network dynamics in order

to achieve robust and efficient ad hoc multicasting A major source of networkdynamics is node mobility and node failure In this subsection we summarizesome basic approaches to addressing this challenge in existing literature Wecite some examples for each of the approaches

Approach 1: Reliance on More Nodes Since nodes are mobile, every termediate node could be a possible cause of route breakage If we includemore nodes in the multicast infrastructure, we can obtain better connectivityamong group members When a link breaks due to node mobility, we may have

in-a good chin-ance to find in-an in-alternin-ative route In other words, we don’t need toinitiate route maintenance procedure frequently corresponding to every singlelink failure

The second advantage of this approach is related to the transmission aspect:redundant transmissions can offset the influence of the unreliable wireless links

In many mesh-based protocols, within-mesh flooding is a common choice toimprove reliability of data delivery

Some examples for this approach include CAMP’s forwarding group [3],ODMRP [4], and neighbor support multicasting [5]

Approach 2: Reliance on Fewer Nodes Since nodes are mobile, it is and resource-consuming for a large number of nodes to get involved in routeconstruction and maintenance By limiting the number of nodes involved, thecontrol overhead can be reduced We can extract a virtual backbone, typi-cally a dominating set of the entire network, and rely on the backbone whileconstructing multicast route when a new session starts

time-MCEDAR [2] uses this approach for ad hoc multicast This approach is alsoused in unicast ad hoc routing [6] [7]

Approach 3: Reliance on No Nodes Since all nodes are mobile, the multicast

routes would need maintenance as time goes by If session states are stored inpacket headers, the protocol does not have to rely on any specific nodes to form

a forwarding path because we do not even need one! Session states carried inpacket header may be a list of node IDs, or a series of location coordinates In

a protocol using this approach, intermediate nodes check the packet header anddecide where or who to forward the packet

Examples for this approaches include location guided small group nication [8] and DDM [9]

commu-Approach 4: Reliance on Stabler Nodes This approach attempts to takeadvantage of node mobility and network architecture If nodes in a networkhave different degrees of mobility, for example, fast and slow, we can rely on theslow (thus stabler) nodes in order to build the multicast route Note that “fast”and “slow” could be in the relative sense For example, a group of nodes maymove fast together toward a common direction, but the relative speed amonggroup member is “slow”

An example of this approach is M-LANMAR [10], which is a multicastprotocol exploiting team-based mobility

Approach 5: Reliance on an Overlay Layer Since all nodes are mobile,adapting to network dynamics is an extra burden for multicasting protocols Byinserting a middle layer in between, we can hide dynamics in lower layer andlet multicast protocols concentrate only on multicasting In this approach, theprotocols normally build an overlay mesh on top of the physical network, andthe multicasting route is built on top of this overlay mesh Without knowingthe underlying dynamics, it is easier for the multicast protocol to focus onimplementing multicast functionalities

Protocols using this approach includes AMRoute [11] and PAST-DM [12],both of which construct a virtual mesh structure on top of the physical network.The virtual mesh relies on some unicast routing protocols to provide tunnelingroute between any two nodes on mesh Data forwarding tree is extracted on top

of the virtual mesh, and is unaware of underlying topology changes

Several popular multicasting protocols are classified according to our cussion and are summarized in Table 4.1

dis-4.3 Multicasting Protocols

In the previous sections, we reviewed the special properties of mobile adhoc networks, and examined how these properties affect the design and imple-mentation of network protocols To deliver packets effectively to the multicastgroup members, any multicasting protocol should address these properties In

this section, we present several multicasting protocols proposed specifically forthe mobile ad hoc networks.

4.3.1 Multicast operations of AODV (MAODV)

As the multicast protocol associated with AODV [13], MAODV [14] usesthe conventional tree-based approach for multicast routing Besides the routingtable, each node maintains a Multicast Route Table (MRT) to support multicastrouting A node adds new entries into the MRT after it is included in the routefor a multicast group Each entry records the multicast group IP address, groupleader IP address, group sequence number and next_hops (neighbors on themulticast tree)

Each multicast group also needs its own sequence number in order to indicatethe freshness of a multicast route, which is maintained by the group leader.When a node wishes to join a multicast group and it does not know who isthe leader, it broadcasts a RREQ packet with destination field set as the group

ID address If it does not receive a RREP before timing out, it will retry forcertain number of times Subsequent unsuccessful attempts would mean thatthere are no other members of the group within its connected portion of thenetwork In such cases, it assumes the group leadership It initializes thegroup sequence number to one, and broadcasts a Group Hello packet across thenetwork periodically with step-wise incremented sequence number

Every node keeps record of who is the leader of which group by cuously listening to RREPs Thus, if it want to join a group, it may have theaddress of the leader If it also has a route to the leader in its routing table, it canunicast the join RREQ to the leader directly Otherwise, it will broadcast thejoin RREQ packet If a member node loses its route to the group, it broadcasts

promis-a normpromis-al RREQ when it wpromis-ant to send dpromis-atpromis-a to the group

If a node receives a join RREQ, it can reply if it is a router on the group’smulticast tree and it holds a group sequence number that is high enough, whilethe group leader always can reply join RREQ RREP is unicasted, and the

responding node updates its MRT accordingly RREP contains the last knowngroup sequence number, address of group leader, and a special field calledMgroup_Hop This field is initialized to zero When a node on the path to thesource node receives the RREP, it increases its Mgroup_Hop field, and updates

to its multicast route table When the source node receives the RREP, it candetermine the hop distance to the nearest router on the group’s tree, and a newbranch of the tree is also built at the same time Moreover, the whole multicasttree is gradually built up while branches are added one by one When a node onthe tree receives a packet targeting its group address, it will multicast the packet

to all its neighbors on the tree To ensure loop-free property, it is necessary

to make sure only one router on the tree responds the join RREQ If multipleresponses do arrive, the source node should accept only one All the otherresponses will be ignored and finally invalidated by expiration timers

Figure 4.2. Multicast join operation of MAODV.

When a member decide to leave its group, and if it is not a leaf node in themulticast tree, it must continue to serve as a router If it is a leaf node, it willhave only one immediate neighbor The node unicast a leave message to thatneighbor and clears all information about the group in its tables The neighbor,upon receiving the message will update its neighbor list as well If it is not

a member and it becomes a leaf node after the pruning, it will start its ownpruning by doing the same So the pruning stops when either a group member

or a non-leaf node is reached

Multicast tree links may break due to node mobility or timer expiration, andthis will be detected by both end nodes of the link But only the downstreamnode will be responsible for the repair To repair, it broadcasts a join RREQ withdestination address set as group leader and Mgroup_Hop field set to its distancefrom the leader The last known group sequence number is also included Torestrict the effects, the TTL field of the RREQ is set to a small value If noreply is received before the time out period, the retrials will be network widebroadcasts The nodes that can respond to this RREQ are those that are at least

as close to the group leader as indicated by the packet This prevents thosenodes on the same side of the broken link from responding Finally, whenRREPs are unicasted to the initiating node, the procedure is the same as thejoining of a new node.

If no RREP is received, it is assumed that the network has been partitionedand the tree cannot be reconnected The partition of the tree that is downstream

of the broken link can select a new leader It must be a group member, andthe new leader will distribute new round of group sequence numbers to itsmembers Later on, the partitions of network may become connected Then,the two leaders will know each other since they are both broadcasting grouphello messages, and will negotiate and combine there partitions and one leaderwill stop its role

4.3.2 Reliance on More Nodes

Node mobility poses a great challenge to multicast routing It is mandatorythat a tree-based routing protocol should continuously update itself to accom-modate the changing network topology When a tree link breaks, a branch of themulticast tree becomes disconnected The routing protocol needs to reconnectthe partitioned branches swiftly In a highly mobile network, the robustnessand efficiency would be an important issue If we allow path redundancy inthe routing structure, i.e., allow the presence of multiple paths between certainnode pairs, we change the tree structure into a mesh structure Thus, the routingstructure does not need to react to every link breakage, which is a nice featureespecially in the mobile ad hoc network settings However, the path redundancywill reduce the data forwarding efficiency, and there could be loop formations.Thus, a mesh-based routing protocol needs a very careful design,

4.3.2.1 Core-Assisted Mesh Protocol (CAMP). CAMP [3] is designed

to support multicast routing in very dynamic ad hoc networks using a sharedmesh structure It ensures that the shortest paths from all receivers to the sources(called reverse shortest paths) are included in the group’s mesh Figure 4.3illustrates how data packets are forwarded from router to the rest of the groupmembers in CAMP and in a shared-tree multicast protocol To prevent packetreplication or looping in the mesh, each node maintains a cache to keep track

of recently forwarded packets Periodically, a receiver node reviews its packetcache in order to determine whether it is receiving data packets from thoseneighbors which are not on the reverse shortest path to the source Whenever

such situation arises, a heartbeat message is sent to successor in its reverse shortest path to the source That heartbeat message triggers a push join message

when the successor is not a mesh member This procedure ensures all the nodesalong any reverse shortest path are included in the mesh

Figure 4.3 Traffic flow from h (a) In a CAMP mesh (b) In the equivalent shared tree.

CAMP uses core node for limiting the control traffic needed for creation ofmulticast meshes Unlike CBT, it does not require that all traffic should flowthrough the core nodes If a node wishing to join a multicast group finds that

it has neighbors which are duplex members of the group, it simply updates itsmulticast routing table (MRT) and announces its membership to the neighborsusing a standard multicast routing update procedure When none of its neigh-bors are mesh members, it either sends a join request toward a core or attempts

to reach a group member by the expanding ring search Any duplex member ofthe mesh can respond a join request with a join ACK, which is propagated back

to the originator of the request The normal mesh members are called duplexnodes Besides, CAMP allows a node to join the mesh in a simplex mode whencreating one-way connections between sender-only nodes and the rest of themulticast mesh

4.3.2.2 On-Demand Multicast Routing Protocol (ODMRP) ODMRP

[4] [15] extends the concept of mesh with the forwarding group concept The

forwarding group is a set of nodes responsible for forwarding multicast data onshortest paths between any member pairs, as is shown in Figure 4.4

Figure 4.4 The forwarding group concept.

In ODMRP, group membership and multicast mesh are established and

up-dated by each source on demand By flooding a JOIN Query, a source node

starts building a forwarding mesh for the multicast group, and collect bership information at the same time When a node receives a non-duplicateJOIN Query, it stores the upstream node ID and rebroadcasts the packet Whenthe JOIN REQUEST packet reaches a multicast receiver, the receiver creates

mem-or updates the source entry in its Member Table A JOIN Reply packet is then

prepared and broadcasted by the receiver node The packet is relayed backtowards the source along the reverse path traversed by the JOIN Query packet.This process constructs (or updates) the routes from sources to receivers and

builds a mesh of nodes, the forwarding group Multicast sources refresh the

membership information and update the routes by sending JOIN Query ically

period-Figure 4.5 Format of JOIN Query packet.

Figure 4.5 shows the format of a JOIN Query packet When a multicastsource has data packets to send but no route is known, it originates a “JoinQuery” packet The source set Type field to 01 (which means a Join Querypacket) Hop Count is initially set to zero The TIME_TO_LIVE value forthe packet should be adjusted based on network size and network diameter.The Sequence Number must be large enough to prevent wraparound ambiguity.When a node receives a Join Query packet, the following process is adopted.1

2

3

Check if it is a duplicate by comparing the (Source IP Address, SequenceNumber) combination with the entries in the message cache If a dupli-cate, then discard the packet DONE

If it is not a duplicate, insert an entry into the message cache with theinformation of the received packet (i.e., sequence number and source

IP address) and insert/update the entry for routing table (i.e., backwardlearning)

If the node is a member of the multicast group, it originates a Join Replypacket with the RET value enclosed

5

6

Increase the Hop Count field by 1 and decrease the TTL field by 1

If the TTL field value is less than or equal to 0, then discard the packet.DONE

If the TTL field value is greater than 0, then set the node’s IP Addressinto Last Hop IP Address field and broadcast DONE

Figure 4.6 Format of JOIN Reply packet.

A multicast receiver transmits a “Join Reply” packet after selecting the ticast route Each sender IP address and next hop IP address of a multicastgroup are contained in the Join Reply packet Figure 4.6 shows the format of aJOIN Reply packet

mul-When a Join Reply is received:

If one or more entries coincide with the node’s IP Address, set theFG_FLAG and build its own Join Reply The next hop IP address can beobtained from the routing table

Broadcast the Join Reply packet to the neighbor nodes DONE

One salient feature of ODMRP is the soft state approach in maintaining

mul-ticast group members For each member, the group membership is periodicallyrenewed by the rounds of request/reply procedure Once a member wants toleave a group, no additional signaling is needed It simply just stops respond-ing to the Join Query packets This feature is very suitable for the mobile ad

hoc network environment, in which join/leave operations may happen morefrequently, and the cost of group maintenance is very high.

4.3.3 Reliance on Backbone Structure

Backbone-based multicast uses a hierarchical routing technique The ticast routing is divided into two levels: the global multicast routing withinthe virtual backbone, and the local multicast from each backbone node to itsdominated receiver nodes

mul-For a backbone-based approach, a distributed election process is conductedamong all nodes in the network, so that a subset of nodes are selected as corenodes The topology induced by the core nodes and paths connecting them formthe virtual backbone, which can be shared by both unicast and multicast routing

In MCEDAR [2], a distributed minimum dominating set (MDS) algorithm is

applied for this purpose, and the resulting backbone has the property that allnodes are within one hop away from a core node A core node and its dominatednode set form a cluster The protocol proposed in [16] uses a more complexselection process It relaxes the dominating set property by allowing each

backbone node to be a root of a local group involving all nearby nodes It is

assumed in [17] that the “slow node” population is dense enough to form aconnected spanning topology of the whole network area Thus, the backbone

is built upon the “slow nodes”

Once a virtual backbone is formed, the multicast operation is divided intotwo levels The lower level multicast, which is within a cluster, is trivial For theupper level multicast, the protocol in [16] uses a pure flooding approach within

the backbone MCEDAR builds a routing mesh, named as mgraph, within the

virtual backbone, to connect all core nodes

4.3.3.1 Multicast Core-Extraction Distributed Ad hoc Routing

(MCEDAR) The protocol bases its core-extraction criteria on the nating set concept for the network topology, namely, a node is either a core or

domi-an immediate neighbor of a core Besides the adopted virtual backbone dures, the protocol itself has four key components: (1)the mesh-based multicaststructure, (2) the join protocol, (3) the core broadcast based forwarding protocol,and (4) the leave pruning and reconstruction protocols

proce-MCEDAR uses a mesh structure called the mgraph as the multicast routing structure Only the core nodes can become members of an mgraph Thus,

the number of nodes involved in a multicast routing structure is significantly

reduced Each member of an mgraph maintains a notion of which of its nearby core nodes are members of the same mgraph This information is used in data forwarding Each mgraph is also associated with a robustness factor R.

When a node wants to join a group, it requires its dominating core to join

the appropriate mgraph, and the dominator then performs the join operation In

order to prevent loop formations during mgraph reconstructions, each member also maintains a notion of local ordering among each other Thus, each mgraph

member is assigned a value named as JoinID, which has an initial value as

infinity, and is updated during the course of mgraph construction.

The new joining core broadcasts a join request JOIN(joinID) The joinID for a fresh joining core is set as infinity The join request is relayed further by

the non-member nodes in accordance to the core broadcast procedure When

a group member receives a join request, it sends back a JOIN-ACK(joinID) if

its joinID is less than the joinID field of the arriving join request When anintermediate core on the reverse path receives a JOIN-ACK, it relays the packet

only when its number of neighbors in the mgraph does not exceed the robustness

factor, R Before relaying the JOIN-ACK, the intermediate core updates its ownjoinID if the relayed JOIN-ACK has lower joinID value, otherwise, it updatesthe joinID field of the JOIN-ACK packet Figure 4.7 shows an example of the

join procedure The left-hand side shows how the join request is relayed up to

the nodes in the core graph The right-hand side shows the reverse paths forJOIN-ACKs and the update of joinIDs at each relaying nodes

Figure 4.7 MCEDAR join procedure.

The forwarding protocol of MCEDAR follows the core broadcast procedure

When a data packet arrives at an mgraph member, the member attempts to forward the packet only to those nearby cores on the same mgraph MCEDAR

introduces a core broadcast procedure, which is used for a core node to flood

a message to all the other core nodes in the network The procedure is moreefficient than the normal hop-by-hop flooding The core broadcast procedureimplicitly creates a source based tree that represents the fastest delivery structurefor each source of the group

In the stateless multicast protocols, the forwarding states are included in

packet header, and no protocol state is maintained at any nodes except forthe source node From the information included in the packet headers, anyintermediate node knows how to forward or duplicate the packet Althoughpacking routing information together with data traffic will enlarge data packetsize, it reduces the total number of control packets generated by the protocol.Besides, when the group is idle, there is no control overhead

4.3.4.1 Differential Destination Multicast (DDM) DDM [9] is tended for small group multicast It not only adopts the stateless approach, but

in-may also operate in a soft state mode In this mode, intermediate nodes cache

the forwarding states read from the packet header The protocol no longerneeds to list all destinations in every data packet header When changes occur,

an upstream node only needs to inform its downstream neighbors regarding thedifference in destination forwarding since the last packet

In DDM, the multicast data packets contain a payload and a DDM header,which is composed of a list of DDM blocks Each DDM block is constructed

for a particular downstream neighbor Each DDM block contains the intended receiver, the DDM block type, the block sequence number and some other fields

depending on the type There are three types of the DDM blocks: Empty (E)blocks, Refresh (R) blocks and Difference (D) blocks Except for the E block,both R block and D block have a destination list L When used in broadcast medianetworks, DDM blocks for different downstream neighbors may be aggregatedtogether into the header of one data packet When the intended neighbors

1Since a mgraph is a mesh structure, each member can have multiple parents The hierarchy is derived from

the JoinID field of each node.

A member of the mgraph issues a leave message only when the following

two conditions hold (1) It does not have any local members in its domain, and(2) its child list is empty, A leaving member needs to issue the message to allits parents.1 A parent that receives the leave message from one of its childrendeletes the corresponding child’s ID from its child list

In some cases, an mgraph member can issue a reconstruction request to the

other members In order to prevent loop formations during this process, theJoinID field at each node is used in the following manner A member issues areconstruction request only when it looses connectivity with all its neighboring

mgraph members who has smaller join times, i.e., JoinID values A member

responds to a reconstruction request only if its join time is less than the jointime of the originator of the request

4.3.4 Stateless Multicasting

Overlay multicast [18] [19] [20] has been proposed as an alternative approachfor providing multicast services in the Internet A virtual infrastructure can bebuilt to form an overlay network on top of the physical Internet Each link

in the virtual infrastructure is a unicast tunnel in the physical network The

IP layer provides a best-effort unicast datagram service, while the overlay work implements all the multicast functionalities such as dynamic membershipmaintenance, packet duplication and multicast routing AMRoute [11] is an adhoc multicasting protocol that uses the overlay multicast approach Bidirec-tional unicast tunnels are used to connect the multicast group members into avirtual mesh After the mesh creation phase, a shared tree is created for datadelivery, and is maintained within the mesh One member node is designated

net-as the logical core, which is responsible for initiating the tree creation processperiodically Figure 4.8 illustrates the concept of virtual mesh and the sharedtree built by the AMRoute protocol within the mesh

When the overlay multicasting technique is applied to the MANETs, themanner in which the overlay layer interacts with the physical network is quitedifferent from that of overlay multicasting in the Internet In MANETs, eachnode acts as a router as well as an end host In most cases, we can assume the

receive the data packet, each neighbor can locate the correct DDM block andthe destination list for itself

Each node maintains one Forwarding Set (FS) for each active multicast sion It records to which destinations this node needs to forward multicast data.When a node receives a DDM data packet from an upstream neighbor, it firstlocates the DDM block intended for itself, and check its block sequence number

ses-to see if it a duplicate one just seen before The receiver then updates its FSaccording to the DDM block type For an R block, the subset of destinations

in FS which are cached from previous received DDM block from the sameupstream node are totally replaced by the list in the newest DDM block For

a D block, that subset is incremented or decremented by the list in the newestDDM block For an E block, that subset is removed from the FS When the

FS is updated, the destinations in the FS may be reached via different paths.Therefore, the FS is further partitioned into subsets according to the next hops.Thus, a new DDM header, containing new DDM blocks, is prepared for thenext transmission of the data packet

DDM follows the 1-to-n communication model The source acts as an mission controller for the information it sends New members join the group

ad-by unicasting a JOIN REQUEST to the source DDM relies on the unicastprotocol to quickly provide the next hop for any destination, which may be ahard request for the on-demand type unicast protocols

4.3.5 Overlay Multicasting