290 likes | 402 Views
DHT-based unicast for mobile ad hoc networks. Thomas Zahn, Jochen Schiller Institute of Computer Science Freie Universitat Berlin 報告 : 羅世豪. Outline. Introduction MADPastry MADPastry’s Unicast Simulation Results Conclusion. Introduction (1/4).
E N D
DHT-based unicast for mobile ad hoc networks Thomas Zahn, Jochen Schiller Institute of Computer Science Freie Universitat Berlin 報告:羅世豪
Outline • Introduction • MADPastry • MADPastry’s Unicast • Simulation Results • Conclusion
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 network that iscurrently 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 (5/8)- Spatial Topology Spatial Topology
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 key • Consults its Pastry routing table and/or leaf set to determine the closest prefix match, as stipulated by standard Pastry. • Consults its AODV routing table for the physical route to execute this overlay hop. • Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop. • 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 (2/7) – Address Publication ASK:h(17) →B7A9CC
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 (4/7)– Address Resolution ASK: h(17) →B7A9CC
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 node • When using AODV and it doesn’t know the path to that destination, 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 each 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) • Constant node velocity:1.4 m/s • Varying network sizes (50,100,150,200,250)
Simulation Results (5/6) • 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
Conclusion (2/2) • MADPastry's unicast can outperform popular reactive and proactive ad hoc routing protocols • In MANETs it can be advantageous to travel numerous short up-to-date routes instead of one long direct route