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 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 (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 (7/8) – Routing Tables

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 (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 (6/7) – Unicast

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 (3/6)

Simulation Results (4/6)

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)

Simulation Results (6/6)

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