On Demand Multicast Routing Protocol - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

On Demand Multicast Routing Protocol

Description:

suffers 'Hidden Terminal' If A timeouts on Passive ACKs, re-transmit ... Even though CAM has more control bytes,, control packets for updates are ... – PowerPoint PPT presentation

Number of Views:1153
Avg rating:3.0/5.0
Slides: 23
Provided by: sameer
Category:

less

Transcript and Presenter's Notes

Title: On Demand Multicast Routing Protocol


1
On Demand Multicast Routing Protocol
  • ECE 802/609
  • Sameer Arora
  • ODMRP in Multihop Wireless Mobile Networks, Lee,
    Su, Gerla, Mobile Networks and Applications, 2002

2
Salient Features
  • Mesh-based
  • On Demand route discovery maintenance
  • Soft state group membership maintenance
  • Does not rely on any underlying unicast protocol

3
Mesh Creation
  • Source initiates by broadcasting JOIN QUERY
  • JOIN QUERY (JQ) has Src ID and Seq
  • Intermediate nodes
  • Cache Src ID Seq from JQ in routing table -
    to detect duplicates
  • Re-broadcast JQ
  • Receiver nodes create broadcast JOIN REPLY (JR)
  • JR has an entry of source and next hop node ID to
    Source (i.e. node forwarding the JQ)
  • Single JR packet may have multiple entries
    corresp. to JQs from multiple intermediate nodes

4
Mesh Creation contd.
  • On receiving JR, an intermediate node
  • Checks if any next hope node ID matches its own
  • If so, concludes its on the path to Source, sets
    flag FG_FLAG
  • This process constructs and updates routes from
    Sources to Receivers and creates a mesh
    Forwarding Group (FG)
  • FG has route redundancy, which avoids
    reconfigurations due to
  • Node displacements
  • Channel fading

5
JOIN REPLY Reliability
  • Reliable JR transmission to source critical for
    establishment and refresh of multicast routes
  • However, standard MAC protocols support reliable
    transmission of unicast (through ACK), not
    broadcast
  • Two approaches
  • Unicast to use MACs reliable transmission
  • Broadcast with passive acknowledgements

6
JR Reliability - Unicast
  • Subdivide JR
  • One sub-table for each distinct next-hop node
  • Unicast JR to each next-hop node
  • Not scalable, but works well for optimum number
    of neighbors (6)
  • Can be used as backup to Broadcast JR

7
JR Reliability - Broadcast
  • When B forwards As packet to C, A can listen
  • A may still miss Passive ACKs
  • if out of Bs propagation range
  • suffers Hidden Terminal
  • If A timeouts on Passive ACKs, re-transmit
  • If re-transmissions remain un-ACKed
  • invalidate route
  • Broadcast looking for next-hop to Src
  • Neighbors with route to Src, unicast JR to
    next-hop, sets FG_FLAG
  • Neighbor without route, broadcasts its ignorance,
    sets FG_FLAG
  • Causes excessive redundancy, but expires on next
    JR propagation

8
ODMRP Working
  • Once forwarding groups and routes are
    established
  • Source can multicast via selected routes and
    forwarding groups
  • A node forwards multicast packets if not
    duplicate and FG_FLAG has not expired
  • Soft state timers
  • Route-refresh timeout interval determines
    frequency of JQ
  • Small interval ? More recent route membership
    info ? congestion
  • Big interval ? Stale route membership info ?
    Unsuitable for highly mobile networks
  • Forwarding Group timeout interval determines
    FG_FLAG expiration
  • High traffic Small interval ? Quickly demote
    unnecessary nodes ? Reduce excessive redundancy
  • High mobility Big interval ? More alternative
    routes available
  • Soft State
  • To leave, Source stops sending JQs
  • To leave, Receiver stops sending JRs ? FG_FLAG
    expires for forwarding nodes lying on receivers
    path to source ? route expires

9
Data structures
  • Route table
  • Created on-demand, maintained by every node
  • Forwarding group table
  • Maintained by forwarding group node
  • Message Cache
  • Maintained by every node to detect duplicates
  • For JQ or data packets
  • Cache empties FIFO/LRU may be employed

10
Mobility Prediction
  • Uses GPS, NTP
  • Based on motion parameters location, speed,
    direction
  • JQ carry motion parameters, MIN_LET (Link
    expiration time).
  • Source sets MIN_LET to MAX_LET_VALUE in initial
    JQ
  • A forwarding node predicts LET between itself
    sender node ? sets MIN_LET to min predicted
    received LET? substitutes its own motion info?
    forwards JQ
  • Receiver predicts LET between itself forwarding
    node ? sets RET (Route Expiration Time) in JR ?
    broadcast JR
  • On receiving multiple JRs, forwarding node
    selects min RET ? broadcasts JR
  • Source sets refresh interval to min RET of all
    JRs ? flood new JQ before min RET expires ?
    Routes preserved in mobility

11
Mobility Prediction
  • Such predicted RET may be
  • Too small due to high mobility ? leads to
    excessive flooding
  • Too large due to low mobility ? long refresh
    interval ? leads to long intervals between JQs ?
    refresh problems
  • Distant non-members have to wait long to receive
    JQ
  • If a node suddenly changes direction/speed, route
    breaks before RET ends ? route would not be
    constructed in time.
  • So, RET is selected between MIN_REFRESH_INTERVAL
    and MAX_REFRESH_INTERVAL
  • Values of these intervals should be adaptive to
    network environments
  • Alternative mobility prediction
  • When GPS may not work properly ( indoor, fading)
  • Based on detected signal strengths of received
    packets

12
Simulation setup
  • GloMoSim
  • 50 mobile nodes, 1000m x 1000m
  • Channel capacity 2 Mbps
  • Average no of neighbors/node 6.82
  • Free space propagation model, no n/w partitions
  • 802.11 MAC
  • DCF mode for broadcast (e.g. for JQs)
  • RTS/CTS for unicast (e.g. for JRs)
  • Evaluated AMRIS, CAMP, AMRoute, flooding in same
    setup
  • No mobility prediction, 512 bytes data payload
  • Multicast members stay from beginning to end

13
Metrics
  • Packet delivery ratio packets delivered
  • packets supposed to be delivered
  • Measures protocol effectiveness
  • Data packets transmitted
  • data packet delivered
  • Data packets transmitted every packet
    transmitted by every node over entire network
    (including drops retransmissions)
  • Unlike in unicast, this can be smaller than 1
  • No. of controlheader bytes transmitted
  • delivered data byte
  • Measures utilization of control packets in
    delivering data
  • No. of control and data packets transmitted
  • delivered data packet
  • Measures efficiency in terms of channel access

14
Packet delivery ration vs. Mobility Speed
  • Pre-defined speeds 0 72 km/h, 20 members, 5
    sources, 2pkts/sec
  • ODMRP performs good even in high mobility - due
    to Mesh topology
  • CAMP suffers - packets to distant routers not
    delivered due to fewer redundant paths away from
    core
  • AMRIS suffers due lack to redundant paths b/w
    any member pairs
  • AMRoute worst in high mobility due to loops
    and sub-optimal trees
  • Relies on underlying unicast protocol to set
    bi-directional links

15
Data Packets TXed /delivered data packet
  • Mesh-based protocols transmit more data packets
    than AMRIS, which tree-based
  • ODMRP transmits nearly as much as flooding

16
No. of Control Bytes TXed/Data byte
  • Flooding has no control packets. Pkt-header
    overhead doesnt increase with mobility
  • AMRIS low control overhead because transmits
    less data in the first place
  • CAMPs control overhead overtakes ODMRPs with
    high mobility because underlying unicast protocol
    causes triggered updates
  • AMRoute high control overhead due to loops and
    inefficient trees

17
No. of Packets TXed/data packet delivered
  • AMRIS smallest ratio because tree-based
  • AMRoute highest ratio because of loops
  • CAMP has smaller number of transmission than
    ODMRP
  • ODMR transmits more data on redundant paths than
    CAMP
  • Even though CAM has more control bytes,, control
    packets for updates are piggybacked onto updates
    of WRP (underlying DV based unicast protocol)

18
Packet Deliver ratio vs. No of Senders (Group
size constant)
  • Performance of flooding slightly degrades with
    increase in senders due to collision, congestion
  • For ODMRP CAMP performance remains robust,
  • in fact improves because better path redundancy
    increasing number of senders
  • For AMRIS, AMRoute performance unaffected
    because they use shared tree

19
Packet Delivery Ratio vs.. Group Size
  • ODMRP performance unaffected by group size
  • CAMP performance improves with group size
    bigger group ? more redundant paths for nodes
    away from core
  • AMRIS improves but not much due to lack of
    redundant paths
  • AMRoute ratio drops since one-way critical
    links increase as tree grows

20
Packet Delivery Ratio vs.. Traffic
  • ODMRP better than flooding because no of data pkt
    transmissions is less than flooding
  • ODMRP better than CAMP due to less control
    overhead and suffers less buffer overflow than
    CAMP
  • AMRoute suffers buffer overflow at tree-members
    and mesh nodes connecting trees
  • AMRIS suffers high collisions because of size and
    transmission of beacon packets

21
Summary of ODMRP
  • Mesh-based protocol - robust to high mobility
  • Low channel and storage overhead due to lack of
    control packets on link breaks
  • even in highly mobile networks
  • On-demand soft state approach to membership
    maintenance
  • Usage of up-to-date shortest routes
  • Reliable construction of routes and forwarding
    groups
  • JQ Flooding may contribute to congestion
    contention, collision

22
Summary of Protocols
Write a Comment
User Comments (0)
About PowerShow.com