group leader

advertisement
CMPE 257: Wireless and Mobile
Networking
Spring 2002
Week 5
CMPE 257 Spring 2002
1
Multicast Communication in Ad Hoc Networks

Group Communications



Conference Scenario
Rescue/Disaster Scenario
Battlefield Scenario …
CMPE 257 Spring 2002
2
Multicast routing classification
Routing Protocols
Table Driven - Proactive
AMRoute
On Demand -Reactive
CAMP/WRP
M-AODV
CMPE 257 Spring 2002
AMRIS
ODMRP
3
Overview






AMRoute
AMRIS
ODMRP
M-AODV
CAMP
Flooding and Variations
CMPE 257 Spring 2002
4
Multicasting

A multicast group is defined with a unique group
identifier



Nodes may join or leave the multicast group anytime
In traditional networks, the physical network
topology does not change often
In MANET, the physical topology can change often
CMPE 257 Spring 2002
5
Multicasting in MANET


Need to take topology change into account when
designing a multicast protocol
Several new protocols have been proposed for
multicasting in MANET
CMPE 257 Spring 2002
6
On-Demand Multicast Routing Protocol
(ODMRP)

ODMRP requires cooperation of nodes wishing to
send data to the multicast group


To construct the multicast mesh
A sender node wishing to send multicast packets
periodically floods a Join Data packet throughout the
network

Periodic transmissions are used to update the routes
CMPE 257 Spring 2002
7
On-Demand Multicast Routing Protocol
(ODMRP)

Each multicast group member on receiving a Join
Data, broadcasts a Join Table to all its neighbors




Join Table contains (sender S, next node N) pairs
next node N denotes the next node on the path from the
group member to the multicast sender S
When node N receives the above broadcast, N
becomes member of the forwarding group
When node N becomes a forwarding group member,
it transmits Join Table containing the entry (S,M)
where M is the next hop towards node S
CMPE 257 Spring 2002
8
On-Demand Multicast Routing Protocol
(ODMRP)

Assume that S is a sender node
S
N
M
A
D
C
B
Join Data
T
Multicast group member
CMPE 257 Spring 2002
9
On-Demand Multicast Routing Protocol
(ODMRP)
N
S
A
M
Join Data
Join Data
Join Data
T
D
C
B
Multicast group member
CMPE 257 Spring 2002
10
On-Demand Multicast Routing Protocol
(ODMRP)
S
N
M
A
Join Table (S,M)
T
D
C
B
Join Table (S,C)
Multicast group member
CMPE 257 Spring 2002
11
On-Demand Multicast Routing Protocol
(ODMRP)
Join Table (S,N)
S
T
F
N
M
A
D
F
C
B
Join Table (S,N)
F
marks a forwarding group member
CMPE 257 Spring 2002
12
On-Demand Multicast Routing Protocol
(ODMRP)
Join Table (S,S)
N
S
F
M
A
F
C
B
F
T
D
Multicast group member
CMPE 257 Spring 2002
13
On-Demand Multicast Routing Protocol
(ODMRP)
F
S
N
M
A
F
C
B
F
T
D
Join Data (T)
Multicast group member
CMPE 257 Spring 2002
14
On-Demand Multicast Routing Protocol
(ODMRP)
F
S
N
M
A
F
Join Table (T,C)
F
F
C
B
T
D
Join Table (T,T) Join Table (T,D) Join Table (T,C)
Multicast group member
CMPE 257 Spring 2002
15
ODMRP Multicast Delivery



A sender broadcasts data packets to all its neighbors
Members of the forwarding group forward the
packets
Using ODMRP, multiple routes from a sender to a
multicast receiver may exist due to the mesh
structure created by the forwarding group members
CMPE 257 Spring 2002
16
ODMRP





No explicit join or leave procedure
A sender wishing to stop multicasting data simply stops
sending Join Data messages
A multicast group member wishing to leave the group stops
sending Join Table messages
A forwarding node ceases its forwarding status unless
refreshed by receipt of a Join Table message
Link failure/repair taken into account when updating routes in
response to periodic Join Data floods from the senders
CMPE 257 Spring 2002
17
AODV Multicasting [Royer00Mobicom]


Each multicast group has a group leader
Group leader is responsible for maintaining group
sequence number (which is used to ensure freshness
of routing information)



Similar to sequence numbers for AODV unicast
First node joining a group becomes group leader
A node on becoming a group leader, broadcasts a
Group Hello message
CMPE 257 Spring 2002
18
AODV Group Sequence Number


In our illustrations, we will ignore the group
sequence numbers
However, note that a node makes use of information
received only with recent enough sequence number
CMPE 257 Spring 2002
19
AODV Multicast Tree
Multicast tree links
Group leader
E
L
C
J
G
H
D
K
A
B
Group and multicast tree member
N
Tree (but not group) member
CMPE 257 Spring 2002
20
Joining the Multicast Tree: AODV
Group leader
E
L
C
J
G
H
D
K
A
B
N
N wishes to
join the group:
it floods RREQ
Route Request (RREQ)
CMPE 257 Spring 2002
21
Joining the Multicast Tree: AODV
Group leader
E
L
C
J
G
H
D
K
A
B
N
N wishes to
join the group
Route Reply (RREP)
CMPE 257 Spring 2002
22
Joining the Multicast Tree: AODV
Group leader
E
L
C
J
G
H
D
K
A
B
N
N wishes to
join the group
Multicast Activation (MACT)
CMPE 257 Spring 2002
23
Joining the Multicast Tree: AODV
Multicast tree links
Group leader
E
L
C
J
G
H
D
K
A
B
N
Group member
N has joined
the group
Tree (but not group) member
CMPE 257 Spring 2002
24
Sending Data on the Multicast Tree


Data is delivered along the tree edges maintained by
the Multicast AODV algorithm
If a node which does not belong to the multicast
group wishes to multicast a packet



It sends a non-join RREQ which is treated similar in many
ways to RREQ for joining the group
As a result, the sender finds a route to a multicast group
member
Once data is delivered to this group member, the data is
delivered to remaining members along multicast tree edges
CMPE 257 Spring 2002
25
Leaving a Multicast Tree: AODV
Multicast tree links
Group leader
E
L
C
J
J wishes to
leave the group
G
H
D
K
A
B
N
CMPE 257 Spring 2002
26
Leaving a Multicast Tree: AODV
Since J is not a leaf
node, it must remain
a tree member
Group leader
E
L
C
J
J has left
the group
G
H
D
K
A
B
N
CMPE 257 Spring 2002
27
Leaving a Multicast Tree: AODV
Group leader
E
L
C
J
G
H
D
K
A
B
MACT (prune)
N
N wishes to leave
the multicast group
CMPE 257 Spring 2002
28
Leaving a Multicast Tree: AODV
Group leader
E
L
C
J
G
H
A
MACT
(prune)
D
K
B
Node N has removed itself from the multicast group.
N
Now node K has become a leaf, and K is not in the group.
So node K removes itself from the tree as well.
CMPE 257 Spring 2002
29
Leaving a Multicast Tree: AODV
Group leader
E
L
C
J
G
H
D
K
A
B
N
Nodes N and K are no more in the multicast tree.
CMPE 257 Spring 2002
30
Handling a Link Failure: AODV Multicasting


When a link (X,Y) on the multicast tree breaks, the node
that is further away from the leader is responsible to
reconstruct the tree, say node X
Node X, which is further downstream, transmits a Route
Request (RREQ)

Only nodes which are closer to the leader than node X’s last
known distance are allowed to send RREP in response to the
RREQ, to prevent nodes that are further downstream from node X
from responding
CMPE 257 Spring 2002
31
Handling Partitions: AODV




When failure of link (X,Y) results in a partition, the downstream
node, say X, initiates Route Request
If a Route Reply is not received in response, then node X
assumes that it is partitioned from the group leader
A new group leader is chosen in the partition containing node X
If node X is a multicast group member, it becomes the group
leader, else a group member downstream from X is chosen as
the group leader
CMPE 257 Spring 2002
32
Merging Partitions: AODV


If the network is partitioned, then each partition has
its own group leader
When two partitions merge, group leader from one of
the two partitions is chosen as the leader for the
merged network

The leader with the larger identifier remains group leader
CMPE 257 Spring 2002
33
Merging Partitions: AODV




Each group leader periodically sends Group Hello
Assume that two partitions exist with nodes P and Q
as group leaders, and let P < Q
Assume that node A is in the same partition as node
P, and that node B is in the same partition as node Q
Assume that a link forms between nodes A and B
P
B
Q
A
CMPE 257 Spring 2002
34
Merging Partitions: AODV


Assume that node A receives Group Hello originated by node Q
through its new neighbor B
Node A asks exclusive permission from its leader P to merge the
two trees using a special Route Request

Node A sends a special Route Request to node Q

Node Q then sends a Group Hello message (with a special flag)

All tree nodes receiving this Group Hello record Q as the leader
CMPE 257 Spring 2002
35
Merging Partitions: AODV
P
A
B
Hello (Q)
Q
CMPE 257 Spring 2002
36
Merging Partitions: AODV
RREQ
(can I repair
partition)
A
B
P
RREP (Yes)
Q
CMPE 257 Spring 2002
37
Merging Partitions: AODV
P
A
B
RREQ (repair)
Q
CMPE 257 Spring 2002
38
Merging Partitions: AODV
P
Group Hello
(update)
A
B
Q
Q becomes leader of the merged multicast tree
New group sequence number is larger than most
recent ones known to P and Q both
CMPE 257 Spring 2002
39
Summary: Multicast AODV


Similar to unicast AODV
Uses leaders to maintain group sequence numbers,
and to help in tree maintenance
CMPE 257 Spring 2002
40
CAMP




Uses Mesh instead of Tree
Assumes the underlying unicast routing protocol can
provide correct distance to known destination within
a finite time
Ensure reverse shortest paths from receivers to
sources are part of a group’s mesh
Strongly depends on the underlying unicast protocol
to work correctly in presence of router failure and
network partition
CMPE 257 Spring 2002
41
Core in CAMP..



Extends the basic receiver-initiated approach
introduced in CBT to create multicast mesh
Core is used to limit the control traffic needed for
receivers to join the group
Cores need not to be part of mesh of their group
CMPE 257 Spring 2002
42
Join the group




Is any of my neighbors a member of group ?
Else send a Join Request towards a Core
Only members of the group can reply with a Join-Ack
Cores are not reachable => expanding ring search
(flooding)
CMPE 257 Spring 2002
43
core
i
j
b
c
g
d
h
k
CMPE 257 Spring 2002
44
core
b
c
g
CMPE 257 Spring 2002
d
h
45
Ad Hoc Multicast Routing Protocol utilizing
Increasing id-number(AMRIS)
CMPE 257 Spring 2002
46
..Overview



Sid initiates a multicast session by broadcasting a NEWSESSION message
All nodes that receive NEW-SESSION generate their own
“multicast session member id” (msm-id) based on the value
found in NEW-SESSION message , then rebroadcast NEWSESSION with its msm-id
NEW-SESSION travels in an expanding ring fashion outwards
from Sid, so nodes closer to Sid will generally have smaller
msm-ids than those further away
CMPE 257 Spring 2002
47
Join the Tree

If the requesting node X has a neighbor who is
already on the tree



send JOIN-REQ to that neighbor Y
neighbor Y will send back JOIN-ACK to confirm now X is its
child
If the neighbors are not on the tree, but have smaller
msm-id

X send JOIN-REQ to one of the neighbor Y
CMPE 257 Spring 2002
48
..Join the Tree




After receiving a JOIN-REQ, neighbor Y sends out its own
JOIN-REQ
If the parent node Y can successfully join the tree, then it
sends a JOIN-ACK to X , otherwise, it will sends a JOINNACK to X
X will send a broadcast JOIN-REQ with limited ttl range, in
turn will trigger all the nodes within that range will send out
their JOIN-REQ
X might possibly receive several JOIN_ACK from its potential
parent . It will choose one of them and sends a JOIN-CONF
to that parent
CMPE 257 Spring 2002
49
AMRoute




Bidirectional shared-tree (1 tree per group)
Create a mesh to establish connectivity before tree
creation
Only group sender and receiver are tree nodes
(replication/forwarding only performed by group
members, and state only in tree node)
No support needed from network nodes who are not
interested/capable of multicast
CMPE 257 Spring 2002
50
..Overview

Uses virtual mesh links to establish the multicast
tree


As long as routes between tree member exist via mesh
links , the tree need not be readjusted when network
topology changes
Suffers from temporary loops and non-optimal
trees
CMPE 257 Spring 2002
51
Protocol
AMRoute
ODMRP
CAMP
AMRIS
TREE
MESH
MESH
TREE
Loop-free
NO
YES
YES
YES
Depends
on Unicast
YES
NO
YES
NO
Periodic
Message
YES
YES
YES
YES
Control
YES
Packet Flood
YES
NO
YES
Configuration
CMPE 257 Spring 2002
52
Simulation Results
CMPE 257 Spring 2002
53
Results Mobility

5 sources, 20 receivers 2pkts/sec
CMPE 257 Spring 2002
54
Results Mobility
CMPE 257 Spring 2002
55
Flooding for Multicast ?

MANETS are very diverse in nature





Different Mobility characteristics
Varying Traffic Load characteristics
Varying Sender / Receiver Populations
Different Network Requirements
No Single Multicast Protocol is optimal in all scenarios

ODMRP



Increased Routing Overhead with increase in number of
senders
Degenerates to flooding as number of senders equals number
of nodes
MAODV

Low Delivery Ratio’s with increased mobility
CMPE 257 Spring 2002
56
Focus

To provide adaptive multicast service where groups
can span different network types.



Requires hosts to dynamically change routing mechanisms
as they move from one network to another
Interoperability among different routing protocols
(Long term !!)
Adaptive Flooding ??


Flooding variations perform better than ODMRP and MAODV
under various scenarios
Flooding variations are easy to interoperate
CMPE 257 Spring 2002
57
Flooding Variations

Scoped Flooding: Reduce redundant transmissions
using a set of heuristics




Nodes transmit HELLO messages with neighbor information
If source node’s neighbor set is a superset then no need to
rebroadcast
Alternately use received power at nodes to decide
retransmission threshold
Hyper Flooding: Re-flood to increase Reliability



Broadcast packets similar to flooding first time
Cache received data packets
In case a node acquires a new neighbor retransmit data
packets in cache
CMPE 257 Spring 2002
58
Switching Criteria

Relative Velocity based Switching







Nodes Send velocity information as part of HELLO messages
Each Node computes its velocity relative to its neighbors
every HELLO_INTERVAL. Only local information is used
If average relative velocity is greater than High_Thresh,
switch to hyper flooding
If average relative velocity is lower than Low_Thresh, switch
to scoped flooding
Else switch to plain flooding
Low threshold = cur_min + ( avg – cur_min)/2
High Threshold = cur_max – ( cur_max – avg) /2
CMPE 257 Spring 2002
59

Network Load based Switching







Use collision as the yardstick for measuring traffic
Each node maintains a count of number of collisions in
current time window
If number of collisions greater than High_Threshold then
switch to scoped flooding
If number of collisions lower than Low_Threshold switch to
hyper flooding
Else switch to plain flooding
Low threshold = cur_min + ( avg – cur_min)/2
High Threshold = cur_max – ( cur_max – avg) /2
CMPE 257 Spring 2002
60
Random Mobility Scenarios

Simulation parameters






1000m x 1000m field
50 Nodes
CBR Traffic 30 pkts/sec
Bouncing Ball Mobility Model
3 different mobility groups consisting of 20, 15, 15 nodes
Velocity 5 - 50 m/s
CMPE 257 Spring 2002
61
Results
CMPE 257 Spring 2002
62
Conference Scenario






Scenario generated using the scenario generator tool
1 speaker node, 20 nodes [audience1] , 20 nodes [audience 2] ,
9 wanderers
1000m x 1000m
CBR 20 pkts/sec
On-Off Traffic On time 3 secs, Off time 3 secs, 5 kbs/sec
Low mobility 2-5 m/sec with pause time of 2secs
CMPE 257 Spring 2002
63
Disaster Scenario





75 Nodes
2000m x 2000m
2 choppers 0-50 m/s
2 teams of foot soldiers 0 -5 m/s
2 teams of vehicles 5-15 m/s
CMPE 257 Spring 2002
64
Disaster Scenario
CMPE 257 Spring 2002
65
Overview of Results



For Conference scenario Adaptive Flooding delivered
15-17% more packets at slightly higher overhead for
ON-OFF traffic
For the Disaster scenario Adaptive Flooding delivered
about 20% more data for both CBR and On-OFF
Traffic at higher routing overhead
Adaptive routing mechanisms not based on flooding
could possibly be used in diverse MANET scenarios
CMPE 257 Spring 2002
66
Interoperability


Nodes belonging to different network types running
different routing protocols should be able to
communicate with each other.
Currently working with ODMRP (mesh based)
MAODV (tree based )

Use some variation of flooding to translate messages

Requires a common routing framework
CMPE 257 Spring 2002
67
Download