ip multicast revisited : algorithms
TRANSCRIPT
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)
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
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)
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
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
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)
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
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
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
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
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
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)
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
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
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
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
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
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