ip multicast revisited : algorithms

18
1 Multicast Protocols for Ad hoc Networks Chien-Chung Shen UDel CISC 861 IP Multicast Revisited : Algorithms Multicast routing problem “To find a tree of links that connects all the group members” Two approaches Group-shared tree one tree per group Source-based tree one tree per group sender F A B E C D G Group-shared F A B E C D G Source-based (G) F A B E C D G Source-based (A)

Upload: others

Post on 02-Jan-2022

12 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: IP Multicast Revisited : Algorithms

1

Multicast Protocols for Ad hoc Networks

Chien-Chung ShenUDel CISC 861

IP Multicast Revisited : AlgorithmsMulticast routing problem“To find a tree of links that connects all the group

members”

Two approachesGroup-shared tree → one tree per groupSource-based tree → one tree per group sender

F

A

B

E

C

D

G

Group-shared

F

A

B

E

C

D

G

Source-based (G)

F

A

B

E

C

D

G

Source-based (A)

Page 2: IP Multicast Revisited : Algorithms

2

JOIN

IP Multicast Revisited : AlgorithmsCore-based tree

Approach to the group-shared treeA node willing to join a group sends a unicast JOIN message toward the core

Pro: control messages sent directly toward the coreCon: bottleneck

JOIN JOIN

F

A

B

E

C

D

GGF

A

Multicasting for MANETs Traditional IP multicast protocols are not suitable

Forwarding information outdated very oftenTrade-offs

dynamic topology,limited resources,

etc.

dynamic topology,limited resources,

etc.

TreeTree

MeshMesh

ProactiveProactive

ReactiveReactive

bandwidth Latency Effective-ness

Efficiency

Page 3: IP Multicast Revisited : Algorithms

3

Proactive Vs. Reactive RoutingTable-driven

Routes (trees) are proactively computedToo much routing information being exchanged and maintained

On-demandRoutes (trees) are not computed until there are data to be sentLikely to cause a global flooding during a route discovery process

Efficiency Vs. RobustnessTree-based

Most efficient, least robust

Mesh-basedLess efficient, more robustSpecial case: flooding

F

A

B

E

C

D

G F

A

B

E

C

D

G F

A

B

E

C

D

G

Tree Mesh Full Mesh(Flooding)

Page 4: IP Multicast Revisited : Algorithms

4

MANET Multicast Protocol : ODMRPOn-Demand Multicast Routing Protocol(Lee, Su, Gerla – UCLA)Source floods JOIN-DATA to find members on-demandMembers propagate JOIN-TABLE back to the source, resulting in mesh creation

ODMRP : Example

Forwarding group is periodically refreshedGPS can be used to predict refresh intervalProblem: excessive overhead due to global flooding of JOIN-DATA messages

F

A

B

E

C

D

G

H

I

Sender NextHop

H C

Sender NextHop

H D

Sender NextHop

H H

E

C

D

Page 5: IP Multicast Revisited : Algorithms

5

MANET Multicast Protocol : CAMPCore-Assisted Mesh Protocol(Garcia-Luna-Aceves & Madruga – UCSC)Cores are used to avoid flooding of control messages (as in CBT)

Problem:Core nodes are pre-selectedthe protocol has to rely on a unicast routing protocol

MANET Multicast Protocol : MCEDARMulticast extension to Core Extraction Dynamic Ad hoc Routing(Sinha,Sivakumar,Bharghavan – UIUC)Based on CEDAR routing protocol, which creates a dominating set for relaying routing informationNot every node participating in route discovery

ProblemDominating set connectivity is hard to maintain in highly dynamic environments

Page 6: IP Multicast Revisited : Algorithms

6

MANET Multicast Protocol : MZRMulticast based on Zone Routing Protocol(Devarapalli & Sidhu)A node defines a zone surrounding itself and processes only forwarding info. within the zoneA source-based tree is proactively created in the zoneThe tree is reactively extended across different zones by border nodes only

ProblemZone radius is pre-configured and fixed, regardless of mobility speed

Other MANET Multicast ProtocolsTree-based

RBM (Corson et al. 95), LAM (Ji & Corson 98), AMRoute(Bommaiah et al. 98), AMRIS (Wu et al. 98), Reliable-mcast(Gupta et al. 99), ODVR-based (Royer & Perkins 99), ABAM(Toh et al. 00), MZR (Devarapalli & Sidhu 01)

Mesh-basedMCEDAR (Sinha et al. 99), CGM (Lin & Chao 99), ODMRP & FGMP (Lee et al. 00), NSMP (Lee & Kim 00), CAMP (Madruga et al. 00), Bandwidth efficient (Ozaki et al. 01)

Flooding/OthersLBM (Ko et al. 99), Flooding Reliable mcast (Ho et al. 99), Role-based (Briesemeister et al. 00), CBM (Zhou et al. 00)

Page 7: IP Multicast Revisited : Algorithms

7

Multicast Methodologies

LAM (Ji & Corson 98)MAODV (Royer & Perkins 99)AMRIS (Wu et al. 98)AMRoute (Bommaiah et al. 98)

Group-shared

ABAM (Toh et al. 00)

Source-based

Tree-basedtechniques

ODMRP (Lee et al. 00)FGMPCAMP (Madruga et al. 00)NSMP (Lee & Kim 00)

Mesh protocols

Flooding (Ho et al. 99)

Mesh-basedtechniques

CGM (Lin & Chao 99)MCEDAR (Sinha et al. 99)

Cluster-based

MZR (Devarapalli & Sidhu 01)

Zone-based

Hybrid/Hierarchicaltechniques

Multicast Techniques

Other ClassificationsProactive vs. ReactiveProactive tree or mesh is maintained at all timeReactive tree or mesh only created or updated

when source has data to be sent

Unicast dependent vs. IndependentNot practical for ad hoc networks

Reactive routing no complete routing tableRoutes changing often high maintenance cost

Page 8: IP Multicast Revisited : Algorithms

8

Adaptive Multicasting : MotivationBehaves like a tree-based protocol in static areas, and like flooding in very dynamic areas

Static Highly Dynamic

Tree-based connection Mesh-based connection

Adaptive Dynamic Backbone ProtocolSelecting a subset of nodes (backbone) for processing control/data messages, as in MCEDARProactively maintaining forwarding information within each local group, as in MZRCoverage of each backbone node (or core) is adaptive to mobility condition of that area

Static/low mobility → large coverageHigh mobility → small coverage

CoreLocalgroup

Page 9: IP Multicast Revisited : Algorithms

9

Justification : Proactive or ReactiveEach node decides whether it should process and relay information of another node by evaluating the stability of the path

In a static environment, number of hops is enough for indicating stabilityNeed something more in dynamic cases

CBA

Tell others I’m here

Tell others A is there, but he’s running away

Huh?Better not!

LINK UP

LINK DOWN

LINK DOWN

Estimation of Node InstabilityNo GPS is assumedEach node keeps track of its link failure frequency per neighbor (NLFF)

0.5)(default 10 , )1(

neighbors) of (#_detect) failureslink of (#

≤<⋅−+⋅=

×=

ααα nlffnlffnlff

WINDOWTIMEnlff

curr

curr

Page 10: IP Multicast Revisited : Algorithms

10

Instability of PathsIndicating instability of path between a pair of nodesTwo components

Number of hopsAccumulated NLFF

Path stability constraint:Number of hops < HOP-THRESHOLDAccumulated NLFF < NLFF-THRESHOLD

A B

∑∈

=pathi

iacc nlffnlff

ADB : Neighbor Discover ProcessObjective → collect immediate neighborhood information

Nodes periodically broadcast hello or beaconmessages

Each node maintains neighbor table upon receiving a hello messagePeriodically, stale entries are flushed and local NLFF is computed at each node

Accumulated NLFF to core#Hops to coreCore IDNode ID

Page 11: IP Multicast Revisited : Algorithms

11

ADB : Core Selection ProcessObjective → choose appropriate core nodes and establish parent-child relationship

Everyone starts as a coreEach node calculates its own height and heights of all neighbors

The node with the highest height is picked as a parentA node with no parent stay as a coreHello messages are monitored to maintain path stability constraint (hops & accumulated NLFF)

⟩⟨= − idNLFFheight , 1

ADB : Core Forwarding ProcessObjective → compute paths to nearby cores

Upon hearing a hello message from another core, report to the parentEach node maintains a core forwarding table with entries <coreId, nextHop, hopCount>

C1 C2

Hello

HelloA

B

C

A

Next hop

4C2

#HopsCore ID

C

Next hop

3C2

#HopsCore ID

Page 12: IP Multicast Revisited : Algorithms

12

Snapshots From Simulation

Mobility speed 0 m/s Mobility speed 30 m/s

Multicast Operation Over ADBTwo-tier architecture

Local operationProactiveJOIN-REQUEST explicitly sent toward the core (as in CBT)Membership info periodically refreshed(to handle mobility)

Backbone operationReactiveMesh/flooding

Backbone

B

A

D

C(2)

(1)

Page 13: IP Multicast Revisited : Algorithms

13

Performance EvaluationSimulation environment

50 nodes uniformly distributed over 1000x1000 m2 terrain2 Mbit/s wireless channel, free-space propagation with approximate transmission range of 250 m802.11 as the MAC layer protocol25 multicast group members randomly selectedSenders generating CBR traffic at 2 pkts/sec (data size 512 bytes)

Performance metrics:Delivery ratio under different mobility speeds and numbers of senders → effectivenessNumber of pkts transmitted per pkt received→ efficiency

Result : Effectiveness

Page 14: IP Multicast Revisited : Algorithms

14

Result : Efficiency

Problems and IssuesTraffic concentration over the backbone

Backbone nodes become hot spots in the network

Unreliability of 802.11’s broadcast mechanismNo CTS/RTS handshake to guarantee data delivery

Page 15: IP Multicast Revisited : Algorithms

15

Conclusion and Future WorkAn adaptive multicast protocol for ad hoc networks is introduced to provide both efficiency under low mobility and robustness under high mobilityFuture plan:

Adapt source-based trees to distribute loadDivert data traffic from the backbone, e.g. using backbone nodes for coordination only, not for forwardinging data

Destination region

Location-Based MulticastSender specifies the receiver group by a geographical region

No explicit join of a receiver

Geographical information is incorporated into multicast packets

I have data for group A

I have data for region (0,0)-(5,3)

Geocast

Page 16: IP Multicast Revisited : Algorithms

16

Content-Based MulticastNo explicit destination is specified by the sender

Senders advertise their informationReceivers subscribe their interests

I have information about tanks

I am interested in (tanks ∨ helicopters)

I am interested in tanks

Brief Comparison

Expression of interest

Geographical region

Group identity(e.g., class-D IP addresses)

Unique identity(e.g., IP addresses,

MAC addresses)

Representation of destination

ImplicitexplicitexplicitexplicitDestination specified by a source

Content-based multicast

Location-based multicastMulticastUnicast

Page 17: IP Multicast Revisited : Algorithms

17

Support for Directional AntennasDirectional antennas

Reducing chance of collisionReducing interference

Directional antenna model (Nasipuri et al):Each node is equipped with N directional antennasEach antenna covers 360°/NAntenna patterns are fixed with respect to the terrain, regardless of node’s orientation

Multicast with Directional AntennasProblem Definition

Although a variety of MAC protocols using directional antennas have been proposed, broadcast mode (omni-directional) is still being used when forwarding multicast data

member

sourcesource

member

member

With directional information from the network layer, expected group of receivers can be reached directionally

Exposed terminal problem is mitigated

Page 18: IP Multicast Revisited : Algorithms

18

Multicast with Directional AntennasWe have investigated the benefits and impacts of using directional antennas for multicast communicationsSwitched-beam antenna model with k-out-of-M selection is assumed

HELLO messages are periodically broadcast to allow nodes to keep track of their neighbors’ directions

member

source member

Radiation patternof Sector 0

Radiation patternof Sector 1

Radiation patternof Sector M-1