dht-based unicast for mobile ad hoc networks thomas zahn, jochen schiller institute of computer...
Post on 13-Dec-2015
216 Views
Preview:
TRANSCRIPT
DHT-based unicast for mobile ad hoc networks
Thomas Zahn, Jochen Schiller
Institute of Computer Science
Freie Universitat Berlin
報告 :羅世豪
Introduction (1/4)
Both MANETs and peer-to-peer (P2P) overlay networks share a number of key characteristics.
the lack of a central infrastructure highly dynamic network topologies the need for self-organization
Introduction (2/4)
Distributed Hash Tables (DHTs) have been proposed for large-scale network applications.
Route a packet based on a key (rather than a fixed destination address) to the (unknown) node in the network that is currently responsible for the given key within a bounded number of hops.
This overlay routing is also referred to as indirect routing.
Introduction (3/4)
DHTs do not closely concern themselves with the physical (routing) aspects of the underlying network
designed to form overlay networks in Internet-based networks where physical routing is practically taken for granted.
Introduction (4/4)
In MANETs, DHT can provide indirect routing direct physical routing (unicasting)
MADPastry a DHT substrate explicitly designed for MANETs
DHT-based unicast can achieve better packet delivery rates lower network traffic
MADPastry (1/8)
MADPastry combines AODV ad hoc routing and Pastry overlay routing at the network layer
provide an efficient primitive for key-based routing in MANETs.
MADPastry (2/8)
Each node in a MADPastry network assigns itself a unique overlay id
defines its logical position on the virtual overlay id ring.
A message's packet header contains a message key. MADPastry routes the message to that node in the netwo
rk that is currently responsible for the message key the node whose overlay id is currently the numerically closest to
the message key among all MADPastry nodes in the network.
To avoid message broadcasts (e.g. for route discovery) MADPastry considers physical locality in the construction of its
routing tables.
MADPastry (3/8) - Clusters
Random Landmark No fixed landmark nodes, landmark keys instead
These keys divide the logical overlay id space into equal sections
0800..00, 1800..00, ......., F800..00
Node currently closest to a landmark key Become temporary landmark node Periodically issue beacon messages
Nodes overhear these beacon messages and periodically determine the physically closest temporary landmark node.
MADPastry (4/8) - Clusters
Node associates itself with closest temporary landmark
assumes same overlay ID prefix If need be, a node assigns itself a new overlay id
sharing the same prefix with the new closest temporary landmark node.
physically close nodes forming overlay clusters with common id prefixes
Physically close nodes are also likely to be close in the overlay
MADPastry (6/8) – Routing Tables
MADPastry maintains three different routing tables:
AODV-style routing table for physical routes from a node to specific target nodes
stripped down Pastry routing table that only contain landmark keys
standard Pastry leaf set for indirect routing
MADPastry (8/8) - Routing
When a node wants to send a packet to a specific key1. Consults its Pastry routing table and/or leaf set to determine the
closest prefix match, as stipulated by standard Pastry. 2. Consults its AODV routing table for the physical route to
execute this overlay hop. 3. Intermediate nodes on the physical path of an overlay hop
consult their AODV table for the corresponding next physical hop.
4. When a packet reaches the destination of an overlay hop, that node again consults its Pastry routing table and/or leaf set to determine the next overlay hop.
This process continues until the packet reaches the eventual target node that is responsible for the packet key ( whose overlay id is the numerically closest to the packet key).
MADPastry’s Unicast (1/7) – Address Publication
Each nodes has exactly one temporary address server
Address server stores its client's current overlay ID
Node A hashes its node ID address server key (ASK).
Node A publishes its current overlay ID towards ASK
Node currently responsible for node A's hash key becomes node A's address server
MADPastry’s Unicast (3/7) – Address Resolution
Node A wants to communicate with node B Node A does not know node B's current overlay
ID Node A hashes node B's net ID to get ASK Node A sends request towards ASK Node B's address server replies with node B's
current overlay ID
MADPastry’s Unicast (5/7) – Unicast
Node A uses overlay ID from reply to send message to node B
MADPastry delivers message using indirect routing
MADPastry’s Unicast (7/7)
Shortest Routing Paths A direct, straight path from the source node to the destination no
de When using AODV and it doesn’t know the path to that destinat
ion, it needs to engage in a costly route discovery process
MADPastry’s Routing Paths Probably travel multiple overlay hops The entries in its routing table are likely up-to-date and valid Usually won’t have to discover a route because it can use at eac
h overlay routing step any existing route that would bring the packet numerically closer to its key
Simulation Results (1/6)
Compare MADPastry's unicast against a popular ad hoc routing protocol
AODV (reactive) OLSR (proactive)
Simulations in ns2 1 random request every 10s per node
Simulation Results (2/6)
requestssent ofnumber total
responses receivedly successful ofnumber totalrate Success
Constant node velocity:1.4 m/s Varying network sizes (50,100,150,200,250)
Simulation Results (5/6)
requestssent ofnumber total
responses receivedly successful ofnumber totalrate Success
Constant network size:250 nodes Varying node velocities (0.1,1.4, 2.5,5.0 m/s)
Conclusion (2/2)
MADPastry already present in the MANET to provide key-based, indirect routing
MADPastry can also provide point-to-point unicasting
No need to maintain ad hoc routing protocol in parallel for DHT applications that use MADPastry handle their point-to-point routing
top related